One document matched: draft-boucadair-softwire-cgn-bypass-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:24:19 |