Re: The stupidity of trying to "fix" DHCPv6

[Ray Soucy <rps () maine edu>]

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 () delong com> 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 () ufp org - CCIE 3440
> >        PGP keys at http://www.ufp.org/~bicknell/



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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