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

[Bob Hinden <[e-mail]>]

Brian,

> On Mar 24, 2022, at 1:04 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> (Trying, far too late, to change the Subject to be the actual subject...)
> 
> I wasn't paying enough attention when RFC6724 was done. I think it's even
> more wrong each time I look at it. For example, it has the consequence that
> if a pair of hosts have both RFC1918 and ULA addresses, the default for
> communication between them is RFC1918. D'Oh. If two hosts have ULAs in the
> same /64, they will nevertheless try IPv4 first. D'Oh. And the default table
> in RFC6724 is sticky in practice, even if configurable in theory.
> 
> I think this needs serious work (in 6MAN most likely).

Without any hats on, I agree.   Suggest you start a thread on the IPv6 list with some proposed changes and/or write a draft.

Bob


> 
> Regards
>   Brian Carpenter
> 
> On 25-Mar-22 00:29, Philip Homburg wrote:
>>> (Dual-stack cannot be the answer anyway - it will have all the issues
>>> of IPv4, plus the added complications of dual-stack.  Services need to
>>> be dual-stack, but for all the rest, single-stack IPv6 needs to be
>>> the end goal - see facebook etc)
>> Obviously, on an IPv6-only system, there is no IPv4, so the relative
>> priority of ULA compared to IPv4 does not matter.
>> I'm curious what IPv4aaS we want to deploy. I consider NAT64 a complete
>> disaster (even if the form of 464xlat). Given how the internet works,
>> we will probably end up with NAT64 everywhere until the end of times.
>>> This is not what I had in mind.  If "we" decide that ULA is a good
>>> way forward, IETF can update RFCs, and vendors will eventually
>>> update their base OS.  It might take 5 years, but so will everything
>>> else in Big Enterprise land.
>> The problem with ULA is that we have lots of installations where hosts with
>> a ULA address don't have access to the IPv6 internet. Often, CPEs announce
>> a ULA when the CPE doesn't have an IPv6 uplink.
>> In contrast, where RFC 1918 was meant for local IPv4 communication, it is
>> now on a very large scale the primary method for a host to reach the IPv4
>> internet.
>> So to avoid the situation where we say that ULA is local and then use it
>> to connect to the IPv6 internet, we should just allocate a new space. And
>> explicitly give it the property to connect to the IPv6 internet through
>> through some sort of address translation.
>> There is also a nice tie-in with PI. Obviously, putting millions of PI
>> prefixes in BGP does not scale.
>> On the other hand, there is no such limit if the PI space is used behind NAT.
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> .
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops