Preference for IPv6 ULAs over IPv4 addresses in RFC6724
draft-ietf-6man-rfc6724-update-04

6MAN                                                         N. Buraglio
Internet-Draft                                   Energy Sciences Network
Updates: 6724 (if approved)                                     T. Chown
Intended status: Standards Track                                    Jisc
Expires: 24 May 2024                                           J. Duncan
                                                        Tachyon Dynamics
                                                        21 November 2023

        Preference for IPv6 ULAs over IPv4 addresses in RFC6724
                   draft-ietf-6man-rfc6724-update-04

Abstract

   This document updates [RFC6724] based on operational experience
   gained since its publication over ten years ago.  In particular it
   updates the precedence of Unique Local Addresses (ULAs) in the
   default address selection policy table, which as originally defined
   by [RFC6724] has lower precedence than legacy IPv4 addressing.  The
   update places both IPv6 Global Unicast Addresses (GUAs) and ULAs
   ahead of all IPv4 addresses on the policy table to better suit
   operational deployment and management of ULAs in production.  In
   updating the [RFC6724] default policy table, this document also
   demotes the preference for 6to4 addresses.  These changes to default
   behavior improve supportability of common use cases such as, but not
   limited to, 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."

   This Internet-Draft will expire on 24 May 2024.

Buraglio, et al.           Expires 24 May 2024                  [Page 1]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

Copyright Notice

   Copyright (c) 2023 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.  Unintended Operational Issues Regarding IPv6 Preference and
           ULAs  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Operational Implications  . . . . . . . . . . . . . . . .   4
   4.  Preference of 6to4 addresses  . . . . . . . . . . . . . . . .   5
   5.  Adjustments to RFC 6724 . . . . . . . . . . . . . . . . . . .   5
     5.1.  Policy Table Update . . . . . . . . . . . . . . . . . . .   6
     5.2.  Additional considerations for policy table adjustment . .   6
     5.3.  Rule 5.5 Adjustments  . . . . . . . . . . . . . . . . . .   7
   6.  The practicalities of implementing address selection
           support . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Related Issues and Guidance . . . . . . . . . . . . . . . . .   7
     7.1.  Relation to RFC 5220  . . . . . . . . . . . . . . . . . .   8
     7.2.  Relation to Happy Eyeballs  . . . . . . . . . . . . . . .   8
     7.3.  Relation to RFC 4193  . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. Appendix A.  Changes since RFC6724  . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

Buraglio, et al.           Expires 24 May 2024                  [Page 2]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

1.  Introduction

   When [RFC6724] was published in 2012 it was expected that the default
   policy table may need to be updated from 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, including Section 10.6 which
   considers a ULA example.

   This document is written on the basis of such operational experience,
   in particular for scenarios where ULAs are used within a site.

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

   However, the default policy table also puts IPv6 ULAs below all IPv4
   addresses, including [RFC1918] addresses.  For many site operators
   this behavior will be counter-intuitive, and may create difficulties
   with respect to planning, operational, and security implications for
   environments where ULA addressing is used in certain IPv4/IPv6 dual-
   stack network scenarios.  The expected prioritization of IPv6 traffic
   over IPv4 by default, as happens with IPv6 GUA addressing, will not
   happen for ULAs.

   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.

   This document makes no comment or recommendation on how ULAs are
   used, or on the use of NAT in an IPv6 network.  As the default policy
   table stands, operationally where GUAs and ULAs are used alongside
   RFC 1918 addressing, an IPv6 GUA would be selected to reach an IPv6
   GUA destination.  However where there are only ULAs and RFC1918
   addressing in use, RFC 1918 addresses will be preferred.

   This document updates 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.

   This change aims to improve the default handling of address selection
   for common cases, and unmanaged / automatic scenarios rather than
   those where DHCPv6 is deployed.  Sites using DHCPv6 for host
   configuration management can make use of implementations of [RFC7078]
   to apply changes to the [RFC6724] policy table.

Buraglio, et al.           Expires 24 May 2024                  [Page 3]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

   The changes should also assist operators in phasing out IPv4 from
   dual-stack environments, since IPv6 GUAs and ULAs will be preferred
   over any IPv4 addresses.  This is an extremely important enabler
   towards IPv6-only networking.

   The changes are discussed in more detail in the following sections,
   with a further section providing a summary of the proposed updates.

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.

3.  Unintended Operational Issues Regarding IPv6 Preference and ULAs

   The preference for use of IPv6 addressing over IPv4 addressing in
   [RFC6724] is inconsistent.  As written, [RFC6724] section 10.3
   states:

   "The default policy table gives IPv6 addresses higher precedence than
   IPv4 addresses.  This means that applications will use IPv6 in
   preference to IPv4 when the two are equally suitable.  An
   administrator can change the policy table to prefer IPv4 addresses by
   giving the ::ffff:0.0.0.0/96 prefix a higher precedence".

   The expected behavior would be that ULA address space would be
   preferred over legacy IPv4, however this is not the case.  This
   presents an issue with any environment that will use ULA addressing
   alongside legacy IPv4, whether global or RFC 1918.  This is counter
   to the standard expectations for legacy IPv4 / IPv6 dual-stack
   behavior in preferring IPv6, which is the case for GUA addressing.

