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

Versions: 00 01

Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Experimental                              March 1, 2010
Expires: September 2, 2010


      Stateless Address Mapping (SAM) for Softwire-Lite Solutions
                     draft-despres-softwire-sam-00

Abstract

   Stateless Address Mapping (SAM) is a generic mechanism which permits,
   in a number of new scenarios, to easily establish tunnels for packets
   of some address family to traverse domains where this family is not
   directly routed (softwires).  It generalizes address mapping
   principles of already deployed technologies such as 6to4, ISATAP, and
   6rd, where encapsulations of IP over IP are used for point-to-
   multipoint tunnels (mesh softwires).

   Identified use cases of SAM include native IPv6 across IPv4 NATs,
   IPv6 multihoming with provider-aggregatable prefixes, public IPv4
   across IPv6-only domains and, to mitigate consequences of the IPv4
   address shortage, extended IPv4 prefixes for statically shared IPv4
   public addresses.

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 September 2, 2010.




Despres                 Expires September 2, 2010               [Page 1]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The SAM model  . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Stateless Address Mappers (SAMs) . . . . . . . . . . . . .  3
     2.2.  Mapping Rules  . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Mapping Functions  . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Encapsulations and Decapsulations  . . . . . . . . . . . .  9
     2.5.  Fragmentation Considerations . . . . . . . . . . . . . . .  9
     2.6.  Extended IPv4 Prefixes and their Port Sets . . . . . . . . 10
     2.7.  Acquisition of Mapping Rules by Customer Nodes . . . . . . 12
   3.  Use-Case examples  . . . . . . . . . . . . . . . . . . . . . . 15
     3.1.  IPv6 across IPv4-only Domains  . . . . . . . . . . . . . . 15
       3.1.1.  Native IPv6 across NAT44 CPEs (6rdE) . . . . . . . . . 15
       3.1.2.  Optimized Mapping for Multiple IPv4 Prefixes . . . . . 18
     3.2.  IPv4 across IPv6-only Domains  . . . . . . . . . . . . . . 20
       3.2.1.  Single IPv4 Prefix . . . . . . . . . . . . . . . . . . 20
       3.2.2.  Multiple IPv4 Prefixes . . . . . . . . . . . . . . . . 21
     3.3.  Public IPv6 across Private-IPv6 Domains  . . . . . . . . . 22
       3.3.1.  Multihoming with Provider-Aggregetable Prefixes  . . . 22
       3.3.2.  Renumbering with Unchanged Internal Routing  . . . . . 24
       3.3.3.  Merging Two Private-Addressing Sites using ULAs  . . . 25
     3.4.  A Planned Experiment at Telecom Bretagne . . . . . . . . . 27
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 30
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33





Despres                 Expires September 2, 2010               [Page 2]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


1.  Introduction

   Stateless Address Mapping (SAM) is a generalization of address-
   mapping and encapsulation mechanisms used in deployed technologies
   such as 6to4 [RFC3056], 6rd [RFC5569] [Standard-track 6rd], and
   ISATAP [RFC5214].  Like these, it establishes point-to-multipoint
   tunnels (mesh softwires of [RFC4925]).  Like these also, but unlike
   mesh softwire mechanisms of [RFC5565], it establishes them without
   needing a common routing protocol between border nodes of traversed
   domains. to keep justifies to call it a "softwire lite" solution.
   Another characteristic of SAM that keeps it simple is that traversed
   domains are treated as virtual links like those of 6to4, i.e. as
   links on which neither link-local addresses nor any link-layer
   protocol are needed.

   A detailed specification of SAM is proposed in Section 2, after what
   a number of typical use cases are described in Section 3.  Security
   considerations are covered Section 4.

   Section 3.1 on IPv6 across IPv4-only domains, Section 3.2 on public
   IPv4 across IPv6-only domains, and Section 3.3 on public IPv6 across
   private-IPv6 domains, can be read in any order, and it is unnecessary
   to have read Section 2.7 on how mapping rules can be acquired by
   customer nodes to understand them.

   Readers not interested in IPv4 address-plus-port locators, a subject
   considered so far as controversial, can just skip Section 2.6 and
   ignore, in the experimental scenario of Section 3.4, what concerns
   them.


2.  The SAM model

2.1.  Stateless Address Mappers (SAMs)

   Figure 1 summarizes the essentials of SAM, with an illustration of
   the terminology used in the upper part, with below mapping-rule
   parameters listed in Section 2.2, and at the end a synthetic
   representation of mapping functions detailed in Section 2.3

   A "SAM domain", is a routing domain in which border nodes (hosts or
   routers) contain "stateless address mappers" (SAMs).  Some of them
   are "customer SAMs" (C-SAMs) and some of them, optional, are
   "provider SAMs" (P-SAMs).  Each SAM, being stateless, can be
   physically replicated if necessary to support heavy traffic loads.
   In this case, they share the same prefixes and locators.  Addresses
   to reach them are configured in routers as anycast addresses.




Despres                 Expires September 2, 2010               [Page 3]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


        customer   customer   provider    domain         domain
        exterior   interior   interior    interior       exterior
        prefix E   prefix I   locator G   prefix K       prefix D
             |______   |___      |            |      __________|
                    |      |     |            |     |
                    |      |     |            | +---|------------------
       exterior     |  +---|-----|------------|-+   |     exterior
   endpoint locator |  |   |     |            | |   |  endpoint locator
    (customer-side) |  |   |     |       K <====:   |  (provider side)
      |             |  |   |     |__________    |   |          |
    --|-------------|--+   |                | P-SAM |          |
      |             |  |   |             G ---->S<==== D     ---->
      |             |  |   |              provider SAM    eLOC (not D...)
      |             |C-SAM |                    |
    <----       I <====S<==== I=P.X             |
   eLOC=E...    E <====S                        |
                E=R.X  |                        |
                 customer SAM                   |
                       |                        |
    CUSTOMER DOMAIN    |       SAM DOMAIN       |
    -------------------+    (iSRC ----> iDST)   |    PROVIDER DOMAIN
                       +------------------------+
              (in a border node)                +----------------------
                                        (in a border node)

   MAPPING RULE(S): {R; P; x[; G][; T]}, where:
        R = rule exterior prefix = D[.C]
        P = rule interior prefix = K[.H]
        C = domain-exterior-prefix code (optional)
        H = domain-exterior-prefix code (optional)
        X = customer index (length x)
        T = lifetime (optional)

     MAPPING FUNCTIONS:
   E( I=P... , {R; P; x}) = R.(I-P)/r+x
   iDST(eDST=R... , any eSRC,{R; P; x}) = P.(eDST - R).0*/p...
   iDST(eDST not R... , eSRC = R... ,{R; ... ; G}) = G


                               THE SAM MODEL

                                 Figure 1

   Each SAM has an "interior interface" and an "exterior interface".  At
   the interior interface, it is addressed in the SAM interior locator
   family of the domain.  At the exterior interface, it can be addressed
   in several locator families.  These locator families can be IPv4,
   IPv6 or, for some scenarios of the IPv4-IPv6 coexistence period



Despres                 Expires September 2, 2010               [Page 4]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   during which there is an IPv4 address shortage, extended IPv4
   (IPv4E).  An IPv4E locator is port-extended, i.e. composed of a
   public IPv4 address plus a transport layer port number.

   a SAM domain may contain any number of interior nodes, which forward
   packets whose locators are in the interior locator family.

   Each provider SAM is assigned, at its interior interface, a "provider
   interior locator" (G).  At its exterior interface, the P-SAM is
   assigned one or several "domain exterior prefixes" (D).

   Each customer SAM is assigned, at its interior interface, an interior
   prefix called its "customer interior prefix" (I).  At its interior
   interface, it assigns to the customer domain behind this interface
   one or several "customer exterior prefixes" (E).

   Customer interior and exterior prefixes I and E have a common part,
   in their lower bits, called the "customer index" (X).  What precedes
   X in a customer exterior prefix E is called "rule exterior prefix"
   (R), and what may precede X in a customer interior prefix I is called
   "rule interior prefix" (P).

   In SAM, prefixes are not only address prefixes (IPv4 or IPv6, public
   or private), but more generally locator prefixes, including port-
   extended prefixes.  Their lengths are not restricted to be shorter
   than that of locators of their families so that a prefix parameter
   can contain a full address or address plus port.

   We use throughout the following notation:

   o  The dot is the a concatenation operator for prefixes, and the
      minus sign is the extraction operator, so that we can write E =
      R.X, I = P.X, also noted X = E - R = I - P.

   o  A locator that matches a prefix Z is noted Z... .

   o  The length of a prefix whose symbol is an upper-case letter is
      noted with the same letter in lower case (d is the length of D, x
      that of X).

   o  The length of a locator Z... is noted z... (e... = 128 if the
      locator family of E is IPv6, and e... = 48 if this family is
      IPv4E.)








