Extension of DHCP Leasequery in Bridging/Switching networks
draft-joshi-dhcp-lease-query-ext-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Bharat Joshi , Pavan Kurapati | ||
| Last updated | 2006-09-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
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 traditional bridge. These Access Concentrators also act as relay agents and relay DHCP messages between hosts and DHCP servers. It also maintains and updates lease/location information while relaying the DHCP messages. Access Concentrators may use the lease/ location information for anti-spoofing, data forwarding etc. This lease/location information is lost if an Access Concentrator gets rebooted. RFC 4388 [5] has defined a new message type DHCPLEASEQUERY to address similar limitation in Routed Access Networks. This document initially gives an overview of the functioning of the Access Concentrator acting as a relay agent in a Layer 2 aggregation network. The limitation[as mentioned above] in a typical switched/ bridged[layer 2] is then discussed followed by the proposal to extend the DHCPLEASEQUERY message to address this limitation.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)