SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement
draft-mishra-v6ops-variable-slaac-problem-stmt-02

Document Type Active Internet-Draft (individual)
Authors Gyan Mishra  , Alexandre Petrescu  , Naveen Kottapalli  , Dusan Mudric  , Dmytro Shytyi 
Last updated 2021-07-12
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
6MAN Working Group                                             G. Mishra
Internet-Draft                                              Verizon Inc.
Intended status: Informational                               A. Petrescu
Expires: January 13, 2022                                      CEA, LIST
                                                           N. Kottapalli
                                                           Benu Networks
                                                               D. Mudric
                                                                   Ciena
                                                               D. Shytyi
                                                                     SFR
                                                           July 12, 2021

  SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A
                           Problem Statement
           draft-mishra-v6ops-variable-slaac-problem-stmt-02

Abstract

   In the past, various IPv6 addressing models have been proposed based
   on a subnet hierarchy embedding a 64-bit prefix.  The last remnant of
   IPv6 classful addressing is a inflexible interface identifier
   boundary at /64.  This document details the 64-bit boundary problem
   statement.

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 January 13, 2022.

Copyright Notice

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

Mishra, et al.          Expires January 13, 2022                [Page 1]
Internet-Draft               Variable SLAAC                    July 2021

   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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Variable SLAAC Use Cases  . . . . . . . . . . . . . . . . . .   5
     4.1.  Permission-less Extension of the Network  . . . . . . . .   5
     4.2.  Private Networks  . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Home and SOHO . . . . . . . . . . . . . . . . . . . . . .   7
     4.5.  3GPP V2I and V2V networking . . . . . . . . . . . . . . .   7
     4.6.  Smart Traffic Lights  . . . . . . . . . . . . . . . . . .   8
     4.7.  6lo . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.8.  Large ISP's backbone POP  . . . . . . . . . . . . . . . .   9
     4.9.  Permission-less extension of the Network  . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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

2.  Introduction

   From the beginning, the IPv6 addressing plan was based on a 128 bit
   address format made up of 8 hextets which were broken down into a 64
   bit four hextet prefix and 64 bit four hextet interface identifier.

Mishra, et al.          Expires January 13, 2022                [Page 2]
Internet-Draft               Variable SLAAC                    July 2021

   For example, the address 2001:db8:3:4::1 has the first 4 hextets
   forming the /64 prefix 2001:db8:3:4::/64, whereas the last four
   hextets form an interface identifier abbreviated as ::1 (a 'hextet'
   is a group of max 4 hex digits between two columns, e.g. "2001" and
   "db8" are each a hextet).  A comprehensive analysis of the 64-bit
   boundary is provided in [RFC7421].  The history of IPv6 Classful
   models proposed, and the last remnant of IPv6 Classful addressing
   rigid network interface identifier boundary at /64 is discussed in
   detail as well as the removal of the fixed position of the boundary
   for interface addressing in draft [I-D.bourbaki-6man-classless-ipv6].

   This document discusses the reasons why the interface identifier has
   been fixed at 64 bits, and the problems that can be addressed by
   changing the GUA interface identifier from fixed 64 bit size to a
   variable interface identifier.  This change would be consistent with
   static and DHCPv6 stateful IPv6 address assignment.  This document
   tries to achieve clearing the confusion related to prefix length, and
   provide consistency of variable length prefix across the three IPv6
   addressing strategies deployed, static, DHCPv6 and Stateless Address
   Autoconfiguration(SLAAC), and finally update all RFCs with the new
   variable SLAAC standard.  The solution to this problem statement is
   defined in draft [I-D.mishra-6man-variable-slaac]

   Over the years one of the merits of increasing the prefix length, and
   reducing the size of the interface identifier has been incorrectly
   stated as the possibility of IPv6 address space exhaustion could be
   circumvented, or that a 64 bit interface identifier is an efficient
   use of address space.

3.  Problem Statement

   This section details the problem statement as to what is broken today
   with fixed length Stateless Address Autoconfiguration SLAAC [RFC4862]
   and why it is critical to resolve this problem.

   The main problem is that SLAAC RA or PD allocates a /64 by the
   wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however
   segmentation of the /64 via SLAAC is required so that downstream
   interfaces can be further sub-netted.  The use case section of this
   draft discusses this scenario as one of the use cases for shorter
   interface identifier, and this use case is the only one stated here
   in the problem statement as this is broken today with the current
   SLAAC specification [RFC4862], and there is not any workaround for
   this use case.

   There are two reasons why this was not a problem in the past, but now
   with increased bandwidth there are more and more devices being piled
   onto a single handset or mobile hotspot.  In the past generations of

