On 15/02/14 02:18, Lorenzo Colitti wrote:
On Sat, Feb 15, 2014 at 8:12 AM, Dave Taht <dave.t...@gmail.com
<mailto:dave.t...@gmail.com>> 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.
This technique is useful for all the _existing_ systems that only do
EUI64 SLAAC, I don't think it's something we should do going forward. It
might be worth pointing out that deprecate-eui64-based-addresses goes
backwards in this respect, and deprecate-eui64-based-addresses-and
use-dhcpv6-instead would be better, or define a hostname option in the
Router Solicit packet.
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.
Two reasons.
1) Using ICMP6 works even when the client is not a neighbour of the
server, ie when it's on a remote network segment and DHCPv4 relay is in use.
2) Implementation. There'a a well defined, stable and universal API to
send and recieve ICMP6 packets. The same code runs everywhere. Snooping
the ND takes code that's platform specific and rather more complex.
Cheers,
Simon.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
