Re: [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames

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

> The local ULA address space would only be used to reach hosts that only have a ULA address.

Yes, that is a desirable result. In some enterprises, there is a convention that internal servers have names like w3.department.example.com, and externally visible servers are like www.department.example.com. You put w3.* names in internal-only DNS with ULAs, and www.* names
in global DNS with GUAs, and everything works as desired for clients with both kinds of address.

Regards
    Brian

On 12-Nov-23 10:05, Mark Smith wrote:
> Hi Nick,
> 
> On Sun, 12 Nov 2023, 07:24 Nick Buraglio, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     A quick recap of this draft:
> 
>     * It changes the preference for ULAs to be above IPv4
> 
> 
> As I read the updated table, RIR assigned GUA DAs match on 0::/0, resulting in a preference of 40.
> 
> ULA DAs match on fc00::/7, resulting in a preference of 30.
> 
> This means GUA DAs will be preferred over ULAs when both are in use in a network, which I think will be the common case, which includes residential networks.
> 
> Consequently there wouldn't be much if any point in having a ULA address space in a GUA addressed network. The local ULA address space would only be used to reach hosts that only have a ULA address.
> 
> ULAs are basically the functional equivalent to the old site-locals, except with a big random number in them to overcome the ambiguity problems that site-locals had because they were a single, non-unique prefix that would have been duplicated many times.
> 
> In RFC 3484, site-locals won over GUAs because they had a site-local scope, which is smaller than GUA's global scope.
> 
> The same outcome needs to be achieved with ULAs verses GUAs.
> 
> Specifically, fc00::/7 needs to have a preference of 45 if 0::/0 continues to have a preference of 40.
> 
> Regards,
> Mark.
> 
> 
> 
>     * It leaves all labels intact, allowing for proper IPv6 to IPv6 behavior
>     * It performs a deliberate tactical change, aimed at demoting IPv4 below all IPv6 enabling consistent behavior, and continuing to leverage the aforementioned existing labels
>     * The newest version adds the section 5.5 MUST adjust back in, per IETF 118 input
>     * The draft is deliberately as simple as we could make it because the topic is fairly complex. It does not address any signaling or other changes to the address selection mechanics that would need to be executed in some new version of getaddrinfo(), and that is by design - see bullet 3.
> 
>     118 comments are already in the working copy, we will address David's great input this week and submit a new version. At that time we will humbly request that it be considered for WGLC.
> 
>     nb
> 
>     On Sat, Nov 11, 2023 at 1:55 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         On 12-Nov-23 07:25, Ted Lemon wrote:
>          > You can’t deprecate ULAs. We’re using them. They work really well. What we are discussing here is if there are things we can do that make them work even better.
> 
>         Exactly. The problem is not ULAs, which work as intended. The problems are:
> 
>         a) Split-horizon DNS, while widely used, is somehow regarded as suspect.
> 
>         b) The RFC3484/6724/getaddrinfo() model is fundamentally inadequate.
> 
>         a) is also behind the answer to Lorenzo's question. It's wrong to put
>         a ULA in public DNS, because it's a private address. It's fine to put
>         a ULA in private DNS, because it's a private address.
> 
>         RFC 4193 says this:
> 
>          >    At the present time, AAAA and PTR records for locally assigned local
>          >    IPv6 addresses are not recommended to be installed in the global DNS.
> 
>         That should probably have used RFC2119 language, but it's clear enough.
> 
>              Brian
> 
>          >
>          > Op za 11 nov 2023 om 16:36 schreef Mark Smith <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >
>          >     I'm starting to believe it is better to deprecate ULAs.
>          >
>          >     People can't seem to get past default address selection being a static starting point, and that it can't be made to cope with all situations because it is a static mechanism which can never cope with the normal dynamic situations of occasional unreachability and human error.
>          >
>          >     If GUAs are preferred over ULAs, then ULAs aren't of any use in networks with GUAs.
>          >
>          >     So much for, from RFC 4193,
>          >
>          >     4.2 <https://datatracker.ietf.org/doc/html/rfc4193#section-4.2 <https://datatracker.ietf.org/doc/html/rfc4193#section-4.2>>. Renumbering and Site Merging
>          >
>          >         The use of Local IPv6 addresses in a site results in making
>          >         communication that uses these addresses independent of renumbering a
>          >         site's provider-based global addresses.
>          >
>          >
>          >
>          >
>          >
>          >     On Sat, 11 Nov 2023, 20:57 Lorenzo Colitti, <lorenzo=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>          >
>          >         Why is is a misconfiguration to put a ULA AAAA record in the DNS? Because it is never preferred over anything, adding it won't break anything, and it will work on IPv6-only networks when global IPv6 connectivity is down. I could totally see someone doing the following:
>          >
>          > server.smallcompany.com <http://server.smallcompany.com> <http://server.smallcompany.com <http://server.smallcompany.com>> AAAA fd73:4899:2a7f:a93a::53
>          > server.smallcompany.com <http://server.smallcompany.com> <http://server.smallcompany.com <http://server.smallcompany.com>> AAAA 2001:db8:4923::1
>          > server.smallcompany.com <http://server.smallcompany.com> <http://server.smallcompany.com <http://server.smallcompany.com>> A 192.0.2.1
>          >
>          >         This would work well today. The server would be reached:
>          >
>          >         - over global IPv6, if the client has it
>          >         - over ULA, if the client is v6-only and is within small company's network but there is no global connectivity (e.g. ISP link down and addresses deprecated)
>          >         - over IPv4, otherwise
>          >
>          >         People might well have done this today because it works for them. If we change the rules as proposed in this draft, it will stop working for any home network that has a ULA and IPv4, but no IPv6 (and there are lots of these).
>          >
>          >         This is a fundamental property of ULA: it doesn't provide reachability. If we give all of ULA the same label, and prefer it over other addresses, we'll always end up with problems.
>          >
>          >         What happened to the idea of treating "same /48" ULA differently from "rest of ULA space"?
>          >
>          >         On Fri, 10 Nov 2023, 15:57 David Farmer, <farmer=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>          >
>          >             In this scenario, a ULA source with a non-local ULA destination can only occur from a misconfiguration that includes both a ULA and Global IPv4 addresses in the Global DNS, contradicting Section 4.4 of RFC4193.
>          >
>          >             Nevertheless, even if this misconfiguration happens, Happy Eyeballs, if implemented, will try the non-local ULA destination with the ULA source and the IPv4 destination and source pairings. The likely result is IPv4 being used in practice since the ULA source will typically fail to communicate with the non-local ULA destination, and IPv4 will succeed if IPv4 Internet connectivity is available.
>          >
>          >             If Happy Eyeballs is not implemented, the non-local ULA destination with the ULA source is preferred, and the ULA source will typically fail to communicate with the non-local ULA destination; however, if the operational guidelines in Section 4.3 of [RFC4193] are followed. In that case, recognizing this failure can be accelerated, and transport layer timeouts (e.g., TCP) can be avoided. These guidelines will cause a Destination Unreachable ICMPv6 Error to be received by the source device, signaling the next address in the list to be tried, as discussed in Section 2 of RFC 6724;
>          >
>          >                 Well-behaved applications SHOULD NOT simply use the first address returned from an API such as getaddrinfo() and then give up if it fails. For many applications, it is appropriate to iterate through the list of addresses returned from getaddrinfo() until a working address is found. For other applications, it might be appropriate to try multiple addresses in parallel (e.g., with some small delay in between) and use the first one to succeed.
>          >
>          >
>          >             Should this also be discussed in the draft?
>          >
>          >             Thanks
>          >
>          >             On Fri, Nov 10, 2023 at 3:35 AM Lorenzo Colitti <lorenzo=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>          >
>          >                 I don't know how common this is, but it's probably worth thinking about.
>          >
>          >                 Many home routers assign ULAs, even if they don't have native IPv6. On such networks, a hostname that has ULA and IPv4 (or ULA and global and IPv4) will currently work using IPv4.
>          >
>          >                 If hosts update to follow the new rules in draft-ietf-6man-rfc6724-update, that will break because new hosts will prefer ULA over IPv4. This won't work, because the ULA is actually a different ULA and the home router will drop the packets.
>          >                 --------------------------------------------------------------------
>          >                 IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >                 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>          >                 --------------------------------------------------------------------
>          >
>          >
>          >
>          >             --
>          >             ===============================================
>          >             David Farmer Email:[e-mail] <mailto:[e-mail]> <mailto:[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
>          >             ===============================================
>          >
>          >         --------------------------------------------------------------------
>          >         IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>          >         --------------------------------------------------------------------
>          >
>          >     --------------------------------------------------------------------
>          >     IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>          >     --------------------------------------------------------------------
>          >
>          >
>          > --------------------------------------------------------------------
>          > IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]>
>          > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>          > --------------------------------------------------------------------
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>         --------------------------------------------------------------------
>