[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

Brian

> You don't specify where "over here" is, but it doesn't matter really -
the message is that there is immense variation on this point**. *Because of
this variability, stable prefixes can't be the wrong solution.*

Exactly, the precise location is 100% irrelevant to the point/issue at hand
(dynamic prefix vs static prefix). You can't go wrong with stable (static)
prefixes, but there's a lot of wrong that can go with dynamic prefixes.

> In rural NZ it can be pretty unreliable, and when it goes down, it's down
for much longer than any consumer UPS can handle.

I'm not an electrical engineer, but over here (India), we use sine-wave
inverters with non-lithium batteries (Tubular batteries are common, but
there are other options), my own personal family home has had no trouble
with close-to 20 hours coverage. With the right electrical engineer who
does the planning, wiring and installation, you can go 24+ hours on the
heavy-duty batteries (battery farm basically) and inverters AND if we are
discussing rural, then, we combine inverters + generators/solar/wind. Some
folks argue for a UPS, I personally never had the switch-over time of
modern inverters failing my network gear, so there's no UPS for me.

If anything, my in-home electronics have more up-time than the ISP's OLTs
(here, everything is PON for residential).

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


On Sun, 11 Aug 2024 at 07:46, Brian E Carpenter <[e-mail]>
wrote:

> Daryll,
>
> > Not sure how electrical systems are built in the west, but over here,
> even lower-income households have inverters (or UPS) in place,
>
> You don't specify where "over here" is, but it doesn't matter really - the
> message is that there is immense variation on this point**. Because of this
> variability, stable prefixes can't be the wrong solution.
>
> ** Over _here_ (urban NZ) the mains power is pretty reliable where it's
> undergrounded, and mainly reliable where it's on poles. In rural NZ it can
> be pretty unreliable, and when it goes down, it's down for much longer than
> any consumer UPS can handle.
> https://youtu.be/RvSctdbRiZg
> (In some remote areas the only solution turns out to be Starlink and a
> generator.)
>
> Regards
>     Brian Carpenter
>
> On 11-Aug-24 09:44, Daryll Swer wrote:
> > David
> >
> >     Changing the prefix delegation on power failure of the CPE generally
> has a fairly low impact, as the devices using the network frequently loose
> power as well and are rebooted. And, even if they don’t loose power they
> typically loose link, which is also a signal to reestablish their addresses.
> >
> > Not sure how electrical systems are built in the west, but over here,
> even lower-income households have inverters (or UPS) in place, i.e. the
> CPE, and client devices connected over Wi-Fi do *not* lose power and the
> Wi-Fi interface *stays up*, upstream OLT comes back up/quick fibre patching
> done, and now the clients have broken IPv6 connectivity for X amount of
> minutes/hours depending on pref/valid values.
> >
> > Again, this isn't theoretical, I see this in real life, ALL the time,
> and if you do a quick Google search using this precise search time, plenty
> of other users reported it:
> > “Dynamic IPv6 breaks SLAAC”.
> >
> > As a consultant, I also get these complaints from unaware ISPs' business
> owners and C-suites, who didn't know about BCOP-690 and static ia_pd, I,
> moved them to static ia_pd, lo and behold — customer complaints about
> broken (v6) connectivity, stopped spamming their ticketing software.
> >
> > Nothing about my feedback on this is “hypothetical”, this is all IRL.
> >
> >     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 agree on this aspect. I am not a protocol designer, but if I was, I'd
> be keenly interested in potentially augmenting both ia_na and ia_pd with a
> “privacy” flag, whereby if the user sets it to 1, they can set a timer to
> renew (per 24 hours, months etc), and the server will feed a fresh ia_na
> and ia_pd that ways. And if the user sets privacy flag = 0, the ia_na and
> ia_pd is permanently (lifetime) static. Probably good to augment it
> further, where privacy flag is independent for each (na, pd), along with
> independent timers giving the user complete control and making the life of
> the ISP and CPE maker, simpler.
> >
> >     Nevertheless, permanent addresses, unchanging for an extended
> periods of time like months or years, is a threat to privacy, it makes
> tracking trivial.
> >
> >
> > This is an arguable/argumentative topic — i.e. “privacy” and “IPs”. Most
> analytics/tracking software rely on system, browser fingerprinting,
> invasive cookies, and even battery API <
> https://eprint.iacr.org/2015/616.pdf> to track users — a lot of
> motivation came for this, from mobile devices where the end-user moves
> between Wi-Fi networks and mobile networks 24/7. Analytics had to figure
> out a way to identify/track the users across different Wi-Fi/Mobile
> networks, and therefore by design can do so even with dynamic IPs.
> >
> > *--*
> > Best Regards
> > Daryll Swer
> > Website: daryllswer.com <
> https://mailtrack.io/l/7070cf174482cea593104513e38e67dd0d19e934?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b99c4df5e4efd1b8
> >
> >
> >
> > On Sun, 11 Aug 2024 at 02:39, David Farmer <farmer=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     I just want to say that I agree simply changing addresses,
> particularly forcing address changes periodically, does not provide privacy
> by itself and doesn’t prevent tracking.
> >
> >     Nevertheless, permanent addresses, unchanging for an extended
> periods of time like months or years, is a threat to privacy, it makes
> tracking trivial.
> >     Changing the prefix delegation on power failure of the CPE generally
> has a fairly low impact, as the devices using the network frequently loose
> power as well and are rebooted. And, even if they don’t loose power they
> typically loose link, which is also a signal to reestablish their addresses.
> >
> >     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.
> >
> >     Thanks.
> >
> >     On Sat, Aug 10, 2024 at 10:15 Daryll Swer <contact=
> [e-mail] <mailto:[e-mail]>>
> wrote:
> >
> >         Ted
> >
> >          > It sounds like the isps who you know of who are doing this
> are not following the rfcs. That makes it cheaper, and makes it break IPv6
> for the end user.
> >
> >         *Most*, ISPs don't conform to RFCs, BCPs and BCOPs. As a
> consultant, I get exposed (They email me their diagrams and configs for
> review) to tens of networks every year, and I can count on one hand, how
> many networks conform to the minimum for networking in general (IPv4 vs
> IPv6 aside).
> >
> >         That's why I think the "draft-ietf-v6ops-cpe-lan-pd" should
> potentially, have something to give to end-users for them to use against
> such ISPs, in order for these users to get a permenaent ia_pd (/56 minimum
> or /48 maximum) via support tickets, asking the ISP to conform.
> >
> >         *--*
> >         Best Regards
> >         Daryll Swer
> >         Website: daryllswer.com <
> https://mailtrack.io/l/713f3f681113f0bfb34c34bcf30460679e5a5347?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=fe00cdb4ee3ab02c
> >
> >
> >
> >         On Sat, 10 Aug 2024 at 19:53, Ted Lemon <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >             At least in Germany the address shifting was a regulatory
> thing—the isp I was working with on it didn’t want to do it—it was
> expensive and inconvenient.
> >
> >             It sounds like the isps who you know of who are doing this
> are not following the rfcs. That makes it cheaper, and makes it break IPv6
> for the end user.
> >
> >             Op za 10 aug 2024 om 10:10 schreef Daryll Swer <
> [e-mail] <mailto:[e-mail]>>
> >
> >                  > Then again, there is a claim that on those you may
> not get a prefix at all (just a single IP6 address), and if you do, often
> its a /64 with no PD.
> >
> >                 IIRC, US Telcos even have separate billing for mobile
> tethering/hotspot, right? And IPv6 doesn't always work over that ways?
> >
> >                 Over here, it appears the tethering interface just
> bridges with the PDP interface, and the “clients” that connects gets a /128
> GUA, shared with a single /64 with the SIM.
> >
> >                  > For security reasons, one of them has a rule to
> change the assigned IPv6 address space at least once every 4 hours.
> >
> >                 You mean conspiracy theories about big bro and
> “privacy”… It's not “security”.
> >
> >                 iPhones have built-in security, Ted Lemon can probably
> elaborate on that. Android, too, has built-in security, the Google folks
> here can probably elaborate on that.
> >
> >                 Nope, I am completely against conspiracy theories about
> “dynamic IP stops big bro from spying on you”. If big bro wants to “spy” on
> you, no amount of “dynamic IPs” is stopping that.
> >
> >                 *--*
> >                 Best Regards
> >                 Daryll Swer
> >                 Website: daryllswer.com <
> https://mailtrack.io/l/ba62818f368e4ab91c6676b1a01e6088ea674e45?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b8dfc4abc306b3d8
> >
> >
> >
> >                 On Sat, 10 Aug 2024 at 19:29, The Multach's <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >                     __
> >
> >                     That triggered a memory about addressing on US
> cellular carriers, at least one of which does this.
> >
> >                     Then again, there is a claim that on those you may
> not get a prefix at all (just a single IP6 address), and if you do, often
> its a /64 with no PD.
> >
> >                     For security reasons, one of them has a rule to
> change the assigned IPv6 address space at least once every 4 hours.
> >
> >
> >                     On 8/9/2024 9:33 PM, Brian E Carpenter wrote:
> >>                     On 10-Aug-24 11:34, Daryll Swer wrote:
> >>>                      > But I don't understand the statement "breaks
> SLAAC on the LAN". A change of prefix renumbers the LAN, but that doesn't
> break SLAAC, it just causes SLAAC to renumber everything. It will only
> break active sessions.
> >>>
> >>>                     It will break, on the host side, because they
> won't know to use the new prefix, until the pref/valid values expire.
> >>>
> >>>
> https://www.6connect.com/blog/is-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router/
> <
> https://www.6connect.com/blog/is-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router/>
>
> >>
> >>                     Thanks, yes, I knew that of course but the
> description of that as breaking SLAAC confused me. (When my ISP was
> changing prefixes after a CE power cut and reboot, the issue was masked by
> other effects of the power cut.)
> >>
> >>>                     There's no reason to be promoting dynamic v6
> prefixes, in addition to the SLAAC context, this makes it painful, for
> end-users to host anything at home, even basic SSH.
> >>
> >>                     I completely agree.
> >>
> >>                        Brian
> >>
> >>>
> >>>                     *--*
> >>>                     Best Regards
> >>>                     Daryll Swer
> >>>                     Website: daryllswer.com <http://daryllswer.com> <
> https://mailtrack.io/l/8b190af15371d42cba28cde7db9581f1c207dde9?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=0564b87de4f69994>
> <
> https://mailtrack.io/l/8b190af15371d42cba28cde7db9581f1c207dde9?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=0564b87de4f69994
> >
> >>>
> >>>
> >>>                     On Sat, 10 Aug 2024 at 04:56, Brian E Carpenter <
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>> wrote:
> >>>
> >>>                         [Public service announcement: as of now, I'm
> spam-filtering messages with 'Digest' subject headers.]
> >>>
> >>>                         My ISP used to change my prefix whenever there
> was a power cut and the modem restarted. Now, it appears to be stable.
> >>>
> >>>                         But I don't understand the statement "breaks
> SLAAC on the LAN". A change of prefix renumbers the LAN, but that doesn't
> break SLAAC, it just causes SLAAC to renumber everything. It will only
> break active sessions.
> >>>
> >>>                         Regards
> >>>                              Brian
> >>>
> >>>                         On 10-Aug-24 10:13, Ted Lemon wrote:
> >>>                          > In order to do this, they would have to not
> renew a previously assigned prefix. I think some German telecoms used to do
> this as a privacy message, but it was operationally very difficult because
> it doubled demand for prefixes.
> >>>                          >
> >>>                          > Where are you seeing this irl, and how does
> it happen?
> >>>                          >
> >>>                          > Op vr 9 aug 2024 om 15:08 schreef Daryll
> Swer <contact=[e-mail] <mailto:contact=
> [e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:
> [e-mail]>>>
> >>>                          >
> >>>                          >     Tim, is there something we can do to
> encourage not only "more than a /64", but also encourage "static ia_pd to
> ensure the customer will not experience broken IPv6 connectivity due to
> ever changing prefixes".
> >>>                          >
> >>>                          >     Too many ISPs out there do dynamic IPs
> and breaks SLAAC on the LAN.
> >>>                          >
> >>>                          >     I feel this draft could be a powerful
> tool, in the hands of the end user to get these ISPs doing the right way of
> IPv6 more often.
> >>>                          >
> >>>                          >     --
> >>>                          >     Sent from my iPhone
> >>>                          >
> >>>                          >
> >>>                          >     On Fri, 9 Aug 2024 at 7:37 PM, Timothy
> Winters <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:[e-mail]>>> wrote:
> >>>                          >
> >>>                          >         Yes.  I've seen several instances
> of /64 being used for container networks on CPEs.
> >>>                          >
> >>>                          >         ~Tim
> >>>                          >
> >>>                          >         On Fri, Aug 9, 2024 at 9:38 AM The
> Multach's <[e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>> wrote:
> >>>                          >
> >>>                          >             So are these considered a LAN
> link prefix assignment under 7084 L2:
> >>>                          >
> >>>                          >             - Assignment of a /64 prefix
> for internal IPv6 communication between a
> >>>                          >             primary SoC and a secondary
> chip (e.g., a Wi-Fi chip which uses IPv6).
> >>>                          >
> >>>                          >             - Assignment of a /64 prefix
> for usage by an internal container or VM.
> >>>                          >
> >>>                          >
> >>>                          >             On 8/9/2024 7:56 AM, Timothy
> Winters wrote:
> >>>                          >              >
> >>>                          >              >
> >>>                          >              > On Thu, Aug 8, 2024 at
> 10:58 PM The Multach's <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>> wrote:
> >>>                          >              >
> >>>                          >              >     The following, while
> being user focused, fails to take into
> >>>                          >              >     account that
> >>>                          >              >     some of those prefixes
> may be used internally (or reserved for
> >>>                          >              >     internal
> >>>                          >              >     use) by the CPE or for
> ISP purposes and not assignable:
> >>>                          >              >
> >>>                          >              >     "SHOULD" (or an
> elongated exception for the above) would be more
> >>>                          >              >     appropriate.
> >>>                          >              >
> >>>                          >              >     LPD-4: After LAN link
> prefix assignment the IPv6 CE Router MUST
> >>>                          >              >     make the
> >>>                          >              >     remaining IPv6 prefixes
> available to other routers via Prefix
> >>>                          >              >     Delegation.
> >>>                          >              >
> >>>                          >              > I think this covers that
> case.  After local assignment, unused
> >>>                          >              > prefixes MUST be made
> available.
> >>>                          >              > LPD-2:  The IPv6 CE Router
> MUST assign a prefix from the delegated
> >>>                          >              >            prefix as
> specified by L-2 [RFC7084].
> >>>                          >              >
> >>>                          >              > 7084
> >>>                          >              >    L-2:   The IPv6 CE router
> MUST assign a separate /64 from its
> >>>                          >              >           delegated
> prefix(es) (and ULA prefix if configured to provide
> >>>                          >              >           ULA addressing)
> for each of its LAN interfaces.
> >>>                          >              >
> >>>                          >              >
> >>>                          >              >
>  _______________________________________________
> >>>                          >              >     v6ops mailing list --
> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>
> >>>                          >              >     To unsubscribe send an
> email to [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>
> >>>                          >              >
> >>>                          >
> >>>                          >
>  _______________________________________________
> >>>                          >         v6ops mailing list --
> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>
> >>>                          >         To unsubscribe send an email to
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>
> >>>                          >
> >>>                          >
>  45efe8dfc775213ded0fc41c7d84ccccb0d6aa20
> _______________________________________________
> >>>                          >     v6ops mailing list -- [e-mail]
> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]>>
> >>>                          >     To unsubscribe send an email to
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>>
> >>>                          >
> >>>                          >
> >>>                          >
> _______________________________________________
> >>>                          > v6ops mailing list -- [e-mail]
> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
> >>>                          > To unsubscribe send an email to
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]> <mailto:[e-mail]>
> >>>
> >         _______________________________________________
> >         v6ops mailing list -- [e-mail] <mailto:[e-mail]>
> >         To unsubscribe send an email to [e-mail] <mailto:
> [e-mail]>
> >
> >
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>