[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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