X-RT-Original-Encoding: utf-8
content-type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Length: 5507
As an aside, I proposed the idea that would become RFC 6939 back in early
2012 on NANOG:
https://mailman.nanog.org/pipermail/nanog/2012-January/044267.html
"If someone were to modify DHCPv6 to address these concerns, I think
the easiest way to do so would be to
*extend DHCPv6 relay messages toinclude the MAC address of the system
making the request* (DHCPv6
servers on local sub-networks would be able to determine the MAC from
the packet). This would allow transitional DHCPv6 configurations to
be built on MAC addresses rather than DUID without client modification
(which is key).
Perhaps this is already possible *through the use of RFC 6422* (which
shouldn’t break anything)."
I was a bit disappointed to see that Cisco didn't reach out to include me
on the RFC, but oh well. Anyway, the idea pre-dates Cisco's implementation
so there should be no IP issues preventing its implementation.
On Tue, Mar 13, 2018 at 11:11 AM, DHCP Public Bugs via RT <
dhcp-public@isc.org> wrote:
> Greetings,
>
> This message was automatically generated to acknowledge receipt of
> your recent email
> "DHCPv6 relay feature requests",
> and to let you know that we have opened a ticket for your request
> (a summary of which appears below.)
>
> We do not need a further response from you at this time, but if you
> do respond, please include in the Subject of your reply the ID
> '[ISC-Bugs #47311]'
> so that we can match up your reply with the ticket in our system.
>
>
> What Happens Next
> =================
>
> Bug reports submitted to us in this manner are handled based on
> perceived severity in relation to other bugs. We handle reports as
> time permits so there is no guaranteed response time for these
> reports.
>
> If you feel the issue you are reporting is a security issue, please
> see http://www.isc.org/security/reporting-issues for details on how
> to report it, including the PGP key you may use.
>
> If it is of a non-security yet still urgent matter, you may reply
> to this message to add further information.
>
>
> Public Visibility of Bugs
> =========================
>
> Most bind and dhcp bug reports submitted since July 7, 2017 are visible
> to the public at https://bugs.isc.org after
> review by the developers.
>
> If you want this report to be withheld from public view, please
> reply to this message with your request.
>
> All reports submitted to
> bind9-confidential@isc.org and
> dhcp-confidential@isc.org
> are withheld from public view.
>
> Other Support Options
> =====================
>
> If your organization requires more immediate attention, ISC offers
> paid support options. Please see http://www.isc.org/services/support
> for more information.
>
> If paid support is not an option, please consider making a donation
> to ISC. We don't require a donation -- we will work on your report
> just as quickly whether or not you can donate -- but we always need
> and welcome community support. See http://www.isc.org/donate/
>
>
> Run a Supported Version
> =======================
>
> If you are not running a supported version of our software, please
> upgrade. Bug reports against unsupported versions of BIND are
> discouraged, as your issue may have already been addressed.
>
> You can find the latest versions of our software here:
>
> https://www.isc.org/downloads/
>
>
> For configuration help...
> =========================
>
> Questions regarding configuration or setup are addressed on mailing
> lists - to subscribe, visit:
>
> https://lists.isc.org/mailman/listinfo/bind-users
> or https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
> Thank you,
> dhcp-public@isc.org
>
> ---------------------------------------------------------------------
>
> Two items:
>
> ----
>
> #1
>
> It would be useful to see support for RFC 6939 added to dhcrelay for
> DHCPv6.
>
> Specifically, the insertion of OPTION_CLIENT_LINKLAYER_ADDR (79) , which
> provides the client MAC to dhcpd as a relay option.
>
> ----
>
> # 2
>
> It would be useful to see support for providing external programs
> information on DHCPv6-PD prefix assignments so that systems used as routers
> could then take action to add routes for delegated prefixes.
>
> This could be as simple as (1) creating a log event with the needed
> information (prefix, expiry, and next-hop) that could be streamed to a
> specific file; or (2) adding support to call an external script with the
> information past as a list of as arguments; or (3) maintaining a
> prefix-delegation database that keeps track of active prefixes delegated.
>
> My personal preference would be the second option to call an external
> script.
>
> ----
>
> These two items are important for enabling IPv6 with DHCPv6 for open source
> network routers and firewall projects, such as VyOS.
>
> They also compliment functionality already in DHCPd, and would provide a
> way to leverage these features without the use of proprietary relay agents.
>
> I know that dhcrelay is not seen as a high priority for the project, but I
> hope I can convey how important this functionality is for both IPv6
> adoption as well as open source router and firewall adoption.
>
>
>
>
> --
> Ray Patrick Soucy
> Senior Cyber Security Engineer
> Networkmaine, University of Maine System US:IT
>
> 207-581-3526
>
>
--
Ray Patrick Soucy
Senior Cyber Security Engineer
Networkmaine, University of Maine System US:IT
207-581-3526