Subject: [dhcwg] Suboption Request Option?

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 07 Mar 2011 10:22:11 +0100

Hi all,
A bit of background info: There are 2 ways DHCPv6 client can inform
server about its intent to have an option configured. The first
(mandatory) way is to send ORO. The second way (optional, can be used as
an addition to the first one) is to send the actual requested option to
provide hints for server. Unfortunately, this only solves the problem of
requesting top-level options.

My question is how is client supposed to request specific suboption?
Even though both top-level options and suboptions share the same number
space, using ORO to request suboption is wrong or at least not elegant
in my opinion. The aspect I don't like is that it causes ambiguity as
the same sub-option type can possibly appear in more than one top-level
option (e.g. STATUS_CODE may appear in IA_NA, IA_TA and IA_PD).

What are your thoughts about defining Suboption Request Option? The
exact format is up to discussion, but first proposal is that it could be
1 or more sets of 4 octects. In each set, first two octets designate
top-level option, while the following two octets describe sub-option.
This approach is simple, but does not deal with sub-sub-options. e.g.
IAADDR is always suboption and it can have suboptions (3rd level options?).

If the idea is sound, I'd like to begin working on this.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Mar 2011 08:17:05 -0600

Can you explain why this is needed?

For option 17 (vendor specific information option) this has come up and
the vendors have simply added an ORO within their option space.

For something like an IA_NA, IA_TA, or IA_PD, why would this be needed?
(And if it was, why would we simply allow an ORO in the
IA_NA/IA_TA/IA_PD?).

While we could do this or something else, without a use case, why would
be bother?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tomasz Mrugalski
Sent: Monday, March 07, 2011 4:22 AM
To: [email-masked]
Subject: [dhcwg] Suboption Request Option?

Hi all,

IAADDR is always suboption and it can have suboptions (3rd level
options?).

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

---

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 07 Mar 2011 22:52:57 +0100

> Can you explain why this is needed?
There's one draft (draft-ietf-mif-dhcpv6-route-option-00) that conveys
routing information in multiple interfaces environment. It defines IA_RT
(an empty container) that contains more one or more routers (NEXT_HOP
option) that finally contains one or more prefix information. The idea
there is to define an absolute minimum that is still usable for routing
configuration.

Various folks expressed interest in defining several additional options
that extend this proposal (e.g. preference, lifetimes etc.). Client
needs a way to tell server, which extra parameters it is able to
consume. The idea here is to avoid reinventing an unique way to request
suboption in every related draft that may appear.

That's just an example. What I'd like to accomplish here is to have a
standard way of requesting suboptions. I'm fine with what you described.
Actually that would be even simpler to implement. Nevertheless, it would
be good to clarify that this is indeed a valid approach. Note that such
usage was not mentioned in RFC3315, so this is kind of extension.

> the vendors have simply added an ORO within their option space.
There's precedence then. More examples that such functionality is needed.

> (And if it was, why would we simply allow an ORO in the
That's fine for me. I gladly accept any way of requesting suboptions.

Would it be ok to write a simple clarification draft that explains that
this is the proper way of requesting specific suboptions? This would
make such approach interoperable.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Mar 2011 16:21:14 -0600

>make such approach interoperable.

Usually one writes and the DHC WG rips it to pieces (or ignores it) if
it doesn't like it :) ...

I guess my issue with this kind of technique is that although we tried
very hard to REQUIRE the ORO for options in DHCPv6, it hasn't always
worked.

And, the client is always free to ignore something that it doesn't want
or understand. So, the only issue with the server sending 'more' is the
size of the packets.

And, if a new 'top' level option is defined that is only meant to appear
'inside' an IA_NA/IA_TA/IA_PD (such as IAADDR/IAPREFIX, though we don't
have them in the ORO), I'm not sure there's much of an issue (the
existing top-level ORO can be used).

Thus, if you have truly optional data and it is large, then I could
begin to see your argument. But, then there is the issue of what you do
with clients that don't send an ORO (because they either don't implement
whatever is proposed or 'forgot' to) and what the server sends?

At least my view is you'd need a pretty strong argument for this ... I
think the existing methods are sufficient (define your new top level
option codes such that if they appear in the top-level ORO, it means
include them encapsulated in the whatever options they are supposed to
be).

But, that's only my view ...

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tomasz Mrugalski
Sent: Monday, March 07, 2011 4:53 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Suboption Request Option?

> the vendors have simply added an ORO within their option space.
There's precedence then. More examples that such functionality is
needed.

Tomek

---

From: Tomasz Mrugalski <[email-masked]>
Date: Tue, 08 Mar 2011 00:57:24 +0100

> it doesn't like it :) ...
I think I'll try my luck. Let's hope for the best and prepare...

> or understand. So, the only issue with the server sending 'more' is the
Some time ago I participated in a discussion. I've heard about things
that some people want to send over DHCP. I didn't like it at all. I'd
like to have the ability to allow server to not send such options,
unless client really asks for it.

> existing top-level ORO can be used).
I think there's an implementation problem. Some of the implementations
are handling options in a uniform way. Server maintains a list of
configured options. ADVERTISE/REPLY messages are populated with options
that are requested by client. If we allow top-level ORO to specify both
top level options and suboptions, then some of the existing server
implementations will get confused.

> begin to see your argument. But, then there is the issue of what you do
Ok, let me provide couple of examples. During various stages of the MIF
discussions, there were proposals to configure following routing
parameters, besides the really essential ones (next hop, prefix, prefix
length): DSCP/TOS, Interface-info, Flow Description, QoS Info, Flow
Route Prefix and several more. I must admit that I don't understand
reasons behind defining all those options, so I won't defend or attack
their usefulness. My point here is that such options should not be sent,
unless explicitly requested by client.

> whatever is proposed or 'forgot' to) and what the server sends?
That's not a problem at all. Existing options are left are they are.
Future, yet to be defined options may benefit from discussed proposal.
If client wants to get its extra option, it will use suboption ORO to
request it. Forgetful clients will get only those options that asked for
(and those that server is configured to send always, regardless if
clients ask for them or not.)

There's already precedence with using multiples instances of the same
option on several levels, sometimes even in the same message -
STATUS_CODE option.

> include them encapsulated in the whatever options they are supposed to
See my comments about existing implementations. Also, allowing ORO to
appear as suboption, would actually simplify server implementations.

I need to think this through, but I'm really convinced that this is
useful feature. The change is rather minor: just allowing using ORO to
appear as suboption. That is behavior that is not forbidden by 3315, and
you said that it was used that way already. Let's see if your
predictions about WG reaction become true. :)

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Mar 2011 21:34:21 -0500

> there is to define an absolute minimum that is still usable for routing

As Bernie said, I would really suggest waiting until this proposal has been churned a bit before working on addressing problems it creates with additional DHCP protocol specs.