RE: ND (NUD) on ISATAP links

Karen,

I haven't seen it before so thanks for bringing it up.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Karen 
> E Nielsen (TED)
> Sent: Thursday, October 10, 2002 10:23 PM
> To: [email protected]; 'Fred L. Templin'
> Subject: (ngtrans) ND (NUD) on ISATAP links

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

You're likely, but not certain, to get the unreachables, and it might
take a while for (for example) the last hop router to assure itself that
the IPv4 host is dead and generate the unreachable. Or you may be on the
same IPv4 hop as the destination, in which case your host will wait for
ARP to fail.

> 
> What is left is the second issue in case the IPv4 address 
> is reachable but the ISATAP host behind it is not.

ISATAP is likely to be deeply bound into a stack, so the "ISATAP host"
not being reachable likely means that the whole IPv6 stack is down. If
IPv4 can't find a taker for a protocol 41 packet it should generate a
protocol unreachable ICMP. But I can easily imagine such packets being
swallowed without a trace.

In any case, I think your point is that you won't always be informed
rapidly when a neighbor dies even when communicating actively with it.

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

Yes, you get liveness detection free at the same time when doing address
resolution.

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

The above analysis assumes perhaps that the NC entry starts in the
REACHABLE state. There's a paragraph in [RFC2461,7.3.3], the first one
at the top of page 70. This deals with the creation of an NC entry other
than by address resolution - for example when you hear a router
solicitation. It says:

   Placing a newly created Neighbor Cache entry for which
   the link-layer address is known in the STALE state provides assurance
   that path failures are detected quickly.

Creation of an NC entry by "static resolution" might fall into this
category. This would get reachability detection invoked earlier, but it
probably just makes us spin through the NC states, then delete, then
recreate, faster than if we started in REACHABLE. The NUD mechanism
doesn't look very useful here.

Maybe your question "is it OK to black hole in this case" could perhaps
be expanded to "is it OK to black hole in this case without telling
upper layers"? I think upper layers currently only get told about
failures in address resolution  - which we don't do for ISATAP. I'd be
hesitant about suggesting the addition of a new state to the
resolution/NUD machine for just ISATAP, which is a transition mechanism.
This might be an issue for other NBMA mechanisms with their own address
resolution protocols.


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

Tim