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

[Jouni Korhonen <[e-mail]>]

> 
>> 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?
> Send the response back to the client, as usual. This is defined in
> RFC3315, section 20.2, which is a very simple section. Here's the
> relevant part:
> 
>   The relay agent extracts the message from the Relay Message option
>   and relays it to the address contained in the peer-address field of
>   the Relay-reply message.
> 
> As simple as that: decapsulate and send to the client.

Ok. So this clears my concerns. Thanks for the patience convincing me ;-)

- Jouni



> 
> Relay is not supposed to inspect the responses coming back from the
> server or act as judge of any sort (that response is good and the other
> is bad, because some DHCP option related to RADIUS attribute is not
> there). Some relays do deep packet inspection for various reasons
> (snooping addresses or prefixes for example), but that's an additional
> thing that do not affect the basic operation - send the response towards
> the client (or next relay closer to the client if there are more
> relays). Relays may produce warnings or send some alerts if certain
> option is missing, but they need to send the resonse back to the client
> anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays,
> but something that acts similar to DHCPv6 relay.
> 
> Tomek