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

[Michael Richardson <[e-mail]>]

Jan Zorz - Go6 <[e-mail]> wrote:
    >> This creates two routes per customer.

    > Ya, I know... Usually this has been handled with creating a pool of IPv6
    > addresses per each BRAS/BNG where /64-s were allocated for each
    > connecting CPE to number the WAN link. Experience shows that dynamic
    > changing of the WAN addressing does not bring much pain, as does
    > changing of addressing in the networks behind CPE. In this way you have
    > just one route towards BRAS/BNG for that pool of "WAN link" addresses.

So half dynamic, and half-static via PD.
It's not a bad a solution, particularly because it feels more efficient
From an address point of view if you have a lot of these single-host
networks:

    > I was surprised to discover how many people still connects to the
    > internet with one host that does the PPPoE connection (Windows, etc)
    > and in this case
    > - not numbering the WAN link would leave this hosts without any IPv6
    > addresses.

    > However, to be honest, I never tried what happens if you connect with a
    > single host PPPoE client that can't do PD and the system on the other end
    > does just prefix exclude option. Would that host still remain without any
    > IPv6 addresses? Hmm...

I don't know either.
That's why I think we need to single the network scenario at the IP6CP,
thus the document that we have been discussing in a private thread.

    >> and IPv6 work exactly the same at that point.  They just didn't
    >> remember that
    >> IPv4 was hiding the same state in what they think of as layer 2.

    > Good point ;)

Also, by "hiding", I also mean: not making the state visible, auditable,
or easily monitored as to how full it is.  While the ARP cache is a *cache*,
and can be reconstructed, if it's full, and you have >cache number of
customers, then each time a customer gets more traffic, a different
customer goes offline.  It's usually completely invisible to network
operations.

Stupid layer-2 tricks that IPv6 eliminates.

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