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

[Vasilenko Eduard <[e-mail]>]

Hi Philip,
What you proposed (separate ULA prefix for NAT) is robust and solid but very heavy - it would need a big change for many RFCs (new address type).
Would you agree to the tradeoff: assume that GUA PIO is absent for ULA+NPT case.
Then I do not see a problem in the implementation: just ULA priority about IPv4 (it is not mandatory to put it in priority above GUA) would be enough.
This is the minimal change for RFC 6724 only.
Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Philip Homburg
Sent: Monday, April 25, 2022 1:42 PM
To: [e-mail]
Cc: 6man list <[e-mail]>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

> > This seems like it would encourage the use of IPv6 NAT. I think 
> > there is re
> asonably strong consensus within the IETF that that is not the right 
> way to g o, because it pushes problems on to application developers. 
> This adds costs f or NAT traversal software development and 
> maintenance, and requires devices t o 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?

Just my 2 cents:

If we have different uses for ULAs, that have significantly different properties then we should allocate different prefixes.

There is one common use of ULA, where we cannot expect a ULA address to communicate with GUA addresses. Obviously, a host should avoid trying this because it will not work.

Other deployments want to put ULAs behind some sort of NAT that allows outgoing flows with an ULA source to connect to GUA addresses.

We can try lots of different fragile magic. But in my opinion the most robust way forward to use a different prefix.

In this context, I wonder why operators are trying to use ULA instead of an PA prefix. Is it lack of money? Being compatible with RFC 1918?

In my optinion, draft-buraglio-v6ops-ula-01 is incorrect in the way Section 2 starts with "The [RFC6724] definition is incorrect for ULA precedence [...]". What we need, is a draft that starts with a description of use cases for ULA, and once we have agreement over those use cases, we can see which solutions support them. 

I strongly dislike NAT. But certainly in the case of NAT, IETF is not the protocol police. If operators want to use NAT, we should accept that as reality. We can only try to offer tools that make NAT unnecessary.

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops