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

[Xipengxiao <[e-mail]>]

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 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
  *   Implementers and deployers are encourage to consider 464XLAT or MAP-T first, unless there are clear reasons to use other transition solutions

This way, common people can go with GUA & 464XLAT, experts can do whatever they want.

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]<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?
o Here is a working recipe for deployment of a dual stack network
o Here are the features required to accomplish this
·  Where should I use ULA?
o Here is an example of a successful ULA deployment
o Here is a link to the operational considerations draft for using ULA (may help further the draft through the process as well)
o Here 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?
o Here 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>).  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