NANOG Digest, Vol 72, Issue 17

Ralph Droms (rdroms) rdroms at
Mon Jan 6 20:30:11 UTC 2014

> Date: Mon, 6 Jan 2014 11:40:29 -0800
> From: Owen DeLong <owen at>
> To: Doug Barton <dougb at>
> Cc: "nanog at" <nanog at>
> Subject: Re: turning on comcast v6
> Message-ID: <741B5A5F-3D87-4BA2-9349-F5BB94A8B483 at>
> 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.
> Owen

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).

- Ralph

More information about the NANOG mailing list