DHCPv6-PD relay route injection - standard?
swmike at swm.pp.se
Sun May 19 06:05:30 UTC 2019
On Sun, 19 May 2019, Brandon Martin wrote:
> I guess my impression from RFC8415 was that it was up to the network
> administrator and their equipment vendor to resolve this. Certainly, I
> wouldn't have expected automatic route injection, though having such a
There needs to be interaction between the packet forwarding layer and the
DHCP layer when doing things like DHCPv6-PD, otherwise it's not of any
Another thing that will be in this document is that we've observed quite a
few gotchas that aren't obvious, and for different deployment scenarios
you want things handled differently by the relay.
What do you do when you have an active lease and the same DUID shows up on
another interface, requesting a prefix? If you're a wireline operator then
you most likely want to hand out a different prefix, because this is now
two different customers and you want to treat them as two different
clients even if they happen to have the same MAC address and DUID.
If you're instead an enterprise for instance, and you want to support
devices moving around and having their PD follow them, then you want to
the opposite, you instead want to just treat it as the same client that
Back in 2005 I was involved in an wireline deployment, and I checked the
customer mac addresses. 5% of the customers had the same mac address
visible to us. Seems a very popular electronics store router vendor had
shipped all their routers of a certain model with the same MAC address as
its default address. I was happy I had designed the wireline solution with
one vlan per customer so this wasn't a problem. Other ISPs weren't so
fortunate and had to spend significant customer support time/money helping
customers use the "clone PC MAC address" functionality in the HGW to work
around this problem.
In DHCPv6 the DUID is considered "world unique", but as wel all know who
work in operational environment, the world typically doesn't adhere to
Mikael Abrahamsson email: swmike at swm.pp.se
More information about the NANOG