tunneling [Was: Agenda for Vienna]

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

> I don't care much for tunnels. Now if they would really solve anything 
> I guess I could live with another wasted 40 bytes per packet but I 
> don't think they do as you can't trust any information in the inner 
> header. So either you need crypto or you check the inner header against 
> know information. But if you knew in the first place, why add the 
> header...?

I'm thinking more at a conceptual level where tunneling implies
that a packet logically injected by the "identifier layer"
on one node with source and destination being identifiers 
and being tunneled (by putting it in an IP packet with 
source and destination being locators) to the "identifier layer"
unmodified.
Thus conceptually it is wrapped in an IP packet and then unwrapped.

This doesn't prevent optimizations like avoiding an extra IP header
when it is known that the receiver can map from the pair of
locators in the packet to the pair of identifiers.
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.

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.

So I don't mind avoiding 40 useless bytes either.

  Erik