Erik, > -----Original Message----- > From: Erik Nordmark [mailto:[email protected]] > Sent: Tuesday, December 08, 2009 5:16 AM > To: Templin, Fred L > Cc: Narasimhan Venkataramaiah; IPv6 Maintenance WG > Subject: Re: Question on RFC 4191 inconsistency > > Templin, Fred L wrote: > > > The presence of default routes means that the host should > > accept packets from all four routers equally, i.e., and not > > only accept the ones from R1 and R2 while dropping those > > from R3 and R4, right? > > What do you mean by "accept"? The content of the default router list (or > a routing table in general) doesn't have any impact on what received > packets are accepted by a host.
I mean that on some link types hosts need to be careful about what routers they accept packets from, and should not accept packets from a node pretending to be a router. > >> Here the admin wants packets to P1 to only go via R1 or R2. > >> > >> However, should there be some short-term flakyness for the connectivity > >> between the host and R1 and R2 (just some wireless packet drops over a > >> 40 second period is sufficient), then NUD could decide that R1 and R2 > >> are unreachable. > > > > But if R1 and R2 are both truly unreachable, shouldn't > > the host be allowed to fail over to R3 and R4, which are > > legitimate forwarders of packets that the host accepts? > > They would do that after the more specific routes pointing at R1 and R2 > times out. But doing it just because 3 NUD packets were lost makes > things less predictable. > > If you, instead of using RFC 4191 to do more specific routes, run ripng > on the host you'd see the expected behavior that the route remains in > use until it times out; NUD might at most affect the selection when > there are Equal Cost Multipath routes. Some routing protocols declare a link down when a certain number of hello messages are lost. I don't see why NUD could not be used in the same way. Fred [email protected] > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
