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

[Mark Smith <[e-mail]>]

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