Is there a standard that defines/recommends behavior for route injection of snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay agents? That is, snooping or otherwise examining a relayed DHCPv6 response for a delegated prefix (or IA, if you want) and installing a quasi-static route toward the relevant next-hop based on the lifetime of the delegation. Typical redistribution can then be used to put it in IGP if you want.
It seems to be a common feature - Cisco ("Relay Agent Notification" on IOS-XE), Juniper ("DHCPv6-PD Route injection" on JunOS), and Arista ("ipv6 dhcp relay install routes" on EOS), and Ruckus ("Relay Agent Prefix Delegation Notification" on FastIron) all seem to support it.
Google has, however, failed me at finding any standard that defines or recommends corresponding behavior. RFC 8415 punts on the issue:
the server may need a protocol or other
out-of-band communication to configure routing information for
delegated prefixes
It would be nice to have some sort of semi-normative behavior to at least refer to if only to use it to prod vendors.
I went through that same search a little over a year ago. I'm
curious if you got any off-list replies of interest. We use dhcpv6
relay on Juniper ACX5048 (should be same on MX series). It did not
work out of the box for me; Juniper had to fix a fundamental way it
worked in order to work with some clients (pretty much anything
Broadcom based at least). I'm running working code now (17.4R2.4). I
was very pleased Juniper took the problem so seriously and fixed it...
That hasn't been my experience with every vendor.
I can provide some info about how it works and what "working"
looks like if you are curious. Getting native dual-stack fully working
has been a long, strange road as a small ISP. I'm thinking about
writing something up about my experience so far.
--TimH
I would definitely read that.
Unfortunately no. Only inquiry I got was one related to support for it in Arista EOS which unfortunately I can't speak well toward since I don't have Arista gear. For those keeping tabs at home, though, I think the feature appeared in EOS 4.20.1f.
Sounds like this may be an area that could use some standardization or best practice documentation even if it's basically just to condense existing practice into something concrete.
This feature is usually found packed with the BNG/BRAS/broadband termination functionality. The keyword you need to search is "subscriber". The feaure pack is usually subject to additional licensing. Cisco, Juniper, Nokia/ALU, all have product ranges supporting that.
Those being said, I'm interested in how that feature is supported on gear that is not "subscriber-aware" (you were talking about Arista), since generating routing information from relayed DHCP(v6) is a big/important part of the "subscriber management" functionality.
Those being said, I'm interested in how that feature is supported on gear that is not "subscriber-aware" (you were talking about Arista), since generating routing information from relayed DHCP(v6) is a big/important part of the "subscriber management" functionality.
What it does is hook into the DHCPv6 lightweight relay functionality. Basically, it just snoops the DHCPv6 replies for a PD assignment and inserts a quasi-static route into its table for anything that it sees with next-hop pointing at wherever the reply was going. The static route is time-limited and gets removed when the delegation expires (or presumably if it sees a release of the corresponding resources). It stores the database of those learned delegations, including expiry, in persistent memory so that it can re-install them in event of a reload. Obviously having good reltime information on the router is important for this.
The key here is that it doesn't care about "who" is getting the resources or why. All it cares is that it saw a DHCPv6 reply via its relay that included a delegated prefix.
Juniper, at least, and presumably Cisco too, also implement a means to get that information via RADIUS. That may be more what you're thinking of?
I'm not sure that the Cisco implementation I'm thinking of requires the BNG/BRAS features to be licensed. See [1] under heading "DHCPv6 Relay Agent Notification for Prefix Delegation". In particular, note:
No user configuration is required for this feature. Static route management is done automatically by the relay agent.
It sounds like it operates similar to how I described above. Basically, you can relegate your "subscriber management" to simple DHCP if such a lightweight implementation is sufficient for your needs.
What it does is hook into the DHCPv6 lightweight relay functionality.
Basically, it just snoops the DHCPv6 replies for a PD assignment and
inserts a quasi-static route into its table for anything that it sees
with next-hop pointing at wherever the reply was going. The static
route is time-limited and gets removed when the delegation expires (or
presumably if it sees a release of the corresponding resources). It
stores the database of those learned delegations, including expiry, in
Yep, that's exactly the expected behaviour (or at least a big part of it)... providedit's implemented properly.
persistent memory so that it can re-install them in event of a reload.
That's an interesting point, most subscriber management implementations don't implement this, requiring low dhcp timers.
The key here is that it doesn't care about "who" is getting the
resources or why. All it cares is that it saw a DHCPv6 reply via its
relay that included a delegated prefix.
Exactly, that's dhcp server's job. Or at least that's what I do at $job[$now].
Juniper, at least, and presumably Cisco too, also implement a means to
get that information via RADIUS. That may be more what you're thinking of?
That's "subscriber management". On Cisco (A9K and A1K) and NokiALU (SR 7750) you normally need a license, even if it's (for now) honor-based. On Cisco it'the "broadband"/BNG, on NokiALU it's "xK subscribers".
I'm not sure that the Cisco implementation I'm thinking of requires the
BNG/BRAS features to be licensed. See [1] under heading "DHCPv6 Relay
Agent Notification for Prefix Delegation". In particular, note:
That one seems to be the simpler form, depending only on an external DHCP server. It may be enough for some set-ups. Subscriber functionality provides more options, such as enforcing auth and internal dhcp server that takes data to be returned from RADIUS. It also allows dissociation between L2 and L3 (same subnet on several VLANs).
You can almost call it SDN 
No, there isn't. However, there is now work ongoing work in the IETF to at least create a functional description of one.
I read a pre-version of the -00 yesterday (my colleague is one of the authors), hopefully a first version of it should be posted coming week. Check out the IETF WG mailing list for when it's posted.
The area of how the router on the LAN gets the DHCPv6-PD route injected never was standardized because consensus couldn't be reached on how to do it, so it was glossed over and vendors solved it the way they saw fit. I've seen implementations where no route was injected (to customer astonishment of course becase it's useless without this), so this is functionality that needs at least some kind of specification.
It's perfect for lots of smaller networks that have L2 DHCP snooping and access enforcement via that means. My L2 happens to offer just that. I do have to enforce a somewhat "traditional" L2-L3 mapping, but it works fine on this network, at least.
I'll keep my eye out for it.
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 feature available is of course really nice. Some sort of standard behavior for it is preferable if it's going to be implemented.
My punt in the absence of support for it on my platform (I'm arguing to get it implemented) was to inject the route via BGP from the DHCP lease database. That's very flexible, but it's also a heck of a lot more work of course.
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 use.
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.
One example:
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 now moved.
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 strict rules.
It was implicit to me, anyway, that this type of behavior is only relevant when the DHCP-endpoint (customer) subnet default router's control plane and the DHCP relay agent are in intimate communication i.e. are essentially integrated in some meaningful way.
I guess you could extend the behavior to any situation where the router is able to snoop the DHCP relay conversation, but I think that's fraught with issues since, if the relay agent isn't on the router itself, who knows where it is on the L2, and trying to snoop the relay-server communication, rather than the client-relay exchange, may give lots of crazy behavior.
If the relay isn't integrated with the router in any meaningful way, I guess you have to fall back to some undefined "out of band signaling protocol" which I guess we don't have, either. BGP or OpenFlow seem like the most obvious options.
I guess most networks offering this are using heavy-weight subscriber management facilities based on RADIUS or some other more-involved AAA mechanism? That's obvious if you're running PPPoE and have highly centralized L3 termination but less so if you're running native Ethernet (or something that looks like Ethernet) everywhere with semi-distributed L3 termination.