Reachability confirmation issue for ISATAP routers (plus solution)

["Fred L. Templin" <ftemplin@IPRG.nokia.com>]

Hello,

The ISATAP specification allows nodes to discover the addresses
of multiple "potential routers" and affiliate with as many or few
of them as desired. For ISATAP nodes that affiliate with more than
one router, an issue for NUD may occur if hints from upper layer
protocols are used to indicate a connection is making forward
progress. In [RFC2461, 7.3.1], we find the following text:

   "A connection makes "forward progress" if the packets received from a
   remote peer can only be arriving if recent packets sent to that peer
   are actually reaching it.  In TCP, for example, receipt of a (new)
   acknowledgement indicates that previously sent data reached the peer.
   Likewise, the arrival of new (non-duplicate) data indicates that
   earlier acknowledgements are being delivered to the remote peer.  If
   packets are reaching the peer, they must also be reaching the
   sender's next-hop neighbor; thus "forward progress" is a confirmation
   that the next-hop neighbor is reachable.  For off-link destinations,
   forward progress implies that the first-hop router is reachable.
   When available, this upper-layer information SHOULD be used."

When a node (A) affiliates with only a single ISATAP router (B), the
above specification works fine, because forward progress will only
occur if both of the following are true:

 1. outgoing packets are flowing from A -> B
 2. return packets are flowing from B -> A

i.e., the bi-directional link A <-> B is confirmed. But, when
A affiliates with multiple ISATAP routers, this condition no
longer holds. In particular, consider the following case:

 1. A affiliates with routers B, C
 2. A initiates a TCP connection with remote peer D. Outgoing packets
    from A -> D flow through B, but return packets from D -> A
    flow through C (i.e., outgoing and return paths are asymmetric)
 3. A initiates a multimedia UDP stream to remote peer E. Outgoing
    packets from A -> E flow through B, but no return packets occur

Now, if "forward progress" indications from the A -> D TCP connection
were used, A would conclude that B was reachable and continue to keep
its neighbor cache entry for B in the REACHABLE state. If the return
path from B -> A were disrupted (i.e., the link becomes unidirectional
from A -> B) this condition would go undetected. This could produce
undesireable results if packets from A -> E were going to a black hole
but B could not deliver critical ICMP messages to A.

Fortunately, the very next paragraph in [RFC2461, 7.3.1] provides the
solution to the problem:

   "In some cases (e.g., UDP-based protocols and routers forwarding
   packets to hosts) such reachability information may not be readily
   available from upper-layer protocols.  When no hints are available
   and a node is sending packets to a neighbor, the node actively probes
   the neighbor using unicast Neighbor Solicitation messages to verify
   that the forward path is still working."

So, the solution for ISATAP nodes when performing NUD for routers
is the following:

 1. When the node affiliates with only a single router, upper-layer
    hints of forward progress MAY be used for reachability confirmation
    as in the first RFC2461 paragraph above

 2. When a node affiliates with multiple routers, upper-layer hints of
    forward progress MUST NOT be used for reachability confirmation.
    Instead, the node MUST actively probe neighboring routers using
    unicast Neighbor Solicitation messages as in the second paragraph
    of RFC2461

Note that in case 2), ONLY those routers that are actively carrying outgoing
traffic are probed. There is no need to probe routers that carry only return
traffic, since the forward direction is all that is needed.

Comments?

Fred Templin
ftemplin@iprg.nokia.com