[v6ops] Re: Dynamic addresses

[David Farmer <[e-mail]>]

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