Prioritizing known-local IPv6 ULAs through address selection policy
draft-ietf-6man-rfc6724-update-09

6MAN                                                         N. Buraglio
Internet-Draft                                   Energy Sciences Network
Updates: 6724 (if approved)                                     T. Chown
Intended status: Standards Track                                    Jisc
Expires: 30 December 2024                                      J. Duncan
                                                        Tachyon Dynamics
                                                            28 June 2024

  Prioritizing known-local IPv6 ULAs through address selection policy
                   draft-ietf-6man-rfc6724-update-09

Abstract

   When RFC 6724 was published it defined an address selection algorithm
   along with a default policy table, and noted a number of examples
   where that policy table might benefit from adjustment for specific
   scenarios.  It also noted that it is important for implementations to
   provide a way to change the default policies as more experience is
   gained.  This update draws on several years of such operational
   experience to refine RFC 6724, with emphasis on preference for the
   use of ULA addresses over IPv4 addresses and the addition of
   mandatory support for Rule 5.5.  It also defines the concept of
   "known-local" ULA prefixes and the means by which nodes can identify
   them and insert them into their policy table such that local ULA-to-
   ULA communications become preferred over GUA-to-GUA for local use.
   The update also demotes the preference for 6to4 addresses.  These
   changes to default behavior improve supportability of common use
   cases, including automatic / unmanaged scenarios.  It is recognized
   that some less common deployment scenarios may require explicit
   configuration or custom changes to achieve desired operational
   parameters.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Buraglio, et al.        Expires 30 December 2024                [Page 1]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   This Internet-Draft will expire on 30 December 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Operational Issues Regarding Preference for IPv4 addresses over
           ULAs  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Preference of 6to4 addresses  . . . . . . . . . . . . . . . .   6
   5.  Adjustments to RFC 6724 . . . . . . . . . . . . . . . . . . .   6
     5.1.  Policy Table Update . . . . . . . . . . . . . . . . . . .   6
     5.2.  Rule 5.5  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Automatic insertion of known-local ULA prefixes into the
           policy table  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Configuration of the default policy table . . . . . . . . . .   9
   7.  Intended behaviors  . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  GUA-GUA preferred over IPv4-IPv4  . . . . . . . . . . . .   9
     7.2.  GUA-GUA preferred over ULA-ULA  . . . . . . . . . . . . .   9
     7.3.  ULA-ULA preferred over IPv4-IPv4  . . . . . . . . . . . .  10
     7.4.  IPv4-IPv4 preferred over ULA-GUA  . . . . . . . . . . . .  10
   8.  Discussion of ULA source with GUA or remote ULA
           destination . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  The ULA Label and its Precedence  . . . . . . . . . . . .  11
     8.2.  Happy Eyeballs  . . . . . . . . . . . . . . . . . . . . .  12
     8.3.  Try the Next Address  . . . . . . . . . . . . . . . . . .  12
   9.  Following ULA operational guidelines in RFC 4193  . . . . . .  13
     9.1.  Filtering ULA-source addresses at site borders  . . . . .  13
     9.2.  Avoid using ULA addresses in the global DNS . . . . . . .  13
   10. The practicalities of implementing address selection
           support . . . . . . . . . . . . . . . . . . . . . . . . .  13
   11. Limitations of RFC 6724 . . . . . . . . . . . . . . . . . . .  14
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15

Buraglio, et al.        Expires 30 December 2024                [Page 2]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   15. Summary of changes and additional text since RFC 6724 . . . .  15
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     16.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Since its publication in 2012, [RFC6724] has become an important
   mechanism by which nodes can perform address selection, deriving the
   most appropriate source and destination address pair to use from a
   candidate set by following the procedures defined in the RFC.  Part
   of the process involves the use of a policy table, where the
   precedence and labels for address prefixes are listed, and for which
   a default policy table is defined.

   It was always expected that the default policy table may need to be
   changed based on operational experience; section 2.1 says "It is
   important that implementations provide a way to change the default
   policies as more experience is gained" and points to the examples in
   Section 10, which include Section 10.6 where a ULA example is
   presented.

   This document is written on the basis of such operational experience,
   in particular for scenarios where ULAs are used for their intended
   purpose as stated in [RFC4193], i.e., they are designed to be routed
   within a local site and by default not advertised, used or received
   from externally to that site.  The document defines how preference
   for ULAs may be elevated for appropriate, common scenarios.

   To support the preference to use ULA address pairs over GUA address
   pairs for local intra-site scenarios, the concept of a "known-local"
   ULA address is introduced.  The means for nodes to determine ULA
   prefixes that are known to be local to the site they are operating in
   and to insert those prefix(es) into their policy table is described
   in this document.  This capability allows nodes to prefer ULA-ULA
   communication locally, but still use GUA-GUA address pairs for
   external communication, and importantly avoid selecting a ULA source
   to talk to a non-local ULA destination.

   It also reinforces the text in RFC 6724 to require support for Rule
   5.5.

   The overall goal of the document is to improve behavior for common
   scenarios, and to assist in the phasing out of use of IPv4, while
   noting that some specific scenarios may still require explicit
   configuration.

Buraglio, et al.        Expires 30 December 2024                [Page 3]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   An IPv6 deployment, whether enterprise, residential or other, may use
   combinations of IPv6 GUAs, IPv6 ULAs, IPv4 globals, IPv4 RFC 1918
   addressing, and may or may not use some form of NAT.  However, this
   document makes no comment or recommendation on how ULAs are used, or
   on the use of NAT in an IPv6 network.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   GUA: Global Unicast Addressing as defined in [RFC3587]

   ULA: Unique Local Addressing as defined in [RFC4193]

   Known-local ULA: A ULA prefix that an individual organization/site
   has determined to be local to a given node/network

3.  Operational Issues Regarding Preference for IPv4 addresses over ULAs

   With multiaddressing being the norm for IPv6, moreso where nodes are
   dual-stack, the ability for a node to pick an appropriate address
   pair for communication is very important.

   Where getaddrinfo() or a comparable API is used, the sorting behavior
   should take into account both the source addresses of the requesting
   node as well as the destination addresses returned, and sort the
   candidate address pairs following the procedures defined in RFC 6724.

   The current default policy table leads to preference for IPv6 GUAs
   over IPv4 globals, which is widely considered preferential behavior
   to support greater use of IPv6 in dual-stack environments.  This
   helps allow sites to phase out IPv4 as its evidenced use becomes ever
   lower.

   However, there are two issues with preference, or rather non-
   preference, for ULAs as orginally defined in RFC 6724.

   One is that the same default policy table also puts IPv6 ULAs below
   all IPv4 addresses, including [RFC1918] addresses, such that
   IPv4-IPv4 address pairs are favoured over ULA-ULA address pairs.  For
   many site operators this behavior will be counter-intuitive, given
   the IPv6 GUA preference, and may create difficulties with respect to
   planning, operational, and security implications for environments
   where ULA addressing is used in IPv4/IPv6 dual-stack network

Buraglio, et al.        Expires 30 December 2024                [Page 4]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   scenarios.  The expected default prioritization of IPv6 traffic over
   IPv4 by default, as happens with IPv6 GUA addressing, does not happen
   for ULAs.

   As a result, the use of ULAs is not a viable option for dual-stack
   networking transition planning, large scale network modeling, network
   lab environments or other modes of large scale networking that run
   both IPv4 and IPv6 concurrently with the expectation that IPv6 will
   be preferred by default.

   The other issue is that where nodes in a dual-stack site are
   addressed from both ULA and GUA prefixes, RFC 6724 will see GUA-GUA
   address pairs chosen over ULA-ULA.  One goal of ULA addressing was to
   allow local communications to be independent of the availablility of
   external connectivity and addressing, such that persistent ULAs can
   be used even when the global prefix made available to a site is
   withdrawn or changes.

   This document therefore describes two methods to support a node
   implementing elevated or differential preference for ULAs in specific
   conditions.

   The first, general method is by updating the default policy table to
   elevate the preference for ULAs such that ULAs will be preferred over
   all IPv4 addresses, providing more consistent and less confusing
   behavior for operators, and to assist operators in phasing out IPv4
   from dual-stack environments, since by this update both IPv6 GUAs and
   ULAs will be preferred over any IPv4 addresses.  This is an important
   enabler for sites seeking to move from dual-stack to IPv6-only
   networking.

   The second method introduces the concept of known-local ULAs.  RFC
   6724 includes a method by which nodes MAY provide more fine-grained
   support for elevating the preference for specific ULA prefixes, while
   leaving other general ULA prefixes at their existing precedence.
   This document elevates the requirement for specific ULA prefixes to
   be inserted into the policy table to be a MUST, but only for observed
   prefixes that are known to be local, i.e., known-local ULAs.  Nodes
   implementing this behaviour will see ULA prefixes known to be local
   to the node's site having precedence over IPv6 GUA addresses, such
   that they can use ULA addressing independently of global prefixes
   within their site and continue to use GUA-GUA address pairs to talk
   to destinations external to their site.

Buraglio, et al.        Expires 30 December 2024                [Page 5]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   These changes aim to improve the default handling of address
   selection for common cases, and unmanaged / automatic scenarios
   rather than those where DHCPv6 is deployed.  The changes are
   discussed in more detail in the following sections, with a further
   section providing a summary of the proposed updates.

4.  Preference of 6to4 addresses

   The anycast prefix for 6to4 relays was formally deprecated by
   [RFC7526] in 2015, and since that time the use of 6to4 addressing has
   further declined, with very little evidence of its use on the public
   internet.  Note that RFC 7526 does not deprecate the 6to4 IPv6 prefix
   2002::/16, it only deprecates the 6to4 Relay IPv4 prefix.

   This document therefore demotes the precedence of the 6to4 prefix in
   the policy table to the same precedence as carried by the Teredo
   prefix.  Leaving this entry in the default table will cause no
   problems and will help if any deployments still exist, and ensure
   6to4 prefixes are differentiated from general GUAs.

   The discussion regarding the adding of 6to4 site prefixes in section
   10.7 of RFC6724 remains valid.

5.  Adjustments to RFC 6724

   This document makes three specific changes to RFC 6724: first to
   update the default policy table, second to change Rule 5.5 on
   prefering addresses in a prefix advertised by the next-hop to a MUST,
   and third to require that nodes MUST insert observed known-local ULAs
   into their policy table.

5.1.  Policy Table Update

   This update alters the default policy table listed in Rule 2.1 of RFC
   6724.

   The table below reflects the current RFC 6724 state on the left, and
   the updated state defined by this RFC on the right:

Buraglio, et al.        Expires 30 December 2024                [Page 6]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

                    RFC 6724                              Updated
Prefix        Precedence Label        Prefix        Precedence Label
::1/128               50     0        ::1/128               50     0
::/0                  40     1        ::/0                  40     1
::ffff:0:0/96         35     4        ::ffff:0:0/96         20     4 (*)
2002::/16             30     2        2002::/16              5     2 (*)
2001::/32              5     5        2001::/32              5     5
fc00::/7               3    13        fc00::/7              30    13 (*)
::/96                  1     3        ::/96                  1     3
fec0::/10              1    11        fec0::/10              1     11
3ffe::/16              1    12        3ffe::/16              1     12

(*) value(s) changed in update

   The update moves 2002::/16 to de-preference its status in line with
   [RFC7526] and moves the precedence of fc00::/7 above legacy IPv4,
   with ::ffff:0:0/96 now set to precedence 20.

5.2.  Rule 5.5

   The heuristic for address selection defined in Rule 5.5 of Section 5
   of RFC 6724 to prefer addresses in a prefix advertised by a next-hop
   router has proven to be very useful.

   The text in RFC 6724 states that the Rules MUST be followed in order,
   but also includes a discussion note under Rule 5.5 that says that an
   IPv6 implementation is not required to remember which next-hops
   advertised which prefixes and thus that Rule 5.5 is only applicable
   to implementations that track this information.

   This document elevates the requirement to prefer ULA addresses in a
   prefix advertised by a next-hop router to a MUST for all nodes.

