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

From: [email-masked]
Date: Fri, 17 Dec 2010 15:45:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : An uniform format for IPv6 extension headers
	Author(s)       : S. Krishnan, et al.
	Filename        : draft-ietf-6man-exthdr-01.txt
	Pages           : 8
	Date            : 2010-12-17

In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the transport
layer header.  There are a small number of such extension headers
currently defined.  This document defines a format for defining a new
family of IPv6 extension headers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-exthdr-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Mon, 20 Dec 2010 14:07:21 +0530

I support this work and would like to see this progressed.

Kam

On Sat, Dec 18, 2010 at 5:15 AM,  <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Tony Li <[email-masked]>
Date: Mon, 20 Dec 2010 17:48:54 -0800

I do not support this work.  It seems ill conceived and unnecessary.

If there are needs for new extension headers, they should be presented.  If the data must be carried as an extension header, then specific new extension headers should be defined for those code points.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 21 Dec 2010 10:10:01 -0800

> If there are needs for new extension headers, they should be presented.  If the data must be carried as an extension header, then specific new extension headers should be defined for those code poi…

I've gotten multiple requests to expound on my comments.  To wit:

It does seem helpful and useful to propose that future new extension headers be TLV encoded.  While it seems obvious from 2460 that this was the intent, I cannot find that explicitly stated anywhere.  I would support this draft simply stating that and no more.  This should therefore be a one sentence document (minus the boilerplate ;-).  

I have an issue with creating the explicit header without a clear requirement.  As best I can tell, there is an allocation of a code point, which thereby implies that the figures shown in the draft are a literal extension that is being proposed and not just an example.  It seems very wasteful to burn this code point without an explicit and clear clause.  

It seems like a generic extension will simply create a security issue, with a new covert channel for IPv6.

The document seems to mandate the internal format of future extensions, above and beyond TLV encoding.  This seems overly restrictive and insufficiently motivated.

Tony

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Dec 2010 18:08:20 -0500

Hi Tony,
   Thanks for your comments. Please see responses inline.

> It does seem helpful and useful to propose that future new extension headers be TLV encoded.  While it seems obvious from 2460 that this was the intent, I cannot find that explicitly stated anywher…

And that is exactly what this draft started out as (a standard format 
for new extension headers to follow).

http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00

> I have an issue with creating the explicit header without a clear requirement.  As best I can tell, there is an allocation of a code point, which thereby implies that the figures shown in the draft…

Since RFC2460 came out, four new extension headers have been defined.

135 - Mobility header
139 - HIP
140 - Shim6
141 - WESP

The idea of burning one protocol number right now was suggested by the 
WG in order to limit further exhaustion of the protocol number space. 
Would it be more acceptable to you, if we do not ask for an IANA 
allocation for a protocol number at this point, and wait till the first 
"Specific Type" request comes up?

> The document seems to mandate the internal format of future extensions, above and beyond TLV encoding.  This seems overly restrictive and insufficiently motivated.

Which fields are you specifically concerned about?

Thanks
Suresh

---

From: Tony Li <[email-masked]>
Date: Tue, 21 Dec 2010 15:30:24 -0800

Hi Suresh,

> And that is exactly what this draft started out as (a standard format for new extension headers to follow).
> 

That's not _exactly_ true.  See section 3 of that document.  I think that that section would create issues.

> The idea of burning one protocol number right now was suggested by the WG in order to limit further exhaustion of the protocol number space. Would it be more acceptable to you, if we do not ask for an IANA allocation for a protocol number at this point, and wait till the first "Specific Type" request comes up?

The typical approach to code point exhaustion is to reserve one code point value within the space for future expansion.  Fortunately, that has already been done.  Value 255 has already been reserved.  This is both necessary and sufficient.

> Which fields are you specifically concerned about?

I'm referring to the Specific Type and Header Options fields.

Tony

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Dec 2010 00:32:28 -0500

Hi Tony,

> I'm referring to the Specific Type and Header Options fields.

We will come back with a proposal to resolve the issues that you, Ran 
and Fernando raised.

Thanks
Suresh

---

From: Tony Li <[email-masked]>
Date: Tue, 21 Dec 2010 22:04:23 -0800

On Dec 21, 2010, at 9:32 PM, Suresh Krishnan wrote:

> We will come back with a proposal to resolve the issues that you, Ran and Fernando raised.

Thank you, we look forward to it.

Tony