[dhcwg] Re: [v6ops] Re: Re: New draft: DHCPv6 Reco mmended IPv6 Address Option

Michael

I agree that reducing the FIB overhead at ISPs important.

This really can be accomplished with a highly efficient subnet plan for
each specific situation (different ISPs have some different contexts). I
would argue, we don't need “ia_pd_only” for SP world to have clean routing
table internally. I've also seen some end-user CPEs in the wild failing to
talking IPv6 to the internet with just ia_pd, even though, it should be
working, they seem to mandate ia_na (or SLAAC) requirement.

One of the common concerns across both SP and CSP world I've heard is PtP
link subnets (some do /127s some like me do clean /64 per link etc)
overpopulating the internal table, but this can be solved with a
hierarchical aggregate parent per device type based on function (P vs PE,
DFZ-PE vs DIA-PE vs BNG etc), out of which, in the IGP (or BGP) we filter
out locally connected routes to export only the aggregate to
adjacent neighbours, so if a device wants to export 100 connected routes,
that would be only 1 aggregate route (not to be conflated with IGP
summarisation).

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.shortlink.es/l/25d7192a2f6eebf912d79c25cbd0773aa0e75ee5?u=2153471>


On Fri, 4 Jul 2025 at 23:13, Michael Richardson <[email protected]>
wrote:

>
> Lorenzo Colitti <[email protected]> wrote:
>     > I read the draft and it seems useful for clients that implement
> DHCPv6
>     > PD.
>
> I haven't read it yet, but I will.
> Erik, are you in a position to implement this option in CE and ISP?
>
>     > It would probably make sense for the draft to say when networks
> should
>     > use this option instead of IA_NA. Your email mentions that this
> option
>     > avoids the need for separate FIB entries for the IA_NA and
>     > IA_PD. Presumably another reason would be that it simplifies client
>     > code, because the client does not need to manage the lifetimes of and
>     > renew the address(es) independently from the prefix. I'd guess maybe
>     > it's possible that there are clients that don't implement IA_NA.
>
>     > It occurs to me that this could be used for IPv6 CE routers as well.
> CE
>     > routers always need to run DHCPv6 PD, and ISP-managed CE routers
>     > additionally need to use IA_NA to get an address on which they can be
>     > managed. This option could be used instead.
>
> Is there a reason that the IA_NA assigned address couldn't be within the
> PD?
> I had a document awhile ago about communicating within IP6CP (for PPPoE)
> about the CE's DHCP/RA capabilities, so that the "WAN" link could remain
> unnumbered if possible, with the CE taking an address within the PD
> allocated.
> {Cable connections where the WAN link is a flatish emulated ethernet, would
> need to allocate addresses on that link anyway, so no savings, but also
> potentially one /64 per neighbourhood}
>
> That would turn off RAs on the WAN link, because the CE didn't need that.
> I stopped working on that document, because I no longer worked on BMCs, so
> couldn't implement.
>
> I agree that reducing the FIB overhead at ISPs important.
>
> --
> Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> v6ops mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]