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

On Apr 9, 2013, at 5:31 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> 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.

Ops. Good catch. Meant actually relay, not client, but wrote something else :-) 

> 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.

I never said server sending the OPTION_RADIUS back. Still confirming what I
meant & asked to be clarified for future use of OPTION_RADIUS (and whether
my concern is valid to begin with):

0) Magic happens..
1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS
   including attributes X,Y,Z.
2) DHCP Server does not understand Z and thus responses to the Relay
   with DHCP options/values based on X & Y only.
3) DHCP Relay receives the response but for it to send a meaningful
   reply to DHCP Client it would need some DHCP option/value in
   the reply that reflects the content of the RADIUS attribute Z
   (that was included into the request sent to Server).
4) what does DHCP Relay do now?

- Jouni

> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg