Re: [mif] Route option for DHCPv6 - next steps?

[Alexandru Petrescu <[e-mail]>]

Le 28/03/2012 10:55, Lorenzo Colitti a écrit :
> [Putting mif back into CC, since now we're talking about the merits of
> the proposal]
>
>> On Wed, Mar 28, 2012 at 10:34, Tomek Mrugalski
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Let me comment on the deprecation a bit more. You mentioned previously
>>     that you are concerned about route entries becoming invalid. Let me
>>     explain how we plan this to defend against it:
>>     - if a host detects link flap, it must flush all routes installed
>>     - host verifies that router is reachable using ND, before using it
>>     - host detects that router died using NUD
>
> And then what does the host? Ask the server again for another default
> route? Why would the server return anything different than what it
> already returned? After all, the server doesn't share state with the
> router, so it has not idea that the host can't reach it.

I agree with this point of view.

In our work we were confronted with the question about what does the 
Client when the default router's lifetime expire: should it issue an RS 
or a DHCPv6 Request?

Also, it may be good to have error processing in the route option draft. 
  Maybe with error codes that would explain why the Server is not able 
to deliver some routes.

Alex

>
>     - you also expressed concerns about new server not being able to
>     invalidate old server's configuration in case of old server crash. That
>     is actually an invalid argument. Failure of the server does not imply
>     failure of the router. Furthermore, it is possible to invalidate old
>     server's information. If you want to do this, your new server can
>     announce route to become obsolete by announcing it with lifetime of 0.
>
>     Do you have any other deprecation mode in mind that is not covered?
>
>
> Example A:
> 1. There are two routers on the link connected to a switch.
> 2. You get a default route from a DHCPv6 server pointing at one of them.
> 3. The router crashes or is taken out of service. You default route is
> not working any more. The server doesn't know this, and so doesn't
> validate your route
> 4. You have no default route.
>
> Example B:
> 1. There are two routers on the link connected to a switch.
> 2. You get a default route from a DHCPv6 server pointing at one of them.
> 3. The server crashes or is unreachable.
> 4. The router is taken out of service for planned maintenance.
> 5. You have no default route, and nobody can invalidate your route,
> since only the crashed / unreachable server has the nonce.
>
> In IPv4, the typical solution to these problems are NOT "use reconfigure
> accept", but "run VRRP". With RAs, we can get rid of VRRP; we just won't
> have the problem.
>
> In the homenet, where stuff can go away permanently at any time, things
> get even worse.
>
>      > DHCPv6 servers often don't share fate with the routers.
>     So? There are over 65 options defined for DHCPv6, much more will be
>     defined. Do you expect server to share fate with all announced services?
>
>
> No. I'm saying we already have a way to do this that shares fate, and
> that it's more reliable, and that we don't need another way.
>
>     This mechanism may affect many groups: MIF, DHC, homenet, shim6, 6man
>     and v6ops. Do you expect us to ask for adoption of this draft to all of
>     those groups in turn? My idea is that this mechanism may affect many
>     WGs, but such document must be adopted somewhere.
>
>
> Agreed, it needs a place to live. I believe MIF is not the right place,
> because 11 of the 14 use cases are not about multiple interfaces. I
> believe that 6man is the right place, because this option provides a
> complete replacement for the basic way in which hosts learn about routers.
>
> If you take this to 6man and get consensus there, then that's fine.
>
> Cheers,
> Lorenzo
>
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif