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

v6ops Working Group                                           L. Colitti
Internet-Draft                                               Google, LLC
Intended status: Best Current Practice                   J. Linkova, Ed.
Expires: 14 May 2023                                              Google
                                                        10 November 2022

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

Abstract

   This document discusses 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 14 May 2023.

Copyright Notice

   Copyright (c) 2022 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 & Linkova          Expires 14 May 2023                  [Page 1]
Internet-Draft                  MultAddrr                  November 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Migration Strategies and Co-existence with SLAAC  . . . . . .   4
   5.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Applicability and Limitations . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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 stable global address and one privacy
   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 thenetwork is multihomed and uses two different prefixes,
   or during graceful renumbering (when the old prefix is deprecated),
   of if an enterprise uses ULAs, the number of global addresses can
   easily double, brining the total number of addresses to 7.  Devices
   running containers/namespaces would need even more addresses per
   physical host.  on one hand this could be considered as a significant
   advantange of IPv6.  On one hand, however, multiple addresses are
   seen as a drawback for the following reasons:

   *  Increased number of addresses introduces scalability issues on the
      network infrastructure.  Network devices need maintain various
      types of tables/hashes (Neighbor Cache on first-hop routers,
      Neighbor Discovery Proxy caches on L2 devices etc).  On VXLAN
      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.

Colitti & Linkova          Expires 14 May 2023                  [Page 2]
Internet-Draft                  MultAddrr                  November 2022

   *  If an infrastrcuture 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 number of IPv6 addresses a host can
   have.  However it seems inevitable that some limits might need to be
   imposed by the network in attempt to protect the network resources
   and prevent DoS attacks (see draft-linkova-v6ops-ipmaclimi).

   Therefore it would be beneficial for IPv6 deployments to address the
   abovementioned 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.  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 using the same /64 assigned
   to that segment:

   *  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 send 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 ifrastructure devices that prefix is
      considered off-link, so no traffic to that prefix does not trigger
      any ND packets.

Colitti & Linkova          Expires 14 May 2023                  [Page 3]
Internet-Draft                  MultAddrr                  November 2022

   *  The host uses /64 to allocate addresses to its interfaces,
      containters etc.

   Using /64 allows the host to assign addresses to virtual instances
   using SLAAC.

4.  Migration Strategies and Co-existence with SLAAC

   There are scenarios when it might be undesirable for a host to
   request an unique prefix.  As the main goal of this approach is to
   address scalability issues, the solution is aimed for large networks
   (enterprises, conference hotspots etc).  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.  Therefore it's desirable for the network to indicate the
   support of the proposed mechanism.  As it's a -00 draft, we do not
   have details for such mechanism yet, just a few rough ideas:

   *  A new RA (or, better, PIO flag) to indicate "don't use this PIO
      for SLAAC, ask for /64 via PD".  Legacy devices would not
      recognize it and contibue to use that /64 for SLAAC.

   *  Some flags/options in DHCPv6 used like Option 108 in DHCPv4 - the
      client sends it and only accepts /64 if the server returns that
      option back.  It would prevent /64 to be allocated for the clients
      in home networks, unless the CPE is explicitly configured to
      support this new mechanism.

   *  Some other crazy ideas?

5.  Benefits

   The proposed solution provides the following benefits:

   *  The network needs 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 support this mode of operation, it is possible to
      remove global /64 prefix from the interface completely, reducing
      the attack surface for Neighbor Discovery attacks described in
      RFC6583.

Colitti & Linkova          Expires 14 May 2023                  [Page 4]
Internet-Draft                  MultAddrr                  November 2022

   *  DHCP-PD logs and first-hop routers roting tables provide complete
      information on IPv6 to MAC mapping, which can be used for
      forensics and troiubleshooting.  Such information is much less
      dynamic that 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 are easier to diagnoze and mitigate.

6.  Applicability and Limitations

   What's unclear at this point (AI for Jen: sort this out):

   *  How to deal with multiple routers in active/active scernario?
      Need to test if they are capable of advertize DHCP-PD routes to
      its neighbors.  What happens if the first-hop router fails and
      switchover occurs?

   *  Interaction with SAVI?

   *  [Do math for how many prefixes/addresses needed and if we are
      going to run out of addresses again ;)]

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

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

9.  References

9.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 & Linkova          Expires 14 May 2023                  [Page 5]
Internet-Draft                  MultAddrr                  November 2022

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

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

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

9.2.  Informative References

Acknowledgements

   Thanks to Erik Kline and 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

Colitti & Linkova          Expires 14 May 2023                  [Page 6]