draft-ietf-dhc-topo-conf-01.txt   draft-ietf-dhc-topo-conf-02.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Intended status: Best Current Practice T. Mrugalski Intended status: Informational T. Mrugalski
Expires: August 18, 2014 Internet Systems Consortium, Inc. Expires: January 5, 2015 Internet Systems Consortium, Inc.
February 14, 2014 July 4, 2014
Customizing DHCP Configuration on the Basis of Network Topology Customizing DHCP Configuration on the Basis of Network Topology
draft-ietf-dhc-topo-conf-01 draft-ietf-dhc-topo-conf-02
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 which is described in the DHCP base
specifications. One aspect of this functionality is support for specifications. One aspect of this functionality is support for
context-specific configuration information. This memo describes some context-specific configuration information. This memo describes some
such features and makes recommendations as to how they can be used. such features and makes recommendations as to how they can be used.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 12
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. Locality . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Locality . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 7 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 8
5. Relay agent running on a host . . . . . . . . . . . . . . . . 9 5. Relay agent running on a host . . . . . . . . . . . . . . . . 10
6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 9 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 10
7. Regional Configuration Example . . . . . . . . . . . . . . . 9 7. Regional Configuration Example . . . . . . . . . . . . . . . 11
8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 11 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 13
9. Relay Agent Configurations . . . . . . . . . . . . . . . . . 12 9. Multiple subnets on the same link . . . . . . . . . . . . . . 14
10. Mutliple subnets on the same link . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Informative References . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
skipping to change at page 2, line 50 skipping to change at page 2, line 47
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 both of operators and of protocol
designers who may wish to use DHCP as a means for configuring their designers who may wish to use DHCP as a means for configuring their
own services, but may not be aware of the capabilities provided by own services, but may not be aware of the capabilities provided by
modern DHCP servers. most modern DHCP servers.
2. Terminology 2. Terminology
an IP address with a scope of use wider than the local link. o Routable IP address: an IP address with a scope of use wider than
the local link.
provider edge router. The provider router closest to the customer. o PE router: Provider Edge Router. The provider router closest to
the customer.
customer premise equipment device. Typically a router belonging to o CPE device: customer premise equipment device. Typically a router
the customer that connects directly to the provider link. belonging to the customer that connects directly to the provider
link.
o Shared subnet: a case where two or more subnets of the same
protocol family are available on the same link. 'Share subnet'
terminology is typically used in Unix environments. It is
typically called 'multinet' in Windows environment. The
administrative configuration inside a Microsoft DHCP server is
called 'DHCP Superscope'.
3. Locality 3. Locality
Figure 1 illustrates a simple hierarchy of network links with Link D Figure 1 illustrates a simple 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 an actual production networks, aspects are unlikely to be seen in an actual production networks,
they are beneficial for explaining finer aspects of the DHCP they are beneficial for explaining finer aspects of the DHCP
protocols. protocols. Note that some nodes act as routers (which forward all
IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific
software that forwards only DHCPv6 traffic).
Link A Link B Link A Link B
|===+===========| |===========+======| |===+===========| |===========+======|
| | | |
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| relay | | relay | | relay | | relay |
| A | | B | | A | | B |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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's important to understand the background of how DHCP works when It's important to understand the background of how DHCP works when
considering this diagram. DHCP clients are assumed not to have considering this diagram. DHCP clients are assumed not to have
routable IP addresses when they are attempting to obtain 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 configuration, it cannot the client does not yet have an IP address configured, it cannot
route packets to an off-link DHCP server, and so some kind of relay route packets to an off-link DHCP server, therefore some kind of
mechanism is required. relay mechanism is required.
The details of how this works are different between DHCPv4 and The details of how packet delivery between clients and servers works
DHCPv6, but the essence is the same: whether or not the client are different between DHCPv4 and DHCPv6, but the essence is the same:
actually has an IP configuration, it generally communicates with the whether or not the client actually has an IP configuration, it
DHCP server by sending its requests to a DHCP relay agent on the generally communicates with the DHCP server by sending its requests
local link; this relay agent, which has a routable IP address, then to a DHCP relay agent on the local link; this relay agent, which has
forwards the DHCP requests to the DHCP server. In some cases in a routable IP address, then forwards the DHCP requests to the DHCP
DHCPv4, when a DHCP client has a routable IPv4 address, the message server. In some cases in DHCPv4, when a DHCP client has a routable
is unicast to the DHCP server rather than going through a relay IPv4 address, the message is unicast to the DHCP server rather than
agent. In DHCPv6 that is also possible in case where server is going through a relay agent. In DHCPv6 that is also possible in case
configured with server unicast option and clients are able to take where the server is configured with a Server Unicast option (see
advantage of it. In such case once the clients get their (presumably Section 22.12 in [RFC3315]) and clients are able to take advantage of
global) addresses, they are able to contact server directly, it. In such case once the clients get their (presumably global)
bypassing relays. It should be noted that such a mode is completely addresses, they are able to contact server directly, bypassing
relays. It should be noted that such a mode is completely
controllable by administrators in DHCPv6. (They may simply choose to controllable by administrators in DHCPv6. (They may simply choose to
not configure server unicast option, thus forcing clients to send not configure server unicast option, thus forcing clients to send
their messages always via relay agents). their messages always via relay agents).
In either case, the DHCP server is able to obtain an IP address that In all cases, the DHCP server is able to obtain an IP address that it
it knows is on-link for the link to which the DHCP client is knows is on-link for the link to which the DHCP client is connected:
connected: either the DHCPv4 client's routable IPv4 address, or the either the DHCPv4 client's routable IPv4 address, or the relay
relay agent's IP address on the link to which the client is agent's IPv4 address on the link to which the client is connected.
connected. So in every case the server is able to determine the client's point
of attachment and select appropriate subnet- or link-specific
configuration.
In DHCPv6 protocol, there are two mechanisms defined in [RFC3315] In the DHCPv6 protocol, there are two mechanisms defined in [RFC3315]
that allow server to distinguish which link the relay agent is that allow server to distinguish which link the relay agent is
connected to. The first mechanism is a link-address field in the connected to. The first mechanism is a link-address field in the
RELAY-FORW and RELAY-REPL messages. Somewhat contrary to its name, RELAY-FORW and RELAY-REPL messages. Somewhat contrary to its name,
relay agents insert an address that is typically global and can be relay agents insert in the link-address field an address that is
used to uniquely identify the link on which the client is located. typically global and can be used to uniquely identify the link on
In normal circumstances this is the solution that is easiest to which the client is located. In normal circumstances this is the
maintain. It requires, however, for the relay agent to have an solution that is easiest to maintain. It requires, however, for the
address configured on its client-facing interface. If for whatever relay agent to have an address with a scope larger than link-local
reason that is not feasible (e.g. because the relay agent does not configured on its client-facing interface. If for whatever reason
have a global address), the relay agent includes an interface-id that is not feasible (e.g. because the relay agent does not have a
option that identifies the link clients are connected to. It is up global address configured on the client-facing interface), the relay
to administrator to make sure that the interface-id is unique within agent includes an Interface-Id option (see Section 22.18 of
his administrative domain. [RFC3315]) that identifies the link clients are connected to. It is
up to administrator to make sure that the interface-id is unique
within his administrative domain. It should be noted that RELAY-FORW
and RELAY-REPL messages are exchanged between relays and servers
only. Clients are never exposed to those messages. Also, servers
never receive RELAY-REPL messages. Relay agents must be able to
process both RELAY-FORW (sending already relayed message further
towards the server, when there is more than one relay agent in a
chain) and RELAY-REPL (when sending back the response towards the
client, when there is more than one relay agent in a chain).
DHCPv6 also has support for more finely grained link identification, DHCPv6 also has support for more finely grained link identification,
using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA). In this
case, in addition to receiving an IPv6 address that is on-link for case, in addition to receiving an IPv6 address that is on-link for
the link to which the client is connected, the DHCPv6 server also the link to which the client is connected, the DHCPv6 server also
receives an Interface Identifier option from the relay agent that can receives an Interface-Id option from the relay agent that can be used
be used to more precisely identify the client's location on the to more precisely identify the client's location on the network.
network.
What this means in practice is that the DHCP server in all cases has What this means in practice is that the DHCP server in all cases has
sufficient information to pinpoint, at the very least, the layer 3 sufficient information to pinpoint, at the very least, the layer 3
link to which the client is connected, and in some cases which layer link to which the client is connected, and in some cases which layer
2 link the client is connected to, when the layer 3 link is 2 link the client is connected to, when the layer 3 link is
aggregated out of multiple layer 2 links. aggregated out of multiple layer 2 links.
In all cases, then, the DHCP server will have a link-identifying IP In all cases, then, the DHCP 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. It should be noted that there is no guarantee that the identifier (e.g. Interface-Id Option or Link Address Option defined
link-specific identifier will be unique outside the scope of the in Section 5 of [RFC6977]). It should be noted that there is no
link-identifying IP address. guarantee that the link-specific identifier will be unique outside
the scope of the link-identifying IP address.
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 link is an aggregate
of two or more link-specific identifiers sent by a set of LDRAs in a of two or more link-specific identifiers sent by a set of LDRAs in a
chain; in general this functions exactly as if a single identifier 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 DHCP servers. will need to be aware of this when configuring their DHCP servers.
So let's examine the implications of this in terms of how a DHCP So let's examine the implications of this in terms of how a DHCP
server can deliver targeted supplemental configuration information to server can deliver targeted supplemental configuration information to
DHCP clients. DHCP clients.
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: links A, B, F and G, on
which DHCP clients will be configured. Relays A, B, C and D in this which DHCP clients will be configured. 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 server on each relay function can also be provided in a separate node on each link.
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 for configuration. Although we know that uses a simple JSON notation for configuration. Although we know
of no DHCP server that uses this specific syntax, every commercial of no DHCP server that uses this specific syntax, most modern DHCP
DHCP server provides similar functionality. server provides similar functionality.
{"prefixes":
{"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]}
"on-link": ["a"]}}
"10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}}
"on-link": ["b"]}
"10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}}
"on-link": ["f"]}
"10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}}
"on-link": ["g"]}}
Figure 2 {
"prefixes": {
"192.0.2.0/26": {
"options": {
"routers": ["192.0.2.1"]
},
"on-link": ["a"]
},
"192.0.2.64/26": {
"options": {
"routers": ["192.0.2.65"]
},
"on-link": ["b"]
},
"192.0.2.128/26": {
"options": {
"routers": ["192.0.2.129"]
},
"on-link": ["f"]
},
"192.0.2.192/26": {
"options": {
"routers": ["192.0.2.193"]
},
"on-link": ["g"]
}
}
}
Figure 3 Figure 3: Configuration example
In Figure 3, we see a configuration example for this scenario: a set In Figure 3, we see a configuration example for this scenario: a set
of prefixes, each of which has a set of options and a list of links of prefixes, each of which has a set of options and a list of links
for which it is on-link. We have defined one option for each prefix: for which it is on-link. We have defined one option for each prefix:
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 have
a link-identifying IP address within the 10.0.0.0/24 prefix, so the a link-identifying IP address within the 192.0.2.0/26 prefix, so the
DHCP server would match it to that prefix. Based on 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: 10.0.0.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 10.0.2.0/24 prefix, and would have a link-identifying address in the 192.0.2.128/26 prefix, and
receive a routers option containing the IP address 10.0.2.1. 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
Relay agent is a DHCP software that may be run on any IP node. Relay agent is a DHCP software that may be run on any IP node.
Although it is typically run on a a router, it doesn't have to be Although it is typically run on a router, this is by no means
one. Relay agent can be run on a host connected to two links. That required by the DHCP protocol. The relay agent is simply a service
case is presented in Figure 2. There is router B that is connected that operates on a link, receiving link-local multicasts or
to links D and E. At the same time there is also a host that is broadcasts and relaying them, using IP routing, to a DHCP 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 DHCP server, it
need not be a router, or even have multiple interfaces.
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
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 legal configuration. that host. That is uncommon, but legal configuration.
6. Cascade relays 6. Cascade relays
Let's observe another case shown in Figure 2. Note that in typical Let's observe another case shown in Figure 2. Note that in typical
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 it to the DHCP
server. This configuration is sometimes referred to as cascade relay server. This configuration is sometimes referred to as cascade relay
agents. 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). Server will send the first relay (i.e. the closest to the client). Server will send
the response back to the GIADDR address, which is the address of the the response back to the GIADDR address, which is the address of the
first relay agent that seen the client's message. That means that first relay agent that saw the client's message. That means that the
the client messages travel on a different path than the server's 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 client connected to link G will travel via
relay D, relay E and to the server. A response message will be sent relay D, relay E and to the server. A response message will be sent
from the server to relay D which will send it to the client on link from the server to relay D via router B, and relay D will send it to
G. 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 server's unicast server. Depending on the configuration that can be server's unicast
address, a multicast address or next relay agent address. The next address, a multicast address or next relay agent address. The next
relay repeats the encapsulation process. Although the resulting relay repeats the encapsulation process. Although the resulting
packet is more complex (may have up to 32 levels of encapsulation if packet is more complex (may have up to 32 levels of encapsulation if
traveled through 32 relays), every relay may insert its own options traveled through 32 relays), every relay may insert its own options
and it is clear which relay agent inserted which option. and it is clear which relay agent inserted which option.
skipping to change at page 10, line 16 skipping to change at page 11, line 27
assume there is a single CPE device attached to the link. 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 this example, the goal is to configure all the devices within a In the example presented in Figure 4, the goal is to configure all
region with server addresses local to that region, so that service the devices within a region with server addresses local to that
traffic does not have to be routed between regions unnecessarily. region, so that service traffic does not have to be routed between
regions unnecessarily.
{"prefixes":
{"2001:DB8:0:0::/40": {"on-link": ["A"]}}
"2001:DB8:100:0::/40": {"on-link": ["B"]}
"2001:DB8:200:0::/40": {"on-link": ["F"]}
"2001:DB8:300:0::/40": {"on-link": ["G"]}}
{"links":
{"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}}}
{"regions": {
{"omashu": {"options": "prefixes": {
{"sip-servers": ["sip.omashu.example.org"], "2001:db8:0:0::/40": {
"on-link": ["A"]
},
"2001:db8:100:0::/40": {
"on-link": ["B"]
},
"2001:db8:200:0::/40": {
"on-link": ["F"]
},
"2001:db8:300:0::/40": {
"on-link": ["G"]
}
},
"links": {
"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}
},
"regions": {
"omashu": {
"options": {
"sip-servers": ["sip.omashu.example.org"],
"dns-servers": ["dns1.omashu.example.org", "dns-servers": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]}}, "dns2.omashu.example.org"]
"gaoling": {"options": }
{"sip-servers": ["sip.gaoling.example.org"], },
"dns-servers": ["dns1.gaoling.example.org", "gaoling": {
"dns2.gaoling.example.org"]}}}} "options": {
"sip-servers": ["sip.gaoling.example.org"],
"dns-servers": ["dns1.gaoling.example.org",
"dns2.gaoling.example.org"]
}
}
}
}
Figure 3 Figure 4: An example regions configuration
In this example, when a request comes in to the DHCP server with a In this example, when a request comes in to the DHCP server with a
link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is link-identifying IP address in the 2001:DB8:0:0::/40 prefix, it is
identified as being on link A. The DHCP server then looks on the identified as being on link A. The DHCP 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 DHCP server then looks up omashu identified as being in omashu. The DHCP server then looks up omashu
in the set of regions, and discovers a list of region-specific in the set of regions, and discovers a list of region-specific
options. options.
The DHCP server then resolves the domain names listed in the options The DHCP server then resolves the domain names listed in the options
and sends a sip-server option containing the IP addresses that the and sends a sip-server option containing the IP addresses that the
resolver returned for sip.omashu.example.org, and a dns-server option resolver returned for sip.omashu.example.org, and a dns-server option
containing the IP addresses returned by the resolver for containing the IP addresses returned by the resolver for
dns1.omashu.example.org and dns2.omashu.example.org. dns1.omashu.example.org and dns2.omashu.example.org. Depending on
the server capability and configuration, it may cache resolved
responses for specific period of time, repeat queries every time or
even keep the response until reconfiguration or shutdown.
Similarly, if the DHCP server receives a request from a DHCP client Similarly, if the DHCP server receives a request from a DHCP client
where the link-identifying IP address is contained by the prefix where the link-identifying IP address is contained by the prefix
2001:DB8:300:0::/40, then the DHCP server identifies the client as 2001:DB8:300:0::/40, then the DHCP server identifies the client as
being connected to link G. The DHCP server then identifies link G as being connected to link G. The DHCP server then identifies link G as
being in the gaoling region, and returns the sip-servers and dns- being in the gaoling region, and returns the sip-servers and dns-
servers options specific to that region. servers 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 DHCP structure shown above does not precisely match what existing DHCP
servers do, but the behavior illustrated in this example can be servers do, but the behavior illustrated in this example can be
accomplished with all existing commercial DHCP servers. accomplished with most existing modern DHCP servers.
8. Dynamic Lookup 8. Dynamic Lookup
In the Regional example, the configuration listed several domain In the Regional example, the configuration listed several domain
names as values for the sip-servers and dns-servers options. The names as values for the sip-servers and dns-servers options. The
wire format of both of these options contains one or more IPv6 wire format of both of these options contains one or more IPv6
addresses--there is no way to return a domain name to the client. addresses--there is no way to return a domain name to the client.
This was understood to be an issue when the original DHCP protocol This was understood to be an issue when the original DHCP protocol
was defined, and historical implementations even from the very early was defined, and historical implementations even from the very early
days would accept domain names and resolve them. Some early DHCP days would accept domain names and resolve them. Some early DHCP
implementations, particularly those based on earlier BOOTP implementations, particularly those based on earlier BOOTP
implementations, had very limited capacity for reconfiguration. implementations, had very limited capacity for reconfiguration.
However, all modern commercial DHCP servers handle name resolution by However, most modern DHCP servers handle name resolution by querying
querying the resolver each time a DHCP packet comes in. This means the resolver each time a DHCP packet comes in. This means that if
that if DHCP servers and DNS servers are managed by different DHCP servers and DNS servers are managed by different administrative
administrative entities, there is no need for the administrators of entities, there is no need for the administrators of the DHCP servers
the DHCP servers and DNS servers to communicate when changes are and DNS servers to communicate when changes are made. When changes
made. When changes are made to the DNS server, these changes are are made to the DNS server, these changes are promptly and
immediately and automatically adopted by the DHCP server. Similarly, automatically adopted by the DHCP server. Similarly, when DHCP
when DHCP server configurations change, DNS server administrators server configurations change, DNS server administrators need not be
need not be aware of this. aware of this.
However, it should be noted that even though the DHCP server may be
configured to query the DNS server every time it uses configured
names, the changes made in the DNS zone may not be visible to the
server until the DNS cache expires. If this is not desired, the DHCP
server can be configured to query the authoritative DNS server
directly, bypassing any caching DNS servers.
It's worth noting that DNS is not the only way to resolve names, and It's worth noting that DNS is not the only way to resolve names, and
not all DHCP servers support other techniques (e.g., NIS+ or WINS). not all DHCP servers support other techniques (e.g., NIS+ or WINS).
However, since these protocols have all but vanished from common use, However, since these protocols have all but vanished from common use,
this won't be an issue in new deployments. this won't be an issue in new deployments.
9. Relay Agent Configurations 9. Multiple subnets on the same link
It's worth mentioning that although we talk about relay agents and
routers in this document mostly as if they are the same device, this
is by no means required by the DHCP protocol. The relay agent is
simply a service that operates on a link, receiving link-local
multicasts or broadcasts and relaying them, using IP routing, to a
DHCP 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
DHCP server, it need not be a router, or even have multiple
interfaces.
10. Mutliple 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 layer 3 link. One example is a slow subnets) configured on the same layer 3 link. One example is a slow
network renumbering where some services are migrated to the new network renumbering where some services are migrated to the new
addressing scheme, but some aren't yet. Second example is a cable addressing scheme, but some aren't yet. Second example is a cable
network, where cable modems and the devices connected behind them are network, where cable modems and the devices connected behind them are
connected to the same layer 2 link. However, operators want the connected to the same layer 2 link. However, operators want the
cable modems and user devices to get addresses from distinct address cable modems and user devices to get addresses from distinct address
spaces, so users couldn't easily access their modems management spaces, so users couldn't easily access their modems management
interfaces. Such a configuration is often referred to as shared interfaces. Such a configuration is often referred to as 'shared
subnets. subnets' in Unix environments or 'multinet' in Microsoft terminology.
To support such an configuration, additional differentiating To support such an 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 certains options or packet characteristics, e.g. presence or value of certains options or
even a match between existing options. Servers require additional even a match between existing options. Servers require additional
information to handle such configuration, as it can't use the information to handle such configuration, as it can't use the
topographical property of the relay addresses alone to properly topographical property of the relay addresses alone to properly
choose a subnet. Such information is always implementation specific. choose a subnet. Such information is always implementation specific.
11. Acknowledgments 10. Acknowledgments
Thanks to Dave Thaler for suggesting that even though "everybody Thanks to Dave Thaler for suggesting that even though "everybody
knows" how DHCP servers are deployed in the real world, it might be knows" how DHCP servers are deployed in the real world, it might be
worthwhile to have an IETF document that explains what everybody worthwhile to have an IETF document that explains what everybody
knows, because in reality not everybody is an expert in how DHCP knows, because in reality not everybody is an expert in how DHCP
servers are administered. servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
Simon Perreault, Jinmei Tatuya and Suresh Krishnan for their reviews,
comments and feedback.
12. Security Considerations 11. 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.
This document introduces no new functionality, and hence no new This document introduces no new functionality, and hence no new
security considerations. security considerations.
13. IANA Considerations 12. IANA Considerations
The IANA is hereby absolved of any requirement to take any action in The IANA is hereby absolved of any requirement to take any action in
relation to this document. relation to this document.
14. References 13. Informative References
14.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
14.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May
2011. 2011.
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6
Reconfiguration from Relay Agents", RFC 6977, July 2013.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2000 Seaport Blvd 2000 Seaport Blvd
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1-650-381-6000 Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com Email: Ted.Lemon@nominum.com
 End of changes. 42 change blocks. 
152 lines changed or deleted 213 lines changed or added

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