I guess adding a default gateway to achieve the scenario below is a shortcut to cluttering the host with a lot of specific routes that exclude P1::/48
If the admin wants the hosts to route all packets to P1 go via R1 or R2 for load balancing or optimization - this algorithm should not break the original intentions in steady state. A few packets getting routed through R3/R4 shouldn't be a big deal in this case - of course if the network is super flaky then there is a problem - however this algorithm will not make a big difference to connectivity in such a network. Any other stricter intention will most likely have some filtering on R3 and R4 to drop packets destined to P1::/48. In this scenario this algorithm has not altered the host's connectivity in any way. 1. Without this algorithm - the preferred routers R1 and R2 are not reachable. Still the host attempts to resolve these addresses and potentially drop the packets while they are unreachable. 2. With this algorithm - when R1 and R2 are unreachable - the host attempts to send to R3 and R4 - they fail too (assuming filtering on R3 and R4). The host keeps probing R1 and R2 and when they are reachable the host switches to R1 / R2. The time to switch may be a little more with the algorithm. The extra work on the admin's (Which is probably done anyway in the non-loadbalancing scenario to prevent misconfigured hosts from sending packets destined to P1::/48 to R3 and R4) part is to filter the packets for P1::/48 on the routers R3 and R4 if they truly want all packets destined to P1::/48 to go over R1 or R2. Simha -----Original Message----- From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] Sent: Monday, December 07, 2009 9:09 AM To: Erik Nordmark; Narasimhan Venkataramaiah Cc: IPv6 Maintenance WG Subject: RE: Question on RFC 4191 inconsistency Erik, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Erik > Nordmark > Sent: Monday, December 07, 2009 1:33 AM > To: Narasimhan Venkataramaiah > Cc: IPv6 Maintenance WG > Subject: Re: Question on RFC 4191 inconsistency > > Narasimhan Venkataramaiah wrote: > > This behavior is implemented in Vista and Windows 7. > > > > Can you explain the concern about unpredictability more? The algorithm > > reacts to the changes in the > network - hence there is bound to be unpredictability on the time line of > when the packets start > getting routed to a different next hop - but given a history of data packets > it isn't all that > unpredictable. Is the concern about the non-standard mechanism used to detect > unreachability? > > If a host is connect to more than two routers, for instance two pairs of > routers, with each pair routing to very different parts of the universe, > then the admin on the routers can no longer control where packets go. > > Say R1 and R2 advertise P1::/48 with high preference, and R3 and R4 > advertise P2::/48 with high preference. All four routers also are > default routers. 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? > 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? Fred fred.l.temp...@boeing.com > If the implementation follows the example in section 3.6 that would > cause packets to P1 to be routed to R3 or R4, which would violate the > intent of the router admin in this example. > And the router admin has no influence when a host might declare a > neighbor unreachable; with base RFC 4861 there is no need for such > control since the hosts behave in a predictable way by always picking > among the equal default routes. > > Thus having NUD affect the choice among equal routes (same prefix > length) is one thing, but the example in 3.6 looks like a bad idea to me. > > Erik > > > Thanks > > Simha > > > > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > > Erik Nordmark > > Sent: Sunday, December 06, 2009 9:23 AM > > To: IPv6 Maintenance WG > > Subject: Question on RFC 4191 inconsistency > > > > > > The default router preferences RFC seems to be internally inconsistent > > on the scope of the "non-reachable router" implications. > > > > Section 3.2 contains: > > using route preference values as a tie-breaker if > > multiple matching routes have the same prefix length. If the best > > route points to a non-reachable router, this router is remembered for > > the algorithm described in Section 3.5 below, and the next best route > > is consulted. > > > > thus it talks about multiple matching routes *with the same prefix > > length*. Nothing in section 3.5 contradicts this. > > > > Yet the example in section 3.6 talks about falling back to the default > > route (or any route with a shorter match) when all the longest match > > routes lead to unreachable routers. > > > > It is quite odd that the example is the only source of this novel behavior. > > > > I'm concerned that going to shorter matching routes isn't only complex > > to implement, makes the protocol operationally unpredictable (who knows > > how quickly a host might decide a router is unreachable when there is > > non-zero packet loss), but also charters completely new territory in > > terms on longest-match routing. > > > > Have this example behavior in section 3.6 been implemented? > > Do we have any operational experience with it? > > > > Erik > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
