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

[Nick Buraglio <[e-mail]>]

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