Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

[Alexandru Petrescu <[e-mail]>]

Le 27/03/2012 14:05, Marc Blanchet a écrit :
> Le 2012-03-27 à 13:47, Alexandru Petrescu a écrit :
>>
>> When setting up routes one would like to make sure they're right
>> and they lead somewhere at least most of the time. At the smart end
>> node and dumb network, there should always exist a fallback and
>> that fallback is typically the default route ("when everything else
>> fails").
>>
>> In this sense, if the end node sets up its routes with DHCP, it
>> would like to be sure they're right most of the time, otherwise use
>> the default route.
>>
>> But when the default route _and_ the other more specific routes
>> are provided by DHCP, and if failing, then there is a risk of
>> misconfiguration.
>
> yes and no. ipv6 stack is pretty good in actively tracking if routers
>  are up.
>
> in fact, having the default route or not does not change the basic
> issue, which is, to me, a trust issue.
>
> say for example that you have two different types as you suggest: one
>  for more specific routes and one for default route. well, if the
> dhcpv6 server sends you a specific route such as 2000::/3, it is
> almost a default route, and moreover, it will be preferred over the
> (good,appropriate) default routes.

We could specify the specific routes part to MUST NOT send 2000::/3 as
route.  Would this solve that?

> Therefore, a specific type does not help the problem.
>
> So your proposal does not help the root issue which is, to me, does
> the node trust the dhcpv6 server for routes insertions.

In a sense yes.  But this seems to me you mention a security (trust)
issue, not necessarily a misconfiguration.

I think protocol specification may guide the way the dhcpd.conf is
written and, if there are different types for specific routes vs default
routes, then there could be different sections in that file as well,
helping a bit to set aside the default routes.

Alex

>
> Marc.
>
>
>>
>> Something that could be done about this is the use of different
>> Types in DHCP (ORO) for specific routes and a different Type for
>> default routes. This would mean not only that the config file owuld
>> have different sections for default routes vs specific routes (thus
>> guide the Server's administrator to double check the default part)
>> but also the DHCP Client implementation to have separate software
>> sections for specific routes vs default routes. Some lighter DHCP
>> Clients may choose to implement _only_ the default route option
>> part (and not the specific route part).
>>
>> With respect to this there was also a question about compliance
>> with specs - if a stack doesn implement eg ICMP Redirect then it's
>> not compliant. Do we want to ensure the same level of strength in
>> compliance with DHCP? Even for low end devices?
>>
>> Alex
>>
>> _______________________________________________ mif mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mif
>