[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

>
> Getting a new IPv4/IPv6 allocation on session disconnect and reconnect
> is a matter of network design.  If the network design is that aggregate
> address pools are routed to BRASes, and the end user's address is
> allocated by the BRAS from its pool, then when you reconnect to a
> different BRAS you'll get a different address. So be it.


Yeah, they/we typically route an aggregate pool to the BRAS/BNG. But also,
they are configured in HA mode with VRRP etc and the pools do not change.
If they did change, we now have the problem with connectivity stability
again, and this brings up the old conversation about DHCPv6 HA (vendors
solved it, to my knowledge, using proprietary software).

Sure in large enough networks, it's possible for an MPLS network that
carries the OLTs, to have multiple paths to different set of BNGs, but in
this day and age of automation, it wouldn't be hard to lift the aggregate
from old *dead* BNG pair, to new *live* BNG pair, ensuring customer
prefixes do not change at all.

I'm afraid I don't see what any of this has to do with IPv6: the same
> issue applies for whether you keep your same IPv4 address or not.
>

IPv4 doesn't have this issue. When a customer pays for a static *IPv4*,
that IP is permanently static even across BNGs groups (automation in their
backend would move the IPs around if required, god forbid, it's manually
done).

But come to IPv6 and most (exception always exists) ISPs globally, refuse
to give a /56 ia_pd static free or paid. I'm personally really tired of
this attitude from ISPs, i.e. the IPv4-centric attitude.

If the ISP forces a new IPv4/IPv6 address periodically while your
> session is established, that is clearly stupid, whether or not it is
> mandated by government (although Citation Needed, as Wikipedia would say)


However, I don't think RFCs can enumerate all the possible stupid things
> that a provider or government might choose to do, and suggest that they
> SHOULD NOT or MUST NOT do it.


Can't enumerate everything, but probably can enumerate and reiterate
BCOP-9690 for persistent static ia_pd with minimum /56 pref length.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/f52f3d9970f63c529dd1e4d712ea08d2b44a3596?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=60bfb695f9f2f13a>


On Sun, 11 Aug 2024 at 17:34, Brian Candler <[e-mail]> wrote:

> On 11/08/2024 03:09, David Farmer wrote:
> > That being said, whether or not to maintain the same prefix across
> > reboots should be in control of the end user, not necessarily the CPE
> > manufacturer or the ISP. Only the end user knows if their use case is
> > advantaged or disadvantaged by getting a new prefix on power loss or
> > other reboots.
>
> I'm afraid I don't see what any of this has to do with IPv6: the same
> issue applies for whether you keep your same IPv4 address or not.
>
> Getting a new IPv4/IPv6 allocation on session disconnect and reconnect
> is a matter of network design.  If the network design is that aggregate
> address pools are routed to BRASes, and the end user's address is
> allocated by the BRAS from its pool, then when you reconnect to a
> different BRAS you'll get a different address. So be it.
>
> If the ISP forces a new IPv4/IPv6 address periodically while your
> session is established, that is clearly stupid, whether or not it is
> mandated by government (although Citation Needed, as Wikipedia would say)
>
> However, I don't think RFCs can enumerate all the possible stupid things
> that a provider or government might choose to do, and suggest that they
> SHOULD NOT or MUST NOT do it.
>
>