Using DHCP-PD to Allocate /64 per Host in Broadcast Networks
draft-collink-v6ops-ent64pd-02

v6ops Working Group                                           L. Colitti
Internet-Draft                                               Google, LLC
Intended status: Informational                           J. Linkova, Ed.
Expires: 31 August 2023                                       X. Ma, Ed.
                                                                  Google
                                                        27 February 2023

      Using DHCP-PD to Allocate /64 per Host in Broadcast Networks
                     draft-collink-v6ops-ent64pd-02

Abstract

   This document discusses the IPv6 deployment scenario when individual
   hosts connected to broadcast networks (like WiFi hotspots or
   enterprise networks) are allocated /64 subnets via DHCP-PD.

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 31 August 2023.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Colitti, et al.          Expires 31 August 2023                 [Page 1]
Internet-Draft                  MultAddrr                  February 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Prefix Length Considerations  . . . . . . . . . . . . . . . .   4
   5.  Routing Considerations  . . . . . . . . . . . . . . . . . . .   5
     5.1.  First-Hop Routers Requirements  . . . . . . . . . . . . .   5
     5.2.  Topologies with Multiple First-Hop Routers  . . . . . . .   5
     5.3.  Preventing Routing Loops  . . . . . . . . . . . . . . . .   5
   6.  DHCPv6-PD Server Considerations . . . . . . . . . . . . . . .   6
   7.  Antispoofing and SAVI Interaction . . . . . . . . . . . . . .   6
   8.  Migration Strategies and Co-existence with SLAAC Using Prefixes
           From PIO  . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Applicability and Limitations . . . . . . . . . . . . . . . .   8
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     14.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Unlike IPv4, IPv6 allows (and often requires) hosts to have multiple
   addresses.  At the very least, a host can be expected to have one
   link-local address, one temporary address and, in most cases, one
   stable global address.  On an IPv6-only network the device would need
   to have a dedicated 464XLAT address, which brings the total number of
   addresses to 4.  If the network is multihomed and uses two different
   prefixes, or during graceful renumbering (when the old prefix is
   deprecated), or if an enterprise uses ULAs, the number of global
   addresses can easily double, bringing the total number of addresses
   to 7.  Devices running containers/namespaces might need even more
   addresses per physical host.  On one hand multiple addresses could be
   considered as a significant advantage of IPv6.  On the other hand,
   however, they are sometimes seen as a drawback for the following
   reasons:

Colitti, et al.          Expires 31 August 2023                 [Page 2]
Internet-Draft                  MultAddrr                  February 2023

   *  Increased number of addresses introduces scalability issues on the
      network infrastructure.  Network devices need to maintain various
      types of tables/hashes (Neighbor Cache on first-hop routers,
      Neighbor Discovery Proxy caches on L2 devices etc).  On VXLAN
      [RFC7348] networks each address might be represented as a route so
      8 addresses instead of 1 requires the devices to support 8 times
      more routes, etc.

   *  An operator might need to know all addresses used by a given
      device in the past for forensics or troubleshooting purposes.

   *  If an infrastructure device resources are exhausted, the device
      might drop some IPv6 addresses from the corresponding tables.  The
      host, however, might be still using the address to send traffic.
      This leads to traffic blackholing and degraded customer
      experience.

   [RFC7934] discusses this aspect and explicitly states that IPv6
   deployments SHOULD NOT limit the number of IPv6 addresses a host can
   have.  However it seems inevitable that some limits might need to be
   imposed by the network in an attempt to protect the network resources
   and prevent DoS attacks (see [I-D.linkova-v6ops-ipmaclimi]).

   Therefore it would be beneficial for IPv6 deployments to address the
   above mentioned issues while still allowing hosts to have multiple
   IPv6 addresses.  One of the very promising approaches is allocating
   an unique /64 prefix per host ([RFC8273]).  The same principle has
   been actively used in mobile IPv6 deployments.  However it's very
   uncommon in enterprise-style networks, where nodes are usually
   connected to broadcast segments/VLANs and each segment has a single
   /64 subnet assigned.  This document expands the approach defined in
   [RFC8273] to allocate an unique IPv6 /64 prefix per host using DHCP-
   PD.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Design Principles

   Instead of all hosts on a given segment forming addresses from the
   same /64 assigned to that segment:

