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

[Philip Homburg <[e-mail]>]

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