5.3.  Automatic insertion of known-local ULA prefixes into the policy
      table

   Section 2.1 of RFC 6724 states that "an implementation MAY
   automatically add additional site-specific rows to the default table
   based on its configured addresses, such as for Unique Local Addresses
   (ULAs)".

   If a node can determine which ULA prefix(es) are known to be local,
   it can provide differential treatment for those over general ULAs,
   and insert these into the policy table at a higher precedence than
   GUAs while keeping all general ULA prefixes to a lower precedence.

   This document thus elevates the MAY requirement above for insertion
   to a MUST for the specific case of known-local ULAs.

Buraglio, et al.        Expires 30 December 2024                [Page 7]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   Such known-local ULA prefixes include prefixes containing a ULA
   address assigned to any interface via manual configuration, Route
   Information Options (RIO) in RAs, or SLAAC or learned from a PIO
   (regardless of how the PIO flags are set) received on any interface.
   Additionally, type C hosts, as defined in [RFC4191] section 3,
   include any ULA prefixes learned from RIOs as known-local ULAs.

   The following rules define how known-local ULA prefixes are inserted
   into the address selection policy table for a node, through a
   conceptual list of known-local prefixes.

   1.  RIOs from within fc00::/7 are considered the preferred
       information source for determining known-local ULAs and should
       override other conflicting information or assumptions from other
       sources, including PIOs.

   2.  RIOs within fd00::/8 with a prefix length of /48 or longer MUST
       be added to the known-local ULA list, while RIOs within fd00::/8
       that are shorter than /48 MAY be excluded from the known-local
       ULA list.

   3.  RIOs within fc00::/8 of any prefix length SHOULD be added to the
       known-local ULA list.

   4.  PIOs of length /64 with A=1 or interface addresses from within
       fd00::/8 that are not already covered by the known-local ULA list
       SHOULD be added to the list with an assumed prefix length of /48.

   5.  Addresses added by other means (static, DHCPv6, etc) that are not
       currently in the prefix policy table, then the /48 known-local
       prefix within which the address sits MUST be added.  The entry
       MUST be removed upon the address being removed from an interface
       when there is no covering RIO or PIO.

   6.  In all cases, when inserting an entry in the known-local ULA list
       a node MUST set the label of the prefix to 14 (rather than the
       default ULA label of 13) and its precedence to 45.

   7.  A node MUST remove inserted entries from its policy table when
       announced prefixes are deprecated, or when an interface address
       within fd00::/8 is removed and there is no covering RIO or PIO.

   8.  Regardless of prefix length or associated flags, other PIOs from
       within fc00::/7 that are not already covered by the known-local
       ULA list MAY added, but only with the advertised prefix length.

Buraglio, et al.        Expires 30 December 2024                [Page 8]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   Note that the above rules differentiate between the part of the
   overall ULA space (fc00::/7) that is in use at the time of
   publication of this document (fd00::/8) and the space that is
   currently reserved for future use (fc00::/8).

   When support is added for the insertion of known-local ULA prefixes
   it MUST default to on, but a mechanism SHOULD be supported to
   administratively toggle the behaviour off and on.

   Tools that display a node's default policy table MUST show all
   currently inserted known-local ULA prefixes.

6.  Configuration of the default policy table

   As stated in Section 2.1 of RFC 6724 "IPv6 implementations SHOULD
   support configurable address selection via a mechanism at least as
   powerful as the policy tables defined here".

   Based on operational experience to date, it is important that node
   policy tables can be changed once deployed to support future emerging
   use cases.  This update thus re-states the importance of such
   configurability.

7.  Intended behaviors

   In this section we review the intended default behaviors after this
   update is applied.

7.1.  GUA-GUA preferred over IPv4-IPv4

   This is the current behaviour, and remains unaltered.  The rationale
   is to promote use of IPv6 GUAs in dual-stack environments.

7.2.  GUA-GUA preferred over ULA-ULA

   This is the current behaviour, and remains unaltered for the general
   case.

   However, where a ULA prefix is determined to be local, and added as a
   known-local ULA prefix to a node's address selection policy table,
   communications to addresses in that prefix will prefer ULA-ULA
   address pairs to GUA-GUA.

   By only adapting this behaviour for known-local ULAs, a node will not
   select a ULA source to talk to a non-local ULA destination and will
   instead correctly use GUA-GUA.

