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

[Vasilenko Eduard <[e-mail]>]

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.
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.
Ed/
From: ipv6 [mailto:[e-mail]] On Behalf Of Mark Smith
Sent: Friday, April 29, 2022 7:47 AM
To: Nicholas Buraglio <[e-mail]>
Cc: Xipengxiao <xipengxiao=[e-mail]>; 6man list <[e-mail]>; v6ops list <[e-mail]>
Subject: Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]


On Fri, 29 Apr 2022, 11:15 Nick Buraglio, <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, 29 Apr 2022 at 07:37, Xipengxiao
<xipengxiao=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Jen Linkova
> Sent: Thursday, April 28, 2022 12:53 PM
> To: Simon <[e-mail]<mailto:[e-mail]>>
> Cc: 6man list <[e-mail]<mailto:[e-mail]>>; v6ops list <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]
>
> On Thu, Apr 28, 2022 at 11:15 AM Simon <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops