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