Unicast Address Sub-Option
draft-decnodder-dhc-rai-unicast-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Stefaan De Cnodder , Patrick Mensch | ||
| Last updated | 2006-08-21 | ||
| 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
In some network topologies, it is preferred to have a trusted network element between the DHCP client and the L3 relay agent that adds the DHCP relay-agent-information option but does not set the giaddr field. They operate in Layer 2 mode and hence act as trusted Layer 2 relay agents. The replies from the server are broadcasted by the L3 relay agents to these L2 relay agents which must be avoided. This document defines a new sub-option for the relay-agent-information option. With this sub-option, the L3 relay agent will always unicast the messages towards the trusted layer 2 DHCP relay agent with a hardware address that is known in the network. The new sub-option is called the "unicast-address" sub-option.
Authors
Stefaan De Cnodder
Patrick Mensch
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)