ND (NUD) on ISATAP links

Hi,

Let me apologise in advance - I have not previously followed the ISATAP discussion on the list 
so the issue in question might have been discussed at length already, if this is the case - simply ignore !

The ISATAP draft - v04 states that NC (Neighbour Cache) should be maintained on ISATAP links 
and that NUD (Neighbour Unreachable Detection) should be performed in
accordance with RFC 2461 - only IPv6 address resolution should simply be done by 
static computation (to the embedded IPv4 address, which in this respect is the link-layer address).
Well, at least this is how I read Section 5-5.1.

I have two problems with this :
- First of all I am concerned with whether maintaining NC on ISATAP links will scale for
routers on large Intra-Sites. In principle, then I suppose that an Intra-Site could be the 
global IPv4 Network. Shouldn't this mechanism be allowed disabled on large links ?

- My second problem is that in this respect then it seems that maintaining NC and NUD 
as performed in RFC 2461 amounts to nothing.
That is:

NUD in RFC 2461 seems to amount to two things:
- ONE- To ensure prompt detection of movement of neighbours 
      and subsequent updating of conceptual ARP cache (new address resolution successful)
- TWO -To advise of black holing of packets caused by unreachability 
      of neighbouring nodes (new address resolution fails - ICMP destination unreachable generated)

The first issue will in ISATAP presumably be taken care of by the IPv4 layer 
which will ensure that the IPv4 address points to the right MAC address.
Further the IPv4 layer will generate the appropriate ICMP's in case the 
IPv4 address isn't reachable (black hole)
regardless of whether NC is maintained or IPv6 NUD is performed.

What is left is the second issue in case the IPv4 address 
is reachable but the ISATAP host behind it is not.
 
For non-ISATAP links (NUD in RFC 2461) - TWO - is taken care of first of all
by the IPv6 address resolution which (this is important) ensures that the IPv6
 stack of the neighbour in question is operational (and reachable) 
(a failure of which results in the appropriate ICMP being generated to advertise of black hole)
and secondly by the NC/NUD algorithm which ensures that unverified NC's expires so
that IPv6 address resolution will be performed anew  

In ISATAP the NC/NUD algorithm in the case : 
*IPv4 address is reachable but the ISATAP host behind it is not*
seems to proceed as follows (skipping some steps in the algorithm):

IPv6 NC: V6prefix:0:5EFE:V4ADDR corresponds to V4ADDR
is created by static computation (no reachability confirmation of ISATAP host is received)
Black holing will occur. 
After some point in time, the NC becomes STALE, PROBE etc.
and unicast NS/NA exchanges are attempted.
Black holing still occurs.
When a number of NS'a have remained unanswered, the NC will be deleted.
The new packet for the destination :V6prefix:0:5EFE:V4ADDR 
will result in new NC exactly as before:
V6prefix:0:5EFE:V4ADDR corresponds to V4ADDR
being created and black holing will continue.

- What am I missing  ?? - Or - is it OK to black hole in this case, and if yes, what should
IPv6 NC and NUD, then be used for on ISATAP links ??

(One way to fix the problem could be to demand that static 
address resolution on ISATAP links should be followed by
a unicast NS/NA exchange, thus
confirming the reachability of the ISATAP hosts)

Karen

-------------------------------------------------------------------
Karen Egede Nielsen, Ericsson Telebit A/S
-------------------------------------------------------------------