<pre>Internet Engineering Task Force (IETF)                          T. Lemon
Request for Comments: 7969                                 Nominum, Inc.
Category: Informational                                     T. Mrugalski
ISSN: 2070-1721                                                      ISC
                                                            October 2016


    <span class="h1">Customizing DHCP Configuration on the Basis of Network Topology</span>

Abstract

   DHCP servers have evolved over the years to provide significant
   functionality beyond that described in the DHCP base specifications.
   One aspect of this functionality is support for context-specific
   configuration information.  This memo describes some such features
   and explains their operation.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7969">http://www.rfc-editor.org/info/rfc7969</a>.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Identifying Client's Location by DHCP Servers . . . . . . . .   <a href="#page-3">3</a>
     <a href="#section-3.1">3.1</a>.  DHCPv4-Specific Behavior  . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.2">3.2</a>.  DHCPv6-Specific Behavior  . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-4">4</a>.  Simple Subnetted Network  . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
   <a href="#section-5">5</a>.  Relay Agent Running on a Host . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-6">6</a>.  Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-7">7</a>.  Regional Configuration Example  . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
   <a href="#section-8">8</a>.  Multiple Subnets on the Same Link . . . . . . . . . . . . . .  <a href="#page-15">15</a>
   <a href="#section-9">9</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
   <a href="#section-10">10</a>. References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
     <a href="#section-10.1">10.1</a>.  Normative References . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
     <a href="#section-10.2">10.2</a>.  Informative References . . . . . . . . . . . . . . . . .  <a href="#page-18">18</a>
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-20">20</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-20">20</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The DHCPv4 [<a href="./rfc2131" title="&quot;Dynamic Host Configuration Protocol&quot;">RFC2131</a>] and DHCPv6 [<a href="./rfc3315" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3315</a>] protocol specifications
   describe how addresses can be allocated to clients based on network
   topology information provided by the DHCP relay infrastructure.
   Address allocation decisions are integral to the allocation of
   addresses and prefixes in DHCP.

   The DHCP protocol also describes mechanisms for provisioning devices
   with additional configuration information, for example, DNS [<a href="./rfc1034" title="&quot;Domain names - concepts and facilities&quot;">RFC1034</a>]
   server addresses, default DNS search domains, and similar
   information.

   Although it was the intent of the authors of these specifications
   that DHCP servers would provision devices with configuration
   information appropriate to each device's location on the network,
   this practice was never documented, much less described in detail.

   Existing DHCP server implementations do in fact provide such
   capabilities; the goal of this document is to describe those
   capabilities for the benefit of both operators and protocol 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 most
   modern DHCP servers.








<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   o  CPE device: Customer Premise Equipment device.  Typically a router
      belonging to the customer that connects directly to the provider
      link.

   o  DHCP, DHCPv4, and DHCPv6: DHCP refers to the Dynamic Host
      Configuration Protocol in general and applies to both DHCPv4 and
      DHCPv6.  The terms DHCPv4 and DHCPv6 are used in contexts where it
      is necessary to avoid ambiguity and explain differences.

   o  PE router: Provider Edge router.  The provider router closest to
      the customer.

   o  Routable IP address: An IP address with a scope of use wider than
      the local link.

   o  Shared subnet: A case where two or more subnets of the same
      protocol family are available on the same link.  'Shared subnet'
      terminology is typically used in Unix environments.  It is
      typically called 'multinet' in the Windows environment.  The
      administrative configuration inside a Microsoft DHCP server is
      called 'DHCP Superscope'.

   o  Link or local link: A layer 2 network link, as defined in
      <a href="./rfc3297#section-1.2">Section&nbsp;1.2 of [RFC3297]</a>.

   o  Link subset: A portion of a link containing a subset of all the
      connection points on that link, which may be used to finely
      determine the physical location of a set of clients or may be used
      to determine topology to a finer degree of detail than the set of
      all locations at which that particular link is available.  The
      smallest link subset is a single link attachment point, for
      example, a port on a layer 2 switch.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Identifying Client's Location by DHCP Servers</span>

   Figure 1 illustrates a small hierarchy of network links with Link D
   serving as a backbone to which the DHCP server is attached.

   Figure 2 illustrates a more complex case.  Although some of its
   aspects are unlikely to be seen in actual production networks, they
   are beneficial for explaining finer aspects of the DHCP protocols.
   Note that some nodes act as routers (which forward all IP traffic)
   and some are relay agents (i.e., they run DHCP-specific software that
   forwards only DHCP traffic).





