Subject: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt

From: [email-masked]
Date: Fri, 25 Oct 2002 07:28:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Moving from 6bone to IPv6 Internet
	Author(s)	: P. Savola
	Filename	: draft-savola-v6ops-6bone-mess-00.txt
	Pages		: 13
	Date		: 2002-10-24
	
Currently, IPv6 Internet is, globally considered, inseparable from
the 6bone network.  The 6bone has been built as a tighly meshed
tunneled topology.  As the number of participants has grown, it has
become an untangible mess, hindering the real deployment of IPv6 due
to low quality of connections.  This memo discusses the nature and
the state of 6bone/IPv6 Internet, points out problems and outlines a
few ways to start fixing them; also, some rough operational
guidelines for different-sized organizations are presented.  The most
important issues are: not offering transit to everyone and real
transit operators being needed to take a more active role.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.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-savola-v6ops-6bone-mess-00.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-savola-v6ops-6bone-mess-00.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: Paul Vixie <[email-masked]>
Date: Fri, 25 Oct 2002 16:26:19 +0000

> http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt

i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt,
which addresses some of the dns-related issues in migrating away from 6bone.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 26 Oct 2002 01:44:17 +0900

>which addresses some of the dns-related issues in migrating away from 6bone.

	two comments -
	1. DNAME is not widely implemented in resolvers in the wild.  therefore
	   not many will be able to resolve "blah.int" with this scheme.
	2. if you drop $ORIGIN from the zone file, you will be okay with the
	   following configuration (which is simpler IMHO).

itojun

f.2.0.0.8.0.e.f.f.f.7.4.3.0.2.0.d.0.0.0  PTR  pa-blue.fwpaa.isc.org.
8.f.b.4.0.0.e.f.f.f.7.4.3.0.2.0.d.0.0.0  PTR  pa-blue.fwpab.isc.org.
e.7.0.b.3.c.e.f.f.f.b.2.0.0.a.0.d.0.0.0  PTR  isrv4.isc.org.
a.7.7.e.7.0.e.f.f.f.8.f.0.0.2.0.d.0.0.0  PTR  phred.isc.org.

2.3. BIND9's configuration file would include two "zone" declarations:

zone "8.f.4.0.1.0.0.2.ip6.arpa" {       // ARIN ISC6-1
	type master;
	file "pri/2001:04F8:";
};

zone "8.f.4.0.1.0.0.2.ip6.int" {        // ARIN ISC6-1 (.int)
	type master;
	file "pri/2001:04F8:";
};

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Oct 2002 19:44:23 +0300 (EEST)

> which addresses some of the dns-related issues in migrating away from 6bone.

The draft is focused on issues in routing (God knows, there are enough
problems there! :-) -- I'll consider whether this needs to be clarified or
the scope expanded so issue with ip6.int/ip6.arpa can be dealt properly.

Resolvers I'm using query ip6.arpa only so I'm constantly being bitten by 
this .. I really hope the political reasons were good enough...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Oct 2002 16:48:02 +0000

> 	   not many will be able to resolve "blah.int" with this scheme.

the dname logic executes in the authority servers, by synthesizing cnames.
so as long as the master and all slaves understand dname, this proposal works.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 26 Oct 2002 01:55:10 +0900

>so as long as the master and all slaves understand dname, this proposal works.

	then
	- how do you sign a zone with DNAME?  synthesize = you can't sign.
	- why DNAME resolution has to be kept in BIND8 resolver?
	  (i have sent a diff to remove DNAME processing in BIND8 resolver
	  distributed in BIND9 package, and i got "don't remove DNAME" comment)

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 26 Oct 2002 02:11:15 +0900

>	  distributed in BIND9 package, and i got "don't remove DNAME" comment)

	and
	- RFC2672 doesn't say that DNAME is a pseudo RR type (which does not
	  appear on wire), so i assume it is a real RR tyep (which appears
	  on the wire).  this is opposite from your statement above.

itojun

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Oct 2002 19:47:53 +0000

this isn't specifically ipv6 related, but it has to do with DNAME, which
is referred to in ISC-TN-2002-1 that was URL'd here earlier, so:

(my thanks to nominum for help providing these answers)

>	- how do you sign a zone with DNAME?  synthesize = you can't sign.

The synthesized CNAME won't be signed, but the DNAME will.  This just
means that anything capable of DNSSEC validation must look at the DNAME, 
not the CNAME.  That's exactly what BIND 9's internal resolver does.

>	  distributed in BIND9 package, and i got "don't remove DNAME" comment)

it should have been removed when we tore dnssec support out of bind8.  my
apologies for rejecting your patch earlier.  please resend :-).

> 	  on the wire).  this is opposite from your statement above.

It is a real RR type.  Any server that doesn't understand DNAMEs should 
treat it no differently than any other unknown RR types, and things will 
still work (because of the synthesized CNAMEs).