Despres                 Expires September 2, 2010               [Page 5]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   A customer exterior prefix E assigned by a customer SAM to its
   customer domain must belong to the locator space of the SAM domain.
   It must therefore be an extension of one of the domain exterior
   prefixes D. For this, each rule exterior prefix R must start with one
   of the domain exterior prefixes D.

   In a SAM domain a common part at the beginning of a number interior
   locator can be identified.  It is then called "domain interior
   prefix" (K) of the domain.  If interior locators are not constrained
   to start with any specified prefix, there is only one K whose length
   is 0.  If there are several Ks, it must be possible to unambiguously
   determine which one is at the beginning of any interior locator.
   These Ks must therefore be non-overlapping prefixes.  Customer
   interior prefixes I assigned in a SAM domain to customer SAMs having
   to be extensions of these Ks, each rule interior prefix P must start
   with one of them.

   If a rule exterior prefix R is longer than its contained domain
   exterior prefix D, the remainder is a "domain-interior-prefix code"
   (C), i.e.  R = D.C, or C = R - D. When present, this code C
   identifies one of the domain interior prefixes K.

   If a rule interior prefix P is longer than its contained domain
   interior prefix K, the remainder is a "domain-exterior-prefix code"
   (H), i.e.  P = K.H, or H = P - K. When present, this code H
   identifies one of the domain exterior prefixes D.

2.2.  Mapping Rules

   To forward an exterior packet across a SAM domain a SAM derives an
   interior destination locator iDST from the destination and source
   locators eDST and eSRC of the exterior packet.  For this, it applies
   a "locator mapping function" which depends on the set of "mapping
   rules" of the SAM domain: iDST = iDST(eDST, eSRC, mapping rules).

   To assign customer exterior prefixes E to its customer domain,
   customer SAMs apply to their prefixes I a "prefix mapping function"
   which depends on the set of mapping rules of the SAM domain: E = E(I,
   mapping rules).












Despres                 Expires September 2, 2010               [Page 6]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   Parameters of mapping rules are the following:

   R: The "rule exterior prefix".  Its family (IPv4, IPv6 or IPv4E)
      determines that of exterior prefixes E that start with it, and
      that of exterior endpoint locators eDST and eSRC.

   P: The "rule interior prefix".  Its family (IPv4, IPv6 or IPv4E)
      determines that of interior prefixes I that start with it, and
      that of interior locators iDST and iSRC.  The length p of this
      prefix may be 0.

   x: The "customer-index length".  It is the length of the field X that
      is common to customer interior and exterior prefixes I and E. It
      determines the lengths of customer interior and exterior prefixes
      (i = p + x, and e = r + x).

   G: The "provider interior prefix" (optional).  It specifies a P-SAM
      that has been assigned the domain exterior prefix D that appears
      at the beginning of the customer exterior prefix R of the rule.
      If G is present but has length g = 0, it means that the interior
      interface of this P-SAM is the default exit from the SAM domain (a
      SAM use cases where this is used is not present in this draft but
      may be included in a later version).  If G is absent, the rule
      applies only to packets whose source and destination exterior
      locators eSRC and eDST both start with the rule-exterior-prefix R
      of the rule (eDST = R... and eSRC = R...).

   T: The "rule lifetime" (optional).  Its absence means an unbounded
      lifetime.  If a SAM sees that the lifetime of a rule has expired
      since the rule was received, no mapping using it is permitted any
      longer.  The rule should then be discarded.  If present, the
      lifetime is expressed in seconds.

   A mapping rule is represented between curly brackets, with its
   parameters in the order R, P, x, G, T, as shown in Section 2 with
   square brackets to indicate what is optional.

2.3.   Mapping Functions

   Ignoring for the time being security checks, which are discussed in
   Section 4, prefix mapping functions are detailed in Figure 2, with
   the following pseudo-code notation:

   o  As above, the dot is the concatenation operator and the minus sign
      is the extraction operator: "(A.B)-D" means that A and B are
      concatenated and that D, which must be present at the beginning of
      the result, is extracted from it to give the final result.




Despres                 Expires September 2, 2010               [Page 7]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   o  The slash notation indicates how many bits are retained in
      concatenation results.  "A.B/(c+d" means that A and B are
      concatenated and that only the first c + d bits are retained.)

   o  0* represents a filler composed of a number of 0 bits which are
      appended to reach the specified total length.  Its length may be
      0.



        CUSTOMER-SAM PREFIX MAPPING
        E(I, mapping rules):
           FOR each rule {R; P; x[; G][; T]} such that I=P..., DO:
               Take, as valid E,  E = R.(I-P)/r+x, with lifetime T

        CUSTOMER-SAM DESTINATION-LOCATOR MAPPING
        iDST(eDST, eSRC, mapping rules):
           Take rules {R; P; x[; G][; T]} such that eDST=R...
           Select among them those that have the maximum R length
           Select among them one that has the maximum T (or no T)
           IF there is such a rule and eSRC=R..., DO:
                  iDST = P.(eDST-R).0*/p...
           ELSE DO:
             Take rules {R; P; x[; G][; T]} such that eSRC=R... :
             Select among them those that have a G
             Select among them one that has the maximum T (or no T)
             IF there is such a rule, DO:
                  iDST = G
             ELSE: Return a "Destination unreachable" error message

        PROVIDER- SAM DESTINATION LOCATOR MAPPING:
        - iDST(eDST, eSRC, mapping rules):
           Take rules {R; P; x[; G][; T]} such that eDST=R...
           Select among them those that have the maximum R length
           Select among them one that has the maximum T (or no T)
           IF there is such a rule and eSRC=R...,, DO:
                 iDST = P.(eDST-R).0*/p...
           ELSE: Return a "Destination unreachable" error message


                           SAM MAPPING FUNCTIONS

                                 Figure 2








Despres                 Expires September 2, 2010               [Page 8]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


2.4.  Encapsulations and Decapsulations

   To traverse SAM domains with end-to-end network transparency,
   exterior packets are encapsulated in interior packets.  Destination
   locators iDST of these interior packets are those obtained by the
   mapping functions of Section 2.3.  The source locators iSRC is in a
   customer SAM its interior prefix I, completed if necessary by a
   filler of 0s.  In a provider SAM, it is its provider interior locator
   G

   If the interior locator family is IPv4 or IPv6, encapsulation is in
   IP over IP, with the protocol/next-header field of the encapsulating
   packet set to 41 (an extension of what this value means for 6to4,
   ISATAP and 6rd).

   If the interior locator family is IPv4E, encapsulation is in IP over
   UDP over IP.  UDP ports are the last 16 bits of 48-bit interior
   locators of the IPv4E family.

   At tunnel exit, interior packets from which exterior packets have to
   be extracted are recognized by their protocol/next-header field = 41,
   if the interior locator family is IPv4 or IPv6, and by their UDP
   destination port being that assigned to encapsulation if this family
   is IPv4E.

   ICMP/ICMPv6 error messages of the interior locator family that are
   received at tunnel exits are analyzed to determine the original
   source and destination locators eSRC and eDST of encapsulated packets
   whose discarding is signaled.  ICMP/ICMPv6 error messages are then
   constructed with the same or appropriately translated error type,
   with this eSRC as destination, with the exterior-interface address of
   the SAM as source SAM, and with the part of the original exterior
   packet found in the received error message after the constructed
   ICMP/ICMPv6 header.