<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


              Link A                   Link B
           |===+===========|    |===========+======|
               |                            |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   A   |                    |   B   |
           +---+---+                    +---+---+
               |                            |
               |       Link C               |
           |===+==========+=================+======|
                          |
                          |
                     +----+---+        +--------+
                     | router |        |  DHCP  |
                     |    A   |        | Server |
                     +----+---+        +----+---+
                          |                 |
                          |                 |
                          |   Link D        |
           |==============+=================+======|
                          |
                          |
                     +----+---+
                     | router |
                     |    B   |
                     +----+---+
                          |
                          |
           |===+==========+=================+======|
               |       Link E               |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   C   |                    |   D   |
           +---+---+                    +---+---+
               |                            |
               |                            |
           |===+===========|    |===========+======|
              Link F                   Link G

        Figure 1: A Simple Network with a Small Hierarchy of Links









<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


              Link A                   Link B            Link H
           |===+==========|    |=========+======|  |======+======|
               |                         |                |
               |                         |                |
           +---+---+                 +---+---+        +---+---+
           | relay |                 | relay |        | relay |
           |   A   |                 |   B   |        |   G   |
           +---+---+                 +---+---+        +---+---+
               |                         |                |
               |       Link C            |                | Link J
           |===+==========+==============+======|  |======+======|
                          |                               |
                          |                               |
                     +----+---+        +--------+     +---+---+
                     | router |        |  DHCP  |     | relay |
                     |    A   |        | Server |     |   F   |
                     +----+---+        +----+---+     +---+---+
                          |                 |             |
                          |                 |             |
                          |   Link D        |             |
           |==============+=========+=======+=============+======|
                          |         |
                          |         |
                     +----+---+ +---+---+
                     | router | | relay |
                     |    B   | |   E   |
                     +----+---+ +---+---+
                          |         |
                          |         |
           |===+==========+=========+=======+======|
               |       Link E               |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   C   |                    |   D   |
           +---+---+                    +---+---+
               |                            |
               |                            |
           |===+===========|    |===========+======|
              Link F                   Link G

                         Figure 2: Complex Network

   These diagrams allow us to represent a variety of different network
   configurations and illustrate how existing DHCP servers can provide
   configuration information customized to the particular location from
   which a client is making its request.




<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   It is important to understand the background of how DHCP works when
   considering those diagrams.  It is assumed that the DHCP clients may
   not have routable IP addresses when they are attempting to obtain
   configuration information.

   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
   the client does not yet have an IP address configured, it cannot
   route packets to an off-link DHCP server; therefore, some kind of
   relay mechanism is required.

   The details of how packet delivery between clients and servers works
   are different between DHCPv4 and DHCPv6, but the essence is the same:
   whether or not the client actually has an IP configuration, it
   generally communicates with the DHCP server by sending its requests
   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
   server (directly or via other relays).  In later stages of the
   configuration, when the client has acquired an address and certain
   conditions are met, it is possible for the client to send packets
   directly to the server, thus bypassing the relays.  The conditions
   for such behavior are different for DHCPv4 and DHCPv6 and are
   discussed in Sections <a href="#section-3.1">3.1</a> and <a href="#section-3.2">3.2</a>.

   To determine the client's point of attachment and link-specific
   configuration, the server typically uses the client-facing IP address
   of the relay agent.  In some cases, the server may use the routable
   IP address of the client if the client has the routable IP address
   assigned to its interface and it is transmitted in the DHCP message.
   The server is then able to determine the client's point of attachment
   and select the appropriate subnet- or link-specific configuration.

   Sometimes it is useful for the relay agents to provide additional
   information about the topology.  A number of extensions have been
   defined for this purpose.  The specifics are different, but the core
   principle remains the same: the relay agent knows exactly where the
   original request came from, so it provides an identifier that will
   help the server to choose appropriate address pool and configuration
   parameters.  Examples of such options are mentioned in the following
   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 an appropriate
   subnet.  This is more complicated for DHCPv6, as the DHCPv6 server is
   not required to have any globally unique addresses.  In such cases,




