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

[Klaus Frank <[e-mail]>]

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...

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? 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
>
>   * 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.
>
> This way, common people can go with GUA & 464XLAT, experts can do 
> whatever they want.
>
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