Re: [v6ops] Heise.de article about IPv6 behaviour of 29 CPEs and reaction to prefix changes

[Ca By <[e-mail]>]

Examples of previous documents that took a lot of WG group time, in the
same way, but did not actually help imho

https://datatracker.ietf.org/doc/html/rfc6092


https://datatracker.ietf.org/doc/html/rfc6204



On Thu, Jan 19, 2023 at 5:51 AM Nick Buraglio <[e-mail]>
wrote:

>
>
> On Thu, Jan 19, 2023 at 7:32 AM Klaus Frank <[e-mail]> wrote:
>
>> Hi,
>>
>> On 19.01.2023 11:59, Xipengxiao wrote:
>> >
>> > Hi Ca, Nick, Ted and folks,
>> >
>> > Nick (and Brian)’s proposal to write clear guidelines is accepted by
>> > all, but I suspect it’s not enough – if we don’t reduce options, these
>> > guidelines will still be too long and requiring the deployers to make
>> > too many decisions (a negative).
>> >
>> > When proposing reducing options, I am not denying flexibility’s value.
>> > But is there a single company that deployed IPv6 for flexibility?
>> > Every IPv6 deployment I know of is for addresses. Therefore, creating
>> > a base-line IPv6 solution that works is top priority for now.
>> > Flexibility and optimization can come later.
>> >
>> > I am surprised that the proposal to reduce options met strong
>> > opposition.  Do you think this direction is wrong, or do you think the
>> > direction is right but it is too difficult to achieve?
>> >
>> I think it probably will be to difficult to achieve in the end, but it
>> is worth trying to craft something anyway.
>
> The main reason for that is
>> that most things related to why deploying IPv6 currently is such a
>> complex topic is because of having to work around bugs and quirks...
>>
>
> Bugs and quirks won't ever go away. A framework of sane and
> straightforward deployment expectations will serve to better clarify what
> those bugs and quirks are, and therefore shine a light on them and,
> hopefully, aid in diminishing them a little.
>
>>
>> Like the scanner that only supports ULA addresses as it fails to use a
>> DNS name within the client component of the driver so you're forced to
>> use an IP address. And then when the GUA changes it breaks.
>> Or a wide variety of different deployments by ISPs. Some offer DHCPv6-PD
>> some don't. Some offer a /48 or /60 others just a single /64 and even
>> use the first address out of it for the WAN interface. I was told of at
>> least one provider that blocked all traffic that originated from every
>> address that was not the SLAAC generated one, so temporary addresses and
>> subnetting are not possible without NAT66. There are ISPs which
>> completely block ICMPv6 on their CPE and thereby completely breaking
>> IPv6 within applications behind it. Clients that refuse to connect to a
>> network that doesn't have an IPv4 address and telling the user it
>> doesn't have network connectivity or immediately automatically
>> disconnecting. And then there is also software like docker which doesn't
>> have a builtin way for dynamic address updates and need custom scripts
>> to be written for it. But even then, can you use DHCPv6-PD or do you
>> need ND-Proxy?
>
>
> These things in particular are what would benefit the most in the long
> term from something like this -
> If there is some document which holds some weight that points to a
> supportable deployment, then there are
> at least some developers that will use it as a reference, and some users
> that will point to it when functionality
> is poor or nonsensical (such as filtering ICMP for all but SLAAC
> addresses). It won't solve all the problems, but a rising tide lifts all
> boats,
> so if it helps a few folks, then we should try.
>
>
>> That depends on what the ISP provides and what other bugs
>> you have to workaround in that network, so it is not portable. When you
>> try to do it on a notebook that is roaming from network to network, it's
>> basically a impracticable to find a solution. And not to mention devices
>> and clients that implement additional "features" that aren't RFC
>> compliant, like Linux ignoring routes that have a longer mask than a
>> predefined value within router advertisements (and often that is set to
>> 0 by default, ignoring all but the default route).
>>
>> All of this *requires a lot of workarounds *to be deployed and these
>> workarounds are what makes IPv6 complicated. It is not that one chooses
>> to use the freedom of IPv6, but the necessity to support all possible
>> combinations a ISP may have chosen to deploy so that your devices work
>> in that network. And if it's a notebook it has to work in all of these.
>> Making the freedom of IPv6 a burden instead of an enabling force.
>>
>> >   I invite people to comment on this.  If enough people think the
>> > direction is wrong, I will shut up.  If it’s just too difficult, then
>> > I think agreeing on a few principles like “keeping reducing options
>> > until it no longer works” may offer a way to define a base-line
>> > solution.   As examples, I wonder who think the following 2 sentences
>> > are not acceptable?
>> >
>> >   * For simplicity of decision making, GUA is recommended, unless
>> >     there are clear reasons to use other types of addresses like ULA
>> >
>> I agree
>>
>
> 100%
>
>
>> >
>> >   * Implementers and deployers are encourage to consider 464XLAT or
>> >     MAP-T first, unless there are clear reasons to use other
>> >     transition solutions
>> >
>> If a MAP-T BR is present also having NAT64 isn't that unrealistic, so
>> I'd suggest 464XLAT AND MAP-T (I.E. both) to be deployed simultaneously.
>> Mainly because MAP-T would be limited to TCP and UDP traffic. E. g. SCTP
>> and QUIC wouldn't be possible with just MAP-T. But in any case the
>> deployment of MAP-T is better than CG-NAT which many ISPs currently
>> have, but I'm not sure if we can change the status quo. Nonetheless we
>> probably also need to specify a minimum amount of TCP and UDP ports an
>> ISP has to allocate to clients.
>>
> In many cases CGN is just a fact of life because small and regional ISPs
> don't have great options for affordable and supportable 464XLAT CPE, as far
> as I can tell.  Advocating for it could help in raising awareness of the
> need for the smaller CPE providers.
>
>> >
>> > This way, common people can go with GUA & 464XLAT, experts can do
>> > whatever they want.
>>
> +1
>
>> >
>> Two additional things we have to consider here:
>>
>>   * Renewal of the addresses, should we specify a minimum lifetime for
>>     the GUA? Should it be unique forever?
>>   * DHCPv6 or ND-Proxy, which one should we propose for scenarios where
>>     a client (application) needs more than one address? I wouldn't
>>     consider most developers "network experts", so we probably have to
>>     handle the docker on a notebook case...
>>
>> Sincerely,
>> Klaus Frank
>>
>> > XiPeng
>> >
>> > *From:* Ted Lemon <[e-mail]>
>> > *Sent:* Tuesday, January 17, 2023 7:58 PM
>> > *To:* [e-mail]
>> > *Cc:* Xipengxiao <[e-mail]>; [e-mail]
>> > *Subject:* Re: [v6ops] Heise.de article about IPv6 behaviour of 29
>> > CPEs and reaction to prefix changes
>> >
>> > One thing I will point out here is that IPv6's flexibility makes
>> > things possible that are actually useful, and are not possible with
>> > IPv4 (at least not without some kind of heavy lift). E.g., there is no
>> > way to do stub networks with IPv4. Doing what we've done with stub
>> > networks using only IPv4 would require stateful NAT64 with the
>> > translation table tied to the service advertisement table. Much more
>> > work than just doing IPv6 routing with ULAs. Also not possible with
>> > GUAs, since IPv6 GUA prefixes aren't universally available.
>> >
>> > I think this idea of reducing flexibility is going in the wrong
>> > direction. I think giving good advice about what solutions go with
>> > what problems is a better approach, as Nick has suggested. I think
>> > also, getting our specs up to date with what works, and getting
>> > implementations to follow the specs, is important work that can't be
>> > discounted.
>> >
>> > If there is any complexity we could probably reduce, it would be
>> > complexity relating to transition technologies. E.g., 464XLAT was
>> > mentioned here, but generally when 464XLAT will work, NAT64 is also
>> > present and also works. NAT64 is less complex than 464XLAT. So there's
>> > no reason to have 464XLAT other than that some application doesn't
>> > understand how to do IPv6. Is this really something that app
>> > ecosystems should ever support?
>> >
>> > On Tue, Jan 17, 2023 at 1:39 PM Nick Buraglio <[e-mail]> wrote:
>> >
>> >     Here is what came to my mind:
>> >
>> >     Informational draft detailing a working deployment with
>> >     suggestions per scenario. When speaking with folks implementing
>> >     IPv6, what most seem to want is a recipe due to the somewhat
>> >     overwhelming set of knobs and levers. Flexibility, by design,
>> >     breeds a potentially complex set of options. What they
>> >     overwhelmingly want to see is a best practice - or at the very
>> >     least a known working methodology for:
>> >
>> >     ·I want to dual stack, what do I need to do?
>> >
>> >     oHere is a working recipe for deployment of a dual stack network
>> >
>> >     oHere are the features required to accomplish this
>> >
>> >     ·Where should I use ULA?
>> >
>> >     oHere is an example of a successful ULA deployment
>> >
>> >     oHere is a link to the operational considerations draft for using
>> >     ULA (may help further the draft through the process as well)
>> >
>> >     oHere are examples of a supportable deployment for using GUA in a
>> >     similar manner to ULA
>> >
>> >     ·What if I want to deploy my network as IPv6-only?
>> >
>> >     oHere are examples of successful and supportable IPv6-only
>> deployments
>> >
>> >     §Here are the features required to deploy these scenarios.
>> >
>> >     ·etc...
>> >
>> >     Some of this may exist, I don't know for sure. I know a lot of
>> >     this exists in the wild in various documentation, forums, blog
>> >     posts, and email threads. Having the IETF produce such text
>> >     provides something more "official" that can be referenced by
>> >     vendors, management, architects, etc..
>> >
>> >     Regardless, and without commenting on whether this is the
>> >     correct avenue or not, having a draft of a set of drafts that give
>> >     these examples will go a *very* long way. If it is caveated in
>> >     such a way that states "this is one way, it may not be the only
>> >     way" may alleviate at least some of the lack of consensus that
>> >     will inevitably arise.
>> >
>> >     I have written some of a draft on ULA use cases (as well as some
>> >     updates to RRC6724) written that need revisiting. Of course, if
>> >     there is no consensus, then it's just another exercise.
>> >
>> >
>> >     ----
>> >     nb
>> >
>> >     ᐧ
>> >
>> >
>> >     ----
>> >
>> >     nb
>> >
>> >     On Tue, Jan 17, 2023 at 11:05 AM Xipengxiao
>> >     <xipengxiao=[e-mail]> wrote:
>> >
>> >         Hi Brian and folks, Please see comments in line.
>> >
>> >         -----Original Message-----
>> >         From: v6ops <[e-mail]> On Behalf Of Brian E
>> >         Carpenter
>> >         Sent: Monday, January 16, 2023 9:06 PM
>> >         To: [e-mail]
>> >         Subject: Re: [v6ops] Heise.de article about IPv6 behaviour of
>> >         29 CPEs and reaction to prefix changes
>> >
>> >         On 17-Jan-23 07:08, Xipengxiao wrote:
>> >
>> >         > Hi folks,
>> >
>> >         >
>> >
>> >         > I am moving the discussion to v6ops as I think the problems
>> >         are more operational than technical.
>> >
>> >         >
>> >
>> >         > In short, the Heise article reported that existing IPv6 CPEs
>> >         have various problems and IPv6 may not work in many
>> >         scenarios.  Then the good question is, what can the IETF do
>> >         about them?  From my first look, there are so many different
>> >         problems that it’s hard to see what to fix.  But maybe the
>> >         experts here have better ideas.
>> >
>> >         >
>> >
>> >         > Personally, I think the root cause is IPv6 has too many
>> >         options (e.g. GUA vs ULA vs now obsoleted SLA, SLAAC vs DHCP,
>> >         10+ transition solutions).
>> >
>> >         As I commented on 6man, I believe that is not quite right.
>> >         It's the real world that has too many options, and IP6 has
>> >         flexibility.
>> >
>> >         XiPeng:  we can say “It's the real world that has too many
>> >         options”, but we can only change ourselves.  This is why I
>> >         propose we limit the options we offer to the world.
>> >
>> >         > This makes it difficult for vendors to implement/fine tune
>> >         their IPv6 solutions, and difficult for common people to learn
>> >         and deploy.  I advocate that IETF should provide clear
>> >         recommendation,
>> >
>> >         Yes, it's our job to provide guidelines and recommendations,
>> >         but doing that is not easy and hard to reach even rough
>> >         consensus. For example:
>> >
>> >         > e.g. only use GUA
>> >
>> >         That's unacceptable. A good BCP on how and when to use ULAs is
>> >         very necessary.
>> >
>> >         XiPeng: we had a debate whether enterprises need ULA in a side
>> >         meeting in London IETF.  Ted, Jen, Lorenzo, Jordi, Mike,
>> >         Nalini, Nick all participated.  The rough consensus was GUA
>> >         works just fine.  So, I am not saying that ULA has no value, I
>> >         am saying that between ULA’s value and reducing choices, I
>> >         advocate the latter.
>> >
>> >         But I agree that “providing guidelines and recommendations” is
>> >         the way to go, but that’s “hard to reach even rough
>> >         consensus”. To overcome that, I would like to propose a
>> >         principle here “keep reducing IPv6 options until it fails”.
>> >         If we can agree on a principle (or a few), maybe we can reach
>> >         some rough consensus.
>> >
>> >         > , only use 464XLAT/MAP-T
>> >
>> >         Possibly. But I am sure there are cases where that is a bad
>> idea.
>> >
>> >         XiPeng: I agree, but think of the principle I mentioned above
>> >         – will the solution fail?  Eduard Vasilenko said in another
>> >         thread that mobile enjoys good IPv6 deployment because there
>> >         are fewer choices: only Dual-Stack or 464XLAT.  I think that’s
>> >         a good point.  Fixed has many more choices. Then we have the
>> >         CPE problems reported by Heise.
>> >
>> >         > and avoid Dual-Stack as much as possible, etc.
>> >
>> >         That's also unacceptable. There are *many* scenarios where
>> >         dual stack on the wire works extremely well.
>> >
>> >         XiPeng: I agree Dual-Stack can “works extremely well”, but in
>> >         some scenarios, IPv4 takes over completely and IPv6 is not
>> >         used at all (due to its various problems, e.g. ULA less
>> >         preferred than IPv4, CPE problems). In other words, IPv4 is
>> >         masking IPv6 problems and gives the IPv6 deployers a false
>> >         sense of accomplishment.  This is why I think if a company is
>> >         serious about IPv6, it should avoid Dual-Stack as much as
>> >         possible.
>> >
>> >         > Some experts may dismiss this recommendation as overly
>> >         simplifying but I think it’s practical at this stage: most
>> >         people only wants a working solution not necessarily the best
>> >         one. Therefore we should unite the industry behind a few
>> >         options and fine tune them.
>> >
>> >         It is over-simplifying and that's why it doesn't work: the
>> >         real world has become too complicated. We *do* need clear BCPs
>> >         but my guess is that we probably need ~10 of them rather than
>> ~1.
>> >
>> >         XiPeng: I trust that despite the difference, we see each
>> >         other’s point – we all want to simplify and give clear
>> >         recommendations but the question is how.  So can we first
>> >         discuss and agree on a (few) principle?  I offer this as a
>> >         starting point: “keep reducing IPv6 options until it fails”.
>> >
>> >         Thanks.  XiPeng
>> >
>> >         > I also want to take this opportunity to say that many
>> >         existing IPv6 adoption stats are user/session% which can look
>> >         good according to APNIC/Google.  This may give us a false
>> >         sense of accomplishment, because an operator with 100% IPv6
>> >         capable users may actually produce 0% IPv6 traffic. I think
>> >         IPv6 traffic% is a better indicator of real IPv6 adoption
>> >         status.  But IPv6 traffic% is hard to find.  Up to this point,
>> >         we only find that Akamai reported 16% traffic for Oct 2022, FB
>> >         reports 15% for 2019, and AMS-IX reports 4.1% for Jun 2022
>> >         (source:
>> >
>> https://labs.ripe.net/author/wilhelm/ipv6-10-years-out-an-analysis-in-users-tables-and-traffic/#:~:text=On%20the%20Internet%20exchanges%2C%20the,observes%20an%20average%20of%204.1%25
>> >         <
>> https://labs.ripe.net/author/wilhelm/ipv6-10-years-out-an-analysis-in-users-tables-and-traffic/#:~:text=On%20the%20Internet%20exchanges%2C%20the,observes%20an%20average%20of%204.1%25
>> >
>> >         <
>> https://labs.ripe.net/author/wilhelm/ipv6-10-years-out-an-analysis-in-users-tables-and-traffic/#:~:text=On%20the%20Internet%20exchanges%2C%20the,observes%20an%20average%20of%204.1%25
>> >         <
>> https://labs.ripe.net/author/wilhelm/ipv6-10-years-out-an-analysis-in-users-tables-and-traffic/#:~:text=On%20the%20Internet%20exchanges%2C%20the,observes%20an%20average%20of%204.1%25
>> >>).
>> >          These traffic% are far lower than worldwide IPv6 user%.
>> >
>> >         >
>> >
>> >         > In summary, I call for the experts in v6ops to make an
>> >         effort to:
>> >
>> >         >
>> >
>> >         >  1. Report and discuss IPv6 traffic%
>> >
>> >         >  2. Identify the problems hiding behind the low IPv6
>> >         traffic% (e.g. the CPE problems reported by the Heise
>> >         article), and recommend solutions for them
>> >
>> >         >
>> >
>> >         > XiPeng
>> >
>> >         _______________________________________________
>> >         v6ops mailing list
>> >         [e-mail]
>> >         https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >     _______________________________________________
>> >     v6ops mailing list
>> >     [e-mail]
>> >     https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> ᐧ
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>