Subject: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt

From: [email-masked]
Date: Thu, 12 Jul 2007 13:16:51 -0400

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

	Title		: Special-Use IPv6 Addresses
	Author(s)	: M. Blanchet
	Filename	: draft-ietf-v6ops-rfc3330-for-ipv6-01.txt
	Pages		: 7
	Date		: 2007-7-12
	
This document describes the global and other specialized IPv6 address
   blocks.It does not address IPv6 address space assigned to operators
   and users through the Regional Internet Registries.  These
   descriptions are useful for route and IP filtering, for documentation
   and other purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3330-for-ipv6-01.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-v6ops-rfc3330-for-ipv6-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-v6ops-rfc3330-for-ipv6-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: Marc Blanchet <[email-masked]>
Date: Mon, 23 Jul 2007 12:51:28 -0500

Hi,
  this new version should cover all WGLC comments. A summary of  
comments and answers in <MB> form are below.

diff of the new draft: http://tools.ietf.org/wg/v6ops/draft-ietf- 
v6ops-rfc3330-for-ipv6/draft-ietf-v6ops-rfc3330-for-ipv6-01- 
from-00.diff.html

So on my side, the new version covers all wglc comments and then  
would be ready for iesg.

Marc.

====================
  ... I'd rather like to see the sentence used in RFC3330:

"Addresses within this block should not appear on the public Internet"

<MB> done</MB>

====================
The document should mention something about IPv4 compatible
addresses, if only to say they were deprecated (are they really? I  
lost track).

<MB>added</MB>

====================
What about addresses outside of 2::/3?

<MB>not done. they are not special addresses, they are non-assigned  
addresses.</MB>

====================
The document should have a normative reference to RFC3513

<MB>done</MB>

============

Well, it has a blank one. But can Marc check carefully for consistency
with http://www.iana.org/assignments/ipv6-unicast-address-assignments ?
And maybe there should be a non-blank IANA action: to add a reference to
this RFC from that registry? And do we want IANA to list things like the
former 6bone prefixes, or to list Teredo explicitly?

<MB>I added a note about the IANA IPv6 address special purpose  
registry[RFC4773]</MB>

===========
RFC 3513 describes the rules for many of these address types in more  
detail.  It would be better to not try to summarize RFC 3513 text.   
If this document needs to include these, it would be better to just  
point to the appropriate section of RFC3513 instead of summarizing.

<MB>I guess that the comments about "summarizing" was mostly about  
multicast addresses and unique-local, so I made new versions. </MB>

===========
    fc00::/7 are the unique-local addresses [RFC4193].  Unique-local
    addresses should not be adverstied on the public Internet.

This isn't correct.  ULA's are not site-scoped, see Section 3.3 Scope  
Definition.

The procedure for when/if they should be advertised is described in  
detail in RFC4193.  The above summary isn't a good substitute for  
this.  For example, this is missing "by default".

<MB>Done.</MB>

=======
I'd say that section 2.9 should be removed.  Default route is IMHO  
not a special address(-prefix) in any way.  How you want to treat it  
differs in each network both in IGP and BGP, so perhaps saying  
nothing is the right thing to do.

<MB>section is not removed, but no word on routing is put</MB>

========
2.10 is somewhat incorrect on Multicast:

    ff00::/8 are multicast addresses [RFC4291].  They have a 4 bits  
scope
    in the address field.  Only addresses having the 'E' value in the
    scope field are of global scope, all other values are local or
    reserved.  Therefore, only ffXe:: routes may be advertised outside a
    site, where X may be any value.

'site-scope' multicast has the scope value '5' and the rest between 6  
through D are unassigned except for '7' (organization-local scope).

The document defines:

         scopes labeled "(unassigned)" are available for administrators
         to define additional multicast regions.

Therefore I think it would be an end run to say only 'E' should be  
acceptable because administrators are welcome to use anything higher  
than '5' in scopes greater than a site.

<MB>Done</MB>