Network Working Group W. Dec, Ed. Internet-Draft Cisco Systems Intended status: Informational March 27, 2011 Expires: September 28, 2011 Stateless 4Via6 Address Sharing draft-dec-stateless-4v6-01 Abstract This document discusses the applicability and possible resolution of a number of issues attributed to A+P based solutions, specifically in the context of an IPv6 based solution characterised by this draft as a stateless 4Via6 (4V6) solution. The document presents that the majority of the issues either do not apply to such stateless 4V6 solutions, or are no worse that in alternative NAT44 based solutions. The few remaining issues can be mitigated by the solutions or operators. 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 September 28, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Dec Expires September 28, 2011 [Page 1] Internet-Draft stateless 4V6 March 2011 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. Dec Expires September 28, 2011 [Page 2] Internet-Draft stateless 4V6 March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Stateless 4-6-4 Technical and Architectual characteristics . . 4 3. Overview of issues and discussion . . . . . . . . . . . . . . 7 3.1. Notion of Unicast Address . . . . . . . . . . . . . . . . 7 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Implementation on hosts . . . . . . . . . . . . . . . . . 8 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Non TCP/UDP port based IP protocols . . . . . . . . . . . 8 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Provisioning and Operational Systems . . . . . . . . . . . 9 3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Training & Education . . . . . . . . . . . . . . . . . . . 11 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 11 3.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 12 3.7. Unknown Failure Modes . . . . . . . . . . . . . . . . . . 13 3.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 13 3.8. Possible Impact on NAT66 use & design . . . . . . . . . . 13 3.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 13 3.8.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 13 3.9. Port statistical multiplexing and monetization of port space . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 3.9.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 14 3.10. Readdressing . . . . . . . . . . . . . . . . . . . . . . . 15 3.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15 3.10.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 15 3.11. Ambiguity about communication between devices sharing an IP address. . . . . . . . . . . . . . . . . . . . . . . 16 3.11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16 3.11.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 16 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Contributors and Acknowledgements . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Dec Expires September 28, 2011 [Page 3] Internet-Draft stateless 4V6 March 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, to which a number of solutions have been put forward. The solutions fall largely into two types of architectures characterized by the location of the IPv4 address sharing/overloading function. As an example, the DS-lite solution [I-D.ietf-softwire-dual-stack-lite] relies on the use of a large scale stateful Address Family Transition Router (AFTR), capable of IPv4 address sharing, ie DS-Lite uses a centralized large scale port overloaded stateful NAT44, aka PAT44, that is deployed within the operators' core network. In contrast, solutions such as a 4rd [I-D.despres-softwire-4rd] and dIVI [I-D.xli-behave-divi] rely on the use of fully distributed NAPT44 functionality located on end user CPEs, keeping the network operators' core effectively stateless. The latter type of solutions, rely on the same IPv4 address being used by multiple CPEs, each with a different TCP/UDP port range, and are often referred to as being part of the Address+Port (A+P) solution space [I-D.ymbk-aplusp]. A number of issues have been claimed to be attributed to this type of technology & solution, eg [I-D.thaler-port-restricted-ip-issues], [A+P BoF], which have so far delayed standardization progress, and which this draft attempts to discuss and resolve. Specifically, for the analysis the document assumes a number of architectural and technical characteristics, termed as the stateless 4via6 solution, as detailed in the following section. The term "stateless 4via6 solution" is a general reference to the class of A+P derivative solutions, such as 4rd [I-D.despres-softwire-4rd] and dIVI [I-D.xli-behave-divi], as well a subset of the original A+P solution [I-D.ymbk-aplusp]. The term NAPT44 is used to refer to IPv4-IPv4 Network Address Translation with port overloading. 2. Stateless 4-6-4 Technical and Architectual characteristics The following architectural and technical characteristics assumed by this document, and evidenced in whole or in part by various stateless 4via6 solution proposals such as 4rd, dIVI, SAM, besides architectural practice. Figure 1 depicts the overall architecture with two IPv4 user networks connected via 4via6 CPEs that share an IPv4 address. Dec Expires September 28, 2011 [Page 4] Internet-Draft stateless 4V6 March 2011 ? User 1 Private IPv4 | Network | O------------------O | 4V6 CPE | | +-----+--------+ | | NAPT44| IPv6 | `-. | +-----+ Adptn | | -._ ,-------. ------. | +--------+ | ,-' `-. ,-' `-. O------------------O / Routed \ O---------O / Public \ / IPv6 \ |Stateless|/ IPv4 \ ( Network --+ 6V4 +- Network ) \ / | Gateway |\ / O------------------O \ / O---------O \ / | 4V6 CPE | ;". ,-' `-. ,-' | +-----+--------+ | ," `-------' ------' | NAPT44| IPv6 | ," | +-----+ Adptn | | | +--------+ | O---.--------------O | User 2 Private IPv4 Network Figure 1 - Generalized Stateless 4via6 system The stateless 4via6 system has the following characteristics: 1. On user network side the routed IPv6 service provider network is demarcated from the IPv4 user network with a dedicated 4V6 CPE. The CPE externally has only a native IPv6 interface to the SP network, and a native IPv4 interface towards the end user network. 2. Internally, the 4V6 CPE can be modelled as having a port restricted NAPT44 function coupled with a stateless IPv6 adaptation function that is able to ferry the IPv4 traffic in/ over the IPv6 interface, besides deriving 4V6 provisioning info from it. The IPv6 adaptation function could be encapsulating packets in IPv4 or translating IPv4 packets, or a combination of both. 3. 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 on the CPE. Note: The stateless 6v4 gateway can be directly at the CPE side edge of the operator Dec Expires September 28, 2011 [Page 5] Internet-Draft stateless 4V6 March 2011 network, eg in an IP Edge router, or as shown some IP hops removed from the edge network. 4. The service provider has the all the necessary provisioning and accounting infrastructure to support a regular IPv6 deployment. CPE management operations, if any, are done using IPv6, however there is no per CPE or subscriber management required of the stateless 4via6 function, i.e. all stateless 4via6 can share the same service configuration, bar the IPv6 address naturally. 5. The network operator has the ability to assign an IPv6 prefix or IPv6 address to a CPE, and log such address assignment. 6. The shared IPv4 address and any port range is conveyed to the CPE as part of an IPv6 address or prefix, for example using [RFC6052], if not other IPv6 compatible encoding and a port indexing method. For a single shared public IPv4 address and port range, only a single IPv6 address or prefix is assigned irrespective of the port range size, with the mapping between IPv6 and IPv4 domains being entirely algorithmic based on a well known indexing schema. 7. The solution's architecture does not require customer traffic flows to pass through specific gateways in the network, or do so symmetrically. 8. 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. 9. The IPv6 Adaptation function is not multi homed to the same IPv6 network. The CPE itself may be multi homed, but it only has one IPv6 addressed interface for the stateless 4via6 application and IPv6 adaptation function. 10. A CPEs NAPT44 function is modified to operate in a shared address port-constrained NAPT44 mode, as per the detailed solution proposals. No DNS64 or IPv6 aware ALGs, nor IPv4 ALGs are used or assumed. 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. 11. Although orthogonal to the discussion of stateless 4V6, it is useful to note that the CPE is expected to have a native IPv6 Dec Expires September 28, 2011 [Page 6] Internet-Draft stateless 4V6 March 2011 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. Overview of 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. 3.1. Notion of Unicast Address 3.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. 3.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 Dec Expires September 28, 2011 [Page 7] Internet-Draft stateless 4V6 March 2011 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. 3.2. Implementation on hosts 3.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. 3.2.2. Discussion As presented in Section 2 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. 3.3. Non TCP/UDP port based IP protocols Dec Expires September 28, 2011 [Page 8] Internet-Draft stateless 4V6 March 2011 3.3.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. 3.3.2. Analysis 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. In relation to the above another aspect deserves to be highlighted. Throughout, in the 4via6 solution, the IPv6 address of the CPE can be used for operational activities, such as pinging. Also, given that each CPE's IPv4 address + port range maps deterministically to an IPv6 address and vice versa, the solution actually facilitates customer troubleshooting in contrast to others, eg DS-Lite, where the mapping between IPv6 and IPv4 addresses is indeterminate. 3.4. Provisioning and Operational Systems 3.4.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. 3.4.2. Discussion The stateless 4via6 solution relies on a fully operational IPv6 network, which on the IPv6 plane fundamentally does not differ from a 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 Dec Expires September 28, 2011 [Page 9] Internet-Draft stateless 4V6 March 2011 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 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. Dec Expires September 28, 2011 [Page 10] Internet-Draft stateless 4V6 March 2011 3.5. Training & Education 3.5.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. 3.5.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). 3.6. Security 3.6.1. Overview The issue relates to port randomization being used as a security mitigation for certain types of specialized attacks, as explained in [RFC6056] and the claim that a system with a restricted port range is grossly more vulnerable. Dec Expires September 28, 2011 [Page 11] Internet-Draft stateless 4V6 March 2011 3.6.2. Discussion The claim that a stateless 4via6 solution grossyly affects security does not appear to be entirely accurate when considering the following i) the actual threat ii) a comparison to a centralized NAPT44 solution, at par value in terms of the number communicating of IP end-points (inside) utilizing the system iii) the ability to use native IPv6 as well as proposed extensions. Assuming all other information has already been aquired, and also the presence of no exploits, the basic security of IP protocols lies in the computational cost of guessing a combination of a protocol field, eg a TCP sequence number or say a DNS transaction ID, multiplied by a the cost of a guess of a source port. Thus, for a TCP brute force attack, the already substantial cost in guessing a sequence number (2^32 possibilities) is multiplied by the port range guess cost. In this context even a increase of say a 2^10 possibilities, corresponding for in a 1K port restricted 4V6 system, is costly enough for most practical purposes. For a UDP/DNS brute force attack, the computational cost required to scan/generate the full range of 2^32 possibilities, corresponding to a port unrestricted system is relatively low/easy - today's GPUs can do so in a few seconds. UDP/DNS can be said to be inherently vulnerable, with the solution residing in DNSec. A 4V6 port restricted system would indeed lower such a computational cost, but for practical purposes it will still be in the order of seconds. Moreover, for the case of UDP/DNS, the CPE is expected to us its DNS proxy resolver functionality, which acting on native IPv6, is totally unaffected by the port restriction, and thus any of the security claims. It's relevant to note that a fully range free random port choice of a centralized NAPT44 system is also something that is unlikely, at least in terms of it being guaranteed, and thus does not form a very strong basis against a port restricted system. When a centralized NAPT44 function is multiplexing N end-points into a given outside IPv4 address, with an average of P ports per end-point, any given next flow from any of the end-points will be assigned to one of the (64k - N *P) available ports. This is dependent on dynamic N and P values, and not just on P, and thus making the port selection a function of the number of end-points as is the case with a stateless 4via6 solution. Beyond the above, in terms of the avoiding a fixed linear or single port range allocations, extensions to the 4V6 solution provides additional remedy, eg [I-D.bajko-pripaddrassign]. In general thus, with a 4V6 solution it is possible to realize a viable level of security, which for practical purposes offers does Dec Expires September 28, 2011 [Page 12] Internet-Draft stateless 4V6 March 2011 not and extending the 4V6 solution with . It remains an area of possible further proposals for optional port range randomization methods to be combined in a 4V6 solution. 3.7. Unknown Failure Modes 3.7.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. 3.7.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. 3.8. Possible Impact on NAT66 use & design 3.8.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). 3.8.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 Dec Expires September 28, 2011 [Page 13] Internet-Draft stateless 4V6 March 2011 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. 3.9. Port statistical multiplexing and monetization of port space 3.9.1. Overview An issue attributed to port range constrained 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. This is generally seen as an undesirable prospect due to it leading to "second class" Internet citizens(hip) in terms of a restriction of the ports utilizable by IP users. 3.9.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 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. In terms of the corollary of this issue, the monetization of port space, the authors do not consider this claim to apply specifically to the restricted port range solution. It is a possibility that is and/all solutions that utilize NAPT44 technology allow. In essence any operator can, should they choose to do so, "monetize ports" using existing NAT techniques, including DS-Lite AFTR, and thus render their users "second class" citizens. This is a commercial decision, not a technical one, and does not appear to bear relevance to the Dec Expires September 28, 2011 [Page 14] Internet-Draft stateless 4V6 March 2011 technical validity of a stateless 4via6 solution.. To draw an analogy, guns and cannons can be used in a reckless manner or not. Thus it appears to be highly unbalanced to claim that one technology (eg cannons/DS-Lite) can to be developed by the community, but not the other (eg guns/a 4via6 address sharing solution). 3.10. Readdressing 3.10.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 3.10.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. 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 Dec Expires September 28, 2011 [Page 15] Internet-Draft stateless 4V6 March 2011 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. 3.11. Ambiguity about communication between devices sharing an IP address. 3.11.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. 3.11.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 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 Dec Expires September 28, 2011 [Page 16] Internet-Draft stateless 4V6 March 2011 the stateless 4via6 family. Throughout, no legacy IPv4 end-systems are expected to implement these techniques. 4. 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 2, 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. 5. IANA Considerations This document does not raise any IANA considerations. 6. Security Considerations This document does not introduce any security considerations over and above those already covered by the referenced stateless 4via6 solution drafts. 7. Contributors and Acknowledgements The authors thank Dan Wing, Jan Zorz, Satoru Matsushima, Qiong Sun, and Arkadiusz Kaliwoda for their review and feedback on the draft. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.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. Dec Expires September 28, 2011 [Page 17] Internet-Draft stateless 4V6 March 2011 [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-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. [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-07 (work in progress), March 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.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] Li, X., Bao, C., and H. Zhang, "Address-sharing stateless double IVI", draft-xli-behave-divi-01 (work in progress), October 2009. [I-D.ymbk-aplusp] Bush, R., "The A+P Approach to the IPv4 Address Shortage", draft-ymbk-aplusp-09 (work in progress), February 2011. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Dec Expires September 28, 2011 [Page 18] Internet-Draft stateless 4V6 March 2011 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. Author's Address Wojciech Dec (editor) Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Email: wdec@cisco.com Dec Expires September 28, 2011 [Page 19]