Hi, Ran, On 07/19/2012 09:04 PM, RJ Atkinson wrote: >> Should we make this latter bit (about this being configurable) >> a MAY, or would you prefer to have non-RFC2119 language? > > I believe this configurability is really desirable. > It isn't a big burden for an implementer, as it is > simply an on/off flag, but we don't want to require it. > > So I would suggest either use "SHOULD support configuration of > whether an ICMPv6 error/diagnostic message is sent" (edit to preference) > OR (more simply) avoid using RFC21109 ALL-CAPS wording and > still urge that implementers support this as a configurable > setting as part of supporting "local operational policy".
Ok. I will craft some text, and post it to the list for review... >>> 4) Security Considerations ought to note the importance of >>> deploying Source Address Forgery Prevention filters, in >>> order to reduce the threat of an adversary forging an >>> illegal packet with contains a victim/target's IP address >>> in the Source IPv6 Address field of the illegal packet. >>> [RFC-2827, RFC-3704] >> >> I have no problem with this. >> However, should we really elaborate on this topic, >> since it applies to all ICMPv6 error messages and >> hence is probably a topic belonging to e.g. RFC 4443? > > I think a brief reminder here is appropriate, in part > because this draft increases the attack surface a bit, > by making illegal a previously-valid, if very odd, > IPv6 packet construct. Ok. As with the above, I will craft some text and send it to the list for review. Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
