Re: A common problem with SLAAC in "renumbering" scenarios

[Michael Richardson <[e-mail]>]

Mikael Abrahamsson <[e-mail]> wrote:
    >> I think a lot of this need in IPv4 has come from IPv4 addresses being
    >> precious and expensive resources. Consequently, it has been worth the
    >> expense and effort of fine grained management of them.
    >>
    >> In IPv6, that level of management isn't needed. Addresses are
    >> plentiful and cheap, so you can throw lots of address space at
    >> problems.

    > It's sometimes from re-farming of things. ISPs tend to today build
    > largish access-routers and call them BNG. So when a 10GE interface is
    > full, you need to split the customer load to two interfaces, or move
    > some to a completely different router.

    > So if you move half of the subscribers of that port to a different
    > router, now you have a problem because typically you'll have a set of
    > addreses-space dedicated for that router and part of that now needs to
    > go to another router. Typically you don't want this type of
    > de-aggregation.

With VDSL2 speeds approaching 100Mb/s, and FTTH going way higher (while
sometimes still using PPPoE), 10GE ports don't carry that many subscribers.

You don't want to dedicate address space for a specific BNG.
I've seen two situations: the BNGs are cheapish, and you run n+1 redundancy
on them, and just keep growing n.  The ISP puts a L3 router in front, and
*that* router gets the big prefix.  Radius can allocate from a pool for
that location, and then lock it down in a database.

One needs to use a routing protocol between the BNGs and the router,
but in OSPF terms, one should make that an area, so /48s don't leak all over
the place.  Maybe we need a BCP that explains all of this?
Seems like more of a RIPE thing?

The other way is that BNGs are expensive silicon filled boxes with multiple
100GE ports, and they are typically limited in terms of number of sessions.
This solution sucks if you are doing 7Mb/s ADSL, because you are limited
by sessions.  It's typically still expensive on a per-customer basis though.
And you have have n+1 redundancy, and having two BFRs per POP is probably
too expensive.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-