DHCPv6 relay with PD

[james machado]

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 at 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 at swm.pp.se
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20160608/5c4b8ace/attachment.htm>