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

[Nick Buraglio <[e-mail]>]

On Thu, Jan 19, 2023 at 7:32 AM Klaus Frank <[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]>
> > *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
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
ᐧ