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

[Vasilenko Eduard <[e-mail]>]

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

It is not a relevant concern to Brian’s proposal.
Because NAT is for source address but Brian was talking about destination address priority.

Ed/
From: v6ops [mailto:[e-mail]] On Behalf Of David Farmer
Sent: Saturday, August 6, 2022 1:13 AM
To: Brian E Carpenter <[e-mail]>
Cc: v6ops list <[e-mail]>
Subject: Re: [v6ops] draft-buraglio-v6ops-ula discussion



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.

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.

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