Colitti, et al.          Expires 31 August 2023                 [Page 3]
Internet-Draft                  MultAddrr                  February 2023

   *  A host acts as DHCP-PD client and requests /64 via DHCPv6-PD by
      sending IA_PD.

   *  The first-hop router acts as a DHCPv6-PD relay and sends the
      request to the DHCPv6-PD servers.  In smaller networks it's
      entirely possible for the first-hop router to act as a DHCPv6-PD
      server and assign /64 from a larger pool allocated for the given
      segment or the whole site.

   *  The allocated /64 is installed into the first-hop router routing
      table as a route pointing to the client's link-local address.  For
      the router and all other infrastructure devices that prefix is
      considered off-link, so no traffic to that prefix does not trigger
      any ND packets.

   *  The host uses the delegated /64 to allocate addresses to its
      interfaces, containers etc.  For example, the device can include
      that /64 into Router Advertisements sent to virtual systems or to
      any other devices connected to its downstream interface.

4.  Prefix Length Considerations

   As per [RFC7421] /64 is the only prefix size that will allow the host
   to use SLAAC.  As a result delegating a /64 prefix to the client
   allows the client to provide limitless addresses to IPv6 nodes
   connected to it (e.g., virtual machines, tethered devices), because
   all IPv6 nodes are required to support SLAAC.  In other words,
   delegating /64 allows the hosts to extend the network arbitrarily,
   similarily to using NAT in IPv4.  Chosing longer prefixes would
   require the host and any connected system to use some other form of
   address assignment and therefore would drastically limit
   applicability of the proposed solution.

   Section 9.2 of [RFC7934] demonstrates that if a network uses
   10.0.0.0/8 to address hosts, /40 would be sufficient to provide each
   host with /64.  In multi-site networks the calculations might get
   more complex as each site IPv6 prefix needs to be larger enough to be
   globally routable and accepted by eBGP peers, for example /48.  Let's
   consider an enterprise network which has 8000 sites (~2^13).  Imagine
   that site has up to 64 (2^6) different network types and each network
   requires its own /48.  So each network can provide /64 to 65K clients
   (an equivalent of using /16 IPv4 subnet to address hosts).  In that
   case such an enterprise would need /29 (48 - 6 - 13) to provide /64
   to its devices.  Networks of such size usually have multiple
   allocations from RIRs so /29 sounds reasonable.  In real life there
   are very few networks of that scale and a single /32 would be
   sufficient for most deployments.

Colitti, et al.          Expires 31 August 2023                 [Page 4]
Internet-Draft                  MultAddrr                  February 2023

5.  Routing Considerations

5.1.  First-Hop Routers Requirements

   The design described in this document is targeted to large networks
   were the number of clients combined with multiple IPv6 addresses per
   client creates scalability issues.  In such networks DHCPv6 servers
   are usually deployed as dedicated systems, so the first-hop routers
   act as DHCP relays.  To delegate IPv6 prefixes to hosts the first hop
   router needs to implement DHCPv6-PD relay functions and meet the
   requirements defined in [RFC8987].

   In particular, if the same DHCPv6-PD pool is used for clients
   connected to multiple routers, dynamic routing protocols are required
   to propagate the routes to the allocated prefixes.  Each relay needs
   to advertise the learned delegated leases as per requirement R-4
   specified in Section 4.2 of [RFC8987].

