[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt
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].
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
Marc.
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
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