One document matched: draft-ietf-dhc-relay-id-suboption-07.xml

<?xml version="1.0"?>

<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2131 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
    <!ENTITY rfc3046 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'>
    <!ENTITY rfc3315 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
    <!ENTITY rfc4030 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4030.xml'>
    <!ENTITY rfc4388 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'>
    <!ENTITY rfc5107 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5107.xml'>
    <!ENTITY rfc5226 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
]>

<rfc ipr="trust200902"
     docName="draft-ietf-dhc-relay-id-suboption-07.txt"
     category="std">

<front>

<title abbrev="The Relay Agent Id Suboption">
The DHCPv4 Relay Agent Identifier Suboption
</title>

<author initials="M." surname="Stapp" fullname="Mark Stapp">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Massachusetts Ave.</street>
<city>Boxborough</city> <region>MA</region> <code>01719</code>
<country>USA</country>
</postal>
<phone>+1 978 936 0000</phone>
<email>mjs@cisco.com</email>
</address>
</author>

<date day="7" month="July" year="2009"></date>
<workgroup>DHC</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>DHCP</keyword>
<keyword>IPv6</keyword>
<keyword>relay</keyword>
<keyword>DHCPv6</keyword>

<abstract>

<t>
This memo defines a new Relay Agent Identifier suboption for the
Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information
option. The suboption carries a value that uniquely identifies the
relay agent device. The value may be administratively-configured or
may be generated by the relay agent. The suboption allows a DHCP relay
agent to include the identifier in the DHCP messages it sends.
</t>

</abstract>

</front>

<middle>

<!--------------------------->

<section title="Introduction" anchor="section.intro">

<t>
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) <xref
target="RFC2131" /> provides IP addresses and configuration
information for IPv4 clients. It includes a relay agent capability, in
which network elements receive broadcast messages from clients and
forward them to DHCP servers as unicast messages. In many network
environments, relay agents add information to the DHCP messages before
forwarding them, using the Relay Agent Information option <xref
target="RFC3046"/>. Servers that recognize the relay information
option echo it back in their replies.
</t>

<t>
This specification introduces a Relay Agent Identifier suboption for
the Relay Information option. The Relay-Id suboption carries a
sequence of octets that is intended to identify the relay agent
uniquely within the administrative domain. The identifier may be
administratively configured: in some networks it may be adequate to
assign ASCII strings such as "switch1" and "switch2". Alternatively,
the identifier may be generated by the relay agent itself, and we
specify use of DUIDs <xref target="RFC3315"/> for this purpose.
</t>

</section>

<!-- =============================================================== -->

<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>

<t>
DHCPv4 terminology is defined in <xref target="RFC2131"/>, and the
DHCPv4 Relay Agent Information Option in <xref
target="RFC3046"/>. DUID terminology is in <xref target="RFC3315"/>.
</t>

</section>

<!-- ===============================================================-->

<section title="Example Use-Cases">

<section title="Industrial Ethernet">

<t>
DHCP typically identifies clients based on information in their DHCP
messages - such as the Client-Identifier option, or the value of the
chaddr field. In some networks, however, the location of a client -
its point of attachment to the network - is a more useful
identifier. In factory-floor networks (commonly called 'Industrial'
networks), for example, the role a device plays is often fixed and
based on its location. Using manual address configuration is possible
(and is common) but it would be beneficial if DHCP configuration
could be applied to these networks.
</t>

<t>
One way to provide connection-based identifiers for industrial
networks is to have the network elements acting as DHCP relay agents
supply information that a DHCP server could use as a client
identifier. A straightforward way to form identifier information is to
combine something that is unique within the scope of the network
element, such as a port/slot value, with something that uniquely
identifies that network element, such as a Relay Agent Identifier.
</t>

</section>

<!-- ===============================================================-->

<section title="Bulk Leasequery">

<t>
There has been quite a bit of recent interest in extending the DHCP
Leasequery protocol <xref target="RFC4388"/> to accommodate some
additional situations. There is a recent draft (<xref
target="draft-kinnear"/>) proposing a variety of enhancements to the
existing Leasequery protocol. The draft describes a use-case where a
relay agent queries DHCP servers using the Relay Identifier to
retrieve all the leases allocated through the relay device.
</t>

</section>

</section>

<!-- ===============================================================-->

<section title="Suboption Format">

<figure>
<preamble>Format of the Relay Agent Identifier suboption:</preamble>
<artwork>

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |SUBOPT_RELAY_ID|    length     |     type      |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
  .                                                               .
  .                     identifier (variable)                     .
  .                                                               .
  +---------------------------------------------------------------+

  Where:

  SUBOPT_RELAY_ID   [TBA]

  length            the number of octets in the suboption
                    (excluding the suboption ID and length fields);
                    the minimum length is two.

  type              a single octet describing the type of
                    identifier that is present.

  identifier        the identifying data.

