Subject: [dhcwg] Re: RE: About joint mip6 and dhc WGLC for hiopt draft

From: Heejin Jang <[email-masked]>
Date: Sat, 07 Jul 2007 07:51:51 +0000 (GMT)

Hi, Bernie.
Kindly see the inline
 
- Regards, 
Heejin.
 
------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]>
Date   : 2007-07-07 00:30
Title  : RE: About joint mip6 and dhc WGLC for hiopt draft

Yes, but 22.17 just describes how they are supposed to be used; it is
not an actual example of real world usage.

In DHCPv6, we have tended to go with new options instead of sub-options.
But that may eventually have a scaling issue (for example, a GUI having
a pull-down list of 2000 options from which to pick from would be
extremely annoying).

It might help us make recommendations if we knew what the typical usage
was. For example, in the cases you have presently defined sub-options,
would there typically only be one or many? In section 3.2.1 you have
three possible suboptions but it seems to me that in many cases only one
would be returned (though the requestor would not know which). The text
does say "Multiple sub-options may exist in a MIP6 Relay Agent option".

In this case, that is also the issue with using top-level options. If
you replaced 3.2.1 with three top-level options, an ORO would need to
contain all three options and in many cases one or more might not be
available. And, some information is lost because it would not be
possible to indicate a server&#39;s preference for which is used (suboptions
could be ordered to indicate the first, second, ... preference).
Specifying that the order in which the options appeared in the packet
have meaning would be very tricky and not something servers and clients
are likely to be able to easily handle (note that the ordering of
multiple instances of a single option can be ordered, it is the order of
DIFFERENT options which essentially carry the same information though in
different data formats, that is the issue here.)

This isn&#39;t very dissimilar to the issues faced by the 33
(OPTION_BCMCS_SERVER_D) and 34 (OPTION_BCMCS_SERVER_A) [RFC4280]
options.

And, it is actually an area that we were, I think, going to look at --
how best to handle cases where multiple data types might be returned.
But, the DHC WG hasn&#39;t done anything to address this.

The two standard methods are:
- Separate options (with the issues as per above)
- A single option with a "flag" field to indicate what data follows --
this is like the OPTION_MIP6-HNID option.

I think for the section 3.2.1 suboptions, you could create a single
option with had a id-type, reserved field, and then data (which depends
on the id-type). Remember, in DHCPv6, multiple instances of an option
are allowed.

Though, if you wanted a single option, it could be:
    option-code (16-bits), option-length (16-bits), NHI-1-len
(16-bits?), id-type (8-bits), [reserved (8-bits),] NHI-1 (variable,
depends on NHI-len, minus 2 (assuming reserved field is present),
NHI-2-len (16-bits), id-type ...

Heejin>> The id-type is the field to describe whether the HA is assigned from the local network or not, 
it does not necessarily included in relay option (from NAS to DHCP server) because its value is always 
set to 1 (which means not locally assigned info). Note that the HN info in NAS comes from AAA server 
originally.
I think that you may confuse the 'id-type' in HN identifier option with the 'sub-opt-code' in a relay option. 

If you're suggesting the use of radius attribute TLV in sub-option of relay-option as we 
can see in rfc4014 (DHCPv4 Radius attribute suboption), it can be considered, but
still the top-level & sub-option issue in the *HN information option* remains.   
  
This isn&#39;t pretty and likely difficult for a lot of servers to allow
users to configure.

But, if this is something that isn&#39;t manually configured but instead
derived from Radius data on the relay (which implies special purpose
code on the relay) [and similarily on the server], that isn&#39;t a big
deal.

NOTE: I used didn&#39;t follow the MIP6 document usage above and mixed and
matched things for illustrative purposes. For example, if the section
3.2.1 suboptions are always relay to server, they would never appear in
an ORO.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 11:01 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: About joint mip6 and dhc WGLC for hiopt draft

On Thu, Jul 05, 2007 at 09:10:55PM -0400, Bernie Volz (volz) wrote:
> There are actually options that have sub-options - the vendor options
> (option 17). For example, see
>
http://www.cablelabs.com/projects/crossproject/downloads/specs/CL-SP-CAN
> N-DHCP-Reg-I01-070119.pdf.

Section 22.17 of RFC3315 is an easier read. :)

I think in the past that there has been a principle that if the
client is likely to only want one of the defined options, and not
all of them all of the time, that &#39;multiple regular options&#39; are
preferrable on the basis that the client can specify what they want
on the ORO option (with sub-options, there is no precedent for
sub-option ORO, so clients will be given all the options).  Otherwise,
sub-options are preferrable.

-- 
David W. Hankins    "If you don&#39;t do it right the first time,
Software Engineer             you&#39;ll just have to do it again."
Internet Systems Consortium, Inc.        -- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg