Internet DRAFT - draft-collink-v6ops-ent64pd
draft-collink-v6ops-ent64pd
v6ops Working Group L. Colitti
Internet-Draft Google, LLC
Intended status: Informational J. Linkova, Ed.
Expires: 5 October 2023 X. Ma, Ed.
Google
3 April 2023
Using DHCP-PD to Allocate Unique IPv6 Prefix per Host in Broadcast
Networks
draft-collink-v6ops-ent64pd-03
Abstract
This document discusses the IPv6 deployment scenario when individual
hosts connected to broadcast networks (like WiFi hotspots or
enterprise networks) are allocated unique prefixes 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 5 October 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 5 October 2023 [Page 1]
Internet-Draft MultAddrr April 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 6
6. DHCPv6-PD Server Considerations . . . . . . . . . . . . . . . 6
7. Antispoofing and SAVI Interaction . . . . . . . . . . . . . . 7
8. Migration Strategies and Co-existence with SLAAC Using Prefixes
From PIO . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Applicability and Limitations . . . . . . . . . . . . . . . . 9
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
13. Security Considerations . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 5 October 2023 [Page 2]
Internet-Draft MultAddrr April 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's been observed that networks do impose such
limits, likely in an attempt to protect the network resources and
prevent DoS attacks. The most common scenario of network-imposed
limitations is Neighbor Discovery (ND) proxy. Many enterprise-scale
wireless solutions implement ND proxy to reduce amount of broadcast
and multicast downstream (AP to clients) traffic. To perform ND
proxy a device usually maintains a table, containing IPv6 and MAC
addresses of connected clients. At least some implementations have
hardcoded limits on how many IPv6 addresses per a single MAC such a
table can contain. When the limit is exceeded the behaviour is
implementation-dependent. Some vendors just fail to install N+1
address to the table. Other delete the oldest entry for this MAC and
replace it with the new address. In any case the affected addresses
lose network connectivity without receiving any implict signal, with
traffic being silently dropped.
It would be beneficial for IPv6 deployments to address the above
mentioned scalability issues while still allowing hosts to have
multiple IPv6 addresses. One of the very promising approaches is
allocating an unique IPv6 prefix per host ([RFC8273]). The same
principle has been actively used in cellular IPv6 deployments
([RFC6459]). 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 prefix per host using DHCP-PD.
Colitti, et al. Expires 5 October 2023 [Page 3]
Internet-Draft MultAddrr April 2023
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:
* A host acts as DHCP-PD client and requests a prefix via DHCPv6-PD
by sending an IA_PD request.
* 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 the prefix from a larger pool allocated for the
given segment or the whole site.
* The allocated prefix 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 traffic to that prefix does not
trigger any ND packets.
* The host uses the delegated prefix to allocate addresses to its
interfaces, containers etc. For example, the device can include
the prefix into Router Advertisements sent to virtual systems or
to any other devices connected to its downstream interface.
4. Prefix Length Considerations
DHCPv6 prefix delegation supports delegating prefixes of any size.
However at the time of writing, the only prefix size that will allow
the host to use SLAAC is 64 bits (see also [RFC7421]). As a result
delegating a /64 prefix 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 a /64 allows hosts to extend the
network arbitrarily, similarily to using NAT in IPv4 but with full
support for end-to-end communication. Chosing longer prefixes would
require the host and any connected system to use some other form of
address assignment and therefore would drastically limit the
applicability of the proposed solution. The extensive analysis
provided in [RFC7421] is fully applicable to selecting the delegated
Colitti, et al. Expires 5 October 2023 [Page 4]
Internet-Draft MultAddrr April 2023
prefix in the proposed deployment model.
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.
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
Colitti, et al. Expires 5 October 2023 [Page 5]
Internet-Draft MultAddrr April 2023
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.
To ensure that routes to the delegated prefixes are preserved even if
a relay is rebooted or replaced, the operator MUST ensure that all
relays in the network infrastructure support DHCPv6 Bulk Leasequery
as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists
keeping active prefix delegations in persistent storage as an
alternative to DHCPv6 Bulk Leasequery, relying on persistent storage
has the following drawbacks:
* In a network with multiple relays, network state can change
significantly while the relay was rebooting (new prefixes
delegated, some prefixes expiring etc).
* Persistent storage might not be preserved if the router is
physically replaced.
5.3. Preventing Routing Loops
To prevent routing loops caused by traffic to unused addresses from
the delegated prefix the client MUST drop all packets to such
addresses (see the requirement WPD-5 in Section 4.2 of [RFC7084]).
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.
* The server MUST provide a prefix short enough for the client to
assign addresses to its interfaces and connected systems via
SLAAC.
Colitti, et al. Expires 5 October 2023 [Page 6]
Internet-Draft MultAddrr April 2023
* If the server receives the same SOLICIT message from the same
client multiple times through multiple relays, it MUST reply to
all of them with the same prefix(es). This ensures that all the
relays will correctly configure routes to the delegated prefixes.
* The server MUST 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.
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 prefixes 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
Colitti, et al. Expires 5 October 2023 [Page 7]
Internet-Draft MultAddrr April 2023
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 a unique prefix 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,
[I-D.collink-6man-pio-pflag] defines a new PIO flag, indicating that
DHCPv6-PD is preferred method of obtaining prefixes.
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 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
prefixes, there is no reason to advertise a common /64 assigned to
that segment in PIO with 'A' flag set. Therefore it is possible
to 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].
Colitti, et al. Expires 5 October 2023 [Page 8]
Internet-Draft MultAddrr April 2023
* 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.
* A dedicated prefix per host allows the network administrator to
create per-host security policies (ACLs) even if the host is using
temporary addresses. This mitigates one of the issues described
in [I-D.gont-opsec-ipv6-addressing].
* 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 a prefix allows the host to provide connectivity
to other hosts, like it is possible in IPv4 with NAT.
10. Applicability and Limitations
Delegating a unique prefix per host provides all the benefits of both
SLAAC and DHCPv6 address allocation, but at the cost of greater
address space usage. This design would substantially benefit some
networks (see Section 9), in which the addional cost of an additional
service (DHCPv6 prefix delegation) and allocating a larger amount of
address space can easily be justified. Examples of such networks
include but are not limited to:
* Large-scale networks where even 3-5 addresses per client might
introduce scalability issues.
* Networks with high number of virtual hosts, so physical endpoints
require multiple addresses.
* Managed networks where extensive troubleshooting, host traffic
logging or forensics might be required.
In smaller networks, such as home networks, with smaller address
space and lower number of clients, SLAAC is a better and simpler
option.
Colitti, et al. Expires 5 October 2023 [Page 9]
Internet-Draft MultAddrr April 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 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. This is
not a new issue as the same attack might be implemented in DHCPv4 or
DHCPv6 for IA_NA requests. To prevent a misbehaving client from
denying service to other clients, the DHCPv6 server or relay MUST
support limiting the number of prefixes delegated to a given host at
any given time.
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
Colitti, et al. Expires 5 October 2023 [Page 10]
Internet-Draft MultAddrr April 2023
[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>.
[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>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>.
[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>.
Colitti, et al. Expires 5 October 2023 [Page 11]
Internet-Draft MultAddrr April 2023
14.2. Informative References
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012,
<https://www.rfc-editor.org/info/rfc6459>.
[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.collink-6man-pio-pflag]
Colitti, L. and J. Linkova, "Signalling DHCPv6 Prefix
Delegation Availability to Hosts", Work in Progress,
Internet-Draft, draft-collink-6man-pio-pflag-00, 27 March
2023, <https://datatracker.ietf.org/doc/html/draft-
collink-6man-pio-pflag-00>.
Colitti, et al. Expires 5 October 2023 [Page 12]
Internet-Draft MultAddrr April 2023
[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>.
[I-D.gont-opsec-ipv6-addressing]
Gont, F. and G. Gont, "Implications of IPv6 Addressing on
Security Operations", Work in Progress, Internet-Draft,
draft-gont-opsec-ipv6-addressing-00, 2 February 2023,
<https://datatracker.ietf.org/doc/html/draft-gont-opsec-
ipv6-addressing-00>.
Acknowledgements
Thanks to Nick Buraglio, Brian Carpenter, Gert Doering, David Farmer,
Fernando Gont, Bob Hinden, Martin Hunek, Erik Kline, David Lamparter,
Andrew McGregor, Tomek Mrugalski, Pascal Thubert, Ole Troan, Eduard
Vasilenko, Timothy Winters for the discussions, their 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 5 October 2023 [Page 13]
