idnits 2.17.1 draft-buraglio-v6ops-ula-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC6724]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 May 2022) is 714 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC6598' is defined on line 324, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Buraglio 3 Internet-Draft C. Cummings 4 Intended status: Informational Energy Sciences Network 5 Expires: 11 November 2022 R. White 6 Juniper Networks 7 10 May 2022 9 Unintended Operational Issues With ULA 10 draft-buraglio-v6ops-ula-02 12 Abstract 14 The behavior of ULA addressing as defined by [RFC6724] is preferred 15 below legacy IPv4 addressing, thus rendering ULA IPv6 deployment 16 functionally unusable in IPv4 / IPv6 dual-stacked environments. This 17 behavior is counter to the operational behavior of GUA IPv6 18 addressing on nearly all modern operating systems that leverage a 19 preference model based on [RFC6724] . 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 11 November 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Defining Well Known Unintended Operational Issues With ULA . 2 56 3. Operational Implications . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 7.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 In modern IPv4 / IPv6 dual-stacked environments, ULA addressing and 68 GUA IPv6 addressing exhibit opposite behavior, which creates 69 difficulties in deployments leveraging ULA addressing. This 70 conflicting behavior carries planning, operational, and security 71 implications for environments requiring ULA addressing with IPv4/IPv6 72 dual-stack and prioritization of IPv6 traffic by default, as is the 73 behavior with IPv6 GUA addressing. 75 2. Defining Well Known Unintended Operational Issues With ULA 77 The [RFC6724] definition is incorrect for ULA precedence if a host is 78 operating in a dual-stack environment. Expected behavior would be 79 that ULA address space would be preferred over legacy IPv4, however 80 this is not the case. This presents an acute issue with any 81 environment that will use ULA addressing along side legacy IPv4 that 82 is counter to the standard expectations for legacy IPv4 / IPv6 dual- 83 stack behavior of preferring IPv6, as is performed with GUA 84 addressing. 86 3. Operational Implications 88 There are demonstrated uses cases of ULA not being preferred in some 89 OS and network equipment over legacy IPv4 that necessitate the 90 immediate update to [RFC6724] to better reflect the original intent 91 of the RFC. As with most adjustments to standards, and using 92 [RFC6724] itself as a measurment, this update will likely take 93 between 8-20 years to become common enough for relatively consistent 94 behavior within operating systems. As a reference, it has been 10 95 years since [RFC6724] has been published but we continue to see 96 existing commercial and open source operating systems exhibiting 97 [RFC3484] behavior. It is anticipated it will take just as long for 98 an update of [RFC6724] to be adopted. In addition, in the current 99 versions of Linux, the priority table (gai.conf) still makes 100 reference to [RFC3484] , further demonstrating the long timeframe to 101 have updates reflected in a current OS. Examples of such out-of-date 102 behavior can be found in printers, cameras, fixed devices, IoT 103 sensors, and longer lifecycle equipment. It is especially important 104 to note this behavior in the long lifecycle equipment that exists in 105 industrial control and operational techology environments due to 106 their very long mean time to replacement. The core issue is the 107 stated interpretation from gai.conf that has the following default: 109 #scopev4 110 # Add another rule to the RFC 6724 scope table for IPv4 addresses. 111 # By default the scope IDs described in section 3.2 in RFC 6724 are 112 # used. Changing these defaults should hardly ever be necessary. 113 # The defaults are equivalent to: 114 # 115 #scopev4 ::ffff:169.254.0.0/112 2 116 #scopev4 ::ffff:127.0.0.0/104 2 117 #scopev4 ::ffff:0.0.0.0/96 14 119 Figure 1 121 Notice that they are interpreting the legacy IPv4 address range as 122 "scopev4" and the prefix ::ffff:0.0.0.0/96 which has a higher 123 precedence (35) in [RFC6724] then the ULA prefix of fc00::/7 (3). 124 This results in legacy IPv4 being preferred over IPv6 ULA. 126 The operational outcome is the move to dual-stack with ULA is 127 inconsistent and imparts unnecessary difficulty for both 128 troubleshooting and creating the baseline expected behavior which are 129 both requirements for deployments. This results in operational and 130 engineering teams not gaining IPv6 experience as limited traffic is 131 actually using IPv6, and security baseline expectations are 132 inconsistent at best and haphazard at worst. 134 In practice, [RFC6724] imposes several operational shortcomings 135 preventing both consistent and desired behavior. If we define 136 "desired behavior" as IPv6 preference over legacy IPv4 for address 137 and protocol selection, then the resulting implemented behavior, 138 based on [RFC6724] , will fall short of that intent. Based on the 139 current verbiage, dual-stacked hosts configured with both a legacy 140 IPv4 address and an IPv6 ULA address, the resulting behavior will 141 manifest as a host choosing IPv4 over ULA IPv6. This behavior 142 deviates from the current goal of a host with legacy IPv4 address and 143 also with an IPv6 GUA address preferring IPv6 over IPv4. 144 Operationally and strategically, this manifests as an impediment to 145 deployment of IPv6 for many non-service provider and mobile networks 146 phasing in dual-stacked (both legacy IPv4 and IPv6) networking with 147 the expectation of consistent behavior (alway use IPv6 before legacy 148 IPv4). 150 Other operational considerations are the use of the policy table 151 detailed in section 2.1 of [RFC6724] . While conceptually the intent 152 was for a configurable, longest-match table to be adjusted as-needed. 153 In practice, modifying the prefix policy table remains difficult 154 across platforms, and in some cases impossible. Embedded, 155 proprietary, closed source, and IoT devices are especially difficult 156 to adjust and are, in many cases, incapable of any adjustment 157 whatsoever. Large scale manipulation of the policy table also 158 remains out of the realm of realistic support for small and medium 159 scale operators due to lack of ability to manipulate all the hosts 160 and systems, or a lack of tooling and access. 162 Below is an example of a gai.conf file from a modern Linux 163 installation as of 03 April 2022: 165 # Configuration for getaddrinfo(3). 166 # 167 # So far only configuration for the destination address sorting is needed. 168 # RFC 3484 governs the sorting. But the RFC also says that system 169 # administrators should be able to overwrite the defaults. This can be 170 # achieved here. 171 # 172 # All lines have an initial identifier specifying the option followed by 173 # up to two values. Information specified in this file replaces the 174 # default information. Complete absence of data of one kind causes the 175 # appropriate default information to be used. The supported commands include: 176 # 177 # reload 178 # If set to yes, each getaddrinfo(3) call will check whether this file 179 # changed and if necessary reload. This option should not really be 180 # used. There are possible runtime problems. The default is no. 182 # 183 # label 184 # Add another rule to the RFC 3484 label table. See section 2.1 in 185 # RFC 3484. The default is: 186 # 187 #label ::1/128 0 188 #label ::/0 1 189 #label 2002::/16 2 190 #label ::/96 3 191 #label ::ffff:0:0/96 4 192 #label fec0::/10 5 193 #label fc00::/7 6 194 #label 2001:0::/32 7 195 # 196 # This default differs from the tables given in RFC 3484 by handling 197 # (now obsolete) site-local IPv6 addresses and Unique Local Addresses. 198 # The reason for this difference is that these addresses are never 199 # NATed while IPv4 site-local addresses most probably are. Given 200 # the precedence of IPv6 over IPv4 (see below) on machines having only 201 # site-local IPv4 and IPv6 addresses a lookup for a global address would 202 # see the IPv6 be preferred. The result is a long delay because the 203 # site-local IPv6 addresses cannot be used while the IPv4 address is 204 # (at least for the foreseeable future) NATed. We also treat Teredo 205 # tunnels special. 206 # 207 # precedence 208 # Add another rule to the RFC 3484 precedence table. See section 2.1 209 # and 10.3 in RFC 3484. The default is: 210 # 211 #precedence ::1/128 50 212 #precedence ::/0 40 213 #precedence 2002::/16 30 214 #precedence ::/96 20 215 #precedence ::ffff:0:0/96 10 216 # 217 # For sites which prefer IPv4 connections change the last line to 218 # 219 #precedence ::ffff:0:0/96 100 221 # 222 # scopev4 223 # Add another rule to the RFC 6724 scope table for IPv4 addresses. 224 # By default the scope IDs described in section 3.2 in RFC 6724 are 225 # used. Changing these defaults should hardly ever be necessary. 226 # The defaults are equivalent to: 227 # 228 #scopev4 ::ffff:169.254.0.0/112 2 229 #scopev4 ::ffff:127.0.0.0/104 2 230 #scopev4 ::ffff:0.0.0.0/96 14 232 Figure 2 234 Several assumptions are made here and are largely based on 235 interpretations of [RFC6724] but are not operationally relevant in 236 modern networks. As this file or an equivalent structure within a 237 given operating system is referenced, it dictates the behavior of the 238 getaddrinfo() or analogous process. More specifically, where 239 getaddrinfo() or comparable API is used, the sorting behavior should 240 take into account both the source address of the requesting host as 241 well as the destination addresses returned and sort according to both 242 source and destination addressing, i.e, when a ULA address is 243 returned, the source address selection should return and use a ULA 244 address if available. Similarly, if a GUA address is returned the 245 source address selection should return a GUA source address if 246 available. 248 Here are some example failure modes: 250 1. ULA per [RFC6724] is less preferred (the Precedence value is 251 lower) than all legacy IPv4 (represented by ::ffff:0:0/96 in the 252 aforementioned table). 254 2. Because of the lower Precedence value of fc00::/7, if a host has 255 legacy IPv4 enabled, it will use legacy IPv4 before using ULA. 257 3. A dual-stacked client will source the traffic from the legacy 258 IPv4 address, meaning it will require a corresponding legacy IPv4 259 destination address. 261 Per number 3, even a host choosing a destination with A and AAAA DNS 262 records, the host in question will choose the A record to get an 263 legacy IPv4 address for the destination, meaning ULA IPv6 is rendered 264 completely unused. It is also notable that Happy Eyeballs ([RFC8305] 265 ) will not change the source address selection process on a host. 266 Happy Eyeballs will only modify the destination sorting process. 268 As a direct result of the described failure modes, and in addition to 269 the aforementioned operational implications, use of ULA is not a 270 viable option for dual-stack \ networking transition planning, large 271 scale network modeling, network lab environments or other modes of 272 emulating a large scale networking that runs both IPv4 and IPv6 273 concurrently. 275 4. IANA Considerations 277 None at this time. 279 5. Security Considerations 281 Such unexpected behavior can result in odd operational outcomes which 282 can result in serious security and compliance issues and could, in 283 some cases, result in disabling of IPv6 to acheive compliance and 284 consistency. . 286 6. Acknowledgements 288 The authors acknowledge the work of Brian Carpenter, Bob Hinden, Mark 289 Andrews, Vasilenko Eduardand, and Mark Smith for participation in the 290 technical discussions leading to this finding and Michael Ackermann, 291 Tom Coffeen, Kevin Myers, and Ed Horley for providing further testing 292 and operational input. 294 7. References 296 7.1. Normative References 298 [RFC3484] Draves, R., "Default Address Selection for Internet 299 Protocol version 6 (IPv6)", RFC 3484, 300 DOI 10.17487/RFC3484, February 2003, 301 . 303 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 304 "Default Address Selection for Internet Protocol Version 6 305 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 306 . 308 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 309 Better Connectivity Using Concurrency", RFC 8305, 310 DOI 10.17487/RFC8305, December 2017, 311 . 313 7.2. Informative References 315 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 316 J., and E. Lear, "Address Allocation for Private 317 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 318 February 1996, . 320 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 321 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 322 . 324 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 325 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 326 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 327 2012, . 329 Authors' Addresses 331 Nick Buraglio 332 Energy Sciences Network 333 Email: buraglio@es.net 335 Chris Cummings 336 Energy Sciences Network 337 Email: chriscummings@es.net 339 Russ White 340 Juniper Networks 341 Email: russ@riw.us