idnits 2.17.1 draft-boucadair-softwire-cgn-bypass-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 123 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2010) is 4947 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 (-11) exists of draft-ietf-softwire-dual-stack-lite-06 == Outdated reference: A later version (-01) exists of draft-boucadair-dispatch-ipv6-atypes-00 == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-ds-lite-tunnel-option-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: April 11, 2011 J. Song 6 Q. Niu 7 ZTE Corporation 8 October 8, 2010 10 Procedure to bypass DS-Lite AFTR 11 draft-boucadair-softwire-cgn-bypass-03.txt 13 Abstract 15 This document proposes a solution to avoid the use of two stateful 16 DS-Lite AFTR devices when both end-points are located behind 17 different AFTR devices. For this purpose a new IPv6 extension 18 header, called Tunnel Endpoint Extension Header (TEEH), is defined. 19 The proposed procedure encourages the use of IPv6 between DS-Lite 20 AFTR nodes as a means to avoid the unnecessary crossing of AFTR 21 devices. A Flow Label based solution is also described. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 11, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.3. Contribution of this Draft . . . . . . . . . . . . . . . . 5 79 2. Overall Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Tunnel Endpoint Extension Header . . . . . . . . . . . . . . . 7 81 4. AFTR Bypass Procedure . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.2. Operational Mode . . . . . . . . . . . . . . . . . . . . . 8 84 5. Flow Label Based Alternative . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Alternative Solution . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 1.1. Purpose 98 The main purpose of this document is to investigate solutions to 99 avoid the solicitation of some of the (AFTR-embedded) NAT 100 capabilities along the path between two hosts located behind AFTR 101 devices. 103 The advantages of this procedure include: 105 o Better one-way delay: No need to check the payload in the 106 originating AFTR and no need to execute ALG operations twice; 108 o Optimised routing path; 110 o Better use of available AFTR resources; 112 o Enhance robustness: an AFTR device is withdrawn from the data 113 path. The stateful nature of DS-Lite AFTR devices will affect the 114 overall performance of the communication. This performance may be 115 even more affected when two AFTR devices need to be crossed to 116 establish the communication. 118 1.2. Terminology 120 Within this memo, the term AFTR is used to refer to both following 121 schemes: 123 o an AFTR function embedded in a router, and/or 125 o a standalone AFTR with limited routing capabilities (redirection 126 capabilities to the AFTR are being enabled in an external router). 128 An outbound AFTR is referred to as Source AFTR. 130 An inbound AFTR is called a Target AFTR. 132 In the example illustrated in Figure 1, if we suppose that A 133 initiates a communication towards B, AFTR1 is the Source AFTR and 134 AFTR2 is the Target AFTR. 136 "===" in the figure represents flows and not links. Furthermore, 137 AFTRs may not be part of the optimal routing path between A and B. 138 +-+ +-----+ +-----+ +-+ 139 |A|====IPv4-in-IPv6==>|AFTR1|=============|AFTR2|===IPv4-in-IPv6===>|B| 140 +-+ +-----+ +-----+ +-+ 141 Source AFTR Target AFTR 143 Figure 1: Source and Target AFTR 145 1.3. Contribution of this Draft 147 This document proposes a solution to avoid invoking NAT capabilities 148 when several DS-Lite AFTR devices [I-D.ietf-softwire-dual-stack-lite] 149 are involved in the data path. This document encourages the use of 150 IPv6 for forwarding traffic between two AFTR devices. 152 This memo focuses primarily on the AFTR devices deployed in the same 153 administrative domain. AFTRs located in distinct administrative 154 domains are out of scope. 156 This document does not make any assumption on the services that may 157 require the establishment of direct communications between hosts 158 located behind AFTR devices. Examples of services would be P2P or 159 hosting FTP/HTTP/SIP server behind a DS-Lite CPE. 161 In order to offload AFTR devices, application-specific solutions 162 (e.g., [I-D.carpenter-behave-referral-object] 163 [I-D.boucadair-mmusic-altc], [I-D.boucadair-dispatch-ipv6-atypes]) 164 may be required to be implemented in order to prefer native IPv6 165 communications rather than crossing AFTR devices. 167 The implementation of the proposed procedure is not motivated in a 168 context where the percentage of traffic involving two AFTR devices is 169 minor (e.g., 1%). Nevertheless, as a side effect, Tunnel Endpoint 170 Extension Header (TEEH) (Section 3) may be used to withdraw an AFTR 171 from the data path, when both participants are managed by the same 172 AFTR. 174 When TEEH is not supported, Two alternatives solutions are described 175 in Section 5 and Appendix A. 177 2. Overall Scenarios 179 This section provides an overview of targeted scenarios. 181 Figure 2 illustrates the communication between two hosts that are 182 located behind an AFTR device. Two NAT operations are required to be 183 performed for the establishment of successful communication between A 184 and B. The stateful nature of a DS-Lite AFTR device will presumably 185 affect the overall performance of the communication. This 186 performance may be even more affected when two AFTR devices need to 187 be crossed to establish the communication. 189 Prior to sending datagrams to B, A has retrieved the IPv4 public 190 address of B owing to DNS resolution, third party referral, etc. 191 +-+ +-----+ +-----+ +-+ 192 |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| 193 +-+ +-----+ +-----+ +-+ 194 NAT44 NAT44 196 Figure 2: Nominal behaviour 198 A first optimisation scenario is shown in Figure 3 where NAT 199 capabilities of the Source AFTR are not solicited. A second 200 optimisation scenario is shown in Figure 4 where NAT capabilities of 201 the Target AFTR are not solicited. The latter is not a valid 202 scenario since the destination is seen with a public IPv4 address 203 which is managed by the Target AFTR (consequently, a NAT44 state must 204 be instantiated in the Target AFTR). The last configuration, 205 illustrated in Figure 5, aims at avoiding the use of NAT capabilities 206 in both Source and Target AFTRs. This configuration is impossible to 207 implement since the remote destination must always be seen with an 208 external public IPv4 address (and/or an IPv6 one). Having an 209 external IPv4 address means that a AFTR has assigned an IPv4 address 210 and port number for that host. Therefore, all the incoming IPv4 211 traffic must cross that AFTR. 213 +-+ +-----+ +-----+ +-+ 214 |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| 215 +-+ +-----+ +-----+ +-+ 216 No_NAT44 NAT44 218 Figure 3: Avoid Source NAT44 220 +-+ +-----+ +-----+ +-+ 221 |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| 222 +-+ +-----+ +-----+ +-+ 223 NAT44 No_NAT44 225 Figure 4: Avoid Target NAT44 227 +-+ +-----+ +-----+ +-+ 228 |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| 229 +-+ +-----+ +-----+ +-+ 230 No_NAT44 No_NAT44 232 Figure 5: Avoid all NAT44 234 3. Tunnel Endpoint Extension Header 236 TEEH is a new IPv6 extension header which is used to inform the 237 remote party about the destination IPv6 address to be used when 238 issuing a response. Particularly, TEEH is used by the Source AFTR to 239 inform the Target AFTR about the IPv6 address of a customer's device 240 attached to the Source AFTR. Therefore, the Target AFTR acts as an 241 inbound AFTR for that customer's device. 243 The format of the Tunnel Endpoint header is shown in Figure 6. 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Next Header | Hdr Ext Len | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 248 | | 249 . . 250 . IPv6 Tunnel Endpoint . 251 . . 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 [NOTE: the format of TEEH may change in the next version of the 256 document to include other information such as the scope for instance] 258 Figure 6: Tunnel Endpoint Extension Header 260 The description of the fields is as follows: 262 o Next Header (8-bit): Identifies the type of header immediately 263 following the TEEH header. 265 o Hdr Ext Len (8-bit, unsigned integer): Length of the Tunnel 266 Endpoint header in 8-octet units, not including the first 8 267 octets. 269 o IPv6 Tunnel Endpoint: Encloses an IPv6 address that should be used 270 as source of the encapsulated IPv4-in-IPv6 response. This field 271 must be padded to ensure that the TEEH length is a multiple of 8 272 octets. 274 When TEEH is included in a received IPv4-in-IPv6 datagram, the answer 275 SHOULD be sent to the IPv6 address conveyed in the TEEH. 277 When TEEH is inserted by a AFTR in an IPv4-in-IPv6 datagram sent to a 278 customer's device, the IPv6 address included in the TEEH SHOULD be 279 used as destination IPv6 address of subsequent IPv4-in-IPv6 messages. 281 4. AFTR Bypass Procedure 283 4.1. Overview 285 Each CPE (which embeds a B4 function) is notified of the IPv6 286 reachability information of (one of) the available DS-Lite AFTRs 287 (e.g., using [I-D.ietf-softwire-ds-lite-tunnel-option]). In 288 addition, the CPE must support at least one encapsulation scheme to 289 convey privately-addressed IPv4 traffic into IPv6 datagrams. The CPE 290 behaves as defined in [I-D.ietf-softwire-dual-stack-lite]. 292 A dedicated IPv6 prefix (pref6_aftr) is used to convey the traffic 293 between AFTR nodes. 295 The following configuration tasks should be undertaken: 297 o Each AFTR is provided with an IPv4 address pool (IPv4@) for its 298 NAT operations; 300 o An IPv4-Converted IPv6 prefix [I-D.ietf-behave-address-format] is 301 also assigned to each AFTR. This IPv6 prefix embeds the IPv4 net: 302 pref6_aftr+IPv4@. 304 o This IPv6 prefix is injected in a routing protocol (IGP/MP-BGP/ 305 i-BGP, or softwire full mesh is used between AFTRs). This route 306 announcement is assumed to be performed by the AFTR itself or by 307 the router which is responsible for redirecting the traffic to a 308 AFTR. When pref6_aftr+IPv4@ is found on routing table, it is used 309 as a "hint" to detect that the IPv4 address is provisioned on a 310 AFTR device. 312 An operational mode to bypass an AFTR is described in Section 4.2. 314 4.2. Operational Mode 316 IPv4-in-IPv6 encapsulated datagrams issued by a CPE are received by 317 an AFTR device (Step 1). This AFTR de-capsulates the datagram and 318 retrieves the destination IPv4 address. Then, it proceeds to a route 319 lookup to check whether a route towards "pref6_aftr+destination 320 IPv4@" is installed. If not, it proceeds with traditional NAT 321 operations. Otherwise (i.e., a route is found. This means that the 322 destination is located behind an AFTR), no NAT44 state is 323 instantiated by the Source AFTR. The datagram is then encapsulated 324 in IPv6 datagram with an IPv6 destination address equal to 325 "pref6_aftr+destination IPv4 @::x" (refer to 326 [I-D.ietf-behave-address-format] for more information on how to build 327 IPv4-Converted IPv6 addresses). 329 As for the source IPv6 address of the encapsulated datagram, two 330 schemes may be envisaged: 332 (1) Maintain the same source IPv6 address as per the datagram 333 received from the customer's device. The deployment of this 334 alternative requires the activation of security association to 335 secure the exchange between the Source and Target AFTR. A trust 336 relationship must be configured. 338 (2) A new extension header (called TEEH for Tunnel Endpoint 339 Extension Header, defined in Figure 6) is inserted to indicate 340 where to send the response back. The value of the extension 341 header is an IPv6 address of the source CPE (as stored in the 342 Source AFTR). 344 The datagram is forwarded to the next hop until being delivered to a 345 Target AFTR (Step 2). 347 - If a NAT entry is instantiated on that AFTR, the datagram is 348 processed. Additionally, the source IPv6 address of the received 349 datagram or the content of the TEEH is stored by the AFTR. This 350 information will be used to send back the response. 352 In addition to re-writing destination IPv4 address+port (i.e., 353 DNAPT for Destination NAPT), the IPv4 source address and the port 354 number are also modified (referred to as SNAPT for Source NAPT). 355 The translation of the source IPv4 address is required to avoid 356 overlapping private IPv4 addressing in the destination home realm. 357 A public IPv4 address belonging to the Target AFTR pool is used to 358 enforce SNAPT. This SNAPT operation does not alter the number of 359 sessions that may be maintained by a given AFTR. 361 The resulting IPv4 datagram is then encapsulated in IPv6 and 362 forwarded to its final destination (i.e., B in Figure 7) (Step 3). 364 An AFTR must be configured to accept TEEH only when it is issued 365 by other AFTR devices. A filtering rule based on the source IPv6 366 address MAY be configured. 368 - Otherwise, the datagram is rejected/dropped/silently discarded. 370 Figure 7 illustrates the occurred flow exchanges. 372 +-----------------+ +-----------------+ +-------------------+ 373 |Src=@IPv6_CPE_A | |Src=@IPv6_aftr_s | | Src=@IPv6_dslite2 | 374 |Dst=@IPv6_dslite1| |Dst=@IPv6_1.2.3.4| | Dst=@IPv6_CPE_B | 375 | | |TEEH=@IPv6_CPE_A | | | 376 | +-------------+ | | +-------------+ | | +---------------+ | 377 | |Src=10.1.1.1 | | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | 378 | |Dst=1.2.3.4 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | 379 | +-------------+ | | +-------------+ | | +---------------+ | 380 +-----------------+ +-----------------+ +-------------------+ 381 | | | 382 +-+ v +-----+ v +-----+ v +-+ 383 |A|====IPv4-in-IPv6==>|AFTR1|====IPv4-inIPv6==>|AFTR2|====IPv4-in-IPv6===>|B| 384 +-+ (1) +-----+ (2) +-----+ (3) +-+ 385 ^ ^ 386 | | 387 +--------------+ +--------------------------------+ 388 | No NAT state | | NAT state | 389 +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | 390 |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| 391 +--------------------------------+ 393 pa, pb, pc and pd are port numbers. Only an excerpt of the NAT table 394 is shown, IPv6 addresses are also maintained in the NAT table. 396 Figure 7: Outbound traffic 398 As for the response, B encapsulates IPv4 traffic in IPv6 datagrams 399 that are forwarded to the AFTR as illustrated in Figure 8 and 400 Figure 9 (Step 4). The AFTR then proceeds to NAT operations (both 401 DNAPT and SNAPT). The resulting IPv4 traffic is then encapsulated in 402 IPv6 and corresponding IPv6 datagrams are then forwarded to the IPv6 403 address of the remote destination as maintained in the NAT tables 404 (Step 5). TEEH may be inserted to indicate the destination IPv6 405 address to be used for the subsequent messages (see Figure 8). 406 Figure 9 shows the exchanged flows when TEEH is not used. 408 +------------------+ +-------------------+ 409 | Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | 410 | Dst=@IPv6_CPE_A | | Dst=@IPv6_dslite2 | 411 |TEEH=@IPv6_aftr2_s| | | 412 | +-------------+ | | +---------------+ | 413 | |Src=1.2.3.4 | | | |Src=192.168.1.1| | 414 | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | 415 | +-------------+ | | +---------------+ | 416 +------------------+ +-------------------+ 417 | | 418 +-+ v +-----+ v +-+ 419 |A|<===================IPv4-inIPv6===============|AFTR2|<===IPv4-in-IPv6====|B| 420 +-+ (5) +-----+ (4) +-+ 422 Figure 8: Incoming traffic with Option Header 424 +-----------------+ +-------------------+ 425 |Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | 426 |Dst=@IPv6_CPE_A | | Dst=@IPv6_dslite2 | 427 | | | | 428 | +-------------+ | | +---------------+ | 429 | |Src=1.2.3.4 | | | |Src=192.168.1.1| | 430 | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | 431 | +-------------+ | | +---------------+ | 432 +-----------------+ +-------------------+ 433 | | 434 +-+ v +-----+ v +-+ 435 |A|<===================IPv4-inIPv6===============|AFTR2|<===IPv4-in-IPv6====|B| 436 +-+ (5) +-----+ (4) +-+ 438 Figure 9: Incoming traffic without Option Header 440 For the remaining exchanges, either A uses the IPv6 address of AFTR2 441 to send subsequent messages owing to the presence of TEEH option (see 442 Figure 8. The experienced behaviour is illustrated in Figure 10) or 443 it uses the default behavior and it sends all IPv4 traffic to its 444 attached AFTR1 (as illustrated in Figure 7). 446 A CPE must be configured to accept incoming IPv4-in-IPv6 traffic with 447 a source address belonging to an IPv6 prefix used to address AFTR 448 devices. 450 +-----------------+ +-------------------+ 451 |Src=@IPv6_CPE_A | | Src=@IPv6_dslite2 | 452 |Dst=@IPv6_dslite2| | Dst=@IPv6_CPE_B | 453 | | | | 454 | +-------------+ | | +---------------+ | 455 | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | 456 | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | 457 | +-------------+ | | +---------------+ | 458 +-----------------+ +-------------------+ 459 | | 460 +-+ v +-----+ v +-+ 461 |A|====================IPv4-inIPv6==============>|AFTR2|====IPv4-in-IPv6===>|B| 462 +-+ (6) +-----+ (7) +-+ 464 Figure 10: Withdraw Source CGN 466 As a result, NAT operations are enforced in one AFTR instead of two 467 nodes. One AFTR is withdrawn from the path. 469 5. Flow Label Based Alternative 471 This alternative aims at avoiding two NAT operations without 472 withdrawing an AFTR from the path and without adding a new IPv6 473 extension header. 475 Outbound flow exchanges are illustrated in Figure 11. Inbound flow 476 exchanges are shown in Figure 12. 478 IPv6 is used to convey traffic between AFTR nodes. IPv4-Converted 479 IPv6 addresses are used to detect whether the destination is also 480 managed by an AFTR. No NAT state is then instantiated in the Source 481 AFTR. Two AFTRs are maintained in the path but only one AFTR 482 maintains a NAT state. 484 AFTR assigns a sequence number (or index) for every softwire between 485 the AFTR and CPE. Sequence numbers must be generated by an AFTR to 486 uniquely identify a given softwire. 488 The source AFTR sends the sequence number filled in flow label field 489 of the IPv6 header to the target AFTR for indicting where to send the 490 response back. 492 +-----------------+ +-----------------+ +-------------------+ 493 |Src=@IPv6_CPE_A | |Src=@IPv6_aftr1_s| | Src=@IPv6_dslite2 | 494 |Dst=@IPv6_dslite1| |Dst=@IPv6_1.2.3.4| | Dst=@IPv6_CPE_B | 495 | | |Flow Lab= a | | | 496 | +-------------+ | | +-------------+ | | +---------------+ | 497 | |Src=10.1.1.1 | | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | 498 | |Dst=1.2.3.4 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | 499 | +-------------+ | | +-------------+ | | +---------------+ | 500 +-----------------+ +-----------------+ +-------------------+ 501 | | | 502 +-+ v +-----+ v +-----+ v +-+ 503 |A|====IPv4-in-IPv6==>|AFTR1|====IPv4-inIPv6==>|AFTR2|====IPv4-in-IPv6===>|B| 504 +-+ (1) +-----+ (2) +-----+ (3) +-+ 505 ^ ^ 506 | | 507 +--------------+ +--------------------------------+ 508 | No NAT state | | NAT state | 509 +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | 510 |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| 511 |Flow label: a | 512 +--------------------------------+ 514 Figure 11: Outbound traffic 516 These steps are followed: 518 o Step 1: A encapsulates its IPv4 datagram in IPv6 one and forwards 519 the encapsulated IPv4-in-IPv6 datagram to its outbound AFTR. 521 o Step 2: Once that datagram is received by AFTR1, it de- capsulates 522 it and retrieves the IPv4 datagram. Moreover, the destination 523 IPv4 address is returned. AFTR1 proceeds to a routing look up to 524 check whether a route to pref6_aftr+destination IPv4@ is 525 installed. If the answer is positive (i.e., the destination is 526 managed by an AFTR), AFTR1 does not proceed to any NAT44 527 operation. The IPv4 datagram is then encapsulated in an IPv6 one 528 and forwarded to AFTR2 (destination IPv6 address of the 529 encapsulated datagram is pref6_aftr+IPv4@). The sequence number a 530 of softwire between AFTR1 and A is filled in the Flow Label field 531 of the IPv6 packet. 533 o Step 3: AFTR2 receives that datagram. It de-capsulates the 534 received datagram and retrieves the enclosed IPv4 one. AFTR2 535 checks if a NAT state is already instantiated towards the 536 destination IPv4 address/port number. If the answer is positive, 537 then it proceeds to DNAPT and SNAPT. AFTR2 keeps the sequence 538 number a in the NAT table. The resulting datagram is then 539 forwarded to the IPv6 address of B (stored in AFTR2). 541 o Step 4: B replies as per DS-Lite specification. o 543 o Step 5: AFTR2 de-capsulates the received datagram and proceeds to 544 DNAPT and SNAPT. The resulting IPv4 datagram is then encapsulated 545 in an IPv6 one and the sequence number a is filled in the Flow 546 Label field. The IPv6 packet is forwarded to AFTR1. o 548 o Step 6: AFTR1 finds the softwire according sequence number a 549 carried in the Flow Label field, then it forwards the packet to A. 551 +-----------------+ +-----------------+ +-------------------+ 552 |Src=@IPv6_CPE_A | |Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | 553 |Dst=@IPv6_dslite1| |Dst=@IPv6_aftr1_s| | Dst=@IPv6_dslite2 | 554 | | |Flow Lab= a | | | 555 | +-------------+ | | +-------------+ | | +---------------+ | 556 | |Src=1.2.3.4 | | | |Src=1.2.3.4 | | | |Src=192.168.1.1| | 557 | |Dst=10.1.1.1 | | | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | 558 | +-------------+ | | +-------------+ | | +---------------+ | 559 +-----------------+ +-----------------+ +-------------------+ 560 | | | 561 +-+ v +-----+ v +-----+ v +-+ 562 |A|<===IPv4-in-IPv6==|AFTR1|<===IPv4-inIPv6====|AFTR2|<===IPv4-in-IPv6====|B| 563 +-+ (6) +-----+ (5) +-----+ (4) +-+ 564 ^ ^ 565 | | 566 +--------------+ +--------------------------------+ 567 | No NAT state | | NAT state | 568 +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | 569 |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| 570 |Flow label: a | 571 +--------------------------------+ 573 Figure 12: Inbound traffic 575 6. IANA Considerations 577 TBC. 579 7. Security Considerations 581 B4 element MUST be configured to accept incoming IPv4-in-IPv6 582 datagrams not issued by its outbound AFTR. All deployed AFTRs SHOULD 583 share a security association to secure the use of the TEEH option. 585 8. Acknowledgements 587 The author would like to thank P. Levis, M. Kassi Lahlou, E. Burgey 588 and D. Binet for their feedback and comments. 590 9. References 592 9.1. Normative References 594 [I-D.ietf-behave-address-format] 595 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 596 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 597 draft-ietf-behave-address-format-10 (work in progress), 598 August 2010. 600 [I-D.ietf-softwire-dual-stack-lite] 601 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 602 Stack Lite Broadband Deployments Following IPv4 603 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 604 in progress), August 2010. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 9.2. Informative References 611 [I-D.boucadair-dispatch-ipv6-atypes] 612 Boucadair, M., Noisette, Y., and A. Allen, "The atypes 613 media feature tag for Session Initiation Protocol (SIP)", 614 draft-boucadair-dispatch-ipv6-atypes-00 (work in 615 progress), July 2009. 617 [I-D.boucadair-mmusic-altc] 618 Boucadair, M., Kaplan, H., Gilman, R., and S. 619 Veikkolainen, "Session Description Protocol (SDP) 620 Alternate Connectivity (ALTC) Attribute", 621 draft-boucadair-mmusic-altc-01 (work in progress), 622 September 2010. 624 [I-D.carpenter-behave-referral-object] 625 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 626 K. Moore, "A Generic Referral Object for Internet 627 Entities", draft-carpenter-behave-referral-object-01 (work 628 in progress), October 2009. 630 [I-D.ietf-softwire-ds-lite-tunnel-option] 631 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 632 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 633 draft-ietf-softwire-ds-lite-tunnel-option-05 (work in 634 progress), September 2010. 636 Appendix A. Alternative Solution 638 This alternative aims at avoiding two NAT operations without 639 withdrawing a AFTR from the path. 641 Outbound flow exchanges are illustrated in Figure 13. Inbound flow 642 exchanges are shown in Figure 14. 644 IPv6 is used to convey traffic between AFTR nodes. IPv4-Converted 645 IPv6 addresses are used to detect whether the destination is also 646 managed by an AFTR. No NAT state is then instantiated in the Source 647 AFTR. Two AFTR are maintained in the path but only one AFTR 648 maintains a NAT state. 650 +-----------------+ +-----------------+ +-------------------+ 651 |Src=@IPv6_CPE_A | |Src=@IPv6_aftr1_s| | Src=@IPv6_dslite2 | 652 |Dst=@IPv6_dslite1| |Dst=@IPv6_1.2.3.4| | Dst=@IPv6_CPE_B | 653 | | | | | | 654 | +-------------+ | | +-------------+ | | +---------------+ | 655 | |Src=10.1.1.1 | | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | 656 | |Dst=1.2.3.4 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | 657 | +-------------+ | | +-------------+ | | +---------------+ | 658 +-----------------+ +-----------------+ +-------------------+ 659 | | | 660 +-+ v +-----+ v +-----+ v +-+ 661 |A|====IPv4-in-IPv6==>|AFTR1|====IPv4-inIPv6==>|AFTR2|====IPv4-in-IPv6===>|B| 662 +-+ (1) +-----+ (2) +-----+ (3) +-+ 663 ^ ^ 664 | | 665 +--------------+ +--------------------------------+ 666 | No NAT state | | NAT state | 667 +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | 668 |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| 669 +--------------------------------+ 671 Figure 13: Outbound traffic 673 The following steps are followed 675 o Step 1: A encapsulates it IPv4 datagram in IPv6 one and forwards 676 the encapsulated IPv4-in-IPv6 datagram to its outbound AFTR. The 677 IPv6 address/FQDN of its outbound AFTR is provisioned using DHCP 678 for instance. 680 o Step 2: Once that datagram is received by the AFTR1, its de- 681 capsulates it and retrieves the IPv4 datagram. Moreover, the 682 destination IPv4 address is returned. AFTR1 proceeds to a routing 683 look up to check whether a route to pref6_aftr+destination IPv4@ 684 is installed. If the answer is positive (i.e., the destination is 685 managed by an AFTR), AFTR1 does not proceeds to any NAT44 686 operation. The IPv4 datagram is then encapsulated in an IPv6 ones 687 and forwarded to AFTR2 (destination IPv6 address of the 688 encapsulated datagram is pref6_aftr+IPv4@). The source IPv6 689 address used by AFTR1 must identify unambiguously A. 691 o Step 3: AFTR2 receives that datagrams. It de-capsulates the 692 received datagram and retrieves the enclosed IPv4 one. AFTR2 693 checks if a NAT state is already instantiated towards the 694 destination IPv4 address/port number. If the answer is positive, 695 then it proceeds to DNAPT and SNAPT. The resulting datagram is 696 then forwards to the IPv6 address of B (stored in AFTR2). 698 o Step 4: B replies as per DS-Lite specifications. 700 o Step 5: AFTR2 de-capsulates the received datagrams and proceeds to 701 DNAPT and SNAPT. The resulting IPv4 datagram is then encapsulated 702 in an IPv6 one and forwarded to AFTR1. 704 o Step 6: AFTR1 checks its swapping states and forwards the packet 705 to A. 707 +-----------------+ +-----------------+ +-------------------+ 708 |Src=@IPv6_CPE_A | |Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | 709 |Dst=@IPv6_dslite1| |Dst=@IPv6_aftr1_s| | Dst=@IPv6_dslite2 | 710 | | | | | | 711 | +-------------+ | | +-------------+ | | +---------------+ | 712 | |Src=1.2.3.4 | | | |Src=1.2.3.4 | | | |Src=192.168.1.1| | 713 | |Dst=10.1.1.1 | | | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | 714 | +-------------+ | | +-------------+ | | +---------------+ | 715 +-----------------+ +-----------------+ +-------------------+ 716 | | | 717 +-+ v +-----+ v +-----+ v +-+ 718 |A|<===IPv4-in-IPv6==|AFTR1|<===IPv4-inIPv6====|AFTR2|<===IPv4-in-IPv6====|B| 719 +-+ (6) +-----+ (5) +-----+ (4) +-+ 720 ^ ^ 721 | | 722 +--------------+ +--------------------------------+ 723 | No NAT state | | NAT state | 724 +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | 725 |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| 726 +--------------------------------+ 728 Figure 14: Inbound traffic 730 Authors' Addresses 732 Mohamed Boucadair 733 France Telecom 734 Rennes 35000 735 France 737 Email: mohamed.boucadair@orange-ftgroup.com 739 Christian Jacquenet 740 France Telecom 741 Rennes 35000 742 France 744 Email: christian.jacquenet@orange-ftgroup.com 745 Jun Song 746 ZTE Corporation 747 No.68,Zijinghua Road, Yuhuatai District 748 Nanjing, Jiangsu Province 749 China 751 Email: song.jun@zte.com.cn 753 Qibo Niu 754 ZTE Corporation 755 No.68,Zijinghua Road, Yuhuatai District 756 Nanjing, Jiangsu Province 757 China 759 Email: niu.qibo@zte.com.cn