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

[Ted Lemon <[e-mail]>]

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