Re: tunneling [Was: Agenda for Vienna]

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

My gut feel is that it is too early to choose a mechanism. But studying
the different possible mechanisms (such as using DNS) to determine what impact
that has on the architecture is a very good thing.

I suspect there are two different ways to do this using DNS:
1. It is possible to lookup both identifier and locators based on a DNS
   name, but the DNS doesn't have a mapping from identifier to locators.
   1a. Perhaps the DNS could have a reverse mapping from locators to DNS names
       aka ip6.arpa as today.
2. The DNS also has a mapping from identifiers to locators.
   Presumably this means that the identifiers must be delegated on some 
   hiearchical boundaries.


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

There is a difference between soft-state and hard-state.
I've been silently assuming that any tunnel endpoint/receiver state would
be soft i.e. have similar behavior as the mobile IPv6 state used
when handling the Home Address Option - if there is no state (due to state
loss) and error saying "please update my state" goes back to the sender.
(The ZOD draft by Glenn Morrow was an example of how to do this with
no packet overhead. Perhaps robustness would be better if there is at
least a "generation" number in the header to be able to detect stale state.)

Such a soft-state approach allows there to be multiple independent tunnel 
endpoints (useful e.g. when the site border runs this during transition)
by dynamically being able to discover the state when packets arrive.

But potentially having such soft-state might use up a lot of memory
on the border - this is something we need to understand more.

  Erik