Subject: Re: [nat66] [BEHAVE] FYI: draft-despres-sam-02 enclosed

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 18:52:14 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Monday, March 16, 2009 5:13 PM
> To: Rémi Després
> Cc: Softwires WG; Behave WG; Internet Area
> Subject: Re: [BEHAVE] FYI: draft-despres-sam-02 enclosed
> 
> 
> Hi Remi,
> 
> I have a few high-level comments/questions on this draft from 
> my first  
> reading, and I may have more after I have reviewed it in more detail.
> 
> (1) You have indicated that you would like to discuss this draft in  
> the 6AI BOF, but you have not cc:ed the mailing list for the 
> 6AI BOF ([email-masked] 
> ). 

He did, in another email that went to both NAT66 and SHARA,
http://www.ietf.org/mail-archive/web/nat66/current/msg00106.html but my email
filters put that message into my SHARA folder.

I added [email-masked] to the CC list in the hopes that discussion regarding
sam-02's applicability to solve 6AI will move to nat66 mailing list.  Reply-to
is also set to nat66.

> Also, have you talked to the chairs of the 6AI BOF (Bob 
> Hinden and  
> Dan Wing) about whether they are willing to include this 
> draft on the  
> agenda, despite the fact that it has not been posted to the I-D  
> archive? 

He has requested agenda time.  We are still considering it and
discussion of sam-02 on the nat66 mailing list would be useful 
to reach a decision.

> There doesn't appear to be an agenda online for the 
> 6AI BOF  
> yet, so I am not sure if it will be included.

Yes, we are still trying to sort through some plans.  Sorry
we don't have a draft agenda posted yet.

-d