2.5.  Fragmentation Considerations

   If the exterior locator family of a SAM domain is IPv6, datagram
   fragmentation has to remain an end-to-end issue.  Exterior packets
   that don't exceed the size that is guaranteed to traverse the SAM
   domain without fragmentation are forwarded.  (To comply with
   [RFC2460], this size must be at least 1280 octets).  Exterior packets
   having more than this size may either be discarded (with the
   appropriate ICMPv6 error message returned to the source), or
   forwarded.  In the latter case, the ICMP "Packet too big" error
   messages may be received, and must be translated as indicated in
   Section 2.4.




Despres                 Expires September 2, 2010               [Page 9]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   If the exterior locator family of a SAM domain is IPv4, a packet size
   that traverses the SAM domain without risking to be found too big has
   to be known.  Exterior packets that have more than this size and
   don't have their "Don't fragment" bit set are then fragmented in IPv4
   and each resulting packet is independently encapsulated in an
   interior family datagram.  Exterior packets having more than this
   size and having the "Don't fragment" bit set to 1 may either be
   discarded (with the appropriate ICMPv6 error message returned to the
   source), or forwarded.  In the latter case, the ICMP "Packet too big"
   error messages may be received, and must be translated as indicated
   in Section 2.4.

   If the exterior locator family of a SAM domain is IPv4E, other
   fragments of a fragmented datagram than the first one don't contain
   the necessary UDP port numbers, and therefore cannot be individually
   forwarded.  Tunnel-entrance SAMs must first reassemble each datagram,
   using for this a classical datagram reassembly function, and then
   treat the result like an IPv4 packet of the previous paragraph.  In
   tunnel-exit SAMs interior and exterior datagrams are reassembled
   before forwarding.

2.6.  Extended IPv4 Prefixes and their Port Sets

   Port forwarding is used for IPv4-only hosts that are behind an IPv4
   NAT (NAT44) to be reachable from the Internet.  Mappings between
   transport-layer ports and host private addresses can be configured by
   administrative commands, or automatically by a protocol such as the
   NAT Port Mapping Protocol of [NAT-PMP]).  Now that more and more
   sites will have no public IPv4 address of their own, new mechanisms
   are needed for this intra-site port forwarding to remain possible.

   The SAM answer to this need consists in ISPs statelessly assigning
   disjoint port sets to customer sites that share a common public IPv4
   address.  This permits customer NAT44s to configure at any time their
   internal port forwarding with ports of their assigned port set.  No
   new protocol between customer-site NATs and ISP provided NATs within
   their infrastructures is needed for this.

   Note that this partial palliative of the IPv4 address shortage does
   not avoid limitations that are inherent to public-address sharing
   between customers: less ports available for port consuming
   applications, impossibility for customers to obtain any specific port
   number, etc.  Enabling IPv6 in addition to IPv4 remains therefore the
   only complete solution to restore good host reachability across the
   Internet, on any chosen ports.






Despres                 Expires September 2, 2010              [Page 10]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   For port sets assigned to customer domains that share public IPv4
   addresses not to include ports that have more value than others,
   ports numbers below 4096 have to be excluded.  (This exclusion is
   chosen by reference to Windows which has been reported to dynamically
   bind ports to applications starting at 4096, because lower numbered
   ports are subject to specific behaviors, in particular well known
   ports below 1096.  If a port range other than above 4095-65535 should
   be preferred, the logic described below could easily be adapted to
   it.)

   Figure 3 shows how SAM derives a port set from an extended IPv4
   prefix, i.e. a prefix of the IPv4E family having a length from 33 to
   48.

   Bits of the prefix after the first 32 are called the port-set index
   S. If its length s is less than 13, S identifies 4 port ranges.  The
   largest of these ranges has 2 ^ (15 - s) elements; the second 2^(14 -
   s); etc.  For port-set indexes of lengths s > 12, the number of port
   ranges of the port set is limited to 15 - s, with the smallest range
   having only one element.  An extended prefix E of less than 45 bits
   has thus 15 / 16 * 2^(48 - e) elements.

   Note that, if desired for simplicity, implementations may use only
   the first contiguous range, leaving unused less than half of the
   ports in the assigned set.


       <-------- extended-IPv4 prefix E ------>

       <--- IPv4 address (32 bits) ---><------>
                                           |
                "port set index" S ________|    port-prefix   number
                                           |      lengths    of ports
                                           |         V          V
                                  /    1<------>   s + 1     2^(15-s)
                  port prefixes  /    01<------>   s + 2     2^(14-s)
                 of the port set \   001<------>   s + 3     2^(13-s)
                    if s < 13     \ 0001<------>   s + 4     2^(12-s)
                                                             --------
                                                          15/16*2^(16-s)


        CORRESPONDENCE EXTENDED-IPv4 PREFIXES AND LOCATOR PORT SETS

                                 Figure 3






Despres                 Expires September 2, 2010              [Page 11]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


2.7.  Acquisition of Mapping Rules by Customer Nodes

   For early experimentations or advanced uses, a customer SAM may
   acquire the SAM rules of its SAM domain by administrative
   configuration.  But for extensive deployments, they must be acquired
   automatically.  The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can be
   used for this.  Alternatively, in particular for scenarios where
   NAT44s have to be traversed, using the DNS as proposed in section 6
   of [DNS-SD] can be a better approach.

   Figure 4 shows how classical functions of DHCP clients and servers
   can be combined with some SAM-specific functions to build a solution:

   o  A "local SAM-rule configurator" is present in each provider-SAM
      border node.  It derives one or several SAM mapping rules from its
      local parameters.  These parameters may have been administratively
      configured and/or obtained by automated prefix delegation from the
      provider domain.  The obtained mapping rules are then submitted,
      in a DHCP-option format shown in Figure 5, to a collocated
      classical DHCP server.

   o  A "SAM multiple DHCP client" is present in each "SAM-capable DHCP
      server", i.e. in each stateless DHCP server that border nodes of
      customer SAMs query to obtain their parameters.  A SAM multiple
      DHCP client is administratively configured with locators of all
      provider SAMs of the domain.  It queries them to obtain their
      mapping rules.  It then submits all of them to the collocated SAM-
      rule merger.

   o  A "SAM-rule merger" is present in each SAM-capable DHCP server.
      It gathers all rules submitted to it by the collocated SAM
      multiple DHCP client, and merges them into a single SAM DHCP
      option.  In a sophisticated version, it may retain only some of
      these rules, according to some criteria that are beyond the scope
      of this version of the draft.  The resulting DHCP option, suitable
      for a stateless DHCP operation, is then submitted to the
      collocated classical stateless DHCP server.

   o  If a SAM-capable DHCP server is collocated with a provider SAM,
      the local SAM-rule configurator can directly submit its rules to
      the local SAM-rule merger, without needing a DHCP client-server
      relationship.









Despres                 Expires September 2, 2010              [Page 12]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


             customer SAM
          +-----------------+
          | +-------------+ |====>|SAM-rules and other requests
          | | DHCP client | |     |(to a SAM-capable DHCP server)
          | +-------------+ |
          +-----------------+
                                                 SAM-capable DHCP server
                                                  +-------------------+
                                                  | +---------------+ |
                SAM-rules and other Requests|====>| |  DHCP server  | |
                        (from customer-SAMs)|     | |  (stateless)  | |
                                                  | +---------------+ |
                                                  | |    SAM-rule   | |
                                                  | |     merger    | |
                                                  | +---------------+ |
                           SAM-rule Requests|<====| |  SAM multiple | |
           (to all P-SAMs, the list of which|     | |   DHCP client | |
             is administratively configured)|     | +---------------+ |
                                                  +-------------------+

                                                     Provider SAM
                                                  +-------------------+
                                                  | +---------------+ |
                          SAM-rules Requests|====>| |  DHCP server  | |
             (from SAM-capable DHCP servers)|     | |  (stateless)  | |
                                                  | +---------------+ |
                                                  | |local SAM rules| |
                                                  | | configurator  | |
                                                  | +---------------+ |
                                                  +-------------------+


          FUNCTIONAL ENTITIES TO AUTOMATE SAM-RULES ADVERTISEMENT

                                 Figure 4

   The proposed format for the SAM DHCP option is the same for both IPv4
   DHCP and DHCPv6.  It is detailed in Figure 5.  Codes of rule
   parameters are chosen to be easy to recognize by maintenance
   personnel.  (In particular, the first hexadecimal digit is 4, 5,or 6,
   distinguishes whether the exterior locator family of the rule is
   IPv4, IPv4E, or IPv6).  To ensure compactness of prefix
   representations, the number of significant bits of their last octets
   is included in parameter codes themselves.







