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

From: Marc Blanchet <[email-masked]>
Date: Wed, 3 Oct 2007 15:13:31 +0200

I understand your comment. However, the issues you are raising (as  
well as others) related to 6to4 are already in the 6to4 security RFC  
(RFC3964), which is already referenced in the 6to4 paragraph.  
Therefore, I would suggest not to add any additional text in order to  
not repeat what is already throughly discussed in RFC3964.

Marc.

Le 07-08-24 à 19:41, Niall O'Reilly a écrit :

> On Thu, 2 Aug 2007 20:40:26 +0200, Gert Doering <[email-masked]>  
> wrote:
>> I'm coming a bit late to this (sorry)
>
> 	Apologies from me too.  At least I'm in good company. 8-)
>
> 	It would be helpful if prefixes such as 2002:a00::/24 were  
> specifically
> 	mentioned as needing special attention.  This might be done by  
> explicit
> 	mention of each such prefix.  Alternatively, language could be used
> 	which would make clear that the 6to4 image of any IPv4 block for  
> which
> 	RFC3330 specifies that "Addresses within this block should not appear
> 	on the public Internet" should be similarly avoided.
>
> 	I believe that this would be useful both to those beginning to deploy
> 	IPv6 in their networks (my case) and those running a 6to4 relay  
> service.
>
>
> 	Best regards,
>
> 	Niall O'Reilly
> 	University College Dublin IT Services
>
> 	PGP key ID: AE995ED9 (see www.pgp.net)
> 	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
>
>
>

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: Joe Abley <[email-masked]>
Date: Wed, 3 Oct 2007 10:26:09 -0400

On 3-Oct-2007, at 0913, Marc Blanchet wrote:

> well as others) related to 6to4 are already in the 6to4 security  
> RFC (RFC3964), which is already referenced in the 6to4 paragraph.  
> Therefore, I would suggest not to add any additional text in order  
> to not repeat what is already throughly discussed in RFC3964.

I think readers would be well-served by a convenient, local reference  
though. If it is left to the reader to translate RFC 3330 into hex,  
chances are good that it won't happen.

How about adding some additional text to section 2.7, such as:

6to4 prefixes are constructed by embedding an IPv4 address into an  
IPv6 prefix according to [RFC3056]. Where the IPv4 address used to  
construct such a prefix is not globally-unique (or is otherwise  
reserved), the resulting 6to4 prefix is unlikely to be useful.

The following is a summary of 6to4 prefixes constructed using special- 
use IPv4 addresses, as documented in [RFC3330]. IPv4 prefixes which  
appear in [RFC3330] but which are known to have legimitate use on the  
public Internet at the time of writing are not included. Operators  
are advised to derive a policy for treatment of these 6to4 prefixes  
which is analogous to their policy for the corresponding IPv4 addresses.

   IPv4 Prefix     Description                       6to4 Prefix

   0.0.0.0/8       "this network" [RFC1700]          2002::/24
   10.0.0.0/8      private networks [RFC1918]        2002:a00::/24
   14.0.0.0/8      "public data networks" [RFC1700]  2002:e00::/24
   127.0.0.0/8     loopback addresses [RFC1700]      2002:7f00::/24
   169.254.0.0/16  "link local"                      2002:a9fe::/32
   172.16.0.0/12   private networks [RFC1918]        2002:ac10::/28
   192.0.2.0/24    "test net"                        2002:c000:200::/40

   (etc, etc)

Joe

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 3 Oct 2007 16:38:36 +0200

Le 07-10-03 à 16:26, Joe Abley a écrit :

> I think readers would be well-served by a convenient, local  
> reference though. If it is left to the reader to translate RFC 3330  
> into hex, chances are good that it won't happen.

- but again, RFC3964 goes in depth of the rationale, implications,  
etc...
- and my understanding from previous wg discussions about this  
document is that we wanted to move out as much as possible of   
routing policy instructions.

Marc.

> The following is a summary of 6to4 prefixes constructed using  
> special-use IPv4 addresses, as documented in [RFC3330]. IPv4  
> prefixes which appear in [RFC3330] but which are known to have  
> legimitate use on the public Internet at the time of writing are  
> not included. Operators are advised to derive a policy for  
> treatment of these 6to4 prefixes which is analogous to their policy  
> for the corresponding IPv4 addresses.
>

