Subject: draft-carpenter-ext-transmit

From: "Michael Richardson" <[email-masked]>
Date: Mon, 05 Nov 2012 09:56:50 -0500

As I understand draft-carpenter-ext-transmit, the goal is to make sure
that at least firewalls support the list of extension headers we have
now.  Not all of them were defined in 2460, and so they aren't all
supported.

This document basically says we are done defining extension headers, we
have a definitive list.

Bob Hinden said that he felt that the list would not grow very much.  
I think he would have said the same thing about the v4 protocol field in
1990, yet we defined lots of new things afterwards.

Brian says that "this is the best we can do", and I conclude he means
that we are not able demand that standard format extensions headers be
skipped.  

If Brian is saying that this the definitive list of Upper-Layer-Protocol
values, and that we may have new extensions, but not new ULPs, then
maybe this is okay.

-- 
Michael Richardson
-on the road-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Nov 2012 19:12:35 +0000

> This document basically says we are done defining extension headers, we

No, it carefully doesn't say that. The issue is this: suppose all the firewall
maintainers in the world do the right thing (as defined by Brian Carpenter).
At that moment we will be fine, because they will behave appropriately for
all the currently defined extension headers.

If somebody registers a new extension header after that, the IANA list will
be updated, so all those firewall maintainers should obediently update again.
That's the fantasy part - it would set the barrier for a new extension header
extremely high

> 1990, yet we defined lots of new things afterwards.

The same thing *was* said in the early 1990's for IPv4 options - the
network was already opaque to IPv4 options back then, and it still is.
It is annoying that IPv6 is getting into the same situation.

The protocol field as such is a different story with its own inertia.
The problem here is chaining through the extension headers to *find*
the protocol field in the first place. That's what
draft-zhang-6man-offset-option was about, but nobody seemed to like it.

> that we are not able demand that standard format extensions headers be

I mean that clarifying what firewalls SHOULD do is the best chance we have to
improve transparency to extension headers. We cannot stop firewalls doing
their job.

> values, and that we may have new extensions, but not new ULPs, then

No, the two things are disjoint. I am only worrying about extension headers
this time around.

Regards
   Brian Carpenter
   Cell phone during IETF85: +1 847 219 0880

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Nov 2012 08:37:26 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> As I understand draft-carpenter-ext-transmit, the goal is to make
    >> sure that at least firewalls support the list of extension
    >> headers we have now.  Not all of them were defined in 2460, and
    >> so they aren't all supported.
    >> 
    >> This document basically says we are done defining extension
    >> headers, we have a definitive list.

    BC> No, it carefully doesn't say that. The issue is this: suppose
    BC> all the firewall maintainers in the world do the right thing (as
    BC> defined by Brian Carpenter).  At that moment we will be fine,
    BC> because they will behave appropriately for all the currently
    BC> defined extension headers.

Yes, I got that.

    BC> If somebody registers a new extension header after that, the
    BC> IANA list will be updated, so all those firewall maintainers
    BC> should obediently update again.  That's the fantasy part - it
    BC> would set the barrier for a new extension header extremely high

Right, which is why I claim that this document is essentially saying we
are done.  Like Lorenzo, I wanted to know why firewalls can't skip
extension headers they do not understand.  

The issue, as I understand it, is that some of things are not extension
headers with TLV,  but are upper-level-protocols, and the firewalls
can't know which ones are ULPs and which ones are TLV-format extension
headers. 

So, what I think this document does it acknowledge that we are a state
of "barrier for new extension extremely high", and make sure that in
fact that list is accurate and authoritative.

-- 
Michael Richardson
-on the road-