</artwork>
</figure>

</section>

<!-- ===============================================================-->

<section title="Relay Identifier Types" anchor="section.types">

<t>
For clarity, the suboption specified here includes a type octet that
describes the data used in the identifier field. The type value zero
is reserved and MUST NOT be used. Two type values are defined here:
RELAY_IDENTIFIER_DUID and
RELAY_IDENTIFIER_ASCII. RELAY_IDENTIFIER_DUID is used when the
identifier field contains a DUID <xref
target="RFC3315"/>. Administrators may want to assign human-friendly
ASCII identifiers: RELAY_IDENTIFIER_ASCII is used when the identifier
field contains an ASCII string.
</t>

</section>

<!-- ===============================================================-->

<section title="Generating a Relay Identifier">

<t>
As described in <xref target="section.intro"/>, in some situations it
may be useful for network devices to generate identifiers
themselves. Relay agents who send the Relay Agent Identifier suboption
using identifiers that are not administratively-configured MUST be
generated following the procedures in the DUID section of <xref
target="RFC3315"/>. Relay agents who use generated identifiers SHOULD
make the generated value visible to their administrators via their
user interface, through a log entry, or through some other mechanism.
</t>

</section>

<!-- ===============================================================-->

<section title="Identifier Stability">

<t>
If the relay identifier is to be meaningful it has to be stable. A
relay agent SHOULD use a single identifier type and value
consistently. The identifier used by a relay device SHOULD be
committed to stable storage, unless the relay device can regenerate
the value upon reboot.
</t>

<t>
Implementors should note that the identifier needs to be present in
all DHCP message types where its value is being used by the DHCP
server. The relay agent may not be able to add the Relay Agent
Information option to all messages - such as RENEW messages sent as IP
unicasts. In some deployments that might mean that the server has to
be willing to continue to associate the relay identifier it has last
seen with a lease that is being RENEWed. Other deployments may prefer
to use the Server Identifier Override suboption <xref
target="RFC5107"/> to permit the relay device to insert the
Information option into all relayed messages.
</t>

<t>
Handling situations where a relay agent device is replaced is another
aspect of "stability". One of the use-cases for the relay identifier
is to permit a server to associate clients' lease bindings with the relay
device connected to the clients. If the relay device is replaced,
because it has failed or been upgraded, it may be desirable for the
new device to continue to provide the same relay identifier as the old
device. Implementors should be aware of this possibility, and consider
making it possible for administrators to configure the identifier.
</t>

</section>

<!-- ===============================================================-->

<section title="Security Considerations">

<t>
Security issues with the Relay Agent Information option and its use by
servers in address assignment are discussed in <xref
target="RFC3046"/> and <xref target="RFC4030"/>. Relay agents who send
the Relay Agent Identifier suboption SHOULD use the Relay Agent Authentication
suboption <xref target="RFC4030"/> to provide integrity protection.
</t>

</section>

<!-- ===============================================================-->

<section title="IANA Considerations" anchor="section.iana">

<t>
We request that IANA assign a new suboption code from the registry of
DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters.
</t>

<t>
<list>
<t></t>
<t>Relay Agent Identifier Suboption    [TBA]</t>
</list>
</t>

<t>
We request that IANA establish a new registry of DHCP Relay Agent
Identifier Sub-Option Types, to be maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. The Identifier
Type is a single octet. The initial values assigned in this document
are:
</t>

<t>
<list>
<t>Reserved                 0</t>
<t>RELAY_IDENTIFIER_DUID    1</t>
<t>RELAY_IDENTIFIER_ASCII   2</t>
</list>
</t>

<t>
Additional Identifier Type values will be allocated and assigned
through IETF Review, as defined in <xref target="RFC5226"/>.
</t>

</section>

</middle>

<!-- ============================================================= -->

<back>

<references title="Normative References">

&rfc2119;
&rfc2131;
&rfc3046;
&rfc3315;
&rfc4030;
&rfc5226;

</references>

<references title="Informative References">

&rfc4388;
&rfc5107;

<reference anchor="draft-kinnear">
    <front>
    <title>Bulk DHCPv4 Lease Query
    (draft-kinnear-dhc-dhcpv4-bulk-leasequery-*)</title>
    <author initials="K." surname="Kinnear">
    <organization>Unknown</organization>
    </author>
    <author initials="B." surname="Volz">
    <organization>Unknown</organization>
    </author>
    <author initials="N." surname="Russell">
    <organization>Unknown</organization>
    </author>
    <author initials="M." surname="Stapp">
    <organization>Unknown</organization>
    </author>
    <date month="July" year="2008"></date>
    </front>
</reference>

</references>

</back>

</rfc>