[v6ops] Re: Dynamic addresses

[Ted Lemon <[e-mail]>]

What do you mean by “use against”?

Op za 10 aug 2024 om 11:14 schreef 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]>
>>>>
>>>>