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

[Nick Buraglio <[e-mail]>]

Without condoning address translation, yes, I think there is benefit in
revisiting RFC4864. a great many things have changed in 2007.

nb

ᐧ

On Tue, Apr 26, 2022 at 9:28 PM Brian E Carpenter <
[e-mail]> wrote:

> On 26-Apr-22 12:51, George Michaelson wrote:
> > I'm having tremendous deja-vu about at meeting at MV where Google was
> tracking IPv6 deloyment (this would be 15+ years ago) and somebody from
> PCI-DSS was telling me IPv6 would never meet their compliance needs and we
> misunderstood the standards imperative, if we thought IETF had any
> influence on how they certified needs in this IP space.
> >
> > Somehow I think the world has orbited a good number of kilometers,
> without significant change in mutual understanding.
>
> About 15 orbits round the Sun, I suspect. Hence, exactly, my question
> whether it's time to update RFC4864.
>
>     Brian
>
> >
> > _G
> >
> > On Tue, Apr 26, 2022 at 10:48 AM Nick Buraglio <[e-mail] <mailto:
> [e-mail]>> wrote:
> >
> >     My experience is pretty dated from my prior job, so take this with
> that caveat, but my understanding of PCI-DSS is that the “functional
> requirements” are highly interpretable and almost wholly up to the auditor
> discretion.
> >     For example, In the environment I was in the auditor deemed that
> VLAN ragged segregation was insufficient and that he required us to use a
> VRF. This was non-negotiable from the answers to my inquiry.
> >     I was told that Campuses almost exactly like ours with similar
> architecture but different auditors used VLANs just fine. We were also
> required to have an IPS when a passive IDS would have been completely
> sufficient.
> >
> >     Compliance doesn’t generally care about technology implementation,
> just risk mitigation.
> >
> >     On Mon, Apr 25, 2022 at 19:38 David Farmer <farmer=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >         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] <mailto:[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]
> <mailto:[e-mail]>> wrote:
> >
> >                 You want to look at PCI DSS 3.2 requirement 1.3.7.
> >                 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] <mailto:[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]
> <mailto:[e-mail]>>
> >                      > *Sent:* Sunday, April 24, 2022, 11:27 PM
> >                      > *To:* Kevin Myers <[e-mail]
> <mailto:[e-mail]>>
> >                      > *Cc:* Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>>; Erik
> Auerswald <[e-mail] <mailto:[e-mail]>>;
> Ted Lemon <[e-mail] <mailto:[e-mail]>>; v6ops list <
> [e-mail] <mailto:[e-mail]>>; 6man list <[e-mail] <mailto:
> [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]>
> <mailto:[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]> <mailto:[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]> <mailto:
> [e-mail] <mailto:[e-mail]>>>; Erik
> Auerswald <[e-mail] <mailto:[e-mail]>
> >                     <mailto:[e-mail] <mailto:
> [e-mail]>>>; Ted Lemon <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                      >     Cc: v6ops list <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>; 6man
> list <[e-mail] <mailto:[e-mail]> <mailto:[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]>>
> <mailto:[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]> <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>>
> <
> 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]> <mailto:
> [e-mail] <mailto:[e-mail]>>
> >                      > https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops> <
> https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>>
> >                      >
> >                      >
> >
> >                     _______________________________________________
> >                     v6ops mailing list
> >                     [e-mail] <mailto:[e-mail]>
> >                     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
> >
> >                 --
> >                 ===============================================
> >                 David Farmer Email:[e-mail] <mailto:
> [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] <mailto:[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
> >         ===============================================
> >         _______________________________________________
> >         v6ops mailing list
> >         [e-mail] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >     --
> >     ---
> >     Nick Buraglio
> >     Planning and Architecture
> >     Energy Sciences Network
> >     [phone]
> >     _______________________________________________
> >     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
> >
>
>