idnits 2.17.1 draft-dec-stateless-4v6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 355 has weird spacing: '...tateful stat...' == Line 387 has weird spacing: '...tateful stat...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 14, 2011) is 4571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'E-UTRAN' is mentioned on line 595, but not defined == Missing Reference: 'EUTRAN' is mentioned on line 718, but not defined == Missing Reference: 'PCMM' is mentioned on line 882, but not defined == Missing Reference: 'PC-DQOS' is mentioned on line 898, but not defined == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 1547, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dual-stack-lite' is defined on line 1577, but no explicit reference was found in the text == Unused Reference: 'I-D.vixie-dnsext-dns0x20' is defined on line 1608, but no explicit reference was found in the text == Unused Reference: 'RFC5961' is defined on line 1635, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 1639, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-03 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-03 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Dec 3 Internet-Draft R. Asati 4 Intended status: Informational Cisco 5 Expires: April 16, 2012 C. Congxiao 6 CERNET Center/Tsinghua 7 University 8 H. Deng 9 China Mobile 10 M. Boucadair 11 France Telecom 12 October 14, 2011 14 Stateless 4Via6 Address Sharing 15 draft-dec-stateless-4v6-04 17 Abstract 19 This document presents an overview of the characteristics of 20 stateless 4V6 solutions, alongside a assessment of the issues 21 attributes. The impact of translated or mapped tunnel transport 22 modes is also presented in the broader context of other industry 23 standard reference architectures and existing deployments. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 16, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Stateless 4V6 Technical and Architectual Overview . . . . . . 5 67 3.1. IPv4 address and algorithmic port indexing . . . . . . . . 7 68 3.2. 4V6 CE IPv6 Address and domain info . . . . . . . . . . . 7 69 3.3. IPv6 Adaptation Function . . . . . . . . . . . . . . . . . 8 70 3.3.1. 4V6 Stateless Tunneling Mode . . . . . . . . . . . . . 8 71 3.3.2. 4V6 Stateless Translation mode . . . . . . . . . . . . 9 72 4. Comparison of 4V6 transport modes . . . . . . . . . . . . . . 9 73 4.1. General Characteristics of 4V6 modes . . . . . . . . . . . 9 74 4.2. Mobile SP Architecture and 4V6 Applicability . . . . . . . 12 75 4.2.1. 3GPP overview . . . . . . . . . . . . . . . . . . . . 13 76 4.2.2. 3GPP and 4V6 modes . . . . . . . . . . . . . . . . . . 15 77 4.3. Cable SP Architectures & 4V6 Applicability . . . . . . . . 18 78 4.3.1. PacketCable Introduction . . . . . . . . . . . . . . . 18 79 4.3.2. PacketCable Construct - Classifier . . . . . . . . . . 20 80 4.3.3. 4V6 Modes Impact on PacketCable . . . . . . . . . . . 20 81 5. Overview of potential issues and discussion . . . . . . . . . 21 82 5.1. Notion of Unicast Address . . . . . . . . . . . . . . . . 21 83 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 84 5.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 22 85 5.2. Implementation on hosts . . . . . . . . . . . . . . . . . 22 86 5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 87 5.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 88 5.3. 4V6 address and impact on other IPv6 hosts . . . . . . . . 23 89 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 23 90 5.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 91 5.4. Impact on 4V6 CE based applications . . . . . . . . . . . 24 92 5.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24 93 5.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 94 5.5. 4V6 interface . . . . . . . . . . . . . . . . . . . . . . 24 95 5.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24 96 5.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 97 5.6. Non TCP/UDP port based IP protocols - ICMP) . . . . . . . 25 98 5.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 99 5.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25 100 5.7. Provisioning and Operational Systems . . . . . . . . . . . 25 101 5.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 102 5.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25 103 5.8. Training & Education . . . . . . . . . . . . . . . . . . . 27 104 5.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 27 105 5.8.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 27 106 5.9. Security and Port Randomization . . . . . . . . . . . . . 28 107 5.9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28 108 5.9.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28 109 5.10. Unknown Failure Modes . . . . . . . . . . . . . . . . . . 28 110 5.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28 111 5.10.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28 112 5.11. Possible Impact on NAT66 use & design . . . . . . . . . . 29 113 5.11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29 114 5.11.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29 115 5.12. Port statistical multiplexing and monetization of port 116 space . . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 5.12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29 118 5.12.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29 119 5.13. Readdressing . . . . . . . . . . . . . . . . . . . . . . . 30 120 5.13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 30 121 5.13.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 30 122 5.14. Ambiguity about communication between devices sharing 123 an IP address. . . . . . . . . . . . . . . . . . . . . . . 31 124 5.14.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 31 125 5.14.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 31 126 5.15. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 32 127 5.15.1. Abuse Claims . . . . . . . . . . . . . . . . . . . . . 32 128 5.15.2. Fragmentation and Traffic Asymmetry . . . . . . . . . 32 129 5.15.3. Multicast Services . . . . . . . . . . . . . . . . . . 33 130 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 33 131 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 133 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 34 134 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 135 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 136 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 139 1. Introduction 141 As network service providers move towards deploying IPv6 and IPv4 142 dual stack networks, and further on towards IPv6 only networks, a 143 problem arises in terms of supporting residual IPv4 services, over an 144 infrastructure geared for IPv6-only operations, and doing so in the 145 context of IPv4 address depletion. This class of problem is referred 146 to by the draft as the 4via6 problem, for which a stateless solution 147 is desired driven by motivation as documented in 148 [I-D.operators-softwire-stateless-4v6-motivation]. Solutions such as 149 a 4rd [I-D.despres-softwire-4rd], 150 [I-D.murakami-softwire-4v6-translation], and 151 [I-D.xli-behave-divi-pd], as well as dIVI [I-D.xli-behave-divi] offer 152 such stateless solutions, by using fully distributed NAPT44 153 functionality located on end user CPEs, which allows the network 154 operators' core to remain effectively stateless in terms of NAT44. 155 The solutions, collectively called Stateless4V6, rely on the same 156 IPv4 address being used by multiple CPEs, each with a different TCP/ 157 UDP port range, and are derived from the Address+Port (A+P) solution 158 space [I-D.ymbk-aplusp]. Differences between the solutions come down 159 to the mode of transport (translation or mapped tunneling), and the 160 mapping algorithm used. This document looks at the issues that have 161 been claimed as applying to A+P technology, in the specific context 162 of the referenced solutions, and also analyzes the two modes of 163 transport. 165 2. Terminology 167 Stateless4V6 domain: A domain is composed out of an arbitrary number 168 of 4V6 CE and Gateway nodes that share a mapping relationship 169 between an operator assigned IPv6 prefix and one or more IPv4 170 subnets along with all the applicable TCP/UDP ports, all mapped 171 into the IPv6 address space. An 4V6 system can have multiple 172 domains. 174 Stateless4V6 CE: A CPE node that implements 4V6 functionality 175 including NAPT44 which is provisioned by means of 4V6. The device 176 interfaces to the SP network using native IPv6 and a IPv4-IPv6 177 adaptation service. 179 Stateless4V6 Gateway A Service Provider node that implements the 180 stateless 46 adaptation functionality for interfacing between the 181 SP's IPv6 domain and an IPv4 domain in delivering end user IPv4 182 connectivity beyond the domain. 184 IPv4 Address sharing The notion of attributing the same IPv4 address 185 by multiple CEs in an 4V6 domain. 187 Port-set: A set composed of unique TCP/UDP ports (ranges) associated 188 to a IPv4 address. A single 4V6 CE is expected to have a single 189 port-set for each IPv4 address. 191 Port-set-id: A numeric identifier of a given port set that is unique 192 in a given 4V6 domain. A port-set-id is used to algorithmically 193 determine the port-set members. The port-set-id is conveyed to 194 CEs as part the CE's IPv6 addressing information, ie it is part of 195 IPv6 subnet or address of a given CE, and its format places no 196 restriction on the use of SLAAC or DHCP addressing. 198 CE-index: A numeric value, composed of a full or partial IPv4 199 address and optionally a port-set-id, which uniquely identifies a 200 given CE in an 4V6 domain. 202 3. Stateless 4V6 Technical and Architectual Overview 204 This section presents the architectural and technical overview of a 205 stateless 46 solution, and evidenced in whole or in part by various 206 stateless 4via6 solution proposals such as 4rd, dIVI. Figure 1 207 depicts the overall architecture with two IPv4 user networks 208 connected via 4via6 CPEs that share an IPv4 address. The goal of the 209 system is to allow IPv4 user connectivity to the Public IPv4 network, 210 across an operator's IPv6 network. 212 A key characteristic of the system, and a major differentiator with 213 respect to previous solutions, is that translation state is only 214 (ever) present on the CE, with the rest of the system performing 215 stateless transport. This stateless transport applies to both the 216 mapped-tunnel and translated modes, as described in the dedicated 217 sections. 219 User 1 220 Private IPv4 221 | Network 222 | 223 O--+---------------O 224 | | 4V6 CE | 225 | +-----+--------+ | 226 | NAPT44| IPv6 | `-. 227 | +-----+ Adptn | | -._ ,-------. ------. 228 | +--------+ | ,-' `-. ,-' `-. 229 O------------------O / Routed \ O---------O / Public \ 230 / IPv6 \ |Stateless|/ IPv4 \ 231 ( Network --+ 6V4 +- Network ) 232 \ / | Gateway |\ / 233 O------------------O \ / O---------O \ / 234 | 4V6 CE | ;". ,-' `-. ,-' 235 | +-----+--------+ | ," `-------' ------' 236 | NAPT44| IPv6 | ," 237 | +-----+ Adptn | | 238 | | +--------+ | 239 O---.--------------O 240 | 241 User 2 242 Private IPv4 243 Network 244 Figure 1 - Generalized Stateless 4V6 system 246 On IPv4 network user side, the routed IPv6 service provider network 247 is demarcated with a 4V6 CE. The CPE externally has only a native 248 IPv6 interface to the SP network, and a native IPv4 interface towards 249 the end user network. 251 The IPv4 Internet is demarcated from the operator IPv6 network with 252 one or more operator managed stateless 6V4 gateways that contain an 253 IPv6 adaptation function (not detailed in the diagram) matching the 254 one in the CE. Note: The stateless 6v4 gateway can be integrated 255 into any existing network element (eg a core router, or an IP Edge). 257 Internally, the 4V6 CE is modelled as having a port restricted NAPT44 258 function coupled with a stateless IPv6 adaptation function that is 259 able to ferry the end-user's IPv4 traffic across the IPv6 network, 260 besides deriving 4V6 provisioning info from it. The NAPT44 function 261 derives its IPv4 address, which may be shared with that of other 262 users, and its unique Layer 4 (TCP/UDP) port range from the IPv6 263 address/prefix by means of an 4V6 algorithm and a port indexing 264 schema. Any IPv4 ALG functionality that the CPE may support, remain 265 unaffected. The CPE is expected to act as a DNS resolver proxy, 266 using native DNS over IPv6 to the SP network. 268 Two forms of the IPv6 adapatation function are: i) 4v6 stateless 269 tunneling ii) 4v6 stateless translation, each described in further in 270 this document. 272 The service provider is assumed to be operating all the necessary 273 provisioning and accounting infrastructure to support a regular IPv6 274 deployment. Similarly, the network operator is assumed to have the 275 ability to assign an IPv6 prefix or IPv6 address to a CPE, and log 276 such an address assignment. 278 End user host's DO NOT implement any of the 4V6, or other address 279 sharing technologies, nor are they addressed directly with a shared 280 IPv4 address. End user IPv4 hosts connected to the CPE receive 281 unique private addresses assigned by the CPE, and it is the CPE that 282 is directly addressed by the shared IPv4 address. 284 Although tangential to the discussion of stateless 4V6, it is useful 285 to note that the CPE is expected to have a native IPv6 interface to 286 the end user network, with any of the end user IPv6 hosts (single or 287 dual stack) receiving IPv6 addresses from an IPv6 delegated prefix 288 issued to the CPE. 290 3.1. IPv4 address and algorithmic port indexing 292 At the heart of the 4V6 solution, irrespective of mode of transport, 293 lies the algorithm described in the specific solution drafts that 294 allows the mapping of a shared IPv4 address and a TCP/UDP given port- 295 set to a single IPv6 prefix or address. Notably, the 4V6 system 296 allows both the shared IPv4 address use, as well as full non-shared 297 IPv4 address use, all subject to the 4V6 domain configuration. 299 The S46 domain information required to compute the IPv4 address and 300 correct port set is retrieved from the 4V6 prefix advertised to the 301 CE, and pre-configured or statelessly acquired domain information. 303 3.2. 4V6 CE IPv6 Address and domain info 305 As presented in Section 2, IPv6 address of an 4V6 CE is composed out 306 of the SP advertised IPv6 4V6 prefix, containing the CE-index, and an 307 algorithmically computed appendix to complete the 128-bit address. 308 This IPv6 address is *in addition* to any other IPv6 interface 309 address that the CE configures or is configured with, including a 310 SLAAC address from the 4V6 prefix or any IPv6 address source. One 311 characteristics of the resulting IPv6 prefix or address is that it is 312 for all intents and purposes a regular IPv6 prefix address that can 313 be assigned to any regular IPv6 host. 315 The IPv6 4V6 interface is reserved for the 4V6 application and the 316 4V6 IPv6 adaptation function will exclusively use this IPv6 address. 317 This is because the 4V6 system supports stateless communication 318 between the 4V6 CE and the 4V6 gateway only by means of packets sent 319 to/from this address. 321 3.3. IPv6 Adaptation Function 323 The IPv6 adaptation function plays a key role in the 4V6 system, in 324 statelessly allowing the IPv4 user payload to be transported across 325 an IPv6 (only) network. Two modes of such a function are currently 326 proposed and presented in the following subsections 328 3.3.1. 4V6 Stateless Tunneling Mode 330 This type of IPv6 adaptation function is adopted and described in 331 [I-D.despres-softwire-4rd]. 333 The 4V6 gateway operates in the IPv4->IPv6 direction by mapping all 334 or part of the IPv4 destination address and the port Index derived 335 from the UDP/TCP payload into an IPv6 CE destination address. The 336 resulting packet is sent using IPv4inIPv6 encapsulation to the CE, 337 sourced from the 4V6's gateway IPv6 address, where the original IPv4 338 packet is extracted and passed to the stateful NAPT44 function. 340 The 4V6 CE operates in the IPv4->IPv6 direction, for traffic bound to 341 the IPv4 internet, by encapsulating the IPv4 packet in an IPv6 header 342 using IPv4inIPv6 encapsulation, and sending the resulting packet to 343 the (well known) unicast address of the 4V6 gateway. There the IPv4 344 packet is extracted and forwarded. 346 The the original IPv4 packet addressing information is only partially 347 visible on the IPv6 data plane, and the original Layer 4 information 348 is only visible as part of the encapsulated IPv4 payload packet. 350 The figure below illustrates the CE model of a 4v6 Mapped Tunnel 351 mode. 353 +......................+ 354 : : 355 : stateful stateless : 356 [IPv4-LAN]-----:-[NAPT44]---[v4-v6]---:---- 357 : [ tunn] : 358 : : 359 : : 360 +......................+ 361 Figure 2 - 4v6 CE model with Tunnel mode 363 3.3.2. 4V6 Stateless Translation mode 365 This type of IPv6 adaptation function is adopted and described in 366 [I-D.murakami-softwire-4v6-translation], I-D.xli-behave-divi-pd, 367 and[I-D.xli-behave-divi] The 4V6 translation mode transport operates 368 by means of stateless NAT46 [RFC6145] extended to map the the TCP/UDP 369 port index algorithmically derived from received IPv4 packets into an 370 IPv6 address suffix, in the IPv6 header, besides the full IPv4 mapped 371 representation of the original IPv4 address information. The 372 resulting packet is then sent across the IPv6 domain as an IPv6 373 packet - this IPv6 packet, besides mapping the original original IPv4 374 address information into a determinate IPv6 format, also places the 375 Layer 4 and packet content directly after the IPv6 header, as any 376 regular IPv6 with TCP/UDP packet. This IPv6 packet is thus capable 377 of being processed by regular IPv6 network elements or servers in the 378 IPv6 domain. At either end of the IPv6 domain, the IPv4 packet 379 header is statelessly recreated, by the 4v6 CE or gateway, again 380 using exactly the same NAT64 process as in [RFC6145]. 382 The figure below illustrates the IPv6 4v6 Stateless Translation model 383 of a 4v6 CE. 385 +......................+ 386 : : 387 : stateful stateless : 388 [IPv4-LAN]-----:-[NAPT44]---[NAT46]---:---- 389 : : 390 : : 391 : : 392 +......................+ 393 Figure 3 - 4v6 CE model with stateless NAT64 395 4. Comparison of 4V6 transport modes 397 This section presents the an overview of the similarities and 398 differences between an IPv4-IPv6 translation based 4V6 transport mode 399 and one that utilizes IPv4-in-IPv6 tunnelling. The comparison takes 400 into consideration a wider deployment view composed of functionality 401 that is known to be in common use today. 403 4.1. General Characteristics of 4V6 modes 405 The following table presents a comparison of the 4V6 transport modes, 406 in terms of the base technology, and constrains, including also IPv4. 408 +------------------------+--------------------+---------------------+ 409 | Item | 4V6 Translation | 4V6 Tunnel Mode | 410 | | mode | | 411 +------------------------+--------------------+---------------------+ 412 | Base Technology | Port restricted | Port restricted | 413 | | NAPT44 with | NAPT44 with IPv4 in | 414 | | modified stateless | IPv6 mapped | 415 | | NAT64 on CPE and | tunneling on CPE | 416 | | Gateway | and Gateway | 417 | ------------------- | ------------------ | ------------------- | 418 | Location of stateful | CPE | CPE | 419 | NAPT44 function | | | 420 | ------------------- | ------------------ | ------------------- | 421 | IPv4 Forwarding | L3 + L4 lookup | L3 + L4 lookup | 422 | paradigm | | | 423 | ------------------- | ------------------ | ------------------- | 424 | IPv6 Addressing | CE uses 4V6 | CE uses 4V6 suffix. | 425 | Constraints | suffix. | | 426 | ------------------- | ------------------ | ------------------- | 427 | Type of IPv6 | ICMPv6 (SLAAC), | ICMPv6 (SLAAC), | 428 | prefix/address | DHCPv6 (both IA_NA | DHCPv6 (both IA_NA | 429 | announcement method | and IA_PD) | and IA_PD) | 430 | supported | | | 431 | ------------------ | ------------------ | ------------------ | 432 | Can the 4V6 IPv6 | Yes | Yes | 433 | prefix be used by non | | | 434 | 4V6 devices? | | | 435 | ------------------- | ------------------ | ------------------- | 436 | IPv4 addressing | Fixed sharing | Fixed sharing ratio | 437 | constraints | ratio per IPv4 | per IPv4 address. | 438 | | address. | | 439 | ------------------ | ------------------ | ------------------ | 440 | TCP/UDP Port range | Ports are | Ports are | 441 | constraint | statically | statically | 442 | | allocated | allocated | 443 | ------------------ | ------------------ | ------------------ | 444 | Requires ALG64 or | No | No | 445 | DNS64 | | | 446 | ------------------ | ------------------ | ------------------ | 447 | Requires IPv6 DNS on | Recommended | Recommended | 448 | CPE | | | 449 | ------------------ | ------------------ | ------------------ | 450 | 4V6 CE Parameter | ICMPv6, Stateless | ICMPv6, Stateless | 451 | provisioning methods | DHCPv6, TR69 | DHCPv6, TR69. | 452 | (assuming suitable | | | 453 | protocol extensions) | | | 454 | ------------------ | ------------------ | ------------------ | 455 | IPv6 Domain Routing to | Regular closest IP | Regular closest IP | 456 | CE based on: | match to CE-IPv6 | match to CE-IPv6 | 457 | | subnet | subnet | 458 | ------------------ | ------------------ | ------------------ | 459 | IPv6 Domain Routing to | IPv6 4V6 domain | 4V6 Gateway | 460 | 4V6 Gateway based on | aggregate route | unicast/anycast | 461 | | | address | 462 | ------------------ | ------------------ | ------------------ | 463 | IPv4 Header Checksum | Yes | No | 464 | recalculation required | | | 465 | ------------------ | ------------------ | ------------------ | 466 | Supports non TCP/UDP | No* | No* | 467 | Protocols | | | 468 | ------------------ | ------------------ | ------------------ | 469 | ICMPv4 Limitations | No ICMPv4 from | No ICMPv4 from | 470 | | "outside the | "outside the | 471 | | domain". Internal | domain". | 472 | | ICMPv4-v6 | | 473 | | translation as per | | 474 | | [RFC6145] | | 475 | ------------------ | ------------------ | ------------------ | 476 | ICMPv5 identifier | Yes | Yes | 477 | NAT/Markup needed | | | 478 | ------------------ | ------------------ | ------------------ | 479 | Supports IPv4 | No | No | 480 | fragmentation (without | | | 481 | additional state) | | | 482 | ------------------ | ------------------ | ------------------ | 483 | Requires IPv6 PMTU | Yes | Yes | 484 | discovery/configuratio | | | 485 | n | | | 486 | ------------------ | ------------------ | ------------------ | 487 | Supports IPv4 Header | No - as per NAT64 | Yes (use of source | 488 | Options | [RFC6145] | route option is | 489 | | | constrained) | 490 | ------------------ | ------------------ | ------------------ | 491 | TCP/UDP Checksum | Yes - depending on | No | 492 | recalculation | suffix, as per | | 493 | | NAT64 [RFC6145] | | 494 | ------------------ | ------------------ | ------------------ | 495 | Supports UDP null | Yes/Configurable - | Yes | 496 | checksum | as per NAT64 | | 497 | | [RFC6145] | | 498 | ------------------ | ------------------ | ------------------ | 499 | Transparency to DF bit | Yes, configurable | Yes | 500 | | as per [RFC6145] | | 501 | ------------------ | ------------------ | ------------------ | 502 | Supports IPv4 | Partial (no | Partial (no | 503 | Fragmentation | fragments from | fragments from | 504 | | outside the | outside the domain) | 505 | | domain) | | 506 | ------------------ | ------------------ | ------------------ | 507 | Transparency to IPv4 | Yes, configurable | Yes | 508 | TOS | as per [RFC6145] | | 509 | ------------------ | ------------------ | ------------------ | 510 | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% | 511 | to original average | | | 512 | payload on IPv6 of a) | | | 513 | ~550 bytes b) 1400 | | | 514 | bytes). | | | 515 | ------------------ | ------------------ | ------------------ | 516 | Supports non-shared | Yes | Yes | 517 | IPv4 usage (ie whole | | | 518 | IPv4 address | | | 519 | assignment to a single | | | 520 | device) | | | 521 | ------------------ | ------------------ | ------------------ | 522 | Can support IPv4 to | Yes - As per | No | 523 | IPv6 host | [RFC6145] | | 524 | communication (for | stateless NAT64 | | 525 | traffic not requiring | specification | | 526 | ALGs) | | | 527 | ------------------ | ------------------ | ------------------ | 528 | Changes to network | Yes - Mapping IPv4 | Yes - Enabling | 529 | element provisioning | to IPv6 addresses | IPv4inIPv6 | 530 | tool(s)** | | functionality | 531 +------------------------+--------------------+---------------------+ 533 * Without specific ALGs. Non UDP/TCP protocols, like ICMP, can be 534 supported with specific ALGs. 536 **Network (feature) provisioning tools/applications need to be 4V6 537 aware. With the translation technique, the tool needs to enable the 538 operator to map IPv4 addresses to IPv6 addresses as disctated by the 539 4V6 domain. With the tunneling technique, the tool needs to allow 540 the operator to enable IPv4 (inIPv6) functionality and modify its 541 characterstics. 543 4.2. Mobile SP Architecture and 4V6 Applicability 545 This section presents the applicability and comparison of the 4V6 546 modes to current 3GPP architectures used by Mobile SP for delivering 547 all sorts of mobile services. 549 4.2.1. 3GPP overview 551 The 3rd Generation Partnership Project (3GPP) is a collaboration 552 between groups of telecommunications associations, whose scope is to 553 develop a globally applicable mobile phone systems and architectures 554 based on service requirements. 3GPP standards are structured as 555 Releases, each of which incorporates numerous individual standard 556 documents. Currently, 3GPP Release 7 is the latest release in common 557 practical deployment, with Release 8 being readied for deployment. 558 Releases 9 and 10 are finalized, and work is underway on Release 11. 560 One of the major service requirement drivers of recent and ongoing 561 3GPP releases is the realization of services that deliver specific 562 QoS, or user charging goals, all based on a policy system (eg tiered 563 data rate or volume plans). Technically this translates to the 564 Policy and Charging Control (PCC) framework, which in turn attributes 565 specific functionality to nodes in the 3GPP architecture, such as the 566 PDN-Gw and the PCRF. This functionality comprises both data-plane 567 features (eg IP flow classification) as well as the interfaces/ 568 protocols between nodes (eg Diameter, and its specific 3GPP 569 applications). 571 The 3GPP specifications allow both IPv4 and IPv6 traffic to be 572 handled, and subject to operator defined handling and charging 573 polices by means of applying suitable user traffic filters. Such 574 filters are currently defined to be either IPv4 or IPv6, are 575 applicable to user plane traffic, and are used in a variety of 576 critical roles including the signalling of PDP contexts/EPC Bearers, 577 as well as PCC signalling and interaction with applications. 579 The following table illustrates the impact of the 4V6 translation and 580 tunnel transport modes respectively on the 3GPP architecture 581 including PCC interfaces. In assessing the impact of these 4V6 582 transport modes a number of additional assumptions are taken: 584 o The 3GPP system supports native IPv6 user traffic, as say per 585 either of the E-UTRAN Release 8 or 9 specifications, using the 586 relevant EPS bearer or PDP functionality. 588 o The 4V6 gateway functionality is not part of the 3GPP core 589 architecture (given that currently it is not scoped by a 3GPP 590 Release). Instead, the 4V6 gateway is taken to be a stand alone 591 component in the 3GPP network operator's core reachable via the 592 SGi interface. 594 The above system, in the context of 3GPPs E-UTRAN architecture as 595 defined in [E-UTRAN] is shown in Figure 2 596 +----------+ 597 | | ,---. 598 | AF | / \ 599 | | / IPv4 \ 600 +----+-----+ ( Internet) 601 | \ / 602 Rx | \ / 603 ,---. | `-+-' 604 / \ +----+-----+ | 605 / \ | | +----+-----+ 606 ; User : +-------+ | PCRF | | | 607 | Home | | | | | | S64 | 608 : Network ; | MME | +----+-----+ | Gateway | 609 \ / | | Gx | +----+-----+ 610 \ / +-+----++ | | 611 `-+-' S1-MME / \ S11 +----+-----+ ,--+--. 612 | ,-/ `. | | ,' `. 613 +---+---+ ,' `.S1-u +--+----+ | | / IP \ 614 | UE +---- -----+ +------+ PDN-Gw +---- Transport ) 615 | w/ 4V6| |E-UTRAN| | S-Gw | | | \ / 616 | CE | : ; | | S5 | | SGi `. ,' 617 +-------+ `. ,' +-------+ | | '-----' 618 LTE-Uu `-' +----------+ 620 Figure 2 - 3GPP Architecture with 4V6 622 The main 3GPP system components, and terms are summarized as follows 623 (the reader is referred to [E-UTRAN for a more detailed definition]: 625 UE The User Equipment, typically a phone or a 3G/4G capable Home 626 Router (shown to incorporate 4V6 functionality) 628 E-UTRAN Evolved Universal Terrestrial Radio Access Network. The 629 Radio Access network, composed on E-NodeB elements. 631 MME Mobility Management Entity. Responsible for user 632 authentication, PDN/SGw selection. Does not interact with the 633 user data plane 635 S-Gw Serving Gateway (function). Responsible for handling local 636 mobility, (some) traffic accounting, traffic forwarding, bearer 637 establishment. 639 PDN-Gw Packet Data Network Gateway (function). Responsible for per 640 user IP traffic handling, incl. address assignment, filtering, 641 QoS, accounting. 643 PCRF Policy And Charging Rules Function. Responsible for 644 authorizing and applying policy rules, as well as binding them to 645 user bearers. 647 Bearer The bearer represents a virtual connection, typically that 648 between a UE and a PDN-Gw. The bearer is specified as an IP 649 Fliter (in terms of IP address, port numbers) and is the object of 650 policy rules. 3GPP, depending on Release and document, defines 651 many terms that are used to refer to the same notion: PDP context, 652 EPS Bearer. 654 AF Application Function. A functional element offering (higher 655 level) applications that require dynamic policy and/or charging 656 control over the user plane (bearer) behaviour. The AF can be 657 seen as bridging the gap between applications and how they affect 658 the IP data plane of a user. 660 S5 It provides user plane tunnelling and tunnel management between 661 SGW and PDN-GW, using GTP or PMIPv6 as the network based mobility 662 management protocol. 664 S1-u Provides user plane tunnelling and inter eNodeB path switching 665 during handover between eNodeB and SGW, using the GTP-U protocol 667 SGi It is the interface between the PDN-GW and the packet data 668 network. Packet data network may be an operator external public 669 or private packet data network or an intra operator packet data 670 network. 672 Gx Bearer and flow control interface between the user data-plane 673 element (PDN-Gw) and the Policy System. A Diameter based 674 interface with a suite of 3GPP applications 676 4.2.2. 3GPP and 4V6 modes 678 4V6 translated traffic appears for all intents and purposes as 679 regular IPv6-user traffic to the 3GPP system and packet processing 680 functions (eg the PDN-Gw). Hence, and based on the stated 681 assumptions, any such 4V6 traffic can be handled using existing 682 native IPv6 functionality defined by the core 3GPP specifications. 684 In contrast, 4V6 tunneled traffic requires additional data plane 685 processing to get to the "real" user IPv4 payload and apply the 686 desired functions. Such additional processing is currently not part 687 of the functionality covered by the 3GPP specifications. In view of 688 this, and solely in relation to the 4V6 tunnel transport mode, two 689 alternative hypotheses need to be placed in order to complete the 690 comparison 691 i) that such IPv4 in IPv6 processing functionality will be supported 692 as part of the existing EPS bearer functionality defined in E-UTRAN, 693 perhaps as a dedicated EPS bearer (ie an additional virtual interface 694 per subscriber). Or, that; 696 ii) a new 46 EPS bearer type (ie interface type) identification and 697 signalling will be defined by the 3GPP architecture, which formalizes 698 the v4inv6 relationship between the IPv4-user payload and the v6-user 699 layers. 701 An apparent benefit of approach (ii) would be in allowing the system 702 to clearly distinguish and expose to other systems v4-user traffic 703 versus v6-user traffic, which is composed of v4inv6 and regular v6 704 traffic that a UE may generate. The former approach (i) is more 705 convoluted given the ambiguity in distinguishing, and representing 706 such a combination of v6-user and v6-user-bearer and v4-user traffic, 707 all while keeping coherence in terms of the policy system. These two 708 options are designated with ** in the table below. 710 +--------------------+----------------+-----------------------------+ 711 | Item | 4V6 | 4V6 Mapped Tunnel Mode | 712 | | Translation | | 713 | | Mode | | 714 +--------------------+----------------+-----------------------------+ 715 | User Data Plane at | IPv6 over | IPv4 over IPv6 over GTP-U | 716 | the PDN-Gw (as per | GTP-U over UDP | over UDP over IP | 717 | section 5.1.2 in | over IP | | 718 | [EUTRAN]) | | | 719 | ------------------ | ----------- | ------------------ | 720 | Gx (Diameter) | No discernible | Impacted: no way to express | 721 | | impact | v4 over v6 in TFT Filter | 722 | | | and Flow Descriptors | 723 | ------------------ | ----------- | ------------------ | 724 | Rx (Diameter) | No discernible | Impacted: no way to express | 725 | | impact | v4 over v6 in | 726 | | | Media-Component-Description | 727 | | | and, Flow-Description-AVP | 728 | ------------------ | ----------- | ------------------ | 729 | S5 (GTP) | No impact | Impacted with new PDP/EPS | 730 | | | Bearer type* | 731 | ------------------ | ----------- | ------------------ | 732 | New 46 Bearer | Not required | Possibly required** | 733 | definition | | | 734 | ------------------ | ----------- | ------------------ | 735 | Secondary | Not required | Possibly required** | 736 | interface | | | 737 | (dedicated bearer | | | 738 | or secondary PDP) | | | 739 | for 46 traffic | | | 740 | ------------------ | ----------- | ------------------ | 741 | PDN-Gw | No impact | New TFT capability, IP Gate | 742 | | | functionality, changes to | 743 | | | Gx, and likely changes to | 744 | | | S5/S7 related to signalling | 745 | | | the new bearer | 746 | ------------------ | ----------- | ------------------ | 747 | SGw | No Impact | No discernible impact | 748 | ------------------ | ----------- | ------------------ | 749 | PCRF | No impact for | Impacted for both IPv6 and | 750 | | IPv6. Feature | IPv4-only applications and | 751 | | to map | Gx applications utilizing | 752 | | IPv4-IPv6 | flow control/charging | 753 | | addresses | | 754 | | needed only in | | 755 | | case of | | 756 | | IPv4-only | | 757 | | applications. | | 758 | ------------------ | ----------- | ------------------ | 759 | AF Application | No discernible | Flow based application | 760 | Function | impact | control impacted | 761 | ------------------ | ----------- | ------------------ | 762 | UE | 4V6 | 4V6 application | 763 | | application | | 764 | ------------------ | ----------- | ------------------ | 765 | LTE-Uu | No discernible | Likely changes required to | 766 | | impact | support signalling of EPS | 767 | | | bearer or PDP type | 768 | ------------------ | ----------- | ------------------ | 769 | Lawful Intercept | No discernible | New rules for tunnel | 770 | | impact | support | 771 +--------------------+----------------+-----------------------------+ 773 *A new PDP Type or EPS bearer signalling has a broader 3GPP system 774 wide impact not fully covered here. 776 As the table illustrates, the 4V6 tunnel transport model appears to 777 affect a significant number of 3GPP elements, when the intent if 778 realize a full suite of services. This observation appears to apply 779 to any other carrier inserted tunneling technology (eg DS-lite). 780 Hence, a substantial investment in 3GPP standard terms and in the 781 evolution of deployed systems appears to be required. 783 In contrast the 4V6 translation mode bears none to no discernible 784 impact on existing 3GPP Release 8/9 specifications and their 785 deployments, while allowing the operator to realize the full set of 786 services on 4V6, alongside any native IPv6 traffic, allowed for by 787 these architecture. Hence, little beyond the addition of 4V6 788 components operating using translation mode appears to be required. 790 4.3. Cable SP Architectures & 4V6 Applicability 792 Cable SPs (commonly referred to as Multi System Operators (MSOs)) 793 usually deliver video, data, and voice service over the cable and 794 fiber access to residential and commercial customers. Many MSOs 795 offer SLAs with various services by exploiting QoS not only in their 796 IP/MPLS network, but also their access network. 798 The cable access network (now synonymous with Hybrid Fiber Coax 799 (HFC)) is commonly enabled with Data Over Cable Service Interface 800 Specifications (DOCSIS, a CableLabs standard) to facilitate the 801 implementation of packet based services. In this paradigm, the HFC/ 802 DOCSIS access bandwidth is typically shared among a number of 803 customers, hence, ensuring optimal service quality & experience per 804 customer becomes extremely important for MSOs' success. 806 Cable SPs/MSOs ensure the optimal service quality of various advanced 807 & real-time multimedia services (such as IP telephony, multimedia 808 conferencing, interactive gaming etc.) by utilizing "PacketCable" 809 framework to enforce QoS on the HFC/DOCSIS access. 811 The next sub-section 4.3.1 provides a brief introduction to 812 PacketCable, section 4.3.2 explains a key PacketCable construct - 813 Classifier, and section 4.3.3 tabulates the impact of 4V6 modes to 814 PacketCable enabled DOCSIS/IP services. 816 4.3.1. PacketCable Introduction 818 PacketCable,a CableLabs standard, defines a framework for ensuring 819 the Quality of Service (QoS) on the HFC/DOCSIS Access. PacketCable 820 specifications (e.g. PacketCable 1.0, PacketCable Multi Media 821 [PCMM], PacketCable Dynamic QoS [PC-DQOS], PacketCable 2.0) specify 822 interoperable interface specifications for executing QoS, Admission 823 Control, Accounting, Policy, and Security functions on Cable Modem 824 (CM) and Cable Modem Termination System (CMTS), as/when needed. They 825 all require DOCSIS 1.1 or later versions. 827 The PacketCable framework is also critically important for MSOs to 828 comply with government regulations for things such as E911 when they 829 offer voice/telephony services, Lawful Intercept (LI) etc. 831 The figure below illustrates one of PacketCable variants i.e. PCMM 832 [PCMM] architecture, as an example, that defines a set of IP-based 833 interfaces (referred to as pkt-mm-1 through 12) pertaining to core 834 QoS and policy management capabilities. 836 +------------+ +---------------+ 837 | Application+-----------+ Application | 838 | Server | pkt-mm-11 | Manager | 839 +-------+----+ +-+--------+----+ 840 ,------| | | pkt-mm-3 841 /,-------------------------+ | 842 // +--+---+ +-------+ 843 pkt-mm-12 // pkt-mm-7 | | |Record | 844 // |Policy+----------+Keeping| 845 // |Server| pkt-mm-4 |Server | 846 // +--+---+ ++------+ 847 // | | 848 // | ,------------+ 849 // pkt-mm-2| / pkt-mm-5 850 // || 851 // || ,--+--. 852 // +---++--+ +-------+ +--++--+ ,' `. +--------+ 853 Clients } | CPE | | Cable | pkt-mm-1 | | / \ | 4V6 | 854 In User }--+ Router+---+ Modem +----DOCSIS------+ CMTS +-----( IP )--+ Gateway| 855 Network } | w/ 4V6| | | | | \ Network / |Boundary| 856 +-------+ +-------+ +------+ `. ,' | Router | 857 '-----' +--+-----+ 858 \~~~~~~~~~~~~~~~~~~~~~/ | 859 A typical Residential | 860 Gateway includes both ,-+--. 861 CPE & CM functions / \ 862 / IPv4/6 \ 863 ( Internet ) 864 \ / 865 \ / 866 * PCMM spec marks these out-of-scope: `----' 867 mm-7, mm-8, mm-9, mm-10, mm-12 868 * PCMM spec does not define/describe 869 4V6 Gateway/Boundary Router, or Internet 871 Figure 3 - PacketCable Multimedia Architecture (with 4V6) 873 4.3.2. PacketCable Construct - Classifier 875 PacketCable framework fundamentally relies on Cable Modem (CM) and 876 Cable Modem Termination System (CMTS) to first qualify and then 877 classify the appropriate IP traffic between them, for effective QoS 878 enforcement. The framework requires the usage of "Classifier" for 879 both qualification (in control plane) and classification (in data 880 plane). 882 Taking PCMM specification [PCMM] again as an example, PCMM mandates 883 the usage of classifier in the control plane (i.e. 'Upstream Packet 884 Classification Encoding' in pkt-mm-1 interface (DOCSIS) , whereas 885 'Multimedia Classifier Object' in pkt-mm-2 and pkt-mm-3 interfaces 886 (COPS)) for conveying the attributes of an IP flow belonging to an 887 application (telephony, say), and subsequently its usage in the data 888 plane i.e. filter matching on the IP packets' layer2/3/4 headers 889 prior to QoS treatment. 891 The PCMM specification mandates the 'classifier' to include Source 892 and Destination IP addresses, DSCP/TOS, IP Protocol, Source and 893 Destination ports for an IPv4 traffic flow received by the CMTS, and 894 similarly, Source and Destination IP addresses, TC, Next Header, 895 Source and Destination ports for an IPv6 traffic flow received by the 896 CMTS. 898 Similar to PCMM, PacketCable DQOS specification [PC-DQOS] also 899 mandates the usage of classifier in the control plane (DSx 900 messaging). In particular, PC-DQOS mandates the classifier 901 definition to have 'protocol' (or next header) in IP header to be 17 902 (=UDP) along with specific Source and Destination ports (and Source 903 and Destination IP addresses, optionally) so as to accommodate voice 904 RTPoUDPoIP traffic. 906 In summary, the CMTS (and CM) construct their data-plane filter based 907 on the 'classifier' information. 909 4.3.3. 4V6 Modes Impact on PacketCable 911 In 4V6 Tunnel mode, the 4V6 tunneled traffic requires additional data 912 plane processing to get to the "real" user IPv4 payload and apply the 913 desired functions. Such additional processing is currently not part 914 of the functionality covered by the PacketCable specifications, nor 915 part of compliant implementations. 917 In 4V6 Translation Mode, the 4V6 translated traffic appears for all 918 intents and purposes as regular IPv6-user traffic to the PacketCable 919 framework (both control plane and data plane). Hence, it is likely 920 that any such 4V6 traffic can be handled using native IPv6 921 functionality e.g. classifier as defined by the PacketCable 922 specifications and supported by CMTS and CM. 924 Taking PCMM specification as an example, it is worth noting that PCMM 925 already allows for (and mandates) a minimum of four classifiers to be 926 included in Gate-set. Hence, a Policy Server can communicate (via 927 pkt-mm-2) both IPv4 and IPv6 classifier to the CMTS, which can use 928 IPv6 classifier for constructing its data-plane filters (for 929 DownStream processing), and convey IPv4 classifier to the CM via 930 DOCSIS messages (pkt-mm-1) for any Upstream Processing. So, the 4V6 931 Translation Mode would work out in current implementations/deployment 932 reasonably well. 934 Separately, it is likely that the CPE Router would be engaged in 935 serving IPv4 multicast content to IPv6 receivers (and vice versa) in 936 future, requiring 'translation' function. 938 In summary, while 4V6 Translation mode can work with the existing 939 PacketCable framework, 4V6 Tunnel mode can not. 941 5. Overview of potential issues and discussion 943 This section summarizes the issues attributed to an A+P, or port 944 restricted scheme, along with a discussion of applicability to the 945 assumed system and possible resolutions. The summary of issues stem 946 from [I-D.thaler-port-restricted-ip-issues] and associated 947 discussions. 949 5.1. Notion of Unicast Address 951 5.1.1. Overview 953 The issue, referred to as the "definition of a unicast address", 954 relates to the notion that in a shared IPv4 address system, multiple 955 hosts will be visible as having a single IPv4 address outside of the 956 system. This issue is a general characteristic of any NAPT44 based 957 solution [I-D.ietf-intarea-shared-addressing-issues], including DS- 958 Lite. However, a more specific aspect of this issue in the context 959 of an address sharing system is the possibility that a single host 960 having multiple interfaces will be assigned the same IPv4 address 961 (with different port ranges) on each of its interfaces. It may also 962 be that multiple hosts sharing an address find themselves on the same 963 Layer 2 segment. Either would impede hosts from working within the 964 notion of known host IP stack and protocol implementations. 966 5.1.2. Discussion 968 A number of the characteristics of the 4via6 solution architecture 969 cause the issues not to be applicable, key of which is that there is 970 no expectation for any kind of end hosts to be part of the shared 971 IPv4 address system. 973 In the stateless 4via6 system, CPE nodes are assigned with a shared 974 IPv4 address+port range by means of the unique IPv6 address, 975 containing the embedded IPv4 address + port index, of that CPE node. 976 The CPE node is in addition enabled to be running the port restricted 977 NAPT44 function from the IPv6 derived address, a key characteristic 978 of the solution. On the IPv6 plane, the IPv6 address of the CPE is 979 practically indistinguishable from any "regular" IPv6 address, and in 980 fact any host that is not aware of it conveying an embedded IPv4 981 address would be able to use this just like any other regular IPv6 982 address, ie the 4via6 solution uses standard IPv6 addressing. In 983 terms of the IPv4 dimension, since the shared address and port index 984 are never used to address native IPv4 nodes or hosts, but instead 985 uniquely assigned to a single NAPT44 function that is part of the 986 CPEs, all legacy or other IPv4 hosts are not exposed to the presented 987 issues. 989 Going beyond the ascribed issue however, it appears desirable to have 990 the 4via6 CPEs that are to be part of the shared system to be able to 991 provide a hint to the network operator in terms of their special 992 capability. Such a hint can be a DHCPv6 Option Request Option, which 993 would be useful to allow the DHCPv6 sub-system to also inform the CPE 994 of any other stateless 4via6 system parameters. A largely similar 995 ORO option is currently being defined as part of 996 [I-D.ietf-softwire-ds-lite-tunnel-option] 998 Recommendation: Define a suitable DHCPv6 ORO for conveying the 4via6 999 capability of a CPE. 1001 5.2. Implementation on hosts 1003 5.2.1. Overview 1005 The issue, as presented, relates to the need for modifications on end 1006 hosts or devices to support a port constrained mechanism and the 1007 overall impossibility of realizing such modifications. Furthermore, 1008 host applications that attempt to bind to specific ports that are not 1009 part of the allowed port range will fail to do so and may also 1010 require modifications. 1012 5.2.2. Discussion 1014 As presented in Section 3 the solution assumes the use of a dedicated 1015 CPE implementing the 4via6 functionality within a port constrained 1016 mode and NAPT44. Granted, CPE nodes will require to implement new 1017 functionality such as the IPv6 adaptation function, that is likely 1018 alongside introducing native IPv6 support. However, any and all 1019 existing end user IPv4 devices (eg PCs, etc) will not affected. Nor 1020 are such devices expected to behave in any way different from that of 1021 today, where they typically obtain a private rfc1918 address and 1022 multiplexed by a CPE using a NAPT44 function. 1024 In summary, the assumed 4via6 solution requires a specific 4via6 CPE 1025 but does not require any IPv4 host stack changes. 1027 5.3. 4V6 address and impact on other IPv6 hosts 1029 5.3.1. Overview 1031 The issue relates to the question of whether the operation of a 1032 regular IPv6, non 4V6 capable, host would be adversely impacted 1033 should it be assigned or auto-configured with an address from an S64 1034 address or prefix pool. 1036 5.3.2. Discussion 1038 The 4V6 prefix is for all intents and purposes a regular IPv6 prefix, 1039 and as such can be announced/assigned to any IPv6 host which in turn 1040 can used derived addresses like any other IPv6 address. Thus, an 4V6 1041 IPv6 domain can address non-4V6 devices, leaving such devices to 1042 operate as native IPv6. 1044 There is however a restriction on the 4V6 CE devices. As described 1045 in Section 2, a 4V6 CE constructs itself the full 128 bit address 1046 from the concatenation of the IPv6 prefix, 4V6 domain information 1047 acquired statelessly, and a pre-determined or algorithmic 1048 interface-id. By definition, only one 4V6 CE can use the same IPv4 1049 address and port index. Hence, while there is no exact limitation on 1050 the number of non 4V6 hosts that can be addressed from an 4V6 prefix, 1051 there is a limit of one 4V6 CE per 4V6 prefix. Using a 4V6 prefix to 1052 address network segments without 4V6 devices does diminish the 1053 efficiency of the IPv4 address sharing mechanism, in terms of using 1054 up port ranges onto segments that will not use them. This is 1055 naturally a deployment consideration which an operator can optimize. 1057 5.4. Impact on 4V6 CE based applications 1059 5.4.1. Overview 1061 It has been claimed that applications implemented on the CE itself, 1062 eg a DNS resolver-client, may be impacted by the 4V6 functionality. 1063 In particular, a concern is that such applications would either need 1064 to be specially engineered to issue socket calls or extensive IP 1065 stack modifications made to support them. 1067 5.4.2. Discussion 1069 By definition the 4V6 CE is an IPv6 capable device, and any IPv6 1070 capable applications will be able to use the native IPv6 stack (note: 1071 IPv6 interface selection, is discussed in section 5.5). As such, the 1072 concern raised does not apply to applications that can be expected to 1073 support IPv6, and instead only to IPv4-only applications running on 1074 the 4V6 CE. 1076 The shared IPv4 address is intended to be used only by the 4V6 CE 1077 function. This shared IPv4 address does not need to be assigned to 1078 an interface on the 4V6 CE and thus a target for potential 1079 applications. Any such applications running on the 4V6 will use any 1080 of the other (likely private) IPv4 address on the CE, which then will 1081 be routed to the 4V6 function this is applied post routing for the 1082 packets generated by these applications. 1084 5.5. 4V6 interface 1086 5.5.1. Overview 1088 A 4V6 CE will have a "self configured" 4V6 IPv6 interface address, 1089 alongside any other SLAAC or DHCPv6 derived addresses, potentially 1090 from the same prefix. This particular 4V6 address may be subject to 1091 specific filtering rules or restrictions by the operator, besides 1092 usage and filtering restrictions on the 4V6 CE. Also, for the 4V6 1093 system to operate as intended, the 4V6 application on the CE must be 1094 restricted to using the specific 4V6 address when sourcing 4V6 1095 packets. Also, the 4V6 CE needs to be set-up to correctly forward 1096 IPv4 traffic to the 4V6 application. 1098 5.5.2. Discussion 1100 While the method of creating the interface is implementation 1101 specific, the generic operating model that is envisaged is for the 1102 4V6 application to create the 4V6 interface as a virtual interface 1103 with an IPv4 unnumbered address. The application would then install 1104 a default IPv4 route pointing to this virtual interface, which would 1105 be effectively see the 4V6 application acting as a network appliance 1106 on the forwarded traffic. In terms of IPv6 behaviour, the 4V6 1107 application is expected to be set up to specify the use (binding) to 1108 the 4v6 IPv6 virtual interface. 1110 5.6. Non TCP/UDP port based IP protocols - ICMP) 1112 5.6.1. Overview 1114 This issue relates to the inability of using regular ICMP messages to 1115 "ping" an end-host that has been addressed with a shared IPv4 1116 address. The issue can be generalized one applicable to any IP 1117 protocol that is not TCP/UDP port based, and also in terms of the 1118 ability of using such protocols from end hosts that are assigned a 1119 shared IPv4 address. 1121 5.6.2. Discussion 1123 The inability to ping a CPE from the IPv4 Internet is shared by other 1124 IPv4 address sharing mechanisms such as DS-Lite. Thus, the issue is 1125 no better or worse in the case of the stateless 4via6 solution. The 1126 same can be said of end user hosts using other non UDP/TCP port based 1127 protocols from behind a NAPT44 function, ie they will not function 1128 irrespective of address sharing or not. 1130 As discussed in [I-D.ietf-intarea-shared-addressing-issues], all IP 1131 address sharing solutions break protocols which do not use transport 1132 numbers. A mitigation solution is to utilize specific ALGs. For 1133 ICMP in particular, a mitigation solution would be to rewrite the 1134 "Identifier" and perhaps "Sequence Number" fields in the ICMP 1135 request, treating them as if they were port numbers. 1137 As a conclusion, this issue can be partially mitigated, likely at par 1138 to centralized NAT solutions. 1140 5.7. Provisioning and Operational Systems 1142 5.7.1. Overview 1144 The general claim of this issue is that a service providers' 1145 provisioning and accounting systems would need to [radically] evolve 1146 to deal with the notions of shared IPv4 addresses and port range 1147 constrains. 1149 5.7.2. Discussion 1151 The stateless 4via6 solution relies on a fully operational IPv6 1152 network, which on the IPv6 plane fundamentally does not differ from a 1153 regular IPv6 network, and the stateless 4via6 solution may be seen as 1154 an IPv6 application - devices connecting to the network, need unique 1155 IPv6 addresses which the network is able to provide. In the 4via6 1156 solution it happens that these unique IPv6 addresses embed an IPv4 1157 address. Hence, additional system enhancements that the stateless 1158 4via6 solution requires, over and above those simply needed to deploy 1159 and operate an IPv6 network, lie in the domain of supporting the 1160 provisioning of the IPv6 adaptation functionality of the CPEs. This 1161 may require the operator to use DHCPv6, or other provisioning methods 1162 such as IPv6CP, TR-69, in order to configure any relevant 4via6 1163 service parameters to a CPE. 1165 From an IPv4 perspective, an operator will likely want to have a 1166 management system capable of the assignment of IPv4 addresses to the 1167 shared pool, and tuning the re-use factor. In this, the solution 1168 exhibits no grossly different characteristics than those of any 1169 system with an operator managed NAT44 function where similar 1170 management capabilities need to be introduced. 1172 One additional aspect of the stateless 4via6 solution needs to be 1173 highlighted. On a par basis this solution requires less per 1174 subscriber management, accounting and logging capabilities than 1175 centralized NAPT44 alternatives such as DS-Lite, due to the 1176 following: 1178 o The assignment of an IPv6 address that embeds a deterministic IPv4 1179 address and port range removes the need for the operator to 1180 perform any NAPT44 binding logging, ie the task of determining 1181 which user had a given IPv4 address and port at a given time is 1182 simply a matter of determining who had the corresponding IPv6 1183 address, rather than collecting large amounts of dynamic binding 1184 data. 1186 o There is no need for the operator to manage NAPT44 binding data 1187 access and retention. 1189 o Given the stateless nature of the 4via6 solution, all subscriber 1190 CPEs in an operator's domain can share exactly the same 4via6 1191 service configuration, i.e. The operator does not need to be 1192 concerned with managing on a per user basis specific AFTR 1193 assignment and/or load balancing such users and throughout 1194 ensuring symmetric traffic flows throughout. 1196 o The location of the NAPT44 function on the user's CPE, allows easy 1197 and direct management of the port mappings by the end user 1198 removing a need for the operator to introduce PCP 1199 [I-D.wing-softwire-port-control-protocol] (or similar) protocols 1200 in on AFTRs, and on CPE devices. In effect the end user can 1201 retains control of any bindings, which could be via today's GUI, 1202 or UPnP IGDv2, or even PCP. 1204 o As and when needed, a stateless 4via6 solution readily supports 1205 the assignment of an unshared IPv4 address, and full port control 1206 by the end user. A similar capability with centralised NAPT44 1207 solutions involve onerous management of per subscriber 1208 configurations on the operator's AFTR. 1210 5.8. Training & Education 1212 5.8.1. Overview 1214 The issue claims a concern with the need for developers and support 1215 staff to be trained & educated in dealing with a port constrained 1216 systems. 1218 5.8.2. Discussion 1220 There appear to be at least two levels of looking at this issue in 1221 the stateless 4via6 context. On one level, it is perfectly true that 1222 developers and support staff will need to be trained with running/ 1223 supporting a native IPv6 network, that is now a basis of the 1224 solution. This however is an inherent aspect of deploying an IPv6 1225 network and applications. On another level, support and developers 1226 need to familiarized with the NAPT44 characteristics of the system, 1227 that are not different from those already known about such systems 1228 today. More specifically, there appears to be no such thing as a 1229 port unconstrained carrier grade NAPT44 system, in either tomorrow's 1230 stateless 4via6 or AFTR guises, or today's residential CPE NAPT44 1231 implementations that have an inherent hard set translation limit 1232 (often 1024 translation, corresponding to a usage of 1024 ports). 1233 That application developers should be trained to be reasonably 1234 conservative in the usage of ports is thus not an issue of the 1235 stateless 4via6 solution, but pretty much of any NAPT44 based 1236 solution, even those in use today. 1238 Another useful observation here is that the stateless 4via6 solution, 1239 actually allows an operator to retain existing troubleshooting 1240 procedures, given which today encompass CPE based NAPT44, rather than 1241 changing them radically to an AFTR. Furthermore, it is possible to 1242 alleviate any port-range constrains for users by allocating more 1243 generous port ranges without the need to manage such users 1244 configuration on active core network devices (eg AFTR). 1246 5.9. Security and Port Randomization 1248 5.9.1. Overview 1250 Preserving port randomization [RFC6056] may be more or less difficult 1251 depending on the address sharing ratio (i.e., the size of the port 1252 space assigned to a CPE). Port randomization may be more difficult 1253 to achieve with a stateless solution than stateful solution. The CPE 1254 can only randomize the ports inside be assigned a fixed port range. 1256 5.9.2. Discussion 1258 The difference in the random port selection range may be significant 1259 in practice and using port-restricted systems without any measures 1260 (like random port selection in draft-bajko-pripaddrassign-03) is one 1261 of the trade-offs of the mechanism. It should be however noted that 1262 even full port unrestricted systems, today, rarely implement random 1263 port selection from the full port range, as such the difference is 1264 largely theoretical, again viewed from today's perspective. Only 1265 with a longer term prospect of devices/hosts adopting random port 1266 selection according to RFC 6056 the NAT-based port-restricted 1267 mechanisms, will degrade security to a certain extent. 1269 5.10. Unknown Failure Modes 1271 5.10.1. Overview 1273 The issue purports that a system with a port constraints introduces 1274 new unknown failure modes, not known with NAT44 or NAPT44 systems, 1275 and in general is more complex than such a system. 1277 5.10.2. Discussion 1279 This claim does not appear to have objective technical arguments that 1280 can be discussed. A restricted port range system, such as the one 1281 assumed in this document, does not appear to have any more or less 1282 complexity than any of the other NAPT44 solutions against which the 1283 same issue has not been levelled. That is a statement that can be 1284 made in consideration of each of those alternative solution network 1285 design (eg elaborate routing rules or topologies) and feature 1286 implementation complexities, which appear to be no better than that 1287 of a stateless 4via6 address port range system. Ultimately, system 1288 complexity is something best left adjudicated by the operators 1289 choosing to deploy one or the other of these IP based transition 1290 solutions. 1292 5.11. Possible Impact on NAT66 use & design 1294 5.11.1. Overview 1296 The notion of a shared address with a constrained port range is seen 1297 as possibly bearing influence on use in future schemes involving 1298 NAT66, where IPv6 address sharing is in general deemed not to be 1299 desired (ie there is good reason to avoid PAT66). 1301 5.11.2. Discussion 1303 The authors do not propose, nor expect to see the IP address sharing 1304 characteristic applying to future NAT66/PAT66 discussions and 1305 specification. However, having said that it is useful to take a 1306 humble step back and consider the general aspect of causality in this 1307 context. The direct cause that brought about IPv4 shared address 1308 solutions to the fore was a shortage/exhaustion of a limited IPv4 1309 address resource, alongside a failure of the community to migrate 1310 IPv4 networks to IPv6 in a timely manner. At the time of writing it 1311 is hard to imagine the same occurring with respect to IPv6 address 1312 resources, and hopefully the same set of causes will not be allowed 1313 to re-occur. This appears to be the only way to ensure that IPv6 1314 address sharing effect does not come to be, as opposed to precluding 1315 such notions within the context of today's IPv4 world where the 1316 causality is rather clear. 1318 5.12. Port statistical multiplexing and monetization of port space 1320 5.12.1. Overview 1322 An issue attributed to 4V6 solutions is that due to their 1323 characteristic of assigning a fixed amount of ports to participating 1324 system nodes, the overall pool of ports cannot be dynamically/ 1325 statistically multiplexed. 1327 A corollary of this claimed issue is the claim that port range 1328 constraints will lead to monetization by service providers of such 1329 port ranges, for example by charging users based on the number of 1330 ports assigned or creating some bronze, silver, gold type of port 1331 based service categories. 1333 5.12.2. Discussion 1335 The 4via6 address shared solution indeed limits the ability to 1336 "overload" ie statistically multiplex amongst users, the ports 1337 available of a given public IPv4 address. This can be seen as a 1338 trade off vs dynamic allocation and the need to log (large amounts) 1339 of NAT bindings. Furthermore, the solution is meant to be 1340 fundamentally a transitional one for supporting legacy IPv4 users 1341 till full migration to IPv6 can occur. As an example, even with a 1342 static allocation of ~1000 ports per shared IP user, it allows an 1343 operator to effectively multiply by ~64 the current IPv4 unrealizable 1344 address space. To put it into a network growth perspective, it 1345 allows an operator to support for some 10 years a steady 50% annual 1346 increase in users, without requiring new IPv4 addresses. This is 1347 likely an alluring (if unlikely) prospect for most, but it 1348 demonstrates the fact that even with static port allocations, IPv4 1349 address sharing can go a long way for many operators. 1351 CGN-based solutions, because they can dynamically assign ports, 1352 provide better IPv4 address sharing ratio than stateless solutions 1353 (i.e., can share the same IP address among a larger number of 1354 customers). For Service Providers who desire an aggressive IPv4 1355 address sharing, a CGN-based solution is more suitable than the 1356 stateless. However, in case a CGN pre-allocates port ranges, for 1357 instance to alleviate traceability complexity it also reduces its 1358 port utilization efficiency. 1360 5.13. Readdressing 1362 5.13.1. Overview 1364 Due to the port range encoding being part of the CPE's IPv6 address, 1365 any change in the range requires a re-configuration of the CPEs 4via6 1366 address. This is said to be an issue given the impact that IP 1367 address changes have on existing traffic flows, as well as general 1368 IPv6 network routing 1370 5.13.2. Discussion 1372 It is true that under the assumed notions of the stateless 4via6 1373 solution, IPv6 re-addressing is required to effect a change in terms 1374 of the shared IPv4 address or ports. Such changes can and are likely 1375 best done using dynamic address configuration methods such as DHCPv6, 1376 or alternatively out of band management tools, eg TR-69, especially 1377 when the 4via6 address can be derived from a delegated prefix. Using 1378 these, the impact of the address change does not translate to a 1379 neither a classic IPv6 host renumbering problem nor an unmanageable 1380 network renumbering problem. On the CPE, the change only affects the 1381 4via6 address of the CPE and not any end user IPv6 hosts behind the 1382 CPE (which would likely continue to derive their IPv6 addresses from 1383 an unchanged delegated prefix). On the service provider network 1384 side, the change, if any, represents a network renumbering case which 1385 the operator can be reasonably expected to handle within their 1386 network numbering plan, especially given that the IPv6-prefix of the 1387 an IPv4-in-IPv6 address is summarizable. 1389 An addressing change will impacting any existing IPv4 flows that are 1390 being NAT'ed by the CPE. This is also analogous to the today's 1391 practice of IPv4 address changes espoused by some operators, which 1392 while not being commendable, is established in the market. 1393 Nevertheless, as a means of alleviating such an impact it appears 1394 desirable for the solutions to investigate the viability of 1395 mechanisms that could allow for more graceful addressing changes. 1397 To facilitate IPv6 summarization and operator appears to have two 4V6 1398 deployment choices. When encoding IPv4 addresses in lower order 1399 address space bits that are subject to summarization,the operator 1400 would need to assign a modest dedicated IPv6 prefix (such as a /64) 1401 as an 4V6 IPv6 addressing sub-domain. Alternatively, without 1402 resorting to a separate 4V6 addressing sub-domain, an operator could 1403 allow for the IPv4 address embedding to be embedded in a high-order 1404 portion of the IPv6 domain address space, one that closely follows 1405 the IPv6 domain prefix. These two valid address subnetting and 1406 deployment options deserve better description in the solution 1407 specifications. 1409 5.14. Ambiguity about communication between devices sharing an IP 1410 address. 1412 5.14.1. Overview 1414 A regular IPv4 destination based routed system inherently does not 1415 allow two devices to communicate while sharing the same IPv4 address, 1416 even if with different ports. Similarly, such a system does not 1417 allow on the basis of a IPv4 source address alone to perform address 1418 spoofing prevention. These two issues naturally render regular IPv4 1419 based routed networks incapable of supporting a shared address 1420 solution. 1422 5.14.2. Discussion 1424 In terms of the IPv4 data plane of the 4via6 solution, the CPE and 1425 the stateless gateway components need to be modified in terms of 1426 their IPv4 forwarding behaviour. The CPE's NAPT44 function, must be 1427 capable of sending traffic towards the IPv6 adaptation function when 1428 the traffic is addressed to its (shared) IPv4 address but a different 1429 port than the one assigned to the CPE. Similarly, the CPE's NAPT44 1430 function must be capable of receiving traffic addressed from its 1431 (shared) IPv4 address but a different port than the one assigned to 1432 it. 1434 On the IPv6 data plane the stateless 4via6 solution does not suffer 1435 from the issue by the nature of relying on regular IPv6 forwarding. 1436 Address-spoofing security can be realized on regular IPv6 devices 1437 plane, in a way which effectively does not allow a CPE to send IPv6 1438 traffic from a source IPv6 address that it has not been assigned. 1439 The spoofing of IPv4 addresses can be prevented in this manner in 1440 4via6 solution relying on translation (dIVI). Tunneling 4via6 1441 solutions (4rd) require IPv6+IPv4 source address validation to be 1442 performed at the CPE and stateless gateway, by the IPv6 adaptation 1443 function. 1445 The conceptual IPv6 adaptation function has many of its core 1446 principles already defined either as part of IPinIP tunneling or 1447 stateless NAT64 drafts. However additional work, such as defining 1448 the port indexing schemes, is needed and is at the heart of what 1449 needs to be covered in the individual solution drafts that fall under 1450 the stateless 4via6 family. Throughout, no legacy IPv4 end-systems 1451 are expected to implement these techniques. 1453 5.15. Other 1455 5.15.1. Abuse Claims 1457 Because the IPv4 address is shared between several customers, and in 1458 order to meet the traceability requirement discussed in Section 12 of 1459 [I-D.ietf-intarea-shared-addressing-issues], Service Providers must 1460 store the assigned ports in addition to the IPv4 address. 1462 If the remote server does not implement the recommendation detailed 1463 in [I-D.ietf-intarea-server-logging-recommendations], the Service 1464 Provider may be obliged to reveal the identity of all customers 1465 sharing the same IP address at a given time. 1467 5.15.2. Fragmentation and Traffic Asymmetry 1469 In order to deliver a fragmented IPv4 packet to its final 1470 destination, among those having the same IPv4 address, a dedicated 1471 procedure similar to the one defined in Section 3.5 of [RFC6146] is 1472 required to reassemble the fragments in order to look at the 1473 destination port number. 1475 When several stateless IPv4/IPv6 interconnection nodes are deployed, 1476 and because of traffic asymmetry, situations where fragments are not 1477 handled by the same stateless IPv4/IPv6 interconnection node may 1478 occur. Such context would lead to session breakdowns. As a 1479 mitigation, a solution would be to redirect fragments towards a given 1480 node which will be responsible for implementing the procedure 1481 documented in [RFC6146]. The redirection procedure is stateless. 1483 As a conclusion, this issue can be mitigated. 1485 5.15.3. Multicast Services 1487 IPv4 service continuity must be guaranteed during the transition 1488 period, including the delivery of multicast-based services such as 1489 IPTV. Because only an IPv6 prefix will be provided to a CPE, 1490 dedicated functions are required to be enabled for the delivery of 1491 legacy multicast services to IPv4 receivers. This is critical since 1492 many of the current IPTV contents are likely to remain IPv4-formatted 1493 and there will remain legacy receivers (e.g., IPv4-only Set Top Boxes 1494 (STB)) that can't be upgraded or be easily replaced. 1496 This issue is similar to the one encountered in the stateful case, 1497 and the same solution can be used to mitigate the issue (e.g., 1498 [I-D.qin-softwire-dslite-multicast]). 1500 As a conclusion, this issue can be solved. 1502 6. Conclusion 1504 As per the discussion in this document, the authors believe that the 1505 set of issues specifically attributed to A+P based such as the 1506 stateless 4via6 solution with characteristics as per Section 3, 1507 either do not apply, or can be mitigated. In several aspects, a 1508 stateless 4V6 solution represents a reasonable trade off compared to 1509 alternatives in areas such as NAT logging, ease as of deployment and 1510 operations, all of which are actually facilitated by such a solution. 1512 In terms of the 4V6 transport mode, both translation and mapped 1513 tunnel appear to be share the same key characteristics, but 1514 applicable to different contexts. The mapped tunnel mode appears 1515 desirable when the operator has no expectations of applying any more 1516 elaborate traffic based services, and/or concerned about the loss of 1517 IP Options or the use of NAT64 technology. The translation based 1518 approach appears particularly attractive to operators who are 1519 concerned about integrating traffic into a more elaborate suite of 1520 services based on regular IPv6 data-plane functionality, as opposed 1521 to specific IPinIP data plane functionality. 1523 7. IANA Considerations 1525 This document does not raise any IANA considerations. 1527 8. Security Considerations 1529 This document does not introduce any security considerations over and 1530 above those already covered by the referenced solution drafts. 1532 9. Contributors and Acknowledgements 1534 The authors thank Dan Wing, Nejc Skoberne, Remi Depres, Xing Li, Jan 1535 Zorz, Satoru Matsushima, Mohamed Boucadair, Qiong Sun, and Arkadiusz 1536 Kaliwoda for their reviews and draft input. 1538 10. References 1540 10.1. Normative References 1542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1543 Requirement Levels", BCP 14, RFC 2119, March 1997. 1545 10.2. Informative References 1547 [I-D.bajko-pripaddrassign] 1548 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 1549 "Port Restricted IP Address Assignment", 1550 draft-bajko-pripaddrassign-03 (work in progress), 1551 September 2010. 1553 [I-D.despres-softwire-4rd] 1554 Despres, R., "IPv4 Residual Deployment across IPv6-Service 1555 networks (4rd) A NAT-less solution", 1556 draft-despres-softwire-4rd-00 (work in progress), 1557 October 2010. 1559 [I-D.ietf-intarea-server-logging-recommendations] 1560 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1561 "Logging recommendations for Internet facing servers", 1562 draft-ietf-intarea-server-logging-recommendations-04 (work 1563 in progress), April 2011. 1565 [I-D.ietf-intarea-shared-addressing-issues] 1566 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1567 Roberts, "Issues with IP Address Sharing", 1568 draft-ietf-intarea-shared-addressing-issues-05 (work in 1569 progress), March 2011. 1571 [I-D.ietf-softwire-ds-lite-tunnel-option] 1572 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1573 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 1574 draft-ietf-softwire-ds-lite-tunnel-option-10 (work in 1575 progress), March 2011. 1577 [I-D.ietf-softwire-dual-stack-lite] 1578 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1579 Stack Lite Broadband Deployments Following IPv4 1580 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 1581 in progress), May 2011. 1583 [I-D.murakami-softwire-4v6-translation] 1584 Murakami, T., Chen, G., Deng, H., Dec, W., and S. 1585 Matsushima, "4via6 Stateless Translation", 1586 draft-murakami-softwire-4v6-translation-00 (work in 1587 progress), July 2011. 1589 [I-D.operators-softwire-stateless-4v6-motivation] 1590 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 1591 Borges, I., and G. Chen, "Motivations for Stateless IPv4 1592 over IPv6 Migration Solutions", 1593 draft-operators-softwire-stateless-4v6-motivation-02 (work 1594 in progress), June 2011. 1596 [I-D.qin-softwire-dslite-multicast] 1597 Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y. 1598 Lee, "Multicast Extensions to DS-Lite Technique in 1599 Broadband Deployments", 1600 draft-qin-softwire-dslite-multicast-04 (work in progress), 1601 June 2011. 1603 [I-D.thaler-port-restricted-ip-issues] 1604 Thaler, D., "Issues With Port-Restricted IP Addresses", 1605 draft-thaler-port-restricted-ip-issues-00 (work in 1606 progress), February 2010. 1608 [I-D.vixie-dnsext-dns0x20] 1609 Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to 1610 Improve Transaction Identity", 1611 draft-vixie-dnsext-dns0x20-00 (work in progress), 1612 March 2008. 1614 [I-D.wing-softwire-port-control-protocol] 1615 Wing, D., Penno, R., and M. Boucadair, "Pinhole Control 1616 Protocol (PCP)", 1617 draft-wing-softwire-port-control-protocol-02 (work in 1618 progress), July 2010. 1620 [I-D.xli-behave-divi] 1621 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 1622 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03 1623 (work in progress), July 2011. 1625 [I-D.xli-behave-divi-pd] 1626 Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun, 1627 "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix 1628 Delegation", draft-xli-behave-divi-pd-01 (work in 1629 progress), September 2011. 1631 [I-D.ymbk-aplusp] 1632 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 1633 draft-ymbk-aplusp-10 (work in progress), May 2011. 1635 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1636 Robustness to Blind In-Window Attacks", RFC 5961, 1637 August 2010. 1639 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1640 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1641 October 2010. 1643 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1644 Protocol Port Randomization", BCP 156, RFC 6056, 1645 January 2011. 1647 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1648 Algorithm", RFC 6145, April 2011. 1650 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1651 NAT64: Network Address and Protocol Translation from IPv6 1652 Clients to IPv4 Servers", RFC 6146, April 2011. 1654 Authors' Addresses 1656 Wojciech Dec 1657 Cisco 1658 Haarlerbergweg 13-19 1659 1101 CH Amsterdam 1660 The Netherlands 1662 Email: wdec@cisco.com 1663 Rajiv Asati 1664 Cisco 1665 Raleigh, NC 1666 USA 1668 Phone: 1669 Fax: 1670 Email: rajiva@cisco.com 1671 URI: 1673 Congxiao Bao 1674 CERNET Center/Tsinghua University 1675 Room 225, Main Building, Tsinghua University 1676 Beijing, 100084 1677 CN 1679 Phone: +86 10-62785983 1680 Fax: 1681 Email: congxiao@cernet.edu.cn 1682 URI: 1684 Hui Deng 1685 China Mobile 1686 Beijing, 1687 CN 1689 Phone: 1690 Fax: 1691 Email: denghui@chinamobile.com 1692 URI: 1694 Mohamed Boucadair 1695 France Telecom 1696 France 1698 Phone: 1699 Fax: 1700 Email: mohamed.boucadair@orange-ftgroup.com 1701 URI: