[v6ops] Re: Dynamic addresses

[Daryll Swer <[e-mail]>]

>
> What do you mean by “use against”?
>

For example, I successfully used RFC4638 “against” such ISPs, and get them
to enable 1500 MTU/MRU on PPPoE. Similarly, the concept is applicable for
IPv6-matters.

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


On Sat, 10 Aug 2024 at 22:14, Ted Lemon <[e-mail]> wrote:

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