<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   additional configuration information may need to be required.  Some
   servers allow indicating that a given subnet is directly reachable
   over a specific local network interface.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  DHCPv4-Specific Behavior</span>

   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.  Examples of such transmissions are
   renewal (DHCPREQUEST) and address release (DHCPRELEASE).

   The relay agent that receives the client's message sets the giaddr
   field to the address of the network interface the message was
   received on.  The relay agent may insert a relay agent option
   [<a href="./rfc3046" title="&quot;DHCP Relay Agent Information Option&quot;">RFC3046</a>].

   There are several options defined that are useful for subnet
   selection in DHCPv4.  [<a href="./rfc3527" title="&quot;Link Selection sub-option for the Relay Agent Information Option for DHCPv4&quot;">RFC3527</a>] defines the Link Selection sub-option
   that is inserted by a relay agent.  This option is particularly
   useful when the relay agent needs to specify the subnet/link on which
   a DHCPv4 client resides, which is different from an IP address that
   can be used to communicate with the relay agent.  The Virtual Subnet
   Selection (VSS) sub-option, specified in [<a href="./rfc6607" title="&quot;Virtual Subnet Selection Options for DHCPv4 and DHCPv6&quot;">RFC6607</a>], can also be added
   by a relay agent to specify information in a VPN environment.  In
   certain cases, it is useful for the client itself to specify the
   Virtual Subnet Selection option, e.g., when there are no relay agents
   involved during the VPN setup process.

   Another option that may influence the subnet selection is the IPv4
   Subnet Selection option, defined in [<a href="./rfc3011" title="&quot;The IPv4 Subnet Selection Option for DHCP&quot;">RFC3011</a>], which allows the
   client to explicitly request allocation from a given subnet.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  DHCPv6-Specific Behavior</span>

   In DHCPv6, unicast communication is possible in cases where the
   server is configured with a Server Unicast option (see <a href="./rfc3315#section-22.12">Section&nbsp;22.12
   in [RFC3315]</a>) and clients are able to take advantage of it.  In such
   cases, once a client is assigned a (presumably global) address, it is
   able to contact the server directly, bypassing any relays.  It should
   be noted that such a mode is completely controllable by
   administrators in DHCPv6.  (They may simply choose to not configure
   the Server Unicast option, thus forcing clients to always send their
   messages via relay agents in every case).

   The DHCPv6 protocol [<a href="./rfc3315" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3315</a>] defines two core mechanisms that allow
   a server to distinguish which link the relay agent is connected to.
   The first mechanism is the link-address field in the Relay-forward
   and Relay-reply messages.  The link-address field uniquely identifies



<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   the link and should not be mistaken for a link-local address.  In
   normal circumstances, this is the solution that is easiest to
   maintain, as existing address assignments can be used and no
   additional administrative actions (like assigning dedicated
   identifiers for each relay agent, making sure they are unique, and
   maintaining a list of such identifiers) are needed.  It requires,
   however, for the relay agent to have an address with a scope larger
   than link-local configured on its client-facing interface.

   The second mechanism uses an Interface-ID option (see <a href="./rfc3315#section-22.18">Section&nbsp;22.18
   of [RFC3315]</a>) inserted by the relay agent, which identifies the link
   that the client is connected to.  This mechanism may be used when the
   relay agent does not have a globally unique address or Unique Local
   Address (ULA) [<a href="./rfc4193" title="&quot;Unique Local IPv6 Unicast Addresses&quot;">RFC4193</a>] configured on its client-facing interface,
   thus making the first mechanism not feasible.  If the interface-id is
   unique within an administrative domain, the interface-id value may be
   used to select the appropriate subnet.  As there is no guarantee for
   the uniqueness ([<a href="./rfc3315" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3315</a>] 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 the interface-id values are not unique, the Interface-ID
   option cannot be used to determine the 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 an
   already relayed message further towards the server when there is more
   than one relay agent in a chain) and Relay-reply (sending back the
   response towards the client when there is more than one relay agent
   in a chain).

   For completeness, we also mention an uncommon but valid case where
   relay agents use a link-local address in the link-address field in
   relayed Relay-forward messages.  This may happen if the relay agent
   doesn't have any address with a larger scope on the interface
   connected to that specific link.  Even though link-local addresses
   cannot be automatically used to associate the relay agent with a
   given link, with additional configuration information, the server may
   still be able to select the proper link.

   This requires that the DHCP server has a way of associating a
   particular link-local address with a particular link.  The network
   administrator can then explicitly configure the DHCP server to
   recognize that the particular link-address field in a relay message
   refers to that link.





