[hipl-users] Re: More questions about RVS and hipdnsproxy

  • From: Robert Moskowitz <rgm@xxxxxxxxxxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Fri, 8 May 2009 13:57:38 -0400


Miika Komu wrote:
Robert Moskowitz wrote:

Hi,

Miika earlier pointed out that hipdnsproxy returns the HIT in place of the IPv6 address to legacy apps so that HIP works with them (or LSIs in place of IPv4 addr). This makes sense.

Ok.

Then along come HIP aware apps, like 'hipconf add rvs server <rvs server fqdn>'

So I run 'hipconf add rvs server oqo3.htt' without hipdnsproxy running, and it works fine. Now if I run it with hipdnsproxy I see:

[root@oqo2 ~]# service hipdnsproxy start
Starting : [ OK ]
[root@oqo2 ~]# cat /etc/resolv.conf
# This is written by dnsproxy.py
nameserver 127.0.0.53
[root@oqo2 ~]# ./rvsup
Opportunistic mode or direct HIT registration
addr: 1.0.0.2
addr: 1.0.0.2
addr: 1.0.0.2
addr: 2001:0011:ef9c:a0ae:8bbb:478a:7425:e912
addr: 2001:0011:ef9c:a0ae:8bbb:478a:7425:e912
addr: 2001:0011:ef9c:a0ae:8bbb:478a:7425:e912
'oqo3.htt' is not a valid IPv4 or IPv6 address.
Failed to send a message to the HIP daemon.
(Check syntax for hipconf. Is hipd running or root privilege needed?)
Error: Cannot configure the HIP daemon.
[root@oqo2 ~]# hipconf get ha all
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
216 bytes received from HIP daemon
HA is ESTABLISHED
Local HIT: 2001:0010:e29f:d131:68a0:02e7:719d:0fda
Peer HIT: 2001:0011:ef9c:a0ae:8bbb:478a:7425:e912
Local LSI: 1.0.0.1
Peer LSI: 1.0.0.2
Local IP: 2607:f4b8:0003:0004:020c:96ff:fe40:cb6a
Local NAT traversal UDP port: 0
Peer IP: 2607:f4b8:0003:0011:020c:96ff:fe40:cb63
Peer NAT traversal UDP port: 0
Peer hostname: oqo3.htt-consult.com

I am not sure about those errrors.

How did it get the IPv6 address of oqo3.htt? Then there various errors you see above.

They can be learned during base exchange (opportunistic mode or broadcasting I1), DHT (opendht on) or DNS (HIT record in DNS or "hit-to-ip on" + "nsupdate on").

It seems to me that there is a need for some work here :)

I think the dnsproxy requires still quite a lot of work even though it works with some "simple" scenarios.

Can a HIP aware app, that gets a HI RR derive the HIT and LSI (and same LSI as proxy would)?

Can HIP DNS Proxy distinguish between a lookup call by a HIP aware app and a legacy app?

If so the answer is 'simple'. If not we have some serious work to do.

It is now 'clear' to me that hipdnsproxy can't be running when you want to register to an RVS server. At least the way it is now. Not if all you want to do is supply the FQDN for the RVS, which to my way of thinking is what a 'user' will want to do.

So now I have to not have hipdnsproxy start as a service, register to RVS then start the service.

Unpleasant for sure...



Other related posts: