Requesting Suboptions in DHCPv6
draft-mrugalski-dhc-dhcpv6-suboptions-04
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Tomek Mrugalski | ||
| Last updated | 2012-09-29 (Latest revision 2012-03-28) | ||
| 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
DHCPv6 clients may use Option Request Option (ORO) defined in RFC3315 [RFC3315] to specify, which options they would like to have configured by DHCPv6 servers. Clients may also be interested in specific options that do not appear in DHCPv6 message directly (top- level options), but rather as nested options or sub-options (i.e. options conveyed within other options). This document clarifies how to use already defined ORO to request sub-options. It also defines new Option Exclude Option (OXO) for cases, when client does not want requested options to appear within specific options. This document updates RFC3315 (if approved).
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)