Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-isatap-03.txt

From: [email-masked]
Date: Fri, 01 Feb 2002 07:01:31 -0500

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		: Intra-Site Automatic Tunnel Addressing Protocol 
                          (ISATAP)
	Author(s)	: F. Templin et al.
	Filename	: draft-ietf-ngtrans-isatap-03.txt
	Pages		: 15
	Date		: 31-Jan-02
	
This document specifies the Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within
IPv4 sites. ISATAP is a transition mechanism that enables incremental
deployment of IPv6 by treating the site's IPv4 infrastructure as a
Non-Broadcast Multiple Access (NBMA) link layer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-03.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-03.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-03.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: "Dave Thaler" <[email-masked]>
Date: Fri, 8 Feb 2002 10:47:10 -0800

> > We are certainly open to other opinions on this. But, since we're
> defining
> > the term here (and only for use in this document) whether/not to
> introduce a
> > new term such as "pseudo-interface" seems like a matter of personal
> preference.
> > RFC 2461 sets the example for IPv6 neighbor discovery over specific
link
> layer
> > documents, and it does not define "pseudo-interface" - neither does
RFC
> 2893,
> > which sets the example for auto-tunnelling mechanisms. Both of these
> documents
> > are normative references for ISATAP. RFC 3056 defines "6to4 pseudo-
> interface",
> > but it is an informative reference (not normative) for ISATAP.
> 
> This is a personal preference, I suppose; I'd just rather call only
> "physical" interfaces "interfaces".

Then your personal preference is at odds with RFC 2863 and its
predecessors, which is as close as we come to an official IETF
definition of the term "interfaces".  

> > We also define 'ISATAP prefix', thus an ISATAP address must satisfy
> > both conditions (i.e., have both an ISATAP prefix and an ISATAP
format
> > interface ID).
> 
> Oh.. I thought ISATAP could be used on existing IPv6 infrastructure,
with
> no need to set up a separate prefix for it.  

Yeah that's not the way it works.  You have to assign an SLA to
the ISATAP link which is not assigned to any other links (unless you're
doing multilink subnets, but that's a different topic).

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 8 Feb 2002 10:47:10 -0800

link
RFC

format
with

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 11 Feb 2002 14:19:18 -0800

> > This was discussed at the interim meeting in Seattle.  As a
> > transition mechanism, ease of debugging and management is important.
> > Using a well known format means that you can pretty-print embedded
> > IPv4 addresses, and the usefulness of this should not be
> > underestimated.
> 
> you are not suggesting to indiscriminately print all IPv6 addresses
> with bit pattern '5EFE' as ISATAP addresses are you?

Yes, that's exactly what we do.

> I would consider that a bad idea because of the possibility of false
> positives, e.g for randomly generated addresses, 

As was also mentioned at the interim meeting, when we randomly
generate addresses, we avoid using this range, and I think it's
a good idea for everyone to do.

> manually configured addresses, 

I don't consider this a problem, if you're doing manual config you
should know what you're doing. 

> or where the address is subnetted further than /64.

Autoconfig with longer than /64 is not supported on any interface
that uses EUI-64, and so is sufficiently obscure/rare today that it's
not interesting (to me at least) during the lifetime of a transition
mechanism.
 
> if you agree that it is most useful to pretty-print ISATAP addresses
> on nodes connected to an ISATAP link, there is no need for a special
> bit pattern. an implementation knows which addresses belongs to the
> ISATAP link.

This is simply not true.  A client doing a DNS lookup has no idea
whether the addresses it gets back are on an ISATAP link or not,
save for the address itself.  The only node that knows it's on an
ISATAP link is the node itself, and we want an address to be
pretty-printed the same way by all nodes.

> I suggest you replace the interface identifier construction text with
> section 3.7 in RFC2893, or just refer to it.

I disagree.

-Dave