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