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

[Marc Blanchet <marc.blanchet@viagenie.ca>]

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>