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

[Mark Smith <[e-mail]>]

On Sun, 12 Nov 2023, 13:07 Brian E Carpenter, <[e-mail]>
wrote:

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

Firstly for DNS, with split DNS you can have the same DNS name, the
difference is that internal hosts receive a different set of RRs than an
external host. www.department.example.com would internally resolve to both
internal ULA and GUA of the web server for internal hosts, external hosts
would only receive the GUA address of the web server. You don't have to
burden end users with remembering whether to use the internal or external
names of their web servers. Bind's DNS views can be used to do that, or you
can set up a parallel internal and external authoritative DNS servers and
tree.

I'm not sure you were understanding the common I made above. Assume that
www.department.example.com resolves to host B below.

Within the same network, (ignoring IPv4, less preferred than any IPv6
addresses)

1. host A has a ULA and GUA address, and host B has a ULA and GUA address

2. host A wants to connect to host B, and does a DNS look up for
www.department.example.com.

3. internal DNS provides host B's GUA and ULA addresses, to provide A with
the best possible chance of connecting, by providing all of host B's
addresses.

DNS doesn't and can't know what possible source addresses host A has (ULA
only, GUA only, ULA+GUA), so the best thing for DNS to provide is all of
host B's addresses.

4. Host A should try to use host B's ULA address first. If Host A can't
reach Host B's ULA address, then it should fall back to using Host B's GUA
address, within around 100 to 250 milliseconds. (Happy Eyeballs v2 will do
this in a staggered parallel manner, it's also possible to do it
sequentially with select() or poll() calls).

If Host A prefer's Host B's GUA address over Host B's ULA address, then how
can is it possible for this to work:

RFC 4193:

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


If internal GUAs are preferred over internal ULAs, then internal ULAs will
never be used while there are internal GUA to use, making it impossible to
perform a 4.2 Renumbering above.


If internal GUAs are preferred over internal ULAs, then the only time an
internal ULA would be used would be if, in the above scenario, Host B only
had a ULA address. That's what I was describing here:

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


Regards,
Mark.





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