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

I'm also in agreement that the problem needs to be addressed and would like
to request the draft be promoted to v6ops WG draft.

On Fri, Apr 29, 2022 at 2:22 PM David Farmer <farmer=
40umn.edu@dmarc.ietf.org> wrote:

> 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 <kevin.myers@iparchitechs.com>
> 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 <v6ops-bounces@ietf.org> *On Behalf Of *Vasilenko Eduard
>> *Sent:* Friday, April 29, 2022 11:22 AM
>> *To:* buraglio@es.net
>> *Cc:* v6ops list <v6ops@ietf.org>; 6man list <ipv6@ietf.org>
>> *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:v6ops-bounces@ietf.org <v6ops-bounces@ietf.org>] *On
>> Behalf Of *Nick Buraglio
>> *Sent:* Friday, April 29, 2022 6:09 PM
>> *To:* Ed Horley <ed@hexabuild.io>
>> *Cc:* David Farmer <farmer=40umn.edu@dmarc.ietf.org>; Xipengxiao <
>> xipengxiao=40huawei.com@dmarc.ietf.org>; v6ops list <v6ops@ietf.org>;
>> 6man list <ipv6@ietf.org>
>> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
>> wider operational input]]
>>
>>
>>
>>
>>
>> On Fri, Apr 29, 2022 at 10:00 AM Ed Horley <ed@hexabuild.io> 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 <mellon@fugue.com> 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=
>> 40umn.edu@dmarc.ietf.org> wrote:
>>
>>
>>
>>
>>
>> On Thu, Apr 28, 2022 at 6:02 PM Mark Smith <markzzzsmith@gmail.com>
>> wrote:
>>
>> On Fri, 29 Apr 2022 at 07:37, Xipengxiao
>> <xipengxiao=40huawei.com@dmarc.ietf.org> 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:farmer@umn.edu
>> 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: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>> --
>>
>> Ed Horley
>>
>> ed@hexabuild.io | (925) 876-6604
>>
>> 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
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> ᐧ
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
Ed Horley
ed@hexabuild.io | (925) 876-6604
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/