Subject: RE: tunneling [Was: Agenda for Vienna]

From: "Tony Li" <[email-masked]>
Date: Tue, 20 May 2003 13:28:50 -0700

Meta note: if we're trying to talk architecture, I'd say that
dealing with the identifier/locator relationship is secondary.

Our primary discussion should be about alternatives to
"identifier/locator split" solutions.  That's clearly one
architecture, what are others that folks find credible?

Tunneling has certainly been mentioned.  I've always considered
this simply a mechanism for virtualizing the topology.  There's
effectively still a single address per host, so there's nothing
new in addressing.

Other directions?

Tony

|    -----Original Message-----
|    From: Iljitsch van Beijnum [mailto:[email-masked]] 
|    Sent: Tuesday, May 20, 2003 12:00 PM
|    To: Iljitsch van Beijnum
|    Cc: Erik Nordmark; [email-masked]
|    Subject: Re: tunneling [Was: Agenda for Vienna]
|    
|    
|    This message was supposed to go to my drafts folder but I 
|    must have hit 
|    send...
|    
|    On dinsdag, mei 20, 2003, at 17:14 Europe/Amsterdam, Iljitsch van 
|    Beijnum wrote:
|    
|    >> To do this compression would require some packet exchange to 
|    >> establish the
|    >> state thus for delay reasons it might in some cases 
|    make sense to be 
|    >> able
|    >> to start sending "uncompressed" packets in parallel 
|    with such state 
|    >> being
|    >> established.
|    
|    > I see three ways to do this. See the link to a draft I 
|    posted on this 
|    > list last week 
|    > 
|    (http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a
|    .txt) where 
|    > I tried to make this work with as little state as possible. The 
|    > destination identifier in packets to the server is 
|    implied, as the 
|    > server can map the locator address used to the 
|    identifier without 
|    > maintaining any per-session state. For the client 
|    address we can't do 
|    > this so I decided to encode the alternative prefix into 
|    the address in 
|    > addition to the regular prefix.
|    
|    Five ways. The above uses two different ones for servers 
|    and clients:
|    
|    1. Encoding the locators in the identifier
|    2. Looking up the mapping from the identifier to locators somewhere
|    3. Negotiate the mapping before communication happens 
|    (like the ISAKMP 
|    protocol does) but this requires some bootstrapping mechanism
|    4. Negotiate the mapping during session start
|    5. Send the packet and receive the mapping state if there is any
|    
|    I think the simple DNS approach is a good choice to start 
|    with unless 
|    depending on the DNS isn't acceptable. Option 5 could be a 
|    reasonable 
|    alternative if we decide we have to go with crypto (which 
|    I personally 
|    don't care for).
|    
|    But it's hard to know at this stage what the best approach is, and 
|    there probably isn't a single best approach. So what I'd 
|    like to see 
|    happen is that we select the simplest option as a default 
|    mechanism 
|    that everyone must implement, but keep the option open for 
|    the user to 
|    override this default behavior in a way that doesn't make the 
|    implementation too complex.
|    
|    This could solve the policy problem in enterprises. People running 
|    enterprise networks have told us they absolutely positively need 
|    mechanisms to implement traffic engineering and other 
|    policies and not 
|    depend on what any particular host decides is the best way 
|    to route a 
|    packet. With this hook in place hosts could run a daemon 
|    that asks some 
|    central servers about the mapping state and source/dest locator 
|    preference whenever a session is initiated to a 
|    destination for which 
|    there is no mapping state yet. (A stateless way to see if 
|    a destination 
|    is multihomed or legacy v4 would be good here.)
|    
|    This has the additional benefit that the dependence on the 
|    DNS isn't so 
|    bad anymore. Mapping information for known correspondents 
|    can be cached 
|    on local storage and periodically updated rather than 
|    resolved whenever 
|    the information is needed.
|    
|    >> And perhaps such state should be optional. It isn't 
|    likely to be 
|    >> harmful
|    >> when the tunnel endpoint is the host, but there might 
|    potentially be
|    >> scaling issues when the tunnel endpoint is some form of 
|    per-site 
|    >> proxy.
|    
|    We can make receiving stateless if we create our own mapping for 
|    sending and depend on return routability. This wouldn't 
|    lead to worse 
|    security problems than regular IP. So if we can make 
|    mapping from the 
|    identifier to the locator for sending stateless we're in stateless 
|    business.
|    
|    
|

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 May 2003 23:57:32 +0200

> dealing with the identifier/locator relationship is secondary.

I don't think we can make informed decisions about the architectural 
approach unless we know how well each approach is going to work out. 
That's why I keep going into detail.

> architecture, what are others that folks find credible?

Ok, let me list some solutions that have come up:

- mobility
- HIP
- source routing / conditional source routing
- controlled deaggregation
- backup path over second ISP using routing or tunnels
- address agile transports
- loc/id
- geo aggregation

I think the limitations of each have been discussed in the past. Some 
kind of more formal recap would probably be useful at this point. Kurt, 
is that what you want in your first proposed Vienna meeting or do you 
only want "active" solutions discussed there?

> effectively still a single address per host, so there's nothing

After some discussions on the ipv6mh mailinglist we reached the 
conclusion that rewriting the original source and destination addresses 
with something else at the source and then replacing the original 
addresses before the packet is processed at the destination is simply 
tunneling optimized for header size at the cost of some state. So I 
guess that makes the loc/id thing a dynamic version of tunneling...

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 08:14:44 +0300 (EEST)

> - controlled deaggregation

- controlled assignment of address space to a class of sites

> - address agile transports

HIP is a subset of loc/id, or maybe you mean a different kind of loc-id.
If you're using loc/id to refer to loc/id separation in the network, stop 
abusing the term to apply for that only.

> guess that makes the loc/id thing a dynamic version of tunneling...

The failure modes are entirely different with rewriting and tunneling.
Consider the case where the state is not fully shared with those who might 
would need it, and the requirements for the devices which must have the 
state.

Tunneling is a very simple thing for intermediaries, and a bit more for 
the end-points (a bit less than rewriting though).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 08:26:59 +0300 (EEST)

> effectively still a single address per host, so there's nothing

"Tunneling" is too generic a term here, and I don't know how you mean it.  
I think you refer to some host-to-host end2end automatic tunneling 
mechanisms..

> Other directions?

(I'm wondering how to say this without going too far into solutions, 
perhaps trying to abstract Iljitsch' list might be useful.)

1) caring for the small organizations
- use of multiple addresses, connection survivability optional
- multi-connecting

2) caring for the very large/international organizations
- having very large end-sites have their own address blocks
- requiring international endsites to get addresses for each region from a 
regional ISP (satisfies the traffic engineering requirements)

