One document matched: draft-ietf-softwire-stateless-4v6-motivation-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-softwire-stateless-4v6-motivation-05"
ipr="trust200902">
<front>
<title abbrev="Solution Motivations">Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization>Softbank Telecom</organization>
<address>
<postal>
<street></street>
<city>Tokyo</city>
<country>Japan</country>
</postal>
<email>satoru.matsushima@tm.softbank.co.jp</email>
</address>
</author>
<author fullname="Yiu Lee" initials="Y." surname="Lee">
<organization>Comcast</organization>
<address>
<postal>
<street></street>
<country>US</country>
</postal>
<email>Yiu_Lee@Cable.Comcast.com</email>
</address>
</author>
<author fullname="Olaf Bonness" initials="O." surname="Bonness">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street></street>
<country>Germany</country>
</postal>
<email>Olaf.Bonness@telekom.de</email>
</address>
</author>
<author fullname="Isabel Borges" initials="I." surname="Borges">
<organization>Portugal Telecom</organization>
<address>
<postal>
<street></street>
<country>Portugal</country>
</postal>
<email>Isabel@ptinovacao.pt</email>
</address>
</author>
<author fullname="Gang Chen" initials="G." surname="Chen">
<organization>China Mobile</organization>
<address>
<postal>
<street>53A,Xibianmennei Ave.</street>
<city>Beijing</city>
<region>Xuanwu District</region>
<code>100053</code>
<country>China</country>
</postal>
<email>chengang@chinamobile.com</email>
</address>
</author>
<date day="13" month="November" year="2012" />
<workgroup>Softwires Working Group</workgroup>
<abstract>
<t>IPv4 service continuity is one of the most pressing problems that
must be resolved by Service Providers during the IPv6 transition period
– especially after the exhaustion of the public IPv4 address
space. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates on
the motivations for the need to undertake a companion effort to specify
stateless IPv4 over IPv6 approaches.</t>
<!---->
<t></t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When the global IPv4 address space is exhausted, Service Providers
will be left with an address pool that cannot be increased anymore. Many
services and network scenarios will be impacted by the lack of IPv4
public addresses. Providing access to the (still limited) IPv6 Internet
only won't be sufficient to address the needs of customers, as most of
them will continue to access legacy IPv4-only services. Service
Providers must guarantee their customers that they can still access IPv4
contents although they will not be provisioned with a global IPv4
address anymore. Means to share IPv4 public addresses are unavoidable
<xref target="RFC6269"></xref>.</t>
<t>Identifying the most appropriate solution(s) to the IPv4 address
exhaustion as well as IPv4 service continuity problems and deploying
them in a real network with real customers is a very challenging and
complex process for all Service Providers. There is no one size fits all
solution. Each Service Provider has to take into account its own context
(e.g., service infrastructures), policies and marketing strategy (a
document that informs Service Providers about the impact of the IPv4
address shortage, and provides some recommendations and guidelines, is
available at <xref target="EURESCOM"></xref>).</t>
<t>Current standardization efforts to address the IPv4 service
continuity issue focuses on stateful mechanisms that share global IPv4
addresses between customers with NAT (Network Address Translation)
capabilities in the network. Because of some caveats of such stateful
approaches, the Service Provider community feels that a companion effort
is required to specify stateless IPv4 over IPv6 approaches. In the
context of address sharing, states should be maintained in other
equipments, e.g. customer premises equipment or host.</t>
<t>This document focuses on carrier-side stateless IPv4 over IPv6.</t>
<t>More discussions about stateless vs. stateful can be found at <xref
target="RFC6144"></xref>.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:</t>
<t><list hangIndent="5" style="hanging">
<t hangText="State:"><xref target="RFC1958">as used in </xref>.</t>
<t hangText="Session state:">refers to an information state as
defined in Section 2.3 of <xref target="RFC2663"></xref>. In
particular, it refers to the state maintained by the NAT so that
datagrams pertaining to a session are routed to the right node.
Note, TCP/UDP sessions are uniquely identified by the tuple of
(source IP address, source TCP/UDP port, target IP address, target
TCP/UDP port) while ICMP query sessions are identified by the tuple
of (source IP address, ICMP query ID, target IP address).</t>
<t hangText="User-session state:">refers to session state belonging
to a given user.</t>
<t hangText="Stateful 4/6 solution">(or stateful solution in short):
denotes a solution where a NAT in the Service Provider's network
maintains user-session states <xref
target="I-D.ietf-behave-lsn-requirements"></xref>. The NAT function
is responsible for sharing the same IPv4 address among several
subscribers and for maintaining user-session state. </t>
<t hangText="Stateless 4/6 solution">(or stateless solution in
short): denotes a solution which does not require any per-user state
(see Section 2.3 of <xref target="RFC1958"></xref>) to be maintained
by any IP address sharing function in the Service Provider's
network. A dependency between an IPv6 prefix and IPv4 address is
assumed. In an IPv4 address sharing context, dedicated functions are
enabled in the CPE router to restrict the source IPv4 port numbers.
Within this document, "port set" and "port range" terms are used
interchangeably. </t>
</list></t>
</section>
<section anchor="motivations"
title="Why Stateless IPv4 over IPv6 Solutions are Needed?">
<t><!----></t>
<t><?rfc subcompact="no"?></t>
<t>The following sub-sections discuss different aspects that motivate
this effort.</t>
<section anchor="simplification"
title="Network Architecture Simplification">
<t>The activation of the stateless function in the Service Provider's
network does not introduce any major constraint on the network
architecture and its engineering. The following sub-sections elaborate
on these aspects.</t>
<section anchor="network_dim" title="Network Dimensioning">
<t>Because no per-user state <xref target="RFC1958"></xref> is
required, a stateless solution does not need to take into account
the maximum number of simultaneous user-sessions and the maximum
number of new user-sessions per second to dimension its networking
equipment. Like current network dimensioning practices, only
considerations related to the customers number, traffic trends and
the bandwidth usage need be taken into account.</t>
</section>
<section anchor="no_intra" title="No Intra-domain Constraint">
<t>Stateless IPv4/IPv6 interconnection functions can be ideally
located at the boundaries of an Autonomous System (e.g., Autonomous
System Border Routers (ASBRs) that peer with 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 for instance; intra-domain
routing processes are not tweaked to direct the traffic to dedicated
nodes. Stateless solutions optimize CPE-to-CPE communication in that
packets don't go through the interconnection function.</t>
</section>
<section anchor="log"
title="Logging - No Need for Dynamic Binding Notifications">
<t>Network abuse reporting requires traceability <xref
target="RFC6269"></xref>. To provide such traceability, prior to
IPv4 address sharing, logging the IPv4 address assigned to a user
was sufficient and generates relatively small logs. The advent of
stateful IPv4 address allows dynamic port assignment, which then
requires port assignment logging. This logging of port assignments
can be considerable.</t>
<t>In contrast, static port assignments do not require such
considerable logging. The volume of the logging file may not be seen
as an important criterion for privileging a stateless approach
because stateful approaches can also be configured (or designed) to
assign port ranges and therefore lead to acceptable log volumes.</t>
<t>If a dynamic port assignment mode is used, dedicated interfaces
and protocols must be supported to forward binding data records
towards dedicated platforms. The activation of these dynamic
notifications may impact the performance of the dedicated device.
For stateless solutions, there is no need for dynamic procedures
(e.g., using SYSLOG) to notify a mediation platform about assigned
bindings.</t>
<t>Some Service Providers have a requirement to use only existing
logging systems and to avoid introducing new ones (mainly because of
Capital Expenditure (CAPEX) considerations). This requirement is
easily met with stateless solutions.</t>
</section>
<section anchor="proto"
title="No Additional Protocol for Port Control is Required">
<t>Stateless solutions do not require activating a new dynamic
signaling protocol in the end-user CPE in addition to those already
used. In particular, existing protocols (e.g., UPnP IGD:2 <xref
target="UPnP-IGD"></xref>) can be used to control the NAT mappings
in the CPE.<list style="empty">
<t>Note: To overcome some security concerns, IGD:2 authorization
framework <xref target="UPnP-IGD"></xref> should be used and
security considerations elaborated in <xref
target="Sec_DCP"></xref> should be taken into account.</t>
</list></t>
</section>
</section>
<section title="Operational Tasks and Network Maintenance Efficiency">
<t></t>
<section anchor="current" title="Preserve Current Practices">
<t>If stateless solutions are deployed, common practices are
preserved. In particular, the maintenance and operation of the
network do not require any additional constraints such as: path
optimization practices, enforcing traffic engineering policies,
issues related to traffic oscillation between stateful devices,
load-balancing the traffic or load sharing the traffic among
egress/ingress points can be used, etc. Particularly, <list
style="symbols">
<t>anycast-based schemes can be used for load-balancing and
redundancy purposes between nodes embedding the Stateless
IPv4/IPv6 interconnection function.</t>
<t>asymmetric routing to/from the IPv4 Internet is natively
supported and no path-pinning mechanisms have to be additionally
implemented.</t>
</list></t>
</section>
<section anchor="planned" title="Planned Maintenance Operations">
<t>Since no state is maintained by stateless IPv4/IPv6
interconnection nodes, no additional constraint needs to be taken
into account when upgrading these nodes (e.g., adding a new service
card, upgrading hardware, periodic reboot of the devices, etc.). In
particular, current practices that are enforced to (gracefully)
reboot or to shutdown routers can be maintained.</t>
</section>
<section anchor="reliability" title="Reliability and Robustness">
<t>Compared to current practices (i.e., without a Carrier Grade NAT
(CGN) in place), no additional capabilities are required to ensure
reliability and robustness in the context of stateless solutions.
Since no state is maintained in the Service Provider's network,
state synchronization procedures are not required.</t>
<t>High availability (including failure recovery) is ensured owing
to best current practices in the field.</t>
</section>
<section anchor="multi" title="Support of Multi-Vendor Redundancy">
<t>Deploying stateful techniques, especially when used in the
Service Providers networks, constrains severely deploying
multi-vendor redundancy since very often proprietary vendor-specific
protocols are used to synchronize state. This is not an issue for
the stateless case. Concretely, the activation of the stateless
IPv4/IPv6 interconnection function does not prevent nor complicate
deploying devices from different vendors.</t>
<t>This criterion is very important for Service Providers because
they want to avoid being locked into one vendor for their entire
network and they want to operate multi-vendor-supplied networks.</t>
</section>
<section anchor="qualification"
title="Simplification of Qualification Procedures">
<t>The introduction of new functions and nodes into operational
networks follows strict procedures elaborated by Service Providers.
These procedures include in-lab testing and field trials. Because of
their nature, stateless implementations optimize testing time and
procedures:</t>
<t><list style="symbols">
<t>The specification of test suites to be conducted should be
shorter;</t>
<t>The required testing resources (in terms of manpower) are
likely to be less solicited that they are for stateful
approaches.</t>
</list>One of the privileged approaches to integrate stateless
IPv4/IPv6 interconnection function consists in embedding stateless
capabilities in existing operational nodes (e.g., IP router). In
this case, any software or hardware update would require to execute
non-regression testing activities. In the context of the stateless
solutions, the non-regression testing load due to an update of the
stateless code is expected to be minimal.</t>
<t>For the stateless case, testing effort and non-regression testing
are to be taken into account for the CPE side. This effort is likely
to be lightweight compared to the testing effort, including the
non-regression testing, of a stateful function which is co-located
with other routing functions for instance.</t>
</section>
</section>
<section title="Facilitating Service Evolution">
<t></t>
<section anchor="identification" title="Implicit Host Identification">
<t>Service Providers do not offer only IP connectivity services but
also added value services (a.k.a., internal services). Upgrading
these services to be IPv6-enabled is not sufficient because of
legacy devices. In some deployments, the delivery of these
added-value services relies on implicit identification mechanism
based on the source IPv4 address. Due to address sharing, implicit
identification will fail <xref target="RFC6269"></xref>; replacing
implicit identification with explicit authentication will be seen as
a non acceptable service regression by the end users (less Quality
of Experience (QoE); refer to <xref target="RFC6462">Section 4.2
</xref>).</t>
<t>When a stateless solution is deployed, implicit identification
for internal services is likely to be easier to implement: the
implicit identification should be updated to take into account the
port range and the IPv4 address. Techniques as those analyzed in
<xref target="I-D.ietf-intarea-nat-reveal-analysis"></xref> are not
required for the delivery of these internal services if a stateless
solution is deployed.</t>
<t>Note stateful approaches configured to assign port ranges allow
also to support implicit host identification.</t>
</section>
<section anchor="organisation" title="No Organizational Impact">
<t>Stateless solutions adopt a clear separation between the
IP/transport layers and the service layers; no service interference
is to be observed when a stateless solution is deployed. This clear
separation:</t>
<t><list style="hanging">
<t hangText="Facilitates service evolution:">Stateless solutions
admit applications which can be deployed without enabling any
application-specific function (e.g., Application Level Gateway
(ALG)) in the Service Provider's network. Avoiding ALGs is
highly desirable.</t>
<t hangText="Limits vendor dependency:">The upgrade of
value-added services does not involve any particular action from
vendors that provide devices embedding the stateless IPv4/IPv6
interconnection function.</t>
<t
hangText="No service-related skills are required for network operators who manage devices that embed the IPv4/IPv6 interconnection function:">IP
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
embedding the stateless IPv4/IPv6 interconnection function. The
introduction of stateless capabilities in the network are
unlikely to degrade management costs.</t>
</list></t>
</section>
</section>
<section title="Cost Minimization Opportunities">
<t>To make decision for which solution is to be adopted, Service
Providers usually undertake comparative studies about viable technical
solutions. It is not only about technical aspects but also economical
optimization (both CAPEX and Operational Expenditure (OPEX)
considerations). From a Service Provider perspective, stateless
solutions may be more attractive because it impacts the current
network operations and maintenance model less than stateful solutions.
<xref target="cost"></xref> shows the general correspondence between
technical benefits and potential economic reduction opportunities.</t>
<t>While not all Service Providers environments are the same, a
detailed case study from one Service Provider <xref
target="I-D.matsushima-v6ops-transition-experience"></xref> reports
that stateless transition solutions can be considerably less expensive
than stateful transition solutions.</t>
<t><?rfc subcompact="yes" ?></t>
<texttable anchor="cost" style="all"
title="Cost minimization considerations">
<ttcol align="center">Section</ttcol>
<ttcol align="center">Technical and Operation Benefit</ttcol>
<ttcol align="center">Cost Area</ttcol>
<c><xref target="network_dim"></xref></c>
<c>Network dimensioning</c>
<c>Network</c>
<c><xref target="no_intra"></xref></c>
<c>No Intra-domain constraint</c>
<c>Network</c>
<c><xref target="log"></xref></c>
<c>Logging</c>
<c>Network & Ops</c>
<c><xref target="proto"></xref></c>
<c>No additional control protocol</c>
<c>Network</c>
<c><xref target="current"></xref></c>
<c>Preserve current practices</c>
<c>Ops</c>
<c><xref target="planned"></xref></c>
<c>Planned maintenance</c>
<c>Ops</c>
<c><xref target="reliability"></xref></c>
<c>Reliability and robustness</c>
<c>Network & Ops</c>
<c><xref target="multi"></xref></c>
<c>Multi-Vendor Redundancy</c>
<c>Network</c>
<c><xref target="qualification"></xref></c>
<c>Simple qualification</c>
<c>Ops</c>
<c><xref target="identification"></xref></c>
<c>Implicit Host Identification for internal services</c>
<c>Ops</c>
<c><xref target="organisation"></xref></c>
<c>Organizational Impact</c>
<c>Ops</c>
</texttable>
<t><?rfc subcompact="no" ?></t>
</section>
</section>
<section title="Discussion">
<t>Issues common to all address sharing solutions are documented in
<xref target="RFC6269"></xref>. The following sub-sections enumerate
some open questions for a CPE-based stateless solution. There are no
universal answers to these open questions since each Service Provider
has its own constraints (e.g., available address pool, address sharing
ratio, etc.).</t>
<section anchor="dependency"
title="Dependency Between IPv4 and IPv6 Address Assignments">
<t>Complete stateless mapping implies that the IPv4 address and the
significant bits that are used to encode the set of assigned ports can
be retrieved from the IPv6 prefix assigned to the CPE. This
requirement can be addressed by either using the IPv6 prefix also used
to forward IPv6 traffic natively, or allocating two prefixes to the
CPE (one that will be used to forward IPv6 traffic natively, and the
other one to forward IPv4 traffic).</t>
<t><list style="symbols">
<t>Providing two IPv6 prefixes avoids the complexity that may be
related to the adaptation of the IPv6 addressing scheme to the
IPv4 addressing scheme. The drawback is the need to allocate two
prefixes instead of one to each CPE and to announce them
accordingly, possibly at the cost of jeopardizing the routing and
forwarding efficiencies.</t>
<t>The use of a single prefix to cover both the forwarding of IPv6
and IPv4-in-IPv6 traffic avoids the need to maintain a double
information (e.g., for customer identification and management
purposes and for forwarding table maintenance purposes). This
scheme somewhat links strongly the IPv4 addressing scheme to the
allocated IPv6 prefixes. For Service Providers requiring to apply
specific policies on per Address-Family (e.g., IPv4, IPv6), some
provisioning tools (e.g., DHCPv6 option) may be required to derive
in a deterministic way the IPv6 address to be used for the IPv4
traffic based on the IPv6 prefix delegated to the home
network.</t>
</list></t>
</section>
<section anchor="efficiency" title="IPv4 Port Utilisation Efficiency">
<t>CGN-based solutions, because they can dynamically assign ports,
provide better IPv4 address sharing ratio than stateless solutions
(i.e., can share the same IP address among a larger number of
customers). For Service Providers who desire an aggressive IPv4
address sharing, a CGN-based solution is more suitable than the
stateless. However<list style="format %d:">
<t>When port overloading is used, some applications are likely to
be broken.</t>
<t>in case a CGN pre-allocates port ranges, e.g.- to alleviate
traceability complexity (see <xref target="log"></xref>), it also
reduces its port utilization efficiency.</t>
</list></t>
</section>
<section anchor="randomization" title="IPv4 Port Randomization">
<t>Preserving port randomization <xref target="RFC6056"></xref> may be
more or less difficult depending on the address sharing ratio (i.e.,
the size of the port space assigned to a CPE). The CPE can only
randomize the ports inside a fixed port range.</t>
<t>More discussion to improve the robustness of TCP against Blind
In-Window Attacks can be found at <xref target="RFC5961"></xref>.
Other means than the (IPv4) source port randomization to provide
protection against attacks should be used (e.g., use <xref
target="I-D.vixie-dnsext-dns0x20"></xref> to protect against DNS
attacks, <xref target="RFC5961"></xref> to improve the robustness of
TCP against Blind In-Window Attacks, use IPv6).</t>
</section>
</section>
<section title="Conclusion">
<t>As discussed in <xref target="motivations"></xref>, stateless
solutions provide several interesting features. Trade-off between the
positive vs. negative aspects of stateless solutions is left to Service
Providers. Each Service Provider will have to select the appropriate
solution (stateless, stateful or even both) meeting its
requirements.</t>
<t>This document recommends to undertake as soon as possible the
appropriate standardization effort to specify a stateless IPv4 over IPv6
solution.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No action is required from IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Except for the less efficient port randomization of and routing loops
<xref target="RFC6324"></xref>, stateless 4/6 solutions are expected to
introduce no more security vulnerabilities than stateful ones. Because
of their stateless nature, they may in addition reduce denial of service
opportunities.</t>
</section>
<section title="Contributors">
<t>The following individuals have contributed to this document:</t>
<figure>
<artwork type="text/plain"><![CDATA[
Christian Jacquenet
France Telecom
Email: christian.jacquenet@orange.com
Pierre Levis
France Telecom
Email: pierre.levis@orange.com
Masato Yamanishi
SoftBank BB
Email: myamanis@bb.softbank.co.jp
Yuji Yamazaki
Softbank Mobile
Email: yuyamaza@bb.softbank.co.jp
Hui Deng
China Mobile
Email: denghui02@gmail.com
]]></artwork>
</figure>
<t></t>
</section>
<section title="Acknowledgments">
<t>Many thanks to the following individuals who provided valuable
comments:</t>
<figure align="center">
<artwork><![CDATA[+---------------+---------------+---------------+---------------+
| X. Deng | W. Dec | D. Wing | A. Baudot |
| E. Burgey | L. Cittadini | R. Despres | J. Zorz |
| M. Townsley | L. Meillarec | R. Maglione | J. Queiroz |
| C. Xie | X. Li | O. Troan | J. Qin |
| B. Sarikaya | N. Skoberne | J. Arkko | D. Lui |
+---------------+---------------+---------------+---------------+
]]></artwork>
</figure>
<t></t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.6144'?>
<?rfc include='reference.RFC.1958'?>
<?rfc include='reference.RFC.2663'?>
<?rfc include='reference.RFC.6056'?>
<reference anchor="EURESCOM"
target="http://archive.eurescom.eu/~pub/deliverables/documents/P1900-series/P1952/D2bis/P1952-D2bis.pdf">
<front>
<title>IPv4 address exhaustion: Issues and Solutions for Service
Providers</title>
<author fullname="Levis, P., Borges, I., Bonness, O. and L. Dillon L."
surname="Levis, P., Borges, I., Bonness, O. and L. Dillon L.">
<organization></organization>
</author>
<date month="March" year="2010" />
</front>
</reference>
<reference anchor="UPnP-IGD" target="http://upnp.org/specs/gw/igd2/">
<front>
<title>Universal Plug and Play (UPnP) Internet Gateway Device (IGD)
V 2.0</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date month="December" year="2010" />
</front>
</reference>
<reference anchor="Sec_DCP" target="">
<front>
<title>Device Protection:1</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization>UPnP Forum</organization>
</author>
<date day="17" month="November" year="2009" />
</front>
</reference>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?rfc include='reference.I-D.vixie-dnsext-dns0x20'?>
<?rfc include='reference.RFC.5961'?>
<?rfc include='reference.RFC.6462'?>
<?rfc include='reference.RFC.6324'?>
<?rfc include='reference.I-D.matsushima-v6ops-transition-experience'?>
<?rfc include='reference.I-D.ietf-intarea-nat-reveal-analysis'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:23 |