Mailing List Archive

> 2 juni 2016 kl. 15:11 skrev Mikael Abrahamsson <swmike@swm.pp.se>:
>
>
> 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 Abrahamsson email: swmike@swm.pp.se

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 <swmike@swm.pp.se>
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: swmike@swm.pp.se

> 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 Abrahamsson email: swmike@swm.pp.se

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 Abrahamsson email: swmike@swm.pp.se

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

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 AG Vorstand: 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

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 Abrahamsson email: swmike@swm.pp.se

Hi,

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Gert Doering
> Sent: Wednesday, June 08, 2016 4:37 AM
> To: Ole Troan <ot@cisco.com>
> Cc: ipv6-ops@lists.cluenet.de; Mikael Abrahamsson <swmike@swm.pp.se>
> 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.templin@boeing.com

> What "other ways" did you have in mind?
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG Vorstand: 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

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

On 9 June 2016 at 03:16, Ole Troan <ot@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.

Hi,

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Erik Kline
> Sent: Wednesday, June 08, 2016 11:37 AM
> To: Ole Troan <ot@cisco.com>
> Cc: IPv6 Ops list <ipv6-ops@lists.cluenet.de>; Mikael Abrahamsson <swmike@swm.pp.se>
> Subject: Re: DHCPv6 relay with PD
>
> On 9 June 2016 at 03:16, Ole Troan <ot@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.

AERO provides operational guidance on collections of blocks that work:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred

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 Abrahamsson email: swmike@swm.pp.se

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

>>> 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

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 <swmike@swm.pp.se> 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 Abrahamsson email: swmike@swm.pp.se
>

Folks, for real – read AERO. It works. I apologize if that offends anyone.



Fred

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

Hi Nick,

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Nick Hilliard
> Sent: Wednesday, June 08, 2016 2:13 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> 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.templin@boeing.com

> Nick

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

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.com@lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Templin, Fred L
> Sent: Wednesday, June 08, 2016 2:35 PM
> To: Nick Hilliard <nick@foobar.org>
> Cc: ipv6-ops@lists.cluenet.de
> Subject: RE: DHCPv6 relay with PD
>
> Hi Nick,
>
> > -----Original Message-----
> > From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> > bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Nick Hilliard
> > Sent: Wednesday, June 08, 2016 2:13 PM
> > To: Templin, Fred L <Fred.L.Templin@boeing.com>
> > 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.templin@boeing.com
>
> > Nick

One more thing, I call this "scalable de-aggregation". It is a refinement of what
first appeared in RFC6179.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Templin, Fred L
> Sent: Wednesday, June 08, 2016 2:52 PM
> To: Nick Hilliard <nick@foobar.org>
> 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.com@lists.cluenet.de [mailto:ipv6-ops-
> > bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Templin, Fred L
> > Sent: Wednesday, June 08, 2016 2:35 PM
> > To: Nick Hilliard <nick@foobar.org>
> > Cc: ipv6-ops@lists.cluenet.de
> > Subject: RE: DHCPv6 relay with PD
> >
> > Hi Nick,
> >
> > > -----Original Message-----
> > > From: ipv6-ops-bounces+fred.l.templin=boeing.com@lists.cluenet.de [mailto:ipv6-ops-
> > > bounces+fred.l.templin=boeing.com@lists.cluenet.de] On Behalf Of Nick Hilliard
> > > Sent: Wednesday, June 08, 2016 2:13 PM
> > > To: Templin, Fred L <Fred.L.Templin@boeing.com>
> > > 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.templin@boeing.com
> >
> > > Nick

On 6/8/16 20:37 , Erik Kline wrote:
> On 9 June 2016 at 03:16, Ole Troan <ot@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

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 <ot@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