[141698] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jun 10 10:59:05 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org>
Date: Fri, 10 Jun 2011 07:53:36 -0700
To: Leo Bicknell <bicknell@ufp.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> I want that flexability as well, but the IETF won't deliver.
>=20
> The two options delivered so far are:
>=20
> 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.
>=20
> I want a third option:
>=20
> DHCPv6 only.
>=20
> I have no desire to remove either of the first two options.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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. =20
>=20
> 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.
>=20
> I really beieve this is going to be the single largest impediment to
> deploying _end user_ IPv6.
>=20
> --=20
> Leo Bicknell - bicknell@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
