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