Subject: Question on RFC 4191 inconsistency

From: Erik Nordmark <[email-masked]>
Date: Sun, 06 Dec 2009 09:22:50 -0800

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

---

From: Narasimhan Venkataramaiah <[email-masked]>
Date: Mon, 7 Dec 2009 01:07:30 +0000

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?

Thanks
Simha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Sunday, December 06, 2009 9:23 AM
To: IPv6 Maintenance WG
Subject: Question on RFC 4191 inconsistency

Section 3.2 contains:

    Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 07 Dec 2009 01:33:25 -0800

> 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…

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.

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.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Dec 2009 09:09:25 -0800

Erik,

> Sent: Monday, December 07, 2009 1:33 AM
> To: Narasimhan Venkataramaiah
> Cc: IPv6 Maintenance WG
> Subject: Re: Question on RFC 4191 inconsistency
> 
> > 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?
> 

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? 

> 40 second period is sufficient), then NUD could decide that R1 and R2

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
[email-masked]

---

From: Narasimhan Venkataramaiah <[email-masked]>
Date: Mon, 7 Dec 2009 18:14:18 +0000

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:[email-masked]] 
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,

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Dec 2009 10:25:55 -0800

Simha,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Narasimhan Venkataramaiah
> Sent: Monday, December 07, 2009 10:14 AM
> To: Templin, Fred L; Erik Nordmark
> Cc: IPv6 Maintenance WG
> 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.

I guess this would be a good case for R3 and R4 to send:

" ICMPv6 - Destination Unreachable - Source address failed
  ingress/egress policy"

In that case, the host can discover that R1 and R2 are
its only alternatives even if routing seems to suggest
that R3 and R4 are also candidates.

Fred

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Dec 2009 05:15:55 -0800

> only accept the ones from R1 and R2 while dropping those

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.

> 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.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Dec 2009 05:24:46 -0800

Narasimhan Venkataramaiah wrote:
> 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.

While it might not make much difference in connectivity, it makes it 
harder for the network operator to understand things, because from an 
operational perspective it doesn't look like the host honors 
longest-match routing.

What are the claimed benefits of no longer doing longest-match routing 
as outlined in example 3.6?

    Erik

> 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:[email-masked]] 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: [email-masked]
>> [mailto:[email-masked]] 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
>> 
>> 
>> 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 
>> 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.
>> 
> 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?
> 
>> 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 [email-masked]
> 
>>  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.
>> 
>>> Thanks Simha
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Erik Nordmark Sent:
>>> Sunday, December 06, 2009 9:23 AM To: IPv6 Maintenance WG 
>>> 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.
>>> 
>>> 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 [email-masked] 
>>> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>  IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Dec 2009 07:22:31 -0800

Erik,

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2009 5:16 AM
> To: Templin, Fred L
> Cc: Narasimhan Venkataramaiah; IPv6 Maintenance WG

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.

> 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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Dec 2009 09:17:36 -0800

> not accept packets from a node pretending to be a router.

That might make sense in some cases. (But more typically it is routers 
and other network devices like bridges that might want to verify source 
addresses etc.)

But I don't see what that has to do with RFC 4191.

> could not be used in the same way.

Perhaps because  NUD is *NOT* a Hello protocol.
With enough thrust pigs can be made to fly, but that doesn't mean it is 
a good idea.

The closest thing we have to a hello protocol in ND are the periodic 
RAs. And when the default router lifetime from the RAs time out, then 
the default route, as well as any more specific routes from that router, 
will time out.

    Erik

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Dec 2009 09:48:25 -0800

Erik,

> Sent: Tuesday, December 08, 2009 9:18 AM
> To: Templin, Fred L

I can live with that if you can, i.e., only have routers
and/or bridges verify source addresses, and let hosts
accept packets that may come from any routers. It would
make life a lot easier for the hosts.

> With enough thrust pigs can be made to fly, but that doesn't mean it is

This is not an all-pigs-flying concept. As long as the
route lifetime has not expired, if NUD can be used as a
hint that the route has become non-operational then why
can't it be used as a hint that the route has come back
to life.

> the default route, as well as any more specific routes from that router,

Correct; a route that has timed out is no longer usable.
Nothing about this changes that fact. But, by my read
of the spec the router lifetime applies only to the
node's ability to act as a default router - not its
ability to service more-specific routes.

Fred

---

From: Narasimhan Venkataramaiah <[email-masked]>
Date: Tue, 8 Dec 2009 21:53:03 +0000

[Erik]"While it might not make much difference in connectivity"
Connectivity is the benefit of section 3.6.

[Erik]"What are the claimed benefits of no longer doing longest-match routing as outlined in example 3.6?"
Failover is the benefit of choosing the next longest matching route that is reachable when the longest matching routes are unreachable.

As for determinism - it's one thing to say that the admin wants to route packets to P1::/48 through R1/R2 and not through R3/R4 and packets sent to R3/R4 destined to P1::/48 are dropped. It's another thing to say that he doesn't expect packets to P1::/48 at R3/R4 altogether. As I understood you are saying that this second non-deterministic behavior is bad. But how does this operationally affect an admin. Is it the processing load on R3/R4 to discard packets? A determined host can always send packets destined to P1::/48 to R3/R4.

On the other hand 4191-3.6 allows an admin to route packets based on an prefix based policy in a network with infrequent packet losses while maintaining connectivity when there is an occasional outage - without altering the longest-match in steady state. And the admin has the option to prevent routing through R3/R4 anyway. 

Simha
-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 5:25 AM
To: Narasimhan Venkataramaiah
Cc: Templin, Fred L; IPv6 Maintenance WG
Subject: Re: Question on RFC 4191 inconsistency

    Erik