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

From: Rémi Després <[email-masked]>
Date: Tue, 17 Mar 2009 09:39:13 +0100

Margaret Wasserman  -  le (m/j/a) 3/17/09 1:13 AM:
>
> 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]).  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?  There doesn't appear to be an agenda online for 
> the 6AI BOF yet, so I am not sure if it will be included.
I started with the NAT66 mailing list, and only followed with WG lists.
See also Dan's answer.
>
> (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?
Routing within the site is based on local addresses, e.g. ULAs.
That's only in SAM-capable CPEs and in SAM-capable hosts that, knowing 
SAM parameters, global-address packets can be encapsulated in 
local-address packets.
> (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?

Thanks for the remark.
There should be a reference, e.g. to RFC 1958.
What is meant is IP-layer network transparency, e2e.
Addresses and ports that are seen by two communicating applications must 
be the same at both ends.

> 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.
With SAM, hosts know their global addresses, and can use them, e.g. with 
SCTP or Shim6.
In my understanding, this is a difference (an an important one).

Regards,

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Mar 2009 10:37:33 +1300

(Cross posting dropped. This is an Area kind of comment.)

> Margaret Wasserman  -  le (m/j/a) 3/17/09 1:13 AM:

...
> be the same at both ends.

That is not what RFC1958 and RFC3724 mean by the end to end principle.
The e2e principle is not the same thing as e2e address transparency.
There's an explicit attempt to separate different e2e issues in RFC2775,
and there's further discussion in RFC3234, which says

>>    We conclude that:
>> 
>>       Although the rise of middleboxes has negative impact on the end to
>>       end principle at the packet level, it does not nullify it as a
>>       useful or desirable principle of applications protocol design.
>>       However, future application protocols should be designed in
>>       recognition of the likely presence of network address translation,
>>       packet diversion, and packet level firewalls, along the data path.

> In my understanding, this is a difference (an an important one).

That depends on the extent to which applications follow the recommendation
from RFC3234 quoted above, and to what extent we succeed in separating
out the concepts of identifier and locator. I don't disagree that
explicit knowledge of the global addresses in use is useful, but it's
a tool, whereas the e2e principle is ... a principle.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 13 Mar 2009 10:56:38 +0100

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/softwire-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]

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 16 Mar 2009 20:13:10 -0400

Hi Remi,

(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] 
).  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?  There doesn't appear to be an agenda online for the 6AI BOF  
yet, so I am not sure if it will be included.

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:

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
>
> In San Francisco, its part that deals with NAT66 avoidance is to be  
> discussed at the 6IA BOF meeting (ex NAT66).
>      2.4.  Privacy  
> protection . . . . . . . . . . . . . . . . . . . .  4
>      2.5.  Host-rooted  
> subnets  . . . . . . . . . . . . . . . . . . .  5
>    3.  SAM  
> specification  . . . . . . . . . . . . . . . . . . . . . .  5
>      3.5.  Privacy  
> protection . . . . . . . . . . . . . . . . . . . . 13
>      3.6.  SAM  
> parameters . . . . . . . . . . . . . . . . . . . . . . 15
>    4.  SAM Application  
> examples . . . . . . . . . . . . . . . . . . . 17
>    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
>     Root interfaces:          
> _________:_______________________:________
>                             |(Z)   (root-SAM)              (root- 
> SAM)  |
>             Ri               
>                             |                SAM ZONE  
> Z                |
>             Bk               
> |      :                :             :    |
>     Branch interfaces:      | 
> ______:________________:_____________:____|
>                                    |                |             |
>                                 |(Z)       (root  
>                                 |              R         LOCAL ZONE  
> Z |
>          *B = la(gX)*           |      [  B->R [gX- 
> >gY[data]]         |
>          *R = parameter*        |               
> ^                      |
>                                 |               
> |                      |
>                                 |               
> B                      |
>                                 | 
> ______________:______________________|
>                                 |(Z)       (root- 
>                                 |              R         LOCAL ZONE  
> Z |
>    (2)  encapsulated packet:    |     [ B1->B2 [gE1- 
> >gE2[data]]       |
>         *B1 = la(gX)*           |         -------- 
> >--------           |
>         *B2 = la(gY)*           |       /                    
> \         |
>                                 |      ^                      
> |        |
>                                 |      |                      
> v        |
>                                 |      B1                     
> B2       |
>                                 | 
> ______:_____________________:________|
>              |<-------------- Branch global address gB@ ------------- 
> >|
>              |<-------- Branch global prefix gB -------- 
> >             |
>              |<-- G --><-----  Branch identifier iB ---- 
> >             |
> (10...00)  |
>              |    G    |   F  |    S    |        I       |      
> H      |
>                            <-- s --->                 <----- i ------ 
> >|
>              |       P     |    S    |      D        |         
> I       |
>              |<-------------- Branch local address B ---------------- 
> >|
>
>
> gE                         |
> ________________________________________________________|
>                            (A) ANALYSIS    ||
>                                            \/
>              |    G    |   F  |    S    |        I       |      
> E      :
>              |         P       |    S    |    D      |         
> I       |
>              |<--------------- Branch Local address B --------------- 
> >|
>
>     Privacy-option ON            /            
> Rk                       |
>     with multiplier PM1                       
>        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]]
>    |         ...        | ... |        ...        
>    |         Fn         | FTn |        SLn       |          
> ILn         |
>    |         ...        | ... |        ...        
>    |     address     |     |       1       |     |       j        
>                                  |(B)             /             
> \      |
>                                  |               |    v4| 
> c610:2000/19 |
>                                  |          v4|c608:c000/19       
>                                  |             (NAT)       (root  
>      |(A)                     |   
>      |       192.0.2.1        |   
>      |(S)     /               \               /               
> \        |
>      |       |                 ::/0          |                 ::/ 
> 0   |
>      | (2^4 SAM  
> hosts)                                                |
> fc00::0018                              |
> _____________________________:__________________________________|
>                                    |
>            HOST (H)           (branch SAM)
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

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

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

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

-d

> > Its part that deals with Port-Range extension, is to be 
> discussed at  
> > the SHARA BOF.
> >
> > Comments most welcome.
> >
> > Regards,
> >
> > RD
> >
> >
> >
> >
> >
> >
> > Internet-Draft                                             
> November  
> > 2008
> >    and may be updated, replaced, or obsoleted by other 
> documents at  
> > any
> >    different address space.  With it, the end-to-end 
> principle, lost  
> > in
> >    local-address packets to traverse SAM zones, and global 
> prefixes  
> > are
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Table of Contents
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >          states.  Negative consequences include limited 
> scalability,  
> > and
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    (This conclusion needs however to be confirmed after 
> further work  
> > on
> >    nodes, but have the drawback of breaking the e2e 
> principle, with  
> > the
> >    With NAT44s, when a prefix assigned by an ISPs to a 
> customer site  
> > is
> >    an ISP access fails, current TCP and UDP connections 
> that go via  
> > this
> >    difficult to determine which hosts establish which 
> connections.   
> > This
> >    level of privacy protection, in particular for some web 
> requests,  
> > is
> >    an added value.
> >
> >
> >
> >
> >
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > 2.5.  Host-rooted subnets
> >
> >    zone" Z. Routing within this zone is independently 
> administered,  
> > and
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                                          ROOT-SIDE ENDPOINTS
> >                                       |         /\            |
> >                                       |         ||            |
> >                                 |_____:_____|   ||     
> |______:_____|
> >                                       |                       |
> >                                       |      ROOT ZONES       |
> >                                       |                      gZ22
> >    hierarchy A, B, C, it has at least gA.aB.bC.cD as a 
> global prefix  
> > gD,
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >                                 |              R         
> LOCAL ZONE  
> BRANCH ZONE B
> >      PACKET ENCAPSULATION AND ADDRESS MAPPING - BRANCH SIDE 
> TO ROOT  
> > SIDE
> >
> >                                  Figure 2
> >
> >    into local address packets, as illustrated in Figure 2 
> and Figure  
> > 3).
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    spoofing mechanism.
> >
> >
> >                                                |
> >                                                |           ROOT ZONE
> >                                               gZ
> >                                  
> >                                 |              R         
> LOCAL ZONE  
> >    ADDRESS MAPPING AND PACKET ENCAPSULATION - BRANCH SIDE 
> TO BRANCH  
> > SIDE
> >
> >                                  Figure 3
> >
> >        prefixes of the zone.  Then, the local address B is 
> obtained  
> > by a
> >        function B=la(gX), completely determined by SAM 
> parameters of  
> > the
> >
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >        branch-side endpoint (otherwise the packet would not 
> traverse  
> > the
> >    that local addresses present in headers of encapsulating 
> packets  
> > are
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> ------------- 
> ---------------- 
> >        (The word "index" is chosen to express that these 
> fields have  
> > no
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 10]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >        have to be in the upper part of local addresses, 
> just behind  
> > the
> >        "constant prefix" (P) that is common to all local 
> addresses.   
> > (In
> >        interface index I, and for this to know their 
> lengths (s and  
> > i).
> >
> >    length of 1 bit, is chosen so that knowing the constant 
> prefix P  
> > and
> >    Detailed steps by which a branch local address B is 
> derived from  
> > from
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 11]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >               
> --------------- 
> > 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
> >       zones, or transport endpoints if endpoints are at 
> this layer,  
> > are
> >       addresses are those from which local addresses are 
> derived in  
> > the
> >    o  In these lower zones, all branch SAMs are informed 
> that a root  
> > SAM
> >    Parameters of a privacy option are a privacy global 
> prefix (PPm)  
> > and
> >    the fact that the topology of the privacy-protected zone 
> and that  
> > of
> >    that successive transport connections from a same host 
> cannot, in  
> > the
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 13]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 14]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 15]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    order bits are binary 11).  For example, a 3-bit prefix 
> extension  
> > 010
> >    one.  Consequences for applications, and for NATs, of 
> restricted  
> > port
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 16]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    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
> >    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
> >
> >
> >    because it has to support up to 2^16 sites, and has only 
> for this  
> > an
> > 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
> >                                   
> >    from its IPv6 prefix 2001:0db8:O2O2::/48, and from SAM 
> parameters  
> > of
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 20]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >       Zone Global prefixes: gZ11 = 
> 2001:1111:1111:1110::/60; gZ12 =  
> > v4|
> >    without breaking the e2e principle, 512 ports for 
> connections via  
> > ISP
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 21]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    4.  The privacy protection described in Section 3.5 
> maintains the  
> > e2e
> >        succession of branch identifiers, so that it becomes 
> possible  
> > to
> >    For information, no intellectual property right has been 
> applied  
> > for
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 22]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >    [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., 
> Groot, G.,  
> > and
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 23]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> >               
> >    [RFC4864]  Van de Velde, G., Hain, T., Droms, R., 
> Carpenter, B.,  
> > and
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 24]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 25]
> >
> >
> > Internet-Draft     Stateless  Address  Mapping  (SAM)      
> November  
> > 2008
> >
> >
> > Full Copyright Statement
> >
> >    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
> IETF TRUST  
> > AND
> > Despres                    Expires May 5, 2009              
>    [Page  
> > 26]
> >