Mac OS X 10.7, still no DHCPv6

Ray Soucy rps at maine.edu
Mon Feb 28 16:29:54 UTC 2011


       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).

Owen, you seem to be fixated around the idea that you can't have
multiple prefixes on the same subnet.

Set the routers to disable SLAAC,

Setup DHCPv6 to only respond with address information for the specific
hosts you want to control for each prefix (this DHCPv6 server can be
run by someone different than the person configuring routers).

Hosts will use the gateway for the prefix they've been assigned.

I'm not sure why you insist otherwise.

I've actually been working on such a setup for web-based host
registration and using a "shadow" ULA prefix until registered, then
they get a real DHCPv6 response.

And yes, you're correct, it would be much better to keep different
hosts on different VLANs, this is just a possible solution to your
problem statement.

I wouldn't be opposed to DHCPv6 options to deliver routes to hosts
(e.g. prefix, prefix-length, gateway, and metric) not just default
route information.  But I'm not sure that anything is really "lost" in
terms of functionality under the current implementation, you just have
to approach it in a slightly different way.

RDNSS encourages people not to implement functional DHCPv6 clients, so
I'm not sure how you find it to be a good thing for the problem
statement above.

On Mon, Feb 28, 2011 at 11:01 AM, Owen DeLong <owen at delong.com> wrote:
>> 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
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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




More information about the NANOG mailing list