Despres                 Expires September 2, 2010              [Page 13]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   1 octet each in DHCP
   2 octets in DHCPv6
        /\
       /  \
    <---><---><---------------- n octets ---------------->
   +----+----+---...---+--- ... ---+---...---+--- ... ---+
   |  . |  n |  rule 1 |           |  rule i |           |
   +--|-+----+---...---+--- ... ---+---...---+--- ... ---+
      |          _________________/          \________________
   option code  /                                             \
                +-----...-----+-- ... --+-----...-----+-- ... --+
                | parameter 1 |         | Parameter j |         |
                +-----...-----+-- ... --+-----...-----+-- ... --+
        order of parameters        _____/              \_____
          R, P, x[, E][,T]        /                          \
                                 +----+----+----+--...--+----+
                                 |  . | k  | parameter value |
                                 +--|-+----+----+--...--+----+
                          parameter code    <--- k octets  -->

   PARAMETER-CODE VALUES (in Hexadecimal)
     1F :  x
     2F :  G
     3F :  T
     4n :  IPv4-family prefix (R or P)  \
     5n :  IPv4E-family prefix (R or P)  > where n = prefix length mod 8
     6n :  IPv6-family prefix (R or P)  /


              PROPOSED DHCP AND DHCPv6 OPTION FORMATS FOR SAM

                                 Figure 5

   For rules to be acquired by means of the DNS, in SRV records, a
   textual representation has to be used.  That which is used in figures
   of use cases could serve this purpose.  A more compact representation
   may be preferable, but is beyond the scope of this version of the
   draft.













Despres                 Expires September 2, 2010              [Page 14]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


3.  Use-Case examples

3.1.  IPv6 across IPv4-only Domains

3.1.1.  Native IPv6 across NAT44 CPEs (6rdE)

   We consider an ISP whose infrastructure is IPv4, and whose customers
   use their own choice of CPEs.  Some of these CPEs are likely to
   remain IPv4 for quite some time, with NAT44s and port-forwarding
   included but no IPv6 support.  By provisioning a P-SAMs (possibly
   physically duplicated for increased availability and/or performance),
   this ISP can offer native IPv6 to all SAM-capable hosts behind these
   NATs.  We call this application "extended 6rd" or "6rdE".

   An IPv6 prefix can be assigned to each host behind such a NAT44 by
   concatenating an IPv6 prefix belonging to the ISP, the IPv4 address
   of the host customer site and the port that is forwarded to it.
   because typical ISPs would not be able to chose for this /16s, these
   prefixes will typically be longer than the /64 limit of [RFC4291].
   But we note that the /64 limit is technically not necessary for
   prefixes only used on virtual links (they don't use the stateless
   address autoconfiguration protocol [RFC2462] which does rely on
   interface IDs and subnet prefixes to having each 64 bits).  We
   therefore choose to accept, for this application, host IPv6 prefixes
   longer than /64.  (How to officialize a relaxation of the /64
   constraint of [RFC4291] for this type of IPv6 addresses is beyond the
   scope of this draft.)

   Figure 6 details the configuration of a 6rdE use case, with the two
   applicable mapping rules .  The first rule concerns IPv6 packets
   exchanged between two customer sites and between a customer site and
   the Internet.  The second concerns IPv6 packets exchanged between two
   hosts within a customer site.

   The IPv6 prefix assigned by the ISP to 6rdE is supposed to be D =
   2001:db8:9::/48.  As nothing is needed in customer exterior locators
   E between this D and customer-site IPv4 addresses, the first rule
   will have its rule exterior prefix R1 = D. The provider interior
   locator G is made of the IPv4 address the P-SAM, supposed to be
   192.88.99.3 (an anycast address similar to that of 6to4), and the UDP
   port assigned to 6rdE in the P-SAM, supposed to be port 9999.  This
   ISP is supposed to have a number of independent IPv4 prefixes so that
   no common IPv4 prefix is supposed to exist, and the length of the
   domain interior prefix P1 of the first rule is 0.







Despres                 Expires September 2, 2010              [Page 15]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


          +---------------------------+------------------------+--------
          |       CUSTOMER SITE       |       ISP NETWORK      | IPv4
          |                           |                        |BACKBONE
          |                           |  multiple prefixes <=========
          |                           |                        |
          |                           |                     P-SAM
          |                           | G=192.88.99.3:9999 ---->S<==== D
          |                           |              D=2001:db8:9:/48(v6)
          |                           |                        |  IPv6
          |                           |                        |BACKBONE
          |                         NAT44                      |
          |    K2=192.168.0.0/16 <====N                        |
          |            0.0.0.0/0 ====>N<---- Y=198.16.2.2      |
          |              192.168.0.2  N  port 4098             |
    HOSTS |              192.168.0.3  N  port 4099             |
      |   |         and, at least for each SAM-capable host,   |
      V   |              192.168.a.b  N  port 4096+256*a+b     |
   -------+                           |                        |
        C-SAM                         |                        |
   I <====S<==== I=192.168.0.2        |                        |
   E <====S                           |                        |
    E=2001:db8:9:c610:202:1002/96(v6) |                        |
   -------+                           |                        |
        C-SAM                         |                        |
   I <====S<==== I=192.168.0.3        |                        |
   E <====S                           |                        |
    E=2001:db8:9:c610:202:1003/96(v6) |                        |
   -------+                           |                        |
          +---------------------------+------------------------+--------

               MAPPING RULES {R1, P1, x1, G} and {R2,P2, x2}
        with R1=D, p=0/0(v4), x1=32+16=48, R2=D.Y, P2=K2,  x2=32-p2 :
      {R1=2001:db8:9::/48(v6); P1=0/0(v4); x1=48; G=192.88.99.3:9999}
      {R2=2001:db8:9:c610:2:2::/80; P2=192.168.0.0/16(v4); x2=16}


                       IPv6 ACROSS NAT44s WITH 6rdE

                                 Figure 6

   The customer-index length x1 is that of an IPv4 address plus a port,
   i.e. x1 = 48.  With the first mapping rule thus defined {R1=2001:db8:
   9::/48(v6); P1=0/0(v4); x1=48; G=192.88.99.3:9999}, IPv6 packets
   between two hosts of different customer sites and between a host and
   the Internet are encapsulated in UDP over IPv4.  They are routed in
   private IPv4 across customer sites and in public IPv4 across the ISP
   network.




Despres                 Expires September 2, 2010              [Page 16]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
   |  IPv4 |                                                       |
   +-+-+-+-+                                                       +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+                               +
   |               |     UDP       |                               | IPv4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        iSRC = 192.88.99.3                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         iDST = NAT external address  Y = 198.16.2.2           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
   |            4098               |              9999             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
   |  IPv6 |                                                       |
   +-+-+-+-+                                                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |           eSRC = any IPv6 address not 2001:db8:9::/48         |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |  IPv6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +     eDST = any IPv6 address 2001:db8:9:c610:202:1002::/96     +
   |                                                               |
   +                                                               +
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
   |                                                               |
   +                        IPv6 payload                           + higher
   |                                                               |  layer


              EXAMPLE OF PACKET TRAVERSING THE CUSTOMER SITE

                                 Figure 7






