Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02 enclosed
"Dan Wing" <dwing@cisco.com> Tue, 17 March 2009 01:51 UTC
Return-Path: <dwing@cisco.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863F93A6804; Mon, 16 Mar 2009 18:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.925
X-Spam-Level:
X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFmd-CNgdCK7; Mon, 16 Mar 2009 18:51:34 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 94B673A6452; Mon, 16 Mar 2009 18:51:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="156736965"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2009 01:52:16 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2H1qGxE015253; Mon, 16 Mar 2009 18:52:16 -0700
Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2H1qExb005885; Tue, 17 Mar 2009 01:52:14 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Margaret Wasserman' <mrw@lilacglade.org>, 'Rémi Després' <remi.despres@free.fr>
References: <49BA2DD6.8080001@free.fr> <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org>
Date: Mon, 16 Mar 2009 18:52:14 -0700
Message-ID: <001101c9a6a2$ff0acb20$c2f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmmlT9aq9s0NxBOSZ+iCQq2e8QfywADS/oQ
In-Reply-To: <96B651AC-8244-44DF-8937-2FB79C119B49@lilacglade.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=74561; t=1237254736; x=1238118736; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[BEHAVE]=20FYI=3A=20draft-despres-sam-0 2=20=20enclosed |Sender:=20; bh=pfaaVsWar6nrhYNKeJHo0K+aMbCVNH24+NAx+pUYV8A=; b=gpCg+cL6Srg4Gh5PNSSBop0c50HHaBRVCt8ht4ZyhJQ0BaLm6vCYCq2vik YTQM8ilOvdIfCMmfN0aP1Q/1nq72CVMysm7SSmT+gvYbcNhHQxZpSInQ5Xm7 kpKg6BZNmF;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Mailman-Approved-At: Tue, 17 Mar 2009 16:20:19 -0700
Cc: 'Softwires WG' <softwires@ietf.org>, 'Internet Area' <int-area@ietf.org>, 'Behave WG' <behave@ietf.org>, nat66@ietf.org
Subject: Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02 enclosed
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: nat66@ietf.org
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2009 01:51:47 -0000
> -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] 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 (nat66@ietf.org > ). 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 nat66@ietf.org 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: remi.despres@free.fr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > ietf-ipr@ietf.org. > > > > > > > > > > > > > > > > > > > > > > > > Despres Expires May 5, 2009 > [Page > > 26] > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave
- Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02… Rémi Després
- Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02… Brian E Carpenter
- [Int-area] FYI: draft-despres-sam-02 enclosed Rémi Després
- Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02… Margaret Wasserman
- Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02… Dan Wing