RE: tunneling [Was: Agenda for Vienna]

["Tony Li" <Tony.Li@procket.com>]

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:iljitsch@muada.com] 
|    Sent: Tuesday, May 20, 2003 12:00 PM
|    To: Iljitsch van Beijnum
|    Cc: Erik Nordmark; multi6@ops.ietf.org
|    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.
|    
|    
|