Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt

From: RJ Atkinson <[email-masked]>
Date: Tue, 4 Jan 2011 10:17:51 -0500

All,

I have very strong sympathy with the thoughts expressed by 
Thomas Narten in this note,
	<http://www.ietf.org/mail-archive/web/ipv6/current/msg13209.html>
especially:

(A) the root question (not yet clearly answered, although it has been 
    asked more than once) of what problem this I-D is trying to solve 

&& 

(B) the observation about how RFC-5175 has been handled by various 
    "IPv6 Profile" organisations:

I also agree with Brian Carpenter's observation:
	% So the one thing this proposal will *not* do is allow
	% new extension headers to cross the Internet transparently. 

Indeed, the BEST chance for a new IPv6-specific extension to be
deployable is to be specified to be carried within an IPv6 
Destination Options header.  Further, I believe that if a 
future proposal could be carried in an IPv6 Destination Option, 
then it ought to be REQUIRED to be carried in an IPv6 Destination
Option.  This maximises backwards compatibility, and is consistent
with the clear intent of RFC-2460.

	Existing deployed silicon (think Verilog & logic gates, 
	not NP or CPU) from multiple vendors know how to parse past 
	such an IPv6 Destination Options header in order to locate 
	the actual transport-layer protocol and transport-layer 
	port-numbers (e.g. to apply QoS or ACLs).  This proposed new 
	IPv6 Extension Header will *break* this *deployed* capability.  
	I know that it is deployed today in multiple large multi-
	continent ISPs to parse past an optional headers.  There are
	also site-border-router/firewall boxes that have this capability,
	used to allow certain applications (based upon examining the
	transport-layer protocol and transport-layer port numbers
	that are located *after* the optional header) and/or
	to permit authorised traffic even when an optional header
	is present between the IPv6 header and the transport-layer
	protocol.  

	I have a strong desire to avoid breaking this deployed and 
	important operational capability.

I also support these 2 specific comments from Joel Halpern,
particularly these 2 ideas:
I) removing "the hook for new extension headers that was left in RFC-2460" 
   (extension headers are only allowed in narrow circumstances at present)
&&
II) "to say that all end-to-end IP information" MUST "be in the 
     destination options".

His precise words that I agree with are:
	> (If we want that prohibition to be the case, we should say so, 
	> and remove the hook for new extension headers that was left in 2460.)
and separately:
	> My own preference would probably be to say that all end-to-end 
	> IP information should be in the destination options.  

I believe there would be broad support within the IPv6 WG to have
a small clarification to RFC-2460 that required the use of 
Destination Options in all cases where they can be made to work
(in essence, this is Joel's I and II above).

However, that could be done in a 1-page (plus boilerplate) draft.

Since Suresh has been driving this issue, perhaps Suresh could create 
such a 1-page (plus boilerplate) draft for the IPv6 WG to review ? (:-)

Yours,

Ran

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 05:12:55 -0500

Hi Ran,
 
> I believe there would be broad support within the IPv6 WG to 
> have a small clarification to RFC-2460 that required the use 
> of Destination Options in all cases where they can be made to 
> work (in essence, this is Joel's I and II above).
> 
> Since Suresh has been driving this issue, perhaps Suresh 
> could create such a 1-page (plus boilerplate) draft for the 
> IPv6 WG to review ? (:-)

I'm up for it :-). In fact I already suggested the meat in

http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html

"RFC2460 allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information, provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs.
The request for allocation of a Specific Type value MUST be accompanied by an specific explanation of why destination options could not be used to convey this information."

Let's see how that is received by the WG. I would appreciate your responses to that specific mail.

Cheers
Suresh

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 5 Jan 2011 08:15:18 -0500

> "RFC2460 allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this inform…

I apologise that I was not clear enough in my note yesterday.

I was looking for something different from the text above.
Specifically, I'm suggesting a 1 page (plus boilerplate)
draft that has both less text and slightly different text.

Here are the 3 key points that I'd like to see:

A) Prohibiting new IPv6 Extension Headers outright, 
   as Joel has repeatedly suggested.  This removes the
   narrow case where RFC-2460 allows Extension Headers,
   so the I-D would be an Update to RFC-2460.

B) Mandating use of existing IPv6 headers instead in all cases.
   Obviously, the Destination Options Header is preferred 
   as it has the least impact on the transit infrastructure.

   (Remi gave an example yesterday that probably belongs
   as a new "Routing Type" for the existing IPv6 Routing Header.)

C) No definition of any new IPv6 Extension Header, as per (A).

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jan 2011 09:15:30 +1300

On 2011-01-06 02:15, RJ Atkinson wrote:
...
>    so the I-D would be an Update to RFC-2460.

My reaction is that this is going too far, and isn't actually
necessary. We have words in 2460 that already make it quite hard
to define a new header. We have running code proof (in the form of
non-existent IPv4 options) that it's in practice impractical to
deploy such things, for exactly the reasons we've been discussing
(routers are not forward-compatible, and firewalls block unknowns
by default, both being partially embedded in silicon).

But who knows what the future may bring, in 20 or 40 years from now?

So I am more inclined to a SHOULD NOT approach; I think I'm agreeing
with a somewhat stronger version of Suresh's proposed paragraph.
At least, add

...accompanied by ... and a convincing explanation of a successful
progressive deployment model for the proposed new header.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 5 Jan 2011 16:56:57 -0500

> But who knows what the future may bring, in 20 or 40 years from now?

There is a kind of procedural elegance lurking here 
that is worth highlighting.  While you probably realise
this due to your IESG experience, perhaps others on
the list haven't considered the implications resulting
from IETF processes.

If some future instance of the IETF really believes they 
need to change things away from an outright prohibition 
on new IPv6 related extension headers, then revising the 
prohibition (e.g. to allow for some hypothetical legitimate need) 
is precisely the same process (i.e. standards action) as 
Suresh's proposed restraint upon creating IPv6 enhancements 
using a new header.  

Put another way, no current IETF action can really prohibit 
the future IETF from undertaking something that the future 
IETF really thinks ought to be undertaken.

The practical difference is that the IETF will think VERY
carefully about reversing a previous decision, whereas it
might not apply the same level of thought about allowing
a new enhancement where the standards-track documents
explicitly allow that.  Some of us think it would be
valuable to have maximum thought before allowing any
new IPv6 headers to be created.

Cheers,

Ran

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Jan 2011 14:26:35 +0100

Le 5 janv. 2011 à 21:15, Brian E Carpenter a écrit :
>> Prohibiting new IPv6 Extension Headers outright, 
>> ...
> My reaction is that this is going too far,

+1

> progressive deployment model for the proposed new header.

This seems to me a good compromise.
+1

RD

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Sun, 16 Jan 2011 04:17:31 +0530

>> My reaction is that this is going too far,

I agree with this. I dont think we should be explicitly prohibiting
any new IPv6 extension headers. We could discourage the use of the
same, but prohibiting is taking it to a new, and rather an
unreasonable level.

> This seems to me a good compromise.

Yes, i agree with this as well. We should at the very least document
what a new IPv6 extension header must look like, with some text that
says that this should only be used once the working group has been
convinced that it cannot use the existing IPv6 extension headers for
the job.

I am ambivalent on the options that have been added.

I also agree that using a new protocol ID perhaps is not required.

Kam