[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 <tomasz.mrugal...@gmail.com>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. > - 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 mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
