Hi, Simon,
On 01/15/2013 07:12 AM, Simon Perreault wrote:
> Le 2013-01-14 20:13, Fernando Gont a écrit :
>> No. The following text in Section 4.2 of RFC 2460 overrides what's in
>> RFC 4443:
>
> An earlier RFC can't "override" a later RFC. The later RFC wins.
I agree that my phrasing was sloppy (at best -- the combination of
English as non-native language + no sleep never helps). However, I'd say
that a "later" RFC that does not formally update an earlier RFC does not
override anything.
In any case, both RFC 2460 and RFC 4443 agree on this point. As I've
just noted to Ole, BTW, bullet "e)" in Section 2.4 (page 6) of RFC 4443
says:
(e.3) A packet destined to an IPv6 multicast address. (There are
two exceptions to this rule: (1) the Packet Too Big Message
(Section 3.2) to allow Path MTU discovery to work for IPv6
multicast, and (2) the Parameter Problem Message, Code 2
(Section 3.4) reporting an unrecognized IPv6 option (see
Section 4.2 of [IPv6]) that has the Option Type highest-
order two bits set to 10).
So I should probably note this in the I-D, and add RFC4443 to the RFCs
that need to be updated.
Thoughts?
>> FWIW, all implementations I've tested so far behave as specified in RFC
>> 2460, and hence can be leveraged as smurf amplifiers.
>
> That's a different (and better IMHO) reason why publishing something new
> could be useful.
In this case, since the RFCs are in agreement, I'm not sure if it would
add anything to comment that "all popular implementations behave as
specified in this RFCs". But I could include such a note if deemed
appropriate.
Thoughts?
Thanks so much!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
