Subject: [dhcwg] Requesting sub-options in DHCPv6

From: Tomasz Mrugalski <[email-masked]>
Date: Sun, 17 Apr 2011 21:20:25 +0200

Dear WG,
RFC3315 does not define any way to request sub-options (options that do
not appear within DHCPv6 message directly, but rather within other
options). After discussing this matter with Ted Lemon, I wrote a simple
draft that clarifies that multiple instances of ORO may be used for this
purpose. Each instance should be placed within specified scope, e.g.
within IA_PD or other option, where client expects to receive requested
options.

The draft is available here:
https://datatracker.ietf.org/doc/draft-mrugalski-dhc-dhcpv6-suboptions/

I'd like to ask for your comments and suggestions. If you don't like
proposed idea, please provide alternate way for requesting sub-options.

Tomek

-------- Original Message --------
Subject: New Version Notification for
draft-mrugalski-dhc-dhcpv6-suboptions-01
Date: Sun, 17 Apr 2011 12:08:12 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-mrugalski-dhc-dhcpv6-suboptions-01.txt has
been successfully submitted by Tomasz Mrugalski and posted to the IETF
repository.

Filename:	 draft-mrugalski-dhc-dhcpv6-suboptions
Revision:	 01
Title:		 Requesting Suboptions in DHCPv6
Creation_date:	 2011-04-17
WG ID:		 Independent Submission
Number_of_pages: 7

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 specific options within scopes
other than top-level.  This document updates RFC3315.