draft-ietf-dhc-topo-conf-09.txt   rfc7969.txt 
Network Working Group T. Lemon Internet Engineering Task Force (IETF) T. Lemon
Internet-Draft Nominum, Inc. Request for Comments: 7969 Nominum, Inc.
Intended status: Informational T. Mrugalski Category: Informational T. Mrugalski
Expires: January 9, 2017 ISC ISSN: 2070-1721 ISC
July 8, 2016 October 2016
Customizing DHCP Configuration on the Basis of Network Topology Customizing DHCP Configuration on the Basis of Network Topology
draft-ietf-dhc-topo-conf-09
Abstract Abstract
DHCP servers have evolved over the years to provide significant DHCP servers have evolved over the years to provide significant
functionality beyond that which is described in the DHCP base functionality beyond that described in the DHCP base specifications.
specifications. One aspect of this functionality is support for One aspect of this functionality is support for context-specific
context-specific configuration information. This memo describes some configuration information. This memo describes some such features
such features and explains their operation. and explains their operation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 9, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7969.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Client's Location by DHCP Servers . . . . . . . . 3 3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7 3.1. DHCPv4-Specific Behavior . . . . . . . . . . . . . . . . 7
3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7 3.2. DHCPv6-Specific Behavior . . . . . . . . . . . . . . . . 7
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 10
5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 11 5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 12
6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 11 6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 12
7. Regional Configuration Example . . . . . . . . . . . . . . . 12 7. Regional Configuration Example . . . . . . . . . . . . . . . 13
8. Multiple subnets on the same link . . . . . . . . . . . . . . 14 8. Multiple Subnets on the Same Link . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications
describe how addresses can be allocated to clients based on network describe how addresses can be allocated to clients based on network
topology information provided by the DHCP relay infrastructure. topology information provided by the DHCP relay infrastructure.
Address allocation decisions are integral to the allocation of Address allocation decisions are integral to the allocation of
addresses and prefixes in DHCP. addresses and prefixes in DHCP.
The DHCP protocol also describes mechanisms for provisioning devices The DHCP protocol also describes mechanisms for provisioning devices
with additional configuration information; for example, DNS [RFC1034] with additional configuration information, for example, DNS [RFC1034]
server addresses, default DNS search domains, and similar server addresses, default DNS search domains, and similar
information. information.
Although it was the intent of the authors of these specifications Although it was the intent of the authors of these specifications
that DHCP servers would provision devices with configuration that DHCP servers would provision devices with configuration
information appropriate to each device's location on the network, information appropriate to each device's location on the network,
this practice was never documented, much less described in detail. this practice was never documented, much less described in detail.
Existing DHCP server implementations do in fact provide such Existing DHCP server implementations do in fact provide such
capabilities; the goal of this document is to describe those capabilities; the goal of this document is to describe those
capabilities for the benefit both of operators and of protocol capabilities for the benefit of both operators and protocol designers
designers who may wish to use DHCP as a means for configuring their who may wish to use DHCP as a means for configuring their own
own services, but may not be aware of the capabilities provided by services but may not be aware of the capabilities provided by most
most modern DHCP servers. modern DHCP servers.
2. Terminology 2. Terminology
o CPE device: Customer Premise Equipment device. Typically a router o CPE device: Customer Premise Equipment device. Typically a router
belonging to the customer that connects directly to the provider belonging to the customer that connects directly to the provider
link. link.
o DHCP, DHCPv4, and DHCPv6. DHCP refers to the Dynamic Host o DHCP, DHCPv4, and DHCPv6: DHCP refers to the Dynamic Host
Configuration Protocol in general and applies to both DHCPv4 and Configuration Protocol in general and applies to both DHCPv4 and
DHCPv6. The terms DHCPv4 and DHCPv6 are used in contexts where it DHCPv6. The terms DHCPv4 and DHCPv6 are used in contexts where it
is necessary to avoid ambiguity and explain differences. is necessary to avoid ambiguity and explain differences.
o PE router: Provider Edge router. The provider router closest to o PE router: Provider Edge router. The provider router closest to
the customer. the customer.
o Routable IP address: an IP address with a scope of use wider than o Routable IP address: An IP address with a scope of use wider than
the local link. the local link.
o Shared subnet: a case where two or more subnets of the same o Shared subnet: A case where two or more subnets of the same
protocol family are available on the same link. 'Shared subnet' protocol family are available on the same link. 'Shared subnet'
terminology is typically used in Unix environments. It is terminology is typically used in Unix environments. It is
typically called 'multinet' in Windows environment. The typically called 'multinet' in the Windows environment. The
administrative configuration inside a Microsoft DHCP server is administrative configuration inside a Microsoft DHCP server is
called 'DHCP Superscope'. called 'DHCP Superscope'.
o Link or local link: A layer 2 network link, as defined in
Section 1.2 of [RFC3297].
o Link subset: A portion of a link containing a subset of all the
connection points on that link, which may be used to finely
determine the physical location of a set of clients or may be used
to determine topology to a finer degree of detail than the set of
all locations at which that particular link is available. The
smallest link subset is a single link attachment point, for
example, a port on a layer 2 switch.
3. Identifying Client's Location by DHCP Servers 3. Identifying Client's Location by DHCP Servers
Figure 1 illustrates a small hierarchy of network links with Link D Figure 1 illustrates a small hierarchy of network links with Link D
serving as a backbone to which the DHCP server is attached. serving as a backbone to which the DHCP server is attached.
Figure 2 illustrates a more complex case. Although some of its Figure 2 illustrates a more complex case. Although some of its
aspects are unlikely to be seen in actual production networks, they aspects are unlikely to be seen in actual production networks, they
are beneficial for explaining finer aspects of the DHCP protocols. are beneficial for explaining finer aspects of the DHCP protocols.
Note that some nodes act as routers (which forward all IPv6 traffic) Note that some nodes act as routers (which forward all IP traffic)
and some are relay agents (i.e. run DHCPv6 specific software that and some are relay agents (i.e., they run DHCP-specific software that
forwards only DHCPv6 traffic). forwards only DHCP traffic).
Link A Link B Link A Link B
|===+===========| |===========+======| |===+===========| |===========+======|
| | | |
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| relay | | relay | | relay | | relay |
| A | | B | | A | | B |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
skipping to change at page 4, line 46 skipping to change at page 4, line 46
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| relay | | relay | | relay | | relay |
| C | | D | | C | | D |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
| | | |
|===+===========| |===========+======| |===+===========| |===========+======|
Link F Link G Link F Link G
Figure 1: A simple network with a small hierarchy of links Figure 1: A Simple Network with a Small Hierarchy of Links
Link A Link B Link H Link A Link B Link H
|===+==========| |=========+======| |======+======| |===+==========| |=========+======| |======+======|
| | | | | |
| | | | | |
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+
| relay | | relay | | relay | | relay | | relay | | relay |
| A | | B | | G | | A | | B | | G |
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+
| | | | | |
| Link C | | Link J | Link C | | Link J
skipping to change at page 5, line 45 skipping to change at page 5, line 45
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| relay | | relay | | relay | | relay |
| C | | D | | C | | D |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
| | | |
|===+===========| |===========+======| |===+===========| |===========+======|
Link F Link G Link F Link G
Figure 2: Complex network Figure 2: Complex Network
Those diagrams allow us to represent a variety of different network These diagrams allow us to represent a variety of different network
configurations and illustrate how existing DHCP servers can provide configurations and illustrate how existing DHCP servers can provide
configuration information customized to the particular location from configuration information customized to the particular location from
which a client is making its request. which a client is making its request.
It is important to understand the background of how DHCP works when It is important to understand the background of how DHCP works when
considering those diagrams. It is assumed that the DHCP clients may considering those diagrams. It is assumed that the DHCP clients may
not have routable IP addresses when they are attempting to obtain not have routable IP addresses when they are attempting to obtain
configuration information. configuration information.
The reason for making this assumption is that one of the functions of The reason for making this assumption is that one of the functions of
DHCP is to bootstrap the DHCP client's IP address configuration; if DHCP is to bootstrap the DHCP client's IP address configuration. If
the client does not yet have an IP address configured, it cannot the client does not yet have an IP address configured, it cannot
route packets to an off-link DHCP server, therefore some kind of route packets to an off-link DHCP server; therefore, some kind of
relay mechanism is required. relay mechanism is required.
The details of how packet delivery between clients and servers works The details of how packet delivery between clients and servers works
are different between DHCPv4 and DHCPv6, but the essence is the same: are different between DHCPv4 and DHCPv6, but the essence is the same:
whether or not the client actually has an IP configuration, it whether or not the client actually has an IP configuration, it
generally communicates with the DHCP server by sending its requests generally communicates with the DHCP server by sending its requests
to a DHCP relay agent on the local link; this relay agent, which has to a DHCP relay agent on the local link; this relay agent, which has
a routable IP address, then forwards the DHCP requests to the DHCP a routable IP address, then forwards the DHCP requests to the DHCP
server (directly or via other relays). In later stages of the server (directly or via other relays). In later stages of the
configuration when the client has acquired an address and certain configuration, when the client has acquired an address and certain
conditions are met, it is possible for the client to send packets conditions are met, it is possible for the client to send packets
directly to the server, thus bypassing the relays. The conditions directly to the server, thus bypassing the relays. The conditions
for such behavior are different for DHCPv4 and DHCPv6 and are for such behavior are different for DHCPv4 and DHCPv6 and are
discussed in sections Section 3.1 and Section 3.2. discussed in Sections 3.1 and 3.2.
To determine the client's point of attachment and link specific To determine the client's point of attachment and link-specific
configuration, the server typically uses the client facing IP address configuration, the server typically uses the client-facing IP address
of the relay agent. In some cases the server may use the routable IP of the relay agent. In some cases, the server may use the routable
address of the client, if the client has the routable IP address IP address of the client if the client has the routable IP address
assigned to its interface and it is transmitted in the DHCP message. assigned to its interface and it is transmitted in the DHCP message.
The server is then able to determine the client's point of attachment The server is then able to determine the client's point of attachment
and select appropriate subnet- or link-specific configuration. and select the appropriate subnet- or link-specific configuration.
Sometimes it is useful for the relay agents to provide additional Sometimes it is useful for the relay agents to provide additional
information about the topology. A number of extensions have been information about the topology. A number of extensions have been
defined for this purpose. The specifics are different, but the core defined for this purpose. The specifics are different, but the core
principle remains the same: the relay agent knows exactly where the principle remains the same: the relay agent knows exactly where the
original request came from, so it provides an identifier that will original request came from, so it provides an identifier that will
help the server to choose appropriate address pool and configuration help the server to choose appropriate address pool and configuration
parameters. Examples of such options are mentioned in the following parameters. Examples of such options are mentioned in the following
sections. sections.
Finally, clients may be connected to the same link as the server, so Finally, clients may be connected to the same link as the server, so
no relay agents are required. In such cases, the DHCPv4 server no relay agents are required. In such cases, the DHCPv4 server
typically uses the IPv4 address assigned to the network interface typically uses the IPv4 address assigned to the network interface
over which the transmission was received to select an appropriate over which the transmission was received to select an appropriate
subnet. This is more complicated for DHCPv6, as the DHCPv6 server is subnet. This is more complicated for DHCPv6, as the DHCPv6 server is
not required to have any globally unique addresses. In such cases, not required to have any globally unique addresses. In such cases,
additional configuration information may need to be required. Some additional configuration information may need to be required. Some
servers allow indicating that a given subnet is directly reachable servers allow indicating that a given subnet is directly reachable
over a specific local network interface. over a specific local network interface.
3.1. DHCPv4 Specific Behavior 3.1. DHCPv4-Specific Behavior
In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4 In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4
address, the message is unicast to the DHCPv4 server rather than address, the message is unicast to the DHCPv4 server rather than
going through a relay agent. Examples of such transmissions are going through a relay agent. Examples of such transmissions are
renewal (DHCPREQUEST) and address release (DHCPRELEASE). renewal (DHCPREQUEST) and address release (DHCPRELEASE).
The relay agent that receives client's message sets giaddr field to The relay agent that receives the client's message sets the giaddr
the address of the network interface the message was received on. field to the address of the network interface the message was
The relay agent may insert a relay agent option [RFC3046]. received on. The relay agent may insert a relay agent option
[RFC3046].
There are several options defined that are useful for subnet There are several options defined that are useful for subnet
selection in DHCPv4. [RFC3527] defines the Link Selection sub-option selection in DHCPv4. [RFC3527] defines the Link Selection sub-option
that is inserted by a relay agent. This option is particularly that is inserted by a relay agent. This option is particularly
useful when the relay agent needs to specify the subnet/link on which useful when the relay agent needs to specify the subnet/link on which
a DHCPv4 client resides, which is different from an IP address that a DHCPv4 client resides, which is different from an IP address that
can be used to communicate with the relay agent. The Virtual Subnet can be used to communicate with the relay agent. The Virtual Subnet
Selection sub-option, specified in [RFC6607], can also be added by a Selection (VSS) sub-option, specified in [RFC6607], can also be added
relay agent to specify information in a VPN environment. In certain by a relay agent to specify information in a VPN environment. In
cases, it is useful for the client itself to specify the Virtual certain cases, it is useful for the client itself to specify the
Subnet Selection option, e.g. when there are no relay agents involved Virtual Subnet Selection option, e.g., when there are no relay agents
during the VPN set up process. involved during the VPN setup process.
Another option that may influence the subnet selection is the IPv4 Another option that may influence the subnet selection is the IPv4
Subnet Selection Option, defined in [RFC3011], which allows the Subnet Selection option, defined in [RFC3011], which allows the
client to explicitly request allocation from a given subnet. client to explicitly request allocation from a given subnet.
3.2. DHCPv6 Specific Behavior 3.2. DHCPv6-Specific Behavior
In DHCPv6 unicast communication is possible in case where the server In DHCPv6, unicast communication is possible in cases where the
is configured with a Server Unicast option (see Section 22.12 in server is configured with a Server Unicast option (see Section 22.12
[RFC3315]) and clients are able to take advantage of it. In such in [RFC3315]) and clients are able to take advantage of it. In such
cases, once a client is assigned a, presumably global, address, it is cases, once a client is assigned a (presumably global) address, it is
able to contact the server directly, bypassing any relays. It should able to contact the server directly, bypassing any relays. It should
be noted that such a mode is completely controllable by be noted that such a mode is completely controllable by
administrators in DHCPv6. (They may simply choose to not configure administrators in DHCPv6. (They may simply choose to not configure
server unicast option, thus forcing clients to send their messages the Server Unicast option, thus forcing clients to always send their
always via relay agents in every case). messages via relay agents in every case).
In the DHCPv6 protocol, there are two core mechanisms defined in The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow
[RFC3315] that allow a server to distinguish which link the relay a server to distinguish which link the relay agent is connected to.
agent is connected to. The first mechanism is the link-address field The first mechanism is the link-address field in the Relay-forward
in the Relay-forward and Relay-reply messages. Somewhat contrary to and Relay-reply messages. The link-address field uniquely identifies
its name, relay agents insert in the link-address field an address the link and should not be mistaken for a link-local address. In
that is typically global and can be used to uniquely identify the normal circumstances, this is the solution that is easiest to
link on which the client is located. In normal circumstances this is maintain, as existing address assignments can be used and no
the solution that is easiest to maintain, as existing address additional administrative actions (like assigning dedicated
assignments can be used and no additional administrative actions identifiers for each relay agent, making sure they are unique, and
(like assigning dedicated identifiers for each relay agent, making maintaining a list of such identifiers) are needed. It requires,
sure they are unique and maintaining a list of such identifiers) are however, for the relay agent to have an address with a scope larger
needed. It requires, however, for the relay agent to have an address than link-local configured on its client-facing interface.
with a scope larger than link-local configured on its client-facing
interface.
The second mechanism uses Interface-Id option (see Section 22.18 of The second mechanism uses an Interface-ID option (see Section 22.18
[RFC3315]) inserted by the relay agent, which identifies the link of [RFC3315]) inserted by the relay agent, which identifies the link
that the client is connected to. This mechanism may be used when the that the client is connected to. This mechanism may be used when the
relay agent does not have a globally unique address or ULA [RFC4193] relay agent does not have a globally unique address or Unique Local
configured on its client-facing interface, thus making the first Address (ULA) [RFC4193] configured on its client-facing interface,
mechanism not feasible. If the interface-id is unique within an thus making the first mechanism not feasible. If the interface-id is
administrative domain, the interface-id value may be used to select unique within an administrative domain, the interface-id value may be
the appropriate subnet. As there is no guarantee for the uniqueness used to select the appropriate subnet. As there is no guarantee for
([RFC3315] only mandates the interface-id to be unique within a the uniqueness ([RFC3315] only mandates the interface-id to be unique
single relay agent context), it is up to the administrator to check within a single relay agent context), it is up to the administrator
whether the relay agents deployed use unique interface-id values. If to check whether the relay agents deployed use unique interface-id
the interface-id values are not unique, the Interface-id option values. If the interface-id values are not unique, the Interface-ID
cannot be used to determine the client's point of attachment. option cannot be used to determine the client's point of attachment.
It should be noted that Relay-forward and Relay-reply messages are It should be noted that Relay-forward and Relay-reply messages are
exchanged between relays and servers only. Clients are never exposed exchanged between relays and servers only. Clients are never exposed
to those messages. Also, servers never receive Relay-reply messages. to those messages. Also, servers never receive Relay-reply messages.
Relay agents must be able to process both Relay-forward (sending Relay agents must be able to process both Relay-forward (sending an
already relayed message further towards the server, when there is already relayed message further towards the server when there is more
more than one relay agent in a chain) and Relay-reply (when sending than one relay agent in a chain) and Relay-reply (sending back the
back the response towards the client, when there is more than one response towards the client when there is more than one relay agent
relay agent in a chain). in a chain).
For completeness, we also mention an uncommon, but valid case, where For completeness, we also mention an uncommon but valid case where
relay agents use a link-local address in the link-address field in relay agents use a link-local address in the link-address field in
relayed Relay-forward messages. This may happen if the relay agent relayed Relay-forward messages. This may happen if the relay agent
doesn't have any address with a larger scope on the interface doesn't have any address with a larger scope on the interface
connected to that specific link. Even though link-local addresses connected to that specific link. Even though link-local addresses
cannot be automatically used to associate relay agent with a given cannot be automatically used to associate the relay agent with a
link, with additional configuration information the server may still given link, with additional configuration information, the server may
be able to select the proper link. That requires the DHCP server still be able to select the proper link.
software to be able to specify relay agent link-address associated
with each link or a feature similar to 'shared subnets' (see
Section 8). Both may or may not be supported by the server software.
Network administrator has to manually configure additional
information that a given subnet uses a relay agent with link-address
X. Alternatively, if the relay agent uses link address X and relays
messages from a subnet A, an administrator can configure that subnet
A is a shared subnet with a very small X/128 subnet. That is not a
recommended configuration, but in cases where it is impossible for
relay agents to get an address from the subnet they are relaying
from, it may be a viable solution.
DHCPv6 also has support for more finely grained link identification, This requires that the DHCP server has a way of associating a
using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this particular link-local address with a particular link. The network
case, the link-address field is set to unspecified address (::), but administrator can then explicitly configure the DHCP server to
the DHCPv6 server also receives an Interface-Id option from the relay recognize that the particular link-address field in a relay message
agent that can be used to more precisely identify the client's refers to that link.
There are two ways that this can work. One is that the DHCP server
can provide a mechanism that explicitly associates the link-local
address with a link. In this case, the network administrator simply
determines the link-local address of the relay agent on a particular
link, which we are presuming to be stable, and configures an
association between that address and the link.
If the DHCP server doesn't explicitly provide such a mechanism, it
may still provide a "shared subnet" mechanism (see Section 8). If it
does, the shared subnet mechanism can be used to explicitly associate
a link-local address with a link. To do this, the network
administrator creates a shared subnet association for the link, if
one does not already exist. The network administrator then
configures a /128 subnet that contains just the link-local address of
the relay agent. The administrator then adds this new /128 to the
shared subnet. Now, when a DHCP message comes in with that link-
layer address in the link-address field, the correct shared network
will be selected.
DHCPv6 also has support for more finely grained link identification
using Lightweight DHCPv6 Relay Agents (LDRAs) [RFC6221]. In this
case, the link-address field is set to an unspecified address (::),
but the DHCPv6 server also receives an Interface-ID option from the
relay agent that can be used to more precisely identify the client's
location on the network. It is possible to mix LDRA and regular location on the network. It is possible to mix LDRA and regular
relay agents in the same network. See Sections 7.2 and 7.3 in relay agents in the same network. See Sections 7.2 and 7.3 in
[RFC6221] for detailed examples. [RFC6221] for detailed examples.
What this means in practice is that the DHCP server in all cases has What this means in practice is that the DHCP server has sufficient
sufficient information to pinpoint, at the very least, the layer 3 information in all cases to pinpoint the link to which the client is
link to which the client is connected, and in some cases which layer connected. In some cases, it may additionally be possible to
2 link the client is connected to, when the layer 3 link is pinpoint the particular link subset to which the client is connected.
aggregated out of multiple layer 2 links.
In all cases, then, the DHCPv6 server will have a link-identifying IP In all cases, then, the DHCPv6 server will have a link-identifying IP
address, and in some cases it may also have a link-specific address, and in some cases, it may also have a link-specific
identifier (e.g. Interface-Id Option or Link Address Option defined identifier (e.g., the Interface-ID option or the Link Address option
in Section 5 of [RFC6977]). It should be noted that the link- defined in Section 5 of [RFC6977]). It should be noted that the
specific identifier is unique only within the scope of the link- link-specific identifier is unique only within the scope of the link-
identifying IP address. For example, link-specific identifier of identifying IP address. For example, the link-specific identifier of
"eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is "eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is
distinct from a "eth0" identifier used by a different relay agent distinct from an "eth0" identifier used by a different relay agent
with address 2001:db8::2. with address 2001:db8::2.
It is also possible for link-specific identifiers to be nested, so It is also possible for link-specific identifiers to be nested so
that the actual identifier that identifies the link is an aggregate that the actual identifier that identifies the specific link subset
of two or more link-specific identifiers sent by a set of LDRAs in a is an aggregate of two or more identifiers sent by a set of LDRAs in
chain; in general this functions exactly as if a single identifier a chain; in general, this functions exactly as if a single identifier
were received from a single LDRA, so we do not treat it specially in were received from a single LDRA, so we do not treat it specially in
the discussion below, but sites that use chained LDRA configurations the discussion below, but sites that use chained LDRA configurations
will need to be aware of this when configuring their DHCPv6 servers. will need to be aware of this when configuring their DHCPv6 servers.
The Virtual Subnet Selection Options, present in DHCPv4, are also The Virtual Subnet Selection options, present in DHCPv4, are also
defined for DHCPv6. The use case is the same as in DHCPv4: the relay defined for DHCPv6. The use case is the same as in DHCPv4: the relay
agent inserts VSS options that can help the server to select the agent inserts VSS options that can help the server to select the
appropriate subnet with its address pool and associated configuration appropriate subnet with its address pool and associated configuration
options. See [RFC6607] for details. options. See [RFC6607] for details.
4. Simple Subnetted Network 4. Simple Subnetted Network
Consider Figure 1 in the context of a simple subnetted network. In Consider Figure 1 in the context of a simple subnetted network. In
this network, there are four leaf subnets: links A, B, F and G, on this network, there are four leaf subnets on which DHCP clients will
which DHCP clients will be configured. Relays A, B, C and D in this be configured: Links A, B, F, and G. Relays A, B, C, and D in this
example are represented in the diagram as IP routers with an embedded example are represented in the diagram as IP routers with an embedded
relay function, because this is a very typical configuration, but the relay function, because this is a very typical configuration, but the
relay function can also be provided in a separate node on each link. relay function can also be provided in a separate node on each link.
In a simple network like this, there may be no need for link-specific In a simple network like this, there may be no need for link-specific
configuration in DHCPv6, since local routing information is delivered configuration in DHCPv6, since local routing information is delivered
through router advertisements. However, in IPv4, it is very typical through router advertisements. However, in IPv4, it is very typical
to configure the default route using DHCP; in this case, the default to configure the default route using DHCP; in this case, the default
route will be different on each link. In order to accomplish this, route will be different on each link. In order to accomplish this,
the DHCP server will need link-specific configuration for the default the DHCP server will need link-specific configuration for the default
route. route.
To illustrate, we will use an example from a hypothetical DHCP server To illustrate, we will use an example from a hypothetical DHCP server
that uses a simple JSON notation [RFC7159] for configuration. that uses a simple JSON notation [RFC7159] for configuration.
Although we know of no DHCP server that uses this specific syntax, Although we know of no DHCP server that uses this specific syntax,
most modern DHCP server provides similar functionality. most modern DHCP servers provide similar functionality.
{ {
"prefixes": { "prefixes": {
"192.0.2.0/26": { "192.0.2.0/26": {
"options": { "options": {
"routers": ["192.0.2.1"] "routers": ["192.0.2.1"]
}, },
"on-link": ["A"] "on-link": ["A"]
}, },
"192.0.2.64/26": { "192.0.2.64/26": {
skipping to change at page 11, line 18 skipping to change at page 11, line 49
a routers option. This option contains a list of values; each list a routers option. This option contains a list of values; each list
only has one value, and that value is the IP address of the router only has one value, and that value is the IP address of the router
specific to the prefix. specific to the prefix.
When the DHCP server receives a request, it searches the list of When the DHCP server receives a request, it searches the list of
prefixes for one that encloses the link-identifying IP address prefixes for one that encloses the link-identifying IP address
provided by the client or relay agent. The DHCP server then examines provided by the client or relay agent. The DHCP server then examines
the options list associated with that prefix and returns those the options list associated with that prefix and returns those
options to the client. options to the client.
So for example a client connected to link A in the example would have So, for example, a client connected to Link A in the example would
a link-identifying IP address within the 192.0.2.0/26 prefix, so the have a link-identifying IP address within the 192.0.2.0/26 prefix, so
DHCP server would match it to that prefix. Based on the the DHCP server would match it to that prefix. Based on the
configuration, the DHCP server would then return a routers option configuration, the DHCP server would then return a routers option
containing a single IP address: 192.0.2.1. A client on link F would containing a single IP address: 192.0.2.1. A client on Link F would
have a link-identifying address in the 192.0.2.128/26 prefix, and have a link-identifying address in the 192.0.2.128/26 prefix and
would receive a routers option containing the IP address 192.0.2.129. would receive a routers option containing the IP address 192.0.2.129.
5. Relay Agent Running on a Host 5. Relay Agent Running on a Host
A relay agent is DHCP software that may be run on any IP node. A relay agent is DHCP software that may be run on any IP node.
Although it is typically run on a router, this is by no means Although it is typically run on a router, this is by no means
required by the DHCP protocol. The relay agent is simply a service required by the DHCP protocol. The relay agent is simply a service
that operates on a link, receiving link-local multicasts (IPv6) or that operates on a link, receiving link-local multicasts (IPv6) or
broadcasts (IPv4) and relaying them, using IP routing, to a DHCP broadcasts (IPv4) and relaying them, using IP routing, to a DHCP
server. As long as the relay has an IP address on the link, and a server. As long as the relay has an IP address on the link and a
default route or more specific route through which it can reach a default route or a more specific route through which it can reach a
DHCP server, it need not be a router, or even have multiple DHCP server, it need not be a router or even have multiple
interfaces. interfaces.
A relay agent can be run on a host connected to two links. That case A relay agent can be run on a host connected to two links. That case
is presented in Figure 2. There is router B that is connected to is presented in Figure 2. There is router B that is connected to
links D and E. At the same time there is also a host that is Links D and E. At the same time, there is also a host that is
connected to the same links. The relay agent software is running on connected to the same links. The relay agent software is running on
that host. That is uncommon, but a valid configuration. that host. That is uncommon but is a valid configuration.
6. Cascaded Relays 6. Cascaded Relays
Let's observe another case, shown in Figure 2. Note that in this Let's observe another case, shown in Figure 2. Note that in this
configuration, the clients connected to link G will send their configuration, the clients connected to Link G will send their
requests to relay D which will forward its packets directly to the requests to relay D, which will forward its packets directly to the
DHCP server. That is typical, but not the only possible DHCP server. That is typical but not the only possible
configuration. It is possible to configure relay agent D to forward configuration. It is possible to configure relay agent D to forward
client messages to relay E which in turn will send it to the DHCP client messages to relay E, which in turn will send them to the DHCP
server. This configuration is sometimes referred to as cascaded server. This configuration is sometimes referred to as "cascaded
relay agents. relay agents".
Note that the relaying mechanism works differently in DHCPv4 and in Note that the relaying mechanism works differently in DHCPv4 and in
DHCPv6. In DHCPv4 only the first relay is able to set the giaddr DHCPv6. In DHCPv4, only the first relay is able to set the giaddr
field in the DHCPv4 packet. Any following relays that receive that field in the DHCPv4 packet. Any following relays that receive that
packet will not change it as the server needs giaddr information from packet will not change it as the server needs giaddr information from
the first relay (i.e. the closest to the client). The server will the first relay (i.e., the closest to the client). The server will
send the response back to the giaddr address, which is the address of send the response back to the giaddr address, which is the address of
the first relay agent that saw the client's message. That means that the first relay agent that saw the client's message. That means that
the client messages travel on a different path than the server's the client messages travel on a different path than the server's
responses. A message from client connected to link G will travel via responses. A message from a client connected to Link G will pass
relay D, relay E and to the server. A response message will be sent through relay D, then through relay E, to reach the server. A
from the server to relay D via router B, and relay D will send it to response message will be sent from the server to relay D via router
the client on link G. B, and relay D will send it to the client on Link G.
Relaying in DHCPv6 is more structured. Each relay agent encapsulates Relaying in DHCPv6 is more structured. Each relay agent encapsulates
a packet that is destined to the server and sends it towards the a packet that is destined to the server and sends it towards the
server. Depending on the configuration, that can be a server's server. Depending on the configuration, that can be a server's
unicast address, a multicast address or next relay agent address. unicast address, a multicast address, or the next relay agent
The next relay repeats the encapsulation process. Although the address. The next relay repeats the encapsulation process. Although
resulting packet is more complex (may have up to 32 levels of the resulting packet is more complex (may have up to 32 levels of
encapsulation if the packet traveled through 32 relays), every relay encapsulation if the packet traveled through 32 relays), every relay
may insert its own options and it is clear which relay agent inserted may insert its own options, and it is clear which relay agent
which option. inserted which option.
7. Regional Configuration Example 7. Regional Configuration Example
In the Figure 2 example, link C is a regional backbone for an ISP. In the Figure 2 example, Link C is a regional backbone for an ISP.
Link E is also a regional backbone for that ISP. Relays A, B, C and Link E is also a regional backbone for that ISP. Relays A, B, C, and
D are PE routers, and Links A, B, F and G are actually link D are PE routers, and Links A, B, F, and G are actually link
aggregators with individual layer 2 circuits to each customer--for aggregators with individual layer 2 circuits to each customer -- for
example, the relays might be DSLAMs or cable head-end systems. At example, the relays might be Digital Subscriber Line Access
each customer site we assume there is a single CPE device attached to Multiplexers (DSLAMs) or cable head-end systems. At each customer
the link. site, we assume there is a single CPE device attached to the link.
We further assume that links A, B, F and G are each addressed by a We further assume that Links A, B, F, and G are each addressed by a
single prefix, although it would be equally valid for each CPE device single prefix, although it would be equally valid for each CPE device
to be numbered on a separate prefix. to be numbered on a separate prefix.
In a real-world deployment, there would likely be many more than two In a real-world deployment, there would likely be many more than two
PE routers connected to each regional backbone; we have kept the PE routers connected to each regional backbone; we have kept the
number small for simplicity. number small for simplicity.
In the example presented in Figure 4, the goal is to configure all In the example presented in Figure 4, the goal is to configure all
the devices within a region with server addresses local to that the devices within a region with server addresses local to that
region, so that service traffic does not have to be routed between region, so that service traffic does not have to be routed between
regions unnecessarily. regions unnecessarily.
{ {
"prefixes": { "prefixes": {
"2001:db8::/40": { "2001:db8::/40": {
"on-link": ["A"] "on-link": ["A"]
}, },
"2001:db8:100::/40": { "2001:db8:100::/40": {
"on-link": ["B"] "on-link": ["B"]
}, },
"2001:db8:200::/40": { "2001:db8:200::/40": {
"on-link": ["F"] "on-link": ["F"]
}, },
"2001:db8:300::/40": { "2001:db8:300::/40": {
"on-link": ["G"] "on-link": ["G"]
}
},
"links": {
"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}
},
"regions": {
"omashu": {
"options": {
"SIP Server": ["sip.omashu.example.org"],
"DNS Recursive Name Server": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]
} }
}, },
"links": { "gaoling": {
"A": {"region": "omashu"}, "options": {
"B": {"region": "omashu"}, "SIP Server": ["sip.gaoling.example.org"],
"F": {"region": "gaoling"}, "DNS Recursive Name Server": ["dns1.gaoling.example.org",
"G": {"region": "gaoling"} "dns2.gaoling.example.org"]
},
"regions": {
"omashu": {
"options": {
"sip-servers": ["sip.omashu.example.org"],
"dns-servers": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]
}
},
"gaoling": {
"options": {
"sip-servers": ["sip.gaoling.example.org"],
"dns-servers": ["dns1.gaoling.example.org",
"dns2.gaoling.example.org"]
}
} }
} }
} }
}
Figure 4: Regional Configuration Example Figure 4: Regional Configuration Example
In this example, when a request comes in to the DHCPv6 server with a In this example, when a request comes in to the DHCPv6 server with a
link-identifying IP address in the 2001:db8::/40 prefix, it is link-identifying IP address in the 2001:db8::/40 prefix, it is
identified as being on link A. The DHCPv6 server then looks on the identified as being on Link A. The DHCPv6 server then looks on the
list of links to see what region the client is in. Link A is list of links to see what region the client is in. Link A is
identified as being in omashu. The DHCPv6 server then looks up identified as being in omashu. The DHCPv6 server then looks up
omashu in the set of regions, and discovers a list of region-specific omashu in the set of regions and discovers a list of region-specific
options. options.
The DHCPv6 server then resolves the domain names listed in the The DHCPv6 server then resolves the domain names listed in the
options and sends a sip-server option containing the IP addresses options and sends a SIP Server option containing the IP addresses
that the resolver returned for sip.omashu.example.org, and a dns- that the resolver returned for sip.omashu.example.org and a DNS
server option containing the IP addresses returned by the resolver Recursive Name Server option containing the IP addresses returned by
for dns1.omashu.example.org and dns2.omashu.example.org. Depending the resolver for dns1.omashu.example.org and dns2.omashu.example.org.
on the server capability and configuration, it may cache resolved Depending on the server capability and configuration, it may cache
responses for specific period of time, repeat queries every time or resolved responses for a specific period of time, repeat queries
even keep the response until reconfiguration or shutdown. For more every time, or even keep the response until reconfiguration or
detailed discussion see Section 7 of [RFC7227]. shutdown. For more detailed discussion, see Section 7 of [RFC7227].
Similarly, if the DHCPv6 server receives a request from a DHCPv6 Similarly, if the DHCPv6 server receives a request from a DHCPv6
client where the link-identifying IP address is contained by the client where the link-identifying IP address is contained by the
prefix 2001:db8:300::/40, then the DHCPv6 server identifies the prefix 2001:db8:300::/40, then the DHCPv6 server identifies the
client as being connected to link G. The DHCPv6 server then client as being connected to Link G. The DHCPv6 server then
identifies link G as being in the gaoling region, and returns the identifies Link G as being in the gaoling region and returns the SIP
sip-servers and dns-servers options specific to that region. Server and DNS Recursive Name Server options specific to that region.
As with the previous example, the exact configuration syntax and As with the previous example, the exact configuration syntax and
structure shown above does not precisely match what existing DHCPv6 structure shown above does not precisely match what existing DHCPv6
servers do, but the behavior illustrated in this example can be servers do, but the behavior illustrated in this example can be
accomplished with most existing modern DHCPv6 servers. accomplished with most existing modern DHCPv6 servers.
8. Multiple subnets on the same link 8. Multiple Subnets on the Same Link
There are scenarios where there is more than one subnet from the same There are scenarios where there is more than one subnet from the same
protocol family (i.e. two or more IPv4 subnets or two or more IPv6 protocol family (i.e., two or more IPv4 subnets or two or more IPv6
subnets) configured on the same link. Such a configuration is often subnets) configured on the same link. Such a configuration is often
referred to as 'shared subnets' in Unix environments or 'multinet' in referred to as 'shared subnets' in Unix environments or 'multinet' in
Microsoft terminology. Microsoft terminology.
The most frequently mentioned use case is a network renumbering where The most frequently mentioned use case is a network renumbering where
some services are migrated to the new addressing scheme, but some some services are migrated to the new addressing scheme, but some
aren't yet. aren't yet.
Second example is expanding the allocation space. In DHCPv4 and for A second example is expanding the allocation space. In DHCPv4 and
DHCPv6 Prefix Delegation, there could be cases where multiple subnets for DHCPv6 Prefix Delegation, there could be cases where multiple
are needed, because a single subnet may be too small to accommodate subnets are needed, because a single subnet may be too small to
the client population. accommodate the client population.
The third use case covers allocating addresses (or delegation The third use case covers allocating addresses (or delegation
prefixes) that are not the same as topological information. For prefixes) that are not the same as topological information. For
example, the link-address is on prefix X and the addresses to be example, the link-address is on prefix X, and the addresses to be
assigned are on prefix Y. This could be based on differentiating assigned are on prefix Y. This could be based on differentiating
information (i.e., whether device is CPE or CM in DOCSIS) or just information (i.e., whether the device is a CPE or cable modem in the
Data Over Cable Service Interface Specification (DOCSIS)) or just
because the link-address/giaddr is different from the actual because the link-address/giaddr is different from the actual
allocation space. allocation space.
The fourth use case is a cable network, where cable modems and the The fourth use case is a cable network, where cable modems and the
devices connected behind them are connected to the same layer 2 link. devices connected behind them are connected to the same layer 2 link.
However, operators want the cable modems and user devices to get However, operators want the cable modems and user devices to get
addresses from distinct address spaces, so users couldn't easily addresses from distinct address spaces, so users couldn't easily
access their modems management interfaces. access their modems' management interfaces.
To support such a configuration, additional differentiating To support such a configuration, additional differentiating
information is required. Many DHCP server implementations offer a information is required. Many DHCP server implementations offer a
feature that is typically called client classification. The server feature that is typically called "client classification". The server
segregates incoming packets into one or more classes based on certain segregates incoming packets into one or more classes based on certain
packet characteristics, e.g. presence or value of certain options or packet characteristics, e.g., the presence or value of certain
even a match between existing options. Servers require additional options or even a match between existing options. Servers require
information to handle such configuration, as they cannot use the additional information to handle such configuration, as they cannot
topographical property of the relay addresses alone to properly use the topographical property of the relay addresses alone to
choose a subnet. Exact details of such operation is not part of the properly choose a subnet. Exact details of such an operation are not
DHCPv4 or DHCPv6 protocols and is implementation dependent. part of the DHCPv4 or DHCPv6 protocols and are implementation
dependent.
9. Acknowledgments
Thanks to Dave Thaler for suggesting that even though "everybody
knows" how DHCP servers are deployed in the real world, it might be
worthwhile to have an IETF document that explains what everybody
knows, because in reality not everybody is an expert in how DHCP
servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-
Francois Tremblay, Marcin Siodelski, Bernie Volz and Yaron Sheffer
for their reviews, comments and feedback.
10. Security Considerations 9. Security Considerations
This document explains existing practice with respect to the use of This document explains existing practice with respect to the use of
Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
Configuration Protocol Version 6 [RFC3315]. The security Configuration Protocol Version 6 [RFC3315]. The security
considerations for these protocols are described in their considerations for these protocols are described in their
specifications and in related documents that extend these protocols. specifications and in related documents that extend these protocols.
The mechanisms described in this document could possibly be exploited The mechanisms described in this document could possibly be exploited
by an attacker to misrepresent its point of attachment in the by an attacker to misrepresent its point of attachment in the
network. This would cause the server to assign addresses, prefixes network. This would cause the server to assign addresses, prefixes,
and other configuration options, which can be considered a leak of and other configuration options, which can be considered a leak of
information. In particular, this could be used a preliminary stage information. In particular, this could be used as a preliminary
of an attack, when the DHCP server leaks information about available stage of an attack when the DHCP server leaks information about
services in parts of the network the attacker does not have access available services in parts of the network the attacker does not have
to. access to.
There are several ways how such an attack can be prevented. First, There are several ways that such an attack can be prevented. First,
it seems to be a common practice to filter out DHCP traffic coming in it is a common practice to filter DHCP traffic passing to clients
from outside of the network and one that is directed to clients within a particular administrative domain from outside of that
outside of the network. Second, the DHCP servers can be configured domain, and also to filter DHCP traffic to clients outside of a
to not respond to traffic that is coming from unknown (i.e. those particular administrative domain from within that domain. Second,
subnets the server is not configured to serve) subnets. Third, some the DHCP servers can be configured to not respond to traffic that is
relays provide the ability to reject messages that do not fit coming from unknown subnets (i.e., those subnets the server is not
expected characteristics. For example CMTS (Cable Modem Termination configured to serve). Third, some relays provide the ability to
System) acting as a DHCP relay detects if the MAC address specified reject messages that do not fit expected characteristics. For
in chaddr in incoming DHCP messages matches the MAC address of the example, the Cable Modem Termination System (CMTS) acting as a DHCP
cable modem it came from and can alter its behavior accordingly. relay detects if the Media Access Control (MAC) address specified in
Also, relay agents and servers that are connected to clients directly chaddr in incoming DHCP messages matches the MAC address of the cable
can reject traffic that looks as if it has passed a relay (this could modem it came from and can alter its behavior accordingly. Also,
relay agents and servers that are connected to clients directly can
reject traffic that looks as if it has passed a relay (this could
indicate the client is attempting to spoof a relay, possibly to indicate the client is attempting to spoof a relay, possibly to
inject forged relay options). inject forged relay options).
There are a number of general DHCP recommendations that should be There are a number of general DHCP recommendations that should be
considered in all DHCP deployments. While not strictly related to considered in all DHCP deployments. While not strictly related to
the mechanisms described in this document, they may be useful in the mechanisms described in this document, they may be useful in
certain deployment scenarios. [RFC7819] and [RFC7824] provide an certain deployment scenarios. [RFC7819] and [RFC7824] provide an
analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If
those are of concern, [RFC7844] offers mitigation steps. those are of concern, [RFC7844] offers mitigation steps.
Current DHCPv4 and DHCPv6 standards lack strong cryptographic Current DHCPv4 and DHCPv6 standards lack strong cryptographic
protection. There is an ongoing effort in DHC working group to protection. There is an ongoing effort in the DHC working group to
address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism address this. [SECURE-DHCPv6] attempts to provide a mechanism for
for strong authentication and encryption between DHCPv6 clients and strong authentication and encryption between DHCPv6 clients and
servers. [I-D.volz-dhc-relay-server-security] attempts to improve servers. [SECURITY-MESSAGES] attempts to improve security of
security of exchanges between DHCP relay agents and servers. exchanges between DHCP relay agents and servers.
Another possible attack vector is to set up a rogue DHCP server and Another possible attack vector is to set up a rogue DHCP server and
provide clients with false information, either as a denial of service provide clients with false information, either as a denial of service
or to execute man in the middle type of attack. This can be or to execute a man-in-the-middle type of attack. This can be
mitigated by deplyoing DHCPv6-shield [RFC7610]. mitigated by deploying DHCPv6-Shield [RFC7610].
Finally, there is an ongoing effort to update DHCPv6 specification,
that is currently 13 years old. Sections 23 (Security
Considerations) and 24 (Privacy Considerations) of
[I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the
security and privacy considerations.
11. IANA Considerations Finally, there is an ongoing effort to update the DHCPv6
specification, which is currently 13 years old. Sections 21
("Security Considerations") and 22 ("Privacy Considerations") of
[DHCPv6bis] contain more recent analysis of the security and privacy
considerations.
The IANA is hereby absolved of any requirement to take any action in 10. References
relation to this document.
12. References 10.1. Normative References
12.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
12.2. Informative References 10.2. Informative References
[I-D.ietf-dhc-rfc3315bis] [DHCPv6bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6) "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
bis", draft-ietf-dhc-rfc3315bis-05 (work in progress), bis", Work in Progress, draft-ietf-dhc-rfc3315bis-05, June
June 2016. 2016.
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-12 (work
in progress), April 2016.
[I-D.volz-dhc-relay-server-security]
Volz, B. and Y. Pal, "Security of Messages Exchanged
Between Servers and Relay Agents", draft-volz-dhc-relay-
server-security-01 (work in progress), June 2016.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, DOI 10.17487/RFC3011, November 2000, RFC 3011, DOI 10.17487/RFC3011, November 2000,
<http://www.rfc-editor.org/info/rfc3011>. <http://www.rfc-editor.org/info/rfc3011>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, DOI 10.17487/RFC3046, January 2001, RFC 3046, DOI 10.17487/RFC3046, January 2001,
<http://www.rfc-editor.org/info/rfc3046>. <http://www.rfc-editor.org/info/rfc3046>.
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content
Negotiation for Messaging Services based on Email",
RFC 3297, DOI 10.17487/RFC3297, July 2002,
<http://www.rfc-editor.org/info/rfc3297>.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information "Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April
2003, <http://www.rfc-editor.org/info/rfc3527>. 2003, <http://www.rfc-editor.org/info/rfc3527>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
skipping to change at page 19, line 5 skipping to change at page 19, line 38
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824, Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016, DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>. <http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>. <http://www.rfc-editor.org/info/rfc7844>.
[SECURE-DHCPv6]
Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", Work in Progress,
draft-ietf-dhc-sedhcpv6-14, October 2016.
[SECURITY-MESSAGES]
Volz, B. and Y. Pal, "Security of Messages Exchanged
Between Servers and Relay Agents", Work in Progress,
draft-volz-dhc-relay-server-security-02, September 2016.
Acknowledgements
Thanks to Dave Thaler for suggesting that even though "everybody
knows" how DHCP servers are deployed in the real world, it might be
worthwhile to have an IETF document that explains what everybody
knows, because in reality not everybody is an expert in how DHCP
servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun,
Jean-Francois Tremblay, Marcin Siodelski, Bernie Volz, and Yaron
Sheffer for their reviews, comments, and feedback.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2000 Seaport Blvd 800 Bridge Parkway, Suite 100
Redwood City, CA 94063 Redwood City, CA 94065
USA United States of America
Phone: +1-650-381-6000 Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com Email: Ted.Lemon@nominum.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA United States of America
Phone: +1 650 423 1345 Phone: +1-650-423-1345
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
 End of changes. 91 change blocks. 
313 lines changed or deleted 338 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/