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

[Brian Carpenter <[e-mail]>]

No, I explicitly don't want to look at audit rules. I want someone who
understands them to explain what the functional requirements are. NAT is
not a functional requirement.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Tue, 26 Apr 2022, 11:06 David Farmer, <[e-mail]> wrote:

> You want to look at PCI DSS 3.2 requirement 1.3.7.
> [image: image.png]
>
> Compensating controls is an option, but auditors have to sign off on them,
> and the whole process is about minimizing exceptions and getting a clean
> audit. IT isn't in charge of this, finance people are, it's not technical,
> it's all about the money, and numbers with 7 or 8 significant digits or
> more.
>
> I've been on that the merry-go-round several times, I believe in IPv6 E2E,
> but if anyone asks me just do NPTv6 or NAT66, whatever the auditor wants
> you to do.
>
> Have fun on the merry-go-round, I'll pass.
>
> Thanks
>
> On Mon, Apr 25, 2022 at 5:32 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> Kevin,
>>
>> > 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.
>>
>> You're describing a vicious circle, and the question is how can we break
>> it?
>>
>> Advocating NPTv6 might achieve that, but many of us dislike that strategy.
>>
>> Can you explain what are the technical requirements in PCI-DSS land that
>> have been interpreted as requiring NAT44? Is it time for RFC4864bis,
>> because this is exactly what we were aiming at with that RFC?
>>
>> Regards
>>     Brian Carpenter
>>
>> On 25-Apr-22 17:34, Kevin Myers 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 <[e-mail]>
>> > *Sent:* Sunday, April 24, 2022, 11:27 PM
>> > *To:* Kevin Myers <[e-mail]>
>> > *Cc:* Brian E Carpenter <[e-mail]>; Erik Auerswald <
>> [e-mail]>; Ted Lemon <[e-mail]>; v6ops list <
>> [e-mail]>; 6man list <[e-mail]>
>> > *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 <
>> [e-mail] <mailto:[e-mail]>>
>> 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 <[e-mail] <mailto:[e-mail]>>
>> On Behalf Of Brian E Carpenter
>> >     Sent: Sunday, April 24, 2022 9:48 PM
>> >     To: Lorenzo Colitti <lorenzo=[e-mail] <mailto:
>> [e-mail]>>; Erik Auerswald <[e-mail]
>> <mailto:[e-mail]>>; Ted Lemon <[e-mail]
>> <mailto:[e-mail]>>
>> >     Cc: v6ops list <[e-mail] <mailto:[e-mail]>>; 6man list
>> <[e-mail] <mailto:[e-mail]>>
>> >     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 <
>> [e-mail] <mailto:[e-mail]> <mailto:
>> [e-mail] <mailto:[e-mail]>>> 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:[e-mail] <mailto:
>> [e-mail]>> 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>
>> <
>> 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
>> >     [e-mail] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops>
>> >
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>