On 05/07/13 18:27, Michael Richardson wrote: > Daniel Pocock <[email protected]> wrote: > >> okay.... my observation is that client side dhcpv6 is unusual still at > >> this point. Certainly none of my phone/tablet devices will do that, > >> and they all speak ipv6 RA just fine. > > > I agree that the RA stuff works fine - the problem is getting DDNS to > > work. Many people currently drive DDNS updates from their DHCP server. > > > Do you prefer to use client-initiated DDNS updates or some other > > solution? > > Client-initiated DDNS updates to the forward zone that that client has a > relationship with works fine, but that has nothing to with DHCP :-)
I agree - that's why I mentioned it, the client could make such an update request after completing SLAAC address configuration > Most clients do not have the right credentials to update forward/reverse for Yes, that's why I don't see it as the most convenient solution (but it would be valid for some sites if there is a convenient way to deploy DNS update keys) > the LAN on which they find themselves, it should be done via DHCPv4. If this is limited to DHCPv4, then there will be no AAAA records in DNS and many local applications will never use IPv6 because they will always get an IPv4 A record. This would mean many applications may not really be exercised on IPv6 as soon as they should be. > On IPv6, my preference (which is not implemented anywhere as yet, AFAIK), > would be > to drive DDNS updates from mDNS. This being discussed at the IETF at > homenet (WG) and now, sdnsext (BOF) I think this is a useful possibility - although not backwards compatible for every DDNS dependent user On the positive side, the use of the ".local" suffix for mDNS also provides some clue that these are addresses that may not be trustworthy. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