-----

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 03 Oct 2007 16:09:39 +0100

> to not repeat what is already throughly discussed in RFC3964.

	I understand your response, and have some sympathy with your point  
of view.

	I see two possible goals here: "communication" and "documentation".   
I'm not
	sure whether both are intended goals of the document being drafted.   
I think
	they should be.

	Repetition is a nuisance in documentation, as it involves parallel  
maintenance.
	OTOH, appropriate repetition is useful in communication, as it helps  
underline
	the message.

	My sense of the purpose of this document is that its readers ought  
to be
	adequately or even compellingly guided towards doing "the right  
thing".  What
	prompted me to comment as I did was that, in reading it, I didn't  
quite find
	the kind of guidance I was looking for.

	I'll read it again a couple of times, and consider whether I was  
simply in
	unreceptive form whenever I read it before.

	Best regards,

	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 03 Oct 2007 16:14:48 +0100

> into hex, chances are good that it won't happen.

	Well put, Joe!

> How about adding some additional text to section 2.7, such as:

	[ no need for me to repeat ]

	Looks like the kind of guidance I was missing.

	Best regards,

	Niall O'Reilly

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 3 Oct 2007 17:34:57 +0200

Le 07-10-03 à 17:09, Niall O'Reilly a écrit :

> 	I see two possible goals here: "communication" and  
> "documentation".  I'm not
> 	sure whether both are intended goals of the document being  
> drafted.  I think
> 	they should be.
>
> 	OTOH, appropriate repetition is useful in communication, as it  
> helps underline
> 	the message.
>

I agree completly on the principle. If you refer to the first  
versions of the document, that was the intent and I covered more  
stuff around this to help people do the right thing concerning  
routing policies. Actually, the first title of the document was "IPv6  
routing policies guidelines". But there were people concerned about  
that direction. Therefore, it was decided to do something similar to  
RFC3330, which roughly documents the special IPv6 addresses with very  
few if any info on routing policies. that was the compromise to get  
the document with concensus. Therefore, I'm trying to stick to the  
guidance that was previously agreed on the scope/direction of the  
document , which is about near zero reference to routing policies.

summary: I agree with your comment, but to my knowledge, this is not  
the direction the wg wanted the document to have.

Marc.

-----

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Oct 2007 10:03:09 +1300

In line...

On 2007-10-04 04:34, Marc Blanchet wrote:
> I agree completly on the principle. If you refer to the first versions 
> of the document, that was the intent and I covered more stuff around 
> this to help people do the right thing concerning routing policies. 
> Actually, the first title of the document was "IPv6 routing policies 
> guidelines". But there were people concerned about that direction. 
> Therefore, it was decided to do something similar to RFC3330, which 
> roughly documents the special IPv6 addresses with very few if any info 
> on routing policies. that was the compromise to get the document with 
> concensus. Therefore, I'm trying to stick to the guidance that was 
> previously agreed on the scope/direction of the document , which is 
> about near zero reference to routing policies.
> 
> summary: I agree with your comment, but to my knowledge, this is not the 
> direction the wg wanted the document to have.

I would suggest making the reference to RFC 3964 more specific, e.g.

2.7.  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. IPv4 addresses disallowed in 6to4 prefixes are listed
    in section 5.3.1 of [RFC3964].

In reference to Joe's list, I think it's out of place to mention
14/8, but in any case, if the list is incomplete, we need to fix
RFC 3964. Having a different list here would be confusing.

     Brian

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 04 Oct 2007 16:51:57 +0100

>    in section 5.3.1 of [RFC3964].

	Good idea.  I think that works for me.  Specific indirect
	reference avoids the parallel-maintenance problem entrained
	by repetition.

	I'm also concerned about ugly pockets of ::/96 and
	::ffff:0.0.0.0/96 such as RFC1918 reservations.  Can they
	be covered by similar language.

> RFC 3964. Having a different list here would be confusing.

	If/when 3964 is fixed, won't the list here need fixing to
	synchronize.  Wouldn't it be good to find a short-cut?

	/Niall

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 5 Oct 2007 14:11:50 +0200

- 6to4: will update the draft based on Brian's suggestion. this will  
be -03 version  (-02 was just an small nit in references).
- ipv4-mapped are already covered as "should not appear on the public  
Internet" as a whole... so I think we are covering it.

Marc.

-----