The stupidity of trying to "fix" DHCPv6

Ray Soucy rps at
Fri Jun 10 15:42:29 UTC 2011

On a side note; I think the RDNSS stuff was pretty silly.  Now instead
of hosts having a DHCPv6 client, they have a DHCPv6 client AND and
RDNSS client.  Two services instead of one to do essentially the same
thing.  That's been my biggest issue with the "let's add things to RA"

On Fri, Jun 10, 2011 at 11:38 AM, Ray Soucy <rps at> wrote:
> There is almost no difference between having RA give out DNS
> information, and having an "other only" DHCPv6 server from a software
> standpoint.  The difference is that DHCPv6 is in the application
> space, while RA is in the kernel space.  It's easier to modify DHCPv6
> than RA; so over time when we add options, we don't need to go back
> and modify the IPv6 implementation in every OS; just update the DHCPv6
> client.  We could just re-name DHCPv6 other-only mode and call it
> "Extended RA" if you like; it wouldn't even require any code change.
> Most routers that support IPv6 also support running an "Other Only"
> (stateless) DHCPv6 server; it's like 3 lines of configuration and
> costs next to nothing.  We haven't seen any DHCPv6 client
> implementations for "other only" but it would be equally trivial to
> write them.  I think the general feeling, though, is that a full
> DHCPv6 client should be considered a requirement for any host
> regardless of if the network makes use of DHCPv6 for address
> assignment or not.
> On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong <owen at> wrote:
>> On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote:
>>> In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote:
>>>> Also agree that I want flexibility to use RA or DHCPv6; the
>>>> disagreement is that RA needs to be removed or changed from IPv6.
>>>> Don't go breaking my IPv6 stack for your own ambitions, please.
>>> I want that flexability as well, but the IETF won't deliver.
>>> The two options delivered so far are:
>>> RA's only.
>> Only sort of... This only works if you don't want to auto-configure things like DNS,
>> NTP, etc.
>> I would like to see both protocols made optionally complete, so, in addition
>> to fixing DHCPv6 by adding routing information options, I'd also like to
>> see something done where it would be possible to add at least DNS
>> servers to RA.
>>> DHCPv6 with RA's to learn a default route.
>>> I want a third option:
>>> DHCPv6 only.
>>> I have no desire to remove either of the first two options.
>>> In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote:
>>>> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off.
>>> There are various drafts and proposals in the IETF to solve this
>>> problem, and they pretty much all focus on the DHCP side of things.
>>> You see, in DHCPv6 it was decided to not implment a field for the
>>> default gateway or subnet mask, under the logic that the former was
>>> learned via RA's, and the latter was always a /64.  While it's not
>>> quite as trivial as adding those two fields, it's not that much
>>> more complex.  The right behavior for a host that comes up and sees
>>> no RA's needs to be documented.
>>> To pick on Ray for a moment, the IETF seems to largely have a similar
>>> attitude to Ray's.  I spent a year or so trying to talk to the
>>> various folks involved, only to be told that I "didn't understand
>>> IPv6", "didn't know what I was talking about with respect to how
>>> RA's work", and "wouldn't want a network with only DHCPv6".  I can't
>>> tell you how many times I had been told I clearly didn't have enough
>>> experience with IPv6, when we've been dual stacked for years.
>>> When I do get someone at the IETF who will listen to my operational
>>> issues the response is always the same as Ray's.  Deploy RA guard.
>>> Never mind that until a year or so ago no vendors at all had it.
>>> Never mind that even today only a handful of switch models support
>>> it.  Never mind that it requires me to forklift out every working
>>> L2 switch I have just to run IPv6.
>>> As far as I can tell the IETF has been killing or stalling the
>>> necessary DHCP additions for the better part of 7 years now.  If
>>> you really want to fix this problem you either need to get a vendor
>>> to just implement it and ignore the IETF, or enough operators to
>>> go to the IETF meeting with pitchforks that perhaps someone finally
>>> listens.
>>> I really beieve this is going to be the single largest impediment to
>>> deploying _end user_ IPv6.
>>> --
>>>       Leo Bicknell - bicknell at - CCIE 3440
>>>        PGP keys at
> --
> Ray Soucy
> Epic Communications Specialist
> Phone: +1 (207) 561-3526
> Networkmaine, a Unit of the University of Maine System

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

More information about the NANOG mailing list