> (2) The end hosts in the SAM system need to know their globally  
> routable addresses, so how can SAM be said to provide address  
> independence?
> 
> (3) Exactly what formulation of the end-to-end principle are you  
> referring to in this paper when you indicate that SAM 
> preserves it in  
> IPv6?
> 
> My understanding of the end-to-end principle is that it has 
> to do with  
> putting intelligence at the edges of the network (in hosts 
> vs. routers/ 
> middleboxes) and with putting certain function at the top of the  
> protocol stack (apps layer vs. lower layers).  This is based on my  
> understanding (and recollection) of a paper by Jerry Saltzer, 
> D. Reed  
> and Dave Clark written in the mid 1980s, which you can find here:
> 
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt
> 
> It is also reasonably well-summarized in this Wikipedia article.
> 
> http://en.wikipedia.org/wiki/End-to-end_principle
> 
> Based on my understanding of the end-to-end principle, I 
> don't see any  
> significant difference in SAM vs. NAT66 WRT how much they 
> maintain (or  
> violate) the end-to-end principle, as both mechanisms place some  
> functions/intelligence in the infrastructure.
>
> Margaret
> 
> 
> 
> On Mar 13, 2009, at 5:56 AM, Rémi Després wrote:
> 
> > Hi,
> > For your information, draft-despres-sam-02, which was ready 
> too late  
> > to be posted before IETF 74, is enclosed below
> >
> > It is a major update of the version-01 which was presented 
> at IETF 73:
> > - In Softwires, ref.:
> > 
> http://www.ietf.org/proceedings/08nov/slides/softwire-3/softwi
> re-3_files/slide0002.htm
> > - In Behave, ref.:
> > http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf
> >
> > In San Francisco, its part that deals with NAT66 avoidance 
> is to be  
> > discussed at the 6IA BOF meeting (ex NAT66).
> > Its part that deals with Port-Range extension, is to be 
> discussed at  
> > the SHARA BOF.
> >
> > Comments most welcome.
> >
> > Regards,
> >
> > RD
> >
> >
> >
> >
> >
> >
> > Internet Engineering Task Force                               R.  
> > Despres
> > Internet-Draft                                             
> November  
> > 2008
> > Intended status: Standards Track
> > Expires: May 5, 2009
> >
> >
> >                     Stateless Address Mapping (SAM)
> >       Avoiding NATs and restoring the end-to-end principle in IPv6
> >                           draft-despres-sam-02
> >
> > Status of this Memo
> >
> >    By submitting this Internet-Draft, each author 
> represents that any
> >    applicable patent or other IPR claims of which he or she is aware
> >    have been or will be disclosed, and any of which he or 
> she becomes
> >    aware will be disclosed, in accordance with Section 6 of BCP 79.
> >
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF), its areas, and its working groups.  Note that
> >    other groups may also distribute working documents as Internet-
> >    Drafts.
> >
> >    Internet-Drafts are draft documents valid for a maximum of six  
> > months
> >    and may be updated, replaced, or obsoleted by other 
> documents at  
> > any
> >    time.  It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt.
> >
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> >    This Internet-Draft will expire on May 5, 2009.
> >
> > Abstract
> >
> >    Stateless Address Mapping (SAM) is a generic mechanism to support
> >    global addressing across network zones where routing is 
> based on a
> >    different address space.  With it, the end-to-end 
> principle, lost  
> > in
> >    IPv4 with the deployment of NATs, can be restored without losing
> >    services that NAT44s offer beyond address-space 
> extension (private
> >    addressing, basic firewall, site multihoming, privacy protection,
> >    host-rooted subnets).  Global-address packets are encapsulated in
> >    local-address packets to traverse SAM zones, and global 
> prefixes  
> > are
> >    statelessly mapped into local addresses.  For the IPv6-IPv4
> >    coexistence period, port-restricted IPv4 addresses are used to  
> > extend
> >    the global IPv4 address space.
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 1]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Table of Contents
> >
> >    1.  Introduction and general problem  
> > statement . . . . . . . . . .  3
> >    2.  NAT44 services availability of which in IPv6 is  
> > desirable  . .  4
> >      2.1.  Private addressing (easy  
> > renumbering)  . . . . . . . . . .  4
> >      2.2.  Basic firewall (by default, no incoming  
> > connections) . . .  4
> >      2.3.  Site multihoming (automatic  
> > fallback)  . . . . . . . . . .  4
> >      2.4.  Privacy  
> > protection . . . . . . . . . . . . . . . . . . . .  4
> >      2.5.  Host-rooted  
> > subnets  . . . . . . . . . . . . . . . . . . .  5
> >    3.  SAM  
> > specification  . . . . . . . . . . . . . . . . . . . . . .  5
> >      3.1.  Local Zones - Root SAMs - Branch  
> > SAMs  . . . . . . . . . .  5
> >      3.2.  Encapsulation of global packets in local  
> > packets . . . . .  7
> >      3.3.  Global prefixes - global addresses - local  
> > addresses . . .  9
> >      3.4.  Endpoint global address to branch local address  
> > mapping  . 11
> >      3.5.  Privacy  
> > protection . . . . . . . . . . . . . . . . . . . . 13
> >      3.6.  SAM  
> > parameters . . . . . . . . . . . . . . . . . . . . . . 15
> >      3.7.  Port-range-based extended IPv4  
> > addressing  . . . . . . . . 16
> >    4.  SAM Application  
> > examples . . . . . . . . . . . . . . . . . . . 17
> >      4.1.  Address independence in an IPv6  
> > site . . . . . . . . . . . 17
> >      4.2.  Multihoming and extended IPv4 addressing in a home  
> > site  . 19
> >    5.  SAM as an alternative to NATs in  
> > IPv6  . . . . . . . . . . . . 21
> >    6.  Security  
> > considerations  . . . . . . . . . . . . . . . . . . . 22
> >    7.  IANA  
> > Considerations  . . . . . . . . . . . . . . . . . . . . . 22
> >    8.   
> > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
> >    9.   
> > References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
> >      9.1.  Normative  
> > References . . . . . . . . . . . . . . . . . . . 23
> >      9.2.  Informative  
> > References . . . . . . . . . . . . . . . . . . 23
> >    Author's  
> > Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
> >    Intellectual Property and Copyright  
> > Statements . . . . . . . . . . 26
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 2]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > 1.  Introduction and general problem statement
> >
> >    In IPv4, Network Address Translations have been extensively  
> > deployed
> >    (NAT44s).  They are key to mitigate the IPv4 address 
> shortage.  But
> >    they also offer various auxiliary services, described in 
> Section 2:
> >    private addressing, basic firewall, site multihoming, privacy
> >    protection, host-rooted subnets.
> >
> >    In counterpart to these auxiliary services, these NAT44s have
> >    introduced two drawbacks:
> >
> >    o  Non compliance with the end-to-end principle of the Internet
> >       (e2e).
> >
> >          Negative consequences include incompatibility with 
> the IPsec
> >          security mechanism, and difficulties for hosts to 
> know their
> >          own global addresses, which they need for connection
> >          redirections, for host referrals, and and, in sites having
> >          several site entrance routers, for multihoming support
> >          mechanisms like the SCTP of [RFC4960] and [Shim6].
> >
> >    o  Stateful operation.
> >
> >          Most NAT44s are in fact stateful NAPTs (ref. < xref
> >          target="RFC2663" />): to support more local 
> addresses than  
> > they
> >          have external addresses, they maintain per-transport- 
> > connection
> >          states.  Negative consequences include limited 
> scalability,  
> > and
> >          the risk of denial of service attacks that go with it, as  
> > well
> >          as single points of failures.
> >
> >    Since no global address shortage is in view in IPv6, the 
> following
> >    questions have to be asked:
> >
> >    o  Which NAT44 services can, in IPv6, be offered statelessly and
> >       without breaking the e2e principle?
> >
> >    o  How?
> >
> >    This draft proposes to answer these questions more 
> completely, and
> >    with more technical details, than [RFC4864], the most advance
> >    document on the subject so far.
> >
> >    For this, a Stateless Address Mapping generic mechanism is  
> > introduced
> >    (SAM).
> >
> >    Conclusion, is that, provided SAM is supported in nodes at  
> > borders of
> >    independently administered routing zones, the e2e 
> principle can be
> >    restored in IPv6, for all identified useful functions of NAT44s.
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 3]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    (This conclusion needs however to be confirmed after 
> further work  
> > on
> >    SAM details, after criticisms by other experts, after 
> some possible
> >    bug corrections, and after validations with running code.)
> >
> >    Thus, traversal of NATs in ISP infrastructures can be avoided.
> >    (These NATs do provide useful connectivity to some 
> non-SAM-capable
> >    nodes, but have the drawback of breaking the e2e 
> principle, with  
> > the
> >    mentioned consequences on security, referrals, multihoming,
> >    scalability and reliability.
> >
> >
> > 2.  NAT44 services availability of which in IPv6 is desirable
> >
> > 2.1.  Private addressing (easy renumbering)
> >
> >    With NAT44s, when a prefix assigned by an ISPs to a 
> customer site  
> > is
> >    modified, local IP addresses in the site can remain unchanged.
> >
> > 2.2.  Basic firewall (by default, no incoming connections)
> >
> >    Most NAT44s, being NAPTs, and therefore maintaining 
> states for all
> >    TCP and UDP connections, have as a byproduct a protection against
> >    incoming connections (unless some "holes" are "punched" in this
> >    protection, under explicit customer control).  This level of  
> > security
> >    protection is largely relied upon.
> >
> > 2.3.  Site multihoming (automatic fallback)
> >
> >    In a site is multi-homed, and if it has a NAT device 
> supporting all
> >    its ISP interfaces, its hosts can take advantage of multihoming
> >    without having to support any multihoming-specific 
> function.  This
> >    level of multihoming support is better than none.
> >
> >    (For this, a NAT44 needs only to make sure that, for 
> each transport
> >    connection, all outgoing packets go through the same 
> ISP.  Thus, if
> >    an ISP access fails, current TCP and UDP connections 
> that go via  
> > this
> >    ISP are broken, but theycan immediately be replaced by new ones.)
> >
> > 2.4.  Privacy protection
> >
> >    From outside a site where a NAT44 operates in NAPT mode, it is
> >    difficult to determine which hosts establish which 
> connections.   
> > This
> >    level of privacy protection, in particular for some web 
> requests,  
> > is
> >    an added value.
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 4]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > 2.5.  Host-rooted subnets
> >
> >    Behind a host that is assigned a single IPv4 address, it is  
> > possible,
> >    with a NAT44 in the host, to deploy a private subnet.  As modern
> >    operating systems include a router function with a NAT44, a  
> > computer
> >    can can serve as a root for a LAN.
> >
> >    Thus, the distinction between hosts and a routers is no longer a
> >    distinction between types of devices.  It has become only a
> >    distinction between functions within nodes.
> >
> >
> > 3.  SAM specification
> >
> > 3.1.  Local Zones - Root SAMs - Branch SAMs
> >
> >    As presented in Figure 1, the SAM mechanism applies to a 
> SAM "local
> >    zone" Z. Routing within this zone is independently 
> administered,  
> > and
> >    is based on a "local address space".
> >
> >    Each SAM zone has one or several "root interfaces" (Ri), 
> that give
> >    access to the global Internet.  Each one has, in the global  
> > Internet,
> >    one or several "global prefixes" (gZij) exclusively assigned to  
> > zone
> >    Z.
> >
> >    SAM global prefixes can be global IPv6 and/or global IPv4.  SAM  
> > local
> >    address spaces can be IPv6 or IPv4, global or private.  If both  
> > IPv4
> >    and IPv6 are routed in the zone, one of the two is 
> chosen for SAM.
> >    (SAM is in this respect therefore an extension of the 6to4 of
> >    [RFC3056], of the ISATAP of [RFC5214], and of [6rd], where all  
> > global
> >    prefixes are IPv6 and all local address spaces are IPv4).
> >
> >    As explained in Section 3.7, global IPv4 addresses can 
> be extended
> >    beyond 32 bits to deal with the IPv4 address shortage during the
> >    IPv4-IPv6 coexistence period.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 5]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                                          ROOT-SIDE ENDPOINTS
> >                                       |         /\            |
> >                                       |         ||            |
> >                                 |_____:_____|   ||     
> |______:_____|
> >                                       |                       |
> >                                       |      ROOT ZONES       |
> >                                       |                      gZ22
> >     Zone Global prefixes gZij       gZ11                     gZ21
> >     Root interfaces:          
> > _________:_______________________:________
> >                             |(Z)   (root-SAM)              (root- 
> > SAM)  |
> >     Root local addresses:   |         R1                        
> > R2      |
> >             Ri               
> > |                                          |
> >                             |                SAM ZONE  
> > Z                |
> >                              
> > |                                          |
> >                              
> > |                                          |
> >     Branch local addresses: |      B1               B2            
> > B3   |
> >             Bk               
> > |      :                :             :    |
> >     Branch interfaces:      | 
> > ______:________________:_____________:____|
> >                                    |                |             |
> >     Branch Global prefixes:        |          (branch-SAM)        |
> >       *gBkij=gZij.zBk*               => + gB211, gB221, gB222
> >     Branch Global Addresses:            +  gB211@, gB221@, gB222@
> >       *gBkij@=gBkij.H*                              ||
> >                                BRANCH ZONES         ||
> >                                                     \/
> >                                           BRANCH-SIDE ENDPOINTS
> >
> >                       ROOT AND BRANCH INTERFACES AND SAMs
> >
> >                                  Figure 1
> >
> >    Each root interface that supports a root-SAM function has a local
> >    address (Rk), and each "branch interface" has a local 
> address (Bk).
> >
> >    If a "branch SAM" function is supported at a branch interface Bk,
> >    this interface gets, in addition to its local address, global
> >    prefixes (gBkij).  Each of these prefixes is made of a global  
> > prefix
> >    of the zone (gZij) followed by an identifier (zBk) of 
> the branch in
> >    its zone.
> >
> >    For each each of its global prefixes gBkij, a branch 
> interface has
> >    also a host global address (gBkij@), derived from the prefix by
> >    appending a standard host suffix (H) to complete the address  
> > length.
> >
> >    Thus, if a zone D is accessible from the global Internet 
> via a zone
> >    hierarchy A, B, C, it has at least gA.aB.bC.cD as a 
> global prefix  
> > gD,
> >    and gA.aB.bC.cD.H as a global address gD@.  SAM is thus an
> >    application of the locator-identifier separation principle.  (It
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 6]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    differs however from [LISP], in that no new protocol is 
> needed fro
> >    SAM, just new options in existing protocols such as DHCP 
> [RFC2131],
> >    DHCPv6 [RFC3315], or ND [RFC4861], to advertise SAM parameters to
> >    branch interfaces.)
> >
> > 3.2.  Encapsulation of global packets in local packets
> >
> >
> >    endpoint Y Global address:                 gY
> >                                                ^
> >                                                |
> >                                               ...
> >    (3)  e2e packet:                    [ gX->gY [data]]
> >                                                ^
> >                                                |
> >                                               gZ         ROOT ZONE R
> >                                  
> ______________:______________________
> >                                 |(Z)       (root  
> > SAM)                 |
> >                                 |              R         
> LOCAL ZONE  
> > Z |
> >                                 |               
> > ^                      |
> >                                 |               
> > |                      |
> >                                  
> > |             ...                     |
> >    (2)  encapsulated packet:     
> > |                                     |
> >          *B = la(gX)*           |      [  B->R [gX- 
> > >gY[data]]         |
> >          *R = parameter*        |               
> > ^                      |
> >                                 |               
> > |                      |
> >                                 |               
> > B                      |
> >                                 | 
> > ______________:______________________|
> >                                           (branch SAM)   
> BRANCH ZONE B
> >                                            => + gB
> >                                                ^
> >                                                |
> >                                               ...
> >    (1)  e2e packet:                    [ gX->gY [data]]
> >                                                ^
> >                                                |
> >    endpoint X Global address:          gX=gZ.id(B).xxx
> >
> >
> >      PACKET ENCAPSULATION AND ADDRESS MAPPING - BRANCH SIDE 
> TO ROOT  
> > SIDE
> >
> >                                  Figure 2
> >
> >    To traverse a SAM local zone, global-address packets are  
> > encapsulated
> >    into local address packets, as illustrated in Figure 2 
> and Figure  
> > 3).
> >
> >    Thus, compatibility is ensured, within the local zone, 
> with ingress
> >    the filtering for multihomed networks of [RFC3704], the 
> basic anti-
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 7]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    spoofing mechanism.
> >
> >
> >                                                |
> >                                                |           ROOT ZONE
> >                                               gZ
> >                                  
> ______________:______________________
> >                                 |(Z)       (root- 
> > SAM)                 |
> >                                 |              R         
> LOCAL ZONE  
> > Z |
> >                                  
> > |                                     |
> >                                  
> > |                                     |
> >                                  
> > |                                     |
> >    (2)  encapsulated packet:    |     [ B1->B2 [gE1- 
> > >gE2[data]]       |
> >         *B1 = la(gX)*           |         -------- 
> > >--------           |
> >         *B2 = la(gY)*           |       /                    
> > \         |
> >                                 |      ^                      
> > |        |
> >                                 |      |                      
> > v        |
> >                                 |      B1                     
> > B2       |
> >                                 | 
> > ______:_____________________:________|
> >            BRANCH ZONES:          (branch-SAM)          (branch-SAM)
> >                                     => + gB1              => + gB2
> >                                        ^                     |
> >                                        |                     v
> >    (3)  e2e packet:                   ...              [ E1->E2  
> > [data]]
> >    (1)  e2e packet:             [ E1->E2 [data]]             ...
> >                                        ^                     |
> >                                        |                     v
> >                                gX=gZ.id(B1).xxx          
> > gY=gZ.id(B2).yyy
> >                                       _:_                   _:_
> >                                      | X |                 | Y |
> >                                      |___|                 |___|
> >
> >    ADDRESS MAPPING AND PACKET ENCAPSULATION - BRANCH SIDE 
> TO BRANCH  
> > SIDE
> >
> >                                  Figure 3
> >
> >    For the IP-in-IP encapsulation, the IPv6 next header or the IPv4
> >    protocol id which indicates the type of IP payload is set to 41  
> > (the
> >    same value as for 6to4, ISATAP, and 6rd).
> >
> >    Local addresses are determined as follows (illustrated in figures
> >    Figure 2 and Figure 3):
> >
> >    1.  If an endpoint global address gE, indifferently source or
> >        destination, is that of a branch-side endpoint, this is
> >        recognized by the fact that it starts with one of the global
> >        prefixes of the zone.  Then, the local address B is 
> obtained  
> > by a
> >        function B=la(gX), completely determined by SAM 
> parameters of  
> > the
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 8]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >        zone (details in Section 3.4).
> >
> >    2.  If an endpoint global address gE, indifferently source or
> >        destination, is that of a root-side endpoint, this is  
> > recognized
> >        by the fact that it doesn't start with any of the global  
> > prefixes
> >        of the zone.  In this case, the other address gX of 
> the packet,
> >        destination or source respectively, is necessarily that of a
> >        branch-side endpoint (otherwise the packet would not 
> traverse  
> > the
> >        local zone).  Then, local address Ri is that of the root
> >        interface that has, in its assigned global prefixes, 
> the global
> >        prefix present at the beginning of the branch-side 
> address gX.
> >
> >    In multihomed sites, the second of these rules ensures  
> > compatibility
> >    with the ingress filtering of [RFC3704] in root zones (if it does
> >    apply, as necessary for anti-spoofing protection).
> >
> >    In Figure 2 and Figure 3, packets in the reverse direction, not
> >    shown, would have the same addresses but with sources and
> >    destinations inverted, and with encapsulations and decapsulations
> >    made at inverted interfaces.
> >
> >    Decapsulation functions MUST verify, for anti-spoofing 
> protection,
> >    that local addresses present in headers of encapsulating 
> packets  
> > are
> >    consistent with global addresses present in headers of 
> encapsulated
> >    packets.
> >
> > 3.3.  Global prefixes - global addresses - local addresses
> >
> >    Internal structures of SAM global prefixes, global addresses, and
> >    local addresses are detailed in Figure 4.
> >
> >    A branch-interface global prefix necessarily starts with a global
> >    prefix of the zone Z. Its remaining bits are a "branch  
> > identifier" in
> >    the zone (gBkij = gZij.zB).
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009                   
> > [Page 9]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >              |<-------------- Branch global address gB@ 
> ------------- 
> > >|
> >              |<-------- Branch global prefix gB -------- 
> > >             |
> >              |<-- G --><-----  Branch identifier iB ---- 
> > >             |
> >               
> ________________________________________________________
> >              |  local  |branch|  Subnet |     branch     |    
> > branch   |
> >              |  zone   |  id  |  index  |      Index     |     
> > Host    |
> >              |  Global |Format| (option)|                |   
> > endpoint  |
> >              |  prefix | code |         |                |    
> > suffix   |
> >              |         |      |         |                |  
> > (10...00)  |
> >              |    G    |   F  |    S    |        I       |      
> > H      |
> >              |_________|______|_________|________________| 
> > ____________|
> >                     _______/   <-- s ---><----- i ------>
> >                   /               ^                    ^
> >                  v                |                    |
> >         Specifies s and b        /                      \
> >           (option)              |                        \
> >         Specify F   <-----.-----|--------------------.    \
> >                            \    |                     \    |
> >                             \   v                      \   v
> >                            <-- s --->                 
> <----- i ------ 
> > >|
> >               
> ________________________________________________________
> >              |local-address| Subnet  |  next field   |      
> > branch     |
> >              |   constant  |  index  |   Delimiter   |       
> > index     |
> >              |    Prefix   |         |   (00...01)    
> > |                |
> >              |             |         |                
> > |                |
> >              |       P     |    S    |      D        |         
> > I       |
> >              |_____________|_________|_______________| 
> > ________________|
> >              |<-- subnet prefix zS -->
> >              |<-------------- Branch local address B 
> ---------------- 
> > >|
> >
> >
> >          SAM GLOBAL PREFIXES - GLOBAL ADDRESSES - LOCAL ADDRESSES
> >
> >                                  Figure 4
> >
> >    Principles that influence the internal structure of branch
> >    identifiers proposed for SAM are the following:
> >
> >    1.  To permit a flexible hierarchy of local zones, branch  
> > identifiers
> >        should be kept rather short.  They should, at least to some
> >        extent, be proportionate to the maximum number of branches
> >        supported in their zone.
> >
> >    2.  Several subnets must be possible in the zone.  For this, a  
> > branch
> >        identifier contain an optional "subnet index" (S), 
> followed the
> >        "branch index" (I) which identifies the branch in its subnet.
> >        (The word "index" is chosen to express that these 
> fields have  
> > no
> >        further internal structure.)
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 10]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    3.  For the efficiency of routing tables, intra-zone 
> subnet indexes
> >        have to be in the upper part of local addresses, 
> just behind  
> > the
> >        "constant prefix" (P) that is common to all local 
> addresses.   
> > (In
> >        IPv6, this constant prefix can typically be an ULA prefix of
> >        [RFC4193]; in IPv4 is typically a private-address prefix of
> >        [RFC1918].)
> >
> >    4.  For efficiency of the neighbor discovery protocol of 
> [RFC2461],
> >        branch indexes B have on the contrary to be in the lowest  
> > part of
> >        branch local addresses B.
> >
> >    5.  Consequently, it must be possible to extract 
> separately, from a
> >        intra-zone branch identifier iB, the subnet index S and the
> >        interface index I, and for this to know their 
> lengths (s and  
> > i).
> >
> >    6.  In order to permit to configure several subnet-index lengths,
> >        and/or several interface index lengths, in SAM zones, an  
> > optional
> >        branch-identifier "format code" (F) is placed at the  
> > beginning of
> >        branch identifiers B (just before the optional 
> subnet index S,
> >        and the branch index B).  Each format codes 
> specifies a subnet-
> >        index length s and an interface-index length i.  
> Format codes T
> >        may have different lengths, but must be non overlapping  
> > prefixes
> >        to be recognized.
> >
> >    Since the local address B of a branch interface starts with a
> >    constant prefix P followed by the interface subnet index 
> S , and is
> >    terminated by the interface-index of the interface, space is left
> >    between them.  It is filled with a next-field delimiter (D).  Its
> >    format, a series of 0s followed by a 1, i.e. 00...01 
> with a minimal
> >    length of 1 bit, is chosen so that knowing the constant 
> prefix P  
> > and
> >    the subnet prefix of a branch interface, lengths s and i 
> of the its
> >    subnet index S and of its interface index I can be determined.   
> > Then,
> >    the identifier format F to be placed in global prefixes 
> of B can be
> >    derived from these lengths s and i.
> >
> > 3.4.  Endpoint global address to branch local address mapping
> >
> >    Detailed steps by which a branch local address B is 
> derived from  
> > from
> >    the global address of a branch-side endpoint are presented in
> >    Figure 5.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 11]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >               
> ________________________________________________________
> >              |                  Endpoint Global  
> > address               |
> >              |                              
> > gE                         |
> >              | 
> > ________________________________________________________|
> >                            (A) ANALYSIS    ||
> >                                            \/
> >               ___________________________________________ 
> ............
> >              | Global  |  id  |  Subnet |     branch     |  
> > endpoint   :
> >              | prefix  |Format|  index  |      Index     |   
> > suffix    :
> >              |    G    |   F  |    S    |        I       |      
> > E      :
> >              |_________|______|_________| 
> > ________________|............:
> >                        |   |       |            |
> >      1. Match found    |   |       |            |
> >      in the G list  ___|   |       |            |
> >                            |       |            |
> >      2. Match found        |       |            |
> >      in the F list   ______|       |            |
> >                                    |            |
> >      3. length defined by F _______|            |
> >                                    .            |
> >      4. length defined by F ____________________|
> >                                    .            .
> >                  (B) CONSTRUCTION  .     ||     .
> >                                    .     \/     .
> >      5. The current                .            .
> >      local-address prefix __       .            .
> >                             |      .            .
> >      6. From step 3. _______:______.__          .
> >                             |         |         .
> >      7. From step 4. _______:_________:_________.__________
> >                             |         |                    |
> >      8. Binary 00...01 _____:_________:________            |
> >                             |         |        |           |
> >               
> ______________|_________|________|___________|__________
> >              |  local-address  | Subnet  |next field |      
> > branch     |
> >              |     Prefix      |  index  | Delimiter |       
> > Index     |
> >              |         P       |    S    |    D      |         
> > I       |
> >              |_________________|_________|___________| 
> > ________________|
> >              |<--------------- Branch Local address B 
> --------------- 
> > >|
> >
> >         DERIVING A BRANCH LOCAL ADDRESS FROM AN ENDPOINT GLOBAL  
> > ADDRESS
> >
> >                                  Figure 5
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 12]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > 3.5.  Privacy protection
> >
> >    In a zone where privacy protection is desired, the 
> privacy option  
> > can
> >    be turned on.  Principles of this option are the following:
> >
> >    o  Fields that identify branch-side IP endpoints in privacy  
> > protected
> >       zones, or transport endpoints if endpoints are at 
> this layer,  
> > are
> >       obfuscated in e2e packets that traverse the the 
> global Internet.
> >
> >    o  This obfuscation is stateless and reversible.
> >
> >    o  Branch SAMs of a privacy-protected zone are informed of  
> > parameters
> >       of this obfuscation.  They can thus know which "hidden"  
> > addresses
> >       (or addresses plus ports), appear on the global Internet in  
> > place
> >       of their "clear" addresses (or address plus ports).  
> These clear
> >       addresses are those from which local addresses are 
> derived in  
> > the
> >       privacy-protected zone and in zones that are lower in the
> >       hierarchy.
> >
> >    o  In these lower zones, all branch SAMs are informed 
> that a root  
> > SAM
> >       in the global-Internet direction has activated a 
> privacy option,
> >       and are informed of parameters of this option.  They can thus
> >       derive a clear address (or address plus port) from an 
> obfuscated
> >       address (or address plus port), and conversely.  They can also
> >       avoid to activate the privacy so that obfuscation is 
> never done
> >       more than once.
> >
> >    Parameters of a privacy option are a privacy global 
> prefix (PPm)  
> > and
> >    a scrambling multiplier (PMm).  The prefix is that which, at the
> >    beginning of global addresses, is not obfuscated in the global
> >    Internet.  The multiplier is a 64 bit odd constant.
> >
> >    Obfuscation consists in a modulo 2^n multiplication by the  
> > scrambling
> >    multiplier, where n is the number of bits to be obfuscated.  De-
> >    obfuscation is the modulo 2^n multiplication by the 
> inverse of the
> >    scrambling multiplier (for odd numbers, such an inverse 
> modulo 2^n
> >    always exists).
> >
> >    In hosts in which the branch SAM is informed of an active privacy
> >    option, applications that ask for their address and their port at
> >    their socket interface, get them in hidden form, that 
> which appears
> >    in the global Internet.  The e2e principle is thus preserved  
> > despite
> >    the fact that the topology of the privacy-protected zone 
> and that  
> > of
> >    lower zones in the hierarchy are all hidden, and despite the fact
> >    that successive transport connections from a same host 
> cannot, in  
> > the
> >    global Internet, be related to a single host.
> >
> >    Ports that are concerned with the privacy option are 
> only the IANA
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 13]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    defined dynamic and/or private ports (ports 49152 to 65535, those
> >    starting with binary 11).  Well known ports and registered ports,
> >    which have an e2e meaning not to be lost must not be obfuscated.
> >
> >    Since some applications, e.g. active mode FTP of 
> [RFC0959], work on
> >    port pairs rather than on individual ports, port bits to be
> >    obfuscated must exclude the las one.  Port bits that are part of
> >    obfuscated endpoint identifiers are then bits 2 to 14.
> >
> >
> >
> >                                             gY
> >                                              ^
> >                                              |
> >                                             ...
> >     e2e packet:              gZ11.F2.hhhh->gY [TCP hh->80 [data]]
> >                                              ^
> >                                              |
> >                                            gZkij         ROOT ZONE R
> >                   
> ___________________________:________________________
> >                  |(Z)             .--> (root  
> > SAM)                     |
> >     Privacy-option ON            /            
> > Rk                       |
> >     for prefix PP1 = gZkij.F1 ---'           ^          LOCAL ZONE  
> > Z  |
> >     with multiplier PM1                       
> > |                        |
> >                  |                            
> > |                        |
> >                   
> > |                          ...                       |
> >     encapsulated |   [ B->R [ gZkij.cccc->gY [TCP cc->80  
> > [data]]      |
> >        packet     
> > |                                                    |
> >                  |                            
> > ^                        |
> >                  |                            
> > |                        |
> >                  |                            
> > B                        |
> >                  | 
> > ___________________________:________________________|
> >                                         (branch SAM)
> >     Clear-address packet:        gZkij.F1.cccc->gY [TCP 
> cc->80 [data]]
> >     e2e packet:                  gZkij.F1.hhhh->gY [TCP 
> hh->80 [data]]
> >        where tmp = modulo 2^m (PM1 x (cccc . (bits 2 to 14 of cc))
> >                    where m = length of cccc + length of cc - 3
> >              hhhh = bits 0 to (length of hhhh - 1) of tmp
> >              hh = cc in which bits 2-15 are replaced by
> >                   bits(length of PP1 TO m - 1) of tmp .
> >
> >                            SAM PRIVACY OPTION ILLUSTRATION
> >
> >                                  Figure 6
> >
> >    Figure 6 illustrates the effect of the privacy option.  The  
> > option is
> >    supposed to be on, in the root SAM of the zone, for its global  
> > prefix
> >    gZkij and its identifier format F1.  The privacy-option prefix is
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 14]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    therefore PP1 = gZ11.F2. the scrambling multiplie ris PM1.
> >
> > 3.6.  SAM parameters
> >
> >    Table 3 to Table 5 of this section present the complete 
> set of SAM
> >    parameters described in previous sections.
> >
> >                       +-----------------------+-----+
> >                       | constant local Prefix | TTL |
> >                       +-----------------------+-----+
> >                       |          ...          | ... |
> >                       |           Pm          | PTm |
> >                       |          ...          | ... |
> >                       +-----------------------+-----+
> >
> >                         CONSTANT PREFIX PARAMETERS
> >
> >                                   Table 1
> >
> >    +--------------------+-----+------------------ 
> > +---------------------+
> >    |  identifier Format | TTL |   Subnet-index   |   Interface- 
> > index   |
> >    |        code        |     |      Length      |         
> > Length       |
> >    +--------------------+-----+------------------ 
> > +---------------------+
> >    |         ...        | ... |        ...        
> > |         ...         |
> >    |         Fn         | FTn |        SLn       |          
> > ILn         |
> >    |         ...        | ... |        ...        
> > |         ...         |
> >    +--------------------+-----+------------------ 
> > +---------------------+
> >
> >                        IDENTIFIER-FORMAT PARAMETERS
> >
> >                                   Table 2
> >
> >    +-----------------+-----+---------------+-----+--------------- 
> > +-----+
> >    |    Root local   | TTL | Global Prefix | ... | Global Prefix  
> > | ... |
> >    |     address     |     |       1       |     |       j        
> > |     |
> >    +-----------------+-----+---------------+-----+--------------- 
> > +-----+
> >    |       ...       | ... |      ...      | ... |      ...       
> > | ... |
> >    |        Ri       | RTi |      gZi1     | ... |      gZij      
> > | ... |
> >    |       ...       | ... |      ...      | ... |      ...       
> > | ... |
> >    +-----------------+-----+---------------+-----+--------------- 
> > +-----+
> >
> >                               ROOT PARAMETERS
> >
> >                                   Table 3
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 15]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                        +--------------------+------+
> >                        | Global zone prefix |  TTL |
> >                        +--------------------+------+
> >                        |         ...        |  ... |
> >                        |        gZij        | GTij |
> >                        |         ...        |  ... |
> >                        +--------------------+------+
> >
> >                          GLOBAL-PREFIX PARAMETERS
> >
> >                                   Table 4
> >
> >         +-----------------------+-----+---------------------------+
> >         | Privacy-option Prefix | TTL | Privacy-option Multiplier |
> >         +-----------------------+-----+---------------------------+
> >         |          ...          | ... |            ...            |
> >         |          PPp          | PTp |            PMp            |
> >         |          ...          | ... |            ...            |
> >         +-----------------------+-----+---------------------------+
> >
> >                          PRIVACY-OPTION PARAMETERS
> >
> >                                   Table 5
> >
> > 3.7.  Port-range-based extended IPv4 addressing
> >
> >    For a dual stack host not to break the e2e principle when it
> >    establishes a connection with an remote endpoint that is 
> still only
> >    reachable in IPv4, it must have a global IPv4 address.  
> Because of
> >    the IPv4 address shortage, this address may however be 
> shared with
> >    other hosts.  For this, SAM accepts "port-extended" IPv4 
> prefixes,
> >    longer than 32 bits.  Bits beyond the first 32 define a port  
> > range in
> >    the set of dynamic and/or private ports (those in which the two  
> > high
> >    order bits are binary 11).  For example, a 3-bit prefix 
> extension  
> > 010
> >    imposes that branch-side hosts use only ports starting 
> with binary
> >    11010.
> >
> >    Note that, due to the systematic encapsulation of global 
> packets in
> >    local packets of SAM, routing within SAM zones is not concerned  
> > with
> >    theses "port-extended" IPv4 addresses.  Only root SAMs and branch
> >    SAMs have to know about of port ranges.
> >
> >    The branch SAM in a host that is assigned a port-restricted IPv4
> >    address has to inform its socket interface of the port range
> >    available to applications, and to inform its internal 
> NAT if it has
> >    one.  Consequences for applications, and for NATs, of 
> restricted  
> > port
> >    ranges, are out of the scope of this SAM specification.  Other
> >    documents are available on the subject, e.g.  [Boucadair], which
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 16]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    however requires further study.
> >
> >
> > 4.  SAM Application examples
> >
> > 4.1.  Address independence in an IPv6 site
> >
> >    In the example of Figure 7, we consider a home or SOHO site in  
> > which
> >    an Ethernet and/or WiFi LAN is deployed.  Its global 
> IPv6 prefix gZ
> >    is 2001:0db8:9999::/48.
> >
> >    Local addressing is done in an IPv6 private space.  To 
> keep address
> >    shorts in the figure, the constant prefix of these addresses is
> >    fc00/8, the shortest prefix reserved for private IPv6 
> addressing in
> >    [RFC4193].  (This prefix could however be replaced by a 
> full fdxx:
> >    xxxx:xxxx::/48 prefix, as recommended in [RFC4193] for ULAs,  
> > without
> >    changing the substance of the example.)
> >
> >    The site is configured to support 255 branch interfaces 
> on the LAN
> >    (each branch being indifferently a host and/or a router).  To
> >    facilitate future changes, a branch-identifier format code F1,  
> > set to
> >    0/4, is used in branch global prefixes.
> >
> >    SAM parameters of the site are then following (ignoring TTLs):
> >
> >       Constant local prefix: P1 = fc00/8
> >
> >       Identifier format code: F1 = 0::/4
> >
> >       Subnet index length: SL1 = 0 (non applicable)
> >
> >       Interface index length: IL1 = 8
> >
> >       Root local address: R1 = fc00::0101
> >
> >       Zone Global prefix: gZ11 = 2001:0db8:9999::/48
> >
> >       Privacy option prefix: none in this example
> >
> >    We now consider a SAM-capable PC which serves as a router for a
> >    bluetooth link.  On this link, a bluetooth mobile phone 
> is active.
> >    (Configuring a root-SAM in the PC would permit the 
> mobile phone, if
> >    acting as a SAM-capable router, to assign global prefixes and
> >    addresses, to hosts behind it.  But this would have been 
> too much  
> > for
> >    the example).
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 17]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                                           |
> >                                           |
> >                                   2001:0db8:9999::/48
> >                          _________________:_________________
> >                         |(Z)       (root SAM) for 2^8 hosts |
> >                 Site    |            fc00::0101             |
> >                gateway  |                                   |
> >                         |                                   |
> >                         |            fc00::0155             |
> >                         |_________________:_________________|
> >                                           |
> >                  Ethernet and/or WiFi    ...
> >                       fcOO::/64           |
> >
> >                                       fc00::0155
> >                                      (branch SAM)
> >                              => +  2001:0db8:9999:0550::/60
> >                                 __________:__________
> >                                |2001:0db8:9999:0558::|
> >                PC              |                     |
> >                                |_____________________|
> >                               /___________._________/
> >                                           |
> >                   Bluetooth              ...
> >                2001:0db8:9999:0550::/64   |
> >                                           |
> >                             2001:0db8:9999:0550:< eui64 IID >
> >                                           |
> >                                         |_|__
> >                                        |     |
> >                Mobile phone            |     |
> >                                        |     |
> >                                        |_____|
> >
> >                                  Figure 7
> >
> >    The PC local address B is fc00::0155, i.e.  P.D.I where P is
> >    fc00::/8, where the 8 bits of I are supposed to be 55::/8, and  
> > where
> >    D is binary 00...01 with consequently (128 - 8 -8) = 112 bits.
> >
> >    The PC global prefix gB is therefore 
> 2001:0db8:9999:0550::/60, i.e.
> >    G.F.I, where G is 2001:0db8:9999::/48, where F is 0::/4, and  
> > where I
> >    is 55::/8.
> >
> >    The PC global address is therefore 
> 2001:0db8:9999:0558::, i.e. gB.E
> >    where E is binary 10...00 with (128 - 48 - 4 - 8) = 68 bits.
> >
> >    The bluetooth link is supposed to have 0::/4 as subnet 
> ID in the  
> > PC.
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 18]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    Its /64 subnet prefix is therefore 2001:0db8:9999:0550::/64.
> >
> >    This simple example illustrates how the SAM logic permits to
> >    establish a hierarchy of routing zones where each host 
> can become a
> >    router, and where the e2e principle is preserved.
> >
> > 4.2.  Multihoming and extended IPv4 addressing in a home site
> >
> >    In the example of Figure 8, we consider a home site S, multihomed
> >    with two ISPs A and B.
> >
> >    ISP A assigns to the site IPv6 prefix 
> 2001:1111:1111:1110::/60, and
> >    IPv4 address 192.0.2.1.
> >
> >    ISP B can only assign port-restricted IPv4 addresses to its sites
> >    because it has to support up to 2^16 sites, and has only 
> for this  
> > an
> >    IPv4 /18 prefix (namely 198.16.0.0/18, i.e. 
> v4|c610:0000:/18), and
> >    since 18 + 16 = 34 which exceeds 32.  Having 
> 2001:0db8::/32 as its
> >    IPv6 prefix, it assigns /48s to its customer sites, in particular
> >    2001:0db8:0202::/48 to site S.
> >
> >    Half of its IPv4 address space, namely v4|c608:c000/19 
> is allocated
> >    to a NAT to support sites that are not SAM capable.  The other  
> > half,
> >    i.e. v4|c610:2000/19, is allocated to a root SAM, the 
> local address
> >    of which is supposed to be 2001:0db8::1.
> >
> >    SAM parameters of the zone of ISP B are then the following:
> >
> >       Constant local prefix: P1 = 2001:0db8: = v4|a000::/8
> >
> >       Identifier format code: F1 = ::/0 (non applicable)
> >
> >       Subnet index length: SL1 = 0 (non applicable)
> >
> >       Interface index length: IL1 = 16
> >
> >       Root local address: R1 = 2001:0db8::1:1
> >
> >       Zone Global prefix: gZ11 = v4|c608:8000/19 (=198.8.128.0/19).
> >
> >       Privacy option prefix: none in this example (::/0)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 19]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                                                       198.16.0.0/18
> >                                 2001:0db8::/32       
> =v4|c610:0000:/18
> >                                   
> ____|__________________|____________
> >                                  |(B)             /             
> > \      |
> >                                  |               |    v4| 
> > c610:2000/19 |
> >                                  |          v4|c608:c000/19       
> > |    |
> >                                  |             (NAT)       (root  
> > SAM) |
> >                                  |         0.0.0.0/0      
> > 2001:0db8::1 |
> >      |(A)                     |   
> > |                                    |
> >      |                        |   
> > |                                    |
> >      |2001:1111:1111:1110::/60|  |   (2^16 SAM  
> > sites)                 |
> >      |       192.0.2.1        |   
> > |                                    |
> >      |      =v4|c000:0201/32  |  |       
> > 2001:0db8:0202::/48           |
> >      |________________:_______|  | 
> > ___________________:________________|
> >                       |                      (branch SAM)
> >                       |           => + v4|c610:2040:4000::/35
> >                       |              = 198.8.128.64/ports 11010...
> >       
> ________________:______________________________:________________
> >      |(S)     /               \               /               
> > \        |
> >      |       |     v4|c000:0201:0000::/33    |  v4| 
> > c610:2040:4000::/36|
> >      |       |                 ::/0          |                 ::/ 
> > 0   |
> >      | v4|c600:0201:8000::/33   |     v4|c608:2040:6000::/36     
> > |     |
> >      |     (NAT)            (root SAM)     (NAT)          (root  
> > SAM)  |
> >      |   0.0.0.0/0          fc00::0011    0.0.0.0/0        
> > fc00::0012  |
> >       
> > |                                                                |
> >      | (2^4 SAM  
> > hosts)                                                |
> >      |                         
> > fc00::0018                              |
> >      | 
> > _____________________________:__________________________________|
> >                                    |
> >            HOST (H)           (branch SAM)
> >                     => + 2001:1111:1111:1118:8000::0008/64
> >                        + 2001:0db8:0220:4800::0008/52
> >            + v4|c000:0201:4000::/37 = 192.0.2.1 ports 1101000...
> >            + v4|c610:2040:5000::/40 = 198.16.32.64 ports 
> 1101001000...
> >                                   :
> >                                   HOST
> >
> >        PRIVATE-ADDRESSING- AND DUAL-HOMING- SITE WITH E2E CAPABILITY
> >
> >                                  Figure 8
> >
> >    In site S, the branch SAM of its root interface with ISP 
> B derives
> >    from its IPv6 prefix 2001:0db8:O2O2::/48, and from SAM 
> parameters  
> > of
> >    ISP B, its IPv4 prefix v4|c610:2040:4000::/35, which is a port-
> >    restricted one.
> >
> >    Two root SAMs are configured in site S. Its 
> local-address constant
> >    prefix is fc00::/8 as.  Half of the each available IPv4 
> addressing
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 20]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    space is reserved for a NAT, and the other half for a root SAM.
> >
> >    Parameters of SAMs of site S are then the following:
> >
> >       Constant local prefix: P1 = fc00/8
> >
> >       Identifier format code: F1 = 0::/4
> >
> >       Subnet index length: SL1 = 0
> >
> >       Interface index length: IL1 = 8
> >
> >       Root local addresses: R1 = fc00::0011; R2 = fc00::0012
> >
> >       Zone Global prefixes: gZ11 = 
> 2001:1111:1111:1110::/60; gZ12 =  
> > v4|
> >       c000:0201/32; gz21 = 2001:0db8:0202::/48; gZ22 = v4|
> >       c610:2040:4000::/35
> >
> >       Privacy option prefix: none in this example (::/0)
> >
> >    Among the 16 hosts of home site S, Host H is supposed to 
> have local
> >    address fc00::0018.  As shown on the figure, the branch SAM of  
> > host H
> >    then derives from this local address two IPv6 global 
> prefixes, two
> >    IPv6 global host addresses starting with these prefixes, and two
> >    port-restricted IPv4 prefixes.  With these prefixes, it can use,
> >    without breaking the e2e principle, 512 ports for 
> connections via  
> > ISP
> >    A, and 64 ports via ISP B.
> >
> >
> > 5.  SAM as an alternative to NATs in IPv6
> >
> >    With SAM as specified, all NAT44 services that have been 
> listed in
> >    Section 2 can be offered in IPv6 without stateful processing and
> >    without breaking the e2e principle:
> >
> >    1.  In a private-addressing IPv6 site, hosts can know 
> their global
> >        addresses to use them in e2e packets that are encapsulated in
> >        local packets to traverse the site.  Renumbering is then
> >        automated simply by automating advertisement of SAM parameter
> >        changes (in DHCP and/or with router advertisements).
> >
> >    2.  The fact that NAT44s are in general configured with 
> by default
> >        rejection of all incoming calls can have a simple stateless
> >        equivalent in IPv6:
> >
> >        *  By default, reject all incoming packets that have 
> a branch-
> >           side port in the well known or in the IANA defined  
> > registered
> >           port ranges.
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 21]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >        *  By default, reject all TCP incoming packets that are  
> > attempts
> >           to open new incoming connections (SYN packets 
> without ACK).
> >
> >    3.  In a SAM-capable site, SAM-capable hosts can take 
> advantage of
> >        site multihoming with full compatibility with 
> ingress filtering
> >        of [RFC3704] in both the site itself and in ISP networks to  
> > which
> >        it is connected.
> >
> >    4.  The privacy protection described in Section 3.5 
> maintains the  
> > e2e
> >        principle.  It is expected to be largely sufficient in  
> > practice.
> >        (Sophisticated hackers would probably find ways 
> around it, and
> >        identify who does what in sites havin the privacy-protection
> >        option, but NAT44s are not perfect for privacy protection
> >        either).
> >
> >    5.  As we have seen, SAM global addresses contain a flexible
> >        succession of branch identifiers, so that it becomes 
> possible  
> > to
> >        set up a flexible hierarchy of private addressing zones.  In
> >        particular, host-rooted subnets become possible without  
> > breaking
> >        the e2e principle.
> >
> >    For information, no intellectual property right has been 
> applied  
> > for
> >    by the author on any of SAM mechanisms.  The intent is to  
> > facilitate
> >    IPv6 deployment with new mechanisms that still enhance its  
> > potential.
> >
> >
> > 6.  Security considerations
> >
> >    Like any function where some parameters have to be 
> configured, SAM
> >    introduces a risk of human errors.
> >
> >    Besides that, no security risk introduced by SAM has so far been
> >    identified.  In particular:
> >
> >    Provided consistency between local addresses present in  
> > encapsulating
> >    packets and global addresses present in encapsulated packets are
> >    systematic, no more address spoofing is possible than 
> without SAM.
> >
> >    Due to the stateless operation of SAM, its scalability is high.
> >    Prevention against denial of service attacks should therefore  
> > remain
> >    easy even for very intense traffic (e.g. using load balancers in
> >    front of parallel devices).
> >
> >
> > 7.  IANA Considerations
> >
> >    If and when this specification is stabilized and approved, option
> >    codes in DHCP, DHCPv6, and ND will have to be defined to
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 22]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    automatically convey SAM parameters to branch SAMs.
> >
> >
> > 8.  Acknowledgements
> >
> >    As this specification has evolved during many months, precious
> >    encouragement and remarks were received from Mark 
> Townsley.  He has
> >    to be warmly thanked for it.  Concerning what SAM can bring to  
> > port-
> >    restricted IPv4 addresses, stimulating discussions with Dan Wing,
> >    Teemu Savolainen, Gabor Bajko, Pierre Levis, Jean-Luc 
> Grimault, and
> >    Alain Villefranque, have influenced progress of the work.   
> > Gratitude
> >    is due to them for this.  Challenging remarks, and a few 
> (deserved)
> >    criticisms from Alain Durand have also helped to better 
> analyze how
> >    SAM will coexist with NATs.  He deserves credit for it.
> >
> >
> > 9.  References
> >
> > 9.1.  Normative References
> >
> >    [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., 
> Groot, G.,  
> > and
> >               E. Lear, "Address Allocation for Private Internets",
> >               BCP 5, RFC 1918, February 1996.
> >
> >    [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
> >               RFC 2131, March 1997.
> >
> >    [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.
> >
> >    [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
> >               Addresses", RFC 4193, October 2005.
> >
> >    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
> >               "Neighbor Discovery for IP version 6 (IPv6)", 
> RFC 4861,
> >               September 2007.
> >
> > 9.2.  Informative References
> >
> >    [6rd]      Despres, R., "IPv6 Rapid Deployment on IPv4
> >               infrastructures (6rd) - Work in progress
> >               (draft-despres-6rd-02)", October 2008.
> >
> >    [Boucadair]
> >               Boucadair, M., Grimault, J-L., Levis, P., and A.
> >               Villefranque, "Behaviour of BitTorrent 
> service in an IP
> >               Shared Address Environment
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 23]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >               
> (draft-boucadair-behave-bittorrent-portrange-02 - work  
> > in
> >               progress)", january 2009.
> >
> >    [LISP]     Farinaci, D., Fuller, V., Oran, D., Meyer, D., and S.
> >               Brim, "Locator/ID Separation Protocol (LISP) -
> >               draft-farinacci-lisp-09", December 2008.
> >
> >    [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
> >               STD 9, RFC 959, October 1985.
> >
> >    [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
> >               Discovery for IP Version 6 (IPv6)", RFC 2461,
> >               December 1998.
> >
> >    [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
> >               Translator (NAT) Terminology and Considerations",
> >               RFC 2663, August 1999.
> >
> >    [RFC3056]  Carpenter, B. and K. Moore, "Connection of 
> IPv6 Domains
> >               via IPv4 Clouds", RFC 3056, February 2001.
> >
> >    [RFC3286]  Ong, L. and J. Yoakum, "An Introduction to the Stream
> >               Control Transmission Protocol (SCTP)", RFC 3286, May  
> > 2002.
> >
> >    [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.
> >
> >    [RFC4219]  Lear, E., "Things Multihoming in IPv6 (MULTI6)  
> > Developers
> >               Should Think About", RFC 4219, October 2005.
> >
> >    [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.
> >
> >    [Shim6]    Nordmark, E. and M. Bagnulo, "Shim6: Level 3 
> Multihoming
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 24]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >               Shim Protocol for IPv6 - Work in progress
> >               (draft-ietf-shim6-failure-detection-09)", 
> October 2007.
> >
> >    [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.
> >
> >
> > Author's Address
> >
> >    Remi Despres
> >    3 rue du President Wilson
> >    Levallois,
> >    France
> >
> >    Email: [email-masked]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 25]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Full Copyright Statement
> >
> >    Copyright (C) The IETF Trust (2008).
> >
> >    This document is subject to the rights, licenses and restrictions
> >    contained in BCP 78, and except as set forth therein, the authors
> >    retain all their rights.
> >
> >    This document and the information contained herein are provided  
> > on an
> >    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
> > REPRESENTS
> >    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
> IETF TRUST  
> > AND
> >    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,  
> > EXPRESS
> >    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE  
> > USE OF
> >    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
> ANY IMPLIED
> >    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
> PARTICULAR PURPOSE.
> >
> >
> > Intellectual Property
> >
> >    The IETF takes no position regarding the validity or scope of any
> >    Intellectual Property Rights or other rights that might be  
> > claimed to
> >    pertain to the implementation or use of the technology 
> described in
> >    this document or the extent to which any license under 
> such rights
> >    might or might not be available; nor does it represent 
> that it has
> >    made any independent effort to identify any such rights.   
> > Information
> >    on the procedures with respect to rights in RFC documents can be
> >    found in BCP 78 and BCP 79.
> >
> >    Copies of IPR disclosures made to the IETF Secretariat and any
> >    assurances of licenses to be made available, or the result of an
> >    attempt made to obtain a general license or permission for the  
> > use of
> >    such proprietary rights by implementers or users of this
> >    specification can be obtained from the IETF on-line IPR  
> > repository at
> >    http://www.ietf.org/ipr.
> >
> >    The IETF invites any interested party to bring to its 
> attention any
> >    copyrights, patents or patent applications, or other proprietary
> >    rights that may cover technology that may be required to 
> implement
> >    this standard.  Please address the information to the IETF at
> >    [email-masked].
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 26]
> >
> > _______________________________________________
> > Behave mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave