Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]

On Fri, Apr 29, 2022 at 03:01 Vasilenko Eduard <vasilenko.eduard@huawei.com>
wrote:

> Yes, GUA over ULA is the problem.
>
> But IPv4 over ULA is the much bigger problem!
>
> And when we would start to fix it we may come to the situation ULA to GUA
> that may be one-way connectivity.
>
> I mean: it is not so simple RFC 6724 fix.
>
> Looking to all these messaging (including a usual flame about NAT) – I am
> not sure that consensus is possible. Some prefer to keep ULA dead
> (prioritized below IPv4) just as one additional barrier on the way to NPT.
>
> Probably, ULA would be down till NPT would be accepted.
>

That is a false flag - NPT will happen, and is currently happening,
regardless. Meanwhile this lack of usable address space leads to:

1. Stifled adoption of IPv6 - a problem that is continually lamented here
and elsewhere in the IPv6 community. Regardless of the semantics of what’s
been discussed here, this is the ultimate outcome.
2. Squatting in space not meant for this (use of documentation space, other
unallocated GUA)
3. Continued deployment of technologies undesirable to certain members of
this community with no guide rails.

If the IETF is willing to say “we are ok with those three givens” then
fine. We can move on, but I’m guessing that the first one by itself - which
regardless of the belief that NPTv6/NAT66/etc. can be ignored and they'll
go away is idealistic at best and dangerous at worst, see #3 above.

Hence, I am doubt that it makes sense to develop a draft to fix ULA – it
> would undermine anti-NPT position. It would be blocked anyway.
>

That is short sighted. Part of technology is adaptation - being able to
evolve to both suit the landscape and to help shape it. One doesn’t happen
without the other, because the landscape will and is always changing
regardless of if we want it to and irrespective of "bad" or "good" or
"right" and "wrong".
I personally don’t see it as condoning, or even hastening anything - like I
said that is absolutely happening anyway as detailed by many others on this
list. Recognizing that something is happening is in no way sanctioning it,
but attempting to impege it by ignoring legitimate use cases is
functionally allowing it to expand unbounded.

We need something that fills this requirement.

nb

Ed/
>
> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Mark Smith
> *Sent:* Friday, April 29, 2022 7:47 AM
> *To:* Nicholas Buraglio <buraglio@es.net>
> *Cc:* Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>; 6man list <
> ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
>
>
>
>
>
> On Fri, 29 Apr 2022, 11:15 Nick Buraglio, <buraglio@es.net> wrote:
>
> Again, we're focusing on the wrong thing that is a tangent out of an
> example used to describe *why* we need the thing. We need something that is
> usable in a dual stacked environment that has similar attributes to ULA. If
> everyone here thinks ULA is fine (which I do not believe is the consensus),
> great. Let's say that.
>
>
>
>
>
> We decided that when RFC4193 was published, also after site-locals were
> deprecated in RFC3879, in 2004/2005. Many networking and telephony
> protocols have provided link and/or network local private address spaces
> that don't require getting address space from an central authority. In CLNS
> it is 49.
>
>
>
> ULAs were further endorsed in RFC6204, Basic Requirements for IPv6
> Customer Edge Routers. I've seen a number of CPE implement the ULA
> requirements in that RFC (including in recent firmware for Google's Nest
> Wifi CPE.)
>
>
>
> The only current issue is preference of GUAs over ULAs in RFC6724 default
> address selection. That seems to have been made without reading of RFC4193,
> because RFC4193 says:
>
>
>
> "4.2.  Renumbering and Site Merging
>
>
>    The use of Local IPv6 addresses in a site results in making
>    communication that uses these addresses independent of renumbering a
>    site's provider-based global addresses."
>
>
>
> which is implicitly saying that ULAs need to be preferred over GUAs for
> DAs and then SAs, when there is a choice between ULA and GUA DA, and then a
> subsequent choice between a ULA and GUA SA,
>
>
>
> and
>
>
>
> " At the present time, AAAA and PTR records for locally assigned local
>
>    IPv6 addresses are not recommended to be installed in the global DNS."
>
>
>
> which is implicitly saying that hosts should be provided with ULA AAAAs
> only when the ULA DA is likely reachable because the host is part of the
> same ULA address domain i.e. split DNS.
>
>
>
> RFC6724 seems to have assumed that ULA AAAAs are always in global DNS, so
> ULAs are going to be far more unreliable most of the time than GUAs, so
> GUAs should be preferred. ULA AAAAs appearing in global DNS is a fault, and
> RFC6724 looks to then have been optimised for a fault situation.
>
>
>
> Regards,
>
> Mark.
>
>
>
>
>
>
>
>
>
>
>
> If not, let's think about how to fix it - or at the very least update the
> draft to reflect its limitations. Ideological soapboxing about the merits
> or detriment of NAT isn't really gaining any ground either way. It is a
> tool in the toolbox. Some folks use it. Vilifying it is like hating an
> earthmover because it's not a Ferrari.
>
>
>
> nb
>
>
>
>
>
>
> ᐧ
>
>
>
> On Thu, Apr 28, 2022 at 6:03 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>
> On Fri, 29 Apr 2022 at 07:37, Xipengxiao
> <xipengxiao=40huawei.com@dmarc.ietf.org> wrote:
> >
> > Hi Jen,
> >
> > Thank you for bringing this useful piece of information to light.  I
> hope more people see it:
> >
> > > PCR DSS 4.0 (published in March 2022) does not mandate NAT for IPv6.
> The text has been updated.
> >
> > That said, I very much agree with Kevin Meyer: "If you want more
> Enterprises participating in the IETF discussions and improving IPv6
> uptake, start thinking about meeting them where they are. And to be crystal
> clear - NAT is where they are and where they will be for quite a while".
> >
> > My point is, given PCI DSS 4.0 (what Jen wrote as PCR DSS 4.0), we
> should tell enterprises they no longer need NAT. But if some enterprises
> still insist, respect their decision.
>
> Ignore them. IPv6 doesn't solve any problem they have, and adding NAT
> to IPv6 still won't solve any problem they have, because IPv6 still
> won't solve a problem they have.
>
>
> Earth moving equipment manufacturer: "We think you should buy an earth
> moving front end loader from us. They're great!"
>
> An Enterprise: "We don't need an earth moving front end loader, we're
> an accountancy firm. It doesn't solve any problems we have."
>
> Earth moving equipment manufacturer: "What if we add a backhoe to it?"
>
> An Enterprise: "We're still an accountancy firm, we still won't need
> it. We don't need to move dirt or dig holes. It still doesn't solve
> any problem we have."
>
> Earth moving equipment manufacturer: "Oh, come on! You really should
> buy one! We love our front end loaders. Everybody needs one. What if
> we paint it green too?"
>
> An Enterprise: "Nope. Even though our corporate colours are green,
> we're still an accountancy firm and we still won't need it. We've got
> better things to spend $100K on."
>
>
> Even government mandates to get enterprises to adopt a networking
> protocol don't work - the Internet is supposed to be running CLNS by
> now as mandated by governments around the world. (I expect Vint Cerf
> was being nice while working on this rather than truly believing OSI
> would take over.)
>
> Explaining the Role of GOSIP
> https://www.rfc-editor.org/rfc/rfc1169.html
>
>
>  It's more important to get enterprises to use IPv6 ASAP, than to
> insist that they use the "right" IPv6 solution.
> >
>
> Why is it important to get enterprises to use IPv6 ASAP?
>
>
> Regards,
> Mark.
>
>
> > XiPeng
> >
> > -----Original Message-----
> > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Jen Linkova
> > Sent: Thursday, April 28, 2022 12:53 PM
> > To: Simon <linux@thehobsons.co.uk>
> > Cc: 6man list <ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
> > Subject: Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
> >
> > On Thu, Apr 28, 2022 at 11:15 AM Simon <linux@thehobsons.co.uk> wrote:
> > > The IPv6 community needs to engage with this other regulatory
> community to get them to bring their standard into the 21st century.
> > >
> > > As long as the PCI standard effectively mandates IPv4 & NAPT then it’s
> going to be an uphill struggle.
> >
> > See my email I sent yesterday. PCR DSS 4.0 (published in March 2022)
> does not mandate NAT for IPv6. The text has been updated.
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> ᐧ