[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt
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-
So on my side, the new version covers all wglc comments and then
would be ready for iesg.
... I'd rather like to see the sentence used in RFC3330:
"Addresses within this block should not appear on the public Internet"
The document should mention something about IPv4 compatible
addresses, if only to say they were deprecated (are they really? I
What about addresses outside of 2::/3?
<MB>not done. they are not special addresses, they are non-assigned
The document should have a normative reference to RFC3513
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
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
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".
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
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.