idnits 2.17.1 draft-cui-softwire-b4-translated-ds-lite-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6333]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (February 25, 2013) is 4040 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) == Unused Reference: 'RFC3484' is defined on line 697, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 6269 ** Downref: Normative reference to an Experimental RFC: RFC 6346 ** Downref: Normative reference to an Informational RFC: RFC 6431 == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-10 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-05 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-04 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-04 == Outdated reference: A later version (-02) exists of draft-sun-dhc-port-set-option-00 == Outdated reference: A later version (-10) exists of draft-tsou-pcp-natcoord-09 Summary: 6 errors (**), 0 flaws (~~), 10 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: August 29, 2013 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 February 25, 2013 16 Lightweight 4over6: An Extension to the DS-Lite Architecture 17 draft-cui-softwire-b4-translated-ds-lite-11 19 Abstract 21 DS-Lite [RFC6333] describes an architecture for transporting IPv4 22 packets over an IPv6 network. This document specifies an extension 23 to DS-Lite called Lightweight 4over6 which moves the Network Address 24 Translation function from the DS-Lite AFTR to the B4, removing the 25 requirement for a Carrier Grade NAT function in the AFTR. This 26 reduces the amount of centralized state that must be held to a per- 27 subscriber level. In order to delegate the NAPT function and make 28 IPv4 Address sharing possible, port-restricted IPv4 addresses are 29 allocated to the B4s. 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 August 19, 2013. 48 Copyright Notice 49 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Lightweight 4over6 Architecture . . . . . . . . . . . . . . . 5 68 5. Lightweight B4 Behavior . . . . . . . . . . . . . . . . . . . 7 69 5.1. Lightweight B4 Provisioning . . . . . . . . . . . . . . . 7 70 5.2. Lightweight B4 Data Plane Behavior . . . . . . . . . . . . 8 71 6. Lightweight AFTR Behavior . . . . . . . . . . . . . . . . . . 9 72 6.1. Binding Table Maintenance . . . . . . . . . . . . . . . . 9 73 6.2. lwAFTR Data Plane Behavior . . . . . . . . . . . . . . . . 10 74 7. Provisioning of IPv4 address and Port Set . . . . . . . . . . 11 75 8. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 11. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Dual-Stack Lite (DS-Lite, [RFC6333]) defines a model for providing 88 IPv4 access over an IPv6 network using two well-known technologies: 89 IP in IP [RFC2473] and Network Address Translation (NAT). The DS- 90 Lite architecture defines two major functional elements as follows: 92 Basic Bridging BroadBand element: A B4 element is a function 93 implemented on a dual-stack capable 94 node, either a directly connected 95 device or a CPE, that creates a 96 tunnel to an AFTR. 98 Address Family Transition Router: An AFTR element is the combination 99 of an IPv4-in-IPv6 tunnel endpoint 100 and an IPv4-IPv4 NAT implemented on 101 the same node. 103 As the AFTR performs the centralized NAT44 function, it dynamically 104 assigns public IPv4 addresses and ports to requesting host's traffic 105 (as described in [RFC3022]). To achieve this, the AFTR must 106 dynamically maintain per-flow state in the form of active NAPT 107 sessions. For service providers with a large number of B4 clients, 108 the size and associated costs for scaling the AFTR can quickly become 109 prohibitive. It can also place a large NAPT logging overhead upon 110 the service provider in countries where legal requirements mandate 111 this. 113 This document describes a mechanism called Lightweight 4 over 6 114 (lw4o6), which provides a solution for these problems. By relocating 115 the NAPT functionality from the centralized AFTR to the distributed 116 B4s, a number of benefits can be realised: 118 o NAPT44 functionality is already widely supported and used in 119 today's CPE devices. Lw4o6 uses this to provide private<->public 120 NAPT44, meaning that the service provider does not need a 121 centralized NAT44 function. 123 o The amount of state that must be maintained centrally in the AFTR 124 can be reduced from per-flow to per-subscriber. This reduces the 125 amount of resources (memory and processing power) necessary in the 126 AFTR. 128 o The reduction of maintained state results in a greatly reduced 129 logging overhead on the service provider. 131 Operator's IPv6 and IPv4 addressing architectures remain independent 132 of each other. Therefore, flexible IPv4/IPv6 addressing schemes can 133 be deployed. 135 Lightweight 4over6 provides a solution for a hub-and-spoke softwire 136 architecture only. It does not offer direct, meshed IPv4 137 connectivity between subscribers without packets traversing the AFTR. 138 If this type of meshed interconnectivity is required, 139 [I-D.ietf-softwire-map] provides a suitable solution. 141 The tunneling mechanism remains the same for DS-Lite and Lightweight 142 4over6. This document describes the changes to DS-Lite that are 143 necessary to implement Lightweight 4over6. These changes mainly 144 concern the configuration parameters and provisioning method 145 necessary for the functional elements. 147 Lightweight 4over6 features keeping per-subscriber state in the 148 service provider's network. It is categorized as Binding approach in 149 [I-D.bfmk-softwire-unified-cpe] which defines a unified IPv4-in-IPv6 150 Softwire CPE. 152 This document is an extended case, which covers address sharing for 153 [I-D.ietf-softwire-public-4over6]. It is also a variant of A+P 154 called Binding Table Mode (see Section 4.4 of [RFC6346]). 156 This document focuses on architectural considerations and 157 particularly on the expected behavior of the involved functional 158 elements and their interfaces. Deployment-specific issues are 159 discussed in a companion document. As such, discussions about 160 redundancy and provisioning policy are out of scope. 162 2. Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. Terminology 170 The document defines the following terms: 172 Lightweight 4over6 (lw4o6): Lightweight 4over6 is an IPv4-over-IPv6 173 hub and spoke mechanism, which extends 174 DS-Lite by moving the IPv4 translation 175 (NAPT44) function from the AFTR to the 176 B4. 178 Lightweight B4 (lwB4): A B4 element (Basic Bridging BroadBand 179 element [RFC6333]), which supports 180 Lightweight 4over6 extensions. An lwB4 181 is a function implemented on a dual- 182 stack capable node, (either a directly 183 connected device or a CPE), that 184 supports port-restricted IPv4 address 185 allocation, implements NAPT44 186 functionality and creates a tunnel to 187 an lwAFTR 189 Lightweight AFTR (lwAFTR): An AFTR element (Address Family 190 Transition Router element [RFC6333]), 191 which supports Lightweight 4over6 192 extension. An lwAFTR is an IPv4-in- 193 IPv6 tunnel endpoint which maintains 194 per-subscriber address binding only and 195 does not perform a NAPT44 function. 197 Restricted Port-Set: A non-overlapping range of allowed 198 external ports allocated to the lwB4 to 199 use for NAPT44. Source ports of IPv4 200 packets sent by the B4 must belong to 201 the assigned port-set. The port set is 202 used for all port aware IP protocols 203 (TCP, UDP, SCTP etc.) 205 Port-restricted IPv4 Address: A public IPv4 address with a restricted 206 port-set. In Lightweight 4over6, 207 multiple B4s may share the same IPv4 208 address, however, their port-sets must 209 be non-overlapping. 211 Throughout the remainder of this document, the terms B4/AFTR should 212 be understood to refer specifically to a DS-Lite implementation. The 213 terms lwB4/lwAFTR refer to a Lightweight 4over6 implementation. 215 4. Lightweight 4over6 Architecture 217 The Lightweight 4over6 architecture is functionally similar to DS- 218 Lite. lwB4s and an lwAFTR are connected through an IPv6-enabled 219 network. Both approaches use an IPv4-in-IPv6 encapsulation scheme to 220 deliver IPv4 connectivity services. The following figure shows the 221 data plane with main functional change between DS-Lite and lw4o6: 223 +--------+ +---------+ IPv4-in-IPv6 +------+ +-------------+ 224 |IPv4 LAN|---|lwB4/NAPT|===================|lwAFTR|------|IPv4 Internet| 225 +--------+ +---------+ +------+ +-------------+ 226 ^ | 227 +--------------------------+ 228 NAPT function relocated 229 to lwB4 in lw4o6 231 Figure 1 Lightweight 4over6 Data Plane Overview 233 There are three main components in the Lightweight 4over6 234 architecture: 236 o The lwB4, which performs the NAPT function and encapsulation/ 237 de-capsulation IPv4/IPv6. 239 o The lwAFTR, which performs the encapsulation/de-capsulation IPv4/ 240 IPv6. 242 o The provisioning system, which tells the lwB4 which IPv4 address 243 and port set to use. 245 The lwB4 differs from a regular B4 in that it now performs the NAPT 246 functionality. This means that it needs to be provisioned with the 247 public IPv4 address and port set it is allowed to use. This 248 information is provided though a provisioning mechanism such as DHCP, 249 PCP or TR-69. 251 The lwAFTR needs to know the binding between the IPv6 address of each 252 subscriber and the IPv4 address and port set allocated to that 253 subscriber. This information is used to perform ingress filtering 254 upstream and encapsulation downstream. Note that this is per- 255 subscriber state as opposed to per-flow state in the regular AFTR 256 case. 258 The consequence of this architecture is that the information 259 maintained by the provisioning mechanism and the one maintained by 260 the lwAFTR MUST be synchronized (See figure 2). The details of this 261 synchronization depend on the exact provisioning mechanism and will 262 be discussed in a companion draft. 264 The solution specified in this document allows to assign either a 265 full IPv4 address or shared IPv4 address to requesting CPEs. 266 [I-D.ietf-softwire-public-4over6] provides a mechanism supporting to 267 assign a full IPv4 address only, which could be referred to in this 268 case. 270 +------------+ 271 /-------|Provisioning|<-------\ 272 | +------------+ | 273 | | 274 V V 275 +--------+ +---------+ IPv4/IPv6 +------+ +-------------+ 276 |IPv4 LAN|---|lwB4/NAPT|===================|lwAFTR|------|IPv4 Internet| 277 +--------+ +---------+ +------+ +-------------+ 279 Figure 2 Lightweight 4over6 Provisioning Synchronization 281 5. Lightweight B4 Behavior 283 5.1. Lightweight B4 Provisioning 285 With DS-Lite, the B4 element only needs to be configured with a 286 single DS-Lite specific parameter so that it can set up the softwire 287 (the IPv6 address of the AFTR). Its IPv4 address can be taken from 288 the well-known range 192.0.0.0/29. 290 In lw4o6, due to the distributed nature of the NAPT function, a 291 number of lw4o6 specific configuration parameters must be provisioned 292 to the lwB4. These are: 294 o IPv6 Address for the lwAFTR 296 o IPv4 External (Public) Address for NAPT44 298 o Restricted port-set to use for NAPT44 300 An IPv6 address from an assigned prefix is also required for the lwB4 301 to use as the encapsulation source address for the softwire. 302 Normally, this is the lwB4's globally unique WAN interface address 303 which can be obtained via an IPv6 address allocation procedure such 304 as SLAAC, DHCPv6 or manual configuration. 306 In the event that the lwB4's encapsulation source address is changed 307 for any reason (such as the DHCPv6 lease expiring), the lwB4's 308 dynamic provisioning process must be re-initiated. 310 For learning the IPv6 address of the lwAFTR, the lwB4 SHOULD 311 implement the method described in section 5.4 of [RFC6333] and 312 implement the DHCPv6 option defined in [RFC6334]. Other methods of 313 learning this address are also possible. 315 An lwB4 MUST support dynamic port-restricted IPv4 address 316 provisioning. The potential port set algorithms are described in 318 [I-D.sun-dhc-port-set-option], and Section 5.1 of 319 [I-D.ietf-softwire-map]. Several different mechanisms can be used 320 for provisioning the lwB4 with its port-restricted IPv4 address such 321 as: DHCPv4, DHCPv6, PCP and PPP. Some alternatives are mentioned in 322 Section 7 of this document. 324 In this document, lwB4 can be a binding mode CPE. Its provisioning 325 method is RECOMMENDED to follow that is specified in section 3.3 of 326 [I-D.bfmk-softwire-unified-cpe], which will evolve to reflect the 327 consensus from DHC Working Group. 329 In the event that the lwB4 receives and ICMPv6 error message (type 1, 330 code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this 331 to mean that no matching entry in the lwAFTR's binding table has been 332 found. The lwB4 MAY then re-initiate the dynamic port-restricted 333 provisioning process. The lwB4's re-initiation policy SHOULD be 334 configurable. 336 The DNS considerations described in Section 5.5 and Section 6.4 of 337 [RFC6333] SHOULD be followed. 339 5.2. Lightweight B4 Data Plane Behavior 341 Several sections of [RFC6333] provide background information on the 342 B4's data plane functionality and MUST be implemented by the lwB4 as 343 they are common to both solutions. The relevant sections are: 345 5.2. Encapsulation Covering encapsulation and de- 346 capsulation of tunneled traffic 348 5.3. Fragmentation and Reassembly Covering MTU and fragmentation 349 considerations (referencing 350 [RFC2473]) 352 7.1. Tunneling Covering tunneling and traffic 353 class mapping between IPv4 and IPv6 354 (referencing [RFC2473] and 355 [RFC4213]) 357 The lwB4 element performs IPv4 address translation (NAPT44) as well 358 as encapsulation and de-capsulation. It runs standard NAPT44 359 [RFC3022] using the allocated port-restricted address as its external 360 IPv4 address and port numbers. 362 The lwB4 should behave as is depicted in (2.2) of section 3.2 of 363 [I-D.bfmk-softwire-unified-cpe] when it starts up. The working flow 364 of the lwB4 is illustrated with figure 3. 366 +-------------+ 367 | lwB4 | 368 +--------+ IPv4 |------+------| IPv4-in-IPv6 +----------+ 369 |IPv4 LAN|------->| |Encap.|-------------->|Configured| 370 | |<-------| NAPT | or |<--------------| lwAFTR | 371 +--------+ | |Decap.| +----------+ 372 +------+------+ 374 Figure 3 Working Flow of the lwB4 376 Internally connected hosts source IPv4 packets with an [RFC1918] 377 address. When the lwB4 receives such an IPv4 packet, it performs a 378 NAPT44 function on the source address and port by using the public 379 IPv4 address and a port number from the allocated port-set. Then, it 380 encapsulates the packet with an IPv6 header. The destination IPv6 381 address is the lwAFTR's IPv6 address and the source IPv6 address is 382 the lwB4's IPv6 tunnel endpoint address. Finally, the lwB4 forwards 383 the encapsulated packet to the configured lwAFTR. 385 When the lwB4 receives an IPv4-in-IPv6 packet from the lwAFTR, it de- 386 capsulates the IPv4 packet from the IPv6 packet. Then, it performs 387 NAPT44 translation on the destination address and port, based on the 388 available information in its local NAPT44 table. 390 The lwB4 is responsible for performing ALG functions (e.g., SIP, 391 FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP, 392 manual binding configuration, PCP) for the internal hosts. This 393 requirement is typical for NAPT44 gateways available today. 395 It is possible that a lwB4 is co-located in a host. In this case, 396 the functions of NAPT44 and encapsulation/de-capsulation are 397 implemented inside the host. 399 6. Lightweight AFTR Behavior 401 6.1. Binding Table Maintenance 403 The lwAFTR maintains an address binding table containing the binding 404 between the lwB4's IPv6 address, the allocated IPv4 address and 405 restricted port-set. Unlike the DS-Lite extended binding table 406 defined in section 6.6 of [RFC6333] which is a 5-tuple NAT table, 407 each entry in the Lightweight 4over6 binding table contains the 408 following 3-tuples: 410 o IPv6 Address for a single lwB4 411 o Public IPv4 Address 413 o Restricted port-set 415 The entry has two functions: the IPv6 encapsulation of inbound IPv4 416 packets destined to the lwB4 and the validation of outbound IPv4-in- 417 IPv6 packets received from the lwB4 for de-capsulation. 419 The lwAFTR does not perform NAPT and so does not need session 420 entries. 422 The lwAFTR MUST synchronize the binding information with the port- 423 restricted address provisioning process. If the lwAFTR does not 424 participate in the port-restricted address provisioning process, the 425 binding MUST be synchronized through other methods (e.g. out-of-band 426 static update). 428 If the lwAFTR participates in the port-restricted provisioning 429 process, then its binding table MUST be created as part of this 430 process. 432 For all provisioning processes, the lifetime of binding table entries 433 MUST be synchronized with the lifetime of address allocations. 435 6.2. lwAFTR Data Plane Behavior 437 Several sections of [RFC6333] provide background information on the 438 AFTR's data plane functionality and MUST be implemented by the lwAFTR 439 as they are common to both solutions. The relevant sections are: 441 6.2. Encapsulation Covering encapsulation and de- 442 capsulation of tunneled traffic 444 6.3. Fragmentation and Reassembly Fragmentation and re-assembly 445 considerations (referencing 446 [RFC2473]) 448 7.1. Tunneling Covering tunneling and traffic 449 class mapping between IPv4 and IPv6 450 (referencing [RFC2473] and 451 [RFC4213]) 453 When the lwAFTR receives an IPv4-in-IPv6 packet from an lwB4, it de- 454 capsulates the IPv6 header and verifies the source addresses and port 455 in the binding table. If both the source IPv4 and IPv6 addresses 456 match a single entry in the binding table and the source port in the 457 allowed port-set for that entry, the lwAFTR forwards the packet to 458 the IPv4 destination. 460 If no match is found (e.g., no matching IPv4 address entry, port out 461 of range, etc.), the lwAFTR MUST discard or implement a policy (such 462 as redirection) on the packet. An ICMPv6 type 1, code 5 (source 463 address failed ingress/egress policy) error message MAY be sent back 464 to the equesting lwB4. The ICMP policy SHOULD be configurable. 466 When the lwAFTR receives an inbound IPv4 packet, it uses the IPv4 467 destination address and port to lookup the destination lwB4's IPv6 468 address in its binding table. If a match is found, the lwAFTR 469 encapsulates the IPv4 packet. The source is the lwAFTR's IPv6 470 address and the destination is the lwB4's IPv6 address from the 471 matched entry. Then, the lwAFTR forwards the packet to the lwB4 472 natively over the IPv6 network. 474 If no match is found, the lwAFTR MUST discard the packet. An ICMPv4 475 type 3, code 1 (Destination unreachable, host unreachable) error 476 message MAY be sent back. The ICMP policy SHOULD be configurable. 478 The lwAFTR MUST support hairpinning of traffic between two lwB4s, by 479 performing de-capsulation and re-encapsulation of packets. The 480 hairpinning policy MUST be configurable. 482 7. Provisioning of IPv4 address and Port Set 484 There are several dynamically provisioning protocols for IPv4 address 485 and port set. These protocols MAY be implemented. Some possible 486 alternatives include: 488 o DHCP: Extending DHCP protocol MAY be used for the provisioning 489 [I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-softwire-map-dhcp]. 491 o PCP[I-D.ietf-pcp-base]: a lwB4 MAY use [I-D.tsou-pcp-natcoord] to 492 retrieve a restricted IPv4 address and a set of ports. 494 In a Lightweight 4over6 domain, the same provisioning mechanism MUST 495 be enabled in the lwB4s, the AFTRs and the provisioning server. 497 DHCP-based provisioning mechanism (DHCPv4/DHCPv6) is RECOMMENDED in 498 this document. The provisioning mechanism for port-restricted IPv4 499 address will evolve according to the consensus from DHC Working 500 Group. 502 8. ICMP Processing 504 ICMP does not work in an address sharing environment without special 505 handling [RFC6269]. Due to the port-set style address sharing, 506 Lightweight 4over6 requires specific ICMP message handling not 507 required by DS-Lite. 509 The following behavior SHOULD be implemented by the lwAFTR to provide 510 ICMP error handling and basic remote IPv4 service diagnostics for a 511 port restricted CPE: for inbound ICMP messages, the lwAFTR MAY behave 512 in two modes: 514 Either: 516 1. Check the ICMP Type field. 518 2. If the ICMP type is set to 0 or 8 (echo reply or request), then 519 the lwAFTR MUST take the value of the ICMP identifier field as 520 the source port, and use this value to lookup the binding table 521 for an encapsulation destination. If a match is found, the 522 lwAFTR forwards the ICMP packet to the IPv6 address stored in the 523 entry; otherwise it MUST discard the packet. 525 3. If the ICMP type field is set to any other value, then the lwAFTR 526 MUST use the method described in REQ-3 of [RFC5508] to locate the 527 source port within the transport layer header in ICMP packet's 528 data field. The destination IPv4 address and source port 529 extracted from the ICMP packet are then used to make a lookup in 530 the binding table. If a match is found, it MUST forward the ICMP 531 reply packet to the IPv6 address stored in the entry; otherwise 532 it MUST discard the packet. 534 Or: 536 o Discard all inbound ICMP messages. 538 The ICMP policy SHOULD be configurable. 540 The lwB4 SHOULD implement the requirements defined in [RFC5508] for 541 ICMP forwarding. For ICMP echo request packets originating from the 542 private IPv4 network, the lwB4 SHOULD implement the method described 543 in [RFC6346] and use an available port from its port-set as the ICMP 544 Identifier. 546 For both the lwAFTR and the lwB4, ICMPv6 MUST be handled as described 547 in [RFC2473]. 549 9. Security Considerations 551 As the port space for a subscriber shrinks due to address sharing, 552 the randomness for the port numbers of the subscriber is decreased 553 significantly. This means it is much easier for an attacker to guess 554 the port number used, which could result in attacks ranging from 555 throughput reduction to broken connections or data corruption. 557 The port-set for a subscriber can be a set of contiguous ports or 558 non-contiguous ports. Contiguous port-sets do not reduce this 559 threat. However, with non-contiguous port-set (which may be 560 generated in a pseudo-random way [RFC6431]), the randomness of the 561 port number is improved, provided that the attacker is outside the 562 Lightweight 4over6 domain and hence does not know the port-set 563 generation algorithm. 565 More considerations about IP address sharing are discussed in Section 566 13 of [RFC6269], which is applicable to this solution. 568 10. IANA Considerations 570 This document does not include an IANA request. 572 11. Author List 574 The following are extended authors who contributed to the effort: 576 Jianping Wu 577 Tsinghua University 578 Department of Computer Science, Tsinghua University 579 Beijing 100084 580 P.R.China 582 Phone: +86-10-62785983 583 Email: jianping@cernet.edu.cn 585 Peng Wu 586 Tsinghua University 587 Department of Computer Science, Tsinghua University 588 Beijing 100084 589 P.R.China 591 Phone: +86-10-62785822 592 Email: pengwu.thu@gmail.com 593 Qi Sun 594 Tsinghua University 595 Department of Computer Science, Tsinghua University 596 Beijing 100084 597 P.R.China 599 Phone: +86-10-62785822 600 Email: sunqi@csnet1.cs.tsinghua.edu.cn 602 Chongfeng Xie 603 China Telecom 604 Room 708, No.118, Xizhimennei Street 605 Beijing 100035 606 P.R.China 608 Phone: +86-10-58552116 609 Email: xiechf@ctbri.com.cn 611 Xiaohong Deng 612 France Telecom 614 Email: xiaohong.deng@orange.com 616 Cathy Zhou 617 Huawei Technologies 618 Section B, Huawei Industrial Base, Bantian Longgang 619 Shenzhen 518129 620 P.R.China 622 Email: cathyzhou@huawei.com 624 Alain Durand 625 Juniper Networks 626 1194 North Mathilda Avenue 627 Sunnyvale, CA 94089-1206 628 USA 629 Email: adurand@juniper.net 631 Reinaldo Penno 632 Cisco Systems, Inc. 633 170 West Tasman Drive 634 San Jose, California 95134 635 USA 637 Email: repenno@cisco.com 639 Alex Clauberg 640 Deutsche Telekom AG 641 GTN-FM4 642 Landgrabenweg 151 643 Bonn, CA 53227 644 Germany 646 Email: axel.clauberg@telekom.de 648 Lionel Hoffmann 649 Bouygues Telecom 650 TECHNOPOLE 651 13/15 Avenue du Marechal Juin 652 Meudon 92360 653 France 655 Email: lhoffman@bouyguestelecom.fr 657 Maoke Chen 658 FreeBit Co., Ltd. 659 13F E-space Tower, Maruyama-cho 3-6 660 Shibuya-ku, Tokyo 150-0044 661 Japan 663 Email: fibrib@gmail.com 665 12. Acknowledgement 667 The authors would like to thank Ole Troan, Ralph Droms and Suresh 668 Krishnan for their comments and feedback. 670 This document is a merge of three documents: 671 [I-D.cui-softwire-b4-translated-ds-lite], [I-D.zhou-softwire-b4-nat] 672 and [I-D.penno-softwire-sdnat]. 674 13. References 676 13.1. Normative References 678 [I-D.bfmk-softwire-unified-cpe] 679 Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 680 Softwire CPE", draft-bfmk-softwire-unified-cpe-02 (work in 681 progress), January 2013. 683 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 684 E. Lear, "Address Allocation for Private Internets", 685 BCP 5, RFC 1918, February 1996. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 691 IPv6 Specification", RFC 2473, December 1998. 693 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 694 Address Translator (Traditional NAT)", RFC 3022, 695 January 2001. 697 [RFC3484] Draves, R., "Default Address Selection for Internet 698 Protocol version 6 (IPv6)", RFC 3484, February 2003. 700 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 701 for IPv6 Hosts and Routers", RFC 4213, October 2005. 703 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 704 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 705 April 2009. 707 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 708 Roberts, "Issues with IP Address Sharing", RFC 6269, 709 June 2011. 711 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 712 Stack Lite Broadband Deployments Following IPv4 713 Exhaustion", RFC 6333, August 2011. 715 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 716 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 717 RFC 6334, August 2011. 719 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 720 IPv4 Address Shortage", RFC 6346, August 2011. 722 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 723 T. Tsou, "Huawei Port Range Configuration Options for PPP 724 IP Control Protocol (IPCP)", RFC 6431, November 2011. 726 13.2. Informative References 728 [I-D.cui-softwire-b4-translated-ds-lite] 729 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 730 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 731 Architecture", draft-cui-softwire-b4-translated-ds-lite-10 732 (work in progress), February 2013. 734 [I-D.ietf-dhc-dhcpv4-over-ipv6] 735 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 736 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in 737 progress), September 2012. 739 [I-D.ietf-pcp-base] 740 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 741 Selkirk, "Port Control Protocol (PCP)", 742 draft-ietf-pcp-base-29 (work in progress), November 2012. 744 [I-D.ietf-softwire-map] 745 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and 746 T. Murakami, "Mapping of Address and Port with 747 Encapsulation (MAP)", draft-ietf-softwire-map-04 (work in 748 progress), February 2013. 750 [I-D.ietf-softwire-map-dhcp] 751 Mrugalski, T., Troan, O., Dec, W., Bao, C., 752 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 753 for Mapping of Address and Port", 754 draft-ietf-softwire-map-dhcp-03 (work in progress), 755 February 2013. 757 [I-D.ietf-softwire-public-4over6] 758 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 759 IPv4 over IPv6 Access Network", 760 draft-ietf-softwire-public-4over6-04 (work in progress), 761 October 2012. 763 [I-D.penno-softwire-sdnat] 764 Penno, R., Durand, A., Hoffmann, L., and A. Clauberg, 765 "Stateless DS-Lite", draft-penno-softwire-sdnat-02 (work 766 in progress), March 2012. 768 [I-D.sun-dhc-port-set-option] 769 Sun, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, 770 "Dynamic Host Configuration Protocol (DHCP) Option for 771 Port Set Assignment", draft-sun-dhc-port-set-option-00 772 (work in progress), October 2012. 774 [I-D.tsou-pcp-natcoord] 775 Sun, Q., Boucadair, M., Deng, X., Zhou, C., Tsou, T., and 776 S. Perreault, "Using PCP To Coordinate Between the CGN and 777 Home Gateway", draft-tsou-pcp-natcoord-09 (work in 778 progress), November 2012. 780 [I-D.zhou-softwire-b4-nat] 781 Zhou, C., Boucadair, M., and X. Deng, "NAT offload 782 extension to Dual-Stack lite", 783 draft-zhou-softwire-b4-nat-04 (work in progress), 784 October 2011. 786 Authors' Addresses 788 Yong Cui 789 Tsinghua University 790 Department of Computer Science, Tsinghua University 791 Beijing 100084 792 P.R.China 794 Phone: +86-10-62603059 795 Email: yong@csnet1.cs.tsinghua.edu.cn 797 Qiong Sun 798 China Telecom 799 Room 708, No.118, Xizhimennei Street 800 Beijing 100035 801 P.R.China 803 Phone: +86-10-58552936 804 Email: sunqiong@ctbri.com.cn 805 Mohamed Boucadair 806 France Telecom 807 Rennes 35000 808 France 810 Email: mohamed.boucadair@orange.com 812 Tina Tsou 813 Huawei Technologies 814 2330 Central Expressway 815 Santa Clara, CA 95050 816 USA 818 Phone: +1-408-330-4424 819 Email: tena@huawei.com 821 Yiu L. Lee 822 Comcast 823 One Comcast Center 824 Philadelphia, PA 19103 825 USA 827 Email: yiu_lee@cable.comcast.com 829 Ian Farrer 830 Deutsche Telekom AG 831 GTN-FM4,Landgrabenweg 151 832 Bonn, NRW 53227 833 Germany 835 Email: ian.farrer@telekom.de