Despres                 Expires September 2, 2010              [Page 17]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   Note that hosts must use as source addresses of encapsulating packets
   they send their interface addresses, which are in their site private
   address spaces (not their site public addresses which are embedded in
   in their exterior IPv6 prefixes).  Similarly, the host receives and
   must accept its IPv4 private address as valid destination in received
   encapsulating headers.  Figure 6 shows the format, with its
   encapsulation headers, of an IPv6 packet that go from the NAT44 to a
   host, coming from the Internet.

   Now, we need a mapping rule for IPv6 packets exchanged between two
   hosts in the same customer site.  In the shown customer site, there
   is a domain interior prefix K2 = 192.168.0.0/16, so that the customer
   index length is x2 = 32 - k2 = 16.  Since there is no need to
   distinguish among several domain exterior prefixes the customer
   interior prefix P2 is equal to the domain interior prefix K2, i.e.
   P2 = 192.168.0.0/16.  The customer exterior prefix, which determines
   whether a locator belongs to the site or not, is D followed by the
   customer site public address Y, supposed to be 198.16.2.2, i.e.  R2 =
   2001:db8:9:c610:2:2::/80.  With this in the second rule, IPv6 packets
   exchanged between two hosts of the site are encapsulated in IPv4
   packets that are routed within the site, as desired.

3.1.2.  Optimized Mapping for Multiple IPv4 Prefixes

   Although 6rd has been successfully used as a tool for "rapid
   deployments" of IPv6 across IPv4 ISP networks, which is its only
   purpose, some people have expressed criticisms that the number of
   bits used to embed IPv4 addresses in IPv6 prefixes could be better
   optimized.  The example which we now present makes such an
   optimization possible.

   Note that this, is not to suggest that SAM should be used in place of
   6rd to rapidly deploy IPv6, but only to show that, if and when SAM is
   eventually an IETF approved design, it will permit, at a price of
   some more complexity, more optimized IPv6 prefix lengths than with
   6rd.

   In this example, shown in Figure 8, the IPv4 ISP network has 3 IPv4
   domain interior prefixes (K1=198.16.0.0/15, K2=198.34.0.0/16,
   K3=198.36.0.0/16), and one IPv6 prefix to be used for SAM (D=2001:
   db8::/32).  Three mapping rules will then be defined, to optimize
   exterior prefix lengths, with an objective that all customer sites
   have the same IPv6 prefix length.








Despres                 Expires September 2, 2010              [Page 18]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


                  +------------------------------+
                  |     ISP NETWORK              |
                  |                              | IPv4 BACKBONE
                  |          K1=198.16.0.0/15 <=========
                  |          K2=198.34.0.0/16    |
                  |          K3=198.36.0.0/16    |
                  |                            P-SAM
            HOSTS |            G=198.16.0.1 ---->S<==== D=2001:db8::/32
              |   |                              | IPv6 BACKBONE
              V   |                              |
           -------+                              |
                c-SAM                            |
           I <====S<==== I=198.16.2.2/32(v4)     |
           E <====S                              |
             E=2001:db8:c610:202                 |
           -------+                              |
                C-SAM                            |
           I <====S<==== I=198.34.2.2/32(v4)     |
           E <====S                              |
             E=2001:db8:c622:202                 |
           -------+                              |
                C-SAM                            |
           I <====S<==== I=198.36.2.2/32(v4)     |
           E <====S                              |
             E=2001:db8:c624:202                 |
           -------+                              |
                  +------------------------------+

                        MAPPING RULES {Rn; Pn; xn; G}
                with Rn=D.Cn, Pn=Kn, i=32, e=56, xn=i-kn,
                     cn=e-d-xn=20-xn, Cn=n000::/cn :
    {R1=2001:db8:1::/39(v6); P1=198.16.0.0/15(v4) ; x1=17; G=198.16.0.1}
    {R2=2001:db8:2::/40(v6); P2=198.16.0.0/15(v4) ; x2=16; G=198.16.0.1}
    {R3=2001:db8:3::/40(v6); P3=198.16.0.0/15(v4) ; x3=16; G=198.16.0.1}


            OPTIMIZED v6/v4 MAPPING FOR MULTIPLE IPv4 PREFIXES

                                 Figure 8

   Since there is only one domain exterior prefix D, there is no need
   for domain-exterior-prefixes codes C in customer interior prefixes so
   that, for n = 1 to 3, Pn = Kn.

   On the other hand, since there are several domain interior prefixes
   Kn, each customer exterior prefix Rn will include a domain-interior
   prefix code Cn after the common D. These codes are chosen so that all
   customer exterior prefixes E have the same length.  We take e = 56,



Despres                 Expires September 2, 2010              [Page 19]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   i.e. long enough to identify all customer sites after the common /32
   prefix D, and constrained to be a multiple of 4 bits for convenience.
   Each customer-index length xn is then determined by the length of the
   domain interior prefixes Kn which precedes customer indexes X in IPv4
   addresses, i.e. xn = 32 - kn.  Lengths cn are then 56 - d - xn = kn -
   8, i.e. c1 = 7 and c2 = c3 = 8.  We choose a value of the first 4
   bits of each cn to be n.  The 3 rules are then as shown on the
   Figure.

3.2.  IPv4 across IPv6-only Domains

   As some ISPs have started deploying IPv6-only networks, typically for
   high bandwidth applications, some of their customers may need
   connectivity with the IPv4 Internet.  (This need is the reverse from
   that satisfied by 6rd where IPv6 connectivity is offered across IPv4-
   only ISP networks).

   The following sections describe how this can be achieved with SAM,
   first if only one ISP IPv4 prefix is used for this, then if there are
   several.

3.2.1.  Single IPv4 Prefix


                     +----------------------------+
                     |         ISP NETWORK        | IPv6 BACKBONE
                     |                       <========= K=2001:db8/32(v6)
                     |                            |
                     |                            | IPv4 BACKBONE
                     |                          P-SAM
   ------------------+         G=2001:db8::1 ---->S<==== D =198.16.0.0/16
     CUSTOMER SITE   |                            |
                   C-SAM                          |
              I <====S<==== I=2001:db8:4:4/48(v6) |
   E=198.16.4.4 <====S                            |
   ------------------+                            |
                     +----------------------------+

                      MAPPING RULE : {R; P; x; G}
                      with R=D, P=K, x=e...-p,
         {R=198.16.0.0/16 ; P=2001:db8::/32; x=16; G=2001:db8:::1}


                IPv4 ADDRESSES ACROSS AN IPv6-ONLY NETWORK

                                 Figure 9

   Figure 9 presents an example configuration where all global IPv4



Despres                 Expires September 2, 2010              [Page 20]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   addresses that have to be assigned to customer sites across the ISP
   IPv6-only infrastructure have the common domain exterior prefix D =
   198.16.0.0/16.  The customer index length x is then set to 32 - d,
   i.e. x = 16.

   The ISP is supposed to assign to this application an IPv6 domain
   interior prefix K=2001:db8/32, and to have as interior locator of the
   provider SAM G = 2001:db8::1.  Since there is only one domain
   exterior prefix D, no domain-exterior-prefix C is needed, and R = D.
   Since there is only one D, we also have P = K. With the resulting
   mapping rule {R=198.16.0.0/16; P=2001:db8::/32; x=16;
   G=2001:db8:::1}, customer sites that are assigned /48 prefixes are
   also assigned public IPv4 addresses.  IPv4 packets are encapsulated
   in IPv6 packets to traverse the ISP network.  Between two customer
   sites, they take the same path as packets that are natively IPv6.
   Between a customer site and the Internet, they go via the P-SAM.

