[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-00.txt
On 22-Mar-2007, at 12:13, Fred Baker wrote:
"Special-Use IPv6 Addresses", Marc Blanchet, 22-Mar-07,
Comments below, in-line.
I think this draft serves a useful purpose, and support its eventual
publication in the RFC series (presumably as "Informational"?).
General: the document doesn't specify what it means by "advertise"
with any degree of precision. It seems to me that it should state
clearly during the introduction that the recommendations are
concerned with advertisements made between autonomous systems on the
Internet, and not between any other routers that might be in the
business of moving IPv6 datagrams.
This document describes the global and other specialized IPv6
Editorial: missing space between "blocks." and "It".
It does not address IPv6 address space assigned to
and users through the Regional Internet Registries.
Editorial: "It does not address [...] address space" is ugly. Perhaps
"It does not discuss", or use the passive voice ("IPv6 address space
assigned or allocated by Regional Internet Registries is not
discussed in this document").
The editorial comments above also apply to section 1, which contains
the same text as the abstract.
2. Address Types
2.1. Node-scoped Unicast
::1/128 is the loopback address [RFC4291].
::/128 is the unspecified address [RFC4291].
The node-scoped unicast addresses should not be advertised and
be filtered out when received.
Editorial: make it "These node-scoped unicast addresses" or just
2.3. Link-scoped Unicast
fe80::/10 are the link-local unicast[RFC4291] addresses.Link-local
addresses should not be advertised and should be filtered out when
Editorial: missing space between "addresses." and "Link-local".
2.4. Site-scoped Unicast
fc00::/7 are the unique-local addresses [RFC4193]. Unique-local
addresses should not be adverstied on the public Internet.
Editorial: perhaps redact "on the public Internet" if the meaning of
"advertisement" throughout the document is clarified, as suggested
above. Spelling mistake/typo in "adverstied".
2.5. Documentation Prefix
The 2001:0db8::/32 are the documentation addresses [RFC3849]. They
are used for documentation purposes such as user manuals, RFCs,
Documentation addresses should not be advertised and should be
filtered out when received.
Editorial: make it "Addresses covered by 2001:db8::/32 are
2002::/16 are the 6to4 addresses [RFC4291][RFC3056]. The 6to4
addresses may be advertised when the site is running a 6to4
offering a 6to4 transit service. However, the provider of this
service should be aware of the implications of running such
service[RFC3964], which includes some specific filtering rules for
Editorial: redact the word "the" before "6to4 addresses".
Presumably the filtering rules alluded to at the end relate to the
plausibility of the embedded IPv4 addresses within the 6to4 address?
Perhaps a reference to RFC3330 would be useful, there?
2001::/32 are the Teredo addresses [RFC4380]. The Teredo addresses
may be advertised when the site is running a Teredo relay or
a Teredo transit service.
RFC 4380 describes that address as "2001:0000::/32" (well, actually
it says "2001:0000:/32", missing the trailing colon before the
forward slash, which is presumably a typo). Whilst obviously
2001::/32 and 2001:0000::/32 are equivalent, the latter format
perhaps aids clarity given that many people have 2001::/16 in their
heads as being special, given that it's the first block from which
RIRs made unicast allocations.
2.9. Default Route
::/0 is the default unicast route address.
Editorial: "route address" seems clumsy to me. Surely "... is the
default route." is sufficient.
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
site, where X may be any value.
Editorial: make it "Addresses covered by ff00::/8 are multicast
X presumably may be any _four-bit_ value, not *any* value :-)