Subject: (ngtrans) ND (NUD) on ISATAP links

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Thu, 10 Oct 2002 15:23:13 +0200

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

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 10 Oct 2002 10:26:03 -0700

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-masked]

---

From: "Timothy Gleeson \(tgleeson\)" <[email-masked]>
Date: Fri, 11 Oct 2002 17:20:16 +0900

Karen,

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

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

> 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 

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.

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

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  
> 
> *IPv4 address is reachable but the ISATAP host behind it is 
> not* seems to proceed as follows (skipping some steps in the 
> algorithm):
> 
> is created by static computation (no reachability 
> confirmation of ISATAP host is received) Black holing will occur. 
> When a number of NS'a have remained unanswered, the NC will 
> be deleted. The new packet for the destination 
> :V6prefix:0:5EFE:V4ADDR 
> - 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 ??
> 

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

Tim