Mac OS X 10.7, still no DHCPv6

Mon Feb 28 13:52:02 UTC 2011

On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin <franck at genius.com> wrote:
> Oh... did not know about the heavy baggage...
>
> No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place?
>
> So I found this whole saga, to put it mildly "stupid", like when people were talking about migrating to IPv6 but the root servers did not even have an IPv6 address: silly!
>
> So I really don't care between RD and DHCPv6, what I care, is that they should be able to do their job correctly on their own.

Really, if you look back at the archives of this list these arguments
are starting to get "silly" as you put it.

It seems that every few months, as people discover that IPv6 isn't
going away and they should brush up on it, people go through this
process of debating the way IPv6 was designed as if it were 1998, and
ultimately make posts like this.

IPv6 is simple, elegant, and flexible.

DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core
components of IPv6, or should we throw ping and traceroute into RA as
well...)

This is why we have flags in RA to signal how addressing is done on a
network for a prefix:

A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix.
O - Other Flag, signals that additional configuration information is
available (such as DNS) and DHCPv6 should be used.
M - Managed Flag, signals that hosts should request a stateful address
using DHCPv6.

The real point, initially at least, for stateless addressing was to
make the Link-Local scope work.  It's brilliantly elegant.  It allows
all IPv6 configuration to be made over IPv6 (and thus use sane
constructs like multicast to do it).

Router Advertisements shift gateway and prefix configuration to the
routers (which are the devices that actually know if they're available
or not) rather than a DHCP server.  If you set things up right, making
a change to your RA will be seen by hosts almost instantly, and you
won't need to go through the headache of waiting for DHCP leases to
expire before hosts see that a network isn't available and let go of
that route.

One thing to keep in mind is that even though DHCPv6 and DHCP have a
similar name, they're still pretty different.  DHCPv6 was designed as
part of IPv6.  DHCP was an afterthought.  Like many things in IPv6,
they have been re-designed and included as a core component of IPv6.
Don't go making assumptions that DHCPv6 was "added" to IPv6 to turn
IPv6 into IPv4, and don't try to modify DHCPv6 to make that the case,
please.  What is needed now is protocol stability, and implementation
of the current standards, not the re-writing of them mid-deployment.

RDNSS is what I would consider "silly".  IPv6 already allows for an
environment in which stateless is used and DHCPv6 only provides DNS
(and other) information.  This is because none of the flags are
exclusive.  In fact, you can use both Stateless and DHCPv6 on the same
network, and host will get two IPv6 addresses (for example to
configure servers with pre-determined addresses).  This was the design
intent.

If you don't use DHCPv6 to assign addresses and are using SLAAC, you
can still use DHCPv6 to provide other information only, or "DHCPv6
Light", and this is already supported in most routing platforms to be
configured right on the router.

Implementation-wise, DHCPv6 Light and RDNSS have almost no difference.
 What RDNSS manages to do is embed DNS into RA (where it doesn't
belong IMHO) seemingly for the sake of not calling it DHCPv6.

Keeping DNS information out of RA is a Good Thing (which makes RDNSS a
Bad Thing).  Why? Because DNS might not always be the method we use
for mapping names to addresses; it might see a rewrite like IP itself
has seen, and there will likely be a desire to provide hosts with more
configuration information.  Looking DNS information into RA is a
slippery slope.  What's next, another option to RA for next-server
information?

DHCPv6 is separate from RA because they know that the needs for host
configuration are more likely to change over time than IPv6 itself,
and keeping them separate keeps IPv6 stable.

The question isn't "Stateless or DHCPv6".  The question is "Why are
people implementing IPv6 without a core component?"  That's pretty
much like saying you support IPv6 but not including ICMPv6 or MLD.

This isn't a war of Stateless vs. DHCPv6.  They're both the same
thing.  They're both core components of IPv6, and they both provide
specific, non-conflicting, functionality.  The argument of "Having to
implement DHCPv6 is more work" is "silly" for these same reasons.
"Well I'm not going to support address scope because that's more
work."

