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

[Vasilenko Eduard <[e-mail]>]

+1

-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Nick Buraglio
Sent: Friday, March 25, 2022 12:21 AM
To: Brian E Carpenter <[e-mail]>
Cc: [e-mail]
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

I am happy to participate, and would like to help with this effort.

nb



On Thu, Mar 24, 2022 at 3: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).
>
> 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

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