Subject: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt

From: [email-masked]
Date: Thu, 13 Jun 2002 07:24:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Tradeoffs in DNS support for IPv6
	Author(s)	: R. Austein
	Filename	: draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt
	Pages		: 10
	Date		: 12-Jun-02
	
The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better.  This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-02.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-dnsext-ipv6-dns-tradeoffs-02.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-dnsext-ipv6-dns-tradeoffs-02.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: Rob Austein <[email-masked]>
Date: Thu, 13 Jun 2002 11:35:34 -0400

Non-cosmetic subset of the diffs since -01 attached for those who want
to know what changed without having to read the whole document yet
again.  Thanks to Ed Lewis for proofreading -01.

--- draft-ietf-dnsext-ipv6-dns-tradeoffs.ms	2002/05/10 18:29:51	1.3
+++ draft-ietf-dnsext-ipv6-dns-tradeoffs.ms	2002/06/07 03:30:43	1.5
@@ -344,22 +344,22 @@
 building the reverse mapping tree (the IPv6 equivalent of IPv4's
 IN-ADDR.ARPA tree).
 
-[Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA
+[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
 mechanism used for IPv4 addresses: the RR name is the hexadecimal
 representation of the IPv6 address, reversed and concatenated with a
 well-known suffix, broken up with a dot between each hexadecimal
 digit.  The resulting DNS names are somewhat tedious for humans to
 type, but are very easy for programs to generate.  Making each
 hexadecimal digit a separate label means that delegation on arbitrary
-bit boundaries will result in a maximum of 16 NS RRs per label; again,
-the mechanism is somewhat tedious for humans, but is very easy to
-program.  As with IPv4's IN-ADDR.ARPA tree, the one place where this
-scheme is weak is in handling delegations in the least significant
-label; however, since there appears to be no real need to delegate the
-least significant four bits of an IPv6 address, this does not appear
-to be a serious restriction.
+bit boundaries will result in a maximum of 16 NS RRsets per label
+level; again, the mechanism is somewhat tedious for humans, but is
+very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one place
+where this scheme is weak is in handling delegations in the least
+significant label; however, since there appears to be no real need to
+delegate the least significant four bits of an IPv6 address, this does
+not appear to be a serious restriction.
 
-[Tweedledum] proposed a radically different way of naming entries in
+[RFC2874] proposed a radically different way of naming entries in
 the reverse mapping tree: rather than using textual representations of
 addresses, it proposes to use a new kind of DNS label (a "bit label")
 to represent binary addresses directly in the DNS.  This has the
@@ -520,6 +520,16 @@
 Private message to the author from Bill Sommerfeld dated 21 March
 2001, summarizing the result of experiments he performed on a copy of
 the MIT.EDU zone.
+
+.ne 2
+.ti 3
+[GSE]
+"GSE" was an evolution of the so-called "8+8" proposal discussed by
+the IPng working group in 1996 and 1997.  The GSE proposal itself was
+written up as an Internet-Draft, which has long since expired.
+Readers interested in the details and history of GSE should review the
+IPng working group's mailing list archives and minutes from that
+period.
 
 .in 6
 .ti 0

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jun 2002 01:52:31 +0859 ()

Rob Austein;

>  to represent binary addresses directly in the DNS.  This has the

GSE has nothing to do with the so-called "8+8" proposal ignoring
all the important points discussed in BigI or IPng ML and is a
complete nonsense.

Readers interested in the details and history of GSE should learn
to ignore it.

							Masataka Ohta

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>