RE: ND (NUD) on ISATAP links

Hi Tim,

Thanks a lot for your comments !

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

I agree, but in any case IPv6 NC and IPv6 NUD with static address resolution
will not buy you any additional information. As long as we rely on
static address resolution without confirmation of IPv6 stack operability, 
IPv6 NC and NUD will only be as good as the service provided by the IPv4 layer.

> > 
> > 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.
> 
If these ICMP's always were generated (and translated by the receiving hosts)
we do not need an "IPv6 NUD mechanism" on ISATAP links.
When they are not (which would be a way to prevent DoS and therefore might be the chosen
path for some), we need an "IPv6 NUD mechanism", but again IPv6 NUD with static address resolution
doesn't give that.

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

As you say, regardless of which state the NC is created in, the NUD mechanism
combined with static address resolution simply doesn't work. It only adds processing overhead.

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

Upper layers for hosts.
Origination hosts for routers.

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

Well, actually my question(s) is:

1. Do we want "real" IPv6 NUD on ISATAP links ? - Or
2. Do we want *only* the NUD functionality achieved by virtue of 
   the mechanisms provided by the IPv4 layer ?
3. Is it sound to require NUD to be performed on ISATAP links.

If the answer to 1. is Yes, then a mechanism need to be defined.
This does not necessarily need to involve changing NUD from 2462, it could simply be fixed
by doing NS/NA exchange on top of static address resolution in ISATAP (or something else), i.e.
one would define an "ISATAP IPv6 address resolution mechanism" or if you like
an "IPv6 over NMBA address resolution mechanism" and then use this combined with RFC 2461.
Strictly speaking this doesn't mean adding a new state to the resolution/NUD mechanism, you're
simply replacing standard (multicast) IPv6 address resolution with something else.

If the answer to 2. is Yes. Then ISATAP tunnels should wrt ND behave as general
automatic tunnel mechanism, RFC 2893, i.e. NC and NUD need not be maintained since
it has no effect.

Wrt. 3 This might be sound for hosts, but is doesn't seem to scale for routers on large links.


Karen