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

[Tomek Mrugalski <[e-mail]>]

On 05.04.2013 15:12, Ted Lemon wrote:
> On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <[e-mail]>
> wrote:
>> Blindly dropping an attribute might not work in all cases. For
>> example, in some cases the server might not then be able to provide
>> all information the relay needs..
> 
> Well, I did say "silently ignored," not "dropped," but yeah.   If the
> server doesn't support that attribute, it's not going to have any
> effect anyway.   It seems like silently ignoring it is better than
> dropping the whole message, although I suppose you could argue the
> opposite, since a misconfiguration of this sort is probably something
> the administrator wants to fix immediately, not discover by accident
> years later.
Anyway, dropping the whole message is definitely too radical here. We
have 3 options when server receives an unknown attribute:
a) ignore just the unknown attribute
b) ignore the whole radius option
c) ignore the whole message

I think we have an agreement that a) is the way to go. At least that's
what I strongly recommend.

Also, depending on server implementation, it is quite likely that the
server will parse unknown attributes and handle them in some generic
way, e.g. hex string. This is what some implementations do with unknown
DHCPv6 options and I imagine similar approach can be taken with RADIUS
attributes. Of course, such a behaviour is strictly implementation
specific, so there's no need to put anything about it in the spec.
So whether the attribute is "unknown" or not may be a bit blurry
definition sometimes.

"Server MAY ignore received RADIUS attributes that it does not support."
seems like a reasonable text here. Some implementors will ignore unknown
attribute, some may produce a warning and some my try to handle it in a
generic way.

Tomek