hi Jim, thanks for the kudos and the use cases!
Definitely want to discuss this a bit more!
re. use cases:
1) internet of things: yes, quite probably... But if we talk sensors and other constrained devices, would rfc6106 still apply, given that these networks will probably be special case governed by ROLL/6LoWPAN IETF WG work ? (http://datatracker.ietf.org/wg/roll/charter/, http://datatracker.ietf.org/wg/6lowpan/charter/ - especially RFC4919. I'll ask the folks involved in those WGs what they think.)
2) LAB/test machines: Let me challenge this :-). In my lab for IPv6-only client test setup I use Stateless DHCPv6, works fine for all major modern OSes. (Ubuntu added it in 12.04, http://www.stgraber.org/2011/07/26/state-of-ipv6-in-ubuntu-oneiric/). Note, that I still use SLAAC for the IPv6 address assignment, so the addresses are stable EUI-64, thus no state on the IOS DHCPv6 server. (NB: Android, sadly, is not yet in this happy group. See http://code.google.com/p/android/issues/detail?id=3389#c107)
3) SOHO: not sure. Assuming the discussion is about the coffee machines (the consumer general purpose OSes would be covered in (2) above) - would depend which kind of code they will run. With the advent of the SoCs like RaspberryPi, the concern about the a few bytes of code space required to run DHCPv6, would no longer hold imho. And I'd be willing to bet that the coffee machine producers will use linux-based hardware to lower the development costs and TTM. What do you think ?
A couple of comments/questions about the implementation:
Do you have any practical experience with the issues mentioned in http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues ? To me seems like the corner cases still need to be a bit hashed out.
As for the difficulty of the DHCPv6 implementation: here's a relevant "server" part that I used in my CL12 San Diego "network hijack" demo. Granted, it's a quick and ugly hack script that used scapy libs (and it is only the server side, I did not write the client side code, and in C it would be a bit more verbose of course):
if DHCP6_InfoRequest in pkt:
print "DHCP Information request"
print (pkt[IPv6].src)
rep = Ether(src=get_ether_src(),dst=pkt[Ether].src)/\
IPv6(dst=pkt[IPv6].src)/\
UDP(sport=31337,dport=546)/\
DHCP6_Reply(trid = pkt[DHCP6_InfoRequest].trid)/\
pkt[DHCP6OptClientId]/\
DHCP6OptOptReq(reqopts=[24,23,32])/\
DHCP6OptServerId(duid=DUID_LLT(lladdr=get_if_hwaddr(scapy.config.conf.iface6)))/\
DHCP6OptDNSDomains(dnsdomains=["hijacked.invalid"])/\
DHCP6OptDNSServers(dnsservers=[dns64_address])/\
DHCP6OptInfoRefreshTime(reftime=300)
sendp(rep, verbose=False)
But, just using this to illustrate that for the stateless DHCPv6 the coding is not too hard. And, unlike the RDNSS, it's fully in userspace on the clients. Which may play a role if any tweaks/changes are needed to implementation.
FWIW, I realise the above looks a like a giant excuse "why we don't do it", I ought to mention that last year I did make an experimental image that had a proof-of-concept code for RFC6106, but had a bit of a hard time gathering the business case that would allow me to solicit for any "official" efforts in this area. If you have or have had real projects that would be critically dependent on RDNSS, I'd be very interested - ping me via email with that.
--a
