[v6ops] Re: Dynamic addresses

[The Multach's <[e-mail]>]

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>
>>
>>
>> On Sat, 10 Aug 2024 at 04:56, Brian E Carpenter 
>> <[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:[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]>>> 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]>>> 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]>>> 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]>>
>>      >              >     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]> <mailto:[e-mail] <mailto:[e-mail]>>
>>      >         To unsubscribe send an email to [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]>>
>>      >     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]>
>>