Re: Mac OS X 10.7, still no DHCPv6

[Owen DeLong <owen () delong com>]

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

> 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.
This may apply to some fraction of posters, but, I think many of the
posters in this thread are actually fairly knowledgeable on IPv6.

> IPv6 is simple, elegant, and flexible.
Parts of it are. Other parts are rigid, inflexible, and represent design
decisions only theorists could love.

> 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...)
The intertwining of RA/DHCPv6 as it currently stands in IPv6 is an example
of a design decision only theorists could love.

In the real world, you have organizations where the people that manage
hosts and host policy are not the people that run routers. In such
environments, creating this kind of cross-organizational dependency
that requires a constant coordination of even trivial changes on either
side is far from optimal.

> 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.
That's all well and good, but, when you consider the real world implications,
it starts to break down in most organizations...

Now, the people that run the routers have full control over the selection
of addressing schemes for the network. The people who set host policy
have no control short of statically configuring the hosts or getting buy-in
from the people that run the routers for their particular preference
in address selection methods.

Yes, in a theoretical world, everyone gets along and cooperates easily
and stuff just works out with whatever decision is agreed upon. In the
real world, this becomes a constant source of tension between the
two groups and increases workload on both sides of the equation
unnecessarily.

> 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).
All well and good, but...

> 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.
Which also means:
        1.      Multiple subnets on the same media that are intended for
                different hosts and have different routers are no longer
                feasible. (Yes, you can argue they're less than desirable
                in IPv4 and I would agree, but, they exist in the real world
                for a variety of layer 8-10 reasons and re-engineering an
                organization to make it fit into IPv6 is non-trivial).

        2.      RA has the problem of treating all routers claiming to
                have the same priority are of equal value to all hosts.
                Routers are considered fully interchangeable units
                and it is assumed that all routers are a viable path
                to everything. DHCPv4 actually provides facilities
                for dealing with more complex topologies where
                different destinations may be in different directions
                from different hosts. It also allows for providing
                different default gateways to different hosts based on
                policy decisions.

Yes, in the most basic cases, RA can be superior to getting routing
information from DHCP. However, in the real world, there are many
cases where it simply breaks things and is a step backwards from
capabilities in use in IPv4.

> 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.
While you have some things right in the first half of that paragraph,
there are real world problems with the approach in the second half
and there are changes that are needed. RDNSS is a positive step
in the right direction (making router-centric host configuration
more viable). Making server-centric configuration more viable
is also necessary.

> 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.
That's all great in a purely theoretical world or a small organization.
In the real world, there are many organizations for whom that set of
tradeoffs and combination of dependencies is far from optimal.

> 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.
Which is a major change in the administrative boundaries for the vast
majority of enterprises. Such changes may not be so welcome at the
layer 8-10 levels of the stack and may, indeed, create substantial
resistance to deployment.

> 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.
Only in theoretical implementations or implementations where the routers
and host policy are administered by the same organization.

> 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?
Which is why it would be better if RA supported a more flexible set
of host configuration options rather than just cobbling DNS onto it.

> 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.
I guess that really depends on your perspective. In the real world, it
does a better job of keeping IPv6 from getting deployed in the enterprise.

> 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 framing of the issue utterly ignores the reality of how things are
handled in the real world and what happens in the enterprise
environment across organizational boundaries.

> 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."
It certainly was such a war for some time in the IETF and it was
carried out in a way that much damage was done to both sides
of the equation.

The end result is a construct with a very limited set of choices
for implementers almost all of which include cross-organizational
interdependency in most enterprise environments that will create
continuing friction and exacerbate the usual level of dysfunction.

> 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.
However, if you want to put host policy completely in the hands of the
host administrators, you still can't.

If you want to have the router administration group provide a complete
set of host parameters, you still can't.

The only way to provide a complete set of host configuration information
through automated processes is to get some fraction from the routers
and some fraction from other servers. This should be improved.

> 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.
We can agree to disagree.
> 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.
True, as far as it goes, but, there is also an issue of not wanting to
completely redesign the org-chart because IPv6 is utterly dysfunctional
with the current organizational boundaries. In some organizations,
you have to get up to the point of a VP before you find common
management shared by the groups that have to cooperate in the
current implementation. The average VP regards the details of
host configuration relatively below his pay grade and will likely
consider any protocol that requires major changes to his org
chart to be, well, broken.

> 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.
Uh, no, it's more to mask the MAC address of devices that move around
so that you can't track their movement easily by matching up the last 64 bits
of their IPv6 address and using the first 64 as a location identifier.

> Apple is probably cringing at this thread going on for so long and not
> getting berried because of the inaccurate topic. :-)
Whether or not Apple is cringing, this thread (or something like it) will
probably continue until theory and implementation in IPv6 advance
to the point of matching reality.

Owen