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

Seems that I forgot to CC mailing lists.

- Jouni

Begin forwarded message:

> From: jouni korhonen <jouni.nospam@gmail.com>
> Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
> Date: April 5, 2013 7:37:47 PM GMT+03:00
> To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
> 
> 
> 5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> kirjoitti:
> >
> > On 05.04.2013 15:12, Ted Lemon wrote:
> > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
> > > 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
> 
> I was not suggesting dropping the message. I said "blindly dropping an attribute".. which is somewhat different. I am fine with a) but my point was that it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. This needs to be taken into account when defining DHCP extensions relying on this I-D and the established registry.
> 
> Jouni
> 
> > 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
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg