draft-ietf-dhc-topo-conf-04.txt   draft-ietf-dhc-topo-conf-05.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Intended status: Informational T. Mrugalski Intended status: Informational T. Mrugalski
Expires: July 13, 2015 ISC Expires: January 7, 2016 ISC
January 9, 2015 July 6, 2015
Customizing DHCP Configuration on the Basis of Network Topology Customizing DHCP Configuration on the Basis of Network Topology
draft-ietf-dhc-topo-conf-04 draft-ietf-dhc-topo-conf-05
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 July 13, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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. Identifying Client's Location by DHCP Servers . . . . . . . . 3 3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 9
5. Relay agent running on a host . . . . . . . . . . . . . . . . 11 5. Relay agent running on a host . . . . . . . . . . . . . . . . 11
6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 11 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 11
7. Regional Configuration Example . . . . . . . . . . . . . . . 12 7. Regional Configuration Example . . . . . . . . . . . . . . . 12
8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 14 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 14
9. Multiple subnets on the same link . . . . . . . . . . . . . . 15 9. Multiple subnets on the same link . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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
most modern DHCP servers. most modern DHCP servers.
2. Terminology 2. Terminology
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 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 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 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 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'.
3. Identifying Client's Location by DHCP Servers 3. Identifying Client's Location by DHCP Servers
Figure 1 illustrates a simple 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 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. Note that some nodes act as routers (which forward all protocols. Note that some nodes act as routers (which forward all
IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific
software that forwards only DHCPv6 traffic). software that forwards only DHCPv6 traffic).
Link A Link B Link A Link 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 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 48 skipping to change at page 5, line 47
| relay | | relay | | relay | | relay |
| C | | D | | C | | D |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
| | | |
|===+===========| |===========+======| |===+===========| |===========+======|
Link F Link G Link F Link G
Figure 2: Complex network Figure 2: Complex network
This diagram allows us to represent a variety of different network Those 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's important to understand the background of how DHCP works when It is important to understand the background of how DHCP works when
considering this diagram. 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
skipping to change at page 6, line 46 skipping to change at page 6, line 46
Sometimes it is useful for the relay agents to provide additional Sometimes it is useful for the relay agents to provide additional
about the topology. A number of extensions have been defined for about the topology. A number of extensions have been defined for
this purpose. The specifics are different, but the core principle this purpose. The specifics are different, but the core principle
remains the same: the relay agent knows exactly where the original remains the same: the relay agent knows exactly where the original
request came from, so it provides an indentifier that will help the request came from, so it provides an indentifier that will help the
server to choose appropriate address pool and configuration 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
no relay agents are required. In such cases, the DHCPv4 server
typically uses the IPv4 address assigned to the network interface
over which the transmission was received to select appropriate
subnet. This is more complicated for DHCPv6, as the DHCPv6 server is
not required to have any globally unique addresses. In such cases,
an additional configuration information may be required. Some
servers allow indicating that a given subnet is directly reachable
over 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. going through a relay agent. Examples of such transmissions are
renewal (DHCPREQUEST) and address release (DHCPRELEASE).
The relay agent that receives client's message sets GIADDR field to
the address of the network interface the message was 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 Link Selection sub-option selection in DHCPv4. [RFC3527] defines Link Selection sub-option
that is iserted by a relay agent. This option is particularly useful that is iserted by a relay agent. This option is particularly useful
when the relay agent needs to specify the subnet/link on which a DHCP when the relay agent needs to specify the subnet/link on which a DHCP
client resides, which is different from an IP address that can be client resides, which is different from an IP address that can be
used to communicate with the relay agent. Virtual Subnet Selection used to communicate with the relay agent. Virtual Subnet Selection
Option, specified in [RFC6607] is used for the same purpose (i.e. Option, specified in [RFC6607] is used for the same purpose (i.e.
relay agents insert that information), but it also covers additional relay agents insert that information), but it also covers additional
use cases in VPN environment. In certain cases it is useful for the use cases in VPN environment. In certain cases it is useful for the
skipping to change at page 7, line 26 skipping to change at page 7, line 39
Another option that may influence the subnet selection is IPv4 Subnet Another option that may influence the subnet selection is IPv4 Subnet
Selection Option, defined in [RFC3011], which allows the client to Selection Option, defined in [RFC3011], which allows the client to
explicitly request allocation from a given subnet. 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 case where the server
is configured with a Server Unicast option (see Section 22.12 in is configured with a Server Unicast option (see Section 22.12 in
[RFC3315]) and clients are able to take advantage of it. In such [RFC3315]) and clients are able to take advantage of it. In such
case once the clients get their (presumably global) addresses, they cases, once a client is assigned a, presumably global, address, it is
are able to contact server directly, bypassing relays. It should be able to contact the server directly, bypassing any relays. It should
noted that such a mode is completely controllable by administrators be noted that such a mode is completely controllable by
in DHCPv6. (They may simply choose to not configure server unicast administrators in DHCPv6. (They may simply choose to not configure
option, thus forcing clients to send their messages always via relay server unicast option, thus forcing clients to send their messages
agents in every case). always via relay agents in every case).
In the DHCPv6 protocol, there are two core mechanisms defined in In the DHCPv6 protocol, there are two core mechanisms defined in
[RFC3315] that allow server to distinguish which link the relay agent [RFC3315] that allow server to distinguish which link the relay agent
is connected to. The first mechanism is a link-address field in the is connected to. The first mechanism is a link-address field in the
Relay-forward and Relay-reply messages. Somewhat contrary to its Relay-forward and Relay-reply messages. Somewhat contrary to its
name, relay agents insert in the link-address field an address that name, relay agents insert in the link-address field an address that
is typically global and can be used to uniquely identify the link on is typically global and can be used to uniquely identify the link on
which the client is located. In normal circumstances this is the which the client is located. In normal circumstances this is the
solution that is easiest to maintain, as existing address assignments solution that is easiest to maintain, as existing address assignments
can be used and no additional administrative actions (like assigning can be used and no additional administrative actions (like assigning
skipping to change at page 8, line 5 skipping to change at page 8, line 19
requires, however, for the relay agent to have an address with a requires, however, for the relay agent to have an address with a
scope larger than link-local configured on its client-facing scope larger than link-local configured on its client-facing
interface. interface.
If for whatever reason that is not feasible (e.g. because the relay If for whatever reason that is not feasible (e.g. because the relay
agent does not have a global address or ULA [RFC4193] configured on agent does not have a global address or ULA [RFC4193] configured on
the client-facing interface), the relay agent includes an Interface- the client-facing interface), the relay agent includes an Interface-
Id option (see Section 22.18 of [RFC3315]) that identifies the link Id option (see Section 22.18 of [RFC3315]) that identifies the link
clients are connected to. If the interface-id is unique within an clients are connected to. If the interface-id is unique within an
administrative domain, the interface-id value may be used to select administrative domain, the interface-id value may be used to select
appropriate subnet. As there is no guarantee for the uniqueness the appropriate subnet. As there is no guarantee for the uniqueness
([RFC3315] only mandates the interface-id to be unique within a ([RFC3315] only mandates the interface-id to be unique within a
single relay agent context), it is up to the administrator to check single relay agent context), it is up to the administrator to check
whether the relay agents deployed use unique interface-id values. If whether the relay agents deployed use unique interface-id values. If
they aren't, Interface-id cannot be used to determine client's point they aren't, Interface-id cannot be used to determine client's point
of attachment. 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
already relayed message further towards the server, when there is already relayed message further towards the server, when there is
more than one relay agent in a chain) and Relay-reply (when sending more than one relay agent in a chain) and Relay-reply (when sending
back the response towards the client, when there is more than one back the response towards the client, when there is more than one
relay agent in a chain). relay agent in a chain).
For completeless, we also mention an uncommon, but valid case, where For completeness, we also mention an uncommon, but valid case, where
relay agents set link-local address in the link-address field in relay agents set 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. Even though link local doesn't have any address with a larger scope. Even though link local
addresses can't be automatically used to associate relay agent with a addresses cannot be automatically used to associate relay agent with
given link, with sufficient information provided the server is still a given link, with sufficient information provided the server is
able to correctly select the proper link. That requires the DHCP still able to correctly select the proper link. That requires the
server software to be able to specify relay agent link-address or a DHCP server software to be able to specify relay agent link-address
feature similar to 'shared subnets' (see Section 9). Network or a feature similar to 'shared subnets' (see Section 9). Network
administrator has to manually configure additional information that a administrator has to manually configure additional information that a
given subnet uses a relay agent with link-address X. Alternatively, given subnet uses a relay agent with link-address X. Alternatively,
if the relay agent uses link address X and relays messages from a 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 A, an administrator can configure that subnet A is a shared
subnet with a very small X/128 subnet. That is not a recommended subnet with a very small X/128 subnet. That is not a recommended
configuration, but in cases where it is impossible for relay agents 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 to get an address from the subnet they are relaying from, it may be a
viable solution. viable solution.
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, the link-address field is set to Unspecified_address (::), but
the link to which the client is connected, the DHCPv6 server also the DHCPv6 server also receives an Interface-Id option from the relay
receives an Interface-Id option from the relay agent that can be used agent that can be used to more precisely identify the client's
to more precisely identify the client's location on the network. location on the 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 (e.g. Interface-Id Option or Link Address Option defined identifier (e.g. Interface-Id Option or Link Address Option defined
skipping to change at page 9, line 46 skipping to change at page 10, line 10
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 [RFC7159] for configuration.
of no DHCP server that uses this specific syntax, most modern DHCP Although we know of no DHCP server that uses this specific syntax,
server provides similar functionality. most modern DHCP server provides 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 10 skipping to change at page 11, line 21
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 192.0.2.0/26 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: 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
Relay agent is a DHCP software that may be run on any IP node. A relay agent is a 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 or that operates on a link, receiving link-local multicasts (IPv6) or
broadcasts and relaying them, using IP routing, to a DHCP server. As broadcasts (IPv4) and relaying them, using IP routing, to a DHCP
long as the relay has an IP address on the link, and a default route server. As long as the relay has an IP address on the link, and a
or more specific route through which it can reach a DHCP server, it default route or more specific route through which it can reach a
need not be a router, or even have multiple interfaces. 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 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 legal configuration. that host. That is uncommon, but a valid 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 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 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). The server will
the response back to the GIADDR address, which is the address of the send the response back to the GIADDR address, which is the address of
first relay agent that saw the client's message. That means that the the first relay agent that saw the client's message. That means that
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 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 via router B, and relay D will send it to from the server to relay D via router B, and relay D will send it to
the client on link 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 a server's
address, a multicast address or next relay agent address. The next unicast address, a multicast address or next relay agent address.
relay repeats the encapsulation process. Although the resulting The next relay repeats the encapsulation process. Although the
packet is more complex (may have up to 32 levels of encapsulation if resulting packet is more complex (may have up to 32 levels of
traveled through 32 relays), every relay may insert its own options encapsulation if the packet traveled through 32 relays), every relay
and it is clear which relay agent inserted which option. may insert its own options and it is clear which relay agent inserted
which option.
7. Regional Configuration Example 7. Regional Configuration Example
In this example, link C is a regional backbone for an ISP. Link E is In the Figure 2 example, link C is a regional backbone for an ISP.
also a regional backbone for that ISP. Relays A, B, C and D are PE Link E is also a regional backbone for that ISP. Relays A, B, C and
routers, and Links A, B, F and G are actually link aggregators with D are PE routers, and Links A, B, F and G are actually link
individual layer 2 circuits to each customer--for example, the relays aggregators with individual layer 2 circuits to each customer--for
might be DSLAMs or cable head-end systems. At each customer site we example, the relays might be DSLAMs or cable head-end systems. At
assume there is a single CPE device attached to the link. each customer 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
skipping to change at page 15, line 4 skipping to change at page 15, line 4
and DNS servers to communicate when changes are made. When changes and DNS servers to communicate when changes are made. When changes
are made to the DNS server, these changes are promptly and are made to the DNS server, these changes are promptly and
automatically adopted by the DHCP server, as long as the DNS server automatically adopted by the DHCP server, as long as the DNS server
is managed appropriately (see the next paragraph). Similarly, when is managed appropriately (see the next paragraph). Similarly, when
DHCP server configurations change, DNS server administrators need not DHCP server configurations change, DNS server administrators need not
be aware of this. be aware of this.
It should be noted that even though the DHCP server may be configured It should be noted that even though the DHCP server may be configured
to query the DNS resolver every time it uses configured names, the to query the DNS resolver every time it uses configured names, the
changes made in the DNS zone may not be visible to the server until changes made in the DNS zone may not be visible to the server until
the DNS cache expires. In general, it's the responsibility of the the DNS cache expires. In general, it is the responsibility of the
DNS zone's administrator to ensure that existing cache does not cause DNS zone's administrator to ensure that existing cache does not cause
a trouble when a change is made to the zone; it should be usually a trouble when a change is made to the zone; it should be usually
reasonable for the DHCP server to rely on it. However, if this is reasonable for the DHCP server to rely on it. However, if this is
not desired or if the management of the DNS zone is not very not desired or if the management of the DNS zone is not very
reliable, the DHCP server can be configured to query the reliable, the DHCP server can be configured to query the
authoritative DNS server directly, bypassing any caching DNS servers. 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 is 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. Multiple subnets on the same link 9. 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 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
skipping to change at page 15, line 35 skipping to change at page 15, line 35
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' in Unix environments or 'multinet' in Microsoft terminology. subnets' in Unix environments or 'multinet' in Microsoft terminology.
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 certains options or packet characteristics, e.g. presence or value of certain 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 they can't use the information to handle such configuration, as they cannot use the
topographical property of the relay addresses alone to properly topographical property of the relay addresses alone to properly
choose a subnet. Exact details of such operation is not part of the choose a subnet. Exact details of such operation is not part of the
DHCPv4 or DHCPv6 protocols and is implementation dependent. DHCPv4 or DHCPv6 protocols and is implementation dependent.
10. 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. Thanks to Andre Kostur, Carsten Strotmann, servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean- Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-
Francois Tremblay and Marcin Siodelski for their reviews, comments Francois Tremblay, Marcin Siodelski and Bernie Volz for their
and feedback. reviews, comments and feedback.
11. 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.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
13.2. Informative References 13.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000. RFC 3011, November 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[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, April 2003. Option for DHCPv4", RFC 3527, April 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[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.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
Selection Options for DHCPv4 and DHCPv6", RFC 6607, April Selection Options for DHCPv4 and DHCPv6", RFC 6607, April
2012. 2012.
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6
Reconfiguration from Relay Agents", RFC 6977, July 2013. Reconfiguration from Relay Agents", RFC 6977, July 2013.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
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. 32 change blocks. 
64 lines changed or deleted 87 lines changed or added

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