Subject: Reachability confirmation issue for ISATAP routers (plus solution)

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Nov 2002 16:38:19 -0800

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

---

From: Jason Goldschmidt <[email-masked]>
Date: Mon, 18 Nov 2002 07:21:40 -0800

Hi Fred,

Sorry for the slow reply and thank you for summarizing the problem for 
everyone.

>     unicast Neighbor Solicitation messages as in the second paragraph

I don't understand how this is a solution.  Requiring this probing will 
seriously limit the scalability of ISATAP.  Given the architecture for 
ISATAP, NS/NA messages will need to be sent unicast between ISATAP hosts 
and routers.  What this means is that each ISATAP host will be sending 
an NS message every 30 seconds or so (depending on the host 
configuration, but 30 seconds is the default timer for ND).  The ISATAP 
router would need to reply to all of these messages, since there is no 
way for hosts to passively listen for ND messages sent to 
ipv6_all_nodes.  This would create a packet storm of ND messages on a 
semi-large network deploying ISATAP.  Requiring (or even making this 
mechanism a SHOULD) is a really bad idea.  At best it should be a MAY 
with strong wording suggesting the scalability issues I mentioned above.  

> traffic, since the forward direction is all that is needed.

I don't understand what you mean by "routers actively carrying outgoing 
traffic"?  Is it possible that you are refering to only those routers 
that an ISATAP host has affiliated with and has defined a 'default 
route'?  It seems you are talking about a scenario (packets going out 
router B from A->D and returning on C from D->A) were the usage of the 
PRL is compounded.  I want to understand how router 'C' might not fall 
into your "ONLY" statement above.

thanks,
-Jason

---

From: Fred Templin <[email-masked]>
Date: Tue, 19 Nov 2002 20:22:07 -0800 (PST)

Jason,

Sorry for the delay; I needed to confer with one of the co-authors before
responding:

> with strong wording suggesting the scalability issues I mentioned above.

After conferring with one of the co-authors, we agree with your above
comments. Hints of forward progress may tell only unidirectional link
information in some cases when there are multiple ISATAP routers. But,
this is only an issue if important ICMPs (e.g., ICMPv4 fragment needed)
are being black-holed along the reverse-path to the source from the
egress router. This presents a possible issue for Path MTU discovery
in operational scenarios, but note that RFC 1981 allows path MTU
discovery to be disabled. After consulting with the co-authors, we
may decide to write this up as an operational consideration in -07.  

> into your "ONLY" statement above.

Not quite following you, but the concern here again was the case of ICMPs
being black-holed along the reverse path to the source. Let me know if the
above comments spoke sufficiently to the (non)issue.
 
> -Jason

Regards,

Fred Templin
[email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com