<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   There are two ways that this can work.  One is that the DHCP server
   can provide a mechanism that explicitly associates the link-local
   address with a link.  In this case, the network administrator simply
   determines the link-local address of the relay agent on a particular
   link, which we are presuming to be stable, and configures an
   association between that address and the link.

   If the DHCP server doesn't explicitly provide such a mechanism, it
   may still provide a "shared subnet" mechanism (see <a href="#section-8">Section 8</a>).  If it
   does, the shared subnet mechanism can be used to explicitly associate
   a link-local address with a link.  To do this, the network
   administrator creates a shared subnet association for the link, if
   one does not already exist.  The network administrator then
   configures a /128 subnet that contains just the link-local address of
   the relay agent.  The administrator then adds this new /128 to the
   shared subnet.  Now, when a DHCP message comes in with that link-
   layer address in the link-address field, the correct shared network
   will be selected.

   DHCPv6 also has support for more finely grained link identification
   using Lightweight DHCPv6 Relay Agents (LDRAs) [<a href="./rfc6221" title="&quot;Lightweight DHCPv6 Relay Agent&quot;">RFC6221</a>].  In this
   case, the link-address field is set to an unspecified address (::),
   but the DHCPv6 server also receives an Interface-ID option from the
   relay agent that can be used to more precisely identify the client's
   location on the network.  It is possible to mix LDRA and regular
   relay agents in the same network.  See Sections <a href="#section-7.2">7.2</a> and <a href="#section-7.3">7.3</a> in
   [<a href="./rfc6221" title="&quot;Lightweight DHCPv6 Relay Agent&quot;">RFC6221</a>] for detailed examples.

   What this means in practice is that the DHCP server has sufficient
   information in all cases to pinpoint the link to which the client is
   connected.  In some cases, it may additionally be possible to
   pinpoint the particular link subset to which the client is connected.

   In all cases, then, the DHCPv6 server will have a link-identifying IP
   address, and in some cases, it may also have a link-specific
   identifier (e.g., the Interface-ID option or the Link Address option
   defined in <a href="./rfc6977#section-5">Section&nbsp;5 of [RFC6977]</a>).  It should be noted that the
   link-specific identifier is unique only within the scope of the link-
   identifying IP address.  For example, the link-specific identifier of
   "eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is
   distinct from an "eth0" identifier used by a different relay agent
   with address 2001:db8::2.

   It is also possible for link-specific identifiers to be nested so
   that the actual identifier that identifies the specific link subset
   is an aggregate of two or more identifiers sent by a set of LDRAs in
   a chain; in general, this functions exactly as if a single identifier
   were received from a single LDRA, so we do not treat it specially in



<span class="grey">Lemon &amp; Mrugalski             Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   the discussion below, but sites that use chained LDRA configurations
   will need to be aware of this when configuring their DHCPv6 servers.

   The Virtual Subnet Selection options, present in DHCPv4, are also
   defined for DHCPv6.  The use case is the same as in DHCPv4: the relay
   agent inserts VSS options that can help the server to select the
   appropriate subnet with its address pool and associated configuration
   options.  See [<a href="./rfc6607" title="&quot;Virtual Subnet Selection Options for DHCPv4 and DHCPv6&quot;">RFC6607</a>] for details.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Simple Subnetted Network</span>

   Consider Figure 1 in the context of a simple subnetted network.  In
   this network, there are four leaf subnets on which DHCP clients will
   be configured: Links A, B, F, and G.  Relays A, B, C, and D in this
   example are represented in the diagram as IP routers with an embedded
   relay function, because this is a very typical configuration, but the
   relay function can also be provided in a separate node on each link.

   In a simple network like this, there may be no need for link-specific
   configuration in DHCPv6, since local routing information is delivered
   through router advertisements.  However, in IPv4, it is very typical
   to configure the default route using DHCP; in this case, the default
   route will be different on each link.  In order to accomplish this,
   the DHCP server will need link-specific configuration for the default
   route.

   To illustrate, we will use an example from a hypothetical DHCP server
   that uses a simple JSON notation [<a href="./rfc7159" title="&quot;The JavaScript Object Notation (JSON) Data Interchange Format&quot;">RFC7159</a>] for configuration.
   Although we know of no DHCP server that uses this specific syntax,
   most modern DHCP servers provide similar functionality.





















<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   {
       "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: Configuration Example

   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
   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
   only has one value, and that value is the IP address of the router
   specific to the prefix.

   When the DHCP server receives a request, it searches the list of
   prefixes for one that encloses the link-identifying IP address
   provided by the client or relay agent.  The DHCP server then examines
   the options list associated with that prefix and returns those
   options to the client.

   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 DHCP server would match it to that prefix.  Based on the
   configuration, the DHCP server would then return a routers option



<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   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
   would receive a routers option containing the IP address 192.0.2.129.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Relay Agent Running on a Host</span>

   A relay agent is DHCP software that may be run on any IP node.
   Although it is typically run on a router, this is by no means
   required by the DHCP protocol.  The relay agent is simply a service
   that operates on a link, receiving link-local multicasts (IPv6) or
   broadcasts (IPv4) and relaying them, using IP routing, to a DHCP
   server.  As long as the relay has an IP address on the link and a
   default route or a more specific route through which it can reach a
   DHCP server, it need not be a router or even have multiple
   interfaces.

   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
   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
   that host.  That is uncommon but is a valid configuration.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Cascaded Relays</span>

   Let's observe another case, shown in Figure 2.  Note that in this
   configuration, the clients connected to Link G will send their
   requests to relay D, which will forward its packets directly to the
   DHCP server.  That is typical but not the only possible
   configuration.  It is possible to configure relay agent D to forward
   client messages to relay E, which in turn will send them to the DHCP
   server.  This configuration is sometimes referred to as "cascaded
   relay agents".

   Note that the relaying mechanism works differently in DHCPv4 and in
   DHCPv6.  In DHCPv4, only the first relay is able to set the giaddr
   field in the DHCPv4 packet.  Any following relays that receive that
   packet will not change it as the server needs giaddr information from
   the first relay (i.e., the closest to the client).  The server will
   send the response back to the giaddr address, which is the address of
   the first relay agent that saw the client's message.  That means that
   the client messages travel on a different path than the server's
   responses.  A message from a client connected to Link G will pass
   through relay D, then through relay E, to reach the server.  A
   response message will be sent from the server to relay D via router
   B, and relay D will send it to the client on Link G.






<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   Relaying in DHCPv6 is more structured.  Each relay agent encapsulates
   a packet that is destined to the server and sends it towards the
   server.  Depending on the configuration, that can be a server's
   unicast address, a multicast address, or the next relay agent
   address.  The next relay repeats the encapsulation process.  Although
   the resulting packet is more complex (may have up to 32 levels of
   encapsulation if the packet traveled through 32 relays), every relay
   may insert its own options, and it is clear which relay agent
   inserted which option.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Regional Configuration Example</span>

   In the Figure 2 example, Link C is a regional backbone for an ISP.
   Link E is also a regional backbone for that ISP.  Relays A, B, C, and
   D are PE routers, and Links A, B, F, and G are actually link
   aggregators with individual layer 2 circuits to each customer -- for
   example, the relays might be Digital Subscriber Line Access
   Multiplexers (DSLAMs) or cable head-end systems.  At 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
   single prefix, although it would be equally valid for each CPE device
   to be numbered on a separate prefix.

   In a real-world deployment, there would likely be many more than two
   PE routers connected to each regional backbone; we have kept the
   number small for simplicity.

   In the example presented in Figure 4, the goal is to configure all
   the devices within a region with server addresses local to that
   region, so that service traffic does not have to be routed between
   regions unnecessarily.



















<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


{
    "prefixes": {
        "2001:db8::/40": {
            "on-link": ["A"]
        },
        "2001:db8:100::/40": {
            "on-link": ["B"]
        },
        "2001:db8:200::/40": {
            "on-link": ["F"]
        },
        "2001:db8:300::/40": {
            "on-link": ["G"]
        }
    },
    "links": {
        "A": {"region": "omashu"},
        "B": {"region": "omashu"},
        "F": {"region": "gaoling"},
        "G": {"region": "gaoling"}
    },
   "regions": {
       "omashu": {
           "options": {
               "SIP Server": ["sip.omashu.example.org"],
               "DNS Recursive Name Server": ["dns1.omashu.example.org",
                               "dns2.omashu.example.org"]
           }
       },
       "gaoling": {
           "options": {
               "SIP Server": ["sip.gaoling.example.org"],
               "DNS Recursive Name Server": ["dns1.gaoling.example.org",
                               "dns2.gaoling.example.org"]
           }
        }
    }
}

                 Figure 4: Regional Configuration Example

   In this example, when a request comes in to the DHCPv6 server with a
   link-identifying IP address in the 2001:db8::/40 prefix, it is
   identified as being on Link A.  The DHCPv6 server then looks on the
   list of links to see what region the client is in.  Link A is
   identified as being in omashu.  The DHCPv6 server then looks up
   omashu in the set of regions and discovers a list of region-specific
   options.



<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   The DHCPv6 server then resolves the domain names listed in the
   options and sends a SIP Server option containing the IP addresses
   that the resolver returned for sip.omashu.example.org and a DNS
   Recursive Name Server option containing the IP addresses returned by
   the resolver for dns1.omashu.example.org and dns2.omashu.example.org.
   Depending on the server capability and configuration, it may cache
   resolved responses for a specific period of time, repeat queries
   every time, or even keep the response until reconfiguration or
   shutdown.  For more detailed discussion, see <a href="./rfc7227#section-7">Section&nbsp;7 of [RFC7227]</a>.

   Similarly, if the DHCPv6 server receives a request from a DHCPv6
   client where the link-identifying IP address is contained by the
   prefix 2001:db8:300::/40, then the DHCPv6 server identifies the
   client as being connected to Link G.  The DHCPv6 server then
   identifies Link G as being in the gaoling region and returns the SIP
   Server and DNS Recursive Name Server options specific to that region.

   As with the previous example, the exact configuration syntax and
   structure shown above does not precisely match what existing DHCPv6
   servers do, but the behavior illustrated in this example can be
   accomplished with most existing modern DHCPv6 servers.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Multiple Subnets on the Same Link</span>

   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
   subnets) configured on the same link.  Such a configuration is often
   referred to as 'shared subnets' in Unix environments or 'multinet' in
   Microsoft terminology.

   The most frequently mentioned use case is a network renumbering where
   some services are migrated to the new addressing scheme, but some
   aren't yet.

   A second example is expanding the allocation space.  In DHCPv4 and
   for DHCPv6 Prefix Delegation, there could be cases where multiple
   subnets are needed, because a single subnet may be too small to
   accommodate the client population.

   The third use case covers allocating addresses (or delegation
   prefixes) that are not the same as topological information.  For
   example, the link-address is on prefix X, and the addresses to be
   assigned are on prefix Y.  This could be based on differentiating
   information (i.e., whether the device is a CPE or cable modem in the
   Data Over Cable Service Interface Specification (DOCSIS)) or just
   because the link-address/giaddr is different from the actual
   allocation space.




