Re: NUD for ISATAP Routers

Karen,

The co-authors discussed this issue in some detail, and the intended
meaning of the base specification is that ISATAP nodes SHOULD send NSs
and MUST send solicited NAs to establish neighbor cache state even though
address resolution is done via static computation. So, the functionality
is recommended (but optional) for the source and mandatory for the target.

Even so, there may be an operational issue for ISATAP routers when the base
specification alone is used, since hints of forward progress probably will
not be available from upper layers, i.e., reliable transport connections are
normally forwarded *through* the router; not terminated *at* the router. If
alternate paths exist, this could result in a unidirectional link *from* the
ISATAP source node *to* the next-hop ISATAP router, which may cause operational
problems in some cases.

When the base specification alone is used, one implementation alternative that
will satisfy many deployment scenarios is to restrict ISATAP nodes to accepting
packets from and sending packets to *exactly one* ISATAP router; even though
numerous potential routers may be available. But, a more generalized, robust,
secure, and scalable alternative is to provide optional extensions to the base
specification that ensure link bi-directionality even when alternate paths exist.
Such an optional extension is proposed here:

   http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt

Does this help clarify things?

Fred Templin
[email protected]

Karen E Nielsen (TED) wrote:
 > Hi,
 >
 > Looking into the latest Isatap draft (v06) I am (still) puzzled by the fact
 > (Section 5.1) that ISATAP nodes SHOULD perform NUD in accordance with RFC 2461,
 > although we all agree (I think) that NUD in accordance with RFc 2461 doesn't work
 > for ISATAP routers -
 > What NUD functionality do you demand (SHOULD) on an ISATAP Router interface ???
 >
 > Karen