Re: [v6ops] draft-buraglio-v6ops-ula discussion

[Brian E Carpenter <[e-mail]>]

On 06-Aug-22 10:13, David Farmer wrote:
> 
> 
> On Fri, Aug 5, 2022 at 4:04 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Eric,
> 
>     On 06-Aug-22 08:13, Eric Vyncke (evyncke) wrote:
>      > David,
>      >
>      > You are correct. I think that the priority order should be (from most suitable to least suitable):
>      >
>      >   * Global IPv6
>      >   * Global IPv4
>      >   * ULA
>      >   * RFC 1918
> 
>     That may be your opinion, but many people disagree and that is why the consensus is otherwise.
> 
>     My own order of default preference for *destination* address selection would be:
> 
>     ULA
>     Global IPv6
>     RFC 1918
>     Global IPv4
> 
>     The rationale is: Prefer IPv6 always. Prefer local addressing when available.
> 
>     Obviously this requires similar rules in discovery (whether by DNS or some other method). If you can't discover a ULA, you will never use a ULA.
> 
>     Source address selection is simple: longest match with the destination.
> 
>           Brian
> 
> 
> However, neither of those is what RFC6724 specifies. Currently, the order is;
> 
> ULA Local /48 (if RFC6724, section 10.6, is implemented automatically or manually, which is generally not the case in the wild)
> Global IPv6
> Global IPv4/ RFC1918
> ULA /7
> Further, the table from RFC 3484 was;
> 
> Global IPv6/ ULA
> Global IPv4/ RFC1918
> 
> Personally, I think RFC6724 almost has it right; what it got wrong is that section 10.6 should be mandatory and automatic, implemented by the IP stack, and not effectively optional and left to manual implementation.

Of course I agree with that.

> As I see it, the problem with distinguishing global IPv4 addresses from local RFC1918 IPv4 addresses is that RFC1918 IPv4 addresses are most often used as global IPv4 source addresses through the use of NAT. Therefore, distinguishing global IPv4 addresses from local RFC1918 IPv4 addresses isn't practical with today's highly NATed IPv4 Internet. Furthermore, adding RFC1918 IPv4 addresses to the table requires at least three entries, one for 10.0.0.0/8 <http://10.0.0.0/8>, 172.16.0.0/12 <http://172.16.0.0/12>, and 192.168.0.0/16 <http://192.168.0.0/16>, and maybe 100.64.0.0/10 <http://100.64.0.0/10> from RFC6598 should be included as well. So, distinguishing global IPv4 addresses from local RFC1918 IPv4 addresses will add a lot of cruft to the table.

Exactly. A lot of cruft to make a legacy protocol work slightly better.

    Brian

> 
> Thanks
> 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================