Network Working Group M. Boucadair Internet-Draft France Telecom Intended status: Standards Track August 23, 2010 Expires: February 24, 2011 Procedure to bypass DS-lite AFTR draft-boucadair-softwire-cgn-bypass-02.txt Abstract This document proposes a solution to avoid the use of two stateful DS-Lite AFTR devices when both end-points are located behind different AFTR 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 DS-Lite 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 in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 24, 2011. Copyright Notice Copyright (c) 2010 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 Boucadair Expires February 24, 2011 [Page 1] Internet-Draft AFTR Bypass Procedure August 2010 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 Simplified 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 February 24, 2011 [Page 2] Internet-Draft AFTR Bypass Procedure August 2010 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. Tunnel Endpoint Extension Header . . . . . . . . . . . . . . . 7 4. AFTR Bypass Procedure . . . . . . . . . . . . . . . . . . . . 8 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Operational Mode . . . . . . . . . . . . . . . . . . . . . 8 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 February 24, 2011 [Page 3] Internet-Draft AFTR Bypass Procedure August 2010 1. Introduction 1.1. Purpose The main purpose of this document is to investigate solutions to avoid the solicitation of some of the (AFTR-embedded) NAT capabilities along the path between two hosts located behind AFTR devices. The advantages of this procedure include: o Better one-way delay: No need to check the payload in the originating AFTR and no need to execute ALG operations twice; o Optimised routing path; o Better use of available AFTR resources; o Enhance robustness: an AFTR device is withdrawn from the data path. The stateful nature of DS-Lite AFTR 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 AFTR is used to refer to both following schemes: o an AFTR function embedded in a router, and/or o a standalone AFTR with limited routing capabilities (redirection capabilities to the AFTR are being enabled in an external router). An outbound AFTR is referred to as Source AFTR. An inbound AFTR is called a Target AFTR. In the example illustrated in Figure 1, if we suppose that A initiates a communication towards B, AFTR1 is the Source AFTR and AFTR2 is the Target AFTR. Boucadair Expires February 24, 2011 [Page 4] Internet-Draft AFTR Bypass Procedure August 2010 "===" in the figure represents flows and not links. Furthermore, AFTRs may not be part of the optimal routing path between A and B. +-+ +-----+ +-----+ +-+ |A|====IPv4-in-IPv6==>|AFTR1|=============|AFTR2|===IPv4-in-IPv6===>|B| +-+ +-----+ +-----+ +-+ Source AFTR Target AFTR Figure 1: Source and Target AFTR 1.3. Contribution of this Draft This document proposes a solution to avoid invoking NAT capabilities when several DS-Lite AFTR devices [I-D.ietf-softwire-dual-stack-lite] are involved in the data path. This document encourages the use of IPv6 for forwarding traffic between two AFTR devices. This memo focuses primarily on the AFTR devices deployed in the same administrative domain. AFTRs located in distinct administrative domains are out of scope. This document does not make any assumption on the services that may require the establishment of direct communications between hosts located behind AFTR devices. Examples of services would be P2P or hosting FTP/HTTP/SIP server behind a DS-Lite CPE. In order to offload AFTR devices, application-specific solutions (e.g., [I-D.carpenter-behave-referral-object] [I-D.boucadair-mmusic-ccap], [I-D.boucadair-dispatch-ipv6-atypes]) may be required to be implemented in order to prefer native IPv6 communications rather than crossing AFTR devices. The implementation of the proposed procedure 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 3) 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 an AFTR device. Two NAT operations are required to be Boucadair Expires February 24, 2011 [Page 5] Internet-Draft AFTR Bypass Procedure August 2010 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==>|AFTR1|============|AFTR2|====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 AFTR are not solicited. A second optimisation scenario is shown in Figure 4 where NAT capabilities of the Target AFTR 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 AFTR (consequently, a NAT44 state must be instantiated in the Target AFTR). The last configuration, illustrated in Figure 5, aims at avoiding the use of NAT capabilities in both Source and Target AFTRs. 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 AFTR has assigned an IPv4 address and port number for that host. Therefore, all the incoming IPv4 traffic must cross that AFTR. +-+ +-----+ +-----+ +-+ |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| +-+ +-----+ +-----+ +-+ No_NAT44 NAT44 Figure 3: Avoid Source NAT44 +-+ +-----+ +-----+ +-+ |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| +-+ +-----+ +-----+ +-+ NAT44 No_NAT44 Figure 4: Avoid Target NAT44 Boucadair Expires February 24, 2011 [Page 6] Internet-Draft AFTR Bypass Procedure August 2010 +-+ +-----+ +-----+ +-+ |A|====IPv4-in-IPv6==>|AFTR1|============|AFTR2|====IPv4-in-IPv6===>|B| +-+ +-----+ +-----+ +-+ No_NAT44 No_NAT44 Figure 5: Avoid all NAT44 3. 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 AFTR to inform the Target AFTR about the IPv6 address of a customer's device attached to the Source AFTR. Therefore, the Target AFTR acts as an inbound AFTR for that customer's device. The format of the Tunnel Endpoint header is shown in Figure 6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 6: Tunnel Endpoint Extension Header 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. Boucadair Expires February 24, 2011 [Page 7] Internet-Draft AFTR Bypass Procedure August 2010 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 AFTR 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. 4. AFTR Bypass Procedure 4.1. Overview Each CPE (which embeds a B4 function) is notified of the IPv6 reachability information of (one of) the available DS-Lite AFTRs (e.g., using [I-D.ietf-softwire-ds-lite-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 AFTR 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 prefix [I-D.ietf-behave-address-format] 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 4.2. 4.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 February 24, 2011 [Page 8] Internet-Draft AFTR Bypass Procedure August 2010 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 AFTR. 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 AFTR. A trust relationship must be configured. (2) A new extension header (called TEEH for Tunnel Endpoint Extension Header, defined in Figure 6) 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 AFTR (Step 2). - If a NAT entry is instantiated on that AFTR, the datagram is processed. Additionally, the source IPv6 address of the received datagram or the content of the TEEH is stored by the AFTR. 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 AFTR pool is used to enforce SNAPT. This SNAPT operation does not alter the number of sessions that may be maintained by a given AFTR. The resulting IPv4 datagram is then encapsulated in IPv6 and forwarded to its final destination (i.e., B in Figure 7) (Step 3). An AFTR must be configured to accept TEEH only when it is issued by other AFTR devices. A filtering rule based on the source IPv6 address MAY be configured. Boucadair Expires February 24, 2011 [Page 9] Internet-Draft AFTR Bypass Procedure August 2010 - Otherwise, the datagram is rejected/dropped/silently discarded. Figure 7 illustrates the occurred flow exchanges. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_aftr_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==>|AFTR1|====IPv4-inIPv6==>|AFTR2|====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 7: Outbound traffic As for the response, B encapsulates IPv4 traffic in IPv6 datagrams that are forwarded to the AFTR as illustrated in Figure 8 and Figure 9 (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 8). Figure 9 shows the exchanged flows when TEEH is not used. Boucadair Expires February 24, 2011 [Page 10] Internet-Draft AFTR Bypass Procedure August 2010 +------------------+ +-------------------+ | Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | | Dst=@IPv6_CPE_A | | Dst=@IPv6_dslite2 | |TEEH=@IPv6_aftr2_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===============|AFTR2|<===IPv4-in-IPv6====|B| +-+ (5) +-----+ (4) +-+ Figure 8: Incoming traffic with Option Header +-----------------+ +-------------------+ |Src=@IPv6_aftr2_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===============|AFTR2|<===IPv4-in-IPv6====|B| +-+ (5) +-----+ (4) +-+ Figure 9: Incoming traffic without Option Header For the remaining exchanges, either A uses the IPv6 address of AFTR2 to send subsequent messages owing to the presence of TEEH option (see Figure 8. The experienced behaviour is illustrated in Figure 10) or it uses the default behavior and it sends all IPv4 traffic to its attached AFTR1 (as illustrated in Figure 7). 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 February 24, 2011 [Page 11] Internet-Draft AFTR Bypass Procedure August 2010 +-----------------+ +-------------------+ |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==============>|AFTR2|====IPv4-in-IPv6===>|B| +-+ (6) +-----+ (7) +-+ Figure 10: Withdraw Source CGN As a result, NAT operations are enforced in one AFTR instead of two nodes. One AFTR is withdrawn from the path. 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] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), Boucadair Expires February 24, 2011 [Page 12] Internet-Draft AFTR Bypass Procedure August 2010 August 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [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.ietf-softwire-ds-lite-tunnel-option] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite", draft-ietf-softwire-ds-lite-tunnel-option-03 (work in progress), June 2010. Appendix A. Alternative Solution This alternative aims at avoiding two NAT operations without withdrawing a AFTR 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 IPv6 addresses are used to detect whether the destination is also Boucadair Expires February 24, 2011 [Page 13] Internet-Draft AFTR Bypass Procedure August 2010 managed by an AFTR. No NAT state is then instantiated in the Source AFTR. Two AFTR are maintained in the path but only one AFTR maintains a NAT state. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_aftr1_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==>|AFTR1|====IPv4-inIPv6==>|AFTR2|====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 AFTR1, its de- capsulates it and retrieves the IPv4 datagram. Moreover, the destination IPv4 address is returned. AFTR1 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), AFTR1 does not proceeds to any NAT44 operation. The IPv4 datagram is then encapsulated in an IPv6 ones and forwarded to AFTR2 (destination IPv6 address of the encapsulated datagram is pref6_aftr+IPv4@). The source IPv6 address used by AFTR1 must identify unambiguously A. Boucadair Expires February 24, 2011 [Page 14] Internet-Draft AFTR Bypass Procedure August 2010 o Step 3: AFTR2 receives that datagrams. It de-capsulates the received datagram and retrieves the enclosed IPv4 one. AFTR2 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 AFTR2). o Step 4: B replies as per DS-Lite specifications. o Step 5: AFTR2 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 AFTR1. o Step 6: AFTR1 checks its swapping states and forwards the packet to A. +-----------------+ +-----------------+ +-------------------+ |Src=@IPv6_CPE_A | |Src=@IPv6_aftr2_s| | Src=@IPv6_CPE_B | |Dst=@IPv6_dslite1| |Dst=@IPv6_aftr1_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==|AFTR1|<===IPv4-inIPv6====|AFTR2|<===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 February 24, 2011 [Page 15] Internet-Draft AFTR Bypass Procedure August 2010 Author's Address Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange-ftgroup.com Boucadair Expires February 24, 2011 [Page 16]