Network Working Group M. Boucadair Internet-Draft France Telecom Intended status: Standards Track December 16, 2009 Expires: June 19, 2010 Procedure to bypass DS-lite AFTR draft-boucadair-softwire-cgn-bypass-00.txt Abstract This document proposes a solution to avoid the use of two stateful CGN (a.k.a., AFTR in [I-D.ietf-softwire-dual-stack-lite]) devices when both participants (a.k.a., B4 element) are located behind different CGN devices. For this purpose a new IPv6 extension header, called Tunnel Endpoint Extension Header (TEEH), is defined. The proposed procedure encourages the use of IPv6 between AFTR nodes as a means to avoid the unnecessary crossing of AFTR devices. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010. Boucadair Expires June 19, 2010 [Page 1] Internet-Draft AFTR Bypass Procedure December 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Boucadair Expires June 19, 2010 [Page 2] Internet-Draft AFTR Bypass Procedure December 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Contribution of this Draft . . . . . . . . . . . . . . . . 5 2. Overall Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 3. AFTR Bypass Procedure . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Operational Mode . . . . . . . . . . . . . . . . . . . . . 7 4. Tunnel Endpoint Extension Header . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Alternative Solution . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Boucadair Expires June 19, 2010 [Page 3] Internet-Draft AFTR Bypass Procedure December 2009 1. Introduction 1.1. Purpose The main purpose of this memo is to investigate candidate solutions to avoid the solicitation of some of the (AFTR-embedded) NAT capabilities along the path between two hosts located behind CGN devices. The advantages of this procedure include: o Better one-way delay: No need to check the payload in the originating CGN and no need to execute ALG operations twice; o Optimised routing path; o Better use of CGN resources; o Enhance robustness: a CGN device is withdrawn from the data path. The stateful nature of DS-lite CGN devices will affect the overall performance of the communication. This performance may be even more affected when two AFTR devices need to be crossed to establish the communication. 1.2. Terminology Within this memo, the term CGN is used to denote both following schemes: o a CGN function embedded in a router, and/or o a standalone CGN with limited routing capabilities (redirection capabilities to the CGN are being enabled in an external router). An outbound CGN is referred to as Source CGN. An inbound CGN is called a Target CGN. In the example illustrated in Figure 1, if we suppose that A initiates a communication towards B, CGN1 is the Source CGN and CGN2 is the Target CGN. Boucadair Expires June 19, 2010 [Page 4] Internet-Draft AFTR Bypass Procedure December 2009 "===" in the figure represents flows and not links. Furthermore, CGNs may not be part of the optimal routing path between A and B. +-+ +----+ +----+ +-+ |A|====IPv4-in-IPv6===>|CGN1|==============|CGN2|====IPv4-in-IPv6===>|B| +-+ +----+ +----+ +-+ Source CGN Target CGN Figure 1: Source and Target CGN 1.3. Contribution of this Draft This draft proposes a framework to avoid invoking NAT capabilities when several DS-lite CGN devices (also known as AFTR in [I-D.ietf-softwire-dual-stack-lite]) are involved in the data path. This draft encourages the use of IPv6 for forwarding traffic between two CGN devices. This memo focuses primarily on the CGN/AFTR devices deployed in the same administrative domain. This document does not make any assumption on the services that may require the establishment of direct communications between hosts located behind CGN devices. Examples of services would be P2P or hosting FTP/HTTP/SIP server behind a DS-lite CPE. In order to offload CGN devices, application-specific solutions (e.g., [I-D.carpenter-behave-referral-object] [I-D.boucadair-mmusic-ccap], [I-D.boucadair-dispatch-ipv6-atypes]) are required to be implemented to prefer native IPv6 communications rather than crossing CGNs. The implementation of the procedure described in this document is not motivated in a context where the percentage of traffic involving two AFTR devices is minor (e.g., 1%). Nevertheless, as a side effect, Tunnel Endpoint Extension Header (TEEH) (Section 4) may be used to withdraw an AFTR from the data path, when both participants are managed by the same AFTR. When TEEH is not supported, an alternative solution is described in Appendix A. 2. Overall Scenarios This section provides an overview of targeted scenarios. Figure 2 illustrates the communication between two hosts that are located behind a CGN device. Two NAT operations are required to be Boucadair Expires June 19, 2010 [Page 5] Internet-Draft AFTR Bypass Procedure December 2009 performed for the establishment of successful communication between A and B. The stateful nature of a DS-lite AFTR device will presumably affect the overall performance of the communication. This performance may be even more affected when two AFTR devices need to be crossed to establish the communication. Prior to sending datagrams to B, A has retrieved the IPv4 public address of B owing to DNS resolution, third party referral, etc. +-+ +----+ +----+ +-+ |A|====IPv4-in-IPv6===>|CGN1|==============|CGN2|====IPv4-in-IPv6===>|B| +-+ +----+ +----+ +-+ NAT44 NAT44 Figure 2: Nominal behaviour A first optimisation scenario is shown in Figure 3 where NAT capabilities of the Source CGN are not solicited. A second optimisation scenario is shown in Figure 4 where NAT capabilities of the Target CGN are not solicited. The latter is not a valid scenario since the destination is seen with a public IPv4 address which is managed by the Target CGN (consequently, a NAT44 state must be instantiated in the Target CGN). The last configuration, illustrated in Figure 5, aims at avoiding the use of NAT capabilities in both Source and Target CGNs. This configuration is impossible to implement since the remote destination must always be seen with an external public IPv4 address (and/or an IPv6 one). Having an external IPv4 address means that a CGN has assigned an IPv4 address and port number for that host. Therefore, all the incoming IPv4 traffic must cross that CGN. +-+ +----+ +----+ +-+ |A|====IPv4-in-IPv6===>|CGN1|==============|CGN2|====IPv4-in-IPv6===>|B| +-+ +----+ +----+ +-+ No_NAT44 NAT44 Figure 3: Avoid Source NAT44 +-+ +----+ +----+ +-+ |A|====IPv4-in-IPv6===>|CGN1|==============|CGN2|====IPv4-in-IPv6===>|B| +-+ +----+ +----+ +-+ NAT44 No_NAT44 Figure 4: Avoid Target NAT44 Boucadair Expires June 19, 2010 [Page 6] Internet-Draft AFTR Bypass Procedure December 2009 +-+ +----+ +----+ +-+ |A|<===IPv4-in-IPv6===>|CGN1|==============|CGN2|<===IPv4-in-IPv6===>|B| +-+ +----+ +----+ +-+ No_NAT44 No_NAT44 Figure 5: Avoid all NAT44 3. AFTR Bypass Procedure 3.1. Overview Each CPE (which embeds a B4 function) is notified of the IPv6 reachability information of (one of) the available DS-lite CGNs (e.g., using [I-D.dhankins-softwire-tunnel-option]). In addition, the CPE must support at least one encapsulation scheme to convey privately-addressed IPv4 traffic into IPv6 datagrams. The CPE behaves as defined in [I-D.ietf-softwire-dual-stack-lite]. A dedicated IPv6 prefix (pref6_aftr) is used to convey the traffic between CGN nodes. The following configuration tasks should be undertaken: o Each AFTR is provided with an IPv4 address pool (IPv4@) for its NAT operations; o An IPv4-embedded IPv6 [I-D.ietf-behave-address-format] prefix is also assigned to each AFTR. This IPv6 prefix embeds the IPv4 net: pref6_aftr+IPv4@. o This IPv6 prefix is injected in a routing protocol (IGP/MP-BGP/ i-BGP, or softwire full mesh is used between AFTRs). This route announcement is assumed to be performed by the AFTR itself or by the router which is responsible for redirecting the traffic to a AFTR. When pref6_aftr+IPv4@ is found on routing table, it is used as a "hint" to detect that the IPv4 address is provisioned on a AFTR device. An operational mode to bypass an AFTR is described in Section 3.2. 3.2. Operational Mode IPv4-in-IPv6 encapsulated datagrams issued by a CPE are received by an AFTR device (Step 1). This AFTR de-capsulates the datagram and retrieves the destination IPv4 address. Then, it proceeds to a route lookup to check whether a route towards "pref6_aftr+destination IPv4@" is installed. If not, it proceeds with traditional NAT Boucadair Expires June 19, 2010 [Page 7] Internet-Draft AFTR Bypass Procedure December 2009 operations. Otherwise (i.e., a route is found. This means that the destination is located behind an AFTR), no NAT44 state is instantiated by the Source CGN. The datagram is then encapsulated in IPv6 datagram with an IPv6 destination address equal to "pref6_aftr+ destination IPv4 @::x" (refer to [I-D.ietf-behave-address-format] for more information on how to build IPv4-embedded IPv6 addresses). As for the source IPv6 address of the encapsulated datagram, two schemes may be envisaged: (1) Maintain the same source IPv6 address as per the datagram received from the customer's device. The deployment of this alternative requires the activation of security association to secure the exchange between the Source and Target CGN. A trust relationship MUST be configured. (2) A new extension header (called TEEH for Tunnel Endpoint Extension Header, defined in Figure 10) is inserted to indicate where to send the response back. The value of the extension header is an IPv6 address of the source CPE (as stored in the Source AFTR). The datagram is forwarded to the next hop until being delivered to a Target CGN (Step 2). - If a NAT entry is instantiated on that CGN, the datagram is processed. Additionally, the source IPv6 address of the received datagram or the content of the TEEH is stored by the CGN. This information will be used to send back the response. In addition to re-writing destination IPv4 address+port (i.e., DNAPT for Destination NAPT), the IPv4 source address and the port number are also modified (referred to as SNAPT for Source NAPT). The translation of the source IPv4 address is required to avoid overlapping private IPv4 addressing in the destination home realm. A public IPv4 address belonging to the Target CGN pool is used to enforce SNAPT. This SNAPT operation does not alter the number of sessions that may be maintained by a given CGN. The resulting IPv4 datagram is then encapsulated in IPv6 and forwarded to its final destination (i.e., B in Figure 6) (Step 3). A CGN MUST be configured to accept TEEH only when it is issued by other CGN devices. A filtering rule based on the source IPv6 address MAY be configured. - Otherwise, the datagram is rejected/dropped/silently discarded. Boucadair Expires June 19, 2010 [Page 8] Internet-Draft AFTR Bypass Procedure December 2009 Figure 6 illustrates the occurred flow exchanges. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_cgn1_s | | Src=@IPv6_dslite2 | |Dst=@IPv6_dslite1| |Dst=@IPv6_1.2.3.4| | Dst=@IPv6_CPE_B | | | |TEEH=@IPv6_CPE_A | | | | +-------------+ | | +-------------+ | | +---------------+ | | |Src=10.1.1.1 | | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | | |Dst=1.2.3.4 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | | +-------------+ | | +-------------+ | | +---------------+ | +-----------------+ +-----------------+ +-------------------+ | | | +-+ v +----+ v +----+ v +-+ |A|====IPv4-in-IPv6===>|CGN1|====IPv4-inIPv6===>|CGN2|====IPv4-in-IPv6===>|B| +-+ (1) +----+ (2) +----+ (3) +-+ ^ ^ | | +--------------+ +--------------------------------+ | No NAT state | | NAT state | +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| +--------------------------------+ pa, pb, pc and pd are port numbers. Only an excerpt of the NAT table is shown, IPv6 addresses are also maintained in the NAT table. Figure 6: Outbound traffic As for the response, B encapsulates IPv4 traffic in IPv6 datagrams that are forwarded to the AFTR as illustrated in Figure 7 and Figure 8 (Step 4). The AFTR then proceeds to NAT operations (both DNAPT and SNAPT). The resulting IPv4 traffic is then encapsulated in IPv6 and corresponding IPv6 datagrams are then forwarded to the IPv6 address of the remote destination as maintained in the NAT tables (Step 5). TEEH may be inserted to indicate the destination IPv6 address to be used for the subsequent messages (see Figure 7). Figure 8 shows the exchanged flows when TEEH is not used. Boucadair Expires June 19, 2010 [Page 9] Internet-Draft AFTR Bypass Procedure December 2009 +------------------+ +-------------------+ | Src=@IPv6_cgn2_s | | Src=@IPv6_CPE_B | | Dst=@IPv6_CPE_A | | Dst=@IPv6_dslite2 | |TEEH=@IPv6_cgn2_s | | | | +-------------+ | | +---------------+ | | |Src=1.2.3.4 | | | |Src=192.168.1.1| | | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | | +-------------+ | | +---------------+ | +------------------+ +-------------------+ | | +-+ v +----+ v +-+ |A|<===================IPv4-inIPv6================|CGN2|<===IPv4-in-IPv6====|B| +-+ (5) +----+ (4) +-+ Figure 7: Incoming traffic with Option Header +-----------------+ +-------------------+ |Src=@IPv6_cgn2_s | | Src=@IPv6_CPE_B | |Dst=@IPv6_CPE_A | | Dst=@IPv6_dslite2 | | | | | | +-------------+ | | +---------------+ | | |Src=1.2.3.4 | | | |Src=192.168.1.1| | | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | | +-------------+ | | +---------------+ | +-----------------+ +-------------------+ | | +-+ v +----+ v +-+ |A|<===================IPv4-inIPv6================|CGN2|<===IPv4-in-IPv6====|B| +-+ (5) +----+ (4) +-+ Figure 8: Incoming traffic without Option Header For the remaining exchanges, either A uses the IPv6 address of CGN2 to send subsequent messages owing to the presence of TEEH option (see Figure 7. The experienced behaviour is illustrated in Figure 9) or it uses the default behavior and it sends all IPv4 traffic to its attached CGN1 (as illustrated in Figure 6). A CPE MUST be configured to accept incoming IPv4-in-IPv6 traffic with a source address belonging to an IPv6 prefix used to address AFTR devices. Boucadair Expires June 19, 2010 [Page 10] Internet-Draft AFTR Bypass Procedure December 2009 +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | | Src=@IPv6_dslite2 | |Dst=@IPv6_dslite2| | Dst=@IPv6_CPE_B | | | | | | +-------------+ | | +---------------+ | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | | +-------------+ | | +---------------+ | +-----------------+ +-------------------+ | | +-+ v +----+ v +-+ |A|====================IPv4-inIPv6===============>|CGN2|====IPv4-in-IPv6===>|B| +-+ (6) +----+ (7) +-+ Figure 9: Withdraw Source CGN As a result, NAT operations are enforced in one AFTR instead of two nodes. One AFTR is withdrawn from the path. 4. Tunnel Endpoint Extension Header TEEH is a new IPv6 extension header which is used to inform the remote party about the destination IPv6 address to be used when issuing a response. Particularly, TEEH is used by the Source CGN to inform the Target CGN about the IPv6 address of a customer's device attached to the Source CGN. Therefore, the Target CGN acts as an inbound CGN for that customer's device . The format of the Tunnel Endpoint header is shown in Figure 10. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . IPv6 Tunnel Endpoint . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [NOTE: the format of TEEH may change in the next version of the document to include other information such as the scope for instance] Figure 10: Tunnel Endpoint Extension Header Boucadair Expires June 19, 2010 [Page 11] Internet-Draft AFTR Bypass Procedure December 2009 The description of the fields is as follows: o Next Header (8-bit): Identifies the type of header immediately following the TEEH header. o Hdr Ext Len (8-bit, unsigned integer): Length of the Tunnel Endpoint header in 8-octet units, not including the first 8 octets. o IPv6 Tunnel Endpoint: Encloses an IPv6 address that should be used as source of the encapsulated IPv4-in-IPv6 response. This field must be padded to ensure that the TEEH length is a multiple of 8 octets. When TEEH is included in a received IPv4-in-IPv6 datagram, the answer SHOULD be sent to the IPv6 address conveyed in the TEEH. When TEEH is inserted by a CGN in an IPv4-in-IPv6 datagram sent to a customer's device, the IPv6 address included in the TEEH SHOULD be used as destination IPv6 address of subsequent IPv4-in-IPv6 messages. 5. IANA Considerations TBC. 6. Security Considerations B4 element MUST be configured to accept incoming IPv4-in-IPv6 datagrams not issued by its outbound AFTR. All deployed AFTRs SHOULD share a security association to secure the use of the TEEH option. 7. Acknowledgements The author would like to thank P. Levis, M. Kassi Lahlou, E. Burgey, C. Jacquenet and D. Binet for their feedback and comments. 8. References 8.1. Normative References [I-D.ietf-behave-address-format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-02 (work in progress), Boucadair Expires June 19, 2010 [Page 12] Internet-Draft AFTR Bypass Procedure December 2009 December 2009. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-02 (work in progress), October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.boucadair-dispatch-ipv6-atypes] Boucadair, M., Noisette, Y., and A. Allen, "The atypes media feature tag for Session Initiation Protocol (SIP)", draft-boucadair-dispatch-ipv6-atypes-00 (work in progress), July 2009. [I-D.boucadair-mmusic-ccap] Boucadair, M. and H. Kaplan, "Session Description Protocol (SDP) Connectivity Capability (CCAP) Attribute", draft-boucadair-mmusic-ccap-00 (work in progress), July 2009. [I-D.carpenter-behave-referral-object] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", draft-carpenter-behave-referral-object-01 (work in progress), October 2009. [I-D.dhankins-softwire-tunnel-option] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol (DHCPv6) Option for Dual-Stack Lite", draft-dhankins-softwire-tunnel-option-05 (work in progress), November 2009. Appendix A. Alternative Solution This alternative aims at avoiding two NAT operations without withdrawing a CGN from the path. Outbound flow exchanges are illustrated in Figure 11. Inbound flow exchanges are shown in Figure 12. IPv6 is used to convey traffic between AFTR nodes. IPv4-embedded Boucadair Expires June 19, 2010 [Page 13] Internet-Draft AFTR Bypass Procedure December 2009 IPv6 addresses are used to detect whether the destination is also managed by an AFTR. No NAT state is then instantiated in the Source CGN. Two AFTR are maintained in the path but only one AFTR maintains a NAT state. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_cgn1_s | | Src=@IPv6_dslite2 | |Dst=@IPv6_dslite1| |Dst=@IPv6_1.2.3.4| | Dst=@IPv6_CPE_B | | | | | | | | +-------------+ | | +-------------+ | | +---------------+ | | |Src=10.1.1.1 | | | |Src=10.1.1.1 | | | |Src=1.2.3.95 | | | |Dst=1.2.3.4 | | | |Dst=1.2.3.4 | | | |Dst=192.168.1.1| | | +-------------+ | | +-------------+ | | +---------------+ | +-----------------+ +-----------------+ +-------------------+ | | | +-+ v +----+ v +----+ v +-+ |A|====IPv4-in-IPv6===>|CGN1|====IPv4-inIPv6===>|CGN2|====IPv4-in-IPv6===>|B| +-+ (1) +----+ (2) +----+ (3) +-+ ^ ^ | | +--------------+ +--------------------------------+ | No NAT state | | NAT state | +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| +--------------------------------+ Figure 11: Outbound traffic The following steps are followed o Step 1: A encapsulates it IPv4 datagram in IPv6 one and forwards the encapsulated IPv4-in-IPv6 datagram to its outbound AFTR. The IPv6 address/FQDN of its outbound AFTR is provisioned using DHCP for instance. o Step 2: Once that datagram is received by the CGN1, its de- capsulates it and retrieves the IPv4 datagram. Moreover, the destination IPv4 address is returned. CGN1 proceeds to a routing look up to check whether a route to pref6_aftr+destination IPv4@ is installed. If the answer is positive (i.e., the destination is managed by an AFTR), CGN1 does not proceeds to any NAT44 operation. The IPv4 datagram is then encapsulated in an IPv6 ones and forwarded to CGN2 (destination IPv6 address of the encapsulated datagram is pref6_aftr+IPv4@). The source IPv6 address used by CGN1 must identify unambiguously A. Boucadair Expires June 19, 2010 [Page 14] Internet-Draft AFTR Bypass Procedure December 2009 o Step 3: CGN2 receives that datagrams. It de-capsulates the received datagram and retrieves the enclosed IPv4 one. CGN2 checks if a NAT state is already instantiated towards the destination IPv4 address/port number. If the answer is positive, then it proceeds to DNAPT and SNAPT. The resulting datagram is then forwards to the IPv6 address of B (stored in CGN2). o Step 4: B replies as per DS-lite specifications. o Step 5: CGN2 de-capsulates the received datagrams and proceeds to DNAPT and SNAPT. The resulting IPv4 datagram is then encapsulated in an IPv6 one and forwarded to CGN1. o Step 6: CGN1 checks its swapping states and forwards the packet to A. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_cgn2_s | | Src=@IPv6_CPE_B | |Dst=@IPv6_dslite1| |Dst=@IPv6_cgn1_s | | Dst=@IPv6_dslite2 | | | | | | | | +-------------+ | | +-------------+ | | +---------------+ | | |Src=1.2.3.4 | | | |Src=1.2.3.4 | | | |Src=192.168.1.1| | | |Dst=10.1.1.1 | | | |Dst=10.1.1.1 | | | |Dst=1.2.3.95 | | | +-------------+ | | +-------------+ | | +---------------+ | +-----------------+ +-----------------+ +-------------------+ | | | +-+ v +----+ v +----+ v +-+ |A|<===IPv4-in-IPv6====|CGN1|<===IPv4-inIPv6====|CGN2|<===IPv4-in-IPv6====|B| +-+ (6) +----+ (5) +----+ (4) +-+ ^ ^ | | +--------------+ +--------------------------------+ | No NAT state | | NAT state | +--------------+ |DNAPT: 10.1.1.1/pa:1.2.3.95/pb | |SNAPT: 192.186.1.1/pc:1.2.3.4/pd| +--------------------------------+ Figure 12: Inbound traffic Boucadair Expires June 19, 2010 [Page 15] Internet-Draft AFTR Bypass Procedure December 2009 Author's Address Mohamed Boucadair France Telecom 3, av Francois Chateau Rennes 35000 France Email: mohamed.boucadair@orange-ftgroup.com Boucadair Expires June 19, 2010 [Page 16]