Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option

From: Wing Cheong Lau <[email-masked]>
Date: Mon, 25 Oct 2004 09:49:51 -0700

Dear Bernie and Ted,

Thanks for your suggestion. My response is interlaced below.

>X-BrightmailFiltered: true
>From: "Bernie Volz" <[email-masked]>
>To: "'Wing Cheong Lau'" <[email-masked]>, <[email-masked]>
>Cc: "'Ralph Droms'" <[email-masked]>
>Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and 
>RADIUS Attributes sub-option
>Date: Fri, 22 Oct 2004 17:41:17 -0400
>Organization: Cisco
>X-Mailer: Microsoft Outlook, Build 10.0.6626
>Importance: Normal
>X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: 
>2004.10.22.1
>X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) 
>FILETIME=[025954B0:01C4B880]
>
>A very basic question ... why have a Relay Agent Information option and 
>have sub-options inside this? And, especially 8-bit suboptions.
>
>It seems to me that with the larger 16-bit DHCPv6 option space, we'd just 
>define an option to carry the "Radius Attributes" instead of placing this 
>under a general "Relay Agent" option. The context of the message is pretty 
>clear -- if it is from the relay, it can only be in a Relay-Forw (and 
>Relay-Reply) message option area.
>
>There's also another advantage to this. Take the DHCPv4 subnet-selection 
>option - there are two forms of this, one in for the relay agent and 
>another for the client. This won't be necessary in DHCPv6 as the LOCATION 
>of the message (either in the Client's Solicit, Request, ... or in a 
>Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to 
>use. This means only ONE option number is needed.
>
>So, I'd much rather see this specify a base option, 
>OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in 
>the standard Radius encoding. So, it is just 16-bit option code, 16-bit 
>length, followed by the radius encoding (as 8-bit suboptions).
>
>
>You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the 
>Relay-Forw (and Relay-Reply) message and MUST NOT appear in client 
>messages themselves.
>
>- Bernie

The original intent of specifying the sub-option was to try to simplify the 
definition of other sub-options in the future,
e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to
save a byte of so if the relay needs to include multiple sub-options at the 
same time.
On 2nd thought, this "uncommon case"  may not worth the complexity.

Your suggestion looks cleaner.
Also, the use of 16-bit instead of 8-bit length field can  eliminate the
255-byte length limit of RADIUS attributes to be included.
I will make it a single-level option according your suggestion in the next 
revision.

About the naming of the option, how about  "OPTION-RELAYED-RADIUS-ATTRIBUTES"
instead of "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature of 
this option,
i.e.  being inserted by the Relay Agent.

Thanks again.

Regards,

Wing

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>Wing Cheong Lau
>Sent: Friday, October 22, 2004 12:45 PM
>To: [email-masked]
>Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS 
>Attributes sub-option
>
>Dear all,
>
>We have submitted a new draft on DHCPv6 Relay Information Option and 
>RADIUS Attributes sub-option last week. It's already available from the 
>ietf site
>
>http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt
>
>but I have not seen the official announcement so far.
>
>The draft basically carries over similar capabilities, namely,
>RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
>from DHCPv4 to DHCPv6, with initial use cases targetting for
>the 3GPP2 environment.
>
>Comments are welcome.
>
>Regards,
>
>Wing
>
>Abstract
>
>    This document introduces the capabilities of the DHCPv4 Relay Agent
>    Information Option in RFC 3046 and the corresponding RADIUS-
>    Attributes Sub-option to DHCPv6. In particular, the document
>    describes a new DHCPv6 option called the Relay Agent Information
>    option which extends the set of DHCPv6 options as defined in RFC 3315
>    and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,
>    the new option is inserted by the DHCPv6 relay agent when forwarding
>    client-originated DHCPv6 packets to a DHCPv6 server. Servers
>    recognizing the Relay Agent Information option may use the
>    information to implement IP address or other parameter assignment
>    policies.  The DHCP Server echoes the option back verbatim to the
>    relay agent in server-to-client replies, and the relay agent strips
>    the option before forwarding the reply to the client. The Relay Agent
>    Information option is organized as a single DHCPv6 option that
>    contains one or more "sub-options" that convey information known by
>    the relay agent.  A RADIUS Attributes Sub-option, following its
>    DHCPv4 counterpart, is also defined.

 >Ted:
 >
 >Not sure what you're referring to.
 >
 >A relay would normally take a client message and place it into a Relay-Forw
 >with a Relay Message option containing the client's message. It can also add
 >any other options that it wants (and are allowed). In the base spec, this
 >might include an Interface-ID option, for example. And, why I suggested was
 >that this new I-D just define a "Radius Attribute" option which the Relay
 >Agent would add into the Relay-Forw message.

 >- Bernie

 > -----Original Message-----
 > From: Ted Lemon [mailto:[email-masked]]
 > Sent: Friday, October 22, 2004 8:18 PM
 > To: Bernie Volz
 > Cc: [email-masked]; 'Ralph Droms'; 'Wing Cheong Lau'
 > Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information
 > Option and RADIUS Attributes sub-option
 >
 >
 > Er, furthermore there's already a relay encapsulation method
 > defined in
 > the base DHCPv6 specification.
 >
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 25 Oct 2004 13:11:27 -0400

Great, I have no objection to your suggested name other than it is rather
long - perhaps it will become known as OPTION_RRA.
 
Are you or Ralph going to discuss this at the upcoming DHC WG session and
request it become a WG work item?

BTW, we don't need a DHCPv6 version of
draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor
options can be used by the Relay Agent just fine. Again, it is WHERE these
options appear that indicates whether they are for the client (in the client
part of the message) or the relay, in the Relay-Forw or Relay-Reply part of
the message. That work is already done and is not needed!!
 
- Bernie

-----Original Message-----
From: Wing Cheong Lau [mailto:[email-masked]] 
Sent: Monday, October 25, 2004 12:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and

Dear Bernie and Ted,

Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS

A very basic question ... why have a Relay Agent Information option and have
sub-options inside this? And, especially 8-bit suboptions.

There's also another advantage to this. Take the DHCPv4 subnet-selection
option - there are two forms of this, one in for the relay agent and another
for the client. This won't be necessary in DHCPv6 as the LOCATION of the
message (either in the Client's Solicit, Request, ... or in a
Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to use.
This means only ONE option number is needed.
 
So, I'd much rather see this specify a base option,
OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in the
standard Radius encoding. So, it is just 16-bit option code, 16-bit length,
followed by the radius encoding (as 8-bit suboptions).

You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the
Relay-Forw (and Relay-Reply) message and MUST NOT appear in client messages
themselves.
 
- Bernie

About the naming of the option, how about
"OPTION-RELAYED-RADIUS-ATTRIBUTES"
instead of "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature of
this option,
i.e.  being inserted by the Relay Agent.

Thanks again.

Regards,

Wing

-----Original Message-----

To: [email-masked]

Dear all,

We have submitted a new draft on DHCPv6 Relay Information Option and RADIUS
Attributes sub-option last week. It's already available from the ietf site 

the 3GPP2 environment.

Comments are welcome.

Regards,

Wing

Abstract

---

From: Wing Cheong Lau <[email-masked]>
Date: Mon, 25 Oct 2004 10:34:27 -0700

>request it become a WG work item?

Yes, I have just requested for a 10-min slot and the objective is to 
request it to become a WG work-item.

Regards,

Wing

>options appear that indicates whether they are for the client (in the 
>client part of the message) or the relay, in the Relay-Forw or Relay-Reply 
>part of the message. That work is already done and is not needed!!
>
>- Bernie
>
>>under a general "Relay Agent" option. The context of the message is 
>>pretty clear -- if it is from the relay, it can only be in a Relay-Forw 
>>(and Relay-Reply) message option area.
>>
>The original intent of specifying the sub-option was to try to simplify 
>the definition of other sub-options in the future,
>save a byte of so if the relay needs to include multiple sub-options at 
>the same time.
>instead of "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature 
>of this option,

---

From: Wing Cheong Lau <[email-masked]>
Date: Mon, 25 Oct 2004 11:59:12 -0700

>part of the message. That work is already done and is not needed!!

I see. However,  the use of such vendor-options by the Relay Agent is kind 
of hidden/missing from the current text of RFC 3315.
For example, Sections  22.16 and 22.17 of RFC 3315 only describe the use of 
such vendor options by the client and the server. The use of these options 
by the relay agent are not mentioned at all.

While it is true that the table in Appendix A of RFC3315
does say the possible inclusion of the vendor options in the 
Relay-Forward/Relay-Reply message,
the table in Appendix B seems to imply otherwise:

In the table in Appendix B,  while there are  "*"'s  for the  Relay-Message 
and Interface ID rows under
the Relay Forw./Relay Replay columns,  no "*"'s are found  for the Vendor 
Class/Vendor Info rows for
the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to 
include those vendor options in the
Relay Forw/Replay messages, just like it includes the Interface option,
the rows for the  Vendor options should look like the row of  the Interface 
option.

Am I missing something ? or did I misunderstand the entire meaning of the 
table in Appendix B ?
Actually, what does the "Option Field" column in the table mean ?

Also what's the "Note" below the table refers to ?

Would you share more clarification/ insights on this ?

Thanks a lot in advance.

Regards,

Wing

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 25 Oct 2004 16:13:52 -0400

In a RFC 3315-bis, we'll need to correct this. Appendix B is in error and
should allow these options in the Relay-Forw/Relay-Reply. And, the
description of the options should mention that these can also be used by the
relay agent <-> server communication.
 
But the intent was always there, as shown in Appendix A, to use these
options for the relay agent as well. I think Appendix A is correct and
complete (in terms of the options in the base specification.)
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wing Cheong Lau
Sent: Monday, October 25, 2004 2:59 PM
To: Bernie Volz; 'Wing Cheong Lau'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and
RADIUS Attributes sub-option

 
- Bernie

Thanks a lot in advance.

Regards,

Wing