3.2.2.  Multiple IPv4 Prefixes

   We now consider a scenario, detailed in Figure 10, in which an ISP,
   whose IPv6 infrastructure is IPv6 only, has a fragmented IPv4 address
   space.  It has three IPv4 prefixes giving a total of 2^19 addresses:
   D1=198.16.0.0/14, D2=198.36.0.0/15, and D3=198.34.0.0/15.  Its IPv6
   address space is contiguous, with K = 2001:db0/28 as domain interior
   prefix.  It could support 2^20 customer sites with a /48 for each,
   but, willing to offer a uniform service, with an IPv4 address for
   each, it will use half the available space.  Three mapping rules will
   be set up.

   The customer index Xn of a customer site whose domain exterior prefix
   is Dn must have length xn = 32 - dn, i.e. x1 = 18 and x2 = x3 = 17.

   Since there are 3 domain exterior prefixes Dn, we have to choose 3
   domain-exterior-prefix codes Cn.  Supposing we want to assign /48s as
   customer interior prefixes P, the length of each Cn must be such that
   that k + cn + xn = 48, i.e. cn = 20 - xn, i.e. c1 = 2, c2 = c3 = 3.
   The Cn having to be non-overlapping prefixes, with otherwise
   arbitrary values, we chose binary values C1 = 00, C2 = 010, and C3 =
   011.

   Assuming that the IPv6 address of the provider SAM is G=2001:d00::1,
   the resulting mapping rules are {R1=198.16.0.0/14; P1=2001:db!::/30;
   x1=18; G=2001:d00::1}, {R2=198.36.0.0/15; P2=2001:d20::/31; x2=17;
   G=2001:d00::1}, and {R3=198.16.0.0/15; P3=2001:d30::/31; x3=17.
   G=2001:d00::1}.  With them, customer sites of the ISP have each one
   one of the 2^19 IPv4 addresses and a /48 prefix starting with the
   common 2001:db0::/29 prefix.




Despres                 Expires September 2, 2010              [Page 21]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


                      +------------------------------+
                      |        ISP NETWORK           | IPv6 BACKBONE
                      |                       K <=========
                      |                         K=2001:db0/28(v6)
                      |                              |
                      |                              | IPv4 BACKBONE
       CUSTOMER SITES |                            P-SAM
             |        |          G=2001:db0::1 ----->S<=====
             V        |                              | D1=198.16.0.0/14
    ------------------+                              | D2=198.34.0.0/15
                    C-SAM                            | D3=198.36.0.0/15
               I <====S<==== I=2001:db0:404::/48(v6) |
    E=198.16.4.4 <====S                              |
    ------------------+                              |
                    C-SAM                            |
                 <====S<==== I=2001:db4:505::/48(v6) |
    E=198.34.5.5 <====S                              |
    ------------------+                              |
                    C-SAM                            |
                 <====S<==== I=2001:db6:707::/48(v6) |
    E=198.36.7.7 <====S                              |
    ------------------+                              |
                      +------------------------------+

                    MAPPING RULES : {Rn, P, xn, G}
               with Rn=Dn, P=K.Cn, xn=32-dn, cn=48-k-xn :
         {R1=198.16.0.0/14; P1=2001:db0::/30; x1=18; G=2001:db0::1}
         {R2=198.36.0.0/15; P2=2001:db4::/31; x2=17; G=2001:db0::1}
         {R3=198.16.0.0/15; P3=2001:db6::/31; x3=17; G=2001:db0::1}


         IPv4 ACROSS AN IPv6-ONLY NETWORK - MULTIPLE IPv4 PREFIXES

                                 Figure 10

3.3.  Public IPv6 across Private-IPv6 Domains

3.3.1.  Multihoming with Provider-Aggregetable Prefixes

   A well known problem of IPv4 is that more and more provider
   independent prefixes (PIs) are needed to support customer-site
   multihoming.  This has led to a dramatic growth of Internet-core
   routing tables [RFC3582].  The well known reason for this is that, in
   multihomed customer sites that have multiple provider-aggregetable
   prefixes (PAs), each packet having an intra-site address starting
   with one of the PAs has to be routed toward the Internet via the ISP
   that provided this PA (ingress-filtering compatibility, discussed in
   particular in Section 4.7 of [RFC4864]).



Despres                 Expires September 2, 2010              [Page 22]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   While it has been expected that the need for PI prefixes might
   disappear with IPv6, a complete solution remains to be specified for
   this to eventually happen.


                 +------------------------------+
                 |          CUSTOMER SITE       | ISP NETWORK
                 |                              |
                 |             K=fc00::/56 <====:
                 |                              |
                 |                            P-SAM
                 |      G1=fc00::7:0:0:0:1 ---->S<==== D1
                 |                            D1=2001:db8:1::/48(v6)
                 |                              |
                 |                            P-SAM
     ------------+      G2=fc00::6:0:0:0:1 ---->S<==== D2
         HOST    |                            D2=2001:db8:2:2200::/56(v6)
                 |                              |
          I <====S<==== I=fc00::8:0:3:3:3(v6)   |
      E1,E2 <====S                              |
       E1=22001:db8::1:8:0:3:3:3/128(v6)        |
       E2=2001:db8:2:2208:3:3:3:3/128(v6)       |
                 |                              |
     ------------+                              |
                 +------------------------------+

                MAPPING RULES {Rn=Dn.Cn; P=K; x; Gn}
                with i=e=128, Cn=::/e-x-dn, x=128-k :
       {R1=2001:db8:1::/56(v6); P=fc00::/56; x=72; G=fc00::7:0:0:0:1}
       {R2=2001:db8:2:2200::/56(v6); P=fc00::/56; x=72; G=fc00::6:0:0:0:1}


         MULTIHOMED SITE WITH IPv6 PROVIDER-AGGREGETABLE PREFIXES

                                 Figure 11

   We now show on an example, detailed in Figure 11, that hosts of IPv6
   multihomed sites that are SAM capable can take advantage of
   multihoming with multiple PAs.

   The customer site is assumed to have two PA prefixes, which we take
   as domain exterior prefixes D1=2001:db8:1::/48 and D2=2001:db8:2:
   2200::/56.  They have different lengths for generality of the case.
   We assume that the site has several IPv6 interior links, with routing
   between based on a private address space and an 8-bit index to
   identify each link.  The domain interior prefix which precedes these
   8 bits is supposed to be K = fc00::/56, in compliance with
   [RFC4193]).  Provider SAMs that face the two ISPs are supposed to



Despres                 Expires September 2, 2010              [Page 23]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   have as provider interior addresses G1=fc00::7:0:0:0:1 and G2=fc00::
   6:0:0:0:1.

   Since we want host IPv6 addresses to be assigned as usual, i.e.
   possibly with the Stateless Address Autoconfiguration of [RFC2462],
   all bits that follow the common domain interior prefix K must be
   taken as customer indexes, i.e. x = 128 - 56 = 72.

   With the resulting mapping rules {R1=2001:db8:1::/56(v6);
   P=fc00::/56; x=72; G=fc00::7:0:0:0:1} and {R2=2001:db8:2:2200::/
   56(v6); P=fc00::/56; x=72; G=fc00::6:0:0:0:1}, and with the customer-
   SAM locator mapping function of Section 2.3, packets of the shown
   host that leave the site have as interior destination iDST G1 or G2
   depending on whether their exterior source eSRC matches R1 or R2,
   i.e.  D1 or D2.  Thus, compatibility with ingress filtering exercised
   by the ISPs is ensured, as desired.

   Packets exchanged between two hosts of the site, with their public
   addresses as source and destination eSRC and eDST, are encapsulated
   in IPv6 packets having private source and destination addresses iSRC
   and iDST.

