idnits 2.17.1 draft-mishra-v6ops-variable-slaac-problem-stmt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IANA-RF' is mentioned on line 433, but not defined == Outdated reference: A later version (-10) exists of draft-bourbaki-6man-classless-ipv6-05 == Outdated reference: A later version (-08) exists of draft-mishra-6man-variable-slaac-03 == Outdated reference: A later version (-10) exists of draft-shytyi-opsawg-vysm-09 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Intended status: Informational A. Petrescu 5 Expires: January 13, 2022 CEA, LIST 6 N. Kottapalli 7 Benu Networks 8 D. Mudric 9 Ciena 10 D. Shytyi 11 SFR 12 July 12, 2021 14 SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A 15 Problem Statement 16 draft-mishra-v6ops-variable-slaac-problem-stmt-02 18 Abstract 20 In the past, various IPv6 addressing models have been proposed based 21 on a subnet hierarchy embedding a 64-bit prefix. The last remnant of 22 IPv6 classful addressing is a inflexible interface identifier 23 boundary at /64. This document details the 64-bit boundary problem 24 statement. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 13, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Variable SLAAC Use Cases . . . . . . . . . . . . . . . . . . 5 64 4.1. Permission-less Extension of the Network . . . . . . . . 5 65 4.2. Private Networks . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.4. Home and SOHO . . . . . . . . . . . . . . . . . . . . . . 7 68 4.5. 3GPP V2I and V2V networking . . . . . . . . . . . . . . . 7 69 4.6. Smart Traffic Lights . . . . . . . . . . . . . . . . . . 8 70 4.7. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.8. Large ISP's backbone POP . . . . . . . . . . . . . . . . 9 72 4.9. Permission-less extension of the Network . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. Introduction 93 From the beginning, the IPv6 addressing plan was based on a 128 bit 94 address format made up of 8 hextets which were broken down into a 64 95 bit four hextet prefix and 64 bit four hextet interface identifier. 97 For example, the address 2001:db8:3:4::1 has the first 4 hextets 98 forming the /64 prefix 2001:db8:3:4::/64, whereas the last four 99 hextets form an interface identifier abbreviated as ::1 (a 'hextet' 100 is a group of max 4 hex digits between two columns, e.g. "2001" and 101 "db8" are each a hextet). A comprehensive analysis of the 64-bit 102 boundary is provided in [RFC7421]. The history of IPv6 Classful 103 models proposed, and the last remnant of IPv6 Classful addressing 104 rigid network interface identifier boundary at /64 is discussed in 105 detail as well as the removal of the fixed position of the boundary 106 for interface addressing in draft [I-D.bourbaki-6man-classless-ipv6]. 108 This document discusses the reasons why the interface identifier has 109 been fixed at 64 bits, and the problems that can be addressed by 110 changing the GUA interface identifier from fixed 64 bit size to a 111 variable interface identifier. This change would be consistent with 112 static and DHCPv6 stateful IPv6 address assignment. This document 113 tries to achieve clearing the confusion related to prefix length, and 114 provide consistency of variable length prefix across the three IPv6 115 addressing strategies deployed, static, DHCPv6 and Stateless Address 116 Autoconfiguration(SLAAC), and finally update all RFCs with the new 117 variable SLAAC standard. The solution to this problem statement is 118 defined in draft [I-D.mishra-6man-variable-slaac] 120 Over the years one of the merits of increasing the prefix length, and 121 reducing the size of the interface identifier has been incorrectly 122 stated as the possibility of IPv6 address space exhaustion could be 123 circumvented, or that a 64 bit interface identifier is an efficient 124 use of address space. 126 3. Problem Statement 128 This section details the problem statement as to what is broken today 129 with fixed length Stateless Address Autoconfiguration SLAAC [RFC4862] 130 and why it is critical to resolve this problem. 132 The main problem is that SLAAC RA or PD allocates a /64 by the 133 wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however 134 segmentation of the /64 via SLAAC is required so that downstream 135 interfaces can be further sub-netted. The use case section of this 136 draft discusses this scenario as one of the use cases for shorter 137 interface identifier, and this use case is the only one stated here 138 in the problem statement as this is broken today with the current 139 SLAAC specification [RFC4862], and there is not any workaround for 140 this use case. 142 There are two reasons why this was not a problem in the past, but now 143 with increased bandwidth there are more and more devices being piled 144 onto a single handset or mobile hotspot. In the past generations of 145 cellular systems (e.g. 2.5G aka GPRS and some 3G) the bandwidth 146 available to the User Equipment was not enough to accommodate several 147 applications; bandwidth available was roughly 256Kbit/s. For that 148 reason, users were rarely tempted to use an UE to link other devices 149 than that UE to the Internet. However, with the arrival of 3G, 3G+ 150 (e.g. HSDPA / HSUPA), and even more so with 4G and 4G+, the 151 bandwidth made available to UE increased significantly; this became 152 an average effective of 1Mbit/s and even more. With this available 153 bandwidth, the users are more and more tempted to connect several 154 devices to the Internet. This operation is named 'connection 155 sharing' or 'tethering'. Another answer to this question is that 156 IPv6 technology that is widely used to 'tether' several IP devices to 157 a smartphone is '64share' RFC7278. This technology is used for 158 smartphones but is not so in vehicles. One of the reasons of not 159 being used in vehicles is the lack of scalability: a /64 prefix is 160 shared between the UE ptp link and the subnet (typically Wi-Fi), but 161 can not be further sub-netted to other subnets in the car. 163 The reason why all devices in a car cannot remain on a single /64 are 164 as follows. These devices have different link-layer technologies, 165 and not all WiFi could be bridged into Ethernet such as to keep all 166 devices into one /64. They could be on links that are not 167 bridgeable: devices on 802.11-OCB cannott be bridged, devices on 168 Bluetooth cannott be bridged, devices on 3GPP cannott be bridged, and 169 so one. Other than the impossibility to bridge several such link- 170 layer technologies there is also a problem of noise: in a vehicle one 171 wants the braking pedal signal to not be disturbed by entertainment 172 sites such as YouTube. That physical technical requirement 173 separation of different link layer technologies segmentation on to 174 different smaller IPv6 subnets cannot be achieved if all devices are 175 on a single /64, or bridged. Therefore, the only possible solution 176 to connect these disparate devices onto a 3GPP network for internet 177 access is to keep these separate link layer technologies segmented 178 onto separate greater then /64 prefix subnets and breaking the /64 179 boundary that exists today with a Variable SLAAC solution. Thus, 180 when the 3GPP network gives a /64 to the car, and when there are 181 unbridgeable technologies in the car (e.g. WiFi cant be bridged to 182 Bluetooth), then the only possibility is to divide that /64 into two 183 /65s. One /65 would be used on the WiFi and another /65 would be 184 used on Bluetooth. But in order for SLAAC to work with /65 then 185 there is a need to have the shorter interface identifier of length 186 63. Hence the need of lengths of PIOs other than 64 (variable plen). 188 There are three scenarios that require SLAAC to be able to be routed 189 between two greater then /64 prefix segments as part of the 190 requirement for variable length SLAAC and what is broken with the 191 current SLAAC specification defined in [RFC4862]. 193 The first scenario is within a car using car manufacturer single SIM 194 for internet access and being able to bridge(Route) other link layer 195 devices like BT via variable slaac. In this scenario the 196 communication between downstream devices are all located within the 197 car using the car manufacturer built in SIM card for in-vehicle 198 communication. The in-vehicle scenario covers both the built-in car 199 manufacturer SIM card scenario, or if the car manufacturer does not 200 support built-in SIM card then a single mobile handset providing 3GPP 201 internet access to all devices in the car. 203 The second scenario is V2V (vehicle to vehicle) between cars 204 requiring SLAAC to subnet the >64 prefix so that the two cars have 205 WiFi connectivity. 207 This third scenario is a uCPE(Universal Customer Premises Equipment) 208 device is LTE 4G and Wi-Fi capable, and utilizes NFV (Network 209 Function Virtualization) framework, providing SFC (Service Function 210 Chaining), where one VNF (Virtual Network Function) is a CPE Layer 3 211 router and is the uCPE device which will receive a /64 prefix from 4G 212 3GPP Wireless provider and would like to be able to provide further 213 segmentation. In order to provide further segmentation and subdivide 214 the /64 into smaller longer prefix subnets variable SLAAC must be 215 employed. In this example we would give 1st /66 to Wi-Fi users, 2nd 216 /66 to Wired connected network device without security, 3rd /66 217 prefix to VNF firewall instance, and 4th /66 prefix VNF load balancer 218 instance. The uCPE (Universal Customer Premises Equipment) defined 219 in draft [I-D.shytyi-opsawg-vysm]. 221 From a segmented bandwidth perspective while breaking up the /64 222 subnet into smaller subnets, there is not any impact to the user 223 experience of the now shared bandwidth, as long as the cellular 224 signal has adequate enough bars as far as signal strength to 225 accommodate the now multiple devices sharing the single cellular 226 signal. These scenarios described above are the problems that can 227 only be solved with a variable SLAAC solution. There is no other 228 solution or workaround for this problem. A possible solution to this 229 problem has been proposed in [I-D.mishra-6man-variable-slaac]. 231 4. Variable SLAAC Use Cases 233 This section describes real world use cases of variable slaac that 234 cannot be done today and with fixed 64 bit prefix lengths. 236 4.1. Permission-less Extension of the Network 238 Permission-less extensions of the network with new links (and by 239 implication with new routers) are not supported. 241 The lack of possibility to realize a permission-less extension of the 242 network is an important problem, which appears at the edge of the 243 network. The permission is 'granted' for end users situated at the 244 edge of the network, and is 'granted' by advertising a prefix of 245 length 64 inside the PIO option in a RA typically. The end user 246 receives this prefix, forms an address, and is able to connect to the 247 internet. However, the end user has no permission to further extend 248 the network. Although the device is able to form subsequent prefixes 249 of a length of, say 65, and further advertise it down in the 250 extension of the network, no other Host in that extension of the 251 network is able to use that advertisement; a Host cannot form an 252 address with a prefix length 65 by using SLAAC. The Linux error text 253 reported in the kernel log upon reception of a plen 65 is "illegal" 254 (or similar). 256 4.2. Private Networks 258 Private networks such as Service Provider core not accessible by 259 customers and enterprises where all hosts are trusted are the primary 260 use case for variable SLAAC as the shorter interface identifier does 261 not create any security issues with not having a longer 64 bit 262 interface identifier for privacy extensions stable interface 263 identifier [RFC8084] due to all hosts being inherently trusted. 264 Private internal networks such as corporate intranets traditionally 265 have always used static IPv6 addressing for infrastructure. This 266 manual IPv6 address assignment process for network infrastructure 267 links can take long lead times to complete deployment. By changing 268 the behavior of SLAAC to support variable length prefix and interface 269 identifier allows SLAAC to be used programmatically to deploy to 270 large scale IPv6 networks with thousands of point-to-point links. 271 Note that network infrastructure technically does not require IPv6 272 addressing due to IPv6 next hop being a link local address for IGP 273 routing protocols such as OSPF and ISIS as well as the link local 274 address can be the peer IPv6 address for exterior gateway routing 275 protocols such as BGP. However for hop by hop ping and traceroute 276 capability to have IPv6 reachability at each hop for troubleshooting 277 jitter, latency and drops it is an IPv6 recommended best practice to 278 configure IPv6 address on all infrastructure interfaces. 280 4.3. Mobile IPv6 282 Old MIP6 (Mobile IPv6) Working Group and old Nemo Working Group's 283 routing solution scenarios related to Mobile IPv6 ([RFC3775]) (note: 284 nowadays most MIP-related activity is in DMM WG) where the mobile 285 endpoint can now obtain from the home agent variable SLAAC address 286 and not 64 bit prefix /64 address. This maybe useful in cases where 287 a /64 can now be managed from an addressing perspective and 288 subdivided into blocks for manageability of MIP6 endpoints instead of 289 allocating a single /64 per endpoint. 291 4.4. Home and SOHO 293 Home and SOHO (Small Office and Home Office) environments where 294 internet access uses a broadband service provider single or dual 295 homed scenario. In those such Home networking Homenet environments 296 where HNCP (Home Network Control Protocol [RFC7788] SADR (Source 297 Address Dependent Routing) are deployed for automatic configuration 298 for LAN Wi-Fi endpoint subnets can also now take advantage of 299 variable length SLAAC in deployment scenarios. In cases where 300 multiple routers are deployed in a home environment where routing 301 prefix reachability needs to be advertised where Babel [RFC6126] 302 routing protocol is utilized in those cases variable SLAAC can also 303 be utilized to break up a /64 into multiple smaller subnets. 305 4.5. 3GPP V2I and V2V networking 307 In V2I networking (with 3GPP or with IEEE 802.11bd) the IP-OBU in the 308 vehicle receives a /64 prefix from the cellular network (or from a 309 IP-RSU - Road-Side Unit). This /64 prefix can be used to form one 310 address for the egress interface of the Mobile Router (MR, which is 311 also termed 'IP-OBU', for IP On-Board Unit, in IPWAVE WG documents 312 such as RFC8691), but can not be used to form IP addresses for other 313 hosts in the vehicle. In the following two paragraphs we explain 314 this problem. 316 In certain 3GPP V2I networking use cases a /56 is allocated by the 317 3GPP infrastructure to the 4G modem of the IP-OBU in the vehicle. In 318 such use case it is possible that the IP-OBU sub-divides the 319 allocated /56 into multiple 'result' /64 prefixes. Such a 'result' 320 /64 prefix could be used to form addresses for deeper subnets in the 321 vehicle, by employing existing SLAAC and existing IPv6-over-foo 322 specifications of Interface ID. 324 If in other 3GPP V2I networking use-cases the infrastructure does not 325 allocate a /56 (or 'longer' prefix lengths such as a /57, /58../63) 326 to the IP-OBU, i.e. a /64 is allocated to the IP-OBU, then the 327 'result' prefix obtained after a sub-divide operation can only be of 328 length /65, or /66, or longer. A prefix of such length (longer than 329 64) can not be used with SLAAC and existing IP-over-foo Interface 330 Identifiers, because the length of all Interface Identifiers in all 331 IPv6-over-foo documents must always be 64, and the length of the IPv6 332 is always 128bit. The 64bit of an IID added to the 65bit (or more) 333 of a prefix is larger than 128bit. It is for this reason that a 334 SLAAC with other than 64bit Interface IDs (hence a 'Variable Prefix 335 Length SLAAC') is needed. 337 The problem of /64 allocation to the vehicle is mostly present in V2I 338 use-cases. In V2V use-cases this problem is less apparent but 339 deserves consideration. Until now there was no clearcut design and 340 decision about the infrastructure allocating addresses to several 341 vehicles (just to one, in V2I, see above). In some use-cases, the 342 prefix allocated to one vehicle could be further extended by that 343 vehicle to delegate prefixes to other vehicles nearby which might not 344 have 3GPP connections, but only 802.11-OCB interfaces. In such cases 345 it is again necessary that a /64 allocated by the infrastructure to 346 the first vehicle be further sub-divided in multiple 'result' longer- 347 than-/64 prefixes; and one of these longer-than-64 prefixes might be 348 used for the second vehicle (instead of being used for the internal 349 subnets of the first vehicle); this latter vehicle will need to use a 350 form of SLAAC and IP-over-foo that are not limited by the /64 limit. 352 4.6. Smart Traffic Lights 354 Smart traffic lights are traffic lights equipped with a communication 355 system. Smart traffic lights are deployed at intersections of roads 356 and serve the purpose of safely arbitrating the passage of 357 automobiles, pedestrians and cyclists. A typical smart traffic 358 lights setting is made of several computers, included but not limited 359 to: a traffic lights controller, a power controller and a 360 communication gateway. More advanced smart traffic lights are 361 equipped with more computers for radars, detection loops, lidars, V2X 362 wireless capabilities, Wi-Fi, Bluetooth and cellular 4G or 5G. All 363 these computers need to use IP addresses: at least one IP address per 364 computer. Since smart traffic lights are deployed in areas where 365 Internet might not be available by cable, fibre or other Wireless MAN 366 technology the only way to connect all computers in the smart traffic 367 lights setting is to employ a 4G (or 5G) gateway. This gateway 368 obtains typically a /64 prefix from the network operator; there is a 369 problem in subdividing that /64 prefix into smaller prefixes, because 370 the obtained prefixes can not be used by SLAAC, because SLAAC uses 371 Interface IDs of length 64 in practice. Even if the SLAAC 372 specification is independent of the prefix length, the length of the 373 Interface ID dictates the prefix length by side effect (128 minus IID 374 length imposes the prefix length). SLAAC might work with a plen 65 375 by specification, but all IIDs in all IPv6-over-foo request that IIDs 376 be 64; and the sum of IID len plus plen must be 128. 378 4.7. 6lo 380 6lo Working IPv6 over Network Constrained nodes working group use 381 cases. Use cases for IoT devices where have limited network access 382 requirements could now take advantage of variable SLAAC longer 383 prefixes lengths /65-/128. 385 4.8. Large ISP's backbone POP 387 Large ISP backbone POPs such as IXPs where many carriers share the 388 same backbone and ND cache exhaustion may occur due to /64 subnet 389 size. One mitigation technique employed is the use of an ARP Sponge 390 for IPv4 or Layer 2 multicast rate limiters for IPv6. In those 391 particular cases a longer prefix static or variable SLAAC subnet 392 could be utilized to reduce the maximum number of hosts on the 393 subnet. 395 4.9. Permission-less extension of the Network 397 When one wants to extend the network, one typically wants to add new 398 computers to it. Currently, there are two ways to achieve it: (1) 399 ask the network administrator to provide addresses while also 400 inserting a route towards the new subnet of devices and (2) use NAT. 401 With IPv6, NAT is not desirable. In order to extend the network 402 without asking for permission one needs to obtain addresses and to 403 obtain that route inserted. In order to obtain addresses, one might 404 take advantage of the /64 prefix typically advertised by the network 405 to an edge of it. To do that, one needs to sub-divide the /64 prefix 406 into /65 sub-prefixes (or longer, such as /66, /67, etc.) which could 407 be further advertised in the extension of the network. For the 408 action of inserting a route, the particular topic is outside the 409 scope of this document. 411 5. Security Considerations 413 The administrator should be aware to maintain 64 bit interface 414 identifier for privacy when connected directly to the internet so 415 that entropy for optimal heuristics are maintained for security. 417 Variable length interface identifier shorter then 64 bits should be 418 only used within corporate intranets and private networks where all 419 hosts are trusted. 421 In all cases where the host is on a public network for privacy 422 concerns to avoid traceability variable interface identifier MUST 423 never be utilized. 425 6. IANA Considerations 427 IANA is requested to assign the new Router Advertisement flag defined 428 in Section 5 of this document. Bit 6 is the next available bit in 429 this registry, IANA is requested to use this bit unless there is a 430 reason to use another bit in this registry. 432 IANA is also requested to register this new flag bit in the IANA IPv6 433 ND Router Advertisement flags Registry [IANA-RF]. 435 7. Contributors 437 Contributors. 439 8. Acknowledgements 441 9. References 443 9.1. Normative References 445 [I-D.bourbaki-6man-classless-ipv6] 446 Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man- 447 classless-ipv6-05 (work in progress), April 2019. 449 [I-D.mishra-6man-variable-slaac] 450 Mishra, G., Petrescu, A., Kottapalli, N., Mudric, D., and 451 D. Shytyi, "SLAAC with prefixes of arbitrary length in PIO 452 (Variable SLAAC)", draft-mishra-6man-variable-slaac-03 453 (work in progress), March 2021. 455 [I-D.shytyi-opsawg-vysm] 456 Shytyi, D., Beylier, L., and L. Iannone, "A YANG Module 457 for uCPE management.", draft-shytyi-opsawg-vysm-09 (work 458 in progress), November 2020. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 466 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 467 . 469 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 470 Address Autoconfiguration", RFC 4862, 471 DOI 10.17487/RFC4862, September 2007, 472 . 474 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 475 DOI 10.17487/RFC6126, April 2011, 476 . 478 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 479 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 480 2016, . 482 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 483 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 9.2. Informative References 492 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 493 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 494 Boundary in IPv6 Addressing", RFC 7421, 495 DOI 10.17487/RFC7421, January 2015, 496 . 498 Appendix A. ChangeLog 500 The changes are listed in reverse chronological order, most recent 501 changes appearing at the top of the list. 503 -00: initial version. 505 Authors' Addresses 507 Gyan Mishra 508 Verizon Inc. 510 Email: gyan.s.mishra@verizon.com 512 Alexandre Petrescu 513 CEA, LIST 514 CEA Saclay 515 Gif-sur-Yvette, Ile-de-France 91190 516 France 518 Phone: +33169089223 519 Email: Alexandre.Petrescu@cea.fr 520 Naveen Kottapalli 521 Benu Networks 522 300 Concord Road 523 Billerica MA 01821 524 United States of America 526 Phone: +1 978 223 4700 527 Email: nkottapalli@benu.net 529 Dusan Mudric 530 Ciena 531 Canada 533 Phone: +1-613-670-2425 534 Email: dmudric@ciena.com 536 Dmytro Shytyi 537 SFR 538 Paris 539 France 541 Email: dmytro.shytyi@sfr.com