Re: The stupidity of trying to "fix" DHCPv6

[Ray Soucy <rps () maine edu>]

I don't mind being picked on; and I hope I don't come off as hostile.
It's all in good fun.

I'm really kind of a young punk compared to a lot of people on list,
and there usually isn't a day that goes by where something I said the
previous day comes back to haunt me. ;-)

I think we have a lot of IPv6 that is usable, and better than IPv4, in
place already.  People were complaining about DHCPv6 being useless and
saying everything should be SLAAC; then we started seeing good client
and server implementations for DHCPv6 and people started coming
around.

As you roll out IPv6 you're going to make some mistakes, you're going
to learn a bit, and you're going to look back at comments you made in
the past and laugh a little.  My idea of IPv6 a year ago was very
different than it is today; tough today I have IPv6 deployed
state-wide on an R&E network, and have met a lot of the technical and
political challenges that I never anticipated along the way.

Given that IPv6 has taken so long to implement to begin with, I
usually have a negative reaction to people marching in on a pony and
telling everyone how IPv6 needs to be re-written because it could be
better.  I don't see the DHCPv6 route option being viable as the
primary method for default nexthop for several years.  It not only
needs to become an actual standard, but then it needs to be
implemented, and you need to wait out the legacy systems.

So what we have for IPv6 today is generally a good starting point.
I'm of the mindset that it's reasonable to expect more form network
switches, so RA Guard being a "requirement" for IPv6, while a messy
transition, is something I'm OK with in the long run.

The addressing piece is something a lot of people get hung up on
because it's very, very different than IPv4, and it's the first thing
people new to IPv6 are exposed to; but I think once you understand it
it's not really a roadblock from deployment.

The next step is figuring out how we deliver IPv6 to the SMB that
currently makes use of a dinky Dual-WAN NAT box for redundancy.  We
don't want these guys in the BGP tables; but we don't want to tell
them that they're stuck with a single provider either.

I think that's where things start to get a lot more interesting, not
all this DHCPv6 vs SLAAC talk ;-)



On Fri, Jun 10, 2011 at 10:47 AM, Leo Bicknell <bicknell () ufp org> 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.
> 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/