<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   The fourth use case is a cable network, where cable modems and the
   devices connected behind them are connected to the same layer 2 link.
   However, operators want the cable modems and user devices to get
   addresses from distinct address spaces, so users couldn't easily
   access their modems' management interfaces.

   To support such a configuration, additional differentiating
   information is required.  Many DHCP server implementations offer a
   feature that is typically called "client classification".  The server
   segregates incoming packets into one or more classes based on certain
   packet characteristics, e.g., the presence or value of certain
   options or even a match between existing options.  Servers require
   additional information to handle such configuration, as they cannot
   use the topographical property of the relay addresses alone to
   properly choose a subnet.  Exact details of such an operation are not
   part of the DHCPv4 or DHCPv6 protocols and are implementation
   dependent.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   This document explains existing practice with respect to the use of
   Dynamic Host Configuration Protocol [<a href="./rfc2131" title="&quot;Dynamic Host Configuration Protocol&quot;">RFC2131</a>] and Dynamic Host
   Configuration Protocol Version 6 [<a href="./rfc3315" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3315</a>].  The security
   considerations for these protocols are described in their
   specifications and in related documents that extend these protocols.

   The mechanisms described in this document could possibly be exploited
   by an attacker to misrepresent its point of attachment in the
   network.  This would cause the server to assign addresses, prefixes,
   and other configuration options, which can be considered a leak of
   information.  In particular, this could be used as a preliminary
   stage of an attack when the DHCP server leaks information about
   available services in parts of the network the attacker does not have
   access to.

   There are several ways that such an attack can be prevented.  First,
   it is a common practice to filter DHCP traffic passing to clients
   within a particular administrative domain from outside of that
   domain, and also to filter DHCP traffic to clients outside of a
   particular administrative domain from within that domain.  Second,
   the DHCP servers can be configured to not respond to traffic that is
   coming from unknown subnets (i.e., those subnets the server is not
   configured to serve).  Third, some relays provide the ability to
   reject messages that do not fit expected characteristics.  For
   example, the Cable Modem Termination System (CMTS) acting as a DHCP
   relay detects if the Media Access Control (MAC) address specified in
   chaddr in incoming DHCP messages matches the MAC address of the cable
   modem it came from and can alter its behavior accordingly.  Also,



