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

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Fri, 11 Oct 2002 11:08:04 +0200

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

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 11 Oct 2002 09:53:53 -0400

Karen E Nielsen (TED) wrote:
Karen

Consider a behavior of an ISATAP host that connects to multiple
ISATAP router and is attempting to establish a connection
to an IPv6 native address.

I can see NUD being performed to the ISATAP router and
if NUD proves the router unreachable (IPv6 address of
the router is not reachable), another router may be tried.

This is the case where I see NUD being usefull in the ISATAP
environment.  You are right that it is not very usefull between
2 ISATAP hosts.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 17 Oct 2002 17:54:51 -0400

Jason

Jason Goldschmidt wrote:
> 
> 
> As Karen pointed out, performing NUD between ISATAP hosts and each 
> router in its PRL will impose scalability problems for ISATAP.  If using 
> the default REACHABLE_TIME value of 30 seconds, this will impose a large 
> strain on ISATAP's routers for sites with 1000+ ISATAP hosts.  Obviously 
> REACHABLE_TIME could be increased, but then it is not clear what value 
> implementing NUD would buy over simply decreasing the minimum value for 
> router lifetime (and in hand decreasing MinRouterSolicitInterval).

NUD is not performed between hosts and "each router in its PRL".  It is
performed between a host and a (one) router from the PRL that is
currently being used.

The router that will be selected by the host will depend on the traffic
patterns from that host and any destination cache entries that may exist.
The reason for NUD is that the IPv6 address of the router may not be 
reachable even though the IPv4 address is reachable.  This is exaclty
what NUD is used for.

The scalability problem you mention only happens when there are
very few routers serving a lot of hosts.  In that case, a particular router
is more likely to be picked as a next hop and NUD will be run after the
AdvReachableTime has expired. The consuption of resources on that ISATAP 
router will roughly equivalent to a normal IPv6 router in a similar 
configuration (+ the extra is a tunnel overhead) so I don't see a large 
problem with scalability.

> 
> Thus I'm not convinced implementing NUD to prevent black-holing is a 
> viable solution.
> 
> Can you please explain the benefits of having an ISATAP host connect to 
> multiple ISATAP routers?  If the goal is for redundancy, this might be a 
> hard goal to achieve if the above problem can not be solved.

It may be redundancy.  It may be multihoming (you have 2 different ISATAP
prefixes).  I think the authors of the draft can comment more since multiple
routers are explicitely described in the draft.

-vlad

> -Jason