RE: HIP draft

["Henderson, Thomas R" <thomas.r.henderson@boeing.com>]

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
> Sent: Sunday, February 01, 2004 1:02 PM
> To: Multi6 List
> Subject: HIP draft
> 
> 
> On 25-jan-04, at 16:59, Brian E Carpenter wrote:
> 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt
> 
> Ok, I'm missing two things here:
> 
> 1. Failover. The draft says the wg should come up with this. Ok.

I assume you mean path failure detection.  This seems to me to be
a transport layer issue, although a local interface failure could
be detected below the transport layer.  Coupling between HIP and 
transport layers is presently unspecified.  

> 
> 2. What mechanism makes it possible for unmodified ULPs to set up 
> connections to HIP-capable destinations? I would expect either the 
> application to be modified so it knows to ask for the HIP DNS RR, or 
> there must be some shady resolver hacks that trick the app 
> and TCP (or 
> other ULPs) so they think they're dealing with a regular IPv6 address 
> but in effect they're using HIP identifiers and the associated IP 
> addresses are recovered at the HIP layer.
> 

See Appendix A in the HIP draft specification for a discussion on this
issue.  Both approaches you mention have been considered, as well as
the inverse case of your last approach that keeps the application, resolver, 
and sockets API unmodified (still using IP addresses) but replaces the 
IP addresses in-kernel with HITs.
http://www.ietf.org/internet-drafts/draft-moskowitz-hip-08.txt

> And would it be possible to implement HIP in middleboxes so that 
> unmodified hosts can talk to HIP boxes?
> 

There have been some informal discussions about this.  This would 
probably be a topic for the proposed research group.

Tom