Buraglio, et al.        Expires 30 December 2024                [Page 9]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   Nodes not yet implementing this RFC will continue to use GUA-GUA over
   ULA-ULA for all cases.

7.3.  ULA-ULA preferred over IPv4-IPv4

   This is another change introduced by this update.  RFC 6724 as
   originally defined would lead to IPv4 being preferred over ULAs,
   which is contrary to the spirit of the IPv6 GUA preference over IPv4,
   and to the goal of removing evidenced use of IPv4 in a dual-stack
   site before transitioning to IPv6-only.

   This document elevates the precedence of ULAs above IPv4, so ULA-ULA
   address pairs will be chosen over IPv4-IPv4 pairs.

7.4.  IPv4-IPv4 preferred over ULA-GUA

   An IPv6 ULA address will only be preferred over an IPv4 address if
   both IPv6 ULA source and destination addresses are available.  With
   Rule 5 of Section 6 of RFC 6724 and the ULA-specific label added in
   [RFC6724] (which was not present in [RFC3484]) an IPv4 source and
   destination will be preferred over an IPv6 ULA source and an IPv6 GUA
   destination address, even though generally IPv6 ULA addresses are
   preferred over IPv4 in the policy table as proposed in this update.
   The IPv4 matching label trumps ULA-GUA.

8.  Discussion of ULA source with GUA or remote ULA destination

   In this section we present a discussion on the specific cases where a
   ULA source may be communicating with a GUA or ULA destination.

   A potential problem exists when a ULA source attempts to communicate
   with GUA or remote ULA destinations.  In these scenarios, the ULA
   source as stated earlier is by default intended for communication
   only with the local network, meaning an individual site, several
   sites that are part of the same organization, or multiple sites
   across cooperating organizations, as detailed in [RFC4193].  As a
   result, most GUA and ULA destinations are not attached to the same
   local network as the ULA source and are, therefore, not reachable
   from the ULA source.

   When only a ULA source is available for communication with GUA
   destinations, this generally implies no connectivity to the IPv6
   Internet is available.  Otherwise, a GUA source would have been made
   available and selected for use with GUA destinations.  As a result,
   the ULA source will typically fail when it attempts to communicate
   with most GUA destinations.  However, corner cases exist where the
   ULA source will not fail, such as when GUA destinations are attached
   to the same local network as the ULA source.

Buraglio, et al.        Expires 30 December 2024               [Page 10]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   Receiving a DNS response for a ULA destination that is not attached
   to the local network, in other words, a remote ULA destination, is
   considered a misconfiguration in most cases, or at least this
   contradicts the operational guidelines provided in Section 4.4 of
   [RFC4193].  Nevertheless, this can occur, and the ULA source will
   typically fail when it attempts to communicate with ULA destinations
   that are not attached to the same local network as the ULA source.
   This case provides a rationale for implementing support for known-
   local ULA prefix insertion in the policy table, such that
   differential behaviour can be applied for known-local versus general
   ULA prefixes.

   The remainder of this section discusses several complementary
   mechanisms involved with these scenarios.

8.1.  The ULA Label and its Precedence

   RFC 6724 added (in obsoleting RFC 3484) a separate label for ULA
   (fc00::/7), whose default precedence is raised by this update.  This
   separate label interacts with Rule 5 of Section 6 of RFC 6724, which
   says:

   Rule 5: Prefer matching label.

   If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB),
   then prefer DA.

   Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) =
   Label(DB), then prefer DB.

   The ULA source label will not match the GUA destination label in the
   first scenario.  Therefore, an IPv4 destination, if available, will
   be preferred over a GUA destination with a ULA source, even though
   the GUA destination has higher precedence than the IPv4 destination
   in the policy table.  This means the IPv4 destination will be moved
   up in the list of destinations over the GUA destination with the ULA
   source.

   If the ULA (fc00::/7) label is removed from the policy table, a GUA
   destination with a ULA source will be preferred over an IPv4
   destination, as GUA and ULA will be part of the same label (for
   ::/0).

   The ULA source label will match the ULA destination label in the
   second scenario; therefore, whether part of the local network or not,
   a ULA destination will be preferred over an IPv4 destination.

