Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme

[Lorenzo Colitti <[e-mail]>]

On Sat, Feb 15, 2014 at 8:12 AM, Dave Taht <[e-mail]> wrote:

>    This memo presents a technique for using the hostname acquired from a
>    DHCPv4 client request to publish AAAA records on that domain name for
>    public IPv6 addresses acquired by the same dual-stack host using
>    SLAAC.
>

Dave,

Good to see some work being done on this problem. A few comments:

1. Assuming that hosts generate IPv6 interface IDs per RFC 4291 will soon
be mostly obsolete. As you point out, Windows already doesn't do it, and I
believe Mac OS and iOS have recently stopped doing it too. So that's a
large chunk of the client population already. For the rest, see
http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00,
which is likely going to be adopted by 6man. It likely won't deprecate
EUI-64-based IPv6 addresses, but it will almost certainly discourage them.
As you also point out, the proposed mechanism also doesn't work for privacy
addresses, which is what virtually all hosts are going to be using for
outgoing connections anyway. So I don't think that the proposed scheme is a
solution to the problem.

2. Since you propose getting this information using MAC addresses, you're
doing layering violations and protocol violations already. So why not go a
step further and look into the neighbour cache? In principle, you could
have the reverse DNS lookup cause a lookup into the IPv6 neighbour cache to
find the address that you would then look up in the DHCP lease database.
That's expensive, but you could cache the result, and you could also snoop
DAD probes to populate the cache when hosts join the network. That would
work in a lot more cases than the proposed scheme.

3. If we're going to do work on this, it would be useful to have a
mechanism that works even without IPv4. The draft says that relying on
dynamic DNS updates "creates a very difficult key management problem", but
I don't understand that statement. Can we not simply use unauthenticated
DNS updates, and agree to accept them only if they come from the local
link? After all, in the proposed scheme the DHCPv4 request that provides
the hostname is also unauthenticated, but the router is perfectly happy to
accept it. What is the additional security difficulty here? Is is something
that could be worked out in a different way? Assuming client support, could
the hostname be provided by other types of packets such as ICMPv6 node
information replies?

Regards,
Lorenzo