3.3.2.  Renumbering with Unchanged Internal Routing

   This example is the same as that of Section 3.3.1 except that, as an
   additional feature, the renumbering which is needed when an ISPs
   modifies the prefix assigned to the site is automated: the periodical
   refresh of SAM parameters, imposed by limited lifetimes assigned to
   mapping rules, does the job.

   For this, SAM rules, similar to those of Section 3.3.1 now contain
   non-default lifetime parameters T, as shown in Figure 12.  These are
   taken shorter than those of received exterior prefixes, e.g. set to
   half their values.  Assuming that ISP-2 plans a replacement of prefix
   D2 by a new one, say D3, it advertises the new prefix D3 with a
   lifetime shorter than that of D2, the still valid but deprecated
   prefix.  Mapping-rule lifetimes T2 and T3, being derived from
   prefixes advertised by ISP-2 for D2 and D3, rule R2 is automatically
   deprecated and will be eliminated after some time.

   As long as bot R2 and R3 are still valid, each customer SAM has two
   ISP-2 exterior prefixes, with different lifetimes.  The prefix that
   has the longer lifetime is the preferred one, i.e. hosts may use it
   in source addresses of transmitted packets, and may accept it in
   destination addresses of received packets.  The other is deprecated,
   i.e. hosts may accept it in destination addresses of received
   packets, but may not use it in source addresses of transmitted
   packets.



Despres                 Expires September 2, 2010              [Page 24]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


               +------------------------------+
               |          CUSTOMER SITE       | ISP NETWORK
               |                              |
               |             K=fc00::/56 <====:
               |                              |
               |                            P-SAM
               |      G1=fc00::7:0:0:0:1 ---->S<==== D1
               |                  D1=2001:db8:1::/48(v6),lifetime=80,000
               |                              |
               |                            P-SAM
               |      G2=fc00::6:0:0:0:1 ---->S<==== D2
   ------------+            D2=2001:db8:2:2200::/56(v6), lifetime=64,000
       HOST    |            D3=2001:db8:3:::/48(v6), lifetime=86,400
               |                              |
        I <====S<==== I=fc00::8:0:3:3:3(v6)   |
    E1,E2 <====S                              |
     E1=22001:db8::1:8:0:3:3:3/128(v6)  <- unique address
     E2=2001:db8:2:2208:3:3:3:3/128(v6) <- valid address
     E3=2001:db8::3:8:3:3:3:3/128(v6)   <- preferred address
               |                              |
   ------------+                              |
               +------------------------------+

                MAPPING RULES {Rn=Dn.Cn; P=K; x; Gn; Tn}
        with i=e=128, Cn=::/e-x-dn, x=128-k, Tn=lifetime(Dn)/2 :
             {R1=2001:db8:1::/48(v6); P=fc00::/56; x=72;
                  G1=fc00::7:0:0:0:1; T1=40,000}
             {R2=2001:db8:2:2200::/56(v6); P=fc00::/56; x=72;
                  G2=fc00::6:0:0:0:1; T2=32,000}
             {R3=2001:db8:3:::/48(v6); P=fc00::/56; x=72;
                  G2=fc00::6:0:0:0:1; T2=43,200}


      RENUMBERING IN A MULTIHOMED IPv6 SITE USING PRIVATE ADDRESSING

                                 Figure 12

   After the deprecated rule has been discarded, the configuration
   returns back back to normal, i.e. with only one customer exterior
   address per ISP in each host.

3.3.3.  Merging Two Private-Addressing Sites using ULAs

   We consider, as shown in Figure 13, two customer sites where interior
   routing is based on unique local IPv6 unicast addresses (ULAs) of
   [RFC4193].





Despres                 Expires September 2, 2010              [Page 25]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


         I=fd12:3456:7890:9:4:4:4:/128(v6)
                     |                       K1=fd12:3456:7890::/56(v6)
         Host-A  +---|-----------------------|--+
          -------+   |  CUSTOMER SITE-1      |  |
               C-SAM |                  K1 <====:
          I <====S<==== I                       |
          E <====S                            P-SAM
          ----|--+    G1=fd12:3456:7890::1 ---->S<==== D1
              |  |           K2     K1       D1=2001:db8:1::/48(v6)
              |  |           ||     /\          |
              |  +-----------\/-----||----------+
              |
           E=2001:db8:1:9:4:4:4:4/128(v6)


          I=fd09:8765:4321:88:3:3:3:3/128(v6)
                     |
                     |        ||     /\      K2=fd09:8765:4321::/56(v6)
         Host-B  +---|--------\/-----||------|--+
          -------+   |        K2     K1      |  |
               C-SAM |                  K2 <====:
          I <====S<==== I                       |
          E <====S                            P-SAM
              |  |    G2=fd09:8765:4321::1 ---->S<==== D2
          ----|--+                            D2=2001:db8:2:220:/56(v6)
              |  |        CUSTOMER SITE-2       |
              |  +------------------------------+
              |
           E=2001:db8:2:2288:3:3:3:3/128(v6)

                 MAPPING RULES: {Rn=Dn.Cn; Pn=Kn; x; Gn}
              with e=i=128, Cn=::/e-x-dn, Pn=Kn, x= 72:
        {R1=2001:db8:1::/56(v6); P1=fd12:3456:7890:/56(v6); x=72;
            G1=fd12:3456:7890::1}
        {R2=2001:db8:2:2200:/56; P2=fd09:8765:4321::/56(v6); x=72;
            G2=fd09:8765:4321::1}



           MERGER OF TWO IPv6 SITES USING UNIQUE LOCAL ADDRESSES

                                 Figure 13

   For end-to-end transparency to be preserved in IPv6 despite the use
   of intra-site private addressing, hosts and customer-site edge
   routers are supposed to be SAM capable.

   Mapping rules are established with only one domain exterior prefix D



