[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:


http://tools.ietf.org/html/draft-ietf-v6ops-rfc3330-for-ipv6
  "Special-Use IPv6 Addresses", Marc Blanchet, 22-Mar-07,
  <draft-ietf-v6ops-rfc3330-for-ipv6-00.txt>

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.

Abstract


   This document describes the global and other specialized IPv6  
address

   blocks.

Editorial: missing space between "blocks." and "It".


           It does not address IPv6 address space assigned to  
operators

   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  
should

   be filtered out when received.

Editorial: make it "These node-scoped unicast addresses" or just  
"These addresses".

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
   received.

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,  
etc.

   Documentation addresses should not be advertised and should be
   filtered out when received.

Editorial: make it "Addresses covered by 2001:db8::/32 are  
documentation addresses".

2.6.  6to4

   2002::/16 are the 6to4 addresses [RFC4291][RFC3056].  The 6to4

   addresses may be advertised when the site is running a 6to4  
relay or

   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
   6to4.

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?

2.7.  Teredo

   2001::/32 are the Teredo addresses [RFC4380].  The Teredo addresses

   may be advertised when the site is running a Teredo relay or  
offering

   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.

2.10.  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.

Editorial: make it "Addresses covered by ff00::/8 are multicast  
addresses".

X presumably may be any _four-bit_ value, not *any* value :-)


Joe