draft-ietf-softwire-stateless-4v6-motivation-03.txt   draft-ietf-softwire-stateless-4v6-motivation-04.txt 
Softwires Working Group M. Boucadair, Ed. Softwires Working Group M. Boucadair, Ed.
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Informational S. Matsushima Intended status: Informational S. Matsushima
Expires: December 17, 2012 Softbank Telecom Expires: March 3, 2013 Softbank Telecom
Y. Lee Y. Lee
Comcast Comcast
O. Bonness O. Bonness
Deutsche Telekom Deutsche Telekom
I. Borges I. Borges
Portugal Telecom Portugal Telecom
G. Chen G. Chen
China Mobile China Mobile
June 15, 2012 August 30, 2012
Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Motivations for Carrier-side Stateless IPv4 over IPv6 Migration
Solutions Solutions
draft-ietf-softwire-stateless-4v6-motivation-03 draft-ietf-softwire-stateless-4v6-motivation-04
Abstract Abstract
IPv4 service continuity is one of the most pressing problems that IPv4 service continuity is one of the most pressing problems that
must be resolved by Service Providers during the IPv6 transition must be resolved by Service Providers during the IPv6 transition
period - especially after the exhaustion of the public IPv4 address period - especially after the exhaustion of the public IPv4 address
space. Current standardization effort that addresses IPv4 service space. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates continuity focuses on stateful mechanisms. This document elaborates
on the motivations for the need to undertake a companion effort to on the motivations for the need to undertake a companion effort to
specify stateless IPv4 over IPv6 approaches. specify stateless IPv4 over IPv6 approaches.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2012. This Internet-Draft will expire on March 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 4, line 47 skipping to change at page 4, line 47
Below is provided a list of motivations which justify the need for a Below is provided a list of motivations which justify the need for a
stateless solution (in no particular order): stateless solution (in no particular order):
(1) Minimizes impact on OSS and logging systems. Ideally, it does (1) Minimizes impact on OSS and logging systems. Ideally, it does
not require OSS & logging systems that wouldn't be there in a not require OSS & logging systems that wouldn't be there in a
pure IPv6 network. pure IPv6 network.
(2) Does not require maintaining per-subscriber configuration on (2) Does not require maintaining per-subscriber configuration on
active data plane network elements. active data plane network elements.
(3) Scales in terms of IP forwarding capacity, rather than amount (3) Scales in terms of IP forwarding capacity, rather than amount
of dynamic state, or new session creation rate. of dynamic state, or new session creation rate.
(4) Support a single architecture that allows 1:1 or N:1 (port (4) Supports a single architecture that allows 1:1 or N:1 (port
range) NAT44 usage without additional extensions. range) NAT44 usage without additional extensions.
(5) Preserves current engineering practices (e.g., anycast-based (5) Preserves current engineering practices (e.g., anycast-based
load-balancing). load-balancing).
(6) Relies on IPv6 and supports transition to an IPv6-only network. (6) Relies on IPv6 and supports transition to an IPv6-only network.
(7) Supports asymmetric routing to/from the IPv4 Internet. (7) Supports asymmetric routing to/from the IPv4 Internet.
(8) Maximizes the ease of deployment and redundancy of nodes. (8) Maximizes the ease of deployment and redundancy of nodes.
(9) Readily supports a multi vendor environment (including (9) Readily supports a multi-vendor environment (including
redundancy). redundancy).
(10) Allows direct user-user traffic flows (i.e., allows for no- (10) Allows direct user-user traffic flows (i.e., allows for no-
tromboning) tromboning)
(11) Retains today's user experience (NAT on CPE) and supports (11) Retains today's user experience (NAT on CPE) and supports
today's operational model. today's operational model.
(12) Does not require deployment of (additional) dynamic signaling (12) Does not require deployment of (additional) dynamic signaling
protocols to the end-user CPE beyond those already used. protocols to the end-user CPE beyond those already used.
(13) Minimizes required non-regression testing effort. (13) Minimizes required non-regression testing effort.
(14) Does not require organizational changes. (14) Does not require organizational changes.
(15) Assumes a clear separation between the service and the network (15) Assumes a clear separation between the service and the network
skipping to change at page 7, line 34 skipping to change at page 7, line 34
robustness in the context of stateless solutions. Since no state is robustness in the context of stateless solutions. Since no state is
maintained in the Service Provider's network, state synchronization maintained in the Service Provider's network, state synchronization
procedures are not required. procedures are not required.
High availability (including failure recovery) is ensured owing to High availability (including failure recovery) is ensured owing to
best current practices in the field. best current practices in the field.
3.2.4. Support of Multi-Vendor Redundancy 3.2.4. Support of Multi-Vendor Redundancy
Deploying stateful techniques, especially when used in the Service Deploying stateful techniques, especially when used in the Service
Providers networks, constrain severely deploying multi-vendor Providers networks, constrains severely deploying multi-vendor
redundancy since very often proprietary vendor-specific protocols are redundancy since very often proprietary vendor-specific protocols are
used to synchronize state. This is not an issue for the stateless used to synchronize state. This is not an issue for the stateless
case. Concretely, the activation of the stateless IPv4/IPv6 case. Concretely, the activation of the stateless IPv4/IPv6
interconnection function does not prevent nor complicate deploying interconnection function does not prevent nor complicate deploying
devices from different vendors. devices from different vendors.
This criterion is very important for Service Providers having a This criterion is very important for Service Providers having a
sourcing policy to avoid mono-vendor deployments and to operate sourcing policy to avoid mono-vendor deployments and to operate
highly-available networks composed on multi-vendors equipment. highly-available networks composed on multi-vendors equipment.
skipping to change at page 8, line 47 skipping to change at page 8, line 47
the end users (less Quality of Experience (QoE)). the end users (less Quality of Experience (QoE)).
When a stateless solution is deployed, implicit identification for When a stateless solution is deployed, implicit identification for
internal services is likely to be easier to implement: the implicit internal services is likely to be easier to implement: the implicit
identification should be updated to take into account the port range identification should be updated to take into account the port range
and the IPv4 address. Techniques as those analyzed in and the IPv4 address. Techniques as those analyzed in
[I-D.ietf-intarea-nat-reveal-analysis] are not required for the [I-D.ietf-intarea-nat-reveal-analysis] are not required for the
delivery of these internal services if a stateless solution is delivery of these internal services if a stateless solution is
deployed. deployed.
Note stateful approaches configured to assign port ranges allows also Note stateful approaches configured to assign port ranges allow also
to support implicit host identification. to support implicit host identification.
3.3.2. No Organizational Impact 3.3.2. No Organizational Impact
Stateless solutions adopt a clear separation between the IP/transport Stateless solutions adopt a clear separation between the IP/transport
layers and the service layers; no service interference is to be layers and the service layers; no service interference is to be
observed when a stateless solution is deployed. This clear observed when a stateless solution is deployed. This clear
separation: separation:
Facilitates service evolution: Since the payload of IPv4 packets is Facilitates service evolution: Since the payload of IPv4 packets is
skipping to change at page 14, line 8 skipping to change at page 14, line 8
[EURESCOM] [EURESCOM]
Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4 Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4
address exhaustion: Issues and Solutions for Service address exhaustion: Issues and Solutions for Service
Providers", March 2010, <http://archive.eurescom.eu/~pub/ Providers", March 2010, <http://archive.eurescom.eu/~pub/
deliverables/documents/P1900-series/P1952/D2bis/ deliverables/documents/P1900-series/P1952/D2bis/
P1952-D2bis.pdf>. P1952-D2bis.pdf>.
[I-D.ietf-behave-lsn-requirements] [I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-07 (work in (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in
progress), June 2012. progress), August 2012.
[I-D.ietf-intarea-nat-reveal-analysis] [I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno, Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host "Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments", Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-02 (work in draft-ietf-intarea-nat-reveal-analysis-04 (work in
progress), April 2012. progress), August 2012.
[I-D.matsushima-v6ops-transition-experience] [I-D.matsushima-v6ops-transition-experience]
Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and
J. Jiao, "Use case and consideration experiences of IPv4 J. Jiao, "Use case and consideration experiences of IPv4
to IPv6 transition", to IPv6 transition",
draft-matsushima-v6ops-transition-experience-02 (work in draft-matsushima-v6ops-transition-experience-02 (work in
progress), March 2011. progress), March 2011.
[I-D.vixie-dnsext-dns0x20] [I-D.vixie-dnsext-dns0x20]
Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
 End of changes. 10 change blocks. 
12 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/