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

[Xipengxiao <[e-mail]>]

Hi Ted, Klaus, Nick and folks,

I feel that we start to converge.  So maybe my previous wording is not clear.  Let me now advocate “IETF clearly recommends just 1-2 options at each decision point like address types, transition solutions, SLAAC vs DHCP, NAT or no-NAT, etc.” so that common implementers/deployers can focus on a few options and make them work (while experts can do/consider all of them).

Let me use RFC9313 “Pros and Cons of IPv6 Transition Technologies for IPv4aaS” as an example.  It reviewed 464XLAT, DS-Lite, lightweight 4o6, map-t, map-e and “Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.”.  First, I acknowledge that it’s useful as it already excludes some IPv4aaS options.  Second, it will be more useful if it clearly says that “we recommend you consider 464XLAT & map-t first”.  This way, many implementers/deployers can skip DS-Lite, lightweight 4o6 & map-e.  I acknowledge that doing so will cause some controversies, but I think the benefit outweighs the loss.

In other words, I think currently IETF is giving people too many IPv6 information and choices (in >500 RFCs). This overwhelms most implementers & deployers. Giving them guidelines (like RFC9313) helps, but telling them “just do this & that” helps even more.

To be a bit more persuasive, let me advertise a bit credential: while less of an IPv6 protocol expert than many people here, my job allows me to know what IPv6 solutions are deployed in real world and what are not, and what problems many deployers are facing.  For example, in the mobile world, IPv6 solutions are (almost) exclusively 464XLAT and Dual-Stack – nothing else.  In the fixed world, many people also want to use 464XLAT but unfortunately few CPEs offer that. So the fixed world sees many different transition solutions, which lead to the problems reported by Heise.  I feel that clearly recommending 464XLAT (and map-t if 464XLAT not available) would help to improve the situation.  As to why map-t not map-e – it’s because in real world we only see map-t deployment.  If some IPv6 options are rarely deployed in real world, why bother writing guidelines for them?

XiPeng

From: Nick Buraglio <[e-mail]>
Sent: Thursday, January 19, 2023 2:52 PM
To: Klaus Frank <[e-mail]>
Cc: Xipengxiao <[e-mail]>; Ted Lemon <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [v6ops] Heise.de article about IPv6 behaviour of 29 CPEs and reaction to prefix changes



On Thu, Jan 19, 2023 at 7:32 AM Klaus Frank <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> *Sent:* Tuesday, January 17, 2023 7:58 PM
> *To:* [e-mail]<mailto:[e-mail]>
> *Cc:* Xipengxiao <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
>
>         Hi Brian and folks, Please see comments in line.
>
>         -----Original Message-----
>         From: v6ops <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian E
>         Carpenter
>         Sent: Monday, January 16, 2023 9:06 PM
>         To: [e-mail]<mailto:[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]<mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>     _______________________________________________
>     v6ops mailing list
>     [e-mail]<mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
[https://mailfoogae.appspot.com/t?sender=abmlja0BidXJhZ2xpby5jb20%3D&type=zerocontent&guid=1ea881bf-cc13-4f13-8288-9a99c084bcc4]ᐧ