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.
Yes, this is a good way of looking at it.
This doesn't prevent optimizations like avoiding an extra IP headerI 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.
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