Subject: (ngtrans) NUD for ISATAP Routers

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Thu, 7 Nov 2002 10:35:33 +0100

Hi,

Looking into the latest Isatap draft (v06) I am (still) puzzled by the fact
(Section 5.1) that ISATAP nodes SHOULD perform NUD in accordance with RFC 2461, 
although we all agree (I think) that NUD in accordance with RFc 2461 doesn't work
for ISATAP routers - 
What NUD functionality do you demand (SHOULD) on an ISATAP Router interface ???

Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 6. november 2002 12:31
> Cc: [email-masked]
> Subject: (ngtrans) I-D 
> ACTION:draft-ietf-ngtrans-isatap-scenario-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Next Generation Transition 
> Working Group of the IETF.
> 
> 	Title		: ISATAP Transition Scenario for 
> Enterprise/Managed 
>                           Networks
> 	Author(s)	: F. Templin et al.
> 	Filename	: draft-ietf-ngtrans-isatap-scenario-01.txt
> 	Pages		: 6
> 	Date		: 2002-11-5
> 	
> This document discusses application of the Intra-Site Automatic
> Tunnel Addressing Protocol (ISATAP) as a transition tool for
> enterprise/managed networks. The enterprise/manged network problem
> space is described, and the ISATAP transition scenario for
> enterprise/managed network environments is presented.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-
> scenario-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ngtrans-isatap-scenario-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-ietf-ngtrans-isatap-scenario-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 07 Nov 2002 11:28:49 -0800

Karen,

The co-authors discussed this issue in some detail, and the intended
meaning of the base specification is that ISATAP nodes SHOULD send NSs
and MUST send solicited NAs to establish neighbor cache state even though
address resolution is done via static computation. So, the functionality
is recommended (but optional) for the source and mandatory for the target.

Even so, there may be an operational issue for ISATAP routers when the base
specification alone is used, since hints of forward progress probably will
not be available from upper layers, i.e., reliable transport connections are
normally forwarded *through* the router; not terminated *at* the router. If
alternate paths exist, this could result in a unidirectional link *from* the
ISATAP source node *to* the next-hop ISATAP router, which may cause operational
problems in some cases.

When the base specification alone is used, one implementation alternative that
will satisfy many deployment scenarios is to restrict ISATAP nodes to accepting
packets from and sending packets to *exactly one* ISATAP router; even though
numerous potential routers may be available. But, a more generalized, robust,
secure, and scalable alternative is to provide optional extensions to the base
specification that ensure link bi-directionality even when alternate paths exist.
Such an optional extension is proposed here:

   http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt

Does this help clarify things?

Fred Templin
[email-masked]

---

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Fri, 8 Nov 2002 11:58:44 +0100

Hi Fred,

I can see lots of reasons for demanding an Isatap HOST to perform NUD
on its neighbours (enabling it to change between Isatap routers etc.)

Further it is natural to demand (MUST) all Isatap nodes to cooperate
with other nodes performing NUD by responding to solicited NS.

What I do not understand is why an Isatap ROUTER in the "base specification" 
SHOULD perform NUD in accordance with 2461 on it's Isatap hosts, when we agree that
this mechsnism is broken and for ROUTERS amounts to nothing (except for overhead).
I would suggest either to omit this requirement for ROUTERS or then at 
least describe how the NUD mechanism from 2461 should be altered in order to
make it meaningful (and scalable) for a ROUTER.

Karen

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Nov 2002 15:28:46 -0800

Karen,

 > make it meaningful (and scalable) for a ROUTER.

I believe what you are saying is consistent with our intended
meaning. But, the text in the draft seems to be coming across to
you as too restrictive and this was not our intention (Tim, Mohit,
or Dave - please let us know if you disagree.) Let's look at the
two elements of section 5.1 that may be causing confusion in
more detail:

    Protocol addresses (IPv6) in ISATAP are resolved to link-layer
    addresses (IPv4) by a static computation, i.e., the last four octets
    are treated as an IPv4 address.

I do not believe there should be any confusion in what is being
said here, but what is *not* said is whether/not the node should
send NSs and wait for NAs at the time the static computation is
done. This seems to me to be an implementation alternative that
may provide faster unreachability detection in some cases, i.e.,
it is not required for interoperability. Perhaps a sentence could
be added to the effect of "Nodes MAY send NSs and wait for NAs
when performing static computation." I personally don't believe
this is needed, but I could possibly be convinced otherwise.

    ISATAP nodes SHOULD perform Neighbor Unreachability Detection (NUD)
    as specified in [DISC, 7.3], and MUST send solicited neighbor adver-
    tisements as specified in [DISC, 7.2.4].

The "SHOULD" here seems to be your bone of contention, and I can
understand your concern. But, I believe we were intending a looser
interpretation of the SHOULD, based on our earlier discussions on
NUD for routers. Perhaps a slight re-wording such as the following
could help disambiguate things:

    + ISATAP routers MAY and ISATAP nodes SHOULD perform Neighbor
    + Unreachability Detection (NUD) as specified in [DISC, 7.3].
    + ISATAP nodes MUST send solicited neighbor advertisements as
    + specified in [DISC, 7.2.4].

Does this address your concerns?

Fred
[email-masked]