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

[Dave Crocker <dhc@dcrocker.net>]

Pekka,

Many thanks for the comments.


PN> Well, HIP does demonstratably work with IPv4.

yes.  sorry for my confusion.


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

I assume the problematic applications are those that embed IP addresses in
them. What others are there?


PN> Actually, HIP is even slightly more ambitious here.  It aims
PN> to provide application interoperability between the IPv4 and
PN> IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
PN> to an IPv6 server,

I do not recall seeing the HIP specification call for IPv4/IPv6 packet
translation.  So I do not see how an IPv4-only host can talk with an IPv6-only
host, as a consequence of their both using HIP.  Where is this described in
the specification?

Hmmm.  Thinking a bit more, I think you mean IPv4 _application_, running on a
host that has IPv6, or vice-versa.  This would be expected to work because HIP
maps all address to a common type, from the perspective of the application.
(Sounds like a NAT between IP and Transport, doesn't it?)

When an application opens a connection by specifying the target's domain name,
I can see this working.  When the application does the DNS query and then
hands to address to TCP to do the open, there will be a problem, no?  The
application has to carry the address for a brief time.


PN> The base HIP specification expects very little administrative
PN> overhead.  Basically, what is needed is to store the host
PN> identifiers (or HITs) to the DNS.

HITs are a new, global name space.  Hence there needs to be a new, global
administrative structure for managing HIT assignments.


PN>   However, HIP is able to work
PN> even without them, in the opportunistic mode.

And that's where things get confusing for me.  If HIP works with
randomly-generated HITs, then why are globally-assigned ones needed?


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

PN> HIP explicitly uses "private IP addresses" within the stack, in order
PN> to help the kernel to differentiate between HITs/LSIs and normal
PN> IP addresses.

Yes, it does seem to take care of the different scenarios.  I must admit that
a scheme that calls for up to 3 different strings, to refer to the same thing
-- in addition to domain name and IP address(es) -- strikes me as rather
daunting.


PN> Some people have suggested that it might be possible to implement
PN> HIP in an external box and using the HITs/LSIs in the place of
PN> IP addresses even locally in the wire.

Note the MAST section called "MAST in NAT".  It occurred to me, too, that it
might be possible to hide all of this from the hosts on a subnet, by placing
all the functionality on an access gateway.


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

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

ok.


PN> To make reverse lookup work, some serious work is needed.

mumble.  yes.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>