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

From: [email-masked]
Date: Thu, 22 Mar 2007 10:50:02 -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-00.txt
	Pages		: 7
	Date		: 2007-3-22
	
   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-00.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-00.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-00.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: Fred Baker <[email-masked]>
Date: Thu, 22 Mar 2007 17:13:11 +0100

Folks:

In the context of the working group meeting Monday morning, please  
read this and comment on its utility, especially as compared to

http://tools.ietf.org/html/draft-ietf-v6ops-routing-guidelines
   "IPv6 Routing Policies Guidelines", Marc Blanchet, 27-Feb-07,
   <draft-ietf-v6ops-routing-guidelines-01.txt>

You may find it at

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>

On Mar 22, 2007, at 3:50 PM, [email-masked] wrote:

> Content-Type: text/plain
> Content-ID:	<[email-masked]>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Mar 2007 21:23:09 -0600

On Mar 22, 2007, at 10:13 AM, Fred Baker wrote:

> read
> this and comment on its utility, especially as compared to
>

>   <draft-ietf-v6ops-rfc3330-for-ipv6-00.txt>

As noted [what seems like only hours ago], I support the latter
of the documents above and suspect it's near ready for a WG
LC.  If work on the former is still believed worthwhile I believe
such a document should be a work item within the GROW
working group.

===================
Minor comments:

3.  Security Considerations

    This document list addresses and

s/list/lists/

-------------------
2.5.  Documentation Prefix

The 2001:0db8::/32 are the documentation addresses [RFC3849].

versus 2001:DB8::/32
--------------------

Thanks much!

-danny

---

From: David Malone <[email-masked]>
Date: Mon, 26 Mar 2007 16:53:00 +0100

>   <draft-ietf-v6ops-rfc3330-for-ipv6-00.txt>

A minor comment. While the historical 6bone prefix is mentioned,
the historical teredo prefix 3FFE:831F::/32 isn't. It is included
in the 6bone address space, so it is already "covered" by the draft,
but it is also a special use prefix, so it may be worth mentioning
explicitly?

	David.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 26 Mar 2007 19:22:36 +0300

>    <draft-ietf-v6ops-rfc3330-for-ipv6-00.txt>

The undefined address :: should probably be included; this is not 
strictly speaking the same thing as the default route (::/0).

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Mar 2007 13:31:01 -0400

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

>    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