Hi, Jean-Michel, On 06/16/2011 02:13 PM, Jean-Michel Combes wrote: > IMHO, this draft should update RFC 6105 (If so, RFC6105 reference > should move from Informative References section to the Normative > References one).
Yep. > Just a comment about your example for the fragmentation case with 2 > Destination extensions: from RFC2460 (section 4.1), this only occurs > when there is also a Routing Header extension, so I have to add a RH > in your example (better chance to get a fragmentation :)) The specs allow for multiple instances of the same extension headers. Hence, even if possibly non-sensical, the example in Section 4.1 is legitime. > o draft-gont-6man-nd-extension-headers > > IMHO, this is not a good idea to forbid the use of IPv6 extension with > NDP messages, especially when the reason is partially based on > implementation issues (i.e. the implementation is not able to process > an IPv6 packet): Well, I'd argue that it is an operational issue, rather than an implementation issue. -- And chances are that if it is not possible to implement a simple solution for this concrete problem, some may start filtering *all* packets that include extension headers (in particular, those in which the uper layer protocol is not present in the first fragment) > today, there is no real use of Extension header with > NDP but, tomorrow, if we need such an use for a solution, what will > happen? Among the options is that we could state that implementations should provide a switch to enable the processing of extension headers, but that it should default to off. > Regarding the fragmentation, is it not possible for the RA-Guard > device to reassemble the fragments and so to be able to check whether > this a RA message or not? This would open the door to DoS attacks -- the attacker would simply fire lots of fragments that would never get to be reassembled. -- then you're back into the same place (or probably a worse one). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
