Network Working Group W. Dec Internet-Draft R. Asati Intended status: Informational Cisco Expires: April 16, 2012 C. Congxiao CERNET Center/Tsinghua University H. Deng China Mobile M. Boucadair France Telecom October 14, 2011 Stateless 4Via6 Address Sharing draft-dec-stateless-4v6-04 Abstract This document presents an overview of the characteristics of stateless 4V6 solutions, alongside a assessment of the issues attributes. The impact of translated or mapped tunnel transport modes is also presented in the broader context of other industry standard reference architectures and existing deployments. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2012. Copyright Notice Dec, et al. Expires April 16, 2012 [Page 1] Internet-Draft stateless 4V6 October 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Stateless 4V6 Technical and Architectual Overview . . . . . . 5 3.1. IPv4 address and algorithmic port indexing . . . . . . . . 7 3.2. 4V6 CE IPv6 Address and domain info . . . . . . . . . . . 7 3.3. IPv6 Adaptation Function . . . . . . . . . . . . . . . . . 8 3.3.1. 4V6 Stateless Tunneling Mode . . . . . . . . . . . . . 8 3.3.2. 4V6 Stateless Translation mode . . . . . . . . . . . . 9 4. Comparison of 4V6 transport modes . . . . . . . . . . . . . . 9 4.1. General Characteristics of 4V6 modes . . . . . . . . . . . 9 4.2. Mobile SP Architecture and 4V6 Applicability . . . . . . . 12 4.2.1. 3GPP overview . . . . . . . . . . . . . . . . . . . . 13 4.2.2. 3GPP and 4V6 modes . . . . . . . . . . . . . . . . . . 15 4.3. Cable SP Architectures & 4V6 Applicability . . . . . . . . 18 4.3.1. PacketCable Introduction . . . . . . . . . . . . . . . 18 4.3.2. PacketCable Construct - Classifier . . . . . . . . . . 20 4.3.3. 4V6 Modes Impact on PacketCable . . . . . . . . . . . 20 5. Overview of potential issues and discussion . . . . . . . . . 21 5.1. Notion of Unicast Address . . . . . . . . . . . . . . . . 21 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Implementation on hosts . . . . . . . . . . . . . . . . . 22 5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 5.3. 4V6 address and impact on other IPv6 hosts . . . . . . . . 23 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 5.4. Impact on 4V6 CE based applications . . . . . . . . . . . 24 5.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24 5.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 5.5. 4V6 interface . . . . . . . . . . . . . . . . . . . . . . 24 5.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24 Dec, et al. Expires April 16, 2012 [Page 2] Internet-Draft stateless 4V6 October 2011 5.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 5.6. Non TCP/UDP port based IP protocols - ICMP) . . . . . . . 25 5.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 5.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Provisioning and Operational Systems . . . . . . . . . . . 25 5.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 5.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25 5.8. Training & Education . . . . . . . . . . . . . . . . . . . 27 5.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 27 5.8.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 27 5.9. Security and Port Randomization . . . . . . . . . . . . . 28 5.9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28 5.9.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28 5.10. Unknown Failure Modes . . . . . . . . . . . . . . . . . . 28 5.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28 5.10.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28 5.11. Possible Impact on NAT66 use & design . . . . . . . . . . 29 5.11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29 5.11.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29 5.12. Port statistical multiplexing and monetization of port space . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29 5.12.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29 5.13. Readdressing . . . . . . . . . . . . . . . . . . . . . . . 30 5.13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 30 5.13.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 30 5.14. Ambiguity about communication between devices sharing an IP address. . . . . . . . . . . . . . . . . . . . . . . 31 5.14.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 31 5.14.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 31 5.15. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.15.1. Abuse Claims . . . . . . . . . . . . . . . . . . . . . 32 5.15.2. Fragmentation and Traffic Asymmetry . . . . . . . . . 32 5.15.3. Multicast Services . . . . . . . . . . . . . . . . . . 33 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Dec, et al. Expires April 16, 2012 [Page 3] Internet-Draft stateless 4V6 October 2011 1. Introduction As network service providers move towards deploying IPv6 and IPv4 dual stack networks, and further on towards IPv6 only networks, a problem arises in terms of supporting residual IPv4 services, over an infrastructure geared for IPv6-only operations, and doing so in the context of IPv4 address depletion. This class of problem is referred to by the draft as the 4via6 problem, for which a stateless solution is desired driven by motivation as documented in [I-D.operators-softwire-stateless-4v6-motivation]. Solutions such as a 4rd [I-D.despres-softwire-4rd], [I-D.murakami-softwire-4v6-translation], and [I-D.xli-behave-divi-pd], as well as dIVI [I-D.xli-behave-divi] offer such stateless solutions, by using fully distributed NAPT44 functionality located on end user CPEs, which allows the network operators' core to remain effectively stateless in terms of NAT44. The solutions, collectively called Stateless4V6, rely on the same IPv4 address being used by multiple CPEs, each with a different TCP/ UDP port range, and are derived from the Address+Port (A+P) solution space [I-D.ymbk-aplusp]. Differences between the solutions come down to the mode of transport (translation or mapped tunneling), and the mapping algorithm used. This document looks at the issues that have been claimed as applying to A+P technology, in the specific context of the referenced solutions, and also analyzes the two modes of transport. 2. Terminology Stateless4V6 domain: A domain is composed out of an arbitrary number of 4V6 CE and Gateway nodes that share a mapping relationship between an operator assigned IPv6 prefix and one or more IPv4 subnets along with all the applicable TCP/UDP ports, all mapped into the IPv6 address space. An 4V6 system can have multiple domains. Stateless4V6 CE: A CPE node that implements 4V6 functionality including NAPT44 which is provisioned by means of 4V6. The device interfaces to the SP network using native IPv6 and a IPv4-IPv6 adaptation service. Stateless4V6 Gateway A Service Provider node that implements the stateless 46 adaptation functionality for interfacing between the SP's IPv6 domain and an IPv4 domain in delivering end user IPv4 connectivity beyond the domain. Dec, et al. Expires April 16, 2012 [Page 4] Internet-Draft stateless 4V6 October 2011 IPv4 Address sharing The notion of attributing the same IPv4 address by multiple CEs in an 4V6 domain. Port-set: A set composed of unique TCP/UDP ports (ranges) associated to a IPv4 address. A single 4V6 CE is expected to have a single port-set for each IPv4 address. Port-set-id: A numeric identifier of a given port set that is unique in a given 4V6 domain. A port-set-id is used to algorithmically determine the port-set members. The port-set-id is conveyed to CEs as part the CE's IPv6 addressing information, ie it is part of IPv6 subnet or address of a given CE, and its format places no restriction on the use of SLAAC or DHCP addressing. CE-index: A numeric value, composed of a full or partial IPv4 address and optionally a port-set-id, which uniquely identifies a given CE in an 4V6 domain. 3. Stateless 4V6 Technical and Architectual Overview This section presents the architectural and technical overview of a stateless 46 solution, and evidenced in whole or in part by various stateless 4via6 solution proposals such as 4rd, dIVI. Figure 1 depicts the overall architecture with two IPv4 user networks connected via 4via6 CPEs that share an IPv4 address. The goal of the system is to allow IPv4 user connectivity to the Public IPv4 network, across an operator's IPv6 network. A key characteristic of the system, and a major differentiator with respect to previous solutions, is that translation state is only (ever) present on the CE, with the rest of the system performing stateless transport. This stateless transport applies to both the mapped-tunnel and translated modes, as described in the dedicated sections. Dec, et al. Expires April 16, 2012 [Page 5] Internet-Draft stateless 4V6 October 2011 User 1 Private IPv4 | Network | O--+---------------O | | 4V6 CE | | +-----+--------+ | | NAPT44| IPv6 | `-. | +-----+ Adptn | | -._ ,-------. ------. | +--------+ | ,-' `-. ,-' `-. O------------------O / Routed \ O---------O / Public \ / IPv6 \ |Stateless|/ IPv4 \ ( Network --+ 6V4 +- Network ) \ / | Gateway |\ / O------------------O \ / O---------O \ / | 4V6 CE | ;". ,-' `-. ,-' | +-----+--------+ | ," `-------' ------' | NAPT44| IPv6 | ," | +-----+ Adptn | | | | +--------+ | O---.--------------O | User 2 Private IPv4 Network Figure 1 - Generalized Stateless 4V6 system On IPv4 network user side, the routed IPv6 service provider network is demarcated with a 4V6 CE. The CPE externally has only a native IPv6 interface to the SP network, and a native IPv4 interface towards the end user network. The IPv4 Internet is demarcated from the operator IPv6 network with one or more operator managed stateless 6V4 gateways that contain an IPv6 adaptation function (not detailed in the diagram) matching the one in the CE. Note: The stateless 6v4 gateway can be integrated into any existing network element (eg a core router, or an IP Edge). Internally, the 4V6 CE is modelled as having a port restricted NAPT44 function coupled with a stateless IPv6 adaptation function that is able to ferry the end-user's IPv4 traffic across the IPv6 network, besides deriving 4V6 provisioning info from it. The NAPT44 function derives its IPv4 address, which may be shared with that of other users, and its unique Layer 4 (TCP/UDP) port range from the IPv6 address/prefix by means of an 4V6 algorithm and a port indexing schema. Any IPv4 ALG functionality that the CPE may support, remain unaffected. The CPE is expected to act as a DNS resolver proxy, using native DNS over IPv6 to the SP network. Dec, et al. Expires April 16, 2012 [Page 6] Internet-Draft stateless 4V6 October 2011 Two forms of the IPv6 adapatation function are: i) 4v6 stateless tunneling ii) 4v6 stateless translation, each described in further in this document. The service provider is assumed to be operating all the necessary provisioning and accounting infrastructure to support a regular IPv6 deployment. Similarly, the network operator is assumed to have the ability to assign an IPv6 prefix or IPv6 address to a CPE, and log such an address assignment. End user host's DO NOT implement any of the 4V6, or other address sharing technologies, nor are they addressed directly with a shared IPv4 address. End user IPv4 hosts connected to the CPE receive unique private addresses assigned by the CPE, and it is the CPE that is directly addressed by the shared IPv4 address. Although tangential to the discussion of stateless 4V6, it is useful to note that the CPE is expected to have a native IPv6 interface to the end user network, with any of the end user IPv6 hosts (single or dual stack) receiving IPv6 addresses from an IPv6 delegated prefix issued to the CPE. 3.1. IPv4 address and algorithmic port indexing At the heart of the 4V6 solution, irrespective of mode of transport, lies the algorithm described in the specific solution drafts that allows the mapping of a shared IPv4 address and a TCP/UDP given port- set to a single IPv6 prefix or address. Notably, the 4V6 system allows both the shared IPv4 address use, as well as full non-shared IPv4 address use, all subject to the 4V6 domain configuration. The S46 domain information required to compute the IPv4 address and correct port set is retrieved from the 4V6 prefix advertised to the CE, and pre-configured or statelessly acquired domain information. 3.2. 4V6 CE IPv6 Address and domain info As presented in Section 2, IPv6 address of an 4V6 CE is composed out of the SP advertised IPv6 4V6 prefix, containing the CE-index, and an algorithmically computed appendix to complete the 128-bit address. This IPv6 address is *in addition* to any other IPv6 interface address that the CE configures or is configured with, including a SLAAC address from the 4V6 prefix or any IPv6 address source. One characteristics of the resulting IPv6 prefix or address is that it is for all intents and purposes a regular IPv6 prefix address that can be assigned to any regular IPv6 host. The IPv6 4V6 interface is reserved for the 4V6 application and the Dec, et al. Expires April 16, 2012 [Page 7] Internet-Draft stateless 4V6 October 2011 4V6 IPv6 adaptation function will exclusively use this IPv6 address. This is because the 4V6 system supports stateless communication between the 4V6 CE and the 4V6 gateway only by means of packets sent to/from this address. 3.3. IPv6 Adaptation Function The IPv6 adaptation function plays a key role in the 4V6 system, in statelessly allowing the IPv4 user payload to be transported across an IPv6 (only) network. Two modes of such a function are currently proposed and presented in the following subsections 3.3.1. 4V6 Stateless Tunneling Mode This type of IPv6 adaptation function is adopted and described in [I-D.despres-softwire-4rd]. The 4V6 gateway operates in the IPv4->IPv6 direction by mapping all or part of the IPv4 destination address and the port Index derived from the UDP/TCP payload into an IPv6 CE destination address. The resulting packet is sent using IPv4inIPv6 encapsulation to the CE, sourced from the 4V6's gateway IPv6 address, where the original IPv4 packet is extracted and passed to the stateful NAPT44 function. The 4V6 CE operates in the IPv4->IPv6 direction, for traffic bound to the IPv4 internet, by encapsulating the IPv4 packet in an IPv6 header using IPv4inIPv6 encapsulation, and sending the resulting packet to the (well known) unicast address of the 4V6 gateway. There the IPv4 packet is extracted and forwarded. The the original IPv4 packet addressing information is only partially visible on the IPv6 data plane, and the original Layer 4 information is only visible as part of the encapsulated IPv4 payload packet. The figure below illustrates the CE model of a 4v6 Mapped Tunnel mode. +......................+ : : : stateful stateless : [IPv4-LAN]-----:-[NAPT44]---[v4-v6]---:---- : [ tunn] : : : : : +......................+ Figure 2 - 4v6 CE model with Tunnel mode Dec, et al. Expires April 16, 2012 [Page 8] Internet-Draft stateless 4V6 October 2011 3.3.2. 4V6 Stateless Translation mode This type of IPv6 adaptation function is adopted and described in [I-D.murakami-softwire-4v6-translation], I-D.xli-behave-divi-pd, and[I-D.xli-behave-divi] The 4V6 translation mode transport operates by means of stateless NAT46 [RFC6145] extended to map the the TCP/UDP port index algorithmically derived from received IPv4 packets into an IPv6 address suffix, in the IPv6 header, besides the full IPv4 mapped representation of the original IPv4 address information. The resulting packet is then sent across the IPv6 domain as an IPv6 packet - this IPv6 packet, besides mapping the original original IPv4 address information into a determinate IPv6 format, also places the Layer 4 and packet content directly after the IPv6 header, as any regular IPv6 with TCP/UDP packet. This IPv6 packet is thus capable of being processed by regular IPv6 network elements or servers in the IPv6 domain. At either end of the IPv6 domain, the IPv4 packet header is statelessly recreated, by the 4v6 CE or gateway, again using exactly the same NAT64 process as in [RFC6145]. The figure below illustrates the IPv6 4v6 Stateless Translation model of a 4v6 CE. +......................+ : : : stateful stateless : [IPv4-LAN]-----:-[NAPT44]---[NAT46]---:---- : : : : : : +......................+ Figure 3 - 4v6 CE model with stateless NAT64 4. Comparison of 4V6 transport modes This section presents the an overview of the similarities and differences between an IPv4-IPv6 translation based 4V6 transport mode and one that utilizes IPv4-in-IPv6 tunnelling. The comparison takes into consideration a wider deployment view composed of functionality that is known to be in common use today. 4.1. General Characteristics of 4V6 modes The following table presents a comparison of the 4V6 transport modes, in terms of the base technology, and constrains, including also IPv4. Dec, et al. Expires April 16, 2012 [Page 9] Internet-Draft stateless 4V6 October 2011 +------------------------+--------------------+---------------------+ | Item | 4V6 Translation | 4V6 Tunnel Mode | | | mode | | +------------------------+--------------------+---------------------+ | Base Technology | Port restricted | Port restricted | | | NAPT44 with | NAPT44 with IPv4 in | | | modified stateless | IPv6 mapped | | | NAT64 on CPE and | tunneling on CPE | | | Gateway | and Gateway | | ------------------- | ------------------ | ------------------- | | Location of stateful | CPE | CPE | | NAPT44 function | | | | ------------------- | ------------------ | ------------------- | | IPv4 Forwarding | L3 + L4 lookup | L3 + L4 lookup | | paradigm | | | | ------------------- | ------------------ | ------------------- | | IPv6 Addressing | CE uses 4V6 | CE uses 4V6 suffix. | | Constraints | suffix. | | | ------------------- | ------------------ | ------------------- | | Type of IPv6 | ICMPv6 (SLAAC), | ICMPv6 (SLAAC), | | prefix/address | DHCPv6 (both IA_NA | DHCPv6 (both IA_NA | | announcement method | and IA_PD) | and IA_PD) | | supported | | | | ------------------ | ------------------ | ------------------ | | Can the 4V6 IPv6 | Yes | Yes | | prefix be used by non | | | | 4V6 devices? | | | | ------------------- | ------------------ | ------------------- | | IPv4 addressing | Fixed sharing | Fixed sharing ratio | | constraints | ratio per IPv4 | per IPv4 address. | | | address. | | | ------------------ | ------------------ | ------------------ | | TCP/UDP Port range | Ports are | Ports are | | constraint | statically | statically | | | allocated | allocated | | ------------------ | ------------------ | ------------------ | | Requires ALG64 or | No | No | | DNS64 | | | | ------------------ | ------------------ | ------------------ | | Requires IPv6 DNS on | Recommended | Recommended | | CPE | | | | ------------------ | ------------------ | ------------------ | | 4V6 CE Parameter | ICMPv6, Stateless | ICMPv6, Stateless | | provisioning methods | DHCPv6, TR69 | DHCPv6, TR69. | | (assuming suitable | | | | protocol extensions) | | | | ------------------ | ------------------ | ------------------ | Dec, et al. Expires April 16, 2012 [Page 10] Internet-Draft stateless 4V6 October 2011 | IPv6 Domain Routing to | Regular closest IP | Regular closest IP | | CE based on: | match to CE-IPv6 | match to CE-IPv6 | | | subnet | subnet | | ------------------ | ------------------ | ------------------ | | IPv6 Domain Routing to | IPv6 4V6 domain | 4V6 Gateway | | 4V6 Gateway based on | aggregate route | unicast/anycast | | | | address | | ------------------ | ------------------ | ------------------ | | IPv4 Header Checksum | Yes | No | | recalculation required | | | | ------------------ | ------------------ | ------------------ | | Supports non TCP/UDP | No* | No* | | Protocols | | | | ------------------ | ------------------ | ------------------ | | ICMPv4 Limitations | No ICMPv4 from | No ICMPv4 from | | | "outside the | "outside the | | | domain". Internal | domain". | | | ICMPv4-v6 | | | | translation as per | | | | [RFC6145] | | | ------------------ | ------------------ | ------------------ | | ICMPv5 identifier | Yes | Yes | | NAT/Markup needed | | | | ------------------ | ------------------ | ------------------ | | Supports IPv4 | No | No | | fragmentation (without | | | | additional state) | | | | ------------------ | ------------------ | ------------------ | | Requires IPv6 PMTU | Yes | Yes | | discovery/configuratio | | | | n | | | | ------------------ | ------------------ | ------------------ | | Supports IPv4 Header | No - as per NAT64 | Yes (use of source | | Options | [RFC6145] | route option is | | | | constrained) | | ------------------ | ------------------ | ------------------ | | TCP/UDP Checksum | Yes - depending on | No | | recalculation | suffix, as per | | | | NAT64 [RFC6145] | | | ------------------ | ------------------ | ------------------ | | Supports UDP null | Yes/Configurable - | Yes | | checksum | as per NAT64 | | | | [RFC6145] | | | ------------------ | ------------------ | ------------------ | | Transparency to DF bit | Yes, configurable | Yes | | | as per [RFC6145] | | | ------------------ | ------------------ | ------------------ | Dec, et al. Expires April 16, 2012 [Page 11] Internet-Draft stateless 4V6 October 2011 | Supports IPv4 | Partial (no | Partial (no | | Fragmentation | fragments from | fragments from | | | outside the | outside the domain) | | | domain) | | | ------------------ | ------------------ | ------------------ | | Transparency to IPv4 | Yes, configurable | Yes | | TOS | as per [RFC6145] | | | ------------------ | ------------------ | ------------------ | | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% | | to original average | | | | payload on IPv6 of a) | | | | ~550 bytes b) 1400 | | | | bytes). | | | | ------------------ | ------------------ | ------------------ | | Supports non-shared | Yes | Yes | | IPv4 usage (ie whole | | | | IPv4 address | | | | assignment to a single | | | | device) | | | | ------------------ | ------------------ | ------------------ | | Can support IPv4 to | Yes - As per | No | | IPv6 host | [RFC6145] | | | communication (for | stateless NAT64 | | | traffic not requiring | specification | | | ALGs) | | | | ------------------ | ------------------ | ------------------ | | Changes to network | Yes - Mapping IPv4 | Yes - Enabling | | element provisioning | to IPv6 addresses | IPv4inIPv6 | | tool(s)** | | functionality | +------------------------+--------------------+---------------------+ * Without specific ALGs. Non UDP/TCP protocols, like ICMP, can be supported with specific ALGs. **Network (feature) provisioning tools/applications need to be 4V6 aware. With the translation technique, the tool needs to enable the operator to map IPv4 addresses to IPv6 addresses as disctated by the 4V6 domain. With the tunneling technique, the tool needs to allow the operator to enable IPv4 (inIPv6) functionality and modify its characterstics. 4.2. Mobile SP Architecture and 4V6 Applicability This section presents the applicability and comparison of the 4V6 modes to current 3GPP architectures used by Mobile SP for delivering all sorts of mobile services. Dec, et al. Expires April 16, 2012 [Page 12] Internet-Draft stateless 4V6 October 2011 4.2.1. 3GPP overview The 3rd Generation Partnership Project (3GPP) is a collaboration between groups of telecommunications associations, whose scope is to develop a globally applicable mobile phone systems and architectures based on service requirements. 3GPP standards are structured as Releases, each of which incorporates numerous individual standard documents. Currently, 3GPP Release 7 is the latest release in common practical deployment, with Release 8 being readied for deployment. Releases 9 and 10 are finalized, and work is underway on Release 11. One of the major service requirement drivers of recent and ongoing 3GPP releases is the realization of services that deliver specific QoS, or user charging goals, all based on a policy system (eg tiered data rate or volume plans). Technically this translates to the Policy and Charging Control (PCC) framework, which in turn attributes specific functionality to nodes in the 3GPP architecture, such as the PDN-Gw and the PCRF. This functionality comprises both data-plane features (eg IP flow classification) as well as the interfaces/ protocols between nodes (eg Diameter, and its specific 3GPP applications). The 3GPP specifications allow both IPv4 and IPv6 traffic to be handled, and subject to operator defined handling and charging polices by means of applying suitable user traffic filters. Such filters are currently defined to be either IPv4 or IPv6, are applicable to user plane traffic, and are used in a variety of critical roles including the signalling of PDP contexts/EPC Bearers, as well as PCC signalling and interaction with applications. The following table illustrates the impact of the 4V6 translation and tunnel transport modes respectively on the 3GPP architecture including PCC interfaces. In assessing the impact of these 4V6 transport modes a number of additional assumptions are taken: o The 3GPP system supports native IPv6 user traffic, as say per either of the E-UTRAN Release 8 or 9 specifications, using the relevant EPS bearer or PDP functionality. o The 4V6 gateway functionality is not part of the 3GPP core architecture (given that currently it is not scoped by a 3GPP Release). Instead, the 4V6 gateway is taken to be a stand alone component in the 3GPP network operator's core reachable via the SGi interface. The above system, in the context of 3GPPs E-UTRAN architecture as defined in [E-UTRAN] is shown in Figure 2 Dec, et al. Expires April 16, 2012 [Page 13] Internet-Draft stateless 4V6 October 2011 +----------+ | | ,---. | AF | / \ | | / IPv4 \ +----+-----+ ( Internet) | \ / Rx | \ / ,---. | `-+-' / \ +----+-----+ | / \ | | +----+-----+ ; User : +-------+ | PCRF | | | | Home | | | | | | S64 | : Network ; | MME | +----+-----+ | Gateway | \ / | | Gx | +----+-----+ \ / +-+----++ | | `-+-' S1-MME / \ S11 +----+-----+ ,--+--. | ,-/ `. | | ,' `. +---+---+ ,' `.S1-u +--+----+ | | / IP \ | UE +---- -----+ +------+ PDN-Gw +---- Transport ) | w/ 4V6| |E-UTRAN| | S-Gw | | | \ / | CE | : ; | | S5 | | SGi `. ,' +-------+ `. ,' +-------+ | | '-----' LTE-Uu `-' +----------+ Figure 2 - 3GPP Architecture with 4V6 The main 3GPP system components, and terms are summarized as follows (the reader is referred to [E-UTRAN for a more detailed definition]: UE The User Equipment, typically a phone or a 3G/4G capable Home Router (shown to incorporate 4V6 functionality) E-UTRAN Evolved Universal Terrestrial Radio Access Network. The Radio Access network, composed on E-NodeB elements. MME Mobility Management Entity. Responsible for user authentication, PDN/SGw selection. Does not interact with the user data plane S-Gw Serving Gateway (function). Responsible for handling local mobility, (some) traffic accounting, traffic forwarding, bearer establishment. PDN-Gw Packet Data Network Gateway (function). Responsible for per user IP traffic handling, incl. address assignment, filtering, QoS, accounting. Dec, et al. Expires April 16, 2012 [Page 14] Internet-Draft stateless 4V6 October 2011 PCRF Policy And Charging Rules Function. Responsible for authorizing and applying policy rules, as well as binding them to user bearers. Bearer The bearer represents a virtual connection, typically that between a UE and a PDN-Gw. The bearer is specified as an IP Fliter (in terms of IP address, port numbers) and is the object of policy rules. 3GPP, depending on Release and document, defines many terms that are used to refer to the same notion: PDP context, EPS Bearer. AF Application Function. A functional element offering (higher level) applications that require dynamic policy and/or charging control over the user plane (bearer) behaviour. The AF can be seen as bridging the gap between applications and how they affect the IP data plane of a user. S5 It provides user plane tunnelling and tunnel management between SGW and PDN-GW, using GTP or PMIPv6 as the network based mobility management protocol. S1-u Provides user plane tunnelling and inter eNodeB path switching during handover between eNodeB and SGW, using the GTP-U protocol SGi It is the interface between the PDN-GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra operator packet data network. Gx Bearer and flow control interface between the user data-plane element (PDN-Gw) and the Policy System. A Diameter based interface with a suite of 3GPP applications 4.2.2. 3GPP and 4V6 modes 4V6 translated traffic appears for all intents and purposes as regular IPv6-user traffic to the 3GPP system and packet processing functions (eg the PDN-Gw). Hence, and based on the stated assumptions, any such 4V6 traffic can be handled using existing native IPv6 functionality defined by the core 3GPP specifications. In contrast, 4V6 tunneled traffic requires additional data plane processing to get to the "real" user IPv4 payload and apply the desired functions. Such additional processing is currently not part of the functionality covered by the 3GPP specifications. In view of this, and solely in relation to the 4V6 tunnel transport mode, two alternative hypotheses need to be placed in order to complete the comparison Dec, et al. Expires April 16, 2012 [Page 15] Internet-Draft stateless 4V6 October 2011 i) that such IPv4 in IPv6 processing functionality will be supported as part of the existing EPS bearer functionality defined in E-UTRAN, perhaps as a dedicated EPS bearer (ie an additional virtual interface per subscriber). Or, that; ii) a new 46 EPS bearer type (ie interface type) identification and signalling will be defined by the 3GPP architecture, which formalizes the v4inv6 relationship between the IPv4-user payload and the v6-user layers. An apparent benefit of approach (ii) would be in allowing the system to clearly distinguish and expose to other systems v4-user traffic versus v6-user traffic, which is composed of v4inv6 and regular v6 traffic that a UE may generate. The former approach (i) is more convoluted given the ambiguity in distinguishing, and representing such a combination of v6-user and v6-user-bearer and v4-user traffic, all while keeping coherence in terms of the policy system. These two options are designated with ** in the table below. +--------------------+----------------+-----------------------------+ | Item | 4V6 | 4V6 Mapped Tunnel Mode | | | Translation | | | | Mode | | +--------------------+----------------+-----------------------------+ | User Data Plane at | IPv6 over | IPv4 over IPv6 over GTP-U | | the PDN-Gw (as per | GTP-U over UDP | over UDP over IP | | section 5.1.2 in | over IP | | | [EUTRAN]) | | | | ------------------ | ----------- | ------------------ | | Gx (Diameter) | No discernible | Impacted: no way to express | | | impact | v4 over v6 in TFT Filter | | | | and Flow Descriptors | | ------------------ | ----------- | ------------------ | | Rx (Diameter) | No discernible | Impacted: no way to express | | | impact | v4 over v6 in | | | | Media-Component-Description | | | | and, Flow-Description-AVP | | ------------------ | ----------- | ------------------ | | S5 (GTP) | No impact | Impacted with new PDP/EPS | | | | Bearer type* | | ------------------ | ----------- | ------------------ | | New 46 Bearer | Not required | Possibly required** | | definition | | | | ------------------ | ----------- | ------------------ | Dec, et al. Expires April 16, 2012 [Page 16] Internet-Draft stateless 4V6 October 2011 | Secondary | Not required | Possibly required** | | interface | | | | (dedicated bearer | | | | or secondary PDP) | | | | for 46 traffic | | | | ------------------ | ----------- | ------------------ | | PDN-Gw | No impact | New TFT capability, IP Gate | | | | functionality, changes to | | | | Gx, and likely changes to | | | | S5/S7 related to signalling | | | | the new bearer | | ------------------ | ----------- | ------------------ | | SGw | No Impact | No discernible impact | | ------------------ | ----------- | ------------------ | | PCRF | No impact for | Impacted for both IPv6 and | | | IPv6. Feature | IPv4-only applications and | | | to map | Gx applications utilizing | | | IPv4-IPv6 | flow control/charging | | | addresses | | | | needed only in | | | | case of | | | | IPv4-only | | | | applications. | | | ------------------ | ----------- | ------------------ | | AF Application | No discernible | Flow based application | | Function | impact | control impacted | | ------------------ | ----------- | ------------------ | | UE | 4V6 | 4V6 application | | | application | | | ------------------ | ----------- | ------------------ | | LTE-Uu | No discernible | Likely changes required to | | | impact | support signalling of EPS | | | | bearer or PDP type | | ------------------ | ----------- | ------------------ | | Lawful Intercept | No discernible | New rules for tunnel | | | impact | support | +--------------------+----------------+-----------------------------+ *A new PDP Type or EPS bearer signalling has a broader 3GPP system wide impact not fully covered here. As the table illustrates, the 4V6 tunnel transport model appears to affect a significant number of 3GPP elements, when the intent if realize a full suite of services. This observation appears to apply to any other carrier inserted tunneling technology (eg DS-lite). Hence, a substantial investment in 3GPP standard terms and in the evolution of deployed systems appears to be required. Dec, et al. Expires April 16, 2012 [Page 17] Internet-Draft stateless 4V6 October 2011 In contrast the 4V6 translation mode bears none to no discernible impact on existing 3GPP Release 8/9 specifications and their deployments, while allowing the operator to realize the full set of services on 4V6, alongside any native IPv6 traffic, allowed for by these architecture. Hence, little beyond the addition of 4V6 components operating using translation mode appears to be required. 4.3. Cable SP Architectures & 4V6 Applicability Cable SPs (commonly referred to as Multi System Operators (MSOs)) usually deliver video, data, and voice service over the cable and fiber access to residential and commercial customers. Many MSOs offer SLAs with various services by exploiting QoS not only in their IP/MPLS network, but also their access network. The cable access network (now synonymous with Hybrid Fiber Coax (HFC)) is commonly enabled with Data Over Cable Service Interface Specifications (DOCSIS, a CableLabs standard) to facilitate the implementation of packet based services. In this paradigm, the HFC/ DOCSIS access bandwidth is typically shared among a number of customers, hence, ensuring optimal service quality & experience per customer becomes extremely important for MSOs' success. Cable SPs/MSOs ensure the optimal service quality of various advanced & real-time multimedia services (such as IP telephony, multimedia conferencing, interactive gaming etc.) by utilizing "PacketCable" framework to enforce QoS on the HFC/DOCSIS access. The next sub-section 4.3.1 provides a brief introduction to PacketCable, section 4.3.2 explains a key PacketCable construct - Classifier, and section 4.3.3 tabulates the impact of 4V6 modes to PacketCable enabled DOCSIS/IP services. 4.3.1. PacketCable Introduction PacketCable,a CableLabs standard, defines a framework for ensuring the Quality of Service (QoS) on the HFC/DOCSIS Access. PacketCable specifications (e.g. PacketCable 1.0, PacketCable Multi Media [PCMM], PacketCable Dynamic QoS [PC-DQOS], PacketCable 2.0) specify interoperable interface specifications for executing QoS, Admission Control, Accounting, Policy, and Security functions on Cable Modem (CM) and Cable Modem Termination System (CMTS), as/when needed. They all require DOCSIS 1.1 or later versions. The PacketCable framework is also critically important for MSOs to comply with government regulations for things such as E911 when they offer voice/telephony services, Lawful Intercept (LI) etc. Dec, et al. Expires April 16, 2012 [Page 18] Internet-Draft stateless 4V6 October 2011 The figure below illustrates one of PacketCable variants i.e. PCMM [PCMM] architecture, as an example, that defines a set of IP-based interfaces (referred to as pkt-mm-1 through 12) pertaining to core QoS and policy management capabilities. +------------+ +---------------+ | Application+-----------+ Application | | Server | pkt-mm-11 | Manager | +-------+----+ +-+--------+----+ ,------| | | pkt-mm-3 /,-------------------------+ | // +--+---+ +-------+ pkt-mm-12 // pkt-mm-7 | | |Record | // |Policy+----------+Keeping| // |Server| pkt-mm-4 |Server | // +--+---+ ++------+ // | | // | ,------------+ // pkt-mm-2| / pkt-mm-5 // || // || ,--+--. // +---++--+ +-------+ +--++--+ ,' `. +--------+ Clients } | CPE | | Cable | pkt-mm-1 | | / \ | 4V6 | In User }--+ Router+---+ Modem +----DOCSIS------+ CMTS +-----( IP )--+ Gateway| Network } | w/ 4V6| | | | | \ Network / |Boundary| +-------+ +-------+ +------+ `. ,' | Router | '-----' +--+-----+ \~~~~~~~~~~~~~~~~~~~~~/ | A typical Residential | Gateway includes both ,-+--. CPE & CM functions / \ / IPv4/6 \ ( Internet ) \ / \ / * PCMM spec marks these out-of-scope: `----' mm-7, mm-8, mm-9, mm-10, mm-12 * PCMM spec does not define/describe 4V6 Gateway/Boundary Router, or Internet Figure 3 - PacketCable Multimedia Architecture (with 4V6) Dec, et al. Expires April 16, 2012 [Page 19] Internet-Draft stateless 4V6 October 2011 4.3.2. PacketCable Construct - Classifier PacketCable framework fundamentally relies on Cable Modem (CM) and Cable Modem Termination System (CMTS) to first qualify and then classify the appropriate IP traffic between them, for effective QoS enforcement. The framework requires the usage of "Classifier" for both qualification (in control plane) and classification (in data plane). Taking PCMM specification [PCMM] again as an example, PCMM mandates the usage of classifier in the control plane (i.e. 'Upstream Packet Classification Encoding' in pkt-mm-1 interface (DOCSIS) , whereas 'Multimedia Classifier Object' in pkt-mm-2 and pkt-mm-3 interfaces (COPS)) for conveying the attributes of an IP flow belonging to an application (telephony, say), and subsequently its usage in the data plane i.e. filter matching on the IP packets' layer2/3/4 headers prior to QoS treatment. The PCMM specification mandates the 'classifier' to include Source and Destination IP addresses, DSCP/TOS, IP Protocol, Source and Destination ports for an IPv4 traffic flow received by the CMTS, and similarly, Source and Destination IP addresses, TC, Next Header, Source and Destination ports for an IPv6 traffic flow received by the CMTS. Similar to PCMM, PacketCable DQOS specification [PC-DQOS] also mandates the usage of classifier in the control plane (DSx messaging). In particular, PC-DQOS mandates the classifier definition to have 'protocol' (or next header) in IP header to be 17 (=UDP) along with specific Source and Destination ports (and Source and Destination IP addresses, optionally) so as to accommodate voice RTPoUDPoIP traffic. In summary, the CMTS (and CM) construct their data-plane filter based on the 'classifier' information. 4.3.3. 4V6 Modes Impact on PacketCable In 4V6 Tunnel mode, the 4V6 tunneled traffic requires additional data plane processing to get to the "real" user IPv4 payload and apply the desired functions. Such additional processing is currently not part of the functionality covered by the PacketCable specifications, nor part of compliant implementations. In 4V6 Translation Mode, the 4V6 translated traffic appears for all intents and purposes as regular IPv6-user traffic to the PacketCable framework (both control plane and data plane). Hence, it is likely that any such 4V6 traffic can be handled using native IPv6 Dec, et al. Expires April 16, 2012 [Page 20] Internet-Draft stateless 4V6 October 2011 functionality e.g. classifier as defined by the PacketCable specifications and supported by CMTS and CM. Taking PCMM specification as an example, it is worth noting that PCMM already allows for (and mandates) a minimum of four classifiers to be included in Gate-set. Hence, a Policy Server can communicate (via pkt-mm-2) both IPv4 and IPv6 classifier to the CMTS, which can use IPv6 classifier for constructing its data-plane filters (for DownStream processing), and convey IPv4 classifier to the CM via DOCSIS messages (pkt-mm-1) for any Upstream Processing. So, the 4V6 Translation Mode would work out in current implementations/deployment reasonably well. Separately, it is likely that the CPE Router would be engaged in serving IPv4 multicast content to IPv6 receivers (and vice versa) in future, requiring 'translation' function. In summary, while 4V6 Translation mode can work with the existing PacketCable framework, 4V6 Tunnel mode can not. 5. Overview of potential issues and discussion This section summarizes the issues attributed to an A+P, or port restricted scheme, along with a discussion of applicability to the assumed system and possible resolutions. The summary of issues stem from [I-D.thaler-port-restricted-ip-issues] and associated discussions. 5.1. Notion of Unicast Address 5.1.1. Overview The issue, referred to as the "definition of a unicast address", relates to the notion that in a shared IPv4 address system, multiple hosts will be visible as having a single IPv4 address outside of the system. This issue is a general characteristic of any NAPT44 based solution [I-D.ietf-intarea-shared-addressing-issues], including DS- Lite. However, a more specific aspect of this issue in the context of an address sharing system is the possibility that a single host having multiple interfaces will be assigned the same IPv4 address (with different port ranges) on each of its interfaces. It may also be that multiple hosts sharing an address find themselves on the same Layer 2 segment. Either would impede hosts from working within the notion of known host IP stack and protocol implementations. Dec, et al. Expires April 16, 2012 [Page 21] Internet-Draft stateless 4V6 October 2011 5.1.2. Discussion A number of the characteristics of the 4via6 solution architecture cause the issues not to be applicable, key of which is that there is no expectation for any kind of end hosts to be part of the shared IPv4 address system. In the stateless 4via6 system, CPE nodes are assigned with a shared IPv4 address+port range by means of the unique IPv6 address, containing the embedded IPv4 address + port index, of that CPE node. The CPE node is in addition enabled to be running the port restricted NAPT44 function from the IPv6 derived address, a key characteristic of the solution. On the IPv6 plane, the IPv6 address of the CPE is practically indistinguishable from any "regular" IPv6 address, and in fact any host that is not aware of it conveying an embedded IPv4 address would be able to use this just like any other regular IPv6 address, ie the 4via6 solution uses standard IPv6 addressing. In terms of the IPv4 dimension, since the shared address and port index are never used to address native IPv4 nodes or hosts, but instead uniquely assigned to a single NAPT44 function that is part of the CPEs, all legacy or other IPv4 hosts are not exposed to the presented issues. Going beyond the ascribed issue however, it appears desirable to have the 4via6 CPEs that are to be part of the shared system to be able to provide a hint to the network operator in terms of their special capability. Such a hint can be a DHCPv6 Option Request Option, which would be useful to allow the DHCPv6 sub-system to also inform the CPE of any other stateless 4via6 system parameters. A largely similar ORO option is currently being defined as part of [I-D.ietf-softwire-ds-lite-tunnel-option] Recommendation: Define a suitable DHCPv6 ORO for conveying the 4via6 capability of a CPE. 5.2. Implementation on hosts 5.2.1. Overview The issue, as presented, relates to the need for modifications on end hosts or devices to support a port constrained mechanism and the overall impossibility of realizing such modifications. Furthermore, host applications that attempt to bind to specific ports that are not part of the allowed port range will fail to do so and may also require modifications. Dec, et al. Expires April 16, 2012 [Page 22] Internet-Draft stateless 4V6 October 2011 5.2.2. Discussion As presented in Section 3 the solution assumes the use of a dedicated CPE implementing the 4via6 functionality within a port constrained mode and NAPT44. Granted, CPE nodes will require to implement new functionality such as the IPv6 adaptation function, that is likely alongside introducing native IPv6 support. However, any and all existing end user IPv4 devices (eg PCs, etc) will not affected. Nor are such devices expected to behave in any way different from that of today, where they typically obtain a private rfc1918 address and multiplexed by a CPE using a NAPT44 function. In summary, the assumed 4via6 solution requires a specific 4via6 CPE but does not require any IPv4 host stack changes. 5.3. 4V6 address and impact on other IPv6 hosts 5.3.1. Overview The issue relates to the question of whether the operation of a regular IPv6, non 4V6 capable, host would be adversely impacted should it be assigned or auto-configured with an address from an S64 address or prefix pool. 5.3.2. Discussion The 4V6 prefix is for all intents and purposes a regular IPv6 prefix, and as such can be announced/assigned to any IPv6 host which in turn can used derived addresses like any other IPv6 address. Thus, an 4V6 IPv6 domain can address non-4V6 devices, leaving such devices to operate as native IPv6. There is however a restriction on the 4V6 CE devices. As described in Section 2, a 4V6 CE constructs itself the full 128 bit address from the concatenation of the IPv6 prefix, 4V6 domain information acquired statelessly, and a pre-determined or algorithmic interface-id. By definition, only one 4V6 CE can use the same IPv4 address and port index. Hence, while there is no exact limitation on the number of non 4V6 hosts that can be addressed from an 4V6 prefix, there is a limit of one 4V6 CE per 4V6 prefix. Using a 4V6 prefix to address network segments without 4V6 devices does diminish the efficiency of the IPv4 address sharing mechanism, in terms of using up port ranges onto segments that will not use them. This is naturally a deployment consideration which an operator can optimize. Dec, et al. Expires April 16, 2012 [Page 23] Internet-Draft stateless 4V6 October 2011 5.4. Impact on 4V6 CE based applications 5.4.1. Overview It has been claimed that applications implemented on the CE itself, eg a DNS resolver-client, may be impacted by the 4V6 functionality. In particular, a concern is that such applications would either need to be specially engineered to issue socket calls or extensive IP stack modifications made to support them. 5.4.2. Discussion By definition the 4V6 CE is an IPv6 capable device, and any IPv6 capable applications will be able to use the native IPv6 stack (note: IPv6 interface selection, is discussed in section 5.5). As such, the concern raised does not apply to applications that can be expected to support IPv6, and instead only to IPv4-only applications running on the 4V6 CE. The shared IPv4 address is intended to be used only by the 4V6 CE function. This shared IPv4 address does not need to be assigned to an interface on the 4V6 CE and thus a target for potential applications. Any such applications running on the 4V6 will use any of the other (likely private) IPv4 address on the CE, which then will be routed to the 4V6 function this is applied post routing for the packets generated by these applications. 5.5. 4V6 interface 5.5.1. Overview A 4V6 CE will have a "self configured" 4V6 IPv6 interface address, alongside any other SLAAC or DHCPv6 derived addresses, potentially from the same prefix. This particular 4V6 address may be subject to specific filtering rules or restrictions by the operator, besides usage and filtering restrictions on the 4V6 CE. Also, for the 4V6 system to operate as intended, the 4V6 application on the CE must be restricted to using the specific 4V6 address when sourcing 4V6 packets. Also, the 4V6 CE needs to be set-up to correctly forward IPv4 traffic to the 4V6 application. 5.5.2. Discussion While the method of creating the interface is implementation specific, the generic operating model that is envisaged is for the 4V6 application to create the 4V6 interface as a virtual interface with an IPv4 unnumbered address. The application would then install a default IPv4 route pointing to this virtual interface, which would Dec, et al. Expires April 16, 2012 [Page 24] Internet-Draft stateless 4V6 October 2011 be effectively see the 4V6 application acting as a network appliance on the forwarded traffic. In terms of IPv6 behaviour, the 4V6 application is expected to be set up to specify the use (binding) to the 4v6 IPv6 virtual interface. 5.6. Non TCP/UDP port based IP protocols - ICMP) 5.6.1. Overview This issue relates to the inability of using regular ICMP messages to "ping" an end-host that has been addressed with a shared IPv4 address. The issue can be generalized one applicable to any IP protocol that is not TCP/UDP port based, and also in terms of the ability of using such protocols from end hosts that are assigned a shared IPv4 address. 5.6.2. Discussion The inability to ping a CPE from the IPv4 Internet is shared by other IPv4 address sharing mechanisms such as DS-Lite. Thus, the issue is no better or worse in the case of the stateless 4via6 solution. The same can be said of end user hosts using other non UDP/TCP port based protocols from behind a NAPT44 function, ie they will not function irrespective of address sharing or not. As discussed in [I-D.ietf-intarea-shared-addressing-issues], all IP address sharing solutions break protocols which do not use transport numbers. A mitigation solution is to utilize specific ALGs. For ICMP in particular, a mitigation solution would be to rewrite the "Identifier" and perhaps "Sequence Number" fields in the ICMP request, treating them as if they were port numbers. As a conclusion, this issue can be partially mitigated, likely at par to centralized NAT solutions. 5.7. Provisioning and Operational Systems 5.7.1. Overview The general claim of this issue is that a service providers' provisioning and accounting systems would need to [radically] evolve to deal with the notions of shared IPv4 addresses and port range constrains. 5.7.2. Discussion The stateless 4via6 solution relies on a fully operational IPv6 network, which on the IPv6 plane fundamentally does not differ from a Dec, et al. Expires April 16, 2012 [Page 25] Internet-Draft stateless 4V6 October 2011 regular IPv6 network, and the stateless 4via6 solution may be seen as an IPv6 application - devices connecting to the network, need unique IPv6 addresses which the network is able to provide. In the 4via6 solution it happens that these unique IPv6 addresses embed an IPv4 address. Hence, additional system enhancements that the stateless 4via6 solution requires, over and above those simply needed to deploy and operate an IPv6 network, lie in the domain of supporting the provisioning of the IPv6 adaptation functionality of the CPEs. This may require the operator to use DHCPv6, or other provisioning methods such as IPv6CP, TR-69, in order to configure any relevant 4via6 service parameters to a CPE. From an IPv4 perspective, an operator will likely want to have a management system capable of the assignment of IPv4 addresses to the shared pool, and tuning the re-use factor. In this, the solution exhibits no grossly different characteristics than those of any system with an operator managed NAT44 function where similar management capabilities need to be introduced. One additional aspect of the stateless 4via6 solution needs to be highlighted. On a par basis this solution requires less per subscriber management, accounting and logging capabilities than centralized NAPT44 alternatives such as DS-Lite, due to the following: o The assignment of an IPv6 address that embeds a deterministic IPv4 address and port range removes the need for the operator to perform any NAPT44 binding logging, ie the task of determining which user had a given IPv4 address and port at a given time is simply a matter of determining who had the corresponding IPv6 address, rather than collecting large amounts of dynamic binding data. o There is no need for the operator to manage NAPT44 binding data access and retention. o Given the stateless nature of the 4via6 solution, all subscriber CPEs in an operator's domain can share exactly the same 4via6 service configuration, i.e. The operator does not need to be concerned with managing on a per user basis specific AFTR assignment and/or load balancing such users and throughout ensuring symmetric traffic flows throughout. o The location of the NAPT44 function on the user's CPE, allows easy and direct management of the port mappings by the end user removing a need for the operator to introduce PCP [I-D.wing-softwire-port-control-protocol] (or similar) protocols in on AFTRs, and on CPE devices. In effect the end user can Dec, et al. Expires April 16, 2012 [Page 26] Internet-Draft stateless 4V6 October 2011 retains control of any bindings, which could be via today's GUI, or UPnP IGDv2, or even PCP. o As and when needed, a stateless 4via6 solution readily supports the assignment of an unshared IPv4 address, and full port control by the end user. A similar capability with centralised NAPT44 solutions involve onerous management of per subscriber configurations on the operator's AFTR. 5.8. Training & Education 5.8.1. Overview The issue claims a concern with the need for developers and support staff to be trained & educated in dealing with a port constrained systems. 5.8.2. Discussion There appear to be at least two levels of looking at this issue in the stateless 4via6 context. On one level, it is perfectly true that developers and support staff will need to be trained with running/ supporting a native IPv6 network, that is now a basis of the solution. This however is an inherent aspect of deploying an IPv6 network and applications. On another level, support and developers need to familiarized with the NAPT44 characteristics of the system, that are not different from those already known about such systems today. More specifically, there appears to be no such thing as a port unconstrained carrier grade NAPT44 system, in either tomorrow's stateless 4via6 or AFTR guises, or today's residential CPE NAPT44 implementations that have an inherent hard set translation limit (often 1024 translation, corresponding to a usage of 1024 ports). That application developers should be trained to be reasonably conservative in the usage of ports is thus not an issue of the stateless 4via6 solution, but pretty much of any NAPT44 based solution, even those in use today. Another useful observation here is that the stateless 4via6 solution, actually allows an operator to retain existing troubleshooting procedures, given which today encompass CPE based NAPT44, rather than changing them radically to an AFTR. Furthermore, it is possible to alleviate any port-range constrains for users by allocating more generous port ranges without the need to manage such users configuration on active core network devices (eg AFTR). Dec, et al. Expires April 16, 2012 [Page 27] Internet-Draft stateless 4V6 October 2011 5.9. Security and Port Randomization 5.9.1. Overview Preserving port randomization [RFC6056] may be more or less difficult depending on the address sharing ratio (i.e., the size of the port space assigned to a CPE). Port randomization may be more difficult to achieve with a stateless solution than stateful solution. The CPE can only randomize the ports inside be assigned a fixed port range. 5.9.2. Discussion The difference in the random port selection range may be significant in practice and using port-restricted systems without any measures (like random port selection in draft-bajko-pripaddrassign-03) is one of the trade-offs of the mechanism. It should be however noted that even full port unrestricted systems, today, rarely implement random port selection from the full port range, as such the difference is largely theoretical, again viewed from today's perspective. Only with a longer term prospect of devices/hosts adopting random port selection according to RFC 6056 the NAT-based port-restricted mechanisms, will degrade security to a certain extent. 5.10. Unknown Failure Modes 5.10.1. Overview The issue purports that a system with a port constraints introduces new unknown failure modes, not known with NAT44 or NAPT44 systems, and in general is more complex than such a system. 5.10.2. Discussion This claim does not appear to have objective technical arguments that can be discussed. A restricted port range system, such as the one assumed in this document, does not appear to have any more or less complexity than any of the other NAPT44 solutions against which the same issue has not been levelled. That is a statement that can be made in consideration of each of those alternative solution network design (eg elaborate routing rules or topologies) and feature implementation complexities, which appear to be no better than that of a stateless 4via6 address port range system. Ultimately, system complexity is something best left adjudicated by the operators choosing to deploy one or the other of these IP based transition solutions. Dec, et al. Expires April 16, 2012 [Page 28] Internet-Draft stateless 4V6 October 2011 5.11. Possible Impact on NAT66 use & design 5.11.1. Overview The notion of a shared address with a constrained port range is seen as possibly bearing influence on use in future schemes involving NAT66, where IPv6 address sharing is in general deemed not to be desired (ie there is good reason to avoid PAT66). 5.11.2. Discussion The authors do not propose, nor expect to see the IP address sharing characteristic applying to future NAT66/PAT66 discussions and specification. However, having said that it is useful to take a humble step back and consider the general aspect of causality in this context. The direct cause that brought about IPv4 shared address solutions to the fore was a shortage/exhaustion of a limited IPv4 address resource, alongside a failure of the community to migrate IPv4 networks to IPv6 in a timely manner. At the time of writing it is hard to imagine the same occurring with respect to IPv6 address resources, and hopefully the same set of causes will not be allowed to re-occur. This appears to be the only way to ensure that IPv6 address sharing effect does not come to be, as opposed to precluding such notions within the context of today's IPv4 world where the causality is rather clear. 5.12. Port statistical multiplexing and monetization of port space 5.12.1. Overview An issue attributed to 4V6 solutions is that due to their characteristic of assigning a fixed amount of ports to participating system nodes, the overall pool of ports cannot be dynamically/ statistically multiplexed. A corollary of this claimed issue is the claim that port range constraints will lead to monetization by service providers of such port ranges, for example by charging users based on the number of ports assigned or creating some bronze, silver, gold type of port based service categories. 5.12.2. Discussion The 4via6 address shared solution indeed limits the ability to "overload" ie statistically multiplex amongst users, the ports available of a given public IPv4 address. This can be seen as a trade off vs dynamic allocation and the need to log (large amounts) of NAT bindings. Furthermore, the solution is meant to be Dec, et al. Expires April 16, 2012 [Page 29] Internet-Draft stateless 4V6 October 2011 fundamentally a transitional one for supporting legacy IPv4 users till full migration to IPv6 can occur. As an example, even with a static allocation of ~1000 ports per shared IP user, it allows an operator to effectively multiply by ~64 the current IPv4 unrealizable address space. To put it into a network growth perspective, it allows an operator to support for some 10 years a steady 50% annual increase in users, without requiring new IPv4 addresses. This is likely an alluring (if unlikely) prospect for most, but it demonstrates the fact that even with static port allocations, IPv4 address sharing can go a long way for many operators. 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, in case a CGN pre-allocates port ranges, for instance to alleviate traceability complexity it also reduces its port utilization efficiency. 5.13. Readdressing 5.13.1. Overview Due to the port range encoding being part of the CPE's IPv6 address, any change in the range requires a re-configuration of the CPEs 4via6 address. This is said to be an issue given the impact that IP address changes have on existing traffic flows, as well as general IPv6 network routing 5.13.2. Discussion It is true that under the assumed notions of the stateless 4via6 solution, IPv6 re-addressing is required to effect a change in terms of the shared IPv4 address or ports. Such changes can and are likely best done using dynamic address configuration methods such as DHCPv6, or alternatively out of band management tools, eg TR-69, especially when the 4via6 address can be derived from a delegated prefix. Using these, the impact of the address change does not translate to a neither a classic IPv6 host renumbering problem nor an unmanageable network renumbering problem. On the CPE, the change only affects the 4via6 address of the CPE and not any end user IPv6 hosts behind the CPE (which would likely continue to derive their IPv6 addresses from an unchanged delegated prefix). On the service provider network side, the change, if any, represents a network renumbering case which the operator can be reasonably expected to handle within their network numbering plan, especially given that the IPv6-prefix of the an IPv4-in-IPv6 address is summarizable. Dec, et al. Expires April 16, 2012 [Page 30] Internet-Draft stateless 4V6 October 2011 An addressing change will impacting any existing IPv4 flows that are being NAT'ed by the CPE. This is also analogous to the today's practice of IPv4 address changes espoused by some operators, which while not being commendable, is established in the market. Nevertheless, as a means of alleviating such an impact it appears desirable for the solutions to investigate the viability of mechanisms that could allow for more graceful addressing changes. To facilitate IPv6 summarization and operator appears to have two 4V6 deployment choices. When encoding IPv4 addresses in lower order address space bits that are subject to summarization,the operator would need to assign a modest dedicated IPv6 prefix (such as a /64) as an 4V6 IPv6 addressing sub-domain. Alternatively, without resorting to a separate 4V6 addressing sub-domain, an operator could allow for the IPv4 address embedding to be embedded in a high-order portion of the IPv6 domain address space, one that closely follows the IPv6 domain prefix. These two valid address subnetting and deployment options deserve better description in the solution specifications. 5.14. Ambiguity about communication between devices sharing an IP address. 5.14.1. Overview A regular IPv4 destination based routed system inherently does not allow two devices to communicate while sharing the same IPv4 address, even if with different ports. Similarly, such a system does not allow on the basis of a IPv4 source address alone to perform address spoofing prevention. These two issues naturally render regular IPv4 based routed networks incapable of supporting a shared address solution. 5.14.2. Discussion In terms of the IPv4 data plane of the 4via6 solution, the CPE and the stateless gateway components need to be modified in terms of their IPv4 forwarding behaviour. The CPE's NAPT44 function, must be capable of sending traffic towards the IPv6 adaptation function when the traffic is addressed to its (shared) IPv4 address but a different port than the one assigned to the CPE. Similarly, the CPE's NAPT44 function must be capable of receiving traffic addressed from its (shared) IPv4 address but a different port than the one assigned to it. On the IPv6 data plane the stateless 4via6 solution does not suffer from the issue by the nature of relying on regular IPv6 forwarding. Address-spoofing security can be realized on regular IPv6 devices Dec, et al. Expires April 16, 2012 [Page 31] Internet-Draft stateless 4V6 October 2011 plane, in a way which effectively does not allow a CPE to send IPv6 traffic from a source IPv6 address that it has not been assigned. The spoofing of IPv4 addresses can be prevented in this manner in 4via6 solution relying on translation (dIVI). Tunneling 4via6 solutions (4rd) require IPv6+IPv4 source address validation to be performed at the CPE and stateless gateway, by the IPv6 adaptation function. The conceptual IPv6 adaptation function has many of its core principles already defined either as part of IPinIP tunneling or stateless NAT64 drafts. However additional work, such as defining the port indexing schemes, is needed and is at the heart of what needs to be covered in the individual solution drafts that fall under the stateless 4via6 family. Throughout, no legacy IPv4 end-systems are expected to implement these techniques. 5.15. Other 5.15.1. Abuse Claims Because the IPv4 address is shared between several customers, and in order to meet the traceability requirement discussed in Section 12 of [I-D.ietf-intarea-shared-addressing-issues], Service Providers must store the assigned ports in addition to the IPv4 address. If the remote server does not implement the recommendation detailed in [I-D.ietf-intarea-server-logging-recommendations], the Service Provider may be obliged to reveal the identity of all customers sharing the same IP address at a given time. 5.15.2. Fragmentation and Traffic Asymmetry In order to deliver a fragmented IPv4 packet to its final destination, among those having the same IPv4 address, a dedicated procedure similar to the one defined in Section 3.5 of [RFC6146] is required to reassemble the fragments in order to look at the destination port number. When several stateless IPv4/IPv6 interconnection nodes are deployed, and because of traffic asymmetry, situations where fragments are not handled by the same stateless IPv4/IPv6 interconnection node may occur. Such context would lead to session breakdowns. As a mitigation, a solution would be to redirect fragments towards a given node which will be responsible for implementing the procedure documented in [RFC6146]. The redirection procedure is stateless. As a conclusion, this issue can be mitigated. Dec, et al. Expires April 16, 2012 [Page 32] Internet-Draft stateless 4V6 October 2011 5.15.3. Multicast Services IPv4 service continuity must be guaranteed during the transition period, including the delivery of multicast-based services such as IPTV. Because only an IPv6 prefix will be provided to a CPE, dedicated functions are required to be enabled for the delivery of legacy multicast services to IPv4 receivers. This is critical since many of the current IPTV contents are likely to remain IPv4-formatted and there will remain legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that can't be upgraded or be easily replaced. This issue is similar to the one encountered in the stateful case, and the same solution can be used to mitigate the issue (e.g., [I-D.qin-softwire-dslite-multicast]). As a conclusion, this issue can be solved. 6. Conclusion As per the discussion in this document, the authors believe that the set of issues specifically attributed to A+P based such as the stateless 4via6 solution with characteristics as per Section 3, either do not apply, or can be mitigated. In several aspects, a stateless 4V6 solution represents a reasonable trade off compared to alternatives in areas such as NAT logging, ease as of deployment and operations, all of which are actually facilitated by such a solution. In terms of the 4V6 transport mode, both translation and mapped tunnel appear to be share the same key characteristics, but applicable to different contexts. The mapped tunnel mode appears desirable when the operator has no expectations of applying any more elaborate traffic based services, and/or concerned about the loss of IP Options or the use of NAT64 technology. The translation based approach appears particularly attractive to operators who are concerned about integrating traffic into a more elaborate suite of services based on regular IPv6 data-plane functionality, as opposed to specific IPinIP data plane functionality. 7. IANA Considerations This document does not raise any IANA considerations. 8. Security Considerations This document does not introduce any security considerations over and Dec, et al. Expires April 16, 2012 [Page 33] Internet-Draft stateless 4V6 October 2011 above those already covered by the referenced solution drafts. 9. Contributors and Acknowledgements The authors thank Dan Wing, Nejc Skoberne, Remi Depres, Xing Li, Jan Zorz, Satoru Matsushima, Mohamed Boucadair, Qiong Sun, and Arkadiusz Kaliwoda for their reviews and draft input. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-03 (work in progress), September 2010. [I-D.despres-softwire-4rd] Despres, R., "IPv4 Residual Deployment across IPv6-Service networks (4rd) A NAT-less solution", draft-despres-softwire-4rd-00 (work in progress), October 2010. [I-D.ietf-intarea-server-logging-recommendations] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging recommendations for Internet facing servers", draft-ietf-intarea-server-logging-recommendations-04 (work in progress), April 2011. [I-D.ietf-intarea-shared-addressing-issues] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", draft-ietf-intarea-shared-addressing-issues-05 (work in progress), March 2011. [I-D.ietf-softwire-ds-lite-tunnel-option] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", draft-ietf-softwire-ds-lite-tunnel-option-10 (work in progress), March 2011. Dec, et al. Expires April 16, 2012 [Page 34] Internet-Draft stateless 4V6 October 2011 [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work in progress), May 2011. [I-D.murakami-softwire-4v6-translation] Murakami, T., Chen, G., Deng, H., Dec, W., and S. Matsushima, "4via6 Stateless Translation", draft-murakami-softwire-4v6-translation-00 (work in progress), July 2011. [I-D.operators-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Stateless IPv4 over IPv6 Migration Solutions", draft-operators-softwire-stateless-4v6-motivation-02 (work in progress), June 2011. [I-D.qin-softwire-dslite-multicast] Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y. Lee, "Multicast Extensions to DS-Lite Technique in Broadband Deployments", draft-qin-softwire-dslite-multicast-04 (work in progress), June 2011. [I-D.thaler-port-restricted-ip-issues] Thaler, D., "Issues With Port-Restricted IP Addresses", draft-thaler-port-restricted-ip-issues-00 (work in progress), February 2010. [I-D.vixie-dnsext-dns0x20] Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity", draft-vixie-dnsext-dns0x20-00 (work in progress), March 2008. [I-D.wing-softwire-port-control-protocol] Wing, D., Penno, R., and M. Boucadair, "Pinhole Control Protocol (PCP)", draft-wing-softwire-port-control-protocol-02 (work in progress), July 2010. [I-D.xli-behave-divi] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03 (work in progress), July 2011. Dec, et al. Expires April 16, 2012 [Page 35] Internet-Draft stateless 4V6 October 2011 [I-D.xli-behave-divi-pd] Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun, "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation", draft-xli-behave-divi-pd-01 (work in progress), September 2011. [I-D.ymbk-aplusp] Bush, R., "The A+P Approach to the IPv4 Address Shortage", draft-ymbk-aplusp-10 (work in progress), May 2011. [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. Authors' Addresses Wojciech Dec Cisco Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Email: wdec@cisco.com Dec, et al. Expires April 16, 2012 [Page 36] Internet-Draft stateless 4V6 October 2011 Rajiv Asati Cisco Raleigh, NC USA Phone: Fax: Email: rajiva@cisco.com URI: Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 CN Phone: +86 10-62785983 Fax: Email: congxiao@cernet.edu.cn URI: Hui Deng China Mobile Beijing, CN Phone: Fax: Email: denghui@chinamobile.com URI: Mohamed Boucadair France Telecom France Phone: Fax: Email: mohamed.boucadair@orange-ftgroup.com URI: Dec, et al. Expires April 16, 2012 [Page 37]