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

[Alexandru Petrescu <[e-mail]>]

Le 27/03/2012 15:17, Marc Blanchet a écrit :
>
> Le 2012-03-27 à 14:38, Alexandru Petrescu a écrit :
>
>> 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?
>
> no. what about 2000::/4, 2000::/5 …

Well, one one hand there should exist a means to write English
about 4, 5 ... 128 prefix lengths.

On another hand, the RFCs say that only ::/0 is a default route, so we
may care more about this.

No?

Alex

>
> Marc.
>
>