<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   relay agents and servers that are connected to clients directly can
   reject traffic that looks as if it has passed a relay (this could
   indicate the client is attempting to spoof a relay, possibly to
   inject forged relay options).

   There are a number of general DHCP recommendations that should be
   considered in all DHCP deployments.  While not strictly related to
   the mechanisms described in this document, they may be useful in
   certain deployment scenarios.  [<a href="./rfc7819" title="&quot;Privacy Considerations for DHCP&quot;">RFC7819</a>] and [<a href="./rfc7824" title="&quot;Privacy Considerations for DHCPv6&quot;">RFC7824</a>] provide an
   analysis of privacy problems in DHCPv4 and DHCPv6, respectively.  If
   those are of concern, [<a href="./rfc7844" title="&quot;Anonymity Profiles for DHCP Clients&quot;">RFC7844</a>] offers mitigation steps.

   Current DHCPv4 and DHCPv6 standards lack strong cryptographic
   protection.  There is an ongoing effort in the DHC working group to
   address this.  [<a href="#ref-SECURE-DHCPv6">SECURE-DHCPv6</a>] attempts to provide a mechanism for
   strong authentication and encryption between DHCPv6 clients and
   servers.  [<a href="#ref-SECURITY-MESSAGES">SECURITY-MESSAGES</a>] attempts to improve security of
   exchanges between DHCP relay agents and servers.

   Another possible attack vector is to set up a rogue DHCP server and
   provide clients with false information, either as a denial of service
   or to execute a man-in-the-middle type of attack.  This can be
   mitigated by deploying DHCPv6-Shield [<a href="./rfc7610" title="&quot;DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers&quot;">RFC7610</a>].

   Finally, there is an ongoing effort to update the DHCPv6
   specification, which is currently 13 years old.  Sections <a href="#section-21">21</a>
   ("Security Considerations") and 22 ("Privacy Considerations") of
   [<a href="#ref-DHCPv6bis">DHCPv6bis</a>] contain more recent analysis of the security and privacy
   considerations.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC2131">RFC2131</a>]  Droms, R., "Dynamic Host Configuration Protocol",
              <a href="./rfc2131">RFC 2131</a>, DOI 10.17487/RFC2131, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2131">http://www.rfc-editor.org/info/rfc2131</a>&gt;.

   [<a id="ref-RFC3315">RFC3315</a>]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, DOI 10.17487/RFC3315, July
              2003, &lt;<a href="http://www.rfc-editor.org/info/rfc3315">http://www.rfc-editor.org/info/rfc3315</a>&gt;.









<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-DHCPv6bis">DHCPv6bis</a>]
              Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
              bis", Work in Progress, <a href="./draft-ietf-dhc-rfc3315bis-05">draft-ietf-dhc-rfc3315bis-05</a>, June
              2016.

   [<a id="ref-RFC1034">RFC1034</a>]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, <a href="./rfc1034">RFC 1034</a>, DOI 10.17487/RFC1034, November 1987,
              &lt;<a href="http://www.rfc-editor.org/info/rfc1034">http://www.rfc-editor.org/info/rfc1034</a>&gt;.

   [<a id="ref-RFC3011">RFC3011</a>]  Waters, G., "The IPv4 Subnet Selection Option for DHCP",
              <a href="./rfc3011">RFC 3011</a>, DOI 10.17487/RFC3011, November 2000,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3011">http://www.rfc-editor.org/info/rfc3011</a>&gt;.

   [<a id="ref-RFC3046">RFC3046</a>]  Patrick, M., "DHCP Relay Agent Information Option",
              <a href="./rfc3046">RFC 3046</a>, DOI 10.17487/RFC3046, January 2001,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3046">http://www.rfc-editor.org/info/rfc3046</a>&gt;.

   [<a id="ref-RFC3297">RFC3297</a>]  Klyne, G., Iwazaki, R., and D. Crocker, "Content
              Negotiation for Messaging Services based on Email",
              <a href="./rfc3297">RFC 3297</a>, DOI 10.17487/RFC3297, July 2002,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3297">http://www.rfc-editor.org/info/rfc3297</a>&gt;.

   [<a id="ref-RFC3527">RFC3527</a>]  Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
              "Link Selection sub-option for the Relay Agent Information
              Option for DHCPv4", <a href="./rfc3527">RFC 3527</a>, DOI 10.17487/RFC3527, April
              2003, &lt;<a href="http://www.rfc-editor.org/info/rfc3527">http://www.rfc-editor.org/info/rfc3527</a>&gt;.

   [<a id="ref-RFC4193">RFC4193</a>]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", <a href="./rfc4193">RFC 4193</a>, DOI 10.17487/RFC4193, October 2005,
              &lt;<a href="http://www.rfc-editor.org/info/rfc4193">http://www.rfc-editor.org/info/rfc4193</a>&gt;.

   [<a id="ref-RFC6221">RFC6221</a>]  Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
              Kavanagh, "Lightweight DHCPv6 Relay Agent", <a href="./rfc6221">RFC 6221</a>,
              DOI 10.17487/RFC6221, May 2011,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6221">http://www.rfc-editor.org/info/rfc6221</a>&gt;.

   [<a id="ref-RFC6607">RFC6607</a>]  Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
              Selection Options for DHCPv4 and DHCPv6", <a href="./rfc6607">RFC 6607</a>,
              DOI 10.17487/RFC6607, April 2012,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6607">http://www.rfc-editor.org/info/rfc6607</a>&gt;.







