"Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 4-Mar-09. ( bytes)
This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942].
"Subnet Allocation Option", Richard Johnson, Jay Kumarasamy, Kim Kinnear, Mark Stapp, 11-Mar-09. ( bytes)
This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options.
"DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Ralph Droms, Bernie Volz, 6-Feb-09. ( bytes)
The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients.
"DHCPv6 Server Reply Sequence Number Option", Bernie Volz, Ralph Droms, 4-Feb-09. ( bytes)
This memo defines the Server Reply Sequence Number option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay agent to detect proper sequencing of Relay-Reply messages that could be delivered out of order.
"Guidelines for Creating New DHCP Options", David Hankins, 24-Feb-09. ( bytes)
This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable.
"Container Option for Server Configuration", Ralph Droms, 24-Mar-09. ( bytes)
In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server.
"Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 21-Apr-09. ( bytes)
In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages.
"Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 25-Feb-09. ( bytes)
As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as a transparent bridge in Layer 2 mode. These Access Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality does not provide means to avoid flooding of DHCP messages and also needs to be extended to support DHCP LeaseQuery This draft discusses these issues and provides solutions for the same.
"DHCPv6 option for network boot", Thomas Huth, Jens Freimann, Vincent Zimmer, Dave Thaler, 14-Apr-09. ( bytes)
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network.
"DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 14-Jan-09. ( bytes)
Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues.
"DHCPv6 Vendor-specific Message", Bernie Volz, 12-Jan-09. ( bytes)
This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes.
"DHCPv4 Vendor-specific Message", Bernie Volz, 12-Jan-09. ( bytes)
This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes.
"Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 13-Feb-09. ( bytes)
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
"Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 2-Mar-09. ( bytes)
The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted.
"Forcerenew Nonce Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 3-Jun-09. ( bytes)
DHCP Forcerenew allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server exchanges a nonce with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message.
"Lightweight DHCPv6 Relay Agent (LDRA)", David Miles, Sven Ooghe, Wojciech Dec, Suresh Krishnan, 1-Jul-09. ( bytes)
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.