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

[Mark Andrews <[e-mail]>]

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