IMO, the biggest question seems to be whether we want to find a "magic" 
solution for large/larger end-sites.  Smaller ones are probably easier to 
cure rather easily.

It may also be prudent to consider which properties of multihoming are 
required for each scenario:

 - being able to switch ISP's without renumbering
 - redundancy due to link failures etc.
 - connection survivability (internal connections, external connections)
 - more fine-grained (ie. not 50/50) inbound traffic engineering
 - the maximum frequency of ISP (=prefix) changes
 - ...

but perhaps this is a bit too detailed yet.

---

From: marcelo bagnulo <[email-masked]>
Date: 21 May 2003 12:18:41 +0200

Hi, 

> - address agile transports

to my understanding multiple of the above solutions are based on the
loc/id separation

That is:
- mobility
- HIP

Are solutions based on the separation of loc/id roles. I mean all of
them use a fixed identifier for application layer and multiple locators
for routing (in this case in the end -hosts)

Moreover, i would say that all (host) multi-address solutions are based
on loc/id split concept when they attempt to preserve established
connections

- backup path over second ISP using routing or tunnels
This may also be considered a loc/id separation, sine an alternative locator is used to reach a final destination 
(so the original dest address plays the role of a locator)

However, i think that there is some fuzziness in this, so perhaps it would be interesting to have 
a more precise definition about what we are talking about when we use the loc/id split expression
I've tried but couldn't find any short definition that i liked...
Perhaps after we have a more precise definition we could ask for opinions and reach consensus more easily.  

So solutions not based on loc/id separation remaining are:

FWIW, i prefer the loc/id split approach (if this means what i think it does)

Regards, marcelo

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 13:34:09 +0300 (EEST)

> for routing (in this case in the end -hosts)

Agree.
 
> on loc/id split concept when they attempt to preserve established

Note that in all cases, preserving the connections may not be a 
requirement... the solution may be OK as is.
 
> (so the original dest address plays the role of a locator)

You could stretch the term, but I wouldn't do this: this requires zero 
changes in host stacks.  It's just a routing thing, while those mentioned 
above in loc/id require modifications.

> However, i think that there is some fuzziness in this, so perhaps it
> would be interesting to have a more precise definition about what we are
> talking about when we use the loc/id split expression I've tried but
> couldn't find any short definition that i liked... Perhaps after we have
> a more precise definition we could ask for opinions and reach consensus
> more easily.

Agree.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 May 2003 14:56:01 +0200 (CEST)

> dealing with the identifier/locator relationship is secondary.

It is secondary to the list of approaches the group wants to explore.
But in terms of understanding the implications of approaches that do
some split between identifiers and locators the form of
the identifier and how and when any mapping from ids to locators is
done is extremely important.

> architecture, what are others that folks find credible?

With my colored glasses I've seen these classes of ideas:
 - short term registry policy tweak to deal with perceived immediate
   problem (draft-kurtis-multihoming-longprefix-00.txt)

 - multiaddressing. Also rather short term; trying to make hosts
   with multiple addresses work better than they do today for
   multihoming purposes (draft-huitema-multi6-hosts-01.txt)

 - geographic addressing schemes (which don't seem to garner much support)

 - loose identifier/locator split
   (multiple ideas here)

 - strict identifier/locator split (multiple ideas here as well e.g. using
   HIP as one part of a solution)

Perhaps there are other classes I've missed.

I don't think we understand the issues for the last two classes in enough
detail to be able to generalize them to properties of the classes themselves.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 21:40:39 +0300 (EEST)

>    problem (draft-kurtis-multihoming-longprefix-00.txt)

I think the above mechanism proposes punching holes to current aggregates, 
not tweaking registry policy.  In that sense, it's dangerous.  A separate 
proposal to assign  e.g. PI /48's from RIR's might be useful to have on 
the table.

I think draft-savola-multi6-asn-pi-00.txt also belongs under this 
category.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 May 2003 10:34:21 +0200

On tisdag, maj 20, 2003, at 23:57 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

>  Kurt, is that what you want in your first proposed Vienna meeting or 
> do you only want "active" solutions discussed there?

I was thinking only about active proposals (read that have submitted 
drafts to the IETF and that haven't expired too long ago). Also, I was 
mostly looking at the actual proposals to be presented.

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 12:37:14 +0300 (EEST)

>    multihoming purposes (draft-huitema-multi6-hosts-01.txt)

Also ohta's proposal, which isn't short-term, of course.. but, still.

Btw, Erik, your mail is bouncing due to too many hops..