Home page logo
/

nanog logo nanog 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.

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



  By Date           By Thread  

Current thread:
  • Re: NANOG Digest, Vol 72, Issue 17 Ralph Droms (rdroms) (Jan 06)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]