Re: DHCPv6 PD & Routing Questions

[Owen DeLong <owen () delong com>]

> On Dec 6, 2015, at 08:45 , Baldur Norddahl <baldur.norddahl () gmail com> wrote:
>
> On 6 December 2015 at 06:18, Mark Andrews <marka () isc org> wrote:
>
> > > Are you really suggesting that a residential ISP accept routes advertised
> > > from their customer’s CPE? Really?
> >
> > PD is used internally as well as externally, and with a little bit
> > of crypto to prove the assigned address belongs to them there really
> > isn't a reason a CPE device couldn't announce a address to a ISP.
> > It would also allow BCP38 filters to be built rather than using RFP
> > which is only a approximate solution.
>
> Do you envision that the CPE runs OSPFv3 or something else? Would that
> scale? I am not an OSPF expert, but thousands of CPEs in an OSPF domain
> does not sound like a sane thing.

As an alternative worth considering, it could do this with BGP instead of OSPF.

There’s nothing mythical or magical about BGP. A CPE autoconfiguring itself
to advertise the prefix(es) it has received from upstream DHCPv6 server(s)
to it’s neighbors is not rocket science. In fact, this would mean that the CPE
could also accept a default route via the same BGP session and it could
even be used to enable automatic failover for mulihomed dynamically addressed
sites.

Sure, this requires modifying the CPE, but not in a particularly huge way and
it provides a much cleaner and more scaleable solution for the ISP side of the
equation than OSPF.

Most current implementations use RIPv2, but we all know just how icky that is.

> What is the advantage? The prefix has been assigned to the CPE. If the CPE
> does not advertise the prefix it just goes to the null route. What is the
> use case where you want a prefix assigned to a CPE but _not_ routed to the
> same CPE?

_not_ routed is not the only consideration here.

routed via alternative paths may be worthy of consideration.

Owen