5.2.  Topologies with Multiple First-Hop Routers

   Traditionally DHCPv6-PD is used in environments where a DHCPv6-PD
   client (a home CPE, for example) is connected to a single router
   which performs DHCPv6-PD relay functions.  In the topology with
   redundant first-hop routers, all those routers need to snoop DHCPv6
   traffic, install the delegated prefixes into its routing table and,
   if needed, advertise those prefixes to the network.  That means that
   all relays the host is connected to must be able to snoop DHCPv6-PD
   traffic, in particular Reply messages sent by the server (as those
   messages contain the delegated prefix).  Normally the client uses
   multicast to reach all servers or an individual server (see
   Section 14 of [RFC8415]).  As per Section 18.4 of [RFC8415] the
   server is not supposed to accept unicast traffic when it is not
   explicitly configured to do, and unicast transmission is only allowed
   for some messages and only if the Server Unicast option ([RFC8415],
   Section 21.12) is used.  Therefore, in the topologies with multiple
   first-hop routers the DHCPv6 servers MUST be configured not to use
   the Server Unicast option (it should be noted that
   [I-D.dhcwg-dhc-rfc8415bis] deprecates the Server Unicast option
   exactly because it is not compatible with multiple relays topology).
   Therefore as long as the Server Unicast option is not used, all
   first-hop routers shall be able to install the route for the
   delegates prefix.