Buraglio, et al.        Expires 30 December 2024               [Page 11]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   Where known-local ULA prefix insertion is implemented, the known-
   local ULA will have a higher precedence (45) than either IPv6 GUAs
   (40) or IPv4 (20), while general ULAs will have the lowest precedence
   (10).

   If the ULA label (fc00::/7) has its precedence lowered below IPv4 or
   the IPv4 precedence is raised above ULA, an IPv4 destination will be
   preferred over all ULA destinations.

8.2.  Happy Eyeballs

   Regardless of the preference resulting from the above discussion,
   Happy Eyeballs version 1 [RFC6555] or version 2 [RFC8305], if
   implemented, will try both the GUA or ULA destination with the ULA
   source and the IPv4 destination and source pairings.  The ULA source
   will typically fail to communicate with most GUA or remote ULA
   destinations, and IPv4 will be preferred if IPv4 connectivity is
   available unless the GUA or ULA destinations are attached to the same
   local network as the ULA source.

8.3.  Try the Next Address

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

   Therefore, when an IPv4 destination is preferred over GUA or ULA
   destinations, IPv4 will likely succeed if IPv4 connectivity is
   available, and the GUA or ULA destination may only be tried if Happy
   Eyeballs is implemented.

   On the other hand, if the GUA or ULA destination with the ULA source
   is preferred, the ULA source will typically fail to communicate with
   GUA or ULA destinations that are not connected to the same local
   network as the ULA source.  However, if the operational guidelines in
   Section 4.3 of RFC 4193 are followed, recognizing this failure can be
   accelerated, and transport layer timeouts (e.g., TCP) can be avoided.
   The 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 above.

Buraglio, et al.        Expires 30 December 2024               [Page 12]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

9.  Following ULA operational guidelines in RFC 4193

   This section re-emphasises two important operational requirements
   stated in [RFC4193] that should be followed by operators.

9.1.  Filtering ULA-source addresses at site borders

   Section 4.3 states "Site border routers and firewalls should be
   configured to not forward any packets with Local IPv6 source or
   destination addresses outside of the site, unless they have been
   explicitly configured with routing information about specific /48 or
   longer Local IPv6 prefixes".

   And further that "Site border routers should respond with the
   appropriate ICMPv6 Destination Unreachable message to inform the
   source that the packet was not forwarded".

   As stated in the above discussion, such ICMPv6 messages can assist in
   fast failover for TCP connections.

9.2.  Avoid using ULA addresses in the global DNS

   Section 4.3 of RFC 4193 states that "AAAA and PTR records for locally
   assigned local IPv6 addresses are not recommended to be installed in
   the global DNS."

   This is particularly important given the general method presented in
   this document elevates the priority for ULAs above IPv4.  However,
   where support for insertion of known-local prefixes is implemented,
   such "rogue" ULAs in the global DNS are no longer a concern for
   address selection as they would have the lowest precedence.

10.  The practicalities of implementing address selection support

   As with most adjustments to standards, and using the introduction of
   RFC 6724 as a measuring stick, the updates defined in this document
   will likely take several years to become common enough for consistent
   behavior within most operating systems.  At the time of writing, it
   has been over 10 years since RFC 6724 has been published but we
   continue to see existing commercial and open source operating systems
   exhibiting RFC 3484 (or other) behavior.

   While it should be noted that RFC 6724 defines a solution to adjust
   the address preference selection table that is functional
   theoretically, operationally the solution is operating system
   dependent and in practice policy table changes cannot be signaled by
   any currently deployed network mechanism.  While RFC 7078 defines
   such a DHCPv6 option, it is not widely implemented.  This lack of an

Buraglio, et al.        Expires 30 December 2024               [Page 13]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   intra-protocol or network-based ability to adjust address selection
   preference, along with the inability to adjust a notable number of
   operating systems either programmatically or manually, renders
   operational scalability of such a mechanism challenging.

   It is especially important to note this behavior in the long
   lifecycle equipment that exists in industrial control and operational
   technology environments due to their very long mean time to
   replacement/lifecycle.

