Subject: Detailed review of draft-ietf-6man-ext-transmit-02

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Aug 2013 18:28:48 -0300

Folks,

I've volunteered to provide a detailed review of this document, in
response to the 6man wg chairs' request.

Overall, I believe that this is a very useful document, and I support
its publication as an RFC.

However, I think it would be great if the technical comments below could
be addressed before we ship it.

*** Technical ****

* Section 1:
> Thus, new extension headers
>    could be introduced progressively, used only by hosts that have been
>    updated to create and interpret them. 

You should probably reference RFC6564 here. I believe it's an important
piece that enables progressive introduction of new extension headers.

* Section 1:
> Unfortunately, experience has showed that as a result,
>    the network is not transparent to IPv6 extension headers.

I'd probably rephrase this sentence. A firewall's goal is, for instance,
to police packets. So that lack of "transparency" is actually a goal
they have (whether we like it or not).

* Section 1:
> Unfortunately, because not all
>    IPv6 extension headers follow a uniform TLV format, this process is
>    clumsy and requires knowledge of each extension header's format.

You should probably note that the upper-layer header might not even be
there, and reference draft-ietf-6man-oversized-header-chain.

* Section 1:
>    If they encounter an unrecognised extension header type, some
>    firewalls treat the packet as suspect and drop it.  Unfortunately, it
>    is an established fact that several widely used firewalls do not
>    recognise some or all of the extension headers standardised since RFC
>    2460. 

Is it that they don't recognize them? Or is it rather that they default
to "drop packets with extension headers"? Or maybe that they are sloppy
enough that they consider whatever follows the IPv6 header to be the
"upper-layer header" (and hence a "pass tcp" wouldn't work as expected
if the packet contains an extension header).

* Section 1:
> This applies in particular to firewalls
>    that attempt to inspect packets statelessly at very high speed, since
>    they cannot take the time to reassemble fragmented packets,
>    especially when under a denial of service attack.

This would be a form of stateful inspection rather than stateless: a
stateless firewall wouldn't try to reassemble a packet, since that
requires state.

* Section 1:
> This will alleviate concerns
>    that stateless firewalls cannot handle a complete header chain as
>    required by the present document.

The problem for stateless firewalls is two-fold:
1) Being able to find the upper-layer information -- this is addressed
by draft-ietf-6man-oversized-header-chain

2) Being able to process the header chain with decent performance --
this one still needs to be addressed.

* Section 2.1:
> 
>    Any forwarding node along an IPv6 packet's path, which forwards the
>    packet for any reason, SHOULD do so regardless of any extension
>    headers that are present, as required by RFC 2460.

I find this particular requirement a bit troublesome. Truth is that many
devices violate this requirement, and will always will.

