Re: DHCPv6 relay with PD
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 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
Re: DHCPv6 relay with PD
On 6/8/16 20:37 , Erik Kline wrote: > On 9 June 2016 at 03:16, Ole Troan 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
RE: DHCPv6 relay with PD
One more thing, I call this "scalable de-aggregation". It is a refinement of what first appeared in RFC6179. Thanks - Fred fred.l.temp...@boeing.com > -Original Message- > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin, > Fred L > Sent: Wednesday, June 08, 2016 2:52 PM > To: Nick Hilliard > Cc: ipv6-ops@lists.cluenet.de > Subject: RE: DHCPv6 relay with PD > > Hi Nick, > > More on this, please see Section 3.7 on the AERO Routing System (2 pages). It > tells > how the DHCPv6 relay can inject delegated prefixes into the routing system > without > imparting unacceptable churn and while allowing scaling to many millions of > delegated > prefixes. There is a terminology gap to overcome in that an "AERO Server" > actually > implements both a DHCPv6 server and relay, while an "AERO Relay" is a simple > BGP > router and does not implement any DHCPv6 functions. > > The section is only two pages long. Let me know if you have any questions or > comments. > > Fred > > > -Original Message- > > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > > [mailto:ipv6-ops- > > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin, > > Fred L > > Sent: Wednesday, June 08, 2016 2:35 PM > > To: Nick Hilliard > > Cc: ipv6-ops@lists.cluenet.de > > Subject: RE: DHCPv6 relay with PD > > > > Hi Nick, > > > > > -Original Message- > > > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > > > [mailto:ipv6-ops- > > > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick > > > Hilliard > > > Sent: Wednesday, June 08, 2016 2:13 PM > > > To: Templin, Fred L > > > Cc: ipv6-ops@lists.cluenet.de > > > Subject: Re: DHCPv6 relay with PD > > > > > > Templin, Fred L wrote: > > > > Folks, for real – read AERO. It works. I apologize if that offends > > > > anyone. > > > > > > Not at all. It's just that I'm confused about why we would need to > > > resort to a tunneling protocol in order to make basic ipv6 functionality > > > work. > > > > > > Would it not be better to try to make ipv6 work without resorting to > > > tunnels? > > > > Mobile clients that can change their point of attachment to the network and > > may be many hops away from the DHCPv6 relay are the primary use case that > > AERO is addressing. But, the way in which AERO manages the routing system > > I think applies even when tunnels aren't needed and the clients are on the > > same link as the relays. > > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > > > Nick
RE: DHCPv6 relay with PD
Hi Nick, More on this, please see Section 3.7 on the AERO Routing System (2 pages). It tells how the DHCPv6 relay can inject delegated prefixes into the routing system without imparting unacceptable churn and while allowing scaling to many millions of delegated prefixes. There is a terminology gap to overcome in that an "AERO Server" actually implements both a DHCPv6 server and relay, while an "AERO Relay" is a simple BGP router and does not implement any DHCPv6 functions. The section is only two pages long. Let me know if you have any questions or comments. Fred > -Original Message- > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin, > Fred L > Sent: Wednesday, June 08, 2016 2:35 PM > To: Nick Hilliard > Cc: ipv6-ops@lists.cluenet.de > Subject: RE: DHCPv6 relay with PD > > Hi Nick, > > > -Original Message- > > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > > [mailto:ipv6-ops- > > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick > > Hilliard > > Sent: Wednesday, June 08, 2016 2:13 PM > > To: Templin, Fred L > > Cc: ipv6-ops@lists.cluenet.de > > Subject: Re: DHCPv6 relay with PD > > > > Templin, Fred L wrote: > > > Folks, for real – read AERO. It works. I apologize if that offends anyone. > > > > Not at all. It's just that I'm confused about why we would need to > > resort to a tunneling protocol in order to make basic ipv6 functionality > > work. > > > > Would it not be better to try to make ipv6 work without resorting to > > tunnels? > > Mobile clients that can change their point of attachment to the network and > may be many hops away from the DHCPv6 relay are the primary use case that > AERO is addressing. But, the way in which AERO manages the routing system > I think applies even when tunnels aren't needed and the clients are on the > same link as the relays. > > Thanks - Fred > fred.l.temp...@boeing.com > > > Nick
Re: DHCPv6 relay with PD
Nick, >> It shouldn't be the IETF's job to tell people how to run their networks. >> The IETF provides the building blocks. > > Take a DHCP server, an ISP access router and a CPE. > > The CPE connects to the ISP access router and issues a dhcp request. > This is relayed by the access device to the dhcp server which replies to > access device with a PD reply. The access router relays this reply to > the CPE. > > At this point, the state is that both the CPE and the dhcp server know > the delegated prefix, but the access router does not. The result is > that the customer's prefix is not routed to the CPE. > > The question is: how do we make this work so that PD is a viable > mechanism for handling customer ipv6 requirements? > > The ISP operator cannot listen to the CPE if it's running a routing > protocol because the access router has no way of determining whether any > announcement it receives from the CPE is a legitimate announcement, > because it has no knowledge of what is or isn't assigned to a particular > customer. > > Installing static routes on the access router is non-scalable and > constrains the network architecture in a way which isn't feasible. > > It might work if the access router implements dhcpv6 snooping, but the > isp operator has little or no control over this. > > I know you're not trying to be unhelpful here, but brushing this off as > someone-else's-problem is not going to make the problem go away. Nor is > claiming that this is a problem with how the network is run, because > this isn't a problem that operators can feasibly fix because it's a > problem that vendors need to solve, potentially helped with some > guidelines from the ietf. oh absolutely agree, I didn't mean to imply that this was a problem caused by operators. I was more trying to say: "unfortunately snooping is the best we've got, and that's pretty obvious how to do, since vendors have done it for IPv4 for decades". I can't imagine vendors aren't supporting it for the reason that they don't understand how to implement it. given how butt ugly snooping is though, it's probably a mechanism that the IETF wouldn't be too keen on specifying. there are a lot of problems with snooping. inferring state as a man in the middle isn't easy. which is why RFC3633 only species PD for a client directly connected to a server. in the first implementation I worked on, we would then do a RADIUS lookup to get the prefix and install route. that's a lot easier to do acting as a server. how do you want it to work? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
RE: DHCPv6 relay with PD
Hi Nick, > -Original Message- > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick Hilliard > Sent: Wednesday, June 08, 2016 2:13 PM > To: Templin, Fred L > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: DHCPv6 relay with PD > > Templin, Fred L wrote: > > Folks, for real – read AERO. It works. I apologize if that offends anyone. > > Not at all. It's just that I'm confused about why we would need to > resort to a tunneling protocol in order to make basic ipv6 functionality > work. > > Would it not be better to try to make ipv6 work without resorting to > tunnels? Mobile clients that can change their point of attachment to the network and may be many hops away from the DHCPv6 relay are the primary use case that AERO is addressing. But, the way in which AERO manages the routing system I think applies even when tunnels aren't needed and the clients are on the same link as the relays. Thanks - Fred fred.l.temp...@boeing.com > Nick
Re: DHCPv6 relay with PD
Templin, Fred L wrote: > Folks, for real – read AERO. It works. I apologize if that offends anyone. Not at all. It's just that I'm confused about why we would need to resort to a tunneling protocol in order to make basic ipv6 functionality work. Would it not be better to try to make ipv6 work without resorting to tunnels? Nick
RE: DHCPv6 relay with PD
Folks, for real – read AERO. It works. I apologize if that offends anyone. Fred
Re: DHCPv6 relay with PD
Wait, Wait! So your telling me that it's wrong for DHCPv6 servers to feed default gateways to endpoints because "who better than the router to know whom to route too" but for DHCPv6-PD we should rely on the DHCPv6 servers to do route injection? This is classic! just classic! Take this back to the *Ivory Tower Population*(tm). What we need now are RA-PD packets! Down with DHCPv6 servers doing useful work. We are in danger of Non-Routing Personnel making Routing Decisions! Man the Battlements! Light the Fires! Heed the call of the RA-PDs! This must be done *Real Soon Now*(tm) On a more serious note. v6 has given us crippled DHCP servers but now it looks like we are going to need route injection servers just to do PD? time for v7. james On Wed, Jun 8, 2016 at 1:15 PM, Mikael Abrahamsson wrote: > On Wed, 8 Jun 2016, Ole Troan wrote: > > 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. >> > > Seems to me that IETF in this case failed to provide a suggestion for a > working solution. > > So neither equipment vendors nor network operators now have any kind of > recommendation on how to do things, and we now see that several vendors > have failed to implement DHCPv6-PD with routing in their equipment, and > network operators are now supposed to modify their DHCPv6 backend servers > to provision static routes in their routers? Is there even an IETF > recommendation document that says this is the way things should be done? > And that indentifies pitfalls in doing so? > > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se >
Re: DHCPv6 relay with PD
>>> 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. > > Seems to me that IETF in this case failed to provide a suggestion for a > working solution. > > So neither equipment vendors nor network operators now have any kind of > recommendation on how to do things, and we now see that several vendors have > failed to implement DHCPv6-PD with routing in their equipment, and network > operators are now supposed to modify their DHCPv6 backend servers to > provision static routes in their routers? Is there even an IETF > recommendation document that says this is the way things should be done? And > that indentifies pitfalls in doing so? an interesting twist of blaming the IETF. usually it's the IETF blaming the "market" that it doesn't adopt any of its more or less brilliant standards. ;-) if you want anything to happen here, write a draft. not that we have an RFC describing DHCPv4 snooping either, so I'd hope you come up with something clever! ;-) Best regards, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DHCPv6 relay with PD
Ole Troan wrote: > It shouldn't be the IETF's job to tell people how to run their networks. > The IETF provides the building blocks. Take a DHCP server, an ISP access router and a CPE. The CPE connects to the ISP access router and issues a dhcp request. This is relayed by the access device to the dhcp server which replies to access device with a PD reply. The access router relays this reply to the CPE. At this point, the state is that both the CPE and the dhcp server know the delegated prefix, but the access router does not. The result is that the customer's prefix is not routed to the CPE. The question is: how do we make this work so that PD is a viable mechanism for handling customer ipv6 requirements? The ISP operator cannot listen to the CPE if it's running a routing protocol because the access router has no way of determining whether any announcement it receives from the CPE is a legitimate announcement, because it has no knowledge of what is or isn't assigned to a particular customer. Installing static routes on the access router is non-scalable and constrains the network architecture in a way which isn't feasible. It might work if the access router implements dhcpv6 snooping, but the isp operator has little or no control over this. I know you're not trying to be unhelpful here, but brushing this off as someone-else's-problem is not going to make the problem go away. Nor is claiming that this is a problem with how the network is run, because this isn't a problem that operators can feasibly fix because it's a problem that vendors need to solve, potentially helped with some guidelines from the ietf. Nick
Re: DHCPv6 relay with PD
On Wed, 8 Jun 2016, Ole Troan wrote: 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. Seems to me that IETF in this case failed to provide a suggestion for a working solution. So neither equipment vendors nor network operators now have any kind of recommendation on how to do things, and we now see that several vendors have failed to implement DHCPv6-PD with routing in their equipment, and network operators are now supposed to modify their DHCPv6 backend servers to provision static routes in their routers? Is there even an IETF recommendation document that says this is the way things should be done? And that indentifies pitfalls in doing so? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: DHCPv6 relay with PD
Hi, > -Original Message- > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Erik Kline > Sent: Wednesday, June 08, 2016 11:37 AM > To: Ole Troan > Cc: IPv6 Ops list ; Mikael Abrahamsson > > Subject: Re: DHCPv6 relay with PD > > On 9 June 2016 at 03:16, Ole Troan 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. AERO provides operational guidance on collections of blocks that work: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thanks - Fred
Re: DHCPv6 relay with PD
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. Cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
RE: DHCPv6 relay with PD
Hi, > -Original Message- > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Gert Doering > Sent: Wednesday, June 08, 2016 4:37 AM > To: Ole Troan > Cc: ipv6-ops@lists.cluenet.de; Mikael Abrahamsson > Subject: Re: DHCPv6 relay with PD > > Hi, > > On Wed, Jun 08, 2016 at 12:39:03PM +0200, Ole Troan wrote: > > > I've talked to several people who claim there are lots of equipment out > > > there which will happily do DHCPv6 relaying of PD > messages, but then not install a route for the corresponding delegation. > > > > That's perfectly fine behaviour by the way. > > DHCPv6 PD snooping is just one way of doing route injection, among many. > > Of course the client device could use OSPFv3 or BGP to inject the newly > acquired prefix into the routing system... but is this a realistic case, > either for Lorenzo's wifi case, or for PE-CPE environments? Add static route and inject into BGP is exactly the way AERO works. Thanks - Fred fred.l.temp...@boeing.com > What "other ways" did you have in mind? > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: DHCPv6 relay with PD
On Wed, 8 Jun 2016, Ole Troan wrote: 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? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6 relay with PD
Hi, On Wed, Jun 08, 2016 at 12:39:03PM +0200, Ole Troan wrote: > > I've talked to several people who claim there are lots of equipment out > > there which will happily do DHCPv6 relaying of PD messages, but then not > > install a route for the corresponding delegation. > > That's perfectly fine behaviour by the way. > DHCPv6 PD snooping is just one way of doing route injection, among many. Of course the client device could use OSPFv3 or BGP to inject the newly acquired prefix into the routing system... but is this a realistic case, either for Lorenzo's wifi case, or for PE-CPE environments? What "other ways" did you have in mind? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: DHCPv6 relay with PD
Mikael, >>> I've talked to several people who claim there are lots of equipment out >>> there which will happily do DHCPv6 relaying of PD messages, but then not >>> install a route for the corresponding delegation. >> >> That's perfectly fine behaviour by the way. >> DHCPv6 PD snooping is just one way of doing route injection, among many. > > Ok, I invoke https://en.wikipedia.org/wiki/Principle_of_least_astonishment > > Does the DHCPv6-PD server backend have access to all information needed to > trigger a provisioning system to install/remove a static route on the relay? > > What other methods are there apart from provisioning a static route on the > relay? BGP? At least these: https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 The PD relay doesn't have to be on the path, and certainly it doesn't have to be the only router on the path. In the DHC working group we failed to standardise an engineered solution to pass options directly to the relay. At the time 3633 was written snooping was not considered a good approach (And also one which would fail in case of encryption). 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? ;-) Cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DHCPv6 relay with PD
On Wed, 8 Jun 2016, Ole Troan wrote: I've talked to several people who claim there are lots of equipment out there which will happily do DHCPv6 relaying of PD messages, but then not install a route for the corresponding delegation. That's perfectly fine behaviour by the way. DHCPv6 PD snooping is just one way of doing route injection, among many. Ok, I invoke https://en.wikipedia.org/wiki/Principle_of_least_astonishment Does the DHCPv6-PD server backend have access to all information needed to trigger a provisioning system to install/remove a static route on the relay? What other methods are there apart from provisioning a static route on the relay? BGP? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6 relay with PD
> I've talked to several people who claim there are lots of equipment out there > which will happily do DHCPv6 relaying of PD messages, but then not install a > route for the corresponding delegation. That's perfectly fine behaviour by the way. DHCPv6 PD snooping is just one way of doing route injection, among many. Ole > > One example seems to be HP 5400zl. > > My own experience is only when I did this with a DOCSIS CMTS, which did > install a static route properly. The two other examples I have are with > DHCPv6(-PD) server running on the L3 device itself (no relaying), a Huawei > 5300 L3-switch and a Cisco 7206 router. Both of them properly installed that > corresponding static route as soon as the DHCPv6-PD process had completed the > delegation. > > I'm looking for experience with other equipment, please share! > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DHCPv6 relay with PD
I saw Nokia (ALU) 7750 SRs not relaying already relayed DHCPv6 messages from a LDRA. That needed a newer software version to fix. Ross Sent from my Samsung device Original message From: Mikael Abrahamsson Date: 02/06/2016 2:11 PM (GMT+00:00) To: ipv6-ops@lists.cluenet.de Subject: DHCPv6 relay with PD Hi, I've talked to several people who claim there are lots of equipment out there which will happily do DHCPv6 relaying of PD messages, but then not install a route for the corresponding delegation. One example seems to be HP 5400zl. My own experience is only when I did this with a DOCSIS CMTS, which did install a static route properly. The two other examples I have are with DHCPv6(-PD) server running on the L3 device itself (no relaying), a Huawei 5300 L3-switch and a Cisco 7206 router. Both of them properly installed that corresponding static route as soon as the DHCPv6-PD process had completed the delegation. I'm looking for experience with other equipment, please share! -- Mikael Abrahamsson email: swm...@swm.pp.se
Re: DHCPv6 relay with PD
> 2 juni 2016 kl. 15:11 skrev Mikael Abrahamsson : > > > Hi, > > I've talked to several people who claim there are lots of equipment out there > which will happily do DHCPv6 relaying of PD messages, but then not install a > route for the corresponding delegation. > > One example seems to be HP 5400zl. > > My own experience is only when I did this with a DOCSIS CMTS, which did > install a static route properly. The two other examples I have are with > DHCPv6(-PD) server running on the L3 device itself (no relaying), a Huawei > 5300 L3-switch and a Cisco 7206 router. Both of them properly installed that > corresponding static route as soon as the DHCPv6-PD process had completed the > delegation. > > I'm looking for experience with other equipment, please share! Cisco 4500 with unknown superwisor should do that. I hope to test it next week but it will be in august if I don’t manage to test it next week. /Tobbe > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se signature.asc Description: Message signed with OpenPGP using GPGMail