<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


   [<a id="ref-RFC6977">RFC6977</a>]  Boucadair, M. and X. Pougnard, "Triggering DHCPv6
              Reconfiguration from Relay Agents", <a href="./rfc6977">RFC 6977</a>,
              DOI 10.17487/RFC6977, July 2013,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6977">http://www.rfc-editor.org/info/rfc6977</a>&gt;.

   [<a id="ref-RFC7159">RFC7159</a>]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", <a href="./rfc7159">RFC 7159</a>, DOI 10.17487/RFC7159, March
              2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7159">http://www.rfc-editor.org/info/rfc7159</a>&gt;.

   [<a id="ref-RFC7227">RFC7227</a>]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              <a href="https://www.rfc-editor.org/bcp/bcp187">BCP 187</a>, <a href="./rfc7227">RFC 7227</a>, DOI 10.17487/RFC7227, May 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7227">http://www.rfc-editor.org/info/rfc7227</a>&gt;.

   [<a id="ref-RFC7610">RFC7610</a>]  Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
              Protecting against Rogue DHCPv6 Servers", <a href="https://www.rfc-editor.org/bcp/bcp199">BCP 199</a>,
              <a href="./rfc7610">RFC 7610</a>, DOI 10.17487/RFC7610, August 2015,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7610">http://www.rfc-editor.org/info/rfc7610</a>&gt;.

   [<a id="ref-RFC7819">RFC7819</a>]  Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
              Considerations for DHCP", <a href="./rfc7819">RFC 7819</a>, DOI 10.17487/RFC7819,
              April 2016, &lt;<a href="http://www.rfc-editor.org/info/rfc7819">http://www.rfc-editor.org/info/rfc7819</a>&gt;.

   [<a id="ref-RFC7824">RFC7824</a>]  Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
              Considerations for DHCPv6", <a href="./rfc7824">RFC 7824</a>,
              DOI 10.17487/RFC7824, May 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7824">http://www.rfc-editor.org/info/rfc7824</a>&gt;.

   [<a id="ref-RFC7844">RFC7844</a>]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              Profiles for DHCP Clients", <a href="./rfc7844">RFC 7844</a>,
              DOI 10.17487/RFC7844, May 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7844">http://www.rfc-editor.org/info/rfc7844</a>&gt;.

   [<a id="ref-SECURE-DHCPv6">SECURE-DHCPv6</a>]
              Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
              Zhang, "Secure DHCPv6", Work in Progress,
              <a href="./draft-ietf-dhc-sedhcpv6-14">draft-ietf-dhc-sedhcpv6-14</a>, October 2016.

   [<a id="ref-SECURITY-MESSAGES">SECURITY-MESSAGES</a>]
              Volz, B. and Y. Pal, "Security of Messages Exchanged
              Between Servers and Relay Agents", Work in Progress,
              <a href="./draft-volz-dhc-relay-server-security-02">draft-volz-dhc-relay-server-security-02</a>, September 2016.









<span class="grey">Lemon &amp; Mrugalski             Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7969">RFC 7969</a>               DHCP Topology Customization          October 2016</span>


Acknowledgements

   Thanks to Dave Thaler for suggesting that even though "everybody
   knows" how DHCP servers are deployed in the real world, it might be
   worthwhile to have an IETF document that explains what everybody
   knows, because in reality not everybody is an expert in how DHCP
   servers are administered.  Thanks to Andre Kostur, Carsten Strotmann,
   Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun,
   Jean-Francois Tremblay, Marcin Siodelski, Bernie Volz, and Yaron
   Sheffer for their reviews, comments, and feedback.

Authors' Addresses

   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway, Suite 100
   Redwood City, CA  94065
   United States of America

   Phone: +1-650-381-6000
   Email: Ted.Lemon@nominum.com


   Tomek Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   United States of America

   Phone: +1-650-423-1345
   Email: tomasz.mrugalski@gmail.com




















Lemon &amp; Mrugalski             Informational                    [Page 20]
</pre>