draft-ietf-dhc-topo-conf-03.txt   draft-ietf-dhc-topo-conf-04.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: March 26, 2015 Internet Systems Consortium, Inc. Expires: July 13, 2015 ISC
September 22, 2014 January 9, 2015
Customizing DHCP Configuration on the Basis of Network Topology Customizing DHCP Configuration on the Basis of Network Topology
draft-ietf-dhc-topo-conf-03 draft-ietf-dhc-topo-conf-04
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 March 26, 2015. This Internet-Draft will expire on July 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Identifying Client's Location by DHCP Servers . . . . . . . . 3
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 8 3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 6
5. Relay agent running on a host . . . . . . . . . . . . . . . . 10 3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7
6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 10 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9
7. Regional Configuration Example . . . . . . . . . . . . . . . 11 5. Relay agent running on a host . . . . . . . . . . . . . . . . 11
8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 13 6. Cascade relays . . . . . . . . . . . . . . . . . . . . . . . 11
9. Multiple subnets on the same link . . . . . . . . . . . . . . 14 7. Regional Configuration Example . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Dynamic Lookup . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Multiple subnets on the same link . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 3, line 18 skipping to change at page 3, line 18
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. 'Share 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. Locality 3. Identifying Client's Location by DHCP Servers
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. 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).
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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 This diagram allows 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's important to understand the background of how DHCP works when
considering this diagram. DHCP clients are assumed not to have considering this diagram. It is assumed that the DHCP clients may
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. In some cases in DHCPv4, when a DHCP client has a routable server (directly or via other relays). In later stages of the
IPv4 address, the message is unicast to the DHCP server rather than configuration when the client has aquired an address and certain
going through a relay agent. In DHCPv6 that is also possible in case conditions are met, it is possible for the client to send packets
where the server is configured with a Server Unicast option (see directly to the server, thus bypassing the relays. The conditions
Section 22.12 in [RFC3315]) and clients are able to take advantage of for such behavior are different for DHCPv4 and DHCPv6 and are
it. In such case once the clients get their (presumably global) discussed in sections Section 3.1 and Section 3.2.
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
not configure server unicast option, thus forcing clients to send
their messages always via relay agents).
In all cases, the DHCP server is able to obtain an IP address that it The DHCP server uses an IP address from the client's message which is
knows is on-link for the link to which the DHCP client is connected: on the same link as the client to perform address assignment
either the DHCPv4 client's routable IPv4 address, or the relay decisions or to select subnet-specific configuration for the client.
agent's IPv4 address on the link to which the client is connected. The address that the server uses is the DHCP client's routable IP
So in every case the server is able to determine the client's point address or the client facing address of the relay agent. The server
of attachment and select appropriate subnet- or link-specific is then able to determine the client's point of attachment and select
configuration. appropriate subnet- or link-specific configuration.
In the DHCPv6 protocol, there are two mechanisms defined in [RFC3315] Sometimes it is useful for the relay agents to provide additional
that allow server to distinguish which link the relay agent is about the topology. A number of extensions have been defined for
connected to. The first mechanism is a link-address field in the this purpose. The specifics are different, but the core principle
RELAY-FORW and RELAY-REPL messages. Somewhat contrary to its name, remains the same: the relay agent knows exactly where the original
relay agents insert in the link-address field an address that is request came from, so it provides an indentifier that will help the
typically global and can be used to uniquely identify the link on server to choose appropriate address pool and configuration
parameters. Examples of such options are mentioned in the following
sections.
3.1. DHCPv4 Specific Behavior
In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4
address, the message is unicast to the DHCPv4 server rather than
going through a relay agent.
There are several options defined that are useful for subnet
selection in DHCPv4. [RFC3527] defines Link Selection sub-option
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
client resides, which is different from an IP address that can be
used to communicate with the relay agent. Virtual Subnet Selection
Option, specified in [RFC6607] is used for the same purpose (i.e.
relay agents insert that information), but it also covers additional
use cases in VPN environment. In certain cases it is useful for the
client itself to specify this option, e.g. when there are no relay
agents involved during VPN set up process.
Another option that may influence the subnet selection is IPv4 Subnet
Selection Option, defined in [RFC3011], which allows the client to
explicitly request allocation from a given subnet.
3.2. DHCPv6 Specific Behavior
In DHCPv6 unicast communication is possible in case where the server
is configured with a Server Unicast option (see Section 22.12 in
[RFC3315]) and clients are able to take advantage of it. In such
case once the clients get their (presumably global) 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 not configure server unicast
option, thus forcing clients to send their messages always via relay
agents in every case).
In the DHCPv6 protocol, there are two core mechanisms defined in
[RFC3315] that allow server to distinguish which link the relay agent
is connected to. The first mechanism is a link-address field in the
Relay-forward and Relay-reply messages. Somewhat contrary to its
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
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. It requires, however, for the solution that is easiest to maintain, as existing address assignments
relay agent to have an address with a scope larger than link-local can be used and no additional administrative actions (like assigning
configured on its client-facing interface. If for whatever reason dedicated identifers for each relay agent, making sure they are
that is not feasible (e.g. because the relay agent does not have a unique and maintaining a list of such identifiers) are needed. It
global address configured on the client-facing interface), the relay requires, however, for the relay agent to have an address with a
agent includes an Interface-Id option (see Section 22.18 of scope larger than link-local configured on its client-facing
[RFC3315]) that identifies the link clients are connected to. It is interface.
up to administrator to make sure that the interface-id is unique
within his administrative domain. It should be noted that RELAY-FORW If for whatever reason that is not feasible (e.g. because the relay
and RELAY-REPL messages are exchanged between relays and servers agent does not have a global address or ULA [RFC4193] configured on
only. Clients are never exposed to those messages. Also, servers the client-facing interface), the relay agent includes an Interface-
never receive RELAY-REPL messages. Relay agents must be able to Id option (see Section 22.18 of [RFC3315]) that identifies the link
process both RELAY-FORW (sending already relayed message further clients are connected to. If the interface-id is unique within an
towards the server, when there is more than one relay agent in a administrative domain, the interface-id value may be used to select
chain) and RELAY-REPL (when sending back the response towards the appropriate subnet. As there is no guarantee for the uniqueness
client, when there is more than one relay agent in a chain). ([RFC3315] only mandates the interface-id to be unique within a
single relay agent context), it is up to the administrator to check
whether the relay agents deployed use unique interface-id values. If
they aren't, Interface-id cannot be used to determine client's point
of attachment.
It should be noted that Relay-forward and Relay-reply messages are
exchanged between relays and servers only. Clients are never exposed
to those messages. Also, servers never receive Relay-reply messages.
Relay agents must be able to process both Relay-forward (sending
already relayed message further towards the server, when there is
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
relay agent in a chain).
For completeless, we also mention an uncommon, but valid case, where For completeless, 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-FORW 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 can't be automatically used to associate relay agent with a
given link, with sufficient information provided the server is still given link, with sufficient information provided the server is still
able to correctly select proper link. That requires the DHCP server able to correctly select the proper link. That requires the DHCP
software to be able to specify relay agent link-address or a feature server software to be able to specify relay agent link-address or a
similar to 'shared subnets' (see Section 9). Network administrator feature similar to 'shared subnets' (see Section 9). Network
has to manually configure additional information that a given subnet administrator has to manually configure additional information that a
uses a relay agent with link-address X. Alternatively, if the relay given subnet uses a relay agent with link-address X. Alternatively,
agent uses link address X and relays messages from a subnet A, an if the relay agent uses link address X and relays messages from a
administrator can configure that subnet A is a shared subnet with a subnet A, an administrator can configure that subnet A is a shared
very small X/128 subnet. That is not a recommended configuration, subnet with a very small X/128 subnet. That is not a recommended
but in cases where it is impossible for relay agents to get an configuration, but in cases where it is impossible for relay agents
address from the subnet they are relaying from, it may be a viable to get an address from the subnet they are relaying from, it may be a
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, 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-Id option from the relay agent that can be used receives an Interface-Id option from the relay agent that can be used
to more precisely identify the client's location on the network. to more precisely identify the client's 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
in Section 5 of [RFC6977]). It should be noted that there is no in Section 5 of [RFC6977]). It should be noted that there the link-
guarantee that the link-specific identifier will be unique outside specific identifier is unique only within the scope of the link-
the scope of the link-identifying IP address. identifying IP address. For example, link-specific indentifier of
"eth0" for a relay agent with IPv4 address 192.0.2.1 means something
different than "eth0" for a relay agent with address 192.0.2.123.
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 The Virtual Subnet Selection Options, present in DHCPv4, are also
server can deliver targeted supplemental configuration information to defined for DHCPv6. The use case is the same as in DHCPv4: the relay
DHCP clients. agent inserts VSS options that can help the server to select the
appropriate subnet with its address pool and associated configuration
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: 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 node on each link. relay function can also be provided in a separate node on each link.
skipping to change at page 9, line 11 skipping to change at page 10, line 11
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, most modern DHCP of no DHCP server that uses this specific syntax, most modern DHCP
server provides similar functionality. 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": {
"options": { "options": {
"routers": ["192.0.2.65"] "routers": ["192.0.2.65"]
}, },
"on-link": ["b"] "on-link": ["B"]
}, },
"192.0.2.128/26": { "192.0.2.128/26": {
"options": { "options": {
"routers": ["192.0.2.129"] "routers": ["192.0.2.129"]
}, },
"on-link": ["f"] "on-link": ["F"]
}, },
"192.0.2.192/26": { "192.0.2.192/26": {
"options": { "options": {
"routers": ["192.0.2.193"] "routers": ["192.0.2.193"]
}, },
"on-link": ["g"] "on-link": ["G"]
} }
} }
} }
Figure 3: Configuration example 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
skipping to change at page 13, line 45 skipping to change at page 14, line 45
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, most modern DHCP servers handle name resolution by querying However, most modern DHCP servers handle name resolution by querying
the resolver each time a DHCP packet comes in. This means that if the resolver each time a DHCP packet comes in. This means that if
DHCP servers and DNS servers are managed by different administrative DHCP servers and DNS servers are managed by different administrative
entities, there is no need for the administrators of the DHCP servers entities, there is no need for the administrators of the DHCP servers
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. Similarly, when DHCP automatically adopted by the DHCP server, as long as the DNS server
server configurations change, DNS server administrators need not be is managed appropriately (see the next paragraph). Similarly, when
aware of this. DHCP server configurations change, DNS server administrators need not
be aware of this.
However, it should be noted that even though the DHCP server may be It should be noted that even though the DHCP server may be configured
configured to query the DNS server every time it uses configured to query the DNS resolver every time it uses configured names, the
names, the changes made in the DNS zone may not be visible to the changes made in the DNS zone may not be visible to the server until
server until the DNS cache expires. If this is not desired, the DHCP the DNS cache expires. In general, it's the responsibility of the
server can be configured to query the authoritative DNS server DNS zone's administrator to ensure that existing cache does not cause
directly, bypassing any caching DNS servers. 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
not desired or if the management of the DNS zone is not very
reliable, 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. 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
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' in Unix environments or 'multinet' in Microsoft terminology. subnets' in Unix environments or 'multinet' in Microsoft terminology.
To support such an 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 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 they 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. Exact details of such operation is not part of the
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 and Suresh Krishnan for their reviews, Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-
comments and feedback. Francois Tremblay and Marcin Siodelski for their 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 15, line 29 skipping to change at page 16, line 36
[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.
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",
RFC 3011, November 2000.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
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
Selection Options for DHCPv4 and DHCPv6", RFC 6607, April
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.
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
 End of changes. 28 change blocks. 
99 lines changed or deleted 177 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/