Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

From: [email-masked]
Date: Mon, 29 Nov 2004 15:16:38 -0500

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

	Title		: Unique Local IPv6 Unicast Addresses
	Author(s)	: R. Hinden, B. Haberman
	Filename	: draft-ietf-ipv6-unique-local-addr-08.txt
	Pages		: 17
	Date		: 2004-11-29
	
This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications, usually inside of a
   site.  They are not expected to be routable on the global Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ipv6-unique-local-addr-08.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-ipv6-unique-local-addr-08.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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 29 Nov 2004 14:40:42 -0800

>         Filename        : draft-ietf-ipv6-unique-local-addr-08.txt

The changes in this draft were to resolve more of the IESG discuss 
comments.  The summary of these changes:

       o Moved sections 4-10, into one new section 4.0 titled
         "operational guidelines" to clarify the their scope.
       o Clarified routing requirements to make it clearer that these
         prefixes should not be routed on the global Internet.
       o Various editorial changes.

A diff from the -07 version can be found at:

  http://people.nokia.net/~hinden/ULA/draft-ietf-ipv6-unique-local-addr-08.html

Bob

---

From: Mark Andrews <[email-masked]>
Date: Tue, 30 Nov 2004 10:16:38 +1100

Section 4.4 DNS Issues

	This sections appears to be a real cop out.

	It is perfectly natural for clients to want to make queries and
	have these addresses returned from the DNS.

	The problem is that there is no co-ordinating authority for
	D.F.IP6.ARPA and if we let queries be made the servers for
	F.IP6.ARPA (or IP6.ARPA) will be swapped.  Similarly we can
	force public servers for zones under C.F.IP6.ARPA.  I propose
	that we actually allow these addresses to be returned but
	that (caching) nameservers be automatically configured to
	return Name Error for queries under D.F.IP6.ARPA and (maybe)
	C.F.IP6.ARPA and that *explicit* configuration be required
	to get a different response.

	e.g.
	that the server behaves as if the following zones are loaded.

	C.F.IP6.ARPA. 3600 IN SOA C.F.IP6.ARPA. RFCXXXX.C.F.IP6.ARPA. (
				  1 7200 3600 604800 3600 )
	C.F.IP6.ARPA. 3600 IN NS  C.F.IP6.ARPA.
	C.F.IP6.ARPA. 3600 IN TXT Automatically generated as per RFCXXXX

	D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. RFCXXXX.D.F.IP6.ARPA. (
				  1 7200 3600 604800 3600 )
	D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA.
	D.F.IP6.ARPA. 3600 IN TXT Automatically generated as per RFCXXXX

	Note 1: the above zones can be used by existing for servers to
		achieve the same behaviour.

	Note 2: There are no addresses associated with the nameservers,
		sites may want to assign a address (e.g. ::1).

	Note 3: RFCXXXX.[CD].F.IP6.ARPA above could be replace by
		a local contact address.
	
	Co-operating sites are would secondary the relevent local reverse
	zones (X.X.X.X.X.X.X.X.X.X.[CD].F.IP6.ARPA.) or manage their own
	[CD].F.IP6.ARPA zones.
	
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Nov 2004 16:41:33 -0800

Mark,

>         have these addresses returned from the DNS.

There is a wide range of views on what is appropriate for putting these 
addresses in the global DNS.  For now, I think the best way to move this 
document forward is to leave it as is and wait until we have operational 
experience.  Once there is some operational experience it would be good if 
V6OPS or DNSOPS wrote a document about the best way to do it.

Bob

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Dec 2004 11:50:30 +1100

> V6OPS or DNSOPS wrote a document about the best way to do it.
 
	I think there is plenty of IPv4 experience that translates to
	this area.  This is basically saying that the as112 should be
	the default treatment for these reverse zones.

	See http://www.as112.net/