draft-ietf-softwire-stateless-4v6-motivation-00.txt   draft-ietf-softwire-stateless-4v6-motivation-01.txt 
Network Working Group M. Boucadair, Ed. softwire M. Boucadair, Ed.
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Informational S. Matsushima Intended status: Informational S. Matsushima
Expires: March 12, 2012 Softbank Telecom Expires: August 13, 2012 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
September 9, 2011 February 10, 2012
Motivations for Stateless IPv4 over IPv6 Migration Solutions Motivations for Stateless IPv4 over IPv6 Migration Solutions
draft-ietf-softwire-stateless-4v6-motivation-00 draft-ietf-softwire-stateless-4v6-motivation-01
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 12, 2012. This Internet-Draft will expire on August 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 4 3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 4
3.1. Network Architecture Simplification . . . . . . . . . . . 5 3.1. Network Architecture Simplification . . . . . . . . . . . 5
3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5 3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5
3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5 3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5
3.1.3. Logging - No Need for Dynamic Binding Notifications . 6 3.1.3. Logging - No Need for Dynamic Binding Notifications . 5
3.1.4. No Additional Protocol for Port Control is Required . 6 3.1.4. No Additional Protocol for Port Control is Required . 6
3.2. Operational Tasks and Network Maintenance Efficiency . . . 6 3.2. Operational Tasks and Network Maintenance Efficiency . . . 6
3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 7 3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 6
3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7 3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7
3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7 3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7
3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7 3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7
3.2.5. Simplification of Qualification Procedures . . . . . . 8 3.2.5. Simplification of Qualification Procedures . . . . . . 7
3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8 3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8
3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8 3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8
3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 9 3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 8
3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9 3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 11 4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 10
4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11 4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11
4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 12 4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . . 14 10. Informative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
When the global IPv4 address space is exhausted, Service Providers When the global IPv4 address space is exhausted, Service Providers
will be left with an address pool that cannot be increased anymore. will be left with an address pool that cannot be increased anymore.
Many services and network scenarios will be impacted by the lack of Many services and network scenarios will be impacted by the lack of
IPv4 public addresses. Providing access to the (still limited) IPv6 IPv4 public addresses. Providing access to the (still limited) IPv6
Internet only won't be sufficient to address the needs of customers, Internet only won't be sufficient to address the needs of customers,
as most of them will continue to access legacy IPv4-only services. as most of them will continue to access legacy IPv4-only services.
skipping to change at page 3, line 45 skipping to change at page 3, line 45
companion effort is required to specify stateless IPv4 over IPv6 companion effort is required to specify stateless IPv4 over IPv6
approaches. This document provides elaboration on such need. approaches. This document provides elaboration on such need.
More discussions about stateless vs. stateful can be found at More discussions about stateless vs. stateful can be found at
[RFC6144]. [RFC6144].
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
State: as used in [RFC1958]. State: as used in [RFC1958].
Session state: refers to an information state as defined in Session state: refers to an information state as defined in Section
Section 2.3 of [RFC2663]. In particular, it 2.3 of [RFC2663]. In particular, it refers to the state
refers to the state maintained by the NAT so that maintained by the NAT so that datagrams pertaining to a session
datagrams pertaining to a session are routed to are routed to the right node. Note, TCP/UDP sessions are
the right node. Note, TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source
uniquely identified by the tuple of (source IP TCP/UDP port, target IP address, target TCP/UDP port) while ICMP
address, source TCP/UDP port, target IP address, query sessions are identified by the tuple of (source IP
target TCP/UDP port) while ICMP query sessions address, ICMP query ID, target IP address).
are identified by the tuple of (source IP
address, ICMP query ID, target IP address).
User-session state: refers to session state belonging to a given User-session state: refers to session state belonging to a given
user. user.
Stateful 4/6 solution (or stateful solution in short): denotes a Stateful 4/6 solution (or stateful solution in short): denotes a
solution where the network maintains user-session solution where the network maintains user-session states relying
states relying on the activation of a NAT on the activation of a NAT function in the Service Providers'
function in the Service Providers' network network [I-D.ietf-behave-lsn-requirements]. The NAT function is
[I-D.ietf-behave-lsn-requirements]. The NAT responsible for sharing the same IPv4 address among several
function is responsible for sharing the same IPv4 subscribers and to maintain user-session state.
address among several subscribers and to maintain
user-session state.
Stateless 4/6 solution (or stateless solution in short): denotes a Stateless 4/6 solution (or stateless solution in short): denotes a
solution which does not require any per-user solution which does not require any per-user state (see Section
state (see Section 2.3 of [RFC1958]) to be 2.3 of [RFC1958]) to be maintained by any IP address sharing
maintained by any IP address sharing function in function in the Service Provider's network. This category of
the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4
solutions assumes a dependency between an IPv6 address. In an IPv4 address sharing context, dedicated
prefix and IPv4 address. In an IPv4 address functions are required to be enabled in the CPE router to
sharing context, dedicated functions are required restrict the source IPv4 port numbers. Within this document,
to be enabled in the CPE router to restrict the "port set" and "port range" terms are used interchangeably.
source IPv4 port numbers. Within this document,
"port set" and "port range" terms are used
interchangeably.
3. Why Stateless IPv4 over IPv6 Solutions are Needed? 3. Why Stateless IPv4 over IPv6 Solutions are Needed?
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.
skipping to change at page 5, line 4 skipping to change at page 4, line 41
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) Support 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
layer and therefore there is no interference between delivered layer and therefore there is no interference between delivered
skipping to change at page 5, line 26 skipping to change at page 5, line 19
(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
layer and therefore there is no interference between delivered layer and therefore there is no interference between delivered
services and underlying network transfer capabilities. services and underlying network transfer capabilities.
This section elaborates further on the aforementioned motivations. This section elaborates further on the aforementioned motivations.
The technical and operational benefits of the stateless solutions are
possible because no per-user state [RFC1958] is maintained in the
Service Providers networks.
3.1. Network Architecture Simplification 3.1. Network Architecture Simplification
The activation of the stateless function in the Service Provider's The activation of the stateless function in the Service Provider's
network does not introduce any major constraint on the network network does not introduce any major constraint on the network
architecture and its engineering. The following sub-sections architecture and its engineering. The following sub-sections
elaborate on these aspects. elaborate on these aspects.
3.1.1. Network Dimensioning 3.1.1. Network Dimensioning
Because no per-user state [RFC1958] is required, a stateless solution Because no per-user state [RFC1958] is required, a stateless solution
does not need to take into account the maximum number of simultaneous does not need to take into account the maximum number of simultaneous
user-sessions and the maximum number of new user-sessions per second user-sessions and the maximum number of new user-sessions per second
to dimension its networking equipment. Like current network to dimension its networking equipment. Like current network
dimensioning practices, only considerations related to the customer dimensioning practices, only considerations related to the customers
number, traffic trends and the bandwidth usage need be taken into number, traffic trends and the bandwidth usage need be taken into
account for dimensioning purposes. account.
3.1.2. No Intra-domain Constraint 3.1.2. No Intra-domain Constraint
Stateless IPv4/IPv6 interconnection functions can be ideally located Stateless IPv4/IPv6 interconnection functions can be ideally located
at the boundaries of an Autonomous System (e.g., ASBR routers that at the boundaries of an Autonomous System (e.g., ASBRs that peer with
peer with external IPv4 domains); in such case: external IPv4 domains); in such case intra-domain paths are not
altered: there is no need to force IP packets to cross a given node
Intra-domain paths are not altered: there is no need to force IP for instance; intra-domain routing processes are not tweaked to
packets to cross a given node for instance; intra-domain routing direct the traffic to dedicated nodes. Stateless solutions optimize
processes are not tweaked to direct the traffic to dedicated CPE-to-CPE communication in that packets don't go through the
nodes. In particular, stateless solutions optimize CPE-to-CPE interconnection function.
communication in that packets don't go through the interconnection
function since the address and port mapping has been realized
based on a well defined mapping schema that is known to all
involved devices.
3.1.3. Logging - No Need for Dynamic Binding Notifications 3.1.3. Logging - No Need for Dynamic Binding Notifications
Network abuse reporting requires traceability [RFC6269]. To provide Network abuse reporting requires traceability [RFC6269]. To provide
such traceability, prior to IPv4 address sharing, logging the IPv4 such traceability, prior to IPv4 address sharing, logging the IPv4
address assigned to a user was sufficient and generates relatively address assigned to a user was sufficient and generates relatively
small logs. The advent of stateful IPv4 address allows dynamic port small logs. The advent of stateful IPv4 address allows dynamic port
assignment, which then requires port assignment logging. This assignment, which then requires port assignment logging. This
logging of port assignments can be considerable. logging of port assignments can be considerable.
skipping to change at page 6, line 43 skipping to change at page 6, line 27
solutions, there is no need for dynamic procedures (e.g., using solutions, there is no need for dynamic procedures (e.g., using
SYSLOG) to notify a mediation platform about assigned bindings. SYSLOG) to notify a mediation platform about assigned bindings.
Some Service Providers have a requirement to use only existing Some Service Providers have a requirement to use only existing
logging systems and to avoid introducing new ones (mainly because of logging systems and to avoid introducing new ones (mainly because of
CAPEX considerations). This requirement is easily met with stateless CAPEX considerations). This requirement is easily met with stateless
solutions. solutions.
3.1.4. No Additional Protocol for Port Control is Required 3.1.4. No Additional Protocol for Port Control is Required
The deployment of stateless solution does not require the deployment Stateless solutions do not require activating a new dynamic signaling
of new dynamic signaling protocols to the end-user CPE in addition to protocol in the end-user CPE in addition to those already used. In
those already used. In particular, existing protocols (e.g., UPnP particular, existing protocols (e.g., UPnP IGD:2 [UPnP-IGD]) can be
IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. used to control the NAT mappings in the CPE.
3.2. Operational Tasks and Network Maintenance Efficiency 3.2. Operational Tasks and Network Maintenance Efficiency
3.2.1. Preserve Current Practices 3.2.1. Preserve Current Practices
Service Providers require as much as possible to preserve the same Service Providers require as much as possible to preserve the same
operations as for current IP networking environments. operations as for current IP networking environments.
If stateless solutions are deployed, common practices are preserved. If stateless solutions are deployed, common practices are preserved.
In particular, the maintenance and operation of the network do not In particular, the maintenance and operation of the network do not
require any additional constraints such as: path optimization require any additional constraints such as: path optimization
practices, enforcing traffic engineering policies, issues related to practices, enforcing traffic engineering policies, issues related to
traffic oscillation between stateful devices, load-balancing the traffic oscillation between stateful devices, load-balancing the
skipping to change at page 7, line 15 skipping to change at page 6, line 45
Service Providers require as much as possible to preserve the same Service Providers require as much as possible to preserve the same
operations as for current IP networking environments. operations as for current IP networking environments.
If stateless solutions are deployed, common practices are preserved. If stateless solutions are deployed, common practices are preserved.
In particular, the maintenance and operation of the network do not In particular, the maintenance and operation of the network do not
require any additional constraints such as: path optimization require any additional constraints such as: path optimization
practices, enforcing traffic engineering policies, issues related to practices, enforcing traffic engineering policies, issues related to
traffic oscillation between stateful devices, load-balancing the traffic oscillation between stateful devices, load-balancing the
traffic or load sharing the traffic among egress/ingress points can traffic or load sharing the traffic among egress/ingress points can
be used, etc. In particular: be used, etc. Particularly,
o anycast-based schemes can be used for load-balancing and o anycast-based schemes can be used for load-balancing and
redundancy purposes. redundancy purposes.
o asymmetric routing to/from the IPv4 Internet is natively supported o asymmetric routing to/from the IPv4 Internet is natively supported
and no path-pinning mechanisms have to be additionally and no path-pinning mechanisms have to be additionally
implemented. implemented.
3.2.2. Planned Maintenance Operations 3.2.2. Planned Maintenance Operations
skipping to change at page 8, line 15 skipping to change at page 7, line 45
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.
3.2.5. Simplification of Qualification Procedures 3.2.5. Simplification of Qualification Procedures
The introduction of new functions and nodes into operational networks The introduction of new functions and nodes into operational networks
follows strict procedures elaborated by Service Providers. These follows strict procedures elaborated by Service Providers. These
procedures include in-lab testing and field trials. Because of their procedures include in-lab testing and field trials. Because of their
nature, stateless implementations optimize testing times and nature, stateless implementations optimize testing time and
procedures: procedures:
o The specification of test suites to be conducted should be o The specification of test suites to be conducted should be
shorter; shorter;
o The required testing resources (in terms of manpower) are likely o The required testing resources (in terms of manpower) are likely
to be less solicited that they are for stateful approaches. to be less solicited that they are for stateful approaches.
One of the privileged approaches to integrate stateless IPv4/IPv6 One of the privileged approaches to integrate stateless IPv4/IPv6
interconnection function consists in embedding stateless capabilities interconnection function consists in embedding stateless capabilities
skipping to change at page 9, line 9 skipping to change at page 8, line 40
services relies on implicit identification mechanism based on the services relies on implicit identification mechanism based on the
source IPv4 address. Due to address sharing, implicit identification source IPv4 address. Due to address sharing, implicit identification
will fail [RFC6269]; replacing implicit identification with explicit will fail [RFC6269]; replacing implicit identification with explicit
authentication will be seen as a non acceptable service regression by authentication will be seen as a non acceptable service regression by
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.boucadair-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 allows 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 adopts a clear separation between the IP/ Stateless solutions adopt a clear separation between the IP/transport
transport layers and the service layers; no service interference is layers and the service layers; no service interference is to be
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
not altered in the path, services can evolve without requiring any not altered in the path, services can evolve without requiring any
specific function (e.g., Application Level Gateway (ALG)) in the specific function (e.g., Application Level Gateway (ALG)) in the
Service Provider's network; Service Provider's network;
Limits vendor dependency: The upgrade of value-added services does Limits vendor dependency: The upgrade of value-added services does
not involve any particular action from vendors that provide not involve any particular action from vendors that provide
devices embedding the stateless IPv4/IPv6 interconnection devices embedding the stateless IPv4/IPv6 interconnection
skipping to change at page 9, line 43 skipping to change at page 9, line 25
No service-related skills are required for network operators who No service-related skills are required for network operators who
manage devices that embed the IPv4/IPv6 interconnection function: IP manage devices that embed the IPv4/IPv6 interconnection function: IP
teams can be in charge of these devices; there is a priori no need teams can be in charge of these devices; there is a priori no need
to create a dedicated team to manage and to operate devices to create a dedicated team to manage and to operate devices
embedding the stateless IPv4/IPv6 interconnection function. The embedding the stateless IPv4/IPv6 interconnection function. The
introduction of stateless capabilities in the network are unlikely introduction of stateless capabilities in the network are unlikely
to degrade management costs. to degrade management costs.
3.4. Cost Minimization Opportunities 3.4. Cost Minimization Opportunities
To make decision for which solution is to be adopted, service To make decision for which solution is to be adopted, Service
providers usually undertake comparative studies about viable Providers usually undertake comparative studies about viable
technical solutions. It is not only about technical aspects but also technical solutions. It is not only about technical aspects but also
economical optimization (both CAPEX and OPEX considerations). economical optimization (both CAPEX and OPEX considerations). From a
Service Provider perspective, stateless solutions are more attractive
From a Service Provider perspective, stateless solutions are more because they do less impact the current network operations and
attractive because they do less impact the current network operations maintenance model that is widely based on stateless approaches.
and maintenance model that is widely based on stateless approaches.
Table 1 shows the general correspondence between technical benefits Table 1 shows the general correspondence between technical benefits
and potential economic reduction opportunities. and potential economic reduction opportunities.
While not all Service Providers environments are the same, a detailed While not all Service Providers environments are the same, a detailed
case study from one Service Provider case study from one Service Provider
[I-D.matsushima-v6ops-transition-experience] reports that stateless [I-D.matsushima-v6ops-transition-experience] reports that stateless
transition solutions can be considerably less expensive than stateful transition solutions can be considerably less expensive than stateful
transition solutions. transition solutions.
+---------------+--------------------------------------+------------+ +---------------+--------------------------------------+------------+
skipping to change at page 10, line 45 skipping to change at page 10, line 39
| | internal services | | | | internal services | |
+---------------+--------------------------------------+------------+ +---------------+--------------------------------------+------------+
| Section 3.3.2 | Organizational Impact | Ops | | Section 3.3.2 | Organizational Impact | Ops |
+---------------+--------------------------------------+------------+ +---------------+--------------------------------------+------------+
Table 1: Cost minimization considerations Table 1: Cost minimization considerations
4. Discussion 4. Discussion
Issues common to all address sharing solutions are documented in Issues common to all address sharing solutions are documented in
[RFC6269]. The following sub-sections enumerates some open questions [RFC6269]. The following sub-sections enumerate some open questions
for a CPE-based stateless solution. There are no universal answers for a CPE-based stateless solution. There are no universal answers
to these open questions since each Service Provider has its own to these open questions since each Service Provider has its own
constraints (e.g., available address pool, address sharing ratio, constraints (e.g., available address pool, address sharing ratio,
etc.). etc.).
4.1. Dependency Between IPv4 and IPv6 Address Assignments 4.1. Dependency Between IPv4 and IPv6 Address Assignments
Complete stateless mapping implies that the IPv4 address and the Complete stateless mapping implies that the IPv4 address and the
significant bits that are used to encode the set of assigned ports significant bits that are used to encode the set of assigned ports
can be retrieved from the IPv6 prefix assigned to the CPE. This can be retrieved from the IPv6 prefix assigned to the CPE. This
skipping to change at page 11, line 45 skipping to change at page 11, line 37
CGN-based solutions, because they can dynamically assign ports, CGN-based solutions, because they can dynamically assign ports,
provide better IPv4 address sharing ratio than stateless solutions provide better IPv4 address sharing ratio than stateless solutions
(i.e., can share the same IP address among a larger number of (i.e., can share the same IP address among a larger number of
customers). For Service Providers who desire an aggressive IPv4 customers). For Service Providers who desire an aggressive IPv4
address sharing, a CGN-based solution is more suitable than the address sharing, a CGN-based solution is more suitable than the
stateless. However stateless. However
1: When port overloading is used, some applications are likely to be 1: When port overloading is used, some applications are likely to be
broken. broken.
2: in case a CGN pre-allocates port ranges, for instance to 2: in case a CGN pre-allocates port ranges, e.g.- to alleviate
alleviate traceability complexity (see Section 3.1.3) it also traceability complexity (see Section 3.1.3), it also reduces its
reduces its port utilization efficiency. port utilization efficiency.
4.3. IPv4 Port Randomization 4.3. IPv4 Port Randomization
Preserving port randomization [RFC6056] may be more or less difficult Preserving port randomization [RFC6056] may be more or less difficult
depending on the address sharing ratio (i.e., the size of the port depending on the address sharing ratio (i.e., the size of the port
space assigned to a CPE). Port randomization may be more difficult space assigned to a CPE). The CPE can only randomize the ports
to achieve with a stateless solution than stateful solution. The CPE inside a fixed port range.
can only randomize the ports inside a fixed port range.
More discussion to improve the robustness of TCP against Blind In- More discussion to improve the robustness of TCP against Blind In-
Window Attacks can be found at [RFC5961]. Window Attacks can be found at [RFC5961]. Other means than the
(IPv4) source port randomization to provide protection against
Other means than the (IPv4) source port randomization to provide attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to
protection against attacks should be used (e.g., use protect against DNS attacks, [RFC5961] to improve the robustness of
[I-D.vixie-dnsext-dns0x20] to protect against DNS attacks, [RFC5961] TCP against Blind In-Window Attacks, use IPv6).
to improve the robustness of TCP against Blind In-Window Attacks, use
IPv6).
5. Conclusion 5. Conclusion
As discussed in Section 3, stateless solutions provide several As discussed in Section 3, stateless solutions provide several
interesting features. Trade-off between the positive vs. negative interesting features. Trade-off between the positive vs. negative
aspects of stateless solutions is left to Service Providers. Each aspects of stateless solutions is left to Service Providers. Each
Service Provider will have to select the appropriate solution Service Provider will have to select the appropriate solution
(stateless, stateful or even both) meeting its requirements. (stateless, stateful or even both) meeting its requirements.
This document recommends to undertake as soon as possible the This document recommends to undertake as soon as possible the
skipping to change at page 13, line 7 skipping to change at page 13, line 7
security vulnerabilities than stateful ones. Because of their security vulnerabilities than stateful ones. Because of their
stateless nature, they may in addition reduce denial of service stateless nature, they may in addition reduce denial of service
opportunities. opportunities.
8. Contributors 8. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
Christian Jacquenet Christian Jacquenet
France Telecom France Telecom
Email: christian.jacquenet@orange.com
Email: christian.jacquenet@orange-ftgroup.com
Pierre Levis Pierre Levis
France Telecom France Telecom
Email: pierre.levis@orange.com
Email: pierre.levis@orange-ftgroup.com
Masato Yamanishi Masato Yamanishi
SoftBank BB SoftBank BB
Email: myamanis@bb.softbank.co.jp Email: myamanis@bb.softbank.co.jp
Yuji Yamazaki Yuji Yamazaki
Softbank Mobile Softbank Mobile
Email: yuyamaza@bb.softbank.co.jp Email: yuyamaza@bb.softbank.co.jp
Hui Deng Hui Deng
China Mobile China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: denghui02@gmail.com Email: denghui02@gmail.com
9. Acknowledgments 9. Acknowledgments
Many thanks to the following individuals who provided valuable Many thanks to the following individuals who provided valuable
comments: comments:
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| X. Deng | W. Dec | D. Wing | A. Baudot | | X. Deng | W. Dec | D. Wing | A. Baudot |
| E. Burgey | L. Cittadini | R. Despres | J. Zorz | | E. Burgey | L. Cittadini | R. Despres | J. Zorz |
| M. Townsley | L. Meillarec | R. Maglione | J. Queiroz | | M. Townsley | L. Meillarec | R. Maglione | J. Queiroz |
skipping to change at page 14, line 14 skipping to change at page 14, line 5
10. Informative References 10. Informative References
[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.boucadair-intarea-nat-reveal-analysis] [I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-05 (work in
progress), November 2011.
[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 in Shared Address Deployments", Identifier in Shared Address Deployments",
draft-boucadair-intarea-nat-reveal-analysis-04 (work in draft-ietf-intarea-nat-reveal-analysis-00 (work in
progress), September 2011. progress), February 2012.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NAT
(CGN)", draft-ietf-behave-lsn-requirements-03 (work in
progress), August 2011.
[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
skipping to change at page 15, line 29 skipping to change at page 15, line 21
Gateway Device (IGD) V 2.0", December 2010, Gateway Device (IGD) V 2.0", December 2010,
<http://upnp.org/specs/gw/igd2/>. <http://upnp.org/specs/gw/igd2/>.
Authors' Addresses Authors' Addresses
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
France Telecom France Telecom
Rennes, 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange-ftgroup.com Email: mohamed.boucadair@orange.com
Satoru Matsushima Satoru Matsushima
Softbank Telecom Softbank Telecom
Tokyo Tokyo
Japan Japan
Email: satoru.matsushima@tm.softbank.co.jp Email: satoru.matsushima@tm.softbank.co.jp
Yiu Lee Yiu Lee
Comcast Comcast
 End of changes. 46 change blocks. 
117 lines changed or deleted 90 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/