Re: RFC 5006 status

[Philip Homburg <pch-v6ops@u-1.phicoh.com>]

In your letter dated Thu, 18 Mar 2010 10:04:13 +0100 you wrote:
>Hi,
>
>On Thu, Mar 18, 2010 at 09:52:34AM +0100, Philip Homburg wrote:
>> I'm curious, how does that work. Does each and every lightswitch at the
>> customer have to individually request an IPv6 address from you using DHCPv6?
>> 
>> Or do you also support giving the customer a /48 using PD?
>
>Well, what we envision is:
>
> - the CPE router gets a /48 or /56 by DHCP-PD
> - the CPE router does RA/5006 announcements so that "the light switches"
>   can do SLAAC
> - other services (NTP, ...) will be discovered by service-location protocols
>   running locally in the LAN (bonjour, SLP, ...) - OSX already does a great
>   job here, in discovering stuff without having to fiddle with DHCP server
>   setup etc.

Now assuming that the light switch also needs the current time. Probably
using SNTP. I don't that many customers will dedicated NTP devices, so it
is either the router that implements NTP or the ISP's NTP server will be used.

So now the light switch has to implement one of those service location
protocols as well? Or does it use DHCP?

From an implementors point of view, the main thing I find annoying about
RFC-5006 is that information about DNS servers ends up in the kernel instead
of in user land where I need it. And I don't want the kernel to store and
forward all kinds of user land data. Of course, it is always possible to send
an extra router solicitation ICMP from user land... 

I find it suprising that where essentially every IPv4 device can speak DHCPv4,
we now envision IPv6 devices that do speak DNS, but cannot afford to speak
enough of DHCPv6 to get the address of DNS resolvers.