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

["Ackermann, Michael" <[e-mail]>]

Thanks Brian
Agree on the subject change and agree on  having this looked at in 6MAN.  

I believe that if/when enterprises finally move to IPv6, there will be several ULA use case candidates.   But only if they work right.   Several of these issues you outlined below would seem to force a lot of traffic to stay on ipv4.   
Thanks for looking into this!

Mike


-----Original Message-----
From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
Sent: Thursday, March 24, 2022 4:04 PM
To: Philip Homburg <[e-mail]>; [e-mail]
Subject: [v6ops] ULA precedence [Thoughts about wider operational input]

[External email]


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

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


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.


This message was secured by Zix(R).