Subject: draft-ietf-v6ops-rfc3330-for-ipv6 WGLC

From: Fred Baker <[email-masked]>
Date: 5 May 2007 12:55:57 -0700

This is to initiate a two week working group last call of draft-ietf- 
v6ops-rfc3330-for-ipv6. Please read it now. If you find nits  
(spelling errors, minor suggested wording changes, etc), comment to  
the authors; if you find greater issues, such as disagreeing with a  
statement or finding additional issues that need to be addressed,  
please post your comments to the list.

We are looking specifically for comments on the importance of the  
document as well as its content. If you have read the document and  
believe it to be of operational utility, that is also an important  
comment to make.
<?xml version="1.0" encoding="UTF-8"?>

---

From: "Durand, Alain" <[email-masked]>
Date: Sat, 5 May 2007 17:23:12 -0400

Here is my review of  draft-ietf-v6ops-rfc3330-for-ipv6:

A) "...addresses should not be advertised and should be filtered out
when
   received"

I found this text a bit vague. It does not say advertised to whom
nor explain if such routes learned via a routing protocol
should be rejected (by default ?) or if special filters
should be put in place (by default ?) to reject any incoming
packets containing those addresses...
It does not say either if this applies to routers or hosts.

I'd rather like to see the sentence used in RFC3330:

"Addresses within this block should not appear on the public Internet"

B) The document should mention something about IPv4 compatible
addresses,
if only to say they were deprecated (are they really? I lost track).

C) What about addresses outside of 2::/3?

D) The document should have a normative reference to RFC3513

E) Actually, re-reading RFC3513, I found that most of the information
   is already there in much greater details.
   The value-added of this document is to talk about old 6bone, 6to4 &
Teredo.
   It is not obvious to *me* that this is enough to justify its
publication,
   but it may be for others.

F) Shouldn't this become an IANA registry? In that case, shouldn't this
   document have an IANA section?

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 16:06:33 +0200

On 2007-05-05 23:23, Durand, Alain wrote:

...
>    but it may be for others.

I think it's useful, since the information needs to be somewhere.
> 
> F) Shouldn't this become an IANA registry? 

See
http://www.iana.org/assignments/ipv6-unicast-address-assignments
but this is bit dry - even the few words of explanation in the
draft seem helpful to me.

> In that case, shouldn't this

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?

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 15 May 2007 10:51:25 -0700

>    The value-added of this document is to talk about old 6bone, 6to4 &

I agree with this.  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.

Also:

> 2.4.  Site-scoped Unicast
>
>    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".

Bob