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

Can you cite this regulation that requires NAT?

On Mon, 25 Apr 2022, 15:35 Kevin Myers, <kevin.myers@iparchitechs.com>
wrote:

> This misses the problem entirely though.
>
> It's not a choice to reconsider, these are regulatory requirements. The
> fact that a handful of enterprises have deployed IPv6 doesn't move the
> needle on compliance for the vast majority of them.
>
> No retail enterprise is going to choose IPv6 without NAT internally if it
> means not being permitted to use credit cards because of a failed PCI-DSS
> audit.
>
> Auditing frameworks and auditors are just not ready for IPv6 and without
> migration strategies like NAT, they'll have no reason to be because IPv4
> will continue to dominate.
>
> ------------------------------
> *From:* Lorenzo Colitti <lorenzo@google.com>
> *Sent:* Sunday, April 24, 2022, 11:27 PM
> *To:* Kevin Myers <kevin.myers@iparchitechs.com>
> *Cc:* Brian E Carpenter <brian.e.carpenter@gmail.com>; Erik Auerswald <
> auerswald@fg-networking.de>; Ted Lemon <elemon@apple.com>; v6ops list <
> v6ops@ietf.org>; 6man list <ipv6@ietf.org>
> *Subject:* Re: [v6ops] ULA precedence [Thoughts about wider operational
> input]
>
> There are several fortune 500 companies that have publicly stated that
> they have deployed IPv6 with global addressing, so that's definitely
> possible.
>
> As for "is it better to deploy IPv6 with NAT66 or not to deploy at all", I
> would guess it depends who you ask. My personal answer would be no. It's
> possible that when faced with app and OS incompatibilities, those
> enterprises might reconsider. Or they might pick the same technical
> solutions as the enterprises that have already deployed with global
> addresses.
>
> On Mon, Apr 25, 2022 at 12:42 PM Kevin Myers <kevin.myers@iparchitechs.com>
> wrote:
>
>> IPv6 NAT is already being deployed in large enterprises for the few that
>> want to tackle IPv6. Vendor implementations exist, so that ship has sailed
>> regardless of where the IETF lands.
>>
>> Most of the Fortune 500 fall under regulatory compliance of one body or
>> another (PCI-DSS, FIPS, HIPAA, etc) and none of them are setup well for an
>> IPv6 no-NAT world. Most of the discussion I see around enterprise adoption
>> on the IETF lists misses this point. It matters very little whether NAT is
>> a "good" or "bad" practice when it comes to selecting an operational model.
>> Enterprises choose operational models that will pass audits and the
>> overwhelming majority rely heavily on NAT.  We can make the argument that
>> compliance bodies and auditors should update their guidance and standards
>> and they absolutely should, but it will probably take close to a decade to
>> change the regulatory compliance auditing landscape to the point that IPv6
>> without NAT is commonplace.
>>
>> If auditors won't sign off on end to end GUA addressing, then NAT is
>> going to remain.
>>
>> Enterprises are more than willing to punt IPv6 for another decade and
>> will likely have no issues in doing so given how little IPv4 space most of
>> them need compared to service providers. Even when IPv6 becomes the
>> predominant transport type for an Internet handoff everywhere, it will
>> still just live in the underlay while IPv4 remains the predominant choice
>> in the overlay, in apps,  and internally in the DC for enterprises.
>>
>> At what point does it become more important to have IPv6 implemented,
>> than to have it "perfectly" implemented?
>>
>> Kevin Myers
>> Sr. Network Architect
>> IP ArchiTechs
>>
>> -----Original Message-----
>> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
>> Sent: Sunday, April 24, 2022 9:48 PM
>> To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>; Erik
>> Auerswald <auerswald@fg-networking.de>; Ted Lemon <elemon@apple.com>
>> Cc: v6ops list <v6ops@ietf.org>; 6man list <ipv6@ietf.org>
>> Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational
>> input]
>>
>> On 25-Apr-22 12:16, Lorenzo Colitti wrote:
>> > On Mon, Apr 25, 2022 at 2:28 AM Erik Auerswald <
>> auerswald@fg-networking.de <mailto:auerswald@fg-networking.de>> wrote:
>> >
>> >       "Since ULAs are defined to have a /48 site prefix, an
>> implementation
>> >        might choose to add such a row automatically on a machine with
>> >        a ULA."
>> >
>> >     The result is that only the local ULA prefix, i.e., exactly the
>> >     local IPv6 addresses, are preferred over IPv4 (and IPv6 GUA).
>> >     This should be exactly what is needed to use ULA addresses inside
>> >     an organization, or for a lab.
>> >     [...]
>> >     Implementing the non-normative suggestion from Section 10.6 of RFC
>> >     6724 would in all likelihood result in making ULA usable for local
>> >     tests and even first steps in deploying IPv6.  ULA addresses would
>> >     only be used locally.  Existing IPv4 based Internet access would not
>> >     be impaired by adding IPv6 ULA.
>> >
>> >
>> > That does seem like it might make ULA more useful, yes.
>> >
>> > Additionally, maybe we could clarify that the longest-prefix match rule
>> does not apply to ULAs outside the same /48? I think that would fix the
>> issue observed by +Ted Lemon <mailto:elemon@apple.com> in home networks:
>> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00
>> <
>> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00>
>> .
>>
>> When two networks each with its own ULA prefix are intentionally merged,
>> longest match would be the right thing, wouldn't it? (Assuming that the
>> split DNSs are also merged, and of course internal routing.) In that case
>> there is no "foreign" ULA prefix.
>>
>> >     In order to keep IPv6 deployment similar to IPv4, IPv6 NAT could be
>> >     considered.  To make this work as intended, the address selection
>> >     policy table could be adjusted to contain the local ULA prefix
>> >     with precedence greater or equal to GUA and the same label as GUA.
>> >
>> >
>> > This seems like it would encourage the use of IPv6 NAT. I think there
>> is reasonably strong consensus within the IETF that that is not the right
>> way to go, because it pushes problems on to application developers. This
>> adds costs for NAT traversal software development and maintenance, and
>> requires devices to implement NAT keepalives, increasing battery usage.
>>
>> That may be the IETF's consensus, but there is a very large fraction of
>> the enterprise network operations community that strongly disagrees, and in
>> fact regards this as a red line issue. It isn't even clear that they'd
>> accept NPTv6 as an alternative to NAPT66. If this is indeed the only way to
>> get IPv6 inside enterprises, what is the right thing for the IETF to do?
>>
>>        Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>