As an aside, I proposed the idea that would become RFC 6939 back in early 2012 on NANOG:

"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 to
include the MAC address of the system making the request
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 <> wrote:

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

If you feel the issue you are reporting is a security issue, please
see 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 <> 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 <> and <>
are withheld from public view.

Other Support Options

If your organization requires more immediate attention, ISC offers
paid support options.  Please see
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

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:

For configuration help...

Questions regarding configuration or setup are addressed on mailing
lists - to subscribe, visit:

Thank you,


Two items:



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


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


Ray Patrick Soucy
Senior Cyber Security Engineer
Networkmaine, University of Maine System US:IT