On 18/06/2015 04:54, Jen Linkova wrote:
On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 17/06/2015 07:02, Jen Linkova wrote:
https://tools.ietf.org/html/draft-wkumari-long-headers-03
Comments are appreciated...
In REQ-2 on HbH headers, you say:
The forwarder MUST process each option as specified in Section 4.2 of [RFC2460].
That aspect of RFC 2460 was fundamentally changed by RFC 7045.
Oh, very good point. Thanks for pointing this out. Looks like it does cover our REQ2 (but requires different behavior).
So, Section 2.1 RFC7045 says about *all* EHs:
"If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. "
and then, in Section 2.1 for HbH: "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. ".
I read this as 'if a router does not recognize/parse the HbH header, it MUST not discard it unless there is an explicit policy configured. It may just ignore it or send for "special processing" via slow path.
So it assumes that it is always safe to ignore HbH header (as if all options in the header had highest-order two bits set to '00') while our draft proposed quite different approach ("drop and send ICMP back").
Right. And we can have that discussion, of course, but IMNSHO a firewall should either let stuff through or drop it for a congigured reason; dropping it because the product development manager made a lazy choice is not OK.
Ignoring HbH header seems to be reasonable and safe if we are sure that every single existing or to be developed HbH option can be safely ignored (or options which could be ignored must be in the very beginning of the header...).
Well, we can't know today what sort of crazy option might be invented in future; so the thinking behind draft-ietf-opsec-ipv6-eh-filtering seems right to me. Maybe that's a draft you need to be tracking. To be honest what I was thinking when we added discussion of HbH to RFC 7045 was not so much fixing the slow routers, but warning the community that "hop-by-hop" does not mean every hop. Fred would like to fix that with his 6man draft, and I don't mean to attack that idea.
In the light of RFC7045 it looks to me that one possible approach for REQ2 might be: - if a forwarder can not parse the HbH header and there is no explicitly configurable policy,
AND if the forwarder is trying to be a firewall or otherwise wants to interfere. If not, just forward the packet, already!
it SHOULD either: -- if the forwarder can not parse any of options or if all parsed options have highest-order two bits set to '00') - ignore the header; -- if the forwarder was able to parse some of options and at least one of the options has highest-order two bits set to smth except '00' - discard the packet and send ICMPv6 message if Section 4.2 of RFC 2460 requires so (sending ICMPv6 MAY be subject to a configurable policy) or send it to slow path for full header processing (subject to a configurable policy).
How does that sound?
As I said: if the forwarder insists on doing something, OK. But we have to think for a typical use case: does it matter if a forwarder simply ignores the HbH header? For example, for the IntServ/RSVP case, it just makes that router transparent to RSVP. That doesn't break RSVP; discarding the packet does. That was the thinking behind RFC 7045. Brian
I'm sure other things in the long-headers draft need revising as a result of RFC 7045, since its whole topic is the handling of extension headers ("This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.")
Yes, we'll revise it, thanks for the comment.
Y'all also need to take account of RFC 7112, which forbids fragmented header chains.
We do mention 7112 but I agree, we should explicitly mention that header chain is limited by a packet size...Will update the doc.