[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-despres-sam-scenarios) 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/