idnits 2.17.1 draft-ietf-softwire-lw4over6-02.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 08, 2013) is 3819 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 12, 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 08, 2013 16 Lightweight 4over6: An Extension to the DS-Lite Architecture 17 draft-ietf-softwire-lw4over6-02 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 12, 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 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 13 84 11. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 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]. Some other mechanisms which may be 306 adapted for the provisioning of IPv4 addresses and port-sets are 307 described in section 7 below. 309 An IPv6 address from an assigned prefix is also required for the lwB4 310 to use as the encapsulation source address for the softwire. In 311 order to enable end-to-end provisioning. This is constructed by 312 taking the /64 prefix assigned to the WAN interface (learned via 313 SLAAC, DHCPv6 or manual configuration) and suffixing 64-bits for the 314 interface identifier. The /128 prefix is constructed as follows: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Operator assigned (64-bits) | 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Zero Padding | IPv4 Address | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | IPv4 Addr cont. | PSID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 3 Construction of the lw4o6 /128 Prefix 329 Padding: Padding (all zeros) 330 IPv4 Address: Public IPv4 address allocated to the client 332 PSID: Port Set ID allocated to the client, left padded with 333 zeros to 16-bits. If no PSID is provisioned, all 334 zeros. 336 In the event that the lwB4's encapsulation source address is changed 337 for any reason (such as the DHCPv6 lease expiring), the lwB4's 338 dynamic provisioning process must be re-initiated. 340 An lwB4 MUST support dynamic port-restricted IPv4 address 341 provisioning. The port set algorithm for provisioning this is 342 described in Section 5.1 of [I-D.ietf-softwire-map]. For lw4o6, the 343 number of a-bits SHOULD be 0. 345 In the event that the lwB4 receives and ICMPv6 error message (type 1, 346 code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this 347 to mean that no matching entry in the lwAFTR's binding table has been 348 found. The lwB4 MAY then re-initiate the dynamic port-restricted 349 provisioning process. The lwB4's re-initiation policy SHOULD be 350 configurable. 352 The DNS considerations described in Section 5.5 and Section 6.4 of 353 [RFC6333] SHOULD be followed. 355 5.2. Lightweight B4 Data Plane Behavior 357 Several sections of [RFC6333] provide background information on the 358 B4's data plane functionality and MUST be implemented by the lwB4 as 359 they are common to both solutions. The relevant sections are: 361 5.2 Encapsulation Covering encapsulation and de- 362 capsulation of tunneled traffic 364 5.3 Fragmentation and Reassembly Covering MTU and fragmentation 365 considerations (referencing 366 [RFC2473]), with the exception 367 noted below. 369 7.1 Tunneling Covering tunneling and traffic 370 class mapping between IPv4 and IPv6 371 (referencing [RFC2473] and 372 [RFC4213]) 374 The lwB4 element performs IPv4 address translation (NAPT44) as well 375 as encapsulation and de-capsulation. It runs standard NAPT44 376 [RFC3022] using the allocated port-restricted address as its external 377 IPv4 address and port numbers. 379 The working flow of the lwB4 is illustrated in figure 3. 381 +-------------+ 382 | lwB4 | 383 +--------+ IPv4 |------+------| IPv4-in-IPv6 +----------+ 384 |IPv4 LAN|------->| |Encap.|-------------->|Configured| 385 | |<-------| NAPT | or |<--------------| lwAFTR | 386 +--------+ | |Decap.| +----------+ 387 +------+------+ 389 Figure 4 Working Flow of the lwB4 391 Internally connected hosts source IPv4 packets with an [RFC1918] 392 address. When the lwB4 receives such an IPv4 packet, it performs a 393 NAPT44 function on the source address and port by using the public 394 IPv4 address and a port number from the allocated port-set. Then, it 395 encapsulates the packet with an IPv6 header. The destination IPv6 396 address is the lwAFTR's IPv6 address and the source IPv6 address is 397 the lwB4's IPv6 tunnel endpoint address. Finally, the lwB4 forwards 398 the encapsulated packet to the configured lwAFTR. 400 When the lwB4 receives an IPv4-in-IPv6 packet from the lwAFTR, it de- 401 capsulates the IPv4 packet from the IPv6 packet. Then, it performs 402 NAPT44 translation on the destination address and port, based on the 403 available information in its local NAPT44 table. 405 If the IPv6 source address does not match the configured lwAFTR 406 address, then the packet MUST be discarded. If the decapsulated IPv4 407 packet does not match the lwB4's configuration (i.e. invalid 408 destination IPv4 address or port) then the packet MUST be dropped. 409 An ICMPv4 error message (type 13 - Communication Administratively 410 Prohibited) message MAY be sent back to the lwAFTR. The ICMP policy 411 SHOULD be configurable. 413 The lwB4 is responsible for performing ALG functions (e.g., SIP, 414 FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP, 415 manual binding configuration, PCP) for the internal hosts. This 416 requirement is typical for NAPT44 gateways available today. 418 It is possible that a lwB4 is co-located in a host. In this case, 419 the functions of NAPT44 and encapsulation/de-capsulation are 420 implemented inside the host. 422 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour 424 On receiving an encapsulated packet containing an IPv4 fragment, the 425 lwB4 MUST wait until all other fragments have been received and de- 426 capsulated. The original packet is then re-assembled before 427 performing NAPT. This is necessary because layer-4 protocol 428 information is only present in the first fragment. 430 When an lwB4 receives an IPv4 packet from its connected host that is 431 larger than the MTU size after encapsulation, the lwB4 MUST fragment 432 the IPv4 packet before encapsulation. This lwB4 behavior will not 433 result IPv6 fragmentation so that lwAFTR does not require to re- 434 assemble the fragmented IPv6 packets. 436 6. Lightweight AFTR Behavior 438 6.1. Binding Table Maintenance 440 The lwAFTR maintains an address binding table containing the binding 441 between the lwB4's IPv6 address, the allocated IPv4 address and 442 restricted port-set. Unlike the DS-Lite extended binding table 443 defined in section 6.6 of [RFC6333] which is a 5-tuple NAPT table, 444 each entry in the Lightweight 4over6 binding table contains the 445 following 3-tuples: 447 o IPv6 Address for a single lwB4 449 o Public IPv4 Address 451 o Restricted port-set 453 The entry has two functions: the IPv6 encapsulation of inbound IPv4 454 packets destined to the lwB4 and the validation of outbound IPv4-in- 455 IPv6 packets received from the lwB4 for de-capsulation. 457 The lwAFTR does not perform NAPT and so does not need session 458 entries. 460 The lwAFTR MUST synchronize the binding information with the port- 461 restricted address provisioning process. If the lwAFTR does not 462 participate in the port-restricted address provisioning process, the 463 binding MUST be synchronized through other methods (e.g. out-of-band 464 static update). 466 If the lwAFTR participates in the port-restricted provisioning 467 process, then its binding table MUST be created as part of this 468 process. 470 For all provisioning processes, the lifetime of binding table entries 471 MUST be synchronized with the lifetime of address allocations. 473 6.2. lwAFTR Data Plane Behavior 475 Several sections of [RFC6333] provide background information on the 476 AFTR's data plane functionality and MUST be implemented by the lwAFTR 477 as they are common to both solutions. The relevant sections are: 479 6.2 Encapsulation Covering encapsulation and de- 480 capsulation of tunneled traffic 482 6.3 Fragmentation and Reassembly Fragmentation and re-assembly 483 considerations (referencing 484 [RFC2473]) 486 7.1 Tunneling Covering tunneling and traffic 487 class mapping between IPv4 and IPv6 488 (referencing [RFC2473] and 489 [RFC4213]) 491 When the lwAFTR receives an IPv4-in-IPv6 packet from an lwB4, it de- 492 capsulates the IPv6 header and verifies the source addresses and port 493 in the binding table. If both the source IPv4 and IPv6 addresses 494 match a single entry in the binding table and the source port is in 495 the allowed port-set for that entry, the lwAFTR forwards the packet 496 to the IPv4 destination. 498 If no match is found (e.g., no matching IPv4 address entry, port out 499 of range, etc.), the lwAFTR MUST discard or implement a policy (such 500 as redirection) on the packet. An ICMPv6 type 1, code 5 (source 501 address failed ingress/egress policy) error message MAY be sent back 502 to the requesting lwB4. The ICMP policy SHOULD be configurable. 504 When the lwAFTR receives an inbound IPv4 packet, it uses the IPv4 505 destination address and port to lookup the destination lwB4's IPv6 506 address in its binding table. If a match is found, the lwAFTR 507 encapsulates the IPv4 packet. The source is the lwAFTR's IPv6 508 address and the destination is the lwB4's IPv6 address from the 509 matched entry. Then, the lwAFTR forwards the packet to the lwB4 510 natively over the IPv6 network. 512 If no match is found, the lwAFTR MUST discard the packet. An ICMPv4 513 type 3, code 1 (Destination unreachable, host unreachable) error 514 message MAY be sent back. The ICMP policy SHOULD be configurable. 516 The lwAFTR MUST support hairpinning of traffic between two lwB4s, by 517 performing de-capsulation and re-encapsulation of packets. The 518 hairpinning policy MUST be configurable. 520 7. Additional IPv4 address and Port Set Provisioning Mechanisms 522 In addition to the DHCPv6 based mechanism described in section 5.1, 523 several other IPv4 provisioning protocols have been suggested. These 524 protocols MAY be implemented. These alternatives include: 526 o DHCPv4 over DHCPv6: [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes 527 implementing DHCPv4 messages over an IPv6 only service providers 528 network. This enables leasing of IPv4 addresses and makes DHCPv4 529 options available to the DHCPv4 over DHCPv6 client. 531 o PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve 532 a restricted IPv4 address and a set of ports. 534 In a Lightweight 4over6 domain, the binding information MUST be 535 aligned between the lwB4s, the lwAFTRs and the provisioning server. 537 8. ICMP Processing 539 ICMP does not work in an address sharing environment without special 540 handling [RFC6269]. Due to the port-set style address sharing, 541 Lightweight 4over6 requires specific ICMP message handling not 542 required by DS-Lite. 544 The following behavior SHOULD be implemented by the lwAFTR to provide 545 ICMP error handling and basic remote IPv4 service diagnostics for a 546 port restricted CPE: for inbound ICMP messages, the lwAFTR MAY behave 547 in two modes: 549 Either: 551 1. Check the ICMP Type field. 553 2. If the ICMP type is set to 0 or 8 (echo reply or request), then 554 the lwAFTR MUST take the value of the ICMP identifier field as 555 the source port, and use this value to lookup the binding table 556 for an encapsulation destination. If a match is found, the 557 lwAFTR forwards the ICMP packet to the IPv6 address stored in the 558 entry; otherwise it MUST discard the packet. 560 3. If the ICMP type field is set to any other value, then the lwAFTR 561 MUST use the method described in REQ-3 of [RFC5508] to locate the 562 source port within the transport layer header in ICMP packet's 563 data field. The destination IPv4 address and source port 564 extracted from the ICMP packet are then used to make a lookup in 565 the binding table. If a match is found, it MUST forward the ICMP 566 reply packet to the IPv6 address stored in the entry; otherwise 567 it MUST discard the packet. 569 Or: 571 o Discard all inbound ICMP messages. 573 The ICMP policy SHOULD be configurable. 575 The lwB4 SHOULD implement the requirements defined in [RFC5508] for 576 ICMP forwarding. For ICMP echo request packets originating from the 577 private IPv4 network, the lwB4 SHOULD implement the method described 578 in [RFC6346] and use an available port from its port-set as the ICMP 579 Identifier. 581 For both the lwAFTR and the lwB4, ICMPv6 MUST be handled as described 582 in [RFC2473]. 584 9. Security Considerations 586 As the port space for a subscriber shrinks due to address sharing, 587 the randomness for the port numbers of the subscriber is decreased 588 significantly. This means it is much easier for an attacker to guess 589 the port number used, which could result in attacks ranging from 590 throughput reduction to broken connections or data corruption. 592 The port-set for a subscriber can be a set of contiguous ports or 593 non-contiguous ports. Contiguous port-sets do not reduce this 594 threat. However, with non-contiguous port-set (which may be 595 generated in a pseudo-random way [RFC6431]), the randomness of the 596 port number is improved, provided that the attacker is outside the 597 Lightweight 4over6 domain and hence does not know the port-set 598 generation algorithm. 600 More considerations about IP address sharing are discussed in 601 Section 13 of [RFC6269], which is applicable to this solution. 603 10. IANA Considerations 605 This document does not include an IANA request. 607 11. Author List 609 The following are extended authors who contributed to the effort: 611 Jianping Wu 613 Tsinghua University 615 Department of Computer Science, Tsinghua University 616 Beijing 100084 618 P.R.China 620 Phone: +86-10-62785983 622 Email: jianping@cernet.edu.cn 624 Peng Wu 626 Tsinghua University 628 Department of Computer Science, Tsinghua University 630 Beijing 100084 632 P.R.China 634 Phone: +86-10-62785822 636 Email: pengwu.thu@gmail.com 638 Qi Sun 640 Tsinghua University 642 Beijing 100084 644 P.R.China 646 Phone: +86-10-62785822 648 Email: sunqi@csnet1.cs.tsinghua.edu.cn 650 Chongfeng Xie 652 China Telecom 654 Room 708, No.118, Xizhimennei Street 656 Beijing 100035 658 P.R.China 660 Phone: +86-10-58552116 662 Email: xiechf@ctbri.com.cn 663 Xiaohong Deng 665 France Telecom 667 Email: xiaohong.deng@orange.com 669 Cathy Zhou 671 Huawei Technologies 673 Section B, Huawei Industrial Base, Bantian Longgang 675 Shenzhen 518129 677 P.R.China 679 Email: cathyzhou@huawei.com 681 Alain Durand 683 Juniper Networks 685 1194 North Mathilda Avenue 687 Sunnyvale, CA 94089-1206 689 USA 691 Email: adurand@juniper.net 693 Reinaldo Penno 695 Cisco Systems, Inc. 697 170 West Tasman Drive 699 San Jose, California 95134 701 USA 703 Email: repenno@cisco.com 705 Alex Clauberg 707 Deutsche Telekom AG 709 GTN-FM4 710 Landgrabenweg 151 712 Bonn, CA 53227 714 Germany 716 Email: axel.clauberg@telekom.de 718 Lionel Hoffmann 720 Bouygues Telecom 722 TECHNOPOLE 724 13/15 Avenue du Marechal Juin 726 Meudon 92360 728 France 730 Email: lhoffman@bouyguestelecom.fr 732 Maoke Chen 734 FreeBit Co., Ltd. 736 13F E-space Tower, Maruyama-cho 3-6 738 Shibuya-ku, Tokyo 150-0044 740 Japan 742 Email: fibrib@gmail.com 744 12. Acknowledgement 746 The authors would like to thank Ole Troan, Ralph Droms and Suresh 747 Krishnan for their comments and feedback. 749 This document is a merge of three documents: 750 [I-D.cui-softwire-b4-translated-ds-lite], [I-D.zhou-softwire-b4-nat] 751 and [I-D.penno-softwire-sdnat]. 753 13. References 755 13.1. Normative References 757 [I-D.ietf-softwire-map-dhcp] 758 Mrugalski, T., Troan, O., Dec, W., Bao, C., 759 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 760 for configuration of Softwire Address and Port Mapped 761 Clients", draft-ietf-softwire-map-dhcp-05 (work in 762 progress), October 2013. 764 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 765 E. Lear, "Address Allocation for Private Internets", BCP 766 5, RFC 1918, February 1996. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 772 IPv6 Specification", RFC 2473, December 1998. 774 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 775 for IPv6 Hosts and Routers", RFC 4213, October 2005. 777 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 778 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 779 April 2009. 781 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 782 Stack Lite Broadband Deployments Following IPv4 783 Exhaustion", RFC 6333, August 2011. 785 13.2. Informative References 787 [I-D.cui-softwire-b4-translated-ds-lite] 788 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 789 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 790 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 791 (work in progress), February 2013. 793 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 794 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 795 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 796 dhcpv4-over-dhcpv6-02 (work in progress), October 2013. 798 [I-D.ietf-pcp-port-set] 799 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 800 T., and S. Perreault, "Port Control Protocol (PCP) 801 Extension for Port Set Allocation", draft-ietf-pcp-port- 802 set-03 (work in progress), October 2013. 804 [I-D.ietf-softwire-map-dhcp] 805 Mrugalski, T., Troan, O., Dec, W., Bao, C., 806 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 807 for configuration of Softwire Address and Port Mapped 808 Clients", draft-ietf-softwire-map-dhcp-05 (work in 809 progress), October 2013. 811 [I-D.ietf-softwire-map] 812 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 813 Murakami, T., and T. Taylor, "Mapping of Address and Port 814 with Encapsulation (MAP)", draft-ietf-softwire-map-08 815 (work in progress), August 2013. 817 [I-D.ietf-softwire-public-4over6] 818 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 819 IPv4 over IPv6 Access Network", draft-ietf-softwire- 820 public-4over6-10 (work in progress), July 2013. 822 [I-D.ietf-softwire-unified-cpe] 823 Boucadair, M., Farrer, I., Perreault, S., and S. 824 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 825 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 827 [I-D.penno-softwire-sdnat] 828 Penno, R., Durand, A., Hoffmann, L., and A. Clauberg, 829 "Stateless DS-Lite", draft-penno-softwire-sdnat-02 (work 830 in progress), March 2012. 832 [I-D.zhou-softwire-b4-nat] 833 Zhou, C., Boucadair, M., and X. Deng, "NAT offload 834 extension to Dual-Stack lite", draft-zhou- 835 softwire-b4-nat-04 (work in progress), October 2011. 837 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 838 Address Translator (Traditional NAT)", RFC 3022, January 839 2001. 841 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 842 Roberts, "Issues with IP Address Sharing", RFC 6269, June 843 2011. 845 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 846 IPv4 Address Shortage", RFC 6346, August 2011. 848 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 849 T. Tsou, "Huawei Port Range Configuration Options for PPP 850 IP Control Protocol (IPCP)", RFC 6431, November 2011. 852 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 853 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 854 2013. 856 Authors' Addresses 858 Yong Cui 859 Tsinghua University 860 Beijing 100084 861 P.R.China 863 Phone: +86-10-62603059 864 Email: yong@csnet1.cs.tsinghua.edu.cn 866 Qiong Sun 867 China Telecom 868 Room 708, No.118, Xizhimennei Street 869 Beijing 100035 870 P.R.China 872 Phone: +86-10-58552936 873 Email: sunqiong@ctbri.com.cn 875 Mohamed Boucadair 876 France Telecom 877 Rennes 35000 878 France 880 Email: mohamed.boucadair@orange.com 882 Tina Tsou 883 Huawei Technologies 884 2330 Central Expressway 885 Santa Clara, CA 95050 886 USA 888 Phone: +1-408-330-4424 889 Email: tena@huawei.com 890 Yiu L. Lee 891 Comcast 892 One Comcast Center 893 Philadelphia, PA 19103 894 USA 896 Email: yiu_lee@cable.comcast.com 898 Ian Farrer 899 Deutsche Telekom AG 900 GTN-FM4,Landgrabenweg 151 901 Bonn, NRW 53227 902 Germany 904 Email: ian.farrer@telekom.de