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

[Wing Cheong Lau <[e-mail]>]

At 10:11 AM 10/25/2004, Bernie Volz wrote:
>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?

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


>
>
>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:[e-mail]]
>Sent: Monday, October 25, 2004 12:50 PM
>To: [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and 
>RADIUS Attributes sub-option
>
>Dear Bernie and Ted,
>
>Thanks for your suggestion. My response is interlaced below.
>
>>X-BrightmailFiltered: true
>>From: "Bernie Volz" <[e-mail]>
>>To: "'Wing Cheong Lau'" <[e-mail]>, <[e-mail]>
>>Cc: "'Ralph Droms'" <[e-mail]>
>>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: [e-mail] [mailto:[e-mail]] On Behalf Of 
>>Wing Cheong Lau
>>Sent: Friday, October 22, 2004 12:45 PM
>>To: [e-mail]
>>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:[e-mail]]
> > Sent: Friday, October 22, 2004 8:18 PM
> > To: Bernie Volz
> > Cc: [e-mail]; '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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg