On Wed, 2016-07-13 at 19:28 +0200, Erik Muller wrote: > On 6/8/16 20:37 , Erik Kline wrote: > > On 9 June 2016 at 03:16, Ole Troan <o...@cisco.com> wrote: > > > Mikael, > > > > > > > > We also tried (and failed) to come up with a secure mechanism > > > > > for the requesting router to advertise it's delegated prefix > > > > > to first-hop routers. > > > > > > > > > > Less astonished? ;-) > > > > > > > > Well, I guess I shouldn't be astonished. I've even seen vendors > > > > implement the DHCPv6-PD server on the router itself, and fail > > > > to install route according to the delegated prefix. > > > > > > > > So basically, regarding how to actually implement PD in a > > > > network (from an IETF point of view), everybody just gave up, > > > > declared the problem unsolvable, and went back to sleep? > > > > > > It shouldn't be the IETF's job to tell people how to run their > > > networks. > > > The IETF provides the building blocks. > > > > But this sounds like what's missing is operational guidance on what > > collections of blocks have been known to work. > > The Broadband forum TR-177 guidelines[1] provide at least one > approach for > how to put it together, if you need a standards-compliance reference > to > cite. (tl;dr: "if you're a BNG and you relay or serve a PD prefix, > you > need to also route it to the client"). > I know Nokia/Alcatel-Lucent 7750s implement routing properly for > relayed PD > blocks. I've had it working on Brocade MLXes and cisco ASR1k as > well. > (ISTR an earlier MLX version implemented relay without route > insertion, but > that was just as an interim release while they were finishing > development, > and likely other gear has had similar times where that half- > implemented > feature made it out the door.) > > -e > > 1. https://www.broadband-forum.org/technical/download/TR-177.pdf
We went through a few MLX softwares with the problems you described. IIRC the first implementation did not do any snooping at all, so "show ipv6 dhcp-relay delegated-prefixes" was empty, and the second did add prefixes to this table but not route them. I think we went around 9 months from the first to the working version. Anyway, thanks for the TR-177 document, this is helpful for me in an ongoing (somewhat related) case with HP about Comware 7 based switches (like 5130) doing DHCPv6 Snooping but not reading the IA_PD part of messages. This of course results in a snooping table with only IA_NA entries and thus IPv6 L2 security breaks Prefix Delegation. As a sidenote I also discovered these switches have some more issues with their IPv6 L2 security where hot-configuring them seems to sometimes partly or even fully break validation of packets. A reboot makes sure it's really working, but this will certainly be somewhat of a headache when we deploy IPv6 config to a few thousand switches. Hopefully it will also be fixed with the software adding snooping of PD! /David