Despres                 Expires September 2, 2010              [Page 26]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   per site, but otherwise with the same principles as in the
   multihoming example of Section 3.3.1, in particular with also 8 bits
   to identify IPv6 links within each site.  These rules are supposed to
   be in site-1 {R1=2001:db8:1::/56(v6); P1=fd12:3456:7890:/56(v6);
   x1=68; G1=fd12:3456:7890::1}, and in site-2{R2=2001:db8:2:2200:/56;
   P2=fd09:8765:4321::/56(v6); x2=72; G2=fd09:8765:4321::1}.

   Now, we want to interconnect the two sites in such a way that traffic
   between hosts of the two sites goes via direct inter-site links.
   Since this is precisely the purpose ULAs, we want to do this without
   having to renumber private addresses in any of the two sites.

   For this, it is sufficient that routes be opened between the two
   sites for their respective ULA prefixes, and that DHCP servers of
   each sites have site their lists of provider-SAM locators completed
   with that of the other site.

   After some delay, which depends on timers of DHCP refreshes, all
   hosts know the two rules.  Then, mapping rules of Section 2.3 are
   such that packets going from a site to the global Internet continue
   to reach it via the same provider SAM as before, but that inter-site
   packets go via the shortcuts, as desired.

   For example, if a packet from host A is addressed to host B, it has
   eDST = 2001:db8:2:2288:3:3:3:3 which matches, the customer exterior
   prefix of the second rule R2 = 2001:db8:2:2200:/60.  The derived
   interior destination locator is then iDST = P2.(eDST - R2).0*/128 =
   fd09:8765:4321:88:3:3:3:3, i.e. the interior address of host B.

   If a more complete merger is desired, with the merged site becoming
   multihomed so that all hosts become able to transmit via either
   provider SAM, this is also possible.  Two rules have for this to be
   added: {{R1=2001:db8:1::/56(v6); P2=fd09:8765:4321::/56(v6); x=72;
   G1=fd12:3456:7890::1} and {R2=2001:db8:2:2200:/56; P1=fd12:3456:
   7890:/56(v6); x=72; G2=fd09:8765:4321::1}.

3.4.  A Planned Experiment at Telecom Bretagne

   A particular experiment of SAM is planned at Telecom Bretagne, an
   academic institution in France.  It involves a two-layer hierarchy of
   SAM domains.  The layer-1 domain is a student-residence network;
   layer-2 domains are LANs within rooms of some of the students that
   participate in the experiment.

   Each student room, which has today a DHCP advertised private IPv4
   address and an auto-configured IPv6 public address, will obtain in
   addition, with SAM, a /60 IPv6 prefix and 240 ports on a shared
   public IPv4 address.



Despres                 Expires September 2, 2010              [Page 27]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


                +------------------------------+
                |  STUDENT-RESIDENCE NETWORK   |TELECOM BRETAGNE
                |                              |     NETWORK
                |                              |IPV6
                |                         <=========
                |                           2001:660:7301:4666::/64
                |                              |
                |                            NAT44 IPv4
                |         K=192.168.0.0/24<====N<----
                |               0.0.0.0/0 ====>N
                |                              |
   -------------+                            P-SAM
                |        G=192.168.0.1/32 ---->S<=====
   STUDENT ROOM |                           D1=2001:660:7301:3000/52(v6)
                |                           D2=192.108.119.26/32(v4)
           <----------                         |
              2001:660:7301:4666:2:3:4:5       |
                |                              |
              C-SAM                            |
         I <----S<---- I=192.168.0.4(v4) <- IPv4 private address
           <====S                              |
        E1=2001:660:7301:3040/60(v6) <- IPv6 public prefix
        E2=192.108.119.26.4/40(v4)   <- 240 ports on a public IPv4 address
                |                           (15/16*2^(48-40))
   -------------+                              |
                +------------------------------+

             STUDENT-RESIDENCE MAPPING RULES : {Rn; P; x; G}
                       with Rn=Dn, P=K, x=32-p :
            {R1=2001:660:7301:3000/52(v6); P=192.168.0.0/24; x=8}
            {R2=192.108.119.26/32(v4); P=192.168.0.0/24; x=8}


               STUDENT-RESIDENCE NETWORK AT TELECOM-BRETAGNE

                                 Figure 14

   In rooms equipped with a SAM-capable CPE, each SAM-capable host will
   have, in addition to its DHCP advertised private IPv4 address, a /64
   IPv6 prefix and 15 ports on the shared IPv4 address.

   The configuration planned for this is shown in Figure 14 and
   Figure 15.








Despres                 Expires September 2, 2010              [Page 28]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


          +---------------+========================+
          | STUDENT-ROOM  |  IN STUDENT-ROOM CPE   | STUDENT-RESIDENCE
          |      LAN      |                        |      NETWORK
          |               |                        |
          |               |                   <----------
          |               |               2001:660:7301:4666:2:3:4:5
          |K= 198.0.0.0/28|                        |
          |           |   |                        |
          |           | NAT44                     C-SAM
          |          <====N<---- 192.168.0.4  <----S<---- I
          |          ====>N                        S  I=192.168.0.4(v4)
          |      0.0.0.0/0|                        S
          |               |                        S
          |             P-SAM                      S
          |        G ---->|<==== D1,D2  E2,E2 <====S
          |    G=198.0.0.1|    D1=E1=2001:660:7301:3040/60(v6)
          |               |    D2=E2=192.108.119.26.4/40(v4)
          |               |                        |
   -------+               +========================+
   STUDENT|               |
    HOST  |               |
          |               |
        C-SAM             |
   I <----S<---- I=192.168.0.2(v4)   <- IPv4 private address
     <====S               |
      E1=2001:660:7301:3042:/64(v6)  <- IPv6 public prefix
      E2=192.108.119.26.4.32/44(v4)  <- 15 ports on a public IPv4 address
          |               |              (15/16*2^(48-44))
   -------+               |
          +---------------+

               STUDENT-ROOM MAPPING RULES : {Rn; P; x; G}
                      with Rn=Dn, P=K, x=32-p :
            {R1=2001:660:7301:3040/60(v6); P=192.168.0.0/28; x=4}
            {R2=192.108.119.26/32(v4); P=192.168.0.0/28; x=4}



                 STUDENT-ROOM EXAMPLE AT TELECOM-BRETAGNE

                                 Figure 15

   In a border node of the residence, a provider SAM will be set up, in
   a PC under Linux, to derive from the 8 lower bits of private IPv4
   addresses two public prefixes: an IPv6 /60 and an extended IPv4 /40.






Despres                 Expires September 2, 2010              [Page 29]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   In each room participating to the intra-room experiment, a router
   under Linux will be supplied.  In addition to its classical NAT44
   which assigns private IPv4 addresses to hosts in the room, it will
   include a customer SAM and a provider SAM.  The customer SAM will
   derive the IPv6 /60 and the IPv4E /40 of the room from its private
   address on the residence LAN.  The provider SAM will further
   distribute these prefixes so that each host in the room can derive
   from it's DHCP assigned IPv4 address an IPv6 /64 and an IPv4E /44.
   Thus, each host will have not only it's own IPv6 address, but will
   also be able to to manage a small IPv6 LAN behind it.  It will also
   be reachable from the Internet in IPv4 at it's shared public address
   on one of it's 15 assigned ports.


4.  Security considerations

   To avoid to introduce new spoofing opportunities, SAMs should
   ascertain that source and destination iSRC and iDST of each received
   interior packet are, with the mapping rules of the domain, valid
   derivate from the exterior source and destination eSRC and eDST
   contained in the encapsulated packet.

   Against denial of service attacks, the fact that mapping functions
   and encapsulations are stateless is clearly favorable.  An exception
   exists however with IPv4E exterior locator spaces because of the the
   datagram reassembly function of Section 2.6 which has a stateful
   internal operation.  (This vulnerability is the same as found in NATs
   that don't forward fragmented datagrams.)

   A systematic study has still to be done on which routing-loop-
   attacks, similar to those documented for ISATAP and 6to4 in
   [RoutingLoops], might be possible.  As a minimal precaution, provider
   SAMs should discard any interior packets received whose source iSRC
   is the provider interior locator G of any provider SAM, and should
   not forward any interior packet whose destination iDST is such a G.
   Any interior address of a 6to4 relay that would be set up in a SAM
   domain, or of a default ISATAP router giving access to the IPv6
   Internet, should be considered also as a forbidden G.


5.  IANA Considerations

   DHCP and DHCPv6 option codes have to be specified by IANA.

   It could also be convenient that a number be assigned by IANA for the
   port used in provider SAMs to encapsulate over UDP over IP.





Despres                 Expires September 2, 2010              [Page 30]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


6.  Acknowledgments

   Although this specification is mostly the result of a personal work
   of the author, in continuity with that which led to the 6rd of
   [RFC5569], recognition is due to a number of colleagues who provided
   useful reactions as the proposal evolved.  Mark Townsley provided
   precious encouragements since the early phases of the project.  He
   also acted as a convincing advocate for a Cisco Research Grant to be
   allocated, a SAM experiment with port-extended IPv4 addressing, at
   Telecom Bretagne.  Laurent Toutain, who leads the team in charge of
   this experiment, deserves special gratitude for the confidence he has
   shown for the concept, and for the time spent for experiment to be
   organized.  Dave Thaler has to be thanked for the detailed review he
   made on a previous draft.  Satoru Matsushima was first to point out
   that, because some providers already operate IPv6-only networks,
   public IPv4 across such networks could become a not-so-long-term
   application of SAM.


7.  References

7.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.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [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.

   [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.







Despres                 Expires September 2, 2010              [Page 31]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


7.2.  Informative References

   [DNS-SD]   Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery
              - draft-cheshire-dnsext-dns-sd-05", September 2008.

   [NAT-PMP]  Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
              (NAT-PMP) - draft-cheshire-nat-pmp-03", April 2008.

   [NatClassification]
              Jennings, C., "NAT Classification Test Results -
              draft-jennings-behave-test-results-04", July 2007.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
              RFC 3068, June 2001.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 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.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
              Problem Statement", RFC 4925, July 2007.




Despres                 Expires September 2, 2010              [Page 32]


Internet-Draft       Stateless Address Mapping (SAM)          March 2010


   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [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)", January 2010.

   [RoutingLoops]
              Nakibly, G. and F. Templin, "Routing Loops using ISATAP
              and 6to4: Problem Statement and Proposed Solutions - -
              draft-nakibly-v6ops-tunnel-loops-01", February 2010.

   [Standard-track 6rd]
              Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
              Networks - draft-ietf-softwire-ipv6-6rd-04",
              February 2010.


Author's Address

   Remi Despres
   RD-IPtech
   3 rue du President Wilson
   Levallois,
   France

   Email: remi.despres@free.fr





















Despres                 Expires September 2, 2010              [Page 33]


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