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

[Ted Lemon <[e-mail]>]

6204 is obsoleted by 7084, which I think is fairly well regarded.
Similarly, the requirements stated in 6092 seem appropriate and I think are
generally well regarded. Both specs are, AFAIK, generally implemented in
IPv6-capable CE routers. Why do you say that these documents didn't help?

On Thu, Jan 19, 2023 at 10:06 AM Ca By <[e-mail]> wrote:

> 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
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>