Mishra, et al.          Expires January 13, 2022                [Page 3]
Internet-Draft               Variable SLAAC                    July 2021

   cellular systems (e.g. 2.5G aka GPRS and some 3G) the bandwidth
   available to the User Equipment was not enough to accommodate several
   applications; bandwidth available was roughly 256Kbit/s.  For that
   reason, users were rarely tempted to use an UE to link other devices
   than that UE to the Internet.  However, with the arrival of 3G, 3G+
   (e.g.  HSDPA / HSUPA), and even more so with 4G and 4G+, the
   bandwidth made available to UE increased significantly; this became
   an average effective of 1Mbit/s and even more.  With this available
   bandwidth, the users are more and more tempted to connect several
   devices to the Internet.  This operation is named 'connection
   sharing' or 'tethering'.  Another answer to this question is that
   IPv6 technology that is widely used to 'tether' several IP devices to
   a smartphone is '64share' RFC7278.  This technology is used for
   smartphones but is not so in vehicles.  One of the reasons of not
   being used in vehicles is the lack of scalability: a /64 prefix is
   shared between the UE ptp link and the subnet (typically Wi-Fi), but
   can not be further sub-netted to other subnets in the car.

   The reason why all devices in a car cannot remain on a single /64 are
   as follows.  These devices have different link-layer technologies,
   and not all WiFi could be bridged into Ethernet such as to keep all
   devices into one /64.  They could be on links that are not
   bridgeable: devices on 802.11-OCB cannott be bridged, devices on
   Bluetooth cannott be bridged, devices on 3GPP cannott be bridged, and
   so one.  Other than the impossibility to bridge several such link-
   layer technologies there is also a problem of noise: in a vehicle one
   wants the braking pedal signal to not be disturbed by entertainment
   sites such as YouTube.  That physical technical requirement
   separation of different link layer technologies segmentation on to
   different smaller IPv6 subnets cannot be achieved if all devices are
   on a single /64, or bridged.  Therefore, the only possible solution
   to connect these disparate devices onto a 3GPP network for internet
   access is to keep these separate link layer technologies segmented
   onto separate greater then /64 prefix subnets and breaking the /64
   boundary that exists today with a Variable SLAAC solution.  Thus,
   when the 3GPP network gives a /64 to the car, and when there are
   unbridgeable technologies in the car (e.g.  WiFi cant be bridged to
   Bluetooth), then the only possibility is to divide that /64 into two
   /65s.  One /65 would be used on the WiFi and another /65 would be
   used on Bluetooth.  But in order for SLAAC to work with /65 then
   there is a need to have the shorter interface identifier of length
   63.  Hence the need of lengths of PIOs other than 64 (variable plen).

   There are three scenarios that require SLAAC to be able to be routed
   between two greater then /64 prefix segments as part of the
   requirement for variable length SLAAC and what is broken with the
   current SLAAC specification defined in [RFC4862].

Mishra, et al.          Expires January 13, 2022                [Page 4]
Internet-Draft               Variable SLAAC                    July 2021

   The first scenario is within a car using car manufacturer single SIM
   for internet access and being able to bridge(Route) other link layer
   devices like BT via variable slaac.  In this scenario the
   communication between downstream devices are all located within the
   car using the car manufacturer built in SIM card for in-vehicle
   communication.  The in-vehicle scenario covers both the built-in car
   manufacturer SIM card scenario, or if the car manufacturer does not
   support built-in SIM card then a single mobile handset providing 3GPP
   internet access to all devices in the car.

   The second scenario is V2V (vehicle to vehicle) between cars
   requiring SLAAC to subnet the >64 prefix so that the two cars have
   WiFi connectivity.

   This third scenario is a uCPE(Universal Customer Premises Equipment)
   device is LTE 4G and Wi-Fi capable, and utilizes NFV (Network
   Function Virtualization) framework, providing SFC (Service Function
   Chaining), where one VNF (Virtual Network Function) is a CPE Layer 3
   router and is the uCPE device which will receive a /64 prefix from 4G
   3GPP Wireless provider and would like to be able to provide further
   segmentation.  In order to provide further segmentation and subdivide
   the /64 into smaller longer prefix subnets variable SLAAC must be
   employed.  In this example we would give 1st /66 to Wi-Fi users, 2nd
   /66 to Wired connected network device without security, 3rd /66
   prefix to VNF firewall instance, and 4th /66 prefix VNF load balancer
   instance.  The uCPE (Universal Customer Premises Equipment) defined
   in draft [I-D.shytyi-opsawg-vysm].

   From a segmented bandwidth perspective while breaking up the /64
   subnet into smaller subnets, there is not any impact to the user
   experience of the now shared bandwidth, as long as the cellular
   signal has adequate enough bars as far as signal strength to
   accommodate the now multiple devices sharing the single cellular
   signal.  These scenarios described above are the problems that can
   only be solved with a variable SLAAC solution.  There is no other
   solution or workaround for this problem.  A possible solution to this
   problem has been proposed in [I-D.mishra-6man-variable-slaac].

