[v6ops] Re: Dynamic addresses

[David Farmer <[e-mail]>]

On Sat, Aug 10, 2024 at 16:45 Daryll Swer <contact=
[e-mail]> 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.
>

In the US most residential power systems don’t have  backup, power outages
are typically short, a minute or less or they are caused by a power
disruption major fault requiring a truck roll, these typically are caused
by thunderstorms and last 30 minutes to an hour, and occur one or twice a
year for a typical customer. Then once a decade or so you will experience
an extended outage of many hours to a day or two, typically cased by major
damage, like trees falling down in severe thunderstorms, straight line
winds or tornados.

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

I never said it was hypothetical, it is a real issue, especially when a
change is forced on some arbitrary timeframe, instead of opportunistically
with reboot. But even a change on reboot will cause issues in at least some
cases.

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

Like I said, changing address doesn’t prevent tracking. But, my point is
without addresses changing once in a while, basic system logging becomes an
effective tracking system, that is tracking is trivial if addresses never
change.

*--*
> 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]> 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]> 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]> 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]>
>>>>
>>>>> > 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]>
>>>>> 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/
>>>>>>
>>>>>>
>>>>>> 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
>>>>>> <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]>
>>>>>> <[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:[e-mail]>
>>>>>> <[e-mail]> <
>>>>>> mailto:[e-mail]
>>>>>> <[e-mail]>
>>>>>> <mailto:[e-mail]>
>>>>>> <[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]> <[e-mail]> <
>>>>>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]>
>>>>>> <[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]>
>>>>>> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]>
>>>>>> <[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]>
>>>>>> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]>
>>>>>> <[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]> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]> <[e-mail]>>
>>>>>>      >              >     To unsubscribe send an email to
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]>
>>>>>> <[e-mail]>>
>>>>>>      >              >
>>>>>>      >
>>>>>>      >         _______________________________________________
>>>>>>      >         v6ops mailing list -- [e-mail]
>>>>>> <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]> <[e-mail]>>
>>>>>>      >         To unsubscribe send an email to [e-mail]
>>>>>> <mailto:[e-mail]> <[e-mail]> <
>>>>>> mailto:[e-mail] <[e-mail]>
>>>>>> <mailto:[e-mail]> <[e-mail]>>
>>>>>>      >
>>>>>>      >     45efe8dfc775213ded0fc41c7d84ccccb0d6aa20
>>>>>> _______________________________________________
>>>>>>      >     v6ops mailing list -- [e-mail]
>>>>>> <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]
>>>>>> <[e-mail]> <mailto:[e-mail]> <[e-mail]>>
>>>>>>      >     To unsubscribe send an email to [e-mail]
>>>>>> <mailto:[e-mail]> <[e-mail]> <
>>>>>> mailto:[e-mail] <[e-mail]>
>>>>>> <mailto:[e-mail]> <[e-mail]>>
>>>>>>      >
>>>>>>      >
>>>>>>      > _______________________________________________
>>>>>>      > v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>>>>>> <[e-mail]>
>>>>>>      > To unsubscribe send an email to [e-mail]
>>>>>> <mailto:[e-mail]> <[e-mail]>
>>>>>>
>>>>>> _______________________________________________
>>> v6ops mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>