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

From: Nathan Ward <[email-masked]>
Date: Tue, 20 Nov 2007 21:41:34 +1300

I'd normally delete the bulk of the context, but as I'm late getting  
in here..
More below..

On 4/10/2007, at 10:03 AM, Brian E Carpenter wrote:

> In line...
>
> On 2007-10-04 04:34, Marc Blanchet wrote:
>> Le 07-10-03 à 17:09, Niall O'Reilly a écrit :
>>>
>>> On 3 Oct 2007, at 14:13, Marc Blanchet wrote:
>>>
>>>> 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.
>>>
>>>    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 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].

Should it mention that de-aggregating 2002::/16 is not good? It's not  
clear here, I don't know if it needs to be.

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

I think this is not just a security concern - using reserved IPv4  
addresses with Teredo will obviously not work over the public  
Internet, which (I would say) is more of a blocking issue than  
security for people using 6to4. So, I'd suggest that it belongs in  
this document, or perhaps in a document describing

Should we also include stuff for Teredo+RFC3330/RFC1918? IE. any of  
the same IPv4 addresses in the A or B (XORed) in:
2001:0000:AAAA:AAAA:0000:0000:BBBB:BBBB

(Now that I've read the draft in detail I realise that we already have  
a documentation prefix, which is what this email was originally  
intended to be about. I was greping for 'example' and thought it had  
been missed out.)

--
Nathan Ward

---

From: Nathan Ward <[email-masked]>
Date: Tue, 20 Nov 2007 21:41:34 +1300

--
Nathan Ward