5.3.  Preventing Routing Loops

   To prevent routing loops caused by traffic to unused addresses from
   the delegated /64, the client MUST drop all packets to such addresses
   (see the requirement WPD-5 in Section 4.2 of [RFC7084].

Colitti, et al.          Expires 31 August 2023                 [Page 5]
Internet-Draft                  MultAddrr                  February 2023

6.  DHCPv6-PD Server Considerations

   The following requirements are applicable to the DHCPv6-PD server
   delegating prefixes to endhosts:

   *  The server MUST follow [RFC8168] recommendations on processing
      prefix-length hints.  Specifically, the server MUST NOT delegate
      prefixes longer than /64 if the client sets the prefix-length
      field of the IA_PD option to 64.  This is required so the host can
      use SLAAC to assign addresses from the delegated /64 to its
      interfaces or virtual instances.  The client MAY ignore any
      delegated prefixes longer that /64.

   *  Do not send the Server Unicast option to the client unless the
      network topology guarantees that no client is connected to a
      segment with multiple relays (see Section 5.2).

7.  Antispoofing and SAVI Interaction

   Enabling the unicast Reverse Path Forwarding (uRPF) on the first-hop
   router interfaces towards clients provides the first layer of defence
   agains spoofing.  If the malicious client sends a spoofed packet it
   would be dropped by the router unless the spoofed address belongs to
   a prefix delegated to another client on the same interface.
   Therefore the malicious client can only spoof addresses already
   delegated to another client on the same segment or another host link-
   local address.

   Source Address Validation Improvement (SAVI, [RFC7039]) provides more
   reliable protection against address spoofing.  Administrators
   deploying the proposed solution on the SAVI-enabled infastructure
   should ensure that SAVI perimeter devices support DHCPv6-PD snooping
   to create the correct binding for the delegated prefixes (see
   [RFC7513]).  Using FCFS SAVI ([RFC6620]) for protecting link-local
   addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes
   would prevent spoofing.

   It should be noted that using DHCPv6-PD makes it harder for an
   attacker to select the spoofed source address.  When all hosts are
   using the same /64 to form addresses, the attacker might learn
   addresses used by other hosts by listening to multicast Neighbor
   Solicitations and Neighbour Advertisements.  In DHCPv6-PD
   environments, however, the attacker can only learn about other hosts
   global addresses by listening to multicast DHCPv6 messages, which are
   not transmitted so often.

Colitti, et al.          Expires 31 August 2023                 [Page 6]
Internet-Draft                  MultAddrr                  February 2023

8.  Migration Strategies and Co-existence with SLAAC Using Prefixes From
    PIO

   It would be beneficial for the network to explicitly indicate its
   support of DHCPv6-PD for hosts.

   *  In small networks (e.g. home ones), where the number of devices is
      not too high, the number of available /64 becomes a limiting
      factor.  If every phone or laptop in a home network would request
      an unique /64, the home network might run out of /64s, if the
      prefix allocated to the CPE by its ISP is too small (e.g. if an
      ISP allocates /60, it would only allow 16 devices to request /64).
      So while the enterprise network administrator might want all
      phones in the network to request /64, it would be highly
      undesirable for the same phone to request /64 when connecting to a
      home network.

   *  When the network supports both /64 per host and /64 advertised in
      PIO as address assignment methods, it's highly desirable for the
      host NOT to use the PIO prefix tto form global addresses and only
      use the prefix delegated via DHCPv6-PD.  Starting both SLAAC using
      the PIO prefix and DHCPv6-PD and deprecating that SLAAC addresses
      after receiving a delegated prefix would be very disruptive for
      applications.  If the host continues to use addresses formed from
      the PIO prefix it would not only undermine the benefits of the
      proposed solution (see Section 9), but would also introduce
      complexity and unpredictability in the source address selection.
      Therefore the host needs to know what address assignment method to
      use and whether to use the prefix in PIO or not, if the network
      provides the PIO with A flag set.

   To allow the network to signal DHCPv6-PD support a new PIO flag is
   proposed (link to the 6man draft will be added here after this draft
   is adopted).

9.  Benefits

   The proposed solution provides the following benefits:

   *  The network devices resources (e.g. memory) need to scale to the
      number of devices, not the number of IPv6 addresses.  The first-
      hop routers have a single /64 route per host pointing to the
      host's link-local address.

   *  If all devices connected to the given network segment support this
      mode of operation and can generate addresses from the delegated
      /64, there is no reason to advertise a common /64 assigned to that
      segment in PIO with 'A' flag set.  Therefore it is possible to

Colitti, et al.          Expires 31 August 2023                 [Page 7]
Internet-Draft                  MultAddrr                  February 2023

      remove the global /64 prefix from that network segment and the
      router interface completely, so no global addresses are on-link
      for the segment.  This would lead to reducing the attack surface
      for Neighbor Discovery attacks described in [RFC6583].

   *  DHCP-PD logs and first-hop routers routing tables provide complete
      information on IPv6 to MAC mapping, which can be used for
      forensics and troubleshooting.  Such information is much less
      dynamic than ND cache and therefore it's much easier for an
      operator to collect and process it.

   *  The cost of having multiple addresses is offloaded to the
      endpoint.  Devices are free to create and use as many addresses as
      they need.

   *  Fate sharing: all global addresses used by a given device are
      routed as a single /64.  Either all of them work or not, which
      makes the failures easier to diagnoze and mitigate.

   *  Ability to extend the network transparently.  If the hosts use
      SLAAC, delegating /64 allows the host to provide connectivity to
      other hosts, like it is possible in IPv4 with NAT.

10.  Applicability and Limitations

   The solution described in this document shouldn't be seen as an
   attempt to deprecate SLAAC.  Delegating /64 provides an alternative
   for SLAAC rather than replacing it, so network administrators and OS
   developers have a choice.  This design would substantially benefit
   some networks (see Section 9), so running an additional service and
   allocation larger amount of address space is well justified.
   Examples of such networks include but are not limited to:

   *  Large-scale networks where even 3-5 addresses per client might
      intorduce scalability issues.

   *  Networks with high number of virtual hosts, so physical enpoints
      require multiple addresses.

   *  Managed networks where extensive troubleshooting, host traffic
      logging or forensics might be required.

   Smaller networks (like home ones) with smaller address space and
   lower number of clients, SLAAC might be a better and simpler option.

Colitti, et al.          Expires 31 August 2023                 [Page 8]
Internet-Draft                  MultAddrr                  February 2023

11.  Privacy Considerations

   Eventually, if/when the vast majority of endpoints support the
   proposed mechanism, an eavesdropper/information collector might be
   able to correlate the prefix to the device.  To mitigate the threat
   the host might implement a mechanism similar to SLAAC temporary
   extensions ([RFC8981]) but for delegated prefixes:

   *  The host requests another /64 prefix.

   *  Upon receiving the new prefix the host deprecates all addresses
      from the old one.

   *  After some time (shall it be T2 from IA_PD for the original
      prefix?) the host sends RELEASE for the old prefix.

12.  IANA Considerations

   This memo includes no request to IANA.

13.  Security Considerations

   A malicious or just misbehaving host might exhaust the DHCP-PD pool
   by sending a large number of requests with various DUIDs.  However
   this is not a new issue as the same attack might be implemented in
   DHCPv4 or DHCPv6 for IA_NA requests.

   A malicious host might request a prefix and then release it very
   quickly, causing routing convergence events on the relays.  The
   probability of such attack can be reduced if the network rate limits
   the amount of broadcast and multicast messages from the client.

   Delegating the same prefix for the same host introduces privacy
   concerns.  The proposed mitigation is discussed in Section 11.

   Spoofing scenarios and prevention mechanisms are discussed in
   Section 7.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Colitti, et al.          Expires 31 August 2023                 [Page 9]
Internet-Draft                  MultAddrr                  February 2023

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <https://www.rfc-editor.org/info/rfc7084>.

   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses",
              RFC 6620, DOI 10.17487/RFC6620, May 2012,
              <https://www.rfc-editor.org/info/rfc6620>.

   [RFC8168]  Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
              Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
              <https://www.rfc-editor.org/info/rfc8168>.

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

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
              <https://www.rfc-editor.org/info/rfc8273>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [RFC8987]  Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson,
              "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987,
              DOI 10.17487/RFC8987, February 2021,
              <https://www.rfc-editor.org/info/rfc8987>.

14.2.  Informative References

Colitti, et al.          Expires 31 August 2023                [Page 10]
Internet-Draft                  MultAddrr                  February 2023

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,
              <https://www.rfc-editor.org/info/rfc6583>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.

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

   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              <https://www.rfc-editor.org/info/rfc7513>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host Address Availability Recommendations", BCP 204,
              RFC 7934, DOI 10.17487/RFC7934, July 2016,
              <https://www.rfc-editor.org/info/rfc7934>.

   [I-D.linkova-v6ops-ipmaclimi]
              Linkova, J., "Minimizing Damage of Limiting Number of IPv6
              Addresses per Host", Work in Progress, Internet-Draft,
              draft-linkova-v6ops-ipmaclimi-00, 7 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-linkova-
              v6ops-ipmaclimi-00>.

   [I-D.dhcwg-dhc-rfc8415bis]
              Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
              Winters, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", Work in Progress, Internet-Draft, draft-dhcwg-
              dhc-rfc8415bis-00, 7 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-dhcwg-dhc-
              rfc8415bis-00>.

Colitti, et al.          Expires 31 August 2023                [Page 11]
Internet-Draft                  MultAddrr                  February 2023

Acknowledgements

   Thanks to Brian Carpenter, Gert Doering, Fernando Gont, Martin Hunek,
   Erik Kline, Pascal Thubert, Eduard Vasilenko, Timothy Winters for the
   discussions, the input and all contribution.

Contributors

Authors' Addresses

   Lorenzo Colitti
   Google, LLC
   Shibuya 3-21-3,
   Japan
   Email: lorenzo@google.com

   Jen Linkova (editor)
   Google
   1 Darling Island Rd
   Pyrmont NSW 2009
   Australia
   Email: furry13@gmail.com, furry@google.com

   Xiao Ma (editor)
   Google
   Shibuya 3-21-3,
   Japan
   Email: xiaom@google.com

Colitti, et al.          Expires 31 August 2023                [Page 12]