4.  Variable SLAAC Use Cases

   This section describes real world use cases of variable slaac that
   cannot be done today and with fixed 64 bit prefix lengths.

4.1.  Permission-less Extension of the Network

   Permission-less extensions of the network with new links (and by
   implication with new routers) are not supported.

Mishra, et al.          Expires January 13, 2022                [Page 5]
Internet-Draft               Variable SLAAC                    July 2021

   The lack of possibility to realize a permission-less extension of the
   network is an important problem, which appears at the edge of the
   network.  The permission is 'granted' for end users situated at the
   edge of the network, and is 'granted' by advertising a prefix of
   length 64 inside the PIO option in a RA typically.  The end user
   receives this prefix, forms an address, and is able to connect to the
   internet.  However, the end user has no permission to further extend
   the network.  Although the device is able to form subsequent prefixes
   of a length of, say 65, and further advertise it down in the
   extension of the network, no other Host in that extension of the
   network is able to use that advertisement; a Host cannot form an
   address with a prefix length 65 by using SLAAC.  The Linux error text
   reported in the kernel log upon reception of a plen 65 is "illegal"
   (or similar).

4.2.  Private Networks

   Private networks such as Service Provider core not accessible by
   customers and enterprises where all hosts are trusted are the primary
   use case for variable SLAAC as the shorter interface identifier does
   not create any security issues with not having a longer 64 bit
   interface identifier for privacy extensions stable interface
   identifier [RFC8084] due to all hosts being inherently trusted.
   Private internal networks such as corporate intranets traditionally
   have always used static IPv6 addressing for infrastructure.  This
   manual IPv6 address assignment process for network infrastructure
   links can take long lead times to complete deployment.  By changing
   the behavior of SLAAC to support variable length prefix and interface
   identifier allows SLAAC to be used programmatically to deploy to
   large scale IPv6 networks with thousands of point-to-point links.
   Note that network infrastructure technically does not require IPv6
   addressing due to IPv6 next hop being a link local address for IGP
   routing protocols such as OSPF and ISIS as well as the link local
   address can be the peer IPv6 address for exterior gateway routing
   protocols such as BGP.  However for hop by hop ping and traceroute
   capability to have IPv6 reachability at each hop for troubleshooting
   jitter, latency and drops it is an IPv6 recommended best practice to
   configure IPv6 address on all infrastructure interfaces.

4.3.  Mobile IPv6

   Old MIP6 (Mobile IPv6) Working Group and old Nemo Working Group's
   routing solution scenarios related to Mobile IPv6 ([RFC3775]) (note:
   nowadays most MIP-related activity is in DMM WG) where the mobile
   endpoint can now obtain from the home agent variable SLAAC address
   and not 64 bit prefix /64 address.  This maybe useful in cases where
   a /64 can now be managed from an addressing perspective and

Mishra, et al.          Expires January 13, 2022                [Page 6]
Internet-Draft               Variable SLAAC                    July 2021

   subdivided into blocks for manageability of MIP6 endpoints instead of
   allocating a single /64 per endpoint.

