Re: ND (NUD) on ISATAP links

Hello Karen,

No, in fact the issue you have raised here is quite new and deserves careful
consideration. I would certainly appreciate the assistance of my co-authors
on this one, since my expertise in the area of neighbour discovery is not as
extensive as theirs. Tim, Dave, or Mohit can you please comment on Karen's message?

Fred
[email protected]

Karen E Nielsen (TED) wrote:
 > 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
> -------------------------------------------------------------------
>