[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

N.Leymann

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

IPv4 is exhausted resource, charging static makes sense. IPv6 isn't
exhausted last I checked, charging it for the very single prefix static
(/56 for residential, /48 enterprise) is just nothing short of greed. Small
WISPs and ISPs around the world in much lower economies can afford free
single prefix static for IPv6. It's very strange, large Telcos and ISPs
with multi-million dollar revenue and net profits can't afford to give
static *single* ia_pd for residential (/56) and enterprise (/48) for free.

This ties in nicely with the “Pay to remove firewall on IPv6” for mobile
networks. Next up, charge separately for IPv6 full table export vs default
route export, charge separately for inet6 MTU changes on the NNI port all
this is surely helping global IPv6 adoption and removal of IPv4 from the
DFZ (sarcasm intended).

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


On Fri, 16 Aug 2024 at 16:14, <[e-mail]> wrote:

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