3.1.  Operational Implications

   There are demonstrated and easily repeatable operational examples of
   the impact of the current [RFC6724] behaviour, i.e., ULAs not being
   preferred in OS and network equipment over legacy IPv4 addresses.
   These reinforce the need to update [RFC6724] to both better reflect
   the original intent of the RFC and to facilitate the depreciation and
   eventual removal of IPv4 in network environments.

   When the default policy table in a given operating system is
   referenced it dictates the behavior of getaddrinfo() or analogous
   process.  More specifically, where getaddrinfo() or a comparable API
   is used, the sorting behavior should take into account both the

Buraglio, et al.           Expires 24 May 2024                  [Page 4]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

   source address of the requesting host as well as the destination
   addresses returned and sort according to both source and destination
   addresses, i.e, when a ULA address is returned, the source address
   selection should return and use a ULA address if available.
   Similarly, if a GUA address is returned the source address selection
   should return a GUA source address if available.

   However, there are clearly evidenced example of three failure
   scenarios:

   1.  ULA per is less preferred (the precedence value is lower) than
       all legacy IPv4 (represented by ::ffff:0:0/96 in the
       aforementioned table).

   2.  Because of the lower precedence value of fc00::/7, if a host has
       legacy IPv4 enabled, it will use legacy IPv4 before using ULA.

   3.  A dual-stacked client will source the traffic from the legacy
       IPv4 address, meaning it will require a corresponding legacy IPv4
       destination address.

   For scenario number 3, when a host resolves through DNS a destination
   with A and AAAA DNS records, the host will choose the A record to get
   an legacy IPv4 address for the destination, meaning ULA IPv6 is
   rendered unused.

   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.

4.  Preference of 6to4 addresses

   The anycast prefix for 6to4 relays was deprecated by [RFC7526] in
   2015, and since that time the use of 6to4 addressing has further
   declined to the point where it is generally not seen and can be
   considered to all intents and purposes deprecated in use.

   This document therefore demotes the precedence of the 6to4 prefix in
   the policy table to the same minimum preference as carried by the
   deprecated site local and 6bone address prefixes.

5.  Adjustments to RFC 6724

   This update will make two specific changes: first, to update the
   default policy table, and second, change the next hop advertised
   prefix by the next hop to a MUST.

Buraglio, et al.           Expires 24 May 2024                  [Page 5]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

5.1.  Policy Table Update

   This update alters the default policy table listed in Rule 2.1 of
   [RFC6724].

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

                    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

   This preference table update moves 2002::/16 to de-preference its
   status in line with RFC 7526 and changes the default address
   selection to move fc00::/7 above legacy IPv4, with ::ffff:0:0/96 now
   set to precedence 20.

5.2.  Additional considerations for policy table adjustment

   As designed, ULAs are defined to have a /48 site prefix.  An
   implementation SHOULD automatically add rows for all covering ULA
   site prefixes received in Router Advertisements (RAs) [RFC4861]
   within Prefix Information Options (PIOs) or Route Information Options
   (RIOs) [RFC4191].  These known-local ULA /48s SHOULD have a
   precedence of 45.  All Nodes SHOULD provide a mechanism to configure
   the policy table.  Any Node that does not provide a mechanism for
   policy table configuration MUST implement the automated increased
   precedence for known-local /48s of ULA.  Nodes implementing the
   automated increased precedence for known-local /48s of ULA MAY set
   the default precedence for the ULA label (fc00::/7) to 10.
   Otherwise, the default precedence for the ULA label (fc00::/7) MUST
   be 30.

Buraglio, et al.           Expires 24 May 2024                  [Page 6]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

5.3.  Rule 5.5 Adjustments

   The heuristic for address selection defined in Section 5.5 of
   [RFC6724] to prefer addresses in a prefix advertised by a next-hop
   router has proven to be very useful.  [RFC6724] does not state any
   requirement for SHOULD or MUST for this heuristic to be used; this
   update therefore amends section 5.5 to reflect that a system MUST
   apply the next-hop tracking heuristic.

