[168035] in North American Network Operators' Group
Re: NANOG Digest, Vol 72, Issue 17
daemon@ATHENA.MIT.EDU (Ralph Droms (rdroms))
Mon Jan 6 15:30:23 2014
From: "Ralph Droms (rdroms)" <rdroms@cisco.com>
To: "<nanog@nanog.org>" <nanog@nanog.org>
Date: Mon, 6 Jan 2014 20:30:11 +0000
In-Reply-To: <mailman.10765.1389037345.40664.nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> Date: Mon, 6 Jan 2014 11:40:29 -0800
> From: Owen DeLong <owen@delong.com>
> To: Doug Barton <dougb@dougbarton.us>
> Cc: "nanog@nanog.org" <nanog@nanog.org>
> Subject: Re: turning on comcast v6
> Message-ID: <741B5A5F-3D87-4BA2-9349-F5BB94A8B483@delong.com>
> Content-Type: text/plain; charset=3Diso-8859-1
>=20
>=20
> [...]
> Doesn't have to be... You can create any local DHCPv6 extension you like.=
That _IS_ in the spec.
>=20
> Owen
Well, not exactly. The authors of RFC 3315, smarting (if I recall correctl=
y) from the local options debacle in DHCPv4, didn't set aside any experimen=
tal option codes for DHCPv6. Oops and mea culpa.
Having said that, I suppose I can't formally recommend that an implementor =
use an option code somewhere near the top of the range and implement a quic=
k extension to a client and server for the default router option, which wou=
ld result in some running code to point at.
But running code isn't enough. The last time I took the default router opt=
ion to the IETF, it died (in the 6man WG, again trusting to memory) for lac=
k of support. More or less the same thing more recently in the mif WG (mor=
e support in mif, but it was the wrong WG). So, someone will have to do th=
e hard work of shepherding and supporting the document through publication =
in the right WG. I understand Nick Hilliard may be undertaking that effort=
; those interested in the new option might want to lend Nick a hand (apolog=
ies to Nick if I've got that wrong).
- Ralph
