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

[David Farmer <[e-mail]>]

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
===============================================