[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

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


I mean, I guess, but a client would get a /56 minimum, out of that, they
can rotate a new /64 per VLAN every month or X amount of time as they
please on their LAN.

But what I do know, is if ia_na and ia_pd had this “privacy” flag I
hypothetically described, it would probably make things easier on both
sides (those who are pro static prefixes/addr. and those who are
pro-dynamic prefixes/addr.).

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


On Sun, 11 Aug 2024 at 04:05, David Farmer <farmer=[e-mail]>
wrote:

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