[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dave Crocker wrote: 
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?


There are two classes of IPv4 applications that will have problems
with HIP:

 1. Applications that embed addresses in application datagrams,
    e.g., FTP and SIP.  These will mostly work, but will in some
    fairly rare corner cases fail, sometimes "mysteriously".  (With
    "mysteriosly" I mean that the user is likely to be confused.)

 2. Applications that interpret the structure of IP addresses and
    try to understand it.  Many of these will work, too, since
    HIP LSIs look like vanilla IPv4 unicast address from 1.0.0.0/8
    subnet.

As far as I can see, all other IPv4 applications should just work.

What comes to IPv6 applications, the probability of the above
mentioned "mysterious" failures becomes so low that it can be
safely ignored.  (Less than the probablity of randomly picking
a given atom in the universe, or in the order of 2^-250.)  On the
other hand, administrative applications that do interpret the
structure of IP addresses probably need to be updated.

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?


If you have a HIP aware IPv4-IPv6 NAT box, why not?  Such a
NAT box just NAPTs the IP headers, leaving the ESP and its
content untouched.  (No, this has not been explicitly defined
in the specifications yet, but it should be fairly trivial.  See also
http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-nat-00.txt )

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.

Exactly. See draft-moskowitz-hip-07.txt, Section 3.5.

(Sounds like a NAT between IP and Transport, doesn't it?) 

Well, one view to HIP is that HIP contains a specialized form of
Bellovin's HostNAT.  See also
http://www.tml.hut.fi/~pnr/BEET/draft-nikander-esp-beet-mode-00.txt
(Another draft that I haven't submitted yet.)

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.


When an application does a DNS query, it gets an LSI or a HIT as
a result.  An easy change to the DNS library.

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

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


There are two types of HITs.  The randomly generated ones are those
that are specified in the current base spec.  A previous version of
the base spec also defined globally-assigned ones, but that has been
moved to a future specification due to dependencies with the DNS.
The base specification only contains a placeholder for the
globally-assigned ones.

I have to admit that I don't really remember the reason for having
globally-assigned ones.  Bob should be able to answer, though.
(Here I will just carry on Bob's ideas and make sure that
the HIP-DNS spec will define the globally-assigned ones in
a precise enough way.)

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


Sometimes you have to pay a price for backwards compatibility.  I have
a student working on a native AF_HIP socket API.

--Pekka Nikander