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

[Vasilenko Eduard <[e-mail]>]

Hi Mark,
It would not work.
Who would be doing this "SHOULD"?
Home subscriber? Or SMB entrepreneur?
I could imagine how "dog hairdresser" would be changing policy table in OpenWRT Linux.
IMHO: It should be more automatic.
Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Mark Andrews
Sent: Friday, March 25, 2022 3:37 AM
To: Brian E Carpenter <[e-mail]>
Cc: [e-mail]
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]



> On 25 Mar 2022, at 07:04, 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.

Swap MAY to SHOULD on adding ULA prefixes (10.6.Configuring ULA Preference) would get the desired behaviour.

The following would need to reworded to seperate out the advice for ULA from 6to4.

   An implementation MAY automatically add additional site-specific rows
   to the default table based on its configured addresses, such as for
   Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
   for instance (see Sections 10.6 and 10.7 for examples).

> 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

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]

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