Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device

[Nick Buraglio <[e-mail]>]

> On Jul 31, 2023, at 2:28 PM, Ole Trøan <[e-mail]> wrote:
>
>> We should probably talk through how the route is installed as well and decide if that guidance needs to be in the document as well.
>
> While I think rfc7078 mostly says what is needed for addressing, routing is a different matter.
>
> In any more complex topology than the requesting router being directly connected to the delegating router, the closest relay to the requesting router has to do snooping and then insert the prefix into a routing protocol.
>
> Finally a chance to make the requesting router responsible for the relay state and a verification of forwarding state as described in Markus’ document 2.3.2.
>
> https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00
>
> [IPv6 Prefix Delegation routing state maintenance approaches](https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00)
> [datatracker.ietf.org](https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00)	[<ietf-logo-nor-180.png>](https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00)
> All routers would have to be manually configured to be dhcp relays with snooping enabled.
> Unsure if there are some corner cases if the topology isn’t a DAG.
>
> What did you have in mind?

I was speaking more to how the host default route is installed on the receiving device, but the upstream routing is important, too. Section 5.1 covers the PD routing upstream of the host within the existing network by relying on RFC8978, I believe.
I think it’s as easy as simply requesting only a PD and not an address but that has been problematic since I have to mess with what to source the host traffic from. Once I get a change to sort that out I am guessing it won’t be an issue, but we’ll see.

> O.