idnits 2.17.1 draft-ietf-softwire-lw4over6-03.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2013) is 3815 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-05 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-02 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-03 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-08 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-unified-cpe-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Working Group Y. Cui 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track Q. Sun 5 Expires: May 17, 2014 China Telecom 6 M. Boucadair 7 France Telecom 8 T. Tsou 9 Huawei Technologies 10 Y. Lee 11 Comcast 12 I. Farrer 13 Deutsche Telekom AG 14 November 13, 2013 16 Lightweight 4over6: An Extension to the DS-Lite Architecture 17 draft-ietf-softwire-lw4over6-03 19 Abstract 21 Dual-Stack Lite (RFC 6333) describes an architecture for transporting 22 IPv4 packets over an IPv6 network. This document specifies an 23 extension to DS-Lite called Lightweight 4over6 which moves the 24 Network Address and Port Translation (NAPT) function from the 25 centralized DS-Lite tunnel concentrator to the tunnel client located 26 in the Customer Premises Equipment (CPE). This removes the 27 requirement for a Carrier Grade NAT function in the tunnel 28 concentrator and reduces the amount of centralized state that must be 29 held to a per-subscriber level. In order to delegate the NAPT 30 function and make IPv4 Address sharing possible, port-restricted IPv4 31 addresses are allocated to the CPEs. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 17, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Lightweight 4over6 Architecture . . . . . . . . . . . . . . . 5 71 5. Lightweight B4 Behavior . . . . . . . . . . . . . . . . . . . 7 72 5.1. Lightweight B4 Provisioning with DHCPv6 . . . . . . . . . 7 73 5.2. Lightweight B4 Data Plane Behavior . . . . . . . . . . . 8 74 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation 75 Behaviour . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Lightweight AFTR Behavior . . . . . . . . . . . . . . . . . . 10 77 6.1. Binding Table Maintenance . . . . . . . . . . . . . . . . 10 78 6.2. lwAFTR Data Plane Behavior . . . . . . . . . . . . . . . 11 79 7. Additional IPv4 address and Port Set Provisioning 80 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 11. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 13.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Dual-Stack Lite (DS-Lite, [RFC6333]) defines a model for providing 94 IPv4 access over an IPv6 network using two well-known technologies: 95 IP in IP [RFC2473] and Network Address Translation (NAT). The DS- 96 Lite architecture defines two major functional elements as follows: 98 Basic Bridging BroadBand element: A B4 element is a function 99 implemented on a dual-stack capable 100 node, either a directly connected 101 device or a CPE, that creates a 102 tunnel to an AFTR. 104 Address Family Transition Router: An AFTR element is the combination 105 of an IPv4-in-IPv6 tunnel endpoint 106 and an IPv4-IPv4 NAT implemented on 107 the same node. 109 As the AFTR performs the centralized NAT44 function, it dynamically 110 assigns public IPv4 addresses and ports to requesting host's traffic 111 (as described in [RFC3022]). To achieve this, the AFTR must 112 dynamically maintain per-flow state in the form of active NAPT 113 sessions. For service providers with a large number of B4 clients, 114 the size and associated costs for scaling the AFTR can quickly become 115 prohibitive. It can also place a large NAPT logging overhead upon 116 the service provider in countries where legal requirements mandate 117 this. 119 This document describes a mechanism called Lightweight 4 over 6 120 (lw4o6), which provides a solution for these problems. By relocating 121 the NAPT functionality from the centralized AFTR to the distributed 122 B4s, a number of benefits can be realised: 124 o NAPT44 functionality is already widely supported and used in 125 today's CPE devices. Lw4o6 uses this to provide private<->public 126 NAPT44, meaning that the service provider does not need a 127 centralized NAT44 function. 129 o The amount of state that must be maintained centrally in the AFTR 130 can be reduced from per-flow to per-subscriber. This reduces the 131 amount of resources (memory and processing power) necessary in the 132 AFTR. 134 o The reduction of maintained state results in a greatly reduced 135 logging overhead on the service provider. 137 Operator's IPv6 and IPv4 addressing architectures remain independent 138 of each other. Therefore, flexible IPv4/IPv6 addressing schemes can 139 be deployed. 141 Lightweight 4over6 provides a solution for a hub-and-spoke softwire 142 architecture only. It does not offer direct, meshed IPv4 143 connectivity between subscribers without packets traversing the AFTR. 144 If this type of meshed interconnectivity is required, 145 [I-D.ietf-softwire-map] provides a suitable solution. 147 The tunneling mechanism remains the same for DS-Lite and Lightweight 148 4over6. This document describes the changes to DS-Lite that are 149 necessary to implement Lightweight 4over6. These changes mainly 150 concern the configuration parameters and provisioning method 151 necessary for the functional elements. 153 Lightweight 4over6 features keeping per-subscriber state in the 154 service provider's network. It is categorized as Binding approach in 155 [I-D.ietf-softwire-unified-cpe] which defines a unified IPv4-in-IPv6 156 Softwire CPE. 158 This document is an extended case, which covers address sharing for 159 [I-D.ietf-softwire-public-4over6]. It is also a variant of A+P 160 called Binding Table Mode (see Section 4.4 of [RFC6346]). 162 This document focuses on architectural considerations and 163 particularly on the expected behavior of the involved functional 164 elements and their interfaces. Deployment-specific issues are 165 discussed in a companion document. As such, discussions about 166 redundancy and provisioning policy are out of scope. 168 2. Conventions 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 3. Terminology 176 The document defines the following terms: 178 Lightweight 4over6 (lw4o6): An IPv4-over-IPv6 hub and spoke 179 mechanism, which extends DS-Lite by 180 moving the IPv4 translation (NAPT44) 181 function from the AFTR to the B4. 183 Lightweight B4 (lwB4): A B4 element (Basic Bridging BroadBand 184 element [RFC6333]), which supports 185 Lightweight 4over6 extensions. An lwB4 186 is a function implemented on a dual- 187 stack capable node, (either a directly 188 connected device or a CPE), that 189 supports port-restricted IPv4 address 190 allocation, implements NAPT44 191 functionality and creates a tunnel to 192 an lwAFTR 194 Lightweight AFTR (lwAFTR): An AFTR element (Address Family 195 Transition Router element [RFC6333]), 196 which supports Lightweight 4over6 197 extension. An lwAFTR is an IPv4-in- 198 IPv6 tunnel endpoint which maintains 199 per-subscriber address binding only and 200 does not perform a NAPT44 function. 202 Restricted Port-Set: A non-overlapping range of allowed 203 external ports allocated to the lwB4 to 204 use for NAPT44. Source ports of IPv4 205 packets sent by the B4 must belong to 206 the assigned port-set. The port set is 207 used for all port aware IP protocols 208 (TCP, UDP, SCTP etc.) 210 Port-restricted IPv4 Address: A public IPv4 address with a restricted 211 port-set. In Lightweight 4over6, 212 multiple B4s may share the same IPv4 213 address, however, their port-sets must 214 be non-overlapping. 216 Throughout the remainder of this document, the terms B4/AFTR should 217 be understood to refer specifically to a DS-Lite implementation. The 218 terms lwB4/lwAFTR refer to a Lightweight 4over6 implementation. 220 4. Lightweight 4over6 Architecture 222 The Lightweight 4over6 architecture is functionally similar to DS- 223 Lite. lwB4s and an lwAFTR are connected through an IPv6-enabled 224 network. Both approaches use an IPv4-in-IPv6 encapsulation scheme to 225 deliver IPv4 connectivity services. The following figure shows the 226 data plane with the main functional change between DS-Lite and lw4o6: 228 +--------+ +---------+ IPv4-in-IPv6 +------+ +-------------+ 229 |IPv4 LAN|---|lwB4/NAPT|==================|lwAFTR|----|IPv4 Internet| 230 +--------+ +---------+ +------+ +-------------+ 231 ^ | 232 +-------------------------+ 233 NAPT function relocated 234 to lwB4 in lw4o6 236 Figure 1 Lightweight 4over6 Data Plane Overview 237 There are three main components in the Lightweight 4over6 238 architecture: 240 o The lwB4, which performs the NAPT function and encapsulation/de- 241 capsulation IPv4/IPv6. 243 o The lwAFTR, which performs the encapsulation/de-capsulation IPv4/ 244 IPv6. 246 o The provisioning system, which tells the lwB4 which IPv4 address 247 and port set to use. 249 The lwB4 differs from a regular B4 in that it now performs the NAPT 250 functionality. This means that it needs to be provisioned with the 251 public IPv4 address and port set it is allowed to use. This 252 information is provided though a provisioning mechanism such as DHCP, 253 PCP or TR-69. 255 The lwAFTR needs to know the binding between the IPv6 address of each 256 subscriber and the IPv4 address and port set allocated to that 257 subscriber. This information is used to perform ingress filtering 258 upstream and encapsulation downstream. Note that this is per- 259 subscriber state as opposed to per-flow state in the regular AFTR 260 case. 262 The consequence of this architecture is that the information 263 maintained by the provisioning mechanism and the one maintained by 264 the lwAFTR MUST be synchronized (See figure 2). The details of this 265 synchronization depend on the exact provisioning mechanism and will 266 be discussed in a companion document. 268 The solution specified in this document allows the assignment of 269 either a full or a shared IPv4 address requesting CPEs. 270 [I-D.ietf-softwire-public-4over6] provides a mechanism for assigning 271 a full IPv4 address only. 273 +------------+ 274 /-------|Provisioning|<-----\ 275 | +------------+ | 276 | | 277 V V 278 +--------+ +---------+ IPv4/IPv6 +------+ +-------------+ 279 |IPv4 LAN|---|lwB4/NAPT|==================|lwAFTR|----|IPv4 Internet| 280 +--------+ +---------+ +------+ +-------------+ 282 Figure 2 Lightweight 4over6 Provisioning Synchronization 284 5. Lightweight B4 Behavior 286 5.1. Lightweight B4 Provisioning with DHCPv6 288 With DS-Lite, the B4 element only needs to be configured with a 289 single DS-Lite specific parameter so that it can set up the softwire 290 (the IPv6 address of the AFTR). Its IPv4 address can be taken from 291 the well-known range 192.0.0.0/29. 293 In lw4o6, due to the distributed nature of the NAPT function, a 294 number of lw4o6 specific configuration parameters must be provisioned 295 to the lwB4. These are: 297 o IPv6 Address for the lwAFTR 299 o IPv4 External (Public) Address for NAPT44 301 o Restricted port-set to use for NAPT44 303 For DHCPv6 based configuration of these parameters, the lwB4 SHOULD 304 implement OPTION_SW46_LW as described in section 6.3 of 305 [I-D.ietf-softwire-map-dhcp]. This means that the lifetime of the 306 softwire and the derived configuration information (e.g. IPv4 shared 307 address, IPv4 address) is bound to the lifetime of the DHCPv6 lease. 308 If stateful IPv4 configuration or additional IPv4 configuration 309 information is required, DHCPv4 [RFC2131] must be used. 311 Some other mechanisms which may be adapted for the provisioning of 312 IPv4 addresses and port-sets are described in section 7 below. 314 An IPv6 address from an assigned prefix is also required for the lwB4 315 to use as the encapsulation source address for the softwire. In 316 order to enable end-to-end provisioning, the IPv6 address is 317 constructed by taking the /64 prefix assigned to the WAN interface 318 (learned via SLAAC, DHCPv6 or manual configuration) and suffixing 319 64-bits for the interface identifier. The /128 prefix is constructed 320 as follows: 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Operator assigned (64-bits) | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Zero Padding | IPv4 Address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | IPv4 Addr cont. | PSID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 3 Construction of the lw4o6 /128 Prefix 335 Padding: Padding (all zeros) 337 IPv4 Address: Public IPv4 address allocated to the client 339 PSID: Port Set ID allocated to the client, left padded with 340 zeros to 16-bits. If no PSID is provisioned, all 341 zeros. 343 In the event that the lwB4's encapsulation source address is changed 344 for any reason (such as the DHCPv6 lease expiring), the lwB4's 345 dynamic provisioning process must be re-initiated. 347 An lwB4 MUST support dynamic port-restricted IPv4 address 348 provisioning. The port set algorithm for provisioning this is 349 described in Section 5.1 of [I-D.ietf-softwire-map]. For lw4o6, the 350 number of a-bits SHOULD be 0. 352 In the event that the lwB4 receives and ICMPv6 error message (type 1, 353 code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this 354 to mean that no matching entry in the lwAFTR's binding table has been 355 found. The lwB4 MAY then re-initiate the dynamic port-restricted 356 provisioning process. The lwB4's re-initiation policy SHOULD be 357 configurable. 359 The DNS considerations described in Section 5.5 and Section 6.4 of 360 [RFC6333] SHOULD be followed. 362 5.2. Lightweight B4 Data Plane Behavior 364 Several sections of [RFC6333] provide background information on the 365 B4's data plane functionality and MUST be implemented by the lwB4 as 366 they are common to both solutions. The relevant sections are: 368 5.2 Encapsulation Covering encapsulation and de- 369 capsulation of tunneled traffic 371 5.3 Fragmentation and Reassembly Covering MTU and fragmentation 372 considerations (referencing 373 [RFC2473]), with the exception 374 noted below. 376 7.1 Tunneling Covering tunneling and traffic 377 class mapping between IPv4 and IPv6 378 (referencing [RFC2473] and 379 [RFC4213]) 381 The lwB4 element performs IPv4 address translation (NAPT44) as well 382 as encapsulation and de-capsulation. It runs standard NAPT44 383 [RFC3022] using the allocated port-restricted address as its external 384 IPv4 address and port numbers. 386 The working flow of the lwB4 is illustrated in figure 3. 388 +-------------+ 389 | lwB4 | 390 +--------+ IPv4 |------+------| IPv4-in-IPv6 +----------+ 391 |IPv4 LAN|------->| |Encap.|-------------->|Configured| 392 | |<-------| NAPT | or |<--------------| lwAFTR | 393 +--------+ | |Decap.| +----------+ 394 +------+------+ 396 Figure 4 Working Flow of the lwB4 398 Internally connected hosts source IPv4 packets with an [RFC1918] 399 address. When the lwB4 receives such an IPv4 packet, it performs a 400 NAPT44 function on the source address and port by using the public 401 IPv4 address and a port number from the allocated port-set. Then, it 402 encapsulates the packet with an IPv6 header. The destination IPv6 403 address is the lwAFTR's IPv6 address and the source IPv6 address is 404 the lwB4's IPv6 tunnel endpoint address. Finally, the lwB4 forwards 405 the encapsulated packet to the configured lwAFTR. 407 When the lwB4 receives an IPv4-in-IPv6 packet from the lwAFTR, it de- 408 capsulates the IPv4 packet from the IPv6 packet. Then, it performs 409 NAPT44 translation on the destination address and port, based on the 410 available information in its local NAPT44 table. 412 If the IPv6 source address does not match the configured lwAFTR 413 address, then the packet MUST be discarded. If the decapsulated IPv4 414 packet does not match the lwB4's configuration (i.e. invalid 415 destination IPv4 address or port) then the packet MUST be dropped. 416 An ICMPv4 error message (type 13 - Communication Administratively 417 Prohibited) message MAY be sent back to the lwAFTR. The ICMP policy 418 SHOULD be configurable. 420 The lwB4 is responsible for performing ALG functions (e.g., SIP, 421 FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP, 422 manual binding configuration, PCP) for the internal hosts. This 423 requirement is typical for NAPT44 gateways available today. 425 It is possible that a lwB4 is co-located in a host. In this case, 426 the functions of NAPT44 and encapsulation/de-capsulation are 427 implemented inside the host. 429 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour 431 On receiving an encapsulated packet containing an IPv4 fragment, the 432 lwB4 MUST wait until all other fragments have been received and de- 433 capsulated. The original packet is then re-assembled before 434 performing NAPT. This is necessary because layer-4 protocol 435 information is only present in the first fragment. 437 When an lwB4 receives an IPv4 packet from its connected host that is 438 larger than the MTU size after encapsulation, the lwB4 MUST fragment 439 the IPv4 packet before encapsulation. This lwB4 behavior will not 440 result IPv6 fragmentation so that lwAFTR does not require to re- 441 assemble the fragmented IPv6 packets. 443 6. Lightweight AFTR Behavior 445 6.1. Binding Table Maintenance 447 The lwAFTR maintains an address binding table containing the binding 448 between the lwB4's IPv6 address, the allocated IPv4 address and 449 restricted port-set. Unlike the DS-Lite extended binding table 450 defined in section 6.6 of [RFC6333] which is a 5-tuple NAPT table, 451 each entry in the Lightweight 4over6 binding table contains the 452 following 3-tuples: 454 o IPv6 Address for a single lwB4 456 o Public IPv4 Address 458 o Restricted port-set 460 The entry has two functions: the IPv6 encapsulation of inbound IPv4 461 packets destined to the lwB4 and the validation of outbound IPv4-in- 462 IPv6 packets received from the lwB4 for de-capsulation. 464 The lwAFTR does not perform NAPT and so does not need session 465 entries. 467 The lwAFTR MUST synchronize the binding information with the port- 468 restricted address provisioning process. If the lwAFTR does not 469 participate in the port-restricted address provisioning process, the 470 binding MUST be synchronized through other methods (e.g. out-of-band 471 static update). 473 If the lwAFTR participates in the port-restricted provisioning 474 process, then its binding table MUST be created as part of this 475 process. 477 For all provisioning processes, the lifetime of binding table entries 478 MUST be synchronized with the lifetime of address allocations. 480 6.2. lwAFTR Data Plane Behavior 482 Several sections of [RFC6333] provide background information on the 483 AFTR's data plane functionality and MUST be implemented by the lwAFTR 484 as they are common to both solutions. The relevant sections are: 486 6.2 Encapsulation Covering encapsulation and de- 487 capsulation of tunneled traffic 489 6.3 Fragmentation and Reassembly Fragmentation and re-assembly 490 considerations (referencing 491 [RFC2473]) 493 7.1 Tunneling Covering tunneling and traffic 494 class mapping between IPv4 and IPv6 495 (referencing [RFC2473] and 496 [RFC4213]) 498 When the lwAFTR receives an IPv4-in-IPv6 packet from an lwB4, it de- 499 capsulates the IPv6 header and verifies the source addresses and port 500 in the binding table. If both the source IPv4 and IPv6 addresses 501 match a single entry in the binding table and the source port is in 502 the allowed port-set for that entry, the lwAFTR forwards the packet 503 to the IPv4 destination. 505 If no match is found (e.g., no matching IPv4 address entry, port out 506 of range, etc.), the lwAFTR MUST discard or implement a policy (such 507 as redirection) on the packet. An ICMPv6 type 1, code 5 (source 508 address failed ingress/egress policy) error message MAY be sent back 509 to the requesting lwB4. The ICMP policy SHOULD be configurable. 511 When the lwAFTR receives an inbound IPv4 packet, it uses the IPv4 512 destination address and port to lookup the destination lwB4's IPv6 513 address in its binding table. If a match is found, the lwAFTR 514 encapsulates the IPv4 packet. The source is the lwAFTR's IPv6 515 address and the destination is the lwB4's IPv6 address from the 516 matched entry. Then, the lwAFTR forwards the packet to the lwB4 517 natively over the IPv6 network. 519 If no match is found, the lwAFTR MUST discard the packet. An ICMPv4 520 type 3, code 1 (Destination unreachable, host unreachable) error 521 message MAY be sent back. The ICMP policy SHOULD be configurable. 523 The lwAFTR MUST support hairpinning of traffic between two lwB4s, by 524 performing de-capsulation and re-encapsulation of packets. The 525 hairpinning policy MUST be configurable. 527 7. Additional IPv4 address and Port Set Provisioning Mechanisms 529 In addition to the DHCPv6 based mechanism described in section 5.1, 530 several other IPv4 provisioning protocols have been suggested. These 531 protocols MAY be implemented. These alternatives include: 533 o DHCPv4 over DHCPv6: [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes 534 implementing DHCPv4 messages over an IPv6 only service providers 535 network. This enables leasing of IPv4 addresses and makes DHCPv4 536 options available to the DHCPv4 over DHCPv6 client. 538 o PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve 539 a restricted IPv4 address and a set of ports. 541 In a Lightweight 4over6 domain, the binding information MUST be 542 aligned between the lwB4s, the lwAFTRs and the provisioning server. 544 8. ICMP Processing 546 ICMP does not work in an address sharing environment without special 547 handling [RFC6269]. Due to the port-set style address sharing, 548 Lightweight 4over6 requires specific ICMP message handling not 549 required by DS-Lite. 551 The following behavior SHOULD be implemented by the lwAFTR to provide 552 ICMP error handling and basic remote IPv4 service diagnostics for a 553 port restricted CPE: for inbound ICMP messages, the lwAFTR MAY behave 554 in two modes: 556 Either: 558 1. Check the ICMP Type field. 560 2. If the ICMP type is set to 0 or 8 (echo reply or request), then 561 the lwAFTR MUST take the value of the ICMP identifier field as 562 the source port, and use this value to lookup the binding table 563 for an encapsulation destination. If a match is found, the 564 lwAFTR forwards the ICMP packet to the IPv6 address stored in the 565 entry; otherwise it MUST discard the packet. 567 3. If the ICMP type field is set to any other value, then the lwAFTR 568 MUST use the method described in REQ-3 of [RFC5508] to locate the 569 source port within the transport layer header in ICMP packet's 570 data field. The destination IPv4 address and source port 571 extracted from the ICMP packet are then used to make a lookup in 572 the binding table. If a match is found, it MUST forward the ICMP 573 reply packet to the IPv6 address stored in the entry; otherwise 574 it MUST discard the packet. 576 Or: 578 o Discard all inbound ICMP messages. 580 The ICMP policy SHOULD be configurable. 582 The lwB4 SHOULD implement the requirements defined in [RFC5508] for 583 ICMP forwarding. For ICMP echo request packets originating from the 584 private IPv4 network, the lwB4 SHOULD implement the method described 585 in [RFC6346] and use an available port from its port-set as the ICMP 586 Identifier. 588 For both the lwAFTR and the lwB4, ICMPv6 MUST be handled as described 589 in [RFC2473]. 591 9. Security Considerations 593 As the port space for a subscriber shrinks due to address sharing, 594 the randomness for the port numbers of the subscriber is decreased 595 significantly. This means it is much easier for an attacker to guess 596 the port number used, which could result in attacks ranging from 597 throughput reduction to broken connections or data corruption. 599 The port-set for a subscriber can be a set of contiguous ports or 600 non-contiguous ports. Contiguous port-sets do not reduce this 601 threat. However, with non-contiguous port-set (which may be 602 generated in a pseudo-random way [RFC6431]), the randomness of the 603 port number is improved, provided that the attacker is outside the 604 Lightweight 4over6 domain and hence does not know the port-set 605 generation algorithm. 607 More considerations about IP address sharing are discussed in 608 Section 13 of [RFC6269], which is applicable to this solution. 610 10. IANA Considerations 612 This document does not include an IANA request. 614 11. Author List 616 The following are extended authors who contributed to the effort: 618 Jianping Wu 620 Tsinghua University 622 Department of Computer Science, Tsinghua University 624 Beijing 100084 626 P.R.China 628 Phone: +86-10-62785983 630 Email: jianping@cernet.edu.cn 632 Peng Wu 634 Tsinghua University 636 Department of Computer Science, Tsinghua University 638 Beijing 100084 640 P.R.China 642 Phone: +86-10-62785822 644 Email: pengwu.thu@gmail.com 646 Qi Sun 648 Tsinghua University 650 Beijing 100084 652 P.R.China 654 Phone: +86-10-62785822 656 Email: sunqi@csnet1.cs.tsinghua.edu.cn 657 Chongfeng Xie 659 China Telecom 661 Room 708, No.118, Xizhimennei Street 663 Beijing 100035 665 P.R.China 667 Phone: +86-10-58552116 669 Email: xiechf@ctbri.com.cn 671 Xiaohong Deng 673 France Telecom 675 Email: xiaohong.deng@orange.com 677 Cathy Zhou 679 Huawei Technologies 681 Section B, Huawei Industrial Base, Bantian Longgang 683 Shenzhen 518129 685 P.R.China 687 Email: cathyzhou@huawei.com 689 Alain Durand 691 Juniper Networks 693 1194 North Mathilda Avenue 695 Sunnyvale, CA 94089-1206 697 USA 699 Email: adurand@juniper.net 701 Reinaldo Penno 703 Cisco Systems, Inc. 705 170 West Tasman Drive 707 San Jose, California 95134 709 USA 711 Email: repenno@cisco.com 713 Alex Clauberg 715 Deutsche Telekom AG 717 GTN-FM4 719 Landgrabenweg 151 721 Bonn, CA 53227 723 Germany 725 Email: axel.clauberg@telekom.de 727 Lionel Hoffmann 729 Bouygues Telecom 731 TECHNOPOLE 733 13/15 Avenue du Marechal Juin 735 Meudon 92360 737 France 739 Email: lhoffman@bouyguestelecom.fr 741 Maoke Chen 743 FreeBit Co., Ltd. 745 13F E-space Tower, Maruyama-cho 3-6 747 Shibuya-ku, Tokyo 150-0044 749 Japan 751 Email: fibrib@gmail.com 753 12. Acknowledgement 755 The authors would like to thank Ole Troan, Ralph Droms and Suresh 756 Krishnan for their comments and feedback. 758 This document is a merge of three documents: 759 [I-D.cui-softwire-b4-translated-ds-lite], [I-D.zhou-softwire-b4-nat] 760 and [I-D.penno-softwire-sdnat]. 762 13. References 764 13.1. Normative References 766 [I-D.ietf-softwire-map-dhcp] 767 Mrugalski, T., Troan, O., Dec, W., Bao, C., 768 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 769 for configuration of Softwire Address and Port Mapped 770 Clients", draft-ietf-softwire-map-dhcp-05 (work in 771 progress), October 2013. 773 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 774 E. Lear, "Address Allocation for Private Internets", BCP 775 5, RFC 1918, February 1996. 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, March 1997. 780 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 781 2131, March 1997. 783 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 784 IPv6 Specification", RFC 2473, December 1998. 786 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 787 for IPv6 Hosts and Routers", RFC 4213, October 2005. 789 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 790 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 791 April 2009. 793 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 794 Stack Lite Broadband Deployments Following IPv4 795 Exhaustion", RFC 6333, August 2011. 797 13.2. Informative References 799 [I-D.cui-softwire-b4-translated-ds-lite] 800 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 801 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 802 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 803 (work in progress), February 2013. 805 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 806 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 807 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 808 dhcpv4-over-dhcpv6-02 (work in progress), October 2013. 810 [I-D.ietf-pcp-port-set] 811 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 812 T., and S. Perreault, "Port Control Protocol (PCP) 813 Extension for Port Set Allocation", draft-ietf-pcp-port- 814 set-03 (work in progress), October 2013. 816 [I-D.ietf-softwire-map-dhcp] 817 Mrugalski, T., Troan, O., Dec, W., Bao, C., 818 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 819 for configuration of Softwire Address and Port Mapped 820 Clients", draft-ietf-softwire-map-dhcp-05 (work in 821 progress), October 2013. 823 [I-D.ietf-softwire-map] 824 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 825 Murakami, T., and T. Taylor, "Mapping of Address and Port 826 with Encapsulation (MAP)", draft-ietf-softwire-map-08 827 (work in progress), August 2013. 829 [I-D.ietf-softwire-public-4over6] 830 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 831 IPv4 over IPv6 Access Network", draft-ietf-softwire- 832 public-4over6-10 (work in progress), July 2013. 834 [I-D.ietf-softwire-unified-cpe] 835 Boucadair, M., Farrer, I., Perreault, S., and S. 836 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 837 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 839 [I-D.penno-softwire-sdnat] 840 Penno, R., Durand, A., Hoffmann, L., and A. Clauberg, 841 "Stateless DS-Lite", draft-penno-softwire-sdnat-02 (work 842 in progress), March 2012. 844 [I-D.zhou-softwire-b4-nat] 845 Zhou, C., Boucadair, M., and X. Deng, "NAT offload 846 extension to Dual-Stack lite", draft-zhou- 847 softwire-b4-nat-04 (work in progress), October 2011. 849 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 850 Address Translator (Traditional NAT)", RFC 3022, January 851 2001. 853 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 854 Roberts, "Issues with IP Address Sharing", RFC 6269, June 855 2011. 857 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 858 IPv4 Address Shortage", RFC 6346, August 2011. 860 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 861 T. Tsou, "Huawei Port Range Configuration Options for PPP 862 IP Control Protocol (IPCP)", RFC 6431, November 2011. 864 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 865 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 866 2013. 868 Authors' Addresses 870 Yong Cui 871 Tsinghua University 872 Beijing 100084 873 P.R.China 875 Phone: +86-10-62603059 876 Email: yong@csnet1.cs.tsinghua.edu.cn 878 Qiong Sun 879 China Telecom 880 Room 708, No.118, Xizhimennei Street 881 Beijing 100035 882 P.R.China 884 Phone: +86-10-58552936 885 Email: sunqiong@ctbri.com.cn 887 Mohamed Boucadair 888 France Telecom 889 Rennes 35000 890 France 892 Email: mohamed.boucadair@orange.com 893 Tina Tsou 894 Huawei Technologies 895 2330 Central Expressway 896 Santa Clara, CA 95050 897 USA 899 Phone: +1-408-330-4424 900 Email: tena@huawei.com 902 Yiu L. Lee 903 Comcast 904 One Comcast Center 905 Philadelphia, PA 19103 906 USA 908 Email: yiu_lee@cable.comcast.com 910 Ian Farrer 911 Deutsche Telekom AG 912 GTN-FM4,Landgrabenweg 151 913 Bonn, NRW 53227 914 Germany 916 Email: ian.farrer@telekom.de