mailing list archives
Re: NANOG Digest, Vol 72, Issue 17
From: "Ralph Droms (rdroms)" <rdroms () cisco com>
Date: Mon, 6 Jan 2014 20:30:11 +0000
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=iso-8859-1
Doesn't have to be... You can create any local DHCPv6 extension you like. That _IS_ in the spec.
Well, not exactly. The authors of RFC 3315, smarting (if I recall correctly) from the local options debacle in DHCPv4,
didn't set aside any experimental 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 quick extension to a client and server for the default router option, which would result in
some running code to point at.
But running code isn't enough. The last time I took the default router option to the IETF, it died (in the 6man WG,
again trusting to memory) for lack of support. More or less the same thing more recently in the mif WG (more support
in mif, but it was the wrong WG). So, someone will have to do the 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 (apologies to Nick if I've got that wrong).
- Re: NANOG Digest, Vol 72, Issue 17 Ralph Droms (rdroms) (Jan 06)