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

[David Farmer <[e-mail]>]

You are correct, RFC 6724, section 10.6, doesn’t specifically mention IPv4.
However, if you do what it says in paragraph 3 of that section, the local
ULA /48 will have a precedence higher than IPv4(both GUA and RFC1918) and
IPv6 GUA.

I agree the draft should focus on the problem statement, however, I don’t
believe implementations that automatically add the local ULA /48, as
suggested in RFC 6724 section 10.6, paragraph 3, actually have the problem
we are taking about. Furthermore, if you manually add the ULA /48, you can
work around the problem, in the cases where it is possible to do so.
However, as noted in the draft, it is not always possible or practical to
modify the table manually. And, therefore, in many/most cases ULA doesn’t
function as intended.

Basically, I believe the solution it to make section 10.6, paragraph 3,
mandatory, a normative MUST, instead of the effective MAY that it is now.
Also, we should probably elaborate on how to automatically add the local
ULA /48, in particular how a network signals there are might be more than
one ULA /48 that should be considered as local.

I believe RFC 6724 is correct, ULAs that are not known to be local, should
be considered remote and GUA IPv6 and IPv4(both GUA and RFC 1918) should be
considered more reliable than any possibly/probably remote ULA prefix.
Where RFC 6724 failed, is not to require the known to be local ULAs to be
added to the table, so ULA will function as intended.

Thanks

On Sun, May 1, 2022 at 13:50 Vasilenko Eduard <vasilenko.eduard=
[e-mail]> wrote:

