Re: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01

On Thu, 9 Aug 2007, Miika Komu wrote:

Hi Jeff,

> On Mon, 6 Aug 2007, Ahrenholz, Jeffrey M wrote:
>
> Replying on multiple posts in a single mail...
>
>> Comments on comments...
>>
>>> This is supported also in the DNS extensions, so why not in
>>> the DHT? Is there are a need to constrain the experimentation?
>>
>> It seems like you are thinking of the DHT as a DNS replacement. Without
>> looking back at the DNS draft (RFC).
>
> Yes in the sense that the OpenDHT should support same things as HIP DNS
> extensions. No in the sense that I think that DNS stuff is most useful for
> servers and OpenDHT stuff for (p2p) clients.
>
>> For the DHT, I was thinking more of bootstrapping, where you have the
>> HIT (or domain name) and you only need to find most current, usable
>> address.
>>
>> Constraint was not the intent, but rather simplicity.
>
> How do you detect the most current, usable address on behalf of a remote
> host? This is not so simple especially in NATted environments.

We had some further discussions on OpenDHT with Samu: one obvious, but forgotten item is also IPv4-IPv6 interoperability. None of the draft suggests only a single locator, but should it be IPv4 or IPv6? I think multiple addresses in DHT would be very useful.

> > I guess the current DHT draft does even not distinguish RVS
> > addresses from end-host addresses. This should be fixed because it is
> > supported also in the DNS extensions. Of course, there should be
> > "room" for new type of
> > middleboxes that are required e.g. for NAT traversal.
>
> It seems like the DHT draft should just reference the HIP DNS RR format.

Following the DNS format could also reduce some lines of parser code if someone glues OpenDHT libraries to local DNS proxy software or resolver libraries. However, following the DNS format requires an additional lookup to find the RVS. According to Samu, the OpenDHT look-up latency is already at least twice as long as DNS in practice according to Samu.

Alternatively, we could save the few lines of parser code by reusing the HIP LOCATOR format. However, the mm-05 draft does not set a flag for RVS locators, so I guess it assumes that the RVS address is always found from DNS (which is not the right assumption IMHO).

-- 
Miika Komu                                       
http://www.iki.fi/miika/
_______________________________________________
Hipsec-rg mailing list
Hipsec-rg@listserv.cybertrust.com
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg