RE: (ngtrans) NUD for ISATAP Routers

["Karen E Nielsen (TED)" <Karen.E.Nielsen@lmd.ericsson.se>]

Hi Fred,

I can see lots of reasons for demanding an Isatap HOST to perform NUD
on its neighbours (enabling it to change between Isatap routers etc.)

Further it is natural to demand (MUST) all Isatap nodes to cooperate
with other nodes performing NUD by responding to solicited NS.

What I do not understand is why an Isatap ROUTER in the "base specification" 
SHOULD perform NUD in accordance with 2461 on it's Isatap hosts, when we agree that
this mechsnism is broken and for ROUTERS amounts to nothing (except for overhead).
I would suggest either to omit this requirement for ROUTERS or then at 
least describe how the NUD mechanism from 2461 should be altered in order to
make it meaningful (and scalable) for a ROUTER.

Karen

> > 
> 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
> ftemplin@iprg.nokia.com
> 
> 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
>