Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Dave,

[I defer my detailed comments on MAST until later, since I still
 haven't had time to *really* contemplate the proposal.]

Dave Crocker wrote:

> HIP and LIN6 are tied to IPv6 and involve notable enhancements to the
> Internet architecture.  Both seem pretty clean to me, architecturally.

Well, HIP does demonstratably work with IPv4.  There are three
implementations that support IPv4.  Our HIP implementation
even supports mobility between IPv4 and IPv6, today.

What HIP does not do that well is IPv4 API support.  That is,
while most current IPv4 applications will work just fine,
including the most common FTP scenarios, there are applications
and use cases where HIP may (mostly indeterministically) fail.

Actually, HIP is even slightly more ambitious here.  It aims
to provide application interoperability between the IPv4 and
IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
to an IPv6 server, and usually also vice versa.  Only if the
IPv4 client sends IP "addresses" over the application level
data stream, does the IPv6 server learn that its peer is
actually using IPv4 addresses.  However, if the IPv6 server
is able to handle these IPv4 "addresses", the "addresses" will be
mapped to the corresponding host identifiers inside the API,
if possible.  The case that apparently will not work is an IPv6 
application sending an IPv6 "address" to an IPv4 only application.

What comes to the architecture, yes, HIP basically presents an
architectural enhancement.  However, we expliclitly try to
avoid the amount of necessary changes, and restrict them
to the end nodes.

> The other issue is administrative overhead. MAST does not create any 
> interesting administrative load HIP and LIN6 impose some significant
> new administration. MAST currently involves none.

The base HIP specification expects very little administrative
overhead.  Basically, what is needed is to store the host
identifiers (or HITs) to the DNS.  However, HIP is able to work
even without them, in the opportunistic mode.  In that sense,
HIP can be deployed without any administrative overhead, if
so desired.

> I think that comparison of HIP, LIN6 and MAST will be helpful.   There
> are some pretty interesting differences among them.  I'm planning on
> doing something more detailed, but for now:

I would be very glad to see such a comparison.

> 1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP
> savant will tell me of any errors, so I can fix them.

I think that you have got it mostly right in the proposal, but
I haven't had time to think of all the details.  OTOH, I tried
to offer some corrections above, some comments below.

> By contrast, MAST introduces *no* new addresses on the wire.  New
> addresses within the end-nodes are not required, though internal use
> of private IP addresses is discussed as an implementation choice.

HIP explicitly uses "private IP addresses" within the stack, in order
to help the kernel to differentiate between HITs/LSIs and normal
IP addresses.  However, that is an implementation detail, and most
probably one could build an HIP implementation that does not do that.
However, given that HIP introduces a new name space, I don't see
any reason for trying to mix the name spaces.  The applications
won't be any happier, since HITs are not IP addresses, even if they
do look like ones.

Some people have suggested that it might be possible to implement
HIP in an external box and using the HITs/LSIs in the place of
IP addresses even locally in the wire.  While there may be some
value in the the proposal, I personally don't like it.

> 3. The LIN6 specification also provides for the rendezvous function,
> using DNS, which MAST chooses to defer. 

We have removed rendezvous from the HIP base specifications, and
plan to address is separately for first time rendezvous
(using DNS) and for mobility (new infrastructure).

SD> - One HIP issue I've wondered about, but have not mentioned in
SD>   public, is how an application might make of "whatever it THINKS
SD>   is the IP address" (because a mobile address/identifier looks
SD>   like any other address). What happens if an application expects
SD>   to do a reverse DNS lookup of a HIP HI, for instance?

Right now, if an application attempts to do a reverse DNS lookup
on a HIP HIT or LSI, that will fail.

To make reverse lookup work, some serious work is needed.  For LSIs,
the DNS library needs to convert them to HITs, and then try to do
reverse lookup of the HITs.   What comes to HITs, the issue is
still open, with proposals ranging from using the first bits in a
HIT to identify an assigning authority to using distributed hash
tables.

--Pekka Nikander