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

[David Farmer <[e-mail]>]

I’ve asked that too and have never received an answer, I always get pointed
requirement 1.3.7, that is it.

Sorry, I can’t be more helpful.

On Mon, Apr 25, 2022 at 18:58 Brian Carpenter <[e-mail]>
wrote:

> 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
>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>       Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
> --
===============================================
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
===============================================