[141695] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Jun 10 10:48:26 2011
Date: Fri, 10 Jun 2011 07:47:51 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: Ray Soucy <rps@maine.edu>, Iljitsch van Beijnum <iljitsch@muada.com>
Mail-Followup-To: Ray Soucy <rps@maine.edu>,
Iljitsch van Beijnum <iljitsch@muada.com>, nanog@nanog.org
In-Reply-To: <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com>
<BANLkTi=XuP0pvOPnRo50SGJ6ihyBGq0LnR4SfaO7sTK=3zpmyQ@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wr=
ote:
> 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 w=
ith a solution that everybody likes. In a greenfield situation that solutio=
n could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" I=
Pv6 systems that aren't compatible with that, and we want results before th=
ose 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. =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.
I really beieve this is going to be the single largest impediment to
deploying _end user_ IPv6.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBTfIul7N3O8aJIdTMAQJrxRAAkIxF07R48Vi47unYAYXatNjNq7+79iYJ
/EGYZrK2GtS4Lb8/sJxZ6To28Uv9kckW3+uqVD3ORXmzLM+HOtbuOpj8fzEr7kiq
b6ufmksvWY1aloVuegobqQOtV1PQoEU8lBdigrWMxOM5Ah/uW1nDHGP/TSf445ok
KKnXltT83Bw/lJ/EGuAF+MXewpR+YSSP949vYTCbB22WYpiUoK5dmUdxZWFMZVmn
YoStCVOXvLTYxiXoGbw4/iY6569H5815j3+yzaK7ffAJUHsVj/mvuQlqOupd4mOl
Bp97MpkD5pSViHAzP4YtH4NJwNh8U3TF41agyZOywPb5ParCA9WVkG+Zrv3SI9r7
akkr0gBtB0dPDTNZuvqzIkW5HMFqDNd3q8QegUr331Cy2LRCIoWLi5Uj4x7inqAi
QO393VSXBQkOd0dhdddTOLi3xdXUzTqBbIePhJ5MaIIe5AV91A81d1Y8zb1CZbRu
LkWDSMmbZlk18YdpGOLDX46oBBjh1XjdHTWMwBehkwrhlITEJPGgzFrTgaf1fRcs
gVgFzlyE7uguwpSLEwXdZwi+eMuztWWo2SiOMUJW4UygCz5YjitPPaWLDazu8OEy
shGxopNk/4V9fQ49kJOg8xToKuzLgxcsILDLtLjgqIJbmlyiuHdE0XYSoKtMvnWa
1drOWm4KFlI=
=7Q1A
-----END PGP SIGNATURE-----
--3MwIy2ne0vdjdPXF--