6.  The practicalities of implementing address selection support

   As with most adjustments to standards, and using [RFC6724] itself as
   a measuring stick, the updates defined in this document will likely
   take between 8-20 years to become common enough for consistent
   behavior within most operating systems.  At the time of writing, it
   has been over 10 years since [RFC6724] has been published but we
   continue to see existing commercial and open source operating systems
   exhibiting [RFC3484] behavior.

   While it should be noted that [RFC6724] 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 [RFC7078] defines
   such a DHCPv6 option, it is not by any means widely implemented.
   This lack of an 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.

   In practice this means that network operators and those who design
   networks need to keep these considerations in mind.  Should the
   current ULA and IPv4 preference issue be of concern then
   'workarounds' do exist.  One is to use IPv6-only networking, i.e.,
   not deploy dual-stack, and another is to only use GUA IPv6 addresses
   which are preferred by default over all IPv4 addresses.

7.  Related Issues and Guidance

Buraglio, et al.           Expires 24 May 2024                  [Page 7]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

7.1.  Relation to RFC 5220

   Section 2.2.2 of [RFC5220] outline a potential failure scenario
   involving the presence of ULA addressing and both an A and AAAA DNS
   record for a destination resource.

   Rule 5 of Section 6 of [RFC6724] states:

 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 concerns expressed in section 2.2.2 of [RFC5220] are addressed
   with the inclusion of a separate label for ULA present in the policy
   table.

   This specifies that the presence of the label and the rule defining
   the behavior based on said rule should prevent the situation
   described in that section from occurring.

7.2.  Relation to Happy Eyeballs

   In cases where a ULA Source Address is selected to communicate with a
   GUA destination, Happy Eyeballs version 1 ([RFC6555]) or version 2
   ([RFC8305]) would result in IPv4 being used in practice since the ULA
   source address will likely fail (due to egress filtering at the
   border, as discussed in the Security Considerations below).  Corner
   cases may exist where the ULA address will not fail, however, in
   normal operation these cases are more likely misconfigurations than
   intentional.

7.3.  Relation to RFC 4193

   If the operational guidelines in sections 4.1 and 4.3 of [RFC4193]
   are followed, a Destination Unreachable ICMPv6 Error should be
   received by the source device.

   In such cases, the guidance in Section 2 of [RFC6724] implies trying
   the next destination address in the ordered list, where it states
   that "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".

Buraglio, et al.           Expires 24 May 2024                  [Page 8]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

8.  Acknowledgements

   The authors would like to acknowledge the valuable input and
   contributions of the 6man WG including Brian Carpenter, XiPeng Xiao,
   Eduard Vasilenko, David Farmer, Bob Hinden, Ed Horley, Tom Coffeen,
   Scott Hogg, Chris Cummings, Paul Wefel, Dale Carder, Erik Auerswald,
   Ole Troan, Eric Vyncke, Timothy Winters, Kyle Rose, Lorenzo Colitti,
   Jen Linkova, and Mark Smith.

9.  Security Considerations

   There are no direct security considerations in this document.

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

   When using the updated ULA source address selection defined in this
   document, network operators MUST follow Section 4.3 of [RFC4193] for
   firewall/packet filtering as "routers be configured by default to
   keep any packets with Local IPv6 addresses from leaking outside of
   the site and to keep any site prefixes from being advertised outside
   of their site."  Following this security practice is critical when
   ULAs have more broad reachability.

   Operators should be mindful of cases where one node is compliant with
   [RFC6724] as originally published and another node is compliant with
   the update presented in this document, as there may be inconsistent
   behaviour for communications initiated in each direction.  Similarly,
   differences between current RFC 6724-compliant and RFC 3484-compliant
   nodes may also be observed.  Ultimately all nodes should be made
   compliant to the updated specification described in this document.

10.  IANA Considerations

   None.

11.  Appendix A.  Changes since RFC6724

   *  Update to default preference table moving 6to4 address block
      2002::/16 to de-preference status in line with [RFC7526],

   *  Change the default address selection to move fc00::/7 to
      preference 30, above legacy IPv4,

   *  Change ::ffff:0:0/96 to preference 20,

Buraglio, et al.           Expires 24 May 2024                  [Page 9]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

   *  Add section relating to Happy Eyeballs,

   *  Change section 5.5 to require interface prefix tracking.

12.  References

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

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

   [RFC7078]  Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
              Address Selection Policy Using DHCPv6", RFC 7078,
              DOI 10.17487/RFC7078, January 2014,
              <https://www.rfc-editor.org/info/rfc7078>.

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

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

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

Buraglio, et al.           Expires 24 May 2024                 [Page 10]
Internet-Draft       Prefer ULAs over IPv4 addresses       November 2023

   [RFC5220]  Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
              "Problem Statement for Default Address Selection in Multi-
              Prefix Environments: Operational Issues of RFC 3484
              Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008,
              <https://www.rfc-editor.org/info/rfc5220>.

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

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

Authors' Addresses

   Nick Buraglio
   Energy Sciences Network
   Email: [email protected]

   Tim Chown
   Jisc
   Email: [email protected]

   Jeremy Duncan
   Tachyon Dynamics
   Email: [email protected]

Buraglio, et al.           Expires 24 May 2024                 [Page 11]