Internet Engineering Task Force R. Despres
Internet-Draft RD-IPtech
Intended status: Standards Track July 13, 2009
Expires: January 14, 2010
Scalable Multihoming across IPv6 Local-Address Routing Zones
Global-Prefix/Local-Address Stateless Address Mapping (SAM)
draft-despres-sam-03
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 January 14, 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
The continuous growth of routing tables in the core of Internet is a
challenge. It would become overwhelming if each multihomed customer
Despres Expires January 14, 2010 [Page 1]
Internet-Draft Stateless Address Mapping (SAM) July 2009
site would need a provider independent prefix to take full advantage
of its multihoming. IPv6 has the potential to solve this problem,
but a complete specification is still missing. This draft proposes
an approach for a solution.
The Stateless Address Mapping (SAM) model, introduced for this, is
applicable to a hierarchy of routing zones with multihoming permitted
at each level, and with each zone using local addresses for its
internal routing plan. End-to-end transparency of the Internet is
maintains across these local-address zones, thanks to a systematic
encapsulation of global-address packets into local-address packets.
Local addresses are statelessly derived from prefixes found in global
addresses, and from static parameters of traversed zones. Global
prefixes delegated by a zone to its child interfaces can be obtained
by autoconfiguration, thanks to to a bidirectional correspondence
between SAM local addresses and SAM global prefixes.
Deployment can be incremental.
Despres Expires January 14, 2010 [Page 2]
Internet-Draft Stateless Address Mapping (SAM) July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Multihoming in Hierarchized Routing Zones . . . . . . . . 5
2.2. Routing Zones in which Addressing is Local . . . . . . . . 7
2.3. Anti-Spoofing Compatibility . . . . . . . . . . . . . . . 7
2.4. Autoconfiguration of Global Prefixes . . . . . . . . . . . 9
2.5. IPv6 hierarchical addressing beyond 64 bits . . . . . . . 10
3. SAM proposed specification . . . . . . . . . . . . . . . . . . 10
3.1. SAM Parameters advertised to SAM Child Interfaces . . . . 10
3.2. SAM Formats for Local Addresses and Global infixes . . . . 11
3.2.1. SAM Subnet Prefixes . . . . . . . . . . . . . . . . . 11
3.2.2. SAM IIDs . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. SAM Global Infixes . . . . . . . . . . . . . . . . . . 13
3.3. Autoconfiguration Procedure for SAM Interfaces . . . . . . 14
4. Application Example . . . . . . . . . . . . . . . . . . . . . 15
5. Security considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Despres Expires January 14, 2010 [Page 3]
Internet-Draft Stateless Address Mapping (SAM) July 2009
1. Introduction
The continuous growth of routing tables in the core of Internet is
one of the important challenges to be faced. This growth would
become an overwhelming problem if each multihomed customer site would
need a provider independent prefix to take full advantage of its
multihoming. As analyzed in particular in [RFC3582], [RFC3582], and
[RFC4219] , IPv6 should help to solve this problem, but a complete
solution has yet to be proposed. Such a solution is needed in not to
far a future because of the increasing variety of access
technologies, both terrestrial and by radio, and because of the
increasing number of usages that require service continuity, both of
these tendencies leading to more and more multihoming.
This draft describes an attempt at filling this gap, using for this a
Stateless Address Mapping model (SAM), between local addresses and
global prefixes.
The SAM model applies to hierarchies of independently administered
routing zones where multihoming is possible anywhere in the hierarchy
(each zone may have several parent zones). Each zone in the
hierarchy has its internal routing based on a local addresses.
End-to-end Internet transparency, as defined in [RFC2775] is
important in particular for IPsec security and for various address
referrals. Despite traversals of zones where addressing is local,
SAM maintains end-to-end transparency, using for this a systematic
encapsulation of global-address packets in local-address packets.
To have a unique routing plan for both local addresses and delegated
global prefixes, and to permit autoconfiguration of delegated
prefixes, a bidirectional correspondence is established between local
addresses and global prefixes. This correspondence depends
statelessly on only a few zone parameters.
With its encapsulations and address mappings, SAM can be viewed as a
generalization, to IPv6 in IPv6 and to routing-zone hierarchies with
multihoming, of techniques used, for IPv4 in IPv6, in the ISATAP of
[RFC5214], the 6to4 of [RFC3056], and the 6rd of [RFC 5569].
In SAM's multihoming support, precaution is taken to guarantee that
routes toward the global Internet can also be taken in the reverse
direction. This is for compatibility with ingress filtering, the
basic anti-spoofing mechanism of [RFC3704].
In an incremental deployment of SAM, SAM-capable hosts that are in
SAM-capable sites take advantage of SAM-specific benefits
independently of when other hosts and sites become SAM capable.
Despres Expires January 14, 2010 [Page 4]
Internet-Draft Stateless Address Mapping (SAM) July 2009
These benefits include end-to-end Internet transparency, continued
Internet connectivity as long as at least one interface to the
Internet of the site is operational, and possible load sharing or
fast recovery if several such interfaces are operational. In this
respect, SAM is an complement to STTP [RFC4960] and to SHIM6
[RFC5533]: these protocols exploit several source addresses but have
no control by themselves on which gateways to the global Internet
packets go through; without such a control, packets sent by Shim6 or
SCTP can be routed through a gateway that is incompatible with
ingress filtering, and can be systematically lost (a black hole
situation).
Previous versions of this draft had a wider scope, which included
some port-range extension of IPv4 addresses, some privacy protection
in IPv6, and a discussion of IPv6 NATs. This version is purposely
much more focused. The scope is now limited to IPv6 multihoming in a
hierarchy of local-address routing zones. The idea is that this is
an application case needing a rather short term solution, while other
subjects, of more debatable interest, would delay acceptability of
the limited-scope solution.
Future evolutions of the SAM proposal, and improvements of its
presentation, are still expected to take place. This early-stage
proposal is submitted to open it to collective work in a direction
that is felt important.
2. Problem statement
2.1. Multihoming in Hierarchized Routing Zones
The principle of hierarchical addressing is that the hierarchy of a
number of independently administered routing zones is directly
reflected in global prefixes that are assigned to these zones.
Formats of CIDR IPv4 addresses, and of IPv6 subnet indexes in the
first 64 bits of IPv6 addresses, are particular applications of
hierarchical addressing.
In the absence of multihoming, a routing-zone hierarchy is a tree.
Each zone has only one global prefix. The global prefix delegated to
a zone is that of it's parent parent zone followed by the infix that,
in its parent zone, identifies this particular child of his.
Despres Expires January 14, 2010 [Page 5]
Internet-Draft Stateless Address Mapping (SAM) July 2009
routing zone
_____________
/ \
child parent
prefixes child prefixes
|| infixes ||
\/ || \/
\/
ACDF... ACD... AC... A...
ACEF... BD... | | .------.
BDF... | | .------.v | |
BE... | .------.V | |------|A |
| .------.V | |------|C | | |
| | |------|D | | | | |
V | | | | '------' | |
------|F | | | | |
| | | | | |
| |------|E | | |
| |^ | |--------------------|B |
'------'| | |^ | |
| '------'| | |
| | '------'
ACE... |
BE... B...
GLOBAL-PREFIX INHERITANCE EXAMPLE IN A HIERARCHY WITH MULTIHOMING
Figure 1
But with multihoming, zones may have several global prefixes. As
illustrated in Figure 1, Prefixes delegated to a zone, at one of its
parent interfaces, can be all those of its parent zone at this
interface followed by the infix that, in this parent zone, identifies
this particular child. This is illustrated in Figure 1 in which
letters C to F are infixes, and ACDF..., for example, is a notation
for a global prefix composed global prefix A followed by successive
infixes C, D, and F.
The SAM model is devised to support multihoming in such routing-zone
hierarchies.
Despres Expires January 14, 2010 [Page 6]
Internet-Draft Stateless Address Mapping (SAM) July 2009
2.2. Routing Zones in which Addressing is Local
Local address spaces in customer sites are largely used in IPv4 for a
number of reasons, only one of which being the lack of enough global
addresses for all hosts. Reasons to also use local addresses in IPv6
are documented in particular in [RFC4193]. Particularly important is
the stability of routing plans, in independently administered zones,
when global prefixes that are assigned to these zones are modified,
added, or deleted (renumbering simplicity).
But local address spaces have a drawback: unless some precaution is
taken, they conflict with Internet transparency as defined in
[RFC2775]: local addresses being prohibited in the core of Internet,
a packet having a local-address source cannot traverse the global
Internet, and some address translation is needed somewhere. To avoid
this loss of transparency with SAM, local addresses are only used
encapsulating packets in which global-address packets, to be
transmitted end to end, are encapsulated.
2.3. Anti-Spoofing Compatibility
The anti-spoofing mechanism of [RFC3704], i.e. ingress filtering,
requires that if a packet is routed across an interface in one
direction, a packet with inverted source and destination has a valid
route to traverse the same interface in the reverse direction.
In a multihomed routing zone, child nodes must therefore control via
which parent interface they send packets toward the global Internet:
if a packet transmitted by a child node has, at the beginning of its
source address, a global prefix that has been assigned to the zone at
its parent interface P, the packet must exit the zone via this
interface P.
Figure 2 shows, for a generic multihomed site, which encapsulations
are permitted to respect these constraints.
Despres Expires January 14, 2010 [Page 7]
Internet-Draft Stateless Address Mapping (SAM) July 2009
.------------------------- global prefixes ---------------------.
| |
| .------------------ local addresses ----------------. |
| | | |
| | encapsulated and encapsulating addresses | |
| | | | |
| | | | |
V V V V V
.-------------------------------------------------------.
| |
| |
AC... | |
BC... | [AC... => ...] in [@c => @1] | A...
------|@c --.>-------------------------------------------> @1|------
| | |
| | |
| | |
| | |
| | |
| | [BC... => ...] in [@c => @2] | B...
| .>------------------------------------------> @2|------
| | |
| | |
| | [AC... or BC... => A... or B...] in [@c => ...] |
| .>-----------------------------------------. |
| \ |
| | |
| <----------<. |
AD... | | |
BD... | [AD... or BD... <= ...] in [@d <= ...] | |
------|@d <--------------------------------------------<. |
| | |
/\ | / | /\
|| | <----------' | ||
|| | | ||
|| '-------------------------------------------------------' ||
|| ||
CHILD INTERFACES PARENT INTERFACES
ENCAPSULATION CONSTRAINTS FOR MULTIHOMING WITH INGRESS FILTERING
Figure 2
Despres Expires January 14, 2010 [Page 8]
Internet-Draft Stateless Address Mapping (SAM) July 2009
2.4. Autoconfiguration of Global Prefixes
Stateless autoconfiguration has been specified for IPv6 to greatly
simplify host address assignments [RFC2462] .
As mappings are necessary for SAM between local addresses and global
prefixes, an extension of autoconfiguration to global prefixes can be
envisaged. It's principle, illustrated in Figure 3, is to establish
a 1:1 correspondence between the local address of a child interface
and the global infix which, appended to a global prefixes of its
parent zone, gives a global prefix of this interface.
<---------------------------- (128 bits) --------------------->
| |
._______ ... _____.__ ... __. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| parent | child | :
| global prefix | global | :
| | infix | :
|_______ ... _____|__ ... __| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _:
<--- CHILD GLOBAL PREFIX --->
<========>
/\
||
|| 1:1 CORRESPONDENCE
||
||
\/ CHILD LOCAL ADDRESS
<==============================================================>
______________________________________________________________
| child | child |
| subnet prefix | IID |
| (64 bits) | (64 bits) |
|_______________________________|______________________________|
CORRESPONDENCE BETWEEN LOCAL ADDRESSES AND GLOBAL PREFIXES
Figure 3
Despres Expires January 14, 2010 [Page 9]
Internet-Draft Stateless Address Mapping (SAM) July 2009
2.5. IPv6 hierarchical addressing beyond 64 bits
[RFC4291] currently imposes that ALL IPv6 addresses have a formatted
IID in their 64 lower bits, although the role of formatted IIDs only
appears the Stateless Autoconfiguration Procedure of [RFC2462].
Applying this constraint to hierarchical addresses of Section 2.1
even if they are those of hosts in local-address zones of Section 2.2
artificially prohibits to extend infix sequences beyond 64 bits.
(Hosts that are in local-address zones never use their global
addresses on any IPv6 link. The Stateless Autoconfiguration
Procedure only applies to local addresses that are derived from these
global addresses.)
Relaxing the 64-bit constraint for hierarchical addresses of
Section 2.1 if lower zones of the hierarchy have local addressing is
possible without interfering with the role of IIDs on IPv6 links.
This remark is a contribution to 6man, the Working Group in charge
maintaining the IPv6 specification. It is a request that compliance
with IID formats in the 64 lower bits of IPv6 addresses be not
imposed to addresses that cannot be directly used on IPv6 links.
3. SAM proposed specification
3.1. SAM Parameters advertised to SAM Child Interfaces
For a child of a zone to know the parent interface of the zone via
which it has to send a packet toward the global Internet, it needs to
know local addresses of all parent interfaces of the zone with, for
each of them, the list of global prefixes that are delegated to the
zone at this interface.
In the example of Figure 2, child interfaces that are respectively at
local addresses @c and @d need to know local addresses @1 and @2 of
the two parent interfaces, and the lists of zone prefixes inherited
at these interfaces, i.e. {A...} and {B...} respectively. (Each of
the two lists has only one element in this example). No other SAM
parameter of the zone is needed.
Various ways to communicate these parameters to child interfaces can
be envisaged. Router advertisements of [RFC2462] (RAs) have the
advantage to be receivable by child interfaces before they have
finalized their local address autoconfiguration. They can
consequently recognize whether they are in a SAM-capable site early
enough to adapt their autoconfiguration procedures.
Despres Expires January 14, 2010 [Page 10]
Internet-Draft Stateless Address Mapping (SAM) July 2009
In SAM zones that have multiple links, the procedure for routers that
have to send these RAs to obtain SAM parameters is left for a further
version of this draft.
3.2. SAM Formats for Local Addresses and Global infixes
3.2.1. SAM Subnet Prefixes
SAM subnet prefixes must be suitable for the 1:1 correspondence of
Section 2.4 between SAML local addresses and SAM global infixes.
Figure 4 presents a proposed format for this.
<---------------------------- 64 bits ----------------------------->
<---- 48 or 12 ----> <-3->
+---------//-------+-------//------+--------------//-----------+---+
| Constant prefix | Subnet infix | 0 | N1|
+---------//-------+------//-------+--------------//-----------+---+
^ <--- N1 x 4 ---> ^
| |
| Subnet-infix length in half octets ---'
|
'----fdXX:XXXX:XXXX:XX00::/48 or fcf0::/12
SAM SUBNET PREFIX FORMAT
Figure 4
For IPv6 local addresses to be distinguishable from global-scope
addresses, [RFC4193] reserves the 7-bit prefix fc00::/7. It also
specifies 48-bit prefixes for ULAs (unique local IPv6 unicast
addresses), which start with fd00::/8.
For convenience, we propose that the constant-prefix part of SAM-zone
local address may not only be a 48-bit ULA, differing from a zone to
another, but may also be shorter and the same for different SAM
zones. As shown in Figure 4, we propose for this to reserve for
prefix fcf0::/12. The f it contains after to fc00::/8 is to permit
other uses of the fc00::/8 prefix in the future (forward
compatibility precaution).
Since routing is in general based on longest-prefix matching, subnet
infix bits, which identify a particular subnet in a SAM zone, are
preferably be placed immediately after the constant prefix.
Despres Expires January 14, 2010 [Page 11]
Internet-Draft Stateless Address Mapping (SAM) July 2009
For the length of subnet infixes to be recognizable in SAM subnet
prefixes themselves, we propose to place a length indicator in the
last half octet of the subnet prefix, and to express it in number of
half octets [Figure 4]. Restricting subnet-infix lengths to multiple
of 4 bits should not be inconvenient in practice since as it
facilitates interpretation of IPv6 addresses in their standard
notation (thus facilitating network maintenance). Using only 3 bits
permits commonality with the length indicator of SAM global infixes
of Section 3.2.3, in which field lengths should preferably be short.
As an example, fcf9:0:0:1 is a SAM subnet prefix that comprises, from
left to right, the short constant prefix 0xFCF, the subnet infix 0x9
(1 half-octet long in this case), an unused field of 5.5 octets, and
the length indicator 0x1 of the subnet infix (for the half octet
0x9).
3.2.2. SAM IIDs
SAM IIDs have also to be suitable for the 1:1 correspondence of
Section 2.4 between SAM local addresses and SAM global infixes.
Figure 5 presents a proposed format for this.
<---------------------------- 64 ------------------------------->
<-4-><2><2> <--------- N2 x 8 -------->
+----+--+--+--------------------------+-----------//------------+
| N2 |11|11| 0 | IID infix |
+----+--+--+--------------------------+-----------//------------+
^ ^
| |
| '---- escape value of u and g bits of RFC 4291
|
'---- escape field for other new IID formats
SAM IID FORMAT
Figure 5
For SAM IIDs to be distinguishable from already specified IIDs of
[RFC4291], whose u and g bits are 00, 01 or 10, we propose SAM IIDs
to have 11 in u and g bits and, to permit other uses of this 11
pattern in the future, 11 in the two preceding bits (forward
compatibility precaution).
Despres Expires January 14, 2010 [Page 12]
Internet-Draft Stateless Address Mapping (SAM) July 2009
Since the Duplicate Address Detection procedure of[RFC2462] uses the
24 last bits of IIDs to discriminate multicast groups that it uses,
bits of IID infix bits, which identify a particular SAM interface on
its link, are preferably placed at the end of IIDs.
For the length of subnet infixes to be recognizable in SAM IIDs, we
propose to place a length indicator in the first half octet of the
IID, and to express it in number of octets. Using only 4 bits
permits commonality with the length indicator of global infixes of
Section 3.2.3, in which all field lengths should preferably be short.
As an example, 2f00:0:0:6666 is a SAM IID that comprises, from left
to right, the length indicator 0x2 of the IID infix (indicating 2
octets), the SAM-IID tag 0xF, an unused field of 5 octets, and the
IID infix 0x6666 (2 octets long as specified in the length
indicator).
NOTE: [RFC4291], where current IID formats are specified and leave
unused the 11 value of u and g bits, has a sentence that may be
interpreted as limiting uses of this 11 value to IIDs that have
universal scope: "The use of the universal/local bit in the Modified
EUI-64 format identifier is to allow development of future technology
that can take advantage of interface identifiers with universal
scope." This interpretation would prohibit using the proposed SAM
IID format because SAM IIDs have local scopes. This note is
therefore a contribution to the 6man Working Group. It is a request
to clarify that the 11 combination of u and g bits may be used for
all new IIDs, including those that have a local scope.
3.2.3. SAM Global Infixes
SAM global-infixes must also be suitable for their 1:1 correspondence
of Section 2.4 with SAM local addresses.
To derive a child local address from a child global infix, the subnet
infix part and the IID infix part of the global infix in must be
extractible. Their lengths must therefore be recognizable when
parsing bits that follow parent-zone global prefixes.
For this, the format proposed in Figure 6 has, before subnet-infix
and IID-infix fields themselves, their length indicators. They are
chosen to be in the short format described for local addresses.
Before these fields, a 1-bit field set to 0 is included so that
different formats can be defined in the future (forward compatibility
precaution).
Despres Expires January 14, 2010 [Page 13]
Internet-Draft Stateless Address Mapping (SAM) July 2009
<1><-3-><-4-><-- N1 x 4 ---><---- N2 x 8----->
... +-+----+----+------//------+------------------+ ...
|0| N1 | N2 | subnet infix | interface infix |
... +-+----+----+-----//-------+------------------+ ...
^ ^ ^
| | |
| | '---- interface-infix length (octets)
| |
| '---- subnet-infix length (half octets)
|
'------ escape bit for possible other formats
PROPOSED FORMAT FOR SAM GLOBAL INFIXES
Figure 6
If N 1= N2 = 0, the infix contains neither subnet infix nor an IID
infix. While it therefore cannot designate any child interface at a
lower level, it naturally provides a global address for the child
interface itself, at its level. Bits that follow, which are unused,
are set to 0.
3.3. Autoconfiguration Procedure for SAM Interfaces
As we have seen in Section 2.4, the correspondence between SAM local
addresses and global prefixes must be such that the autoconfiguration
of local addresses can also be that of global prefixes.
For this, a first point to be noted is that, since SAM IIDs are
distinct from IIDs having a classic format, SAM-capable hosts can
coexist on a link with classic IIDs. As necessary for incremental
deployment, there is no risk that hosts that don't support SAM would
miss IID duplicates caused by SAM-capable neighbors.
The second point is that SAM-capable nodes can have a SAM-specific
Duplicate Address Detection procedure. The SAM duplicate address
procedure is the same as usual except that two SAM local addresses
are considered duplicate if one of the two IID infixes is a prefix of
the other.
Thus, if a SAM-capable node recognizes that it is in a SAM zone
(finding SAM parameters in received RAs), it can proceed as follows
to get an n-bit infix (from which it derives its global prefixes):
pick at random a SAM prefix having an n-bit long IID infix; test it
to see whether it has a duplicate on the link; if there is one, try
again with a different randomly selected IID; if there is none,
Despres Expires January 14, 2010 [Page 14]
Internet-Draft Stateless Address Mapping (SAM) July 2009
derive the delegated global prefix from the obtained local address
(and from SAM parameters of the zone).
4. Application Example
To detail how SAM applies to a simple practical example, we now
consider the customer site of Figure 7.
The site has gateways to the Internet from service providers ISP-A
and ISP-B, with global prefixes assigned to the site being A... and
B... respectively . The ISP-A gateway is physically connected to a
WiFi LAN and to the site Ethernet LAN, with a bridge between them.
The ISP-B gateway is physically connected to the Ethernet LAN. IIDs
of these gateways are m and n respectively.
To keep the example simple, it is assumed that there is only one
subnet in the site (but it could be easily extended to include
several administratively configured subnets).
The host we consider is physically connected via its interface 1 to
the WiFi LAN of the ISP-A, on which it has h as IID, and via its
interface 2 to the Ethernet LAN on which it has k as IID. It may
have to act as a router, with one or several subnets behind it, so
that it may need to know its global prefixes.
ISP gateways and the host are assumed to be SAM capable.
The host can derive its 4 permitted global prefixes from the local
addresses it has at its two interfaces, and from SAM parameters of
the zone. They are indicated in Figure 7 with a notation where, for
example, prefix AH..., stands for prefix A... followed by the SAM
infix derived from the local address whose IID is h.
Depending on which of these prefixes appears in the source address of
a global-address packet, the local destination to reach the global
Internet has to be gateway A or gateway B. Host parameters that
govern this choice are shown on the Figure.
Despres Expires January 14, 2010 [Page 15]
Internet-Draft Stateless Address Mapping (SAM) July 2009
. - - - (WiFi) - - > \|/ ISP-A gateway
/ | .-----.
' | | |
| '----| |
| | | A...
V IID m |------
| |
HOST |---| |
.------. \|/ | '-----'
| | | |
| | | |
| 1|---' |
| IID h |
| | |
| o | |
| | | |
| | 2|---------- (Ethernet) -----|
| | IID k |
| | | | ISP-B gateway
| | | | .-----.
'--|--- | | | B...
| |---| |------
Global prefixes | IID n |
AH... via m | | |
AK... via m '-----'
BH... via n
BK... via n
||
\/
- Failure of ISP-A or of its gateway ==> use BK...
- Failure of ISP-B or of its gateway ==> use AH... or AK...
- Failure of host Ethernet port ==> use AH... or BH...
- Loss of the WiFi connectivity ==> use AK... or BK...
MULTIHOMED-SITE EXAMPLE WITH HOST RESISTANCE TO SINGLE-POINT FAILURES
Figure 7
In Figure 8, the same site configuration is presented, but this time
with detailed IPv6 addresses and prefixes in their standard format of
[RFC4291].
Despres Expires January 14, 2010 [Page 16]
Internet-Draft Stateless Address Mapping (SAM) July 2009
subnet infix 0x9 PARENT
. - - - - - - - - -> \|/ NODE
/ | .-----.
' | | |
| '----| |
| IID infix 0x5555 |
V | |------
CHILD | | | 2001:db8:a:a::/48
NODE |---| |
.------. \|/ | '-----'
| | | |
| | | |
| 1|---' IID infix 0x7777 |
| | |
| | |
| o | |
| | | |
| | 2|---------------------------|
| | | IID infix 0x8888 | PARENT
| | | | NODE
| | | | .-----.
'--|---' ^ | | |
| ^ | |---| |
| | | IID infix 0x6666 |------
| | | | | | 2001:db8:b:b:b00::/56
| | | '-----'
| | |
| | Local addresses
| | fcf9:0:0:1:2f00::7777 on 1
| | fcf9:0:0:1:2f00::8888 on 2
| |
| Global addresses
| 2001:db8:a:a:1297:7770:: on 1
| 2001:db8:b:b:b12:9777:7000:: on 1
| 2001:db8:a:a:1298:8880:: on 2
| 2001:db8:b:b:b:129888:8000:: on 2
|
Global prefixes
2001:db8:a:a:1297:7770::/76 via 1 and fcf9:0:0:1:2f00::5555
2001:db8:b:b:b12:9777:7000::/88 via 1 and fcf9:0:0:1:2f00::6666
2001:db8:a:a:1298:8880::/76 via 2 and fcf9:0:0:1:2f00::5555
2001:db8:b:b:b:129777:7000::/88 via 1 and fcf9:0:0:1:2f00::6666
EXAMPLE OF PREFIXES AND ADDRESSES FOR THE NETWORK EXAMPLE
Figure 8
Despres Expires January 14, 2010 [Page 17]
Internet-Draft Stateless Address Mapping (SAM) July 2009
In this example, the constant prefix of local addresses is chosen to
be to 0xFCF. The subnet infix of the unique subnet is set to 0x9
(having only one subnet, the subnet infix could have been given a
null length, but this would have imposed a reconfiguration if other
subnets are added later on). Prefixes assigned by ISPs A and B are
supposed to be 2001:db8:a:a::/48 and 2001:db8:b:b:b000::/56
respectively. IID infixes of m, n, h, and k interfaces, possibly
obtained by autoconfiguration, are supposed to be 0x5555, 0x6666,
0x7777, and 0x8888 respectively.
SAM parameters of the zone that result are presented in Table 1.
Global prefixes of the host, and via which interfaces and which
gateways they can be used, are detailed in the Figure. Global
addresses of the host itself , obtained with trailing 0s appended to
global prefixes are also shown.
+-----------------------+-----------------------+
| Parent local address | Zone global prefix |
+-----------------------+-----------------------+
| fcf9:0:0:1:2f00::5555 | 2001:db8:a:a::/48 |
| fcf9:0:0:1:2f00::6666 | 2001:db8:b:b:b00::/56 |
+-----------------------+-----------------------+
SAM PARAMETERS TO BE ADVERTISED TO CHILD INTERFACES
Table 1
5. Security considerations
No security issue that appears to be specific of SAM has been
identified so far.
In particular, provided consistency between local addresses and
global prefixes are systematically checked at parent and child
interfaces, no new address spoofing possibility seems to be
introduced.
Also, SAM being stateless, its scalability is high. Resistance to
denial of service attacks should therefore be possible even for very
intense traffic, using if needed load balancers in front of parallel
hardware devices.
6. IANA Considerations
As indicated in Section 3.1, mechanisms to advertise SAM parameters
of a SAM zone to its child interfaces will need some number
Despres Expires January 14, 2010 [Page 18]
Internet-Draft Stateless Address Mapping (SAM) July 2009
assignments by IANA.This is however beyond the scope of this version
of the draft.
7. Acknowledgements
Although the substance of this draft, with its now restricted scope,
is essentially the result of a personal work, the author expresses
his gratitude to Mark Townsley. He took time to listen to
intermediate stage presentations, and provided useful reactions.
Thanks are also due to Dave Thaler who made a precious detailed
review of the previous version. Beyond this, the open discussion
environment of IETF in general has been a continuous encouragement.
8. References
8.1. Normative References
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
8.2. Informative References
[RFC 5569]
Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd) - Work in progress
(draft-despres-6rd-02) *to soon be replaced by RFC 5569*",
October 2008.
[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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[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.
Despres Expires January 14, 2010 [Page 19]
Internet-Draft Stateless Address Mapping (SAM) July 2009
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 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.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[draft-carpenter-renum-needs-work-01]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work - Work in progress", December 2008.
[shim6 fail detec]
Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming -
Work in progress (draft-ietf-shim6-failure-detection-09)",
July 2007.
[shim6 protocol]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6 - Work in progress
(draft-ietf-shim6-failure-detection-09)", October 2007.
Despres Expires January 14, 2010 [Page 20]
Internet-Draft Stateless Address Mapping (SAM) July 2009
Author's Address
Remi Despres
RD-IPtech
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Despres Expires January 14, 2010 [Page 21]