[v6ops] Re: Dynamic addresses

[[e-mail]]

Hi,

Von: Daryll Swer <contact=[e-mail]>
Gesendet: Montag, 12. August 2024 06:07
An: Brian Candler <[e-mail]>
Cc: The Multach's <[e-mail]>; [e-mail]
Betreff: [v6ops] Re: Dynamic addresses


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).
That's what we are doing as well. We aggregate on the BNG and assign addresses
(IPv4 and IPv6) from the address pools of the BNG. For residential users
those addresses are dynamic.

For business customers requiring a static address/prefix we backhaul them
to a different set of BNGs providing static addresses. Those BNGs have
their own pools for static assignments and allow to use the same, static address
even in case users are moving within our network (e.g., from one city to
another city).

> 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.

Regards

Nic


On Sun, 11 Aug 2024 at 17:34, Brian Candler <[e-mail]<mailto:[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.