Internet DRAFT - draft-despres-sam-scenarios
draft-despres-sam-scenarios
Internet Engineering Task Force R. Despres
Internet-Draft September 28, 2008
Intended status: Informational
Expires: April 1, 2009
IPv4-IPv6 Coexistence Scenarios based on Stateless Address Mapping
draft-despres-sam-scenarios-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 1, 2009.
Abstract
As each global IPv4 address will be shared among more and more
customers, and as more and more NATs will be deployed in ISP
infrastructures, the lack of end-to-end transparency and the limited
scalability of some NATs are likely to cause increasing difficulties
to customers and to ISPs. This document introduces IPv4-IPv6
coexistence scenarios where IPv4 addresses are shared with good
scalability and, in favorable configurations, with full IPv4 end-to-
end transparency. For this, the key tool is the Stateless Address
Mapping (SAM) of draft-despres-SAM-00, with in particular its
extended IPv4 addressing (IPv4E) in which port prefixes are used as
IPv4 address extensions. For each considered scenario, Static
Address Mappers (SAMs) are deployed at scenario specific places.
Despres Expires April 1, 2009 [Page 1]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples of SAM based scenarios . . . . . . . . . . . . . . . 5
4. Examples of SAM ISP configurations . . . . . . . . . . . . . . 6
4.1. ISP infrastructure with private IPv4 internal routing . . 7
4.2. ISP infrastructure with private IPv4 and IPv6 internal
routings . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. ISP infrastructure with only IPv6 internal routing . . . . 9
5. SAM CPE internal architecture . . . . . . . . . . . . . . . . 10
6. SAM host internal architecture . . . . . . . . . . . . . . . . 12
7. Security considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Despres Expires April 1, 2009 [Page 2]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
1. Introduction
As each global IPv4 address will be shared among more and more
customers, and as more and more NATs will be deployed in ISP
infrastructures, the lack of end-to-end transparency and the limited
scalability of such NATs are likely to cause increasing difficulties
to customers and to ISPs.
This document introduces IPv4-IPv6 coexistence scenarios where IPv4
addresses are shared with good ISP infrastructure scalability and, in
favorable configurations, with full IPv4 end-to-end transparency.
For this, the key tool is the Stateless Address Mapping (SAM) of
draft-despres-SAM-00, with in particular its extended IPv4 addressing
(IPv4E) in which port prefixes are used as IPv4 address extensions.
Section 3 describes four IPv4-IPv6 inter-working scenarios. For each
one, it indicates which ISP functions are stateless, ensuring the
good scalability, and where available port ranges are restricted.
Section 4 describes three ISP infrastructure configurations which are
compatible with scenarios of Section 3, and which, for backward
compatibility with non SAM solutions, are also compatible with many
other scenarios. These configurations differ in that ISP routing is
only private IPv4, is only IPv6, or is both private IPv4 and IPv6.
Section 5 describes a CPE internal architecture which is compatible
with scenarios of Section 3 and, for backward compatible with non SAM
solutions, which is is also compatible with many other scenarios.
Section 6 describes a host internal architecture which is compatible
with all scenarios of Section 3, and which, for backward
compatibility with non SAM solutions, is also compatible with many
other scenarios.
Despres Expires April 1, 2009 [Page 3]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
2. Acronyms
PACKET TYPES
4 : global IPv4
4P : ISP private IPv4
4S : customer-site private IPv4
6 : global IPv6
a/b : IPva encapsulated in IPvb
v : address family 4 or 6
NEWORK COMPONENTS
CPE : customer premise equipment
SAM CPE : a router CPE which supports SAM at its site and/or ISP
interfaces
SAM ISP GW : an ISP gateway to the global Internet which supports SAM
CGN44 : a NAT of an ISP, from 4P to 4, at its border to the global
Internet
CGN4/64 : a NAT of an ISP, from 4S/6 to 4, at its border to the
global Internet
PE : ISP edge nodes, facing customer sites
PREFIXES AND ADDRESSES
Gv : anycast address, in the ISP infrastructure, of gateways
to the global Internet
Hv : Header of all v addresses in the considered ISP infrastructure
Nv : v unicast address of a CGN of the ISP
P6 : IPv6 prefix, in the global Internet, of SAMs of the ISP
P4a : IPv4 prefix, in the global Internet, of SAMs of the ISP
P4b : IPv4 prefix of ISP NAT in the global Internet
Svi : v prefix of customer site i in the ISP infrastructure
Despres Expires April 1, 2009 [Page 4]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
3. Examples of SAM based scenarios
Considered scenarios are presented in of Figure 1 and Figure 2. They
all concern communication between host that cannot have global IPv4
address of their own, and remote hosts addresses of which are global
IPv4, each end being able to initiate connections. None of the
scenario involves a CGN. In scenarios A to C, sites themselves have
no global IPv4 addresses. Scenarios B to D provide IPv4 packet
transparency between considered hosts and the global Internet, so
that this transparency is end-to-end if remote hosts have the same
property.
SCENARIO A +--------+ Global
+------+ +---------+ | SAM | Internet
| host |--site 4S--| SAM CPE |-- ISP 4P ----| ISP GW |<--- 4 --->
+------+ +---------+ or 6 +--------+
<--- 4S ----> NAT+SAM <-- 4/4P or 4/6 --> SAM <----- 4 --->
: :
Port restricted NAT ---' '--- Stateless GW
SCENARIO B
+------+ +--------+ Global
| SAM | | SAM | Internet
| host |------------------------ ISP 4P ----| ISP GW |<--- 4 --->
+------+ or 6 +--------+
SAM <------------------------ 4/4P or 4/6 --> SAM <----- 4 --->
: :
'- Port restricted '--- Stateless GW
socket interface
<-------------- transparency to global v4 packets ------------>
SCENARIOS A AND B
Figure 1
Despres Expires April 1, 2009 [Page 5]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
SCENARIO C
+------+ +--------+ Global
| SAM | +---------+ | SAM | Internet
| host |--site 4S--| SAM CPE |-- ISP 4P ----| ISP GW |<--- 4 --->
+------+ or 6 +---------+ or 6 +--------+
SAM <-4/4S or 4/6->SAM1 SAM2<-- 4/4P or 4/6 --> SAM <----- 4 --->
: : :
'- Port restricted '- Stateless CPE '--- Stateless GW
socket interface
<-------------- transparency to global v4 packets ------------>
SCENARIO D
+------+ Peering Global
| SAM | +---------+ point Internet
| host |--site 4S--| SAM CPE |------ ISP 4-------O--------- 4 --->
+------+ or 6 +---------+
SAM <--- 4/4S ---> SAM <------------------- 4 ----------------->
:
'- Port restricted
socket interface
<-------------- transparency to global v4 packets ------------>
SCENARIOS C AND D
Figure 2
4. Examples of SAM ISP configurations
In Figures of the following subsections, routing prefixes xx are
shown with simple arrows xx --> style.
Types of packets that may arrive on these routes are shown above
double arrows made of equal signs.
Packet types and parameters are as defined in Section 2.
Understanding which services are offered to customer sites in each of
these configurations doesn't necessitate to know details of how SAMs
make their address mappings and encapsulations-decapsulations. These
details are available in [draft-despres-SAM-00].
Despres Expires April 1, 2009 [Page 6]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
4.1. ISP infrastructure with private IPv4 internal routing
If an ISP, to deploy customer sites without global IPv4 addresses,
uses only a private IPv4 address space for its internal routing, it
needs a CGN44 between its infrastructure and the global Internet.
It can, in addition, support SAMs at its border with IPv4 and IPv6
global Internets [Figure 3]. Doing it adds global IPv4E connectivity
and IPv6 connectivity to customer sites where CPEs are SAM capable
(router or hosts).
+-------------------------------+
| |
| |
SAM CPE | 6/4P | 6
DHCP | 4/4P +---+ 4
| | <=======>|SAM|<=======>
parameters | G4 ---> +---+ <--- P4a
B4i,H4,C4 | | <--- P6
| | |
| | ( PRIVATE IPv4 ROUTING ) |
V | |
| |
6/4P | 6/4P |
4/4P | 4/4P |
4P | 4P |
<=======>O<===========> |
customer | <--- S4i |
site i | |
| |
| 4P +-----+ 4
| <=======>|CGN44|<=====>
| 0.0.0.0/0 ---> +-----+ <--- P4b
| |
+-------------------------------+
Length of CPE port prefixes: p = l(T4a) - l(H4)
Example: p = 12 - 8 = 4
EXAMPLE OF ISP CONFIGURATION WITH ONLY PRIVATE IPV4 ROUTING
Figure 3
Despres Expires April 1, 2009 [Page 7]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
4.2. ISP infrastructure with private IPv4 and IPv6 internal routings
If an ISP, to deploy customer sites without global IPv4 addresses,
uses both a private IPv4 and the IPv6 address spaces for its internal
routing, it provides IPv6 connectivity to its customer sites, and can
operate a CGN44 between its infrastructure and the global Internet
for its IPv4 only CPEs.
It can, in addition, support SAMs at its border with IPv4 global
Internet [Figure 4]. Doing it adds global IPv4E connectivity to CPEs
that are SAM capable (router or hosts). .
+-------------------------------+
| |
| 4/4P +---+ 4
| <=======>|SAM|<=======>
SAM CPE | G4 ---> +---+ <--- P4a
DHCP | G6 ---> |
parameters | |
B4i,H4,C4 | 6 | 6
B6i,H6,C6 | <===========>O<=======>
| | 0::/0 ---> | <--- P6
| | |
V | ( IPv6 & PRIVATE IPV4 |
| ROUTINGS ) |
6 | 6 |
4P | 4P |
4/4P | 4/4P |
<=======>O<===========> |
customer | <--- S4i |
site i | <--- S6i |
| |
| 4P +-----+ 4
| <=======>|CGN44|<=====>
| 0.0.0.0/0 ---> +-----+ <--- P4b
| |
+-------------------------------+
4P : private IPv4 of the Provider
Length of CPE port prefixes: idem IPv4 Routing alone
EXAMPLE OF ISP CONFIGURATION WITH IPV6 AND PRIVATE IPV4 ROUTINGS
Figure 4
Despres Expires April 1, 2009 [Page 8]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
4.3. ISP infrastructure with only IPv6 internal routing
If an ISP, to deploy customer sites without global IPv4 addresses,
uses only the IPv6 address space for its internal routing, it cannot
support IPv4 only customers with a CGN44.
If it support SAMs and a CGN4/64 at its border with IPv4 global
Internet, and if it also supports SAMs in its PEs, it adds global
IPv4E connectivity to CPEs that are SAM capable (router or hosts),
and adds IPv4 connectivity via a NAT to IPv4-only CPEs.
+-------------------------------+
| |
| 4/6 +---+ 4
| <=======>|SAM|<=======>
| G6 ---> +---+ <--- P4a
| |
SAM CPE | 6 | 6
DHCP | <===========>o<=======>
parameters | 0::/0 ---> | <--- P6
B6i,H6,C6,N6 | |
| | ( IPv6 ROUTING ) |
V | |
| 6 |
6 | 4S/6 |
4P or 4S| 4P/6 |
4/6 +---+ 4/6 |
<=======>|SAM|<=======> |
customer +---+ <--- S6i |
site i | |
| 4S/6 |
| 4P/6 +-------+ 4
| <=======>|CGN4/64|<====>
| N6 ---> +-------+ <-- P4b
| |
+-------------------------------+
4P : private IPv4 of the Provider
4S : private IPv4 of the customer Site
Length of CPE port prefixes: p = l(B6i) - l(H6) - (32 - T4a)
Example: p = 60 - 36 - (32 - 12) = 4
EXAMPLE OF ISP CONFIGURATION WITH ONLY IPV6 ROUTING
Figure 5
Despres Expires April 1, 2009 [Page 9]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
5. SAM CPE internal architecture
Router CPEs can exist in many variants because of the variety of
packet types that ISP can support at their customer site interfaces,
because of the variety of routing families that customers may desire
to support in their sites, and because some ISPs that supply CPEs to
their customers may prefer to have NATs in their infrastructures
rather than in CPEs (the DS lite approach).
The generic internal architecture which is proposed in Figure 6 is
intended to cover all useful cases. Its operation in each particular
case is governed by: (1) the presence or absence of a NAT in the CPE;
(2) SAM parameters which determine which packet types are supported
at ISP interfaces; (3) which packet types have to be routed in
customer sites (4S, 6, or both 4S and 6).
Figure 6 details processing paths that each packet follows depending
on: (1) which side it comes from; (2) what was its type when
received; (3) what is the transmit type that is compatible with the
receipt one, among those that are available at the forwarding
interface (depending on configured SAM parameters).
CPE parameters should be configurable both manually, and
automatically using IPv4 DHCP and/or DHCPv6.
SAM CPEs should also be able to provide in DHCP all SAM parameters
that may be needed by SAM hosts.
Despres Expires April 1, 2009 [Page 10]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
Possible packet types Possible ISP supported
in the customer site packet types
| |
| 4P |
| +-+ ->4 4b |
| | | .---------------------------. V
V 4P |N| | |
6/4P .-------|A|---: | 6/4P
6/4S | |T| | ->4/6 | 6/4
4/4P | | | | ->4P 4a | 4S/4P
4/4S | +-+ '---------------. | 4P
4P | | | 4/4P
4S |4S 4S | | 4
<---->:-----------------------------: 6/4P :<---->
| +-+ | +-+ 6/4 |
|6/4S | | | | | 4/4P |
|4/4S | | 4b | | | 4 |
'------|S|--------------------'--|S|------'
|A| |A|
4S/6 |M| ->6/4P |M|
4/6 | | ->6/4 <-6/4S | | 4/6
.------| |--.-----------------.--| |------.
| +-+ | | +-+ |
| | ->6 6<- | |
4S/6 | '------. .------' | 6
4/6 | | | | 4S/6
6 | : : | 4/6
<---->: 6->6/4P \ / :<---->
| 6->6/4 / \ 4S/6 |
:------------------' '-------------------:
| |
| 6->6 6 |
'-----------------------------------------'
->x : processing path to be taken if SAM parameters show
that type x is possible at the forwarding interface
A FLEXIBLE USE SAM CPE ARCHITECTURE
Figure 6
Despres Expires April 1, 2009 [Page 11]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
6. SAM host internal architecture
Figure 7 presents a generic SAM host architecture. With it, a host
can work in non SAM environments as well as in SAM environments, thus
preserving the backward compatibility that is necessary for
incremental deployment.
Socket
programming
interface
: .-- Restricted ports if ->4/4P or ->4/6
: | Local address = 10.0.0.0.1 if -> 4H/6
: |
: |
: +--+ ->4P 4P 6/4P
: |v4| ->4 4 6/4
: | | .-------------------------. 4P
: |S | | | 4/4P
: |o | | | 4
IPv4 <---->|c |-----: :<------>
: |k | | ->4H/6 6/4P |
: |e | | ->4/6 +---+ 6/4 |
: |t | | ->4/4P | | 4/4P |
: |s | '---------| |-----------'
: +--+ | S |
: ->6/4 | A |
: +--+ ->6/4P | M |
: |v6| .---------| |-----------.
: | | | | | | 4H/6
: |S | | +---+ | 4/6
: |o | | | 6
IPv6 <---->|c |-----: :<------>
: |k | | |
: |e | | ->6 |
: |t | '-------------------------'
: |s |
: +--+
INTERNAL ARCHITECTURE OF A SAM-CAPABLE CPE
Figure 7
The logic is expected to be straightforward enough for operating
systems of mobile phones and PCs to have it included it in not too
distant a future, in any case well before the end of the coexistence
period.
Despres Expires April 1, 2009 [Page 12]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
A host that has SAM compatibility has the benefit that it can support
server applications that are reachable by IPv4-only hosts, even when
this PC gets doesn't get a a global IPv4 address of its own. This
remains true if it is behind a SAM CPE that has only a port
restricted IPv4 address. Another expected benefit is that, with
restoration of end-to-end transparency to IPv4 packets, protocols
that need it or work better with it (e.g. SCTP) can work not only in
IPv6 with unrestricted ports, but also in IPv4 with restricted ports.
Concerning the effect of restricted port ranges, it should be noted
that reserving a local port for each outgoing connection, as
apparently most socket modules do, leaves plenty of room for
optimization: if a local socket used for a given connection
identified by its 5-tuple [source and destination addresses & ports
and protocol], it can be reused for different 5-tuples. Thus, the
number of ports needed by each host can be drastically reduced.
Whether this optimization has no risk to interfere with existing NAT
traversal techniques like ICE has however to be checked.
7. Security considerations
8. IANA Considerations
9. Acknowledgements
So far, the SAM approach has essentially been worked out by the
author, with various intermediate stages like the so called Address
Borrowing Protocol and the Global Address Protocol, respectively
presented in IETF 71 and IETF 72, without any sponsoring or company
contract and without seeking intellectual property protection. He
therefore wishes to expresses its first acknowledgment to his wife:
she accepted that traveling and other expenses be supported by the
uni-personal enterprise of the author, the money of which cannot be
distinguished from family money.
One important and recent progress of the approach has been the
recognition that, with the flexibility of DHCP, no new protocol would
be necessary to automate SAM parameter settings. Acknowledgment is
due to Gabor Bajko and Teemu Savolainen for pointing it out at IETF
72.
10. Informative References
[draft-despres-SAM-00]
Despres Expires April 1, 2009 [Page 13]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
"Stateless Address Mapping (SAM) - Work in progress",
September 2008.
Author's Address
Remi Despres
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Despres Expires April 1, 2009 [Page 14]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Despres Expires April 1, 2009 [Page 15]