OTOH, the rest of the document is perfectly fine in this respect -- it
acknowledges that some devices will look at the extension headers, and
provides advice on what to do (e.g., "you should have an explicit policy
regarding what to do with extension headers").

I guess I could live with a SHOULD (at least, it's not a "MUST") --
however, in the light of reality, I'd probably relax this requirement.

* Section 2.1:
> 
>    The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD
>    NOT be used.  However, as specified in [RFC5095], this does not mean
>    that the IPv6 Routing Header can be unconditionally dropped by
>    forwarding nodes. 

I don't think you need the "SHOULD NOT" above - RFC5095 should be taking
are of that.

As an aside, and in the light of e.g. bringing HBH to the real world, I
think that requiring nodes to inspect the contents of RHT0 is
unrealistic. I would align this with the processing of HBH extension
headers. And in doing so, this document should update RFC5095.

* Section 4:
> 
>    This list excludes both type 59, No Next Header, [RFC2460], which is
>    not an extension header as such, and type 139, HIP, [RFC5201], which
>    is experimental.

If RFC5201 specifies an extension header, why shouldn't it be listed in
the registry? (Disclaimer: I haven't even looked at RFC5201... so I
might be missing something).

**** Nits ****

* Section 1:
> It has also been observed that certain firewalls do not even
>    handle all the extension headers standardised in RFC 2460, including
>    the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental
>    problems of connectivity.

I'd probably s/connectivity/interoperability/

* Section 1:
> It cannot be widely deployed, because
>    existing middleboxes will render large parts of the Internet opaque
>    to it. 

I'm not sure this conveys the information that those packets will be
dropped. Maybe rephrase?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Aug 2013 16:29:08 +1200

Fernando,

Thanks for the careful review. Most of your comments lead to fairly obvious
fixes, which we'll apply in the next version. Just a few points below which
may need discussion:

On 14/08/2013 09:28, Fernando Gont wrote:
...
> they have (whether we like it or not).

True, but it's unfortunate from the point of view of the design of IPv6.
Speaking for myself only, I think the sentence is accurate - see the
next point.

...
> devices violate this requirement, and will always will.

Yes, but the IPv6 design really does require this. I think the
SHOULD is right, because RFC 2119 says that it means "there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course." That is
a perfectly reasonable choice for the person managing a firewall
to make, but it doesn't change the IPv6 design assumption.

> however, in the light of reality, I'd probably relax this requirement.

...

> might be missing something).

This is a bit tricky. If HIP was a standards-track protocol it would
be easy, but since it's experimental, it really doesn't seem realistic
to hint that firewalls should allow it by default. Maybe we should
change the IANA registry to include the experimental ones, but with
a special tag? (Extension headers 253 and 254 are also tricky, because
they are experimental values defined by a standards track RFC. Go figure!)

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Aug 2013 04:59:30 -0300

Hi, Brian,

On 08/14/2013 01:29 AM, Brian E Carpenter wrote:
> Yes, but the IPv6 design really does require this. 

That's my point: is that a sensible requirement? For instance, for the
time being (Flow Label not used), there's no other way to identify flows
than to break this reuirement.

> I think the

I have no issues with this. -- Although I'd note that this text gives
the idea that processing the extesion header chain is more an exception
than a rule.

> to hint that firewalls should allow it by default.

So the question here is:
1) Are we creating an IANA registry for Ext Headers or,
2) Are we creating a registry for ext headers that, by default, should
be passed?

If the former, HIP should be in. If the latter, it shouldn't.

Besides, if we imply that HIP should be filtered but they use some
specific "Next Header" value (as opposed to 253 or 254), then whatever
value is currently used for the HIP ext header will be unusable on the
public Internet even if the the document eventually becomes a Proposed
Standard.

> Maybe we should

I think we might be able to do both "1)" and "2)" above by adding a tag
along the lines of "not expected in the public Internet"? (with the
implication that "it's okay to filter").

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Aug 2013 07:29:30 +1200

> than to break this reuirement.

Which is indeed why I worked hard to get RFC 6437 written. But changing
this aspect of IPv6 design would be a *really* big discussion.
> implication that "it's okay to filter").

Something like that, yes. We'll try some words in the next version.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Aug 2013 17:08:40 -0300

Hi, Brian,

> this aspect of IPv6 design would be a *really* big discussion.

I'm fully in favor of RFC6437. My point is that host implementations
still not use or o weird stuff with the Flow Label -- hence it's not
dependable for anything. This means that in the short of near term
there's no better option than following the IPv6 header chain (not that
I like it but... that doesn't change the facts).

> Something like that, yes. We'll try some words in the next version.

Great.

Thanks!

Cheers,

---

From: Kevin Lahey <[email-masked]>
Date: Wed, 21 Aug 2013 18:10:55 -0700

> I like it but... that doesn't change the facts).

As an implementor, I'd far rather hear, "Get on the ball implementing
flowlabels, and until you do, any packets you originate might suffer
re-ordering via ECMP because we can't reliably get to the L4 info,"
rather than, "Tell your customers that they can't send fragments 
over IPv6 (or use any other IPv6 options)."

Kevin
[email-masked]