Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna])

[Iljitsch van Beijnum <iljitsch@muada.com>]

On donderdag, mei 22, 2003, at 06:51 Europe/Amsterdam, Pekka Savola 
wrote:

> > I don't really want to use the words "long term" as that might make
> > people think there is no point in working on it / waiting for it. But
> > it should solve the problem rather definitively, so in that sense it 
> > is
> > long term. [...]
> I disagree: I don't think loc/id, a solution like HIP for instance, 
> would
> solve the whole problem.  Care to elaborate?
Elaborate why you disagree? That's going to be hard...

Multihoming works by having two or more valid paths through the network 
between two hosts. (Valid = no administrative blocks, just having some 
wire isn't enough, you must also be able to route over it.) Then if one 
path disappears, the communication continues over the other. If we 
can't have routing take care of this switch, the most obvious way is to 
have different addresses that are each tied to a path. But then we're 
changing addresses in mid-session, which our transport protocols can't 
handle. Enter the loc/id separation: the transport protocols and 
applications get a stable identifier to work with, but we get to change 
the underlying locator when there are outages. Assuming we take care of 
details such as how outages are detected and how the 
locator<->identifier mapping is set up, this should solve the 
multihoming problem once and for all.

Locator/identifier separation is also very useful if we want to 
implement a new namespace. Loc/id in itself doesn't require a new 
namespace. Either locators and identifiers can overlap (i.e., any IPv6 
address can be either or even both) or we split the IPv6 address space 
in two, with parts for both purposes. This is mostly a deployment 
tradeoff.

About HIP. I've been reading the new architecture document. It seems it 
pretty much does the whole loc/id thing, although it doesn't really 
mention failover. The problem however is that HIP does much more than 
just multihoming. Maybe there is some synergy between multihoming and 
mobility, but I don't see the advantages of leaping multihoming, 
mobility and encryption on one big pile. In the end, that's going to 
mean you're going to do at least one of those not very well.

And then there is simple economics: how are you going to convince 
someone who multihomes in IPv6 to switch to IPv6 and then adopt HIP to 
retain multihoming functionality? This means lots of additional 
expenses because of the crypto hardware (if you can't do line rate 
crypto you're a sitting duck for crypto DoS) and the additional 
bandwidth for all the extra headers. Don't think it's so bad? I think 
it is. The HIP header is at least 40 bytes. Then you need ESP, which is 
at least 8 bytes (probably more like 16), an initialization vector and 
padding. But of course just encrypting isn't enough, you really should 
be doing authentication as well... Ignoring that for a moment the total 
is 64 - 95 bytes when using a block cipher with 16 byte blocks. This 
makes a TCP ACK 136 bytes. In plain IPv4 it's only 40 bytes... The 
average pacet size is typically around 500 bytes. With HIP and IPv6 
adding some 92 bytes, this eats away 16% of the available bandwidth.

On a related note, I've been thinking about ways to do something about 
all this outrageous overhead but being able to have some per-packet 
additional info at the same time. It occurs to me that much of the 
stuff we're thinking about putting in each packet really doesn't have 
to be in _each_ packet. Having identifiers and such in every 32th 
packet or once every 5 seconds or so should be more than enough.