[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

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