Internet DRAFT - draft-despres-softwire-mesh-sam
draft-despres-softwire-mesh-sam
Internet Engineering Task Force R. Despres
Internet-Draft October 26, 2009
Intended status: Standards Track
Expires: April 29, 2010
Stateless Address Mapping (SAM) - Mesh Softwires without e-BGP
draft-despres-softwire-mesh-sam-01
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 April 29, 2010.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
SAM is a generic and simple mechanism for packets having addresses in
a family IPvX to traverse routing domains where this address family
is not directly routed.
Despres Expires April 29, 2010 [Page 1]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
SAM topological scenarios are those of Mesh Softwire, i.e. with point
to multipoint tunnels between border nodes of interior routing
domains. In the mesh-softwire context, SAM differs from RFC 5565 in
that SAM uses no protocol between border nodes of the domain, and in
that customer border nodes don't need to maintain states for all
other border nodes. (RFC 5565 is based on an Exterior Border-Gateway
Protocol e-BGP between border nodes, with dynamic routing tables to
be maintained in all of them). SAM's address mappings are stateless,
based on only a few domain parameters. SAM is thus suitable to small
to medium enterprises, and small to medium ISPs, that cannot afford
e-BGP in all their border nodes. All combinations of IPv4 and IPv6,
global or private, are supported. Also, to mitigate consequences of
the IPv4 address shortage, SAM supports port-extended IPv4 addresses
(A+P).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
2.1. A small ISP lacking enough global IPv4 addresses . . . . . 5
2.2. A small customer site having only a port-restricted
IPv4 address . . . . . . . . . . . . . . . . . . . . . . . 7
3. The SAM Model and its Terminology . . . . . . . . . . . . . . 9
4. SAM functional sub-modules and their parameters . . . . . . . 10
5. Mapping between SAM Interior Addresses and SAM interior IDs . 13
5.1. SAM-interior-address Formats . . . . . . . . . . . . . . . 13
5.2. SAM Interior Addresses and SAM Interior IDs in IPv6 . . . 14
5.3. SAM Interior Addresses and SAM Interior IDs in IPv4 . . . 15
6. SAM Prefixes and SAM Raw Prefixes . . . . . . . . . . . . . . 16
7. Derivation of Sub-delegated prefixes from Delegated
Prefixes and Interior IDs . . . . . . . . . . . . . . . . . . 19
8. Mapping from Source and Destination Endpoint Locators to
Source and Destination Interior Addresses . . . . . . . . . . 20
8.1. Encapsulation Function . . . . . . . . . . . . . . . . . . 20
8.2. Decapsulation Function . . . . . . . . . . . . . . . . . . 21
9. Detailed Prefixes for the Example Scenarios . . . . . . . . . 22
10. Applicability to other scenarios . . . . . . . . . . . . . . . 24
11. Security considerations . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Despres Expires April 29, 2010 [Page 2]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
1. Introduction
The Softwires Working Group standardizes discovery, control, and
encapsulation methods, for connecting IPv4 networks across IPv6
networks and IPv6 networks across IPv4 networks. Two topological
scenarios have been identified for this in [RFC4925]: Hubs and Spokes
and Mesh.
o Hubs and Spokes targets carriers, or large enterprise networks
acting as carriers, that deploy Centralized Softwire
Concentrators.
o The particular mesh framework described in [RFC5565] targets
carriers or large-enterprises whose networks support, in all their
border nodes, a common exterior Border Gateway Protocol (e-BGP).
Stateless Address Mapping (SAM) targets small to medium enterprises,
or small to medium Internets service providers (ISPs), that don't
operate centralized software concentrators, and in whose networks a
common e-BGP in all border nodes in not practicable. (In SAM,
stateless means that border nodes are not obliged to maintain states
for all other border nodes - a meaning similar to that used in
Stateless DHCP of [RFC3736]).
SAM principles are an extension of those already in practice with
6to4 [RFC3056], ISATAP [RFC5214], and 6rd [Free's IPv6 in 2007]
[RFC5569] [6rd], which support IPv6 across IPv4 routing domains,
encapsulate exterior packets into interior packets, and statelessly
map from exterior addresses to interior addresses.
SAM unifies and generalizes their scopes in the following directions:
o Other encapsulations than just global IPv6 in global or private
IPv4 are supported, with all combinations of IPv6 and IPv4,
including with the IPv4 private addresses of [RFC1918] and the
IPv6 private addresses of [RFC4193] for interior routing.
o Provisions are made so that, despite the IPv4 address shortage
[Ipv4Shortage], the end-to-end transparency of [RFC2775] can be
restored in IPv4.
o Stateless autoconfiguration of sub-delegated prefixes
[PrefSubDeleg] is made possible in addition to the IPv6 stateless
address autoconfiguration of [RFC2462].
o Support of multihoming is generalized [RFC3582] [RFC4219], with
compatibility with ingress filtering in ISP networks [RFC3704].
Despres Expires April 29, 2010 [Page 3]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
SAM's design has some commonalities with various earlier proposals,
like ENCAPS (RFC 1955 in 1996), GSE (draft-ipng-gseaddr-00 in 1997),
DSTM (draft-ietf-ngtrans-dstm in 1999-2002), LISP
(draft-farinacci-lisp in 2007-2009), RANGERS (draft-templin-ranger in
2008-2009), IVIT (draft-xu-behave-ivit in July 2009). But it has a
significantly different scope from all of them. In particular, LISP
introduces an Endpoint Identifier space different from the Routing
Locator space. Tunnels across the Internet core are consequently
always necessary. On the contrary, SAM's endpoint identifiers are
based on routable IPv4 and IPv6 address spaces. Tunnels across the
Internet core are therefore not necessary, which is important for
incremental deployability [RFC5218].
Compared to protocols such as SCTP [RFC4960] and Shim6 [RFC5533],
which specify how to use to multiple addresses in host endpoints, SAM
is complementary. It introduces new ways to assign multiple
addresses to hosts so that they can be used by SCTP or Shim6.
This SAM specification is an evolution from [-SAM-02] and [-SAM-03].
The former was focused on how NATs might be totally dispensed with if
SAM would be generalized (somewhat theoretical); the latter was
limited to how SAM supports multihoming in sites using private IPv6
addresses (practical, but too restrictive). This one is focused on
what SAM can provide, in a reasonable short term, in many
configurations (more practical, not restrctive). It also introduces
some technical improvements and, the author believes, substantial
clarifications.
The proposed specification is intended to be complete enough now to
permit compatible independent implementations, by developers skilled
in the art, with administratively configured parameters. (DHCP-
option formats have yet to be specified).
Being new, this specification is likely to have remaining
inadequacies and even, the devil being in details, sheer bugs. Many
improvements and corrections are therefore expected to be necessary
after more work, but the approach is believed to sound.
Implementation of a subset of this specification is under way at
Telecom Bretagne, in view of a first experimentation.
Despres Expires April 29, 2010 [Page 4]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
2. Example Scenarios
To mitigate consequences of the IPv4 address shortage during the
transition-to-IPv6 period, diverse solutions have been identified for
different scenarios: [Frmwk-trans] and [DSlite] are based on ISP
provisioned NATs (CGNs); [PRR] and [A+P], which can coexist with CGNs
or in some cases make them unnecessary, target hubs-and-spokes
configurations. They support dynamic reservations of port ranges
(with stateful mappings).
The two example scenarios below are similar to the latter
(coexistence with CGNs, with possibilities to bypass them), but
concerns mesh configurations, and is based on static port-range
assignments (stateless mappings).
SAM's applicability is much larger than described in these two
examples. They have been been chosen to insist on SAM's potential to
face the more and more pressing IPv4 address shortage problem.
2.1. A small ISP lacking enough global IPv4 addresses
Figure 1 shows the configuration of this first scenario.
The considered small ISP offers native IPv6 to its customers.
Because it has a /32 IPv6 prefix and assigns /48s to its customers,
it can support up to 64K of them. Now, due to the IPv4 address
shortage, it has only a /20 IPv4 prefix (a maximum of 4K global IPv4
addresses). This not being enough to assign one IPv4 address to each
customer, IPv4 address have to be shared. This can be done both
dynamically, for an optimized multiplexing efficiency but at a cost
of non-transparent NAT traversal, and statically, to avoid NAT
traversals and so that assigned addresses and ports can be safely
advertised outside (typically for server or peer-to-peer applications
that need incoming connections).
To support IPv4-only legacy hosts, and to offer dynamic port sharing
to all hosts including SAM-capable ones, the ISP of this scenario
operates a CGN for IPv4-to-IPv4 address translations (NAT44). To use
it, customers are assigned private IPv4 addresses of [RFC1918].
These addresses are obtained by customer-edge routers (CEs) in DHCPv4
[RFC2131].
The ISP assigns ports 0 to 32K - 1 of all its global IPv4 addresses
to its CGN, and ports 32K to 64K - 1 to SAM for its port-extended
IPv4 addressing.
Despres Expires April 29, 2010 [Page 5]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
INTERNET
IPv6-SubnetPrefix/64 (RA) BACKBONES
IPv6-Add (autoconf) |
PrivIPv4-Add (DHCPv4) IPv6-Pref/32 |
| | V
CUSTOMER-EDGE | |
NODES (CEs) | +-------------------------+ | +---------
| | | ISP NETWORK | | |
V | | IPv6 & private IPv4 |<=== |
+------------+<=== | +-------+ IPV6
| dual stack |<--- | | |
| only +------+ | |
| | | | +---------
+------------+ | |
| |
+------------+ | +-------+
| dual stack | | | CGN | +---------
| +------+------+ | NAT44 | |
| | SAM |<=== | | | |
| |<=== |<--- | +-------+-------+ IPV4
| | | | | | | |<=== |
+-----+--|---+ | | | SAM | | |
| | | | | | +---------
| | +-----------------+-------+ |
| |
| IPv6-SubnetPrefix/64 (RA) |
| IPv6-Add (autoconf) IPv4-Pref/20
| PrivIPv4-Add (DHCPv4)
|
IPv6-Pref/48
IPv4-Add:(PortPref/5)
Number of customer sites: 64K
NAT44 external ports : 2K / customer site
IPv4 assigned ports : 2K / customer site
AN ISP EXAMPLE WITH LESS IPv4 ADDRESSES THAN IPV6 /48 PREFIXES
Figure 1
With SAM, in a way that will be explained in subsequent sections, and
detailed for this example in Section 2.1, each dual-stack CE, in
addition to its possibility to use shared ports of the CGN like any
IPv4-capable CE, is statically assigned 2K reserved ports on a shared
global IPv4 address.
Despres Expires April 29, 2010 [Page 6]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Each CE has freedom to use these reserved ports its own way to take
advantage of the end-to-end Internet transparency they make possible.
In the next-section scenario, we describe how a particular CE uses
its reserved ports.
2.2. A small customer site having only a port-restricted IPv4 address
Figure 2 shows a possible scenario for a customer site whose ISP is
that of the previous section.
The considered customer site is residential or is that of a small-
office/home-office. It has up to 16 hosts on a single LAN. (This
LAN may include a switch between different physical media, like
copper wires, Wifi, power-lines, etc.).
For IPv4-only legacy hosts, the CE supports a NAT44, and a DHCP
server which assigns private IPv4 addresses. This NAT uses ports 4K
to 64K - 1 of the site private-IPv4 address. It also uses 1K ports
among the 2K reserved ports of the site global-IPv4 address. (With
these ports, it can support administratively configured port
forwarding, and dynamic reservation protocol such as NAT-PMP or
UPnP.)
In addition to IPv6 possibilities of all dual-stack hosts, SAM-
capable hosts are statically assigned IPv6 /52 prefixes. They may
use these prefixes freely, for example to run small LANs behind them,
e.g. in Bluetooth, with global-IPv6 addresses assignable to hosts of
these LANs.
In IPv4, each SAM-capable host is automatically assigned, besides its
private IPv4 address, 64 reserved ports of the site global IPv4
address. It can use them its own way, in particular to advertise
outside its ports on which it has server and/or peer-to peer
applications. It can also further distribute some of these reserved
ports to SAM-capable hosts on a LAN behind it.
Some protocols are known to traverse NATs without problem, like that
of Web requests (remote port 80) and that of DNS queries (remote port
53). In order to save ports of the site global IPv4 address for
other usages, outgoing connections having these protocols can use the
site private address and traverse both the site NAT44 and the CGN.
Note that, in the case of DNS queries, a known advantage of
traversing NATs is that used external ports are less predictable.
This is a known precaution to prevent the DNS attack identified by
Dan Kaminsky [DnsAttack].
Despres Expires April 29, 2010 [Page 7]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
IPv6-SubnetPrefix/64 (RA)
IPv6-Add (autoconf)
PrivIPv4-Add (DHCPv4)
HOSTS | IPv6-SubnetPrefix/64 (RA)
| | LAN IPv6-Add (autoconf)
| | IPv6 & private IPv4 PrivIPv4-Add (DHCPv4)
v | | |
+------------+ | | CUSTOMER-EDGE ROUTER (CE) |
| dual stack |<=== | +--------------------+ |
| only |<--- | | | |
| |<--- | | +-------+ | |
| +-------------+ | | | | <===
| | | | | NAT44 | | <---
+------------+ | | | | | <---
+-------+ +-------+-------+---------
+------------+ | | | SAM | SAM |
| dual stack | | | | |<=== |
| +-----+-------------+ | | | | |
| | SAM |<=== | +----+-------+--|----+
| |<=== |<--- | |
| | | |<--- | IPv6-Pref/48
+------+--|--+ | | IPv4-Add:(PortPref/5)
| |
| |
| IPv6-SubnetPrefix/64 (RA)
| IPv6-Add (autoconf)
| PrivIPv4-Add (DHCPv4)
|
IPv6-Pref/52
IPv4-Add:(PortPref/9)
Number of SAM hosts: 16
NAT44 external ports via ISP NAT44 : 60K = ~ 4K / host
NAT44 external ports on its public address: 512 = 64 / host
IPv4 assigned ports : 64 / host
A SMALL CUSTOMER SITE HAVING A PORT-RESTRICTED IPV4 ADDRESS
Figure 2
Despres Expires April 29, 2010 [Page 8]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
3. The SAM Model and its Terminology
Th SAM model is illustrated in Figure 3. SAM functional modules, or
"SAMs" for short, are located in "border nodes" of the SAM interior
routing domain (or "SAM domain" for short). These modules
encapsulate packets they receive from "exterior" domains, and forward
them across the SAM "interior" domain. In the other direction, they
decapsulate packets received from the interior to forward them on
their exterior domain.
.--------------- EXTERIOR --------------.
/ \
------'----> <---- INTERIOR ----> <----'-------
<--- CONSUMER SIDE --- --- PROVIDER SIDE --->
SUB-DELEGATED DELEGATED
prefixes prefixes
| interior | endpoint
| ADDRESSES | LOCATOR
endpoint | / \ | |
LOCATOR | / \ +--|------|-------
| | +---/-----------\---+ | | |
-----|----+ | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| +--|----+ | | +-------+ | |
| | | | | | | | | |
+--+ | | | | | | | | | | +--+
| +<--- |<=== |<--- --->| |<=== --->+ |
+--+ | SAM | | SAM | +--+
ENDPOINT | | SAM DOMAIN | | ENDPOINT
+-------+ +-------+
| | with defined | |
| ^ | INTERIOR ADDRESS | ^ |
-----------+ : | FORMAT(S) | : |
: +-------------------+ : |
: : +-----------
: :
<-------> <------->
in a BORDER NODE in a BORDER NODE
(host or router) (router)
SAM TERMINOLOGY
Figure 3
Despres Expires April 29, 2010 [Page 9]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
An endpoint "locator" can be a global-IPv4 or global-IPv6 address or,
if its endpoint is in a domain where port-extended IPv4 addressing is
used, an address-plus-port couple (A+P). (In domains using port-
extended addressing, endpoints exist only for applications that use
ports, i.e. all applications using TCP, UDP, DCCP, or SCTP. ICMP
error messages returned when packets of such connections are
discarded, because they contain the port numbers of discarded
packets, can reach such endpoints.)
With SAM, port-extended-addressing applies not only to IPv4, to deal
with the IPv4 address shortage, but also to IPv6. This not only
maintains orthogonality of features (avoidance of restrictions for
which there is no identified reason), but has also identified
applications. In particular, if a LAN is deployed behind a host
having a global IPv6 address but no IPv6 prefix, and if this LAN has
a frame format such that bridging in the host is not possible, then
port-extended IPv6 addressing on this LAN is a useful tool to provide
global IPv6 reachability to hosts on this LAN.
If one or several delegated prefixes are received from the exterior
side of a SAM (in DHCP or otherwise), these prefixes are called
"delegated prefixes" of the SAM domain, and the exterior side of this
SAM is called a "provider side" of the SAM domain.
If, conversely, a SAM delegates one or several prefixes to its
exterior domain, these prefixes are called "sub-delegated prefixes"
of the SAM, and the exterior side of this SAM is called a "consumer
side" of the SAM domain. As detailed in Section 7, prefixes that are
sub-delegated by a SAM are derived from the delegated prefixes of the
SAM domain and the "interior ID" of this SAM.
Delegated and sub-delegated prefixes, are prefixes of endpoint
locators. As such, they can be port-extended (up to 48 bits in IPv4
and 144 in IPv6).
4. SAM functional sub-modules and their parameters
Sub-modules of SAMs, both customer-side and provider-side, are shown
in Figure 4.
Despres Expires April 29, 2010 [Page 10]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
customer-side SAM
<- exterior interior ->
+-----------------+
| +-------------+ | | SAM PARAMETERS
| | DHCP client | |<=== | (obtained from a provider-side SAM)
| +-------------+ |
| | SAM | |
| | stateless | |
| | autoconf | |
| +-------------+ |
| | SAM | | provider-side SAM
| | map & encap | | <-- interior exterior -->
| +-------------+ | +-------------------+
+-----------------+ | +---------------+ |
| | stateless | |
SAM PARAMETERS | <====| | DHCP server | |
(provided to consumer-side SAMs) | | +---------------+ |
* Interior parameters | | | SAM | |
- SAM interior-address format(s) | | | map & encap | |
* Exterior parameters | | +---------------+ |
- provider-SAM interior address(es) | | |SAM-parameter | |
- their delegated prefix(es) | | | gatherer | |
| +---------------+ |
SAM PARAMETERS | | | DHCP | |
(obtained from other provider SAMs) | ===>| | multiple | |
| | client | |
Configured parameters: | +---------------+ |
* SAM interior-address format(s) |---.->| |
* interior addresses of provider SAMs | / +-------------------+
\
'----- delegated prefixes
of this SAM
SAM FUNCTIONAL MODULES AND THEIR PARAMETERS
Figure 4
A customer-side SAM has a DHCP client to obtain SAM parameters that
apply to its SAM domain. The DHCPv6 of [RFC3736] is used if IPv6
interior addresses are available, the DHCPv4 of [RFC2131] otherwise.
The SAM stateless autoconfiguration sub-module is, in a customer-side
SAM, in charge of building its "SAM interior address". This address
conforms to one of the SAM interior-address formats of the SAM
domain. This format is such that the interior ID of the SAM, shorter
than an address, can be derived from its SAM interior address. For
the IPv6 stateless address autoconfiguration of [RFC2462] to still
work with legacy hosts that may be on the same links, SAM interior-
Despres Expires April 29, 2010 [Page 11]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
addresses must have a different format from all possible addresses of
such hosts. For this, SAM interior addresses have a SAM tag that
distinguishes them, as detailed in Section 5.2. In IPv4, the
autoconfiguration is based on [RFC3927], applied to interior
addresses of Section 5.3. IPv4 SAM interior addresses, having no
place for a SAM tag, have to be distinguished from other interior
addresses by means of distinct subnet prefixes.
The SAM map&encap sub-module is present in all SAMs, customer-side as
well as provider-side. It checks that source and destination
locators received by a SAM from either of its sides are authorized.
It also has to check that, in packets received from its interior
side, source and destination interior addresses of encapsulating
packets are consistent with source and destination endpoint locators
of encapsulated packets. If these checks don't fail, packets are in
the exterior-to-interior direction encapsulated as specified in
[RFC4213], and are in the interior-to-exterior direction
decapsulated.
The DHCP-server sub-module is, as far as SAM parameters are
concerned, stateless (no need to maintain states about customer-side
SAMs). It is in charge of transmitting SAM parameters of the SAM
domain to customer-side SAMs from which it receives queries. These
parameters are those that have been collected by the SAM-parameter
gatherer sub-module. In a node that already needs a DHCP server for
other purposes, the SAM DHCP-server sub-module can be this DHCP
server.
The SAM-parameter gatherer sub-module makes a synthesis of:
o delegated prefixes received from the exterior side of the SAM;
o the interior address of the SAM.
o parameters that are administratively configured for this SAM (i.e.
formats of SAM interior addresses and, if the SAM domain is multi-
homed, the list of interior addresses of other provider-side
SAMs);
o parameters that are obtained from other provider-side SAMs by the
DHCP multiple client sub-module;
The interior address of a provider-side SAM must be distinguishable
from that of a customer-side SAM for routing-loop-attack prevention
as explained in Section 8. It has therefore to be obtained as a
classical IPv6 address (whose format is different from that of SAM
interior addresses that customer-side SAMs obtain as detailed in
Section 5).
Despres Expires April 29, 2010 [Page 12]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
The SAM-parameter gatherer module queries stateless DHCP servers of
other provider-side SAMs. It merges all parameters it thus receives
with those received locally. It checks that SAM interior-address
formats are consistent (identical if they have the same format ID, as
specified in Section 5).
All SAM functions being stateless, each SAM can be duplicated to
sustain traffic loads that exceed a single processor capacity. All
instances must have the same SAM interior address (routed as an
anycast address in the SAM domain).
5. Mapping between SAM Interior Addresses and SAM interior IDs
5.1. SAM-interior-address Formats
A SAM interior-address format has the following sub-parameters:
o A "format ID" F. Having several formats in a SAM domain permits to
have in a SAM domain link subnets having different lengths, and to
sub-delegate prefixes having different lengths. If a SAM domain
has only one SAM interior-address format, the format ID is not
needed. Its length can then be set to 0. If there are several
non-null-length formats, their IDs must be non overlapping
prefixes so that they can be recognized in locators. (For
example, 0, 100, 1O1, 110, 1110, and 1111, are compatible format
IDs, but not 01 and 011).
o A "common prefix" C. In SAM domains that use private address
spaces, C can for example be in IPv4 10.0.0.0/8 [RFC1918]. In
IPv6, it can be a /48 randomly selected prefix of [RFC4193], used
to build Unique Local IPv6 addresses in the SAM domain. In one of
the provider-side SAMs of the domain, C can be administratively
specified to be a received delegated prefix of the SAM (as short
as possible if there are several) rather than a given constant.
In this case the interior address space is a global, as in
examples of Section 9.
o The "subnet-ID" length s. If a SAM domain has several links
having different subnet prefixes, it needs several formats.
Subnet IDs are the fields that appear after Cs to distinguish
subnet prefixes. In a site with only one link, subnet IDs are not
needed, and s can be set to 0.
o The "host-ID" length h. In a SAM interior address, the host ID is
in the lower part of the address. Two consumer SAMs that are on a
common link have different host IDs, obtained by
autoconfiguration.
Despres Expires April 29, 2010 [Page 13]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
5.2. SAM Interior Addresses and SAM Interior IDs in IPv6
Figure 5 shows the reversible mapping between SAM interior address
and interior ID in IPv6.
A SAM tag is necessary, in the stateless address autoconfiguration of
[RFC2462], to distinguish SAM interior addresses from other IPv6
addresses on the same link. It is enough for this that the two lower
bits of addresses 9th octet be set to 0b11 (a value which differs
from that of all currently IPv6 addresses specified in [RFC4291]).
Other bits of the octet are proposed to be all set to 1 to keep an
escape mechanism for future new IPv6 address formats.
SAM INTERIOR ADDRESS - IPv6
common prefix subnet ID SAM format ID host ID
| (s may be 0) tag | (f may be 0) |
| | | | |
V V V V V
<----------c---------><--s-> <-8-><f-> <--h--->
<------------- 64 -------------><------------- 64 ------------->
+---------------------+-----+---+----+---+--------------+------+
| C |XXXXX| 0 |0xFF| F | 0 |XXXXXX|
+---------------------+-----+---+----+---+--------------+------+
| | / / / /
Format /\ |_____|______/ / / /
Parameters || / __|_________/ / /
F, C, s, h || /| / | _____________________/ /
|| / | / | / _____________________/
\/ / |/ |/ /
+---+-----+------+
|"F"|XXXXX|XXXXXX|
+---+-----+------+
<---- f+s+h ---->
SAM INTERIOR ID
MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv6
Figure 5
Despres Expires April 29, 2010 [Page 14]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
5.3. SAM Interior Addresses and SAM Interior IDs in IPv4
Figure 6 shows the reversible mapping between SAM interior addresses
and SAM interior IDs in IPv4.
In IPv4 SAM interior addresses, there is not, like in IPv6, a place
to have different format IDs without interfering with routable subnet
prefixes. If there are several links in a SAM domain, there should
then be only one format. SAM interior IDs have then the same length
for all consumer-side SAMs of the SAM domain. If on the other hand
there is only one link in the SAM domain, different format IDs can be
used to have several host-ID lengths, which permits several sub-
delegated-prefix lengths.
SAM INTERIOR ADDRESS - IPv4
format
constant ID
prefix (optional) host ID
| | |
| | subnet |
| | ID |
| | (s may be 0) |
| | | |
V V V V
<------c-----><f-><-s-> <-h->
<--------------- 32 --------------->
+-------------+---+----+-------+----+
| C |"F"|XXXX| 0 |XXXX|
+-------------+---+----+-------+----+
Format /\ | | | / /
Parameters || | | | ___/ /
F, C, s, h || | | | / ___/
\/ | | |/ /
+---+----+----+
|"F"|XXXX|XXXX|
+---+----+----+
<---- s+h ---->
SAM INTERIOR ID
MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv4
Despres Expires April 29, 2010 [Page 15]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Figure 6
Because of this lack of flexibility of IPv4 SAM interior addresses,
IPv6 should be used for SAM interior addresses if both IPv6 and IPv4
are possible.
6. SAM Prefixes and SAM Raw Prefixes
An important feature of SAM is that the free hierarchical structure
of addresses, which has been advantageously introduced in IPv4 with
the classless inter-domain routing of [RFC1519] (CIDR), is
generalized: in IPv4, where it currently applies only to the 32-bits
of IPv4 addresses, it is extended to 48 bits with port-extended IPv4
addresses; in IPv6, where it currently applies only to the first 64
bits of IPv6 addresses, it is first extended to their full 128 bits,
and then to 144 bits with port-extended IPv6 addresses.
This flexibility in prefix lengths considerably extends the
possibility to organize routing domains in a hierarchical setup.
Each domain receives delegated prefixes from its provider-side
domains, and assigns sub-delegated prefixes to its customer-side
domains.
Some precautions are however necessary, due to format constraints
which exist on IPv6 addresses [RFC4291] and on port numbers
[RFC1700].
Concerning IPv6 address formats, there is an ongoing debate about
accepting, or not, that subnet prefixes of IPv6 addresses that never
appear directly as destinations on IPv6 links might be extended
beyond 64 bits, with any value in 9th octet. (For example, ISATAP
addresses of [RFC5214] are such IPv6 addresses. They do comply with
the 9th octet constraint of [RFC4291] but, with the freedom under
discussion, they could have been specified without it).
The only technical reason known by the author against this new
freedom on IPv6 address formats relates routing-loop-attack
prevention. (These attacks have been found to be possible with some
ISATAP and 6to4-relay routers. It was first documented on July 16
2009 by Gabi Nakibly in an e-mail to the v6ops mailing list. It is
still unclear whether the 9th octet constraint is useful to prevent
some of these attacks or not). By precaution, we assume in this
draft that the 9th octet constraint still holds. If it can be
relaxed, some of the complexity introduced below to distinguish SAM
raw prefixes from SAM prefixes can disappear.
Despres Expires April 29, 2010 [Page 16]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Concerning port-number prefixes used as address extensions, they must
exclude the well-known-ports range 0-1023 of [RFC1700] because it has
specific interpretations in firewalls and in hosts. For this reason,
ports prefixes used for address extension will have their first bit
always set to 1.
IPv6 SAM PREFIX up to 64 bits
+------------+-------------------+
|XXXXXXXXXXXX|...................| IPv6 ADDRESS
+------------+-------------------+ (128 bits)
: :
+------------+
|XXXXXXXXXXXX|
+------------+
IPv6 SAM RAW PREFIX up to 64 bits
IPv6 SAM PREFIX up to 128 bits
<----- 64 -----><8><---->
+---------------+--+-----+-------+
|XXXXXXXXXXXXXXX|FF|XXXXX|.......| IPv6 ADDRESS
+---------------+--+-----+-------+ (128 bits)
: : / /
: :/ /
+---------------+-----+
|XXXXXXXXXXXXXX |XXXXX|
+---------------+-----+
IPv6 SAM RAW PREFIX up to 120 bits
IPv6 SAM PREFIX up to 144 bits
<----- 64 -----><8><--- 56 ----><1><>
+---------------+--+-------------+-+--+---+ IPv6 ADDRESS
|XXXXXXXXXXXXXXX|FF|XXXXXXXXXXXXX|1|XX|...| + PORT
+---------------+--+-------------+-+--+---+ (144 bits)
: : / / / /
: :/ / / /
: : : / /
: : :/ /
+---------------+-------------+--+
|XXXXXXXXXXXXXXX|XXXXXXXXXXXXX|XX|
+---------------+-------------+--+
IPv6 SAM RAW PREFIX up to 135 bits
1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv6
Despres Expires April 29, 2010 [Page 17]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Figure 7
To deal with the above format constraints, a distinction is made
between "SAM raw prefixes", and "SAM prefixes":
o SAM raw prefixes are fully hierarchical, like classical CIDR
prefixes, with all their bits permitted to have any values.
o SAM prefixes, which may span all bits of A+P locators, have some
fixed fields to be complied with if they are long enough to reach
these fixed fields.
Detailed mappings between SAM prefixes and SAM raw prefixes are shown
in Figure 7 and Figure 8, for IPv6 and IPv4 respectively.
IPv4 SAM PREFIX up to 32 bits
+------------+-----+
|XXXXXXXXXXXX|.....| IPv4 ADDRESS
+------------+-----+ (32 bits)
: :
+------------+
|XXXXXXXXXXXX|
+------------+
IPv4 SAM RAW PREFIX up to 32 bits
IPv4 SAM PREFIX up to 48 bits
<------- 32 ------><1><->
+------------------+-+---+--+ IPv4 ADDRESS
|XXXXXXXXXXXXXXXXXX|1|XXX|..| + PORT
+------------------+-+---+--+ (48 bits)
: :/ /
: : /
: : :
: : :
+------------------+--+
|XXXXXXXXXXXXXXXXXX|XX|
+------------------+--+
IPv4 SAM RAW PREFIX up to 47 bits
1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv4
Figure 8
Despres Expires April 29, 2010 [Page 18]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
7. Derivation of Sub-delegated prefixes from Delegated Prefixes and
Interior IDs
Raw sub-delegated prefixes are built, in each SAM domain, according
to the CIDR principle: each domain in the hierarchy adds its SAM
interior ID to its raw delegated prefixes. Actual sub-delegated
prefixes are then derived from raw sub-delegated prefixes as detailed
in Section 6. Figure 9 shows successive steps of sub-delegated-
prefix constructions.
IPv4 or IPv6
+--------------+
| INTERIOR ID |
+--------------+
IPv4 or IPv6 | || :
+------------------------+ || :
| a DELEGATED PREFIX | || :
+------------------------+ || :
: || : || :
: \/ : || :
+------------------------+ || :
| its derived RAW PREFIX | || :
+------------------------+ || :
: || : || :
: \/ : \/ :
+---------------------------------------+
| the derived SUB-DELEGATED RAW PREFIX |
+---------------------------------------+
: || :
: \/ :
+---------------------------------------+
| the derived SUB-DELEGATED PREFIX |
+---------------------------------------+
IPv4 or IPv6
1:N MAPPING BETWEEN INTERIOR IDs AND DELEGATED PREFIXES
Figure 9
Despres Expires April 29, 2010 [Page 19]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
8. Mapping from Source and Destination Endpoint Locators to Source and
Destination Interior Addresses
8.1. Encapsulation Function
In the encapsulation function of a SAM, the following rules govern
how source and destination addresses of encapsulating packets are
derived from source and destination locators found in packets to be
encapsulated:
PROVIDER-SIDE-SAM ENCAPSULATION
1. The source locator MUST NOT match any delegated prefix of this
SAM (spoofing prevention), and the destination locator MUST match
one of them (there is upstream a routing-configuration error if
it doesn't).
2. In the destination locator, an interior ID MUST be extractible
from bits that follow the prefix of this SAM that is matched.
The destination interior address is then derived from this
interior ID, and the source interior address is the interior
address of this SAM.
CUSTOMER-SIDE-SAM ENCAPSULATION
1. The source locator MUST match a sub-delegated prefix of this SAM
(spoofing prevention), and the destination locator MUST NOT match
any of them (there is upstream a routing-configuration error does
match).
2. If the destination locator matches a delegated prefix of the SAM
domain, an interior ID MUST be extractible from bits that, in
this destination locator, follow the matched delegated prefix.
The destination interior address is then derived from this
interior ID, and the source interior address is the SAM interior
address of this SAM.
3. If the destination locator doesn't match any delegated prefix of
the SAM domain, the destination interior address is that of the
provider-side SAM that has, among its delegated prefixes, one
that matches the source locator. The source interior address is
the interior address of this provider-side SAM.
Despres Expires April 29, 2010 [Page 20]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
8.2. Decapsulation Function
In the decapsulation function of a SAM, the following rules have be
complied with to ensure that source and destination addresses of
encapsulating packets and source and destination locators of
encapsulated packet are valid. (They have to be consistent both
among themselves and with parameters of the SAM.)
PROVIDER-SIDE-SAM DECAPSULATION
1. The source locator MUST match a delegated prefix of this SAM
(spoofing prevention), and the destination locator MUST NOT match
any of them (there is upstream a routing-configuration error if
it does match).
2. An interior ID MUST be extractible, in the source locator, from
its bits that follow the matched delegated prefix. The source
interior address MUST be the SAM interior address which is
derived from this interior ID. (This check makes it impossible
that a packet coming from another provider-side SAM be accepted,
the interior address of this other SAM being different from any
SAM interior address. Routing-loop attacks are thus prevented).
The destination interior address MUST be this SAM's interior
address.
CUSTOMER-SIDE-SAM DECAPSULATION
1. The source locator MUST NOT match any sub-delegated prefix of
this SAM (spoofing prevention), and the destination locator MUST
match one of them (there is upstream a routing-configuration
error if it doesn't).
2. If the source locator matches a delegated prefix of the SAM
domain, an interior ID MUST be extractible from this source
locator in bits that follow the matched delegated prefix. The
source interior address MUST be that which is derived from this
interior ID, and the destination interior address MUST be the
interior address of this SAM.
3. If the source locator doesn't match any delegated prefix of the
SAM domain, the destination locator MUST match one of the sub-
delegated prefixes of the SAM, and the source interior address
MUST be that of a provider-side SAM whose delegated prefix is at
the beginning of this sub-delegated prefix. The destination
interior address MUST be the interior address of this SAM.
Despres Expires April 29, 2010 [Page 21]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
9. Detailed Prefixes for the Example Scenarios
We now return to the two scenarios of Section 2 to show how the
described SAM mechanisms can deliver what was claimed.
INTERNET
ISP NETWORK BACKBONES
| 2001:a::/32 |
V | V
+-------------------------+ | +---------
| IPv6 & private IPv4 | | |
| |<=== |
| 0::/0 ===>+-------+ IPV6
| | |
| | |
CUSTOMER-EDGE | | +---------
NODES | link 5 |
| | 2001:a:50000::/64 (198.0.0.0/20):(0/1)
V | 10.0.0x50.0x44 | /
+------------+ | | +-------+ /
| dual stack | | | | |/ +---------
| +------+------+--+ 0../0 ===>| NAT44 / |
| | SAM |<--- | | | /| |
| |<=== |<--- | | +-------+-------+ IPV4
| | | | | | | |<=== |
+-----+--|---+ | | --->| SAM | | |
| | | | | | | +---------
| | +---------------|-+-------+ |
| | \ |
| 2001:a:5000:0:ff00::222 | |
| (SAM autoconf on link 5) | 198.0.0.0/20
| 10.0x52.0x22.0 (DHCPv4) |
| |
| |
2001:a:5222::/48 2001:a:0000:0:<EUI-64>
198.0.1.0x22:(0b10010/5) (autoconf on link 0)
SAM interior-address format: C=2001:a::/32; F=0/0; s=4; h=12
Number of customer sites: 64K
NAT44 external ports : 2K / customer site
IPv4 assigned ports : 2K / customer site
(IPv6 assigned ports : 64K / customer site)
EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 1
Despres Expires April 29, 2010 [Page 22]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Figure 10
Figure 10 and Figure 11 respectively deal with the small ISP scenario
of Section 2.1 and with the customer site scenario of Section 2.2.
LAN 10.0.0x54.0x44
2001:a:5222:0::/64 198.0.1.0x22:(0b100100/6)
192.168.0.0/24 |
| |
| CUSTOMER-EDGE ROUTER |
| +---------------|----+
SAM | | +-------+ | |
HOSTS | | | | / |
| | | ==>| NAT44 |/ |
V | | | | |
+-------+ +-------+-------+---------
+------------+ | --->| | | ISP |<---
| dual stack | | ===>|--->| SAM | SAM |<---
| +-----+-------------+ | | | |<=== | |
| | SAM |<=== | | +----+-------+--|----+ |
| |<=== |<--- | | | \
| | | |<--- | | | |
+------+--|--+ | | 2001:a:5222::/48 |
| | | 198.0.1.0x22:(0b10010/5) |
| | | |
| | 2001:a:1222:0:<EUI-64> /64 |
| | (autoconf) |
| | 0.0.0.0/0 |
| | |
| 2001:a:5222:0::/64 (RA) |
| 2001:a:5222:0:ff00::3 2001:a:5000:0:ff00::222
| (SAM autoconf) (SAM autoconf)
| 192.168.0.x (DHCPv4) 10.0.0x54.0x44 (DHCPv4)
|
2001:a:1222:3000::/51
198.0.1.0x22:(0b1001010011/10)
SAM interior-address format: C=2001:a:5222::/48; F=0/0; s=0; h=4
Number of SAM hosts : 16
NAT44 shared external ports via ISP-NAT : 4K / host
NAT44 shared external ports on a global add : 64 / host
IPv4 assigned ports : 64 / host
EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 2
Figure 11
Despres Expires April 29, 2010 [Page 23]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
10. Applicability to other scenarios
SAM can be used across ISP networks that route exclusively in IPv6
like those of in [IVI]. With SAM, IPv4 end-to-end transparency, port
extended or not, can be offered as an additional possibility to IVI
customers that are SAM-capable (with IPv4 packets encapsulated in
IPv6 packets).
Other SAM scenarios, which are numerous, are beyond the scope of this
particular version of the draft. Some should be added in later
versions.
11. Security considerations
Provided all address checks of Section 8 are performed, as required
by this specification, no new security risk has been identified.
12. IANA Considerations
The SAM tag in the 9th octet of IPv6 addresses, used to distinguish
SAM interior addresses from other IPv6 addresses, should in due time
be registered by IANA.
Also, if an when detailed formats for SAM-specific DHCP options are
agreed on, they will have to be submitted to IANA.
13. Acknowledgments
This specification is mostly the result of a personal effort of the
author, in continuation with what he did for 6rd [Free's IPv6 in
2007], but high recognition is due to Mark Townsley who listened to
intermediate stage presentations, provided useful reactions, and was
a convincing advocate for a Cisco Research Grant to be allocated to
Telecom Bretagne, for a validation of a subset of SAM. Special
thanks are also due to Laurent Toutain. After having seen SAM's
potential, he planned an experiment with students at Telecom
Bretagne. Dave Thaler made a precious detailed review of an earlier
draft. Beyond this, the open discussion environment of IETF in
general has been a continuous encouragement.
Despres Expires April 29, 2010 [Page 24]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
14. References
14.1. Normative References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
14.2. Informative References
[-SAM-02] Despres, R., "Stateless Address Mapping (SAM) - Avoiding
NATs and restoring the end-to-end model in IPv6",
March 2009.
[-SAM-03] Despres, R., "Scalable Multihoming across IPv6 Local-
Address Routing Zones - Global-Prefix/Local-Address
Stateless Address Mapping (SAM)", July 2009.
[6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks, draft-ietf-softwire-ipv6-6rd", August 2009.
[A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage -
draft-ymbk-aplusp-04", July 2009.
[DSlite] Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion - draft-ietf-softwire-dual-stack-lite-01",
July 2009.
[DnsAttack]
Friedl, S., "An Illustrated Guide to the Kaminsky DNS
Vulnerability -
http://unixwiz.net/techtips/
iguide-kaminsky-dns-vuln.html", August 2008.
[Free's IPv6 in 2007]
Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd) - draft-despres-6rd-03", April 2009.
Despres Expires April 29, 2010 [Page 25]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
[Frmwk-trans]
Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
Translation - raft-baker-behave-v4v6-framework-02",
February 2009.
[IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 - Coexistence and Transition -
draft-xli-behave-ivi-02", June 2009.
[Ipv4Shortage]
Levis, P., Boucadair, M., Grimault, JL., and A.
Villefranque, "IPv4 Shortage: Needs and Open Issues -
draft-levis-behave-ipv4-shortage-framework-01",
March 2009.
[PRR] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"Pv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture -
draft-boucadair-port-range-02", July 2009.
[PrefSubDeleg]
Baker, F., "Prefix Sub-delegation in a SOHO/SMB
Environment - draft-baker-ipv6-prefix-subdelegation-00",
July 2009.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
Despres Expires April 29, 2010 [Page 26]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, October 2005.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, July 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd) - Publication delayed since May 2009
for a reason common to all independent-submission RFCs".
Despres Expires April 29, 2010 [Page 27]
Internet-Draft SAM - Mesh Softwires without e-BGP October 2009
Author's Address
Remi Despres
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Despres Expires April 29, 2010 [Page 28]
