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

[Mark Smith <[e-mail]>]

I've always seen the main themes of IPv6 default address selection to be:

- prefer IPv6 over IPv4 when there is a choice, as the main IPv6 transition
mechanism

- prefer likely most reliable and available, with smaller scoped addresses
being likely more reliable and available than greater ones.

For example, a ULA address is likely more reliable and available than a GUA
address, because a local network is likely more reliable than a global one.

Ultimately though, address selection is a best guess. The current state of
the network may make the default selection order at a particular time
incorrect.

So applications should walk through the set of DAs and try to connect to
them until one succeeds, as discussed in RFC6724

Looking at RFC 5220, used to justify IPv4 over ULAs, that point seems to
have been was missed. There were scenarios where IPv4 was more reliable
than ULAs, due to ULA's being put in global DNS, contrary to the advice in
ULA RFC4193. Rather than letting applications overcome this DNS
configuration error by attempting to connect to all addresses in the set
until successful, ULAs were instead put below IPv4, contrary to the main
intent of using IPv6 over IPv4 when available.

So the uncommon case of an error of putting ULAs in global DNS was
countered by making it the common case of preferring IPv4 over ULAs in RFC
6724 default address selection.

Regards,
Mark.


On Sat, 6 Aug 2022, 08:14 David Farmer, <farmer=[e-mail]>
wrote:

>
>
> On Fri, Aug 5, 2022 at 4:04 PM Brian E Carpenter <
> [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, 172.16.0.0/12, and 192.168.0.0/16, and
> maybe 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]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>