Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

[Tomek Mrugalski <[e-mail]>]

On 09.04.2013 16:35, Ted Lemon wrote:
> On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski <[e-mail]>
>  wrote:
>> On 09.04.2013 11:59, Jouni Korhonen wrote:
>>> What I am after is a note stating that a _client_ must be prepared
>>> for a reply from a server that does not provide adequate
>>> response/information for all the RADIUS attributes the client
>>> included in the request. This is solely meant for the future
>>> specifications using the OPTION_RADIUS.
>> When clarifying that, we must remember to be explicit about which client
>> or server (radius or dhcpv6) we are talking about here.
>>
>> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6
>> client. DHCPv6 client will never send it either. DHCPv6 Server will
>> never send this option back, just receive it from the DHCPv6 relay.
> 
> Oops, right.   So it's the relay that may need to deal with an inappropriate response from the DHCP server?
No. Is is the DHCP server. Relay/radius client get some attributes from
radius server and then sends it along with the relayed message to the
DHCP server. The DHCP server will use that information to select
configuration parameters for the dhcp client. If the relay includes some
Radius attributes the DHCP server does not recognize, the DHCP server
should ignore that particular RADIUS attribute and use those it
understands. Server will send response back to the DHCP client via DHCP
relay, but that response will not include any RADIUS attributes.