4.4.  Home and SOHO

   Home and SOHO (Small Office and Home Office) environments where
   internet access uses a broadband service provider single or dual
   homed scenario.  In those such Home networking Homenet environments
   where HNCP (Home Network Control Protocol [RFC7788] SADR (Source
   Address Dependent Routing) are deployed for automatic configuration
   for LAN Wi-Fi endpoint subnets can also now take advantage of
   variable length SLAAC in deployment scenarios.  In cases where
   multiple routers are deployed in a home environment where routing
   prefix reachability needs to be advertised where Babel [RFC6126]
   routing protocol is utilized in those cases variable SLAAC can also
   be utilized to break up a /64 into multiple smaller subnets.

4.5.  3GPP V2I and V2V networking

   In V2I networking (with 3GPP or with IEEE 802.11bd) the IP-OBU in the
   vehicle receives a /64 prefix from the cellular network (or from a
   IP-RSU - Road-Side Unit).  This /64 prefix can be used to form one
   address for the egress interface of the Mobile Router (MR, which is
   also termed 'IP-OBU', for IP On-Board Unit, in IPWAVE WG documents
   such as RFC8691), but can not be used to form IP addresses for other
   hosts in the vehicle.  In the following two paragraphs we explain
   this problem.

   In certain 3GPP V2I networking use cases a /56 is allocated by the
   3GPP infrastructure to the 4G modem of the IP-OBU in the vehicle.  In
   such use case it is possible that the IP-OBU sub-divides the
   allocated /56 into multiple 'result' /64 prefixes.  Such a 'result'
   /64 prefix could be used to form addresses for deeper subnets in the
   vehicle, by employing existing SLAAC and existing IPv6-over-foo
   specifications of Interface ID.

   If in other 3GPP V2I networking use-cases the infrastructure does not
   allocate a /56 (or 'longer' prefix lengths such as a /57, /58../63)
   to the IP-OBU, i.e. a /64 is allocated to the IP-OBU, then the
   'result' prefix obtained after a sub-divide operation can only be of
   length /65, or /66, or longer.  A prefix of such length (longer than
   64) can not be used with SLAAC and existing IP-over-foo Interface
   Identifiers, because the length of all Interface Identifiers in all
   IPv6-over-foo documents must always be 64, and the length of the IPv6
   is always 128bit.  The 64bit of an IID added to the 65bit (or more)
   of a prefix is larger than 128bit.  It is for this reason that a
   SLAAC with other than 64bit Interface IDs (hence a 'Variable Prefix
   Length SLAAC') is needed.

Mishra, et al.          Expires January 13, 2022                [Page 7]
Internet-Draft               Variable SLAAC                    July 2021

   The problem of /64 allocation to the vehicle is mostly present in V2I
   use-cases.  In V2V use-cases this problem is less apparent but
   deserves consideration.  Until now there was no clearcut design and
   decision about the infrastructure allocating addresses to several
   vehicles (just to one, in V2I, see above).  In some use-cases, the
   prefix allocated to one vehicle could be further extended by that
   vehicle to delegate prefixes to other vehicles nearby which might not
   have 3GPP connections, but only 802.11-OCB interfaces.  In such cases
   it is again necessary that a /64 allocated by the infrastructure to
   the first vehicle be further sub-divided in multiple 'result' longer-
   than-/64 prefixes; and one of these longer-than-64 prefixes might be
   used for the second vehicle (instead of being used for the internal
   subnets of the first vehicle); this latter vehicle will need to use a
   form of SLAAC and IP-over-foo that are not limited by the /64 limit.

4.6.  Smart Traffic Lights

   Smart traffic lights are traffic lights equipped with a communication
   system.  Smart traffic lights are deployed at intersections of roads
   and serve the purpose of safely arbitrating the passage of
   automobiles, pedestrians and cyclists.  A typical smart traffic
   lights setting is made of several computers, included but not limited
   to: a traffic lights controller, a power controller and a
   communication gateway.  More advanced smart traffic lights are
   equipped with more computers for radars, detection loops, lidars, V2X
   wireless capabilities, Wi-Fi, Bluetooth and cellular 4G or 5G.  All
   these computers need to use IP addresses: at least one IP address per
   computer.  Since smart traffic lights are deployed in areas where
   Internet might not be available by cable, fibre or other Wireless MAN
   technology the only way to connect all computers in the smart traffic
   lights setting is to employ a 4G (or 5G) gateway.  This gateway
   obtains typically a /64 prefix from the network operator; there is a
   problem in subdividing that /64 prefix into smaller prefixes, because
   the obtained prefixes can not be used by SLAAC, because SLAAC uses
   Interface IDs of length 64 in practice.  Even if the SLAAC
   specification is independent of the prefix length, the length of the
   Interface ID dictates the prefix length by side effect (128 minus IID
   length imposes the prefix length).  SLAAC might work with a plen 65
   by specification, but all IIDs in all IPv6-over-foo request that IIDs
   be 64; and the sum of IID len plus plen must be 128.

4.7.  6lo

   6lo Working IPv6 over Network Constrained nodes working group use
   cases.  Use cases for IoT devices where have limited network access
   requirements could now take advantage of variable SLAAC longer
   prefixes lengths /65-/128.

Mishra, et al.          Expires January 13, 2022                [Page 8]
Internet-Draft               Variable SLAAC                    July 2021

4.8.  Large ISP's backbone POP

   Large ISP backbone POPs such as IXPs where many carriers share the
   same backbone and ND cache exhaustion may occur due to /64 subnet
   size.  One mitigation technique employed is the use of an ARP Sponge
   for IPv4 or Layer 2 multicast rate limiters for IPv6.  In those
   particular cases a longer prefix static or variable SLAAC subnet
   could be utilized to reduce the maximum number of hosts on the
   subnet.

4.9.  Permission-less extension of the Network

   When one wants to extend the network, one typically wants to add new
   computers to it.  Currently, there are two ways to achieve it: (1)
   ask the network administrator to provide addresses while also
   inserting a route towards the new subnet of devices and (2) use NAT.
   With IPv6, NAT is not desirable.  In order to extend the network
   without asking for permission one needs to obtain addresses and to
   obtain that route inserted.  In order to obtain addresses, one might
   take advantage of the /64 prefix typically advertised by the network
   to an edge of it.  To do that, one needs to sub-divide the /64 prefix
   into /65 sub-prefixes (or longer, such as /66, /67, etc.) which could
   be further advertised in the extension of the network.  For the
   action of inserting a route, the particular topic is outside the
   scope of this document.

5.  Security Considerations

   The administrator should be aware to maintain 64 bit interface
   identifier for privacy when connected directly to the internet so
   that entropy for optimal heuristics are maintained for security.

   Variable length interface identifier shorter then 64 bits should be
   only used within corporate intranets and private networks where all
   hosts are trusted.

   In all cases where the host is on a public network for privacy
   concerns to avoid traceability variable interface identifier MUST
   never be utilized.

6.  IANA Considerations

   IANA is requested to assign the new Router Advertisement flag defined
   in Section 5 of this document.  Bit 6 is the next available bit in
   this registry, IANA is requested to use this bit unless there is a
   reason to use another bit in this registry.

Mishra, et al.          Expires January 13, 2022                [Page 9]
Internet-Draft               Variable SLAAC                    July 2021

   IANA is also requested to register this new flag bit in the IANA IPv6
   ND Router Advertisement flags Registry [IANA-RF].

7.  Contributors

   Contributors.

8.  Acknowledgements

9.  References

9.1.  Normative References

   [I-D.bourbaki-6man-classless-ipv6]
              Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man-
              classless-ipv6-05 (work in progress), April 2019.

   [I-D.mishra-6man-variable-slaac]
              Mishra, G., Petrescu, A., Kottapalli, N., Mudric, D., and
              D. Shytyi, "SLAAC with prefixes of arbitrary length in PIO
              (Variable SLAAC)", draft-mishra-6man-variable-slaac-03
              (work in progress), March 2021.

   [I-D.shytyi-opsawg-vysm]
              Shytyi, D., Beylier, L., and L. Iannone, "A YANG Module
              for uCPE management.", draft-shytyi-opsawg-vysm-09 (work
              in progress), November 2020.

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004,
              <https://www.rfc-editor.org/info/rfc3775>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC6126]  Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
              DOI 10.17487/RFC6126, April 2011,
              <https://www.rfc-editor.org/info/rfc6126>.

Mishra, et al.          Expires January 13, 2022               [Page 10]
Internet-Draft               Variable SLAAC                    July 2021

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers",
              BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
              <https://www.rfc-editor.org/info/rfc8084>.

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

9.2.  Informative References

   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
              Boundary in IPv6 Addressing", RFC 7421,
              DOI 10.17487/RFC7421, January 2015,
              <https://www.rfc-editor.org/info/rfc7421>.

Appendix A.  ChangeLog

   The changes are listed in reverse chronological order, most recent
   changes appearing at the top of the list.

   -00: initial version.

Authors' Addresses

   Gyan Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com

   Alexandre Petrescu
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette, Ile-de-France  91190
   France

   Phone: +33169089223
   Email: Alexandre.Petrescu@cea.fr

Mishra, et al.          Expires January 13, 2022               [Page 11]
Internet-Draft               Variable SLAAC                    July 2021

   Naveen Kottapalli
   Benu Networks
    300 Concord Road
   Billerica  MA 01821
   United States of America

   Phone: +1 978 223 4700
   Email: nkottapalli@benu.net

   Dusan Mudric
   Ciena
   Canada

   Phone: +1-613-670-2425
   Email: dmudric@ciena.com

   Dmytro Shytyi
   SFR
   Paris
   France

   Email: dmytro.shytyi@sfr.com

Mishra, et al.          Expires January 13, 2022               [Page 12]