Thankfully, with Apple seemingly supporting DHCPv6, that means
Windows, Linux, Mac, and BSD will all have full IPv6 implementations,
and if you don't want to use DHCPv6 for addressing you don't have to.

If the goal was really to keep DNS simple for IPv6, rather than RDNSS,
they should have written an autonomous anycast or multicast DNS spec
rather than cluttering up RA with DNS server messages.  RDNSS is a
cancer IMHO and I hope we don't see it implemented.

Just replace RDNSS with "DHCPv6 Light" and you get the same thing
without breaking IPv6.  Most of the people who want RDNSS wanted to
avoid implementing DHCPv6, but its already been implemented, so I'm
not sure what all the extra effort bought us, except that now we're
seeing confused companies like Apple implement both RDNSS and DHCPv6
because they don't know which one will be needed.  So what I'm saying
here is that RDNSS is successful is doing the opposite of its goal:
Instead of making IPv6 implementation more simple, they've made it
more complex.

DHCPv6 has nothing to do with "wanting to do things the way we always
have".  It has everything to do with "we might not always do things
the same way we do today, so lets split this from being in RA".  When
it comes down to it, for hosts that provide content (servers) you'll
always need a way of knowing that address.  I'm sure manual IPv6
configuration works fine for you, but in something significant, say a
VM cluster, I for one would rather not go back to the dark ages of
manually configuring IPv6 addresses on each host.

Privacy addressing is more to mask the MAC address of a host than to
provide "privacy".  This is because some systems are easily
identifiable by their MAC address, such as Apple computers, and
embedding that into the source IP provides potential attackers with a
guess as to what the device is.  That said, host that use both DHCPv6
and Stateless addresses will use their stateless address for new
outgoing requests, by the way, effectively making the stateful address
an alias.  So I'm not sure what the issue is here.

Apple is probably cringing at this thread going on for so long and not
getting berried because of the inaccurate topic. :-)

On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin <franck at genius.com> wrote:
> Oh... did not know about the heavy baggage...
>
> No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place?
>
> So I found this whole saga, to put it mildly "stupid", like when people were talking about migrating to IPv6 but the root servers did not even have an IPv6 address: silly!
>
> So I really don't care between RD and DHCPv6, what I care, is that they should be able to do their job correctly on their own.
>
> ----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>
> To: "Franck Martin" <franck at genius.com>
> Cc: "Matthew Palmer" <mpalmer at hezmatt.org>, nanog at nanog.org
> Sent: Sunday, 27 February, 2011 6:08:28 PM
> Subject: Re: Mac OS X 10.7, still no DHCPv6
>
> Look, can we stop arguing about whether someone needs DHCP or not,
> whether they need SLAAC or not. Let's just get both solutions to a mature
> and useful state where a network administrator can pick the one that works
> best for their environment and move on.
>
> Devices, routers, OSs, etc. should support both. The IETF should stop letting
> the two working groups focus on damaging the other protocol and we should
> stop treating this as a competition or a battle and start treating it as options
> to accomplish a task.
>
> Owen
>
> On Feb 27, 2011, at 1:25 PM, Franck Martin wrote:
>
>> Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no?
>>
>> ----- Original Message -----
>> From: "Matthew Palmer" <mpalmer at hezmatt.org>
>> To: nanog at nanog.org
>> Sent: Sunday, 27 February, 2011 4:06:29 PM
>> Subject: Re: Mac OS X 10.7, still no DHCPv6
>>
>> On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote:
>>> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS
>>> server information in an IPv6-only environment.  Of course nobody else
>>> has implemented that yet, making Apple a "special case" host once
>>> again (I don't even think Cisco supports the option in their T series
>>> yet).
>>
>> radvd and rdnssd work together on Linux nicely to provide RDNSS support.
>> Works a treat.
>>
>> - Matt
>>
>
>
>

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/