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

Jason,

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

--- Jason Goldschmidt <[email protected]> wrote:
> Hi Fred,
> 
> Sorry for the slow reply and thank you for summarizing the problem for 
> everyone.
> 
> Fred L. Templin wrote:
> 
> >
> >  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
> 
> 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.

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.  

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

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.
 
> thanks,
> -Jason

Regards,

Fred Templin
osprey67=/[email protected]

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