11.  Limitations of RFC 6724

   The procedures defined in RFC 6724 do not give optimal results for
   all scenarios.  As stated in the introduction, the aim of this update
   is to improve the behavior for the most common scenarios.

   It is widely recognised in the IETF 6man WG that the whole 3484/6724/
   getaddrinfo() model is fundamentally inadequate for optimal address
   selection.  A model that considers address pairs directly, rather
   than sorting on destination addresses with the best source for that
   address, would be preferable, but beyond the scope of this document.

   To simplify address selection, operators may instead look to deploy
   IPv6-only, and may choose to only use GUA addresses and no ULA
   addresses.  Other approaches to reduce the use of IPv4, e.g., through
   use of DHCPv4 Option 108 as defined in [RFC8925], also helps simplify
   address selection for nodes.

12.  Acknowledgements

   The authors would like to acknowledge the valuable input and
   contributions of the 6man WG including (in alphabetic order) Erik
   Auerswald, Dale Carder, Brian Carpenter, Tom Coffeen, Lorenzo
   Colitti, Chris Cummings, David Farmer (in particular for the ULA to
   GUA/ULA discussion text), Bob Hinden, Scott Hogg, Ed Horley, Ted
   Lemon, Jen Linkova, Michael Richardson, Kyle Rose, Ole Troan, Eduard
   Vasilenko, Eric Vyncke, Paul Wefel, Timothy Winters, and XiPeng Xiao.

13.  Security Considerations

   There are no direct security considerations in this document.

   The mixed preference for IPv6 over IPv4 from the default policy table
   in RFC 6724 represents a potential security issue, given an operator
   may expect ULAs to be used when in practice RFC 1918 addresses are
   used instead.

Buraglio, et al.        Expires 30 December 2024               [Page 14]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   The requirements of RFC 4193, stated earlier in this document, should
   be followed for optimal behavior.

   Operators should be mindful of cases where communicating nodes have
   differing behaviours for address selection, e.g., RFC3484 behavior,
   RFC6724, the updated RFC6724 behavior defined here, some other non-
   IETF-standardized behavior, or even no mechanism.  There may thus be
   inconsistent behaviour for communications initiated in each
   direction.  Ultimately all nodes should be made compliant to the
   updated specification described in this document.

14.  IANA Considerations

   None.

15.  Summary of changes and additional text since RFC 6724

   *  Changed default policy table to move fc00::/7 to precedence 30,
      above legacy IPv4.

   *  Changed default policy table to move the 6to4 address block
      2002::/16 to the same precedence as the Teredo prefix.

   *  Changed ::ffff:0:0/96 to precedence 20.

   *  Changed Rule 5.5 to a MUST support.

   *  Defined the concept of known-local ULA prefixes and the
      requirement to (MUST) insert them into the policy table.

   *  Added text clarifying intended behaviors.

   *  Added text discussing ULA to GUA/ULA case.

   *  Added text for the security section.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

Buraglio, et al.        Expires 30 December 2024               [Page 15]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC7526]  Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
              Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
              DOI 10.17487/RFC7526, May 2015,
              <https://www.rfc-editor.org/info/rfc7526>.

   [RFC8925]  Colitti, L., Linkova, J., Richardson, M., and T.
              Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
              RFC 8925, DOI 10.17487/RFC8925, October 2020,
              <https://www.rfc-editor.org/info/rfc8925>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

16.2.  Informative References

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/info/rfc6724>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484,
              DOI 10.17487/RFC3484, February 2003,
              <https://www.rfc-editor.org/info/rfc3484>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <https://www.rfc-editor.org/info/rfc6555>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/info/rfc8305>.

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
              August 2003, <https://www.rfc-editor.org/info/rfc3587>.

Buraglio, et al.        Expires 30 December 2024               [Page 16]
Internet-Draft  Prioritizing known-local ULAs in RFC 672       June 2024

Authors' Addresses

   Nick Buraglio
   Energy Sciences Network
   Email: buraglio@forwardingplane.net

   Tim Chown
   Jisc
   Email: Tim.Chown@jisc.ac.uk

   Jeremy Duncan
   Tachyon Dynamics
   Email: jduncan@tachyondynamics.com

Buraglio, et al.        Expires 30 December 2024               [Page 17]