> RFC 6724 section 10.6 does not discuss the primary problem: IPv4
> precedence over ULA. This section does not touch IPv4 at all.
>
> Hence, it is not a solution to the problem.
>
>
>
> Moreover, I believe that the default configuration should prefer ULA over
> IPv4.
>
> It is just a problem how to make sure that the ULA source would not
> connect GUA destination in the absence of NPT.
>
> Erik Auerswald proposal (to use Labels) is good but I have shown that in a
> corner case (not sync routers) it would fail because next-hop is chosen 1
> st that restricts PIOs choice.
>
> It is a big question how far WG would agree to change RFC 6724.
>
>
>
> draft-buraglio-v6ops-ula is just a problem statement. Hence, not dependent
> on the solution that would be difficult to find a consensus.
>
> Ed/
>
> *From:* David Farmer [mailto:farmer=[e-mail]]
> *Sent:* Saturday, April 30, 2022 12:21 AM
> *To:* Kevin Myers <[e-mail]>
> *Cc:* Vasilenko Eduard <[e-mail]>; [e-mail];
> v6ops list <[e-mail]>; 6man list <[e-mail]>
> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
>
>
>
> I think this problem needs to be worked on, so I think this draft should
> be promoted to v6ops WG draft.
>
>
>
> As I see it, the problem is that many implementations prefer IPv4 local
> addresses over IPv6 (ULA) local addresses. This is because many
> implementations don't implement the suggestion in RFC6724, section 10.6,
> paragraph 3. Without RFC6724, section 10.6, paragraph 3, hosts prefer IPv4
> local addresses over IPv6 (ULA) local addresses, whether or not NAT44 is
> being used.
>
>
>
> Additionally, RFC6724 seems to have an unstated assumption that all
> devices need and want global connectivity to the Internet. This is probably
> the correct assumption for most general-purpose devices, like desktops,
> laptops, tablets, and even smartphones. However, many other devices, such
> as IoT or 6lowpan devices, and even printers, are intended only to
> communicate locally, or locally to an application-specific gateway, then to
> the cloud or the Internet through that gateway.
>
>
>
> I think maybe the answer is to require the implementation of RFC6724,
> section 10.6, paragraph 3, which is effectively a MAY currently and should
> be promoted to at least SHOULD, if not a MUST. Currently, implementations
> that don't add the local ULA /48 as described in RFC6724, section 10.6,
> paragraph 3, exhibit a default behavior that prefers an IPv4 local address
> over an IPv6 local address.
>
>
>
> Further, it might be worth making separate recommendations for devices
> that are intended for local-only communications, for these devices, it
> might be appropriate for ULA to be preferred over IPv4 and IPv6 GUA, only
> using GUA if ULA is unavailable.
>
>
>
> Thanks.
>
>
>
> On Fri, Apr 29, 2022 at 12:49 PM Kevin Myers <[e-mail]>
> wrote:
>
> I agree, the problem is well defined and documented. It is impactful for
> real world ops and further work is valuable to a great number of orgs and
> operators worldwide.
>
> it should be promoted to v6ops WG draft.
>
>
>
> *From:* v6ops <[e-mail]> *On Behalf Of *Vasilenko Eduard
> *Sent:* Friday, April 29, 2022 11:22 AM
> *To:* [e-mail]
> *Cc:* v6ops list <[e-mail]>; 6man list <[e-mail]>
> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
>
>
>
> IMHO: draft-buraglio-v6ops-ula should be promoted to v6ops WG draft.
>
> The problem is real and important.
>
> Ed/
>
> *From:* v6ops [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Nick Buraglio
> *Sent:* Friday, April 29, 2022 6:09 PM
> *To:* Ed Horley <[e-mail]>
> *Cc:* David Farmer <farmer=[e-mail]>; Xipengxiao <
> xipengxiao=[e-mail]>; v6ops list <[e-mail]>;
> 6man list <[e-mail]>
> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
>
>
>
>
>
> On Fri, Apr 29, 2022 at 10:00 AM Ed Horley <[e-mail]> wrote:
>
> To bring things back into focus. I believe the goal of the submitted
> informational draft was to identify the "Unintended Operational issues with
> ULA" (which is the title of the draft) so that it was clear what structural
> problems exist with ULA currently. It does not propose any fixes, I believe
> that would be a separate but important discussion (well, a yelling
> match apparently). I am specifically interested if anyone has any
> documented and verifiable configurations that either counter the points
> made, disprove the points made, or prove false the points made in the
> submitted draft. For those that have not read it yet you can find it here:
>
> https://datatracker-ietf-org.lucaspardue.com/doc/draft-buraglio-v6ops-ula/
>
> or
>
> https://www.ietf.org/id/draft-buraglio-v6ops-ula-01.html
>
>
>
> Once we agree on what the problem space is, I believe it makes it a bit
> easier to talk about what to actually fix, if anything. I believe that was
> the goal Nick had originally with this, but he can confirm that I imagine.
>
>
>
> Exactly this. The draft was intended to identify a gap, a problem space
> that we encounter fairly frequently in the work I am doing at the moment.
> It is *not* intended to condone address translation, to hasten NAT66, or to
> solutioneer anything. That part should come after we agree that there is in
> fact a problem space as defined in the draft.
>
>
>
> To bring this back to a very simple yes or no question, does anyone
> disagree with, or have recent experience that is counter to the draft?
>
> If the answer is that "yes, we have data that shows that this draft is
> incorrect", let's talk about that.
>
>
>
> nb
>
>
>
>
>
> - Ed
>
>
>
> On Fri, Apr 29, 2022 at 7:38 AM Ted Lemon <[e-mail]> wrote:
>
> The difference is that NAT44 made things better. NAT66 arguably doesn’t.
> Pretty clearly there is a better alternative for the specific pci case
> we’ve been discussing.
>
>
>
> This doesn’t mean people won’t do nat66 out of habit anyway, but it will
> cost extra and add no value, so I don’t see any reason why it would become
> and remain a best practice.
>
>
>
> On Fri, Apr 29, 2022 at 10:16 David Farmer <farmer=
> [e-mail]> wrote:
>
>
>
>
>
> On Thu, Apr 28, 2022 at 6:02 PM Mark Smith <[e-mail]> wrote:
>
> On Fri, 29 Apr 2022 at 07:37, Xipengxiao
> <xipengxiao=[e-mail]> wrote:
>
> > My point is, given PCI DSS 4.0 (what Jen wrote as PCR DSS 4.0), we
> should tell enterprises they no longer need NAT. But if some enterprises
> still insist, respect their decision.
>
> Ignore them. IPv6 doesn't solve any problem they have, and adding NAT
> to IPv6 still won't solve any problem they have, because IPv6 still
> won't solve a problem they have.
>
> ...
>
> Even government mandates to get enterprises to adopt a networking
> protocol don't work - the Internet is supposed to be running CLNS by
> now as mandated by governments around the world. (I expect Vint Cerf
> was being nice while working on this rather than truly believing OSI
> would take over.)
>
> Explaining the Role of GOSIP
> https://www.rfc-editor.org/rfc/rfc1169.html
>
>
>  It's more important to get enterprises to use IPv6 ASAP, than to
> insist that they use the "right" IPv6 solution.
> >
>
> Why is it important to get enterprises to use IPv6 ASAP?
>
>
> Regards,
> Mark.
>
>
>
> Ignore credit cards and enterprises, that's your advice for IPv6?
>
>
>
> So, no one using IPv6 wants to get paid for anything? Or, are you
> suggesting we maintain a quaint IPv4 network in the corner, so we can do
> credit cards and can get paid?
>
>
>
> As for enterprises, Google and AWS are enterprises, are you suggesting
> they should be ignored too? Most of the valuable things on the Internet are
> run by enterprises.
>
>
>
> Supporters of IPv6 need to very much care about enterprises; We need them
> to make their content available via IPv6. We need them to enable IPv6 on
> the Internet-facing parts of their networks.
>
>
>
> Do we need them to enable IPv6 on their internal networks, maybe or maybe
> not. However, if enterprises are not comfortable with IPv6 why would they
> enable their content over IPv6?
>
>
>
> I'm not suggesting we have to do NAT66 or even NPTv6, however, I think we
> should have something to tell those doing NAT44 today and want to maintain
> an internal private network. Maybe ULA with application gateways and
> proxies instead of NAT. But I don't think the internal private network
> model is just going to go away, too many people are comfortable with it.
>
>
>
> Furthermore, ignoring NAT44 from a standardization point of view worked so
> well the last time. "Ignore them, and they will go away," didn't work last
> time and it's not going to work this time either.
>
>
>
> Thanks
>
>
>
>
>
> --
>
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://streaklinks.com/BByrD6ad3b0OpBiK1wctjpyV/https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F2218%2BUniversity%2BAve%2BSE%3Fentry%3Dgmail%26source%3Dg>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
>
> --
>
> Ed Horley
>
> [e-mail] | [phone]
>
> Advancing Cloud, IoT, and Security with IPv6
>
> https://hexabuild.io
>
> And check out the IPv6 Buzz Podcast at
> https://packetpushers.net/series/ipv6-buzz/
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> 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
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
===============================================
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
===============================================