Subject: New draft on IPv6 extension headers

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Oct 2006 16:07:15 -0400

Hi Folks,
   I have submitted a draft requesting a standard format for IPv6 
extension headers. I would appreciate any comments on it.

Thanks
Suresh

-------- Original Message --------
Subject: I-D ACTION:draft-krishnan-ipv6-exthdr-00.txt
Date: Wed, 18 Oct 2006 15:50:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Format for IPv6 extension headers
	Author(s)	: S. Krishnan
	Filename	: draft-krishnan-ipv6-exthdr-00.txt
	Pages		: 8
	Date		: 2006-10-18
	
    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 new
    IPv6 extension headers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnan-ipv6-exthdr-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-krishnan-ipv6-exthdr-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-krishnan-ipv6-exthdr-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Oct 2006 09:14:24 +0300

Hello,

> extension headers. I would appreciate any comments on it.

I think I don't understand why one would need new extension headers,
instead of adding options to the existing ones (plus depleting the IP
protocols number might not be such a godd idea). But I guess I'm missing
something.

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2006 09:50:37 +0200

> protocols number might not be such a godd idea). But I guess I'm missing

Well, we have the ability today to standardize new extension headers,
if the case is strong enough. This draft only seems to be proposing
some additional constraints on such extensions.

    Brian

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Oct 2006 09:48:16 +0200

> protocols number might not be such a godd idea). But I guess I'm missing

I hope we can avoid that as well. I see one problem with creating new 
extension headers, which this draft won't solve.

End hosts and some other systems (e.g. firewalls) need to locate the IP 
payload for various reasons. The only way to locate the payload, is to 
pass through the known extension headers one by one, until you find a 
next header value that is not a known extension header. If a new 
extension header is created, then such equipment will need to be 
updated, else they will treat the new extension header as being
the payload and not locate the real payload.

Stig

---

From: Su Thunder <[email-masked]>
Date: Thu, 19 Oct 2006 18:53:15 +0800

I don't think your comment is a problem.Whether a block of memory is payload or an extension header is determined by the Next Header value of the immediately preceding header, not whether the extension header is known or unknown.A node should pass an unknown extension header to the next header immediately following it, why it regards something unknown as something else?
----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: "Rémi Denis-Courmont" <[email-masked]>
Cc: <[email-masked]>; "Suresh Krishnan" <[email-masked]>
Sent: Thursday, October 19, 2006 3:48 PM
Subject: Re: New draft on IPv6 extension headers

Stig

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Oct 2006 04:13:09 -0700

On Oct 19, 2006, at 3:53 AM, Su Thunder wrote:
> I don't think your comment is a problem. Whether a block of memory  
> is payload or an extension header is determined by the Next Header  
> value of the immediately preceding header, not whether the  
> extension header is known or unknown. A node should pass an unknown  
> extension header to the next header immediately following it, why  
> it regards something unknown as something else?

yes, but there is some ambiguity there. One can use the value in the  
next header field to indicate an interior header, or one can use it  
to pass out to another protocol such as TCP.

So you are a machine that doesn't know the meaning of the number  
(let's say) 254. Is it an interior header, in which case it is of a  
certain size and you can continue processing to determine that maybe  
there is an end to end header after it, or is it a new transport  
protocol? How do you know?

And actually, as I read the spec, that's not what it is supposed to do.

    If, as a result of processing a header, a node is required to  
proceed
    to the next header but the Next Header value in the current  
header is
    unrecognized by the node, it should discard the packet and send an
    ICMP Parameter Problem message to the source of the packet, with an
    ICMP Code value of 1 ("unrecognized Next Header type encountered")
    and the ICMP Pointer field containing the offset of the unrecognized
    value within the original packet.  The same action should be  
taken if
    a node encounters a Next Header value of zero in any header other
    than an IPv6 header.

When it comes to a number it doesn't know how to interpret, it is  
supposed to drop the datagram and report to the sender.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Oct 2006 14:40:32 +0300

On Thu, Oct 19, 2006 at 06:53:15PM +0800, Su Thunder wrote :
> I don't think your comment is a problem.

I do think it is.

> Whether a block of memory is payload or an extension header is
> determined by the Next Header value of the immediately preceding
> header,

Yes.

> not whether the extension header is known or unknown.

It certainly is, for if it is unknown, it is considered to not be an
extension header.

> A node should pass an unknown extension header to the next header
> immediately following it, why it regards something unknown as
> something else?

I don't understand the statement. But in any case, an IPv6
implementation will stop processing the packet and return an ICMPv6
error if it ever sees an unknown extension header, because it will think
it is an unknown transport protocol.

That's why new IPv6 options should use the existing extension headers
(Dst, Hop-by-hop, Routing), which are always known, and for which there
are predefined fallback behavior for unknown options (e.g. depending on
the high order bits or the option number).

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Oct 2006 13:40:25 +0200

Fred Baker wrote:
>> I don't think your comment is a problem. Whether a block of memory  is 
>> payload or an extension header is determined by the Next Header  value 
>> of the immediately preceding header, not whether the  extension header 
>> is known or unknown. A node should pass an unknown  extension header 
>> to the next header immediately following it, why  it regards something 
>> unknown as something else?
> 
> 
> next header field to indicate an interior header, or one can use it  to 
> pass out to another protocol such as TCP.
> 
> So you are a machine that doesn't know the meaning of the number  (let's 
> say) 254. Is it an interior header, in which case it is of a  certain 
> size and you can continue processing to determine that maybe  there is 
> an end to end header after it, or is it a new transport  protocol? How 
> do you know?
> 
>    If, as a result of processing a header, a node is required to  proceed
>    to the next header but the Next Header value in the current  header is
>    value within the original packet.  The same action should be  taken if

Right, so for end hosts, any new extension header would have to be 
supported. Firewalls, IDSes, routers with ACLs etc. would probably also
need to be upgraded. Say a firewall might be configured to only allow 
certain UDP and TCP traffic through. If it finds an unknown extension 
header, it might believe it's an unknown protocol that shouldn't get 
through. Even if the payload really is UDP/TCP that should get through.

Trying to assume that an unknown protocol number is an extension header
and then to look what's beyond it would be a very bad idea.

It might have been useful to remove the ambiguity by having a predefined 
protocol number range for potential new extension headers. Then current 
equipment/software could be made to support future unknown headers.

Anyway, I'm hoping that any new stuff can be options within the
currently defined extension headers...

Stig

---

From: Markku Savela <[email-masked]>
Date: Thu, 19 Oct 2006 10:20:02 +0300

>From draft...
   However, some intermediate nodes such as firewalls, may need to
   look at the transport layer header fields in order to make a
   decision to allow or deny the packet.  If new extension headers are
   defined and the intermediate node is not aware of them, the
   intermediate node cannot proceed further in the header chain since
   it does not know where the unknown header ends and the next header
   begins.

If intermediate node is not aware of the protocol number, it cannot
skip over the "extension", because it doesn't know it is an extension
header in the first place.

The standard format might make it a little bit easier to implement
skipping, after you have updated the software on intermediate node to
recognize the new protocol number as an extension header number.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 Oct 2006 13:06:40 -0700

Suresh,

[No hats on]

> extension headers. I would appreciate any comments on it.

I really like reading clear and concise drafts!!!  Thanks!

While I agree that the problem that your draft is addressing is real,  
I think in practice your proposal won't have very much effect on  
fixing the problem.  This will address new IPv6 extention headers  
defined in the future, but it won't address other new protocols that  
are defined that might show up after an IPv6 header, nor will it  
address the ones that have been defined in the past.  The result is  
that a node that wants to parse all of the headers will still have to  
still know about each one.  It will even have to know that it is a  
new IPv6 extension header that has this format.  There is no bit or  
flag that identifies an IPv6 extension header.

Also, for devices like firewalls the security implications of  
skipping unknown (except for their format) headers isn't very good.

Finally, I think it is too late to be redefining the fragmentation  
header.

Bob

p.s. I hope this draft doesn't mean that someone is thinking of  
defining a lot of new IPv6 extension headers....  :-)

---

From: Su Thunder <[email-masked]>
Date: Fri, 20 Oct 2006 08:49:03 +0800

If we can predict that many new extension headers will be defined in the future,a new draft for the router to recognize the newly defined extension header will be neccessary.For example,we can define a set of parameters including the Next Header value in the immediately preceding header,a list of the format of probable options,the extension headers that might be placed before the newly defined extension header,and the probable actions of the router when meeting the extension header.The purppose of the parameters likes the feature of virsus.
So future implementations can recognize any extension header.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Oct 2006 10:34:09 -0700

Su,

On Oct 19, 2006, at 5:49 PM, ext Su Thunder wrote:

> If we can predict that many new extension headers will be defined  
> in the future,a new draft for the router to recognize the newly  
> defined extension header will be neccessary.For example,we can  
> define a set of parameters including the Next Header value in the  
> immediately preceding header,a list of the format of probable  
> options,the extension headers that might be placed before the newly  
> defined extension header,and the probable actions of the router  
> when meeting the extension header.The purppose of the parameters  
> likes the feature of virsus.

I don't see how we can predict this.

This is exactly why we previously defined the hop-by-hop option  
format.  It does all of these things.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Oct 2006 13:07:24 -0400

FWIW, I largely agree with Bob.

The biggest issue I see with this is that this document requires code
changes on routers in anticipation of a some vague, future possible
new extension type.

I strongly suspect that any such RFC will be largely ignored by
vendors and thus won't be implemented. And if it is not implemented
_now_, in the future, when that new extension is finally defined, it
will be too late to matter.

This sort of thing would have made more sense early on as part of the
base IPv6 protocol RFC. Today, there is no compelling reason for
anyone to implement this.

PS, I'd also like to see some evidence that there exist potential
future header extensions that routers/firewalls will need to process
that can't be dealt with via (say) a hop-by-hop option or routing
header.

Just saying it's theoretically possible doesn't make it compelling.

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 23 Oct 2006 13:25:15 -0400

Hi Folks,
   Thanks a lot for the comments. I don't see myself ever requesting a 
new extension header and I would use Options instead, but since someone 
has the option to request one, we need to tighten up the spec. I would 
be just as happy if a new document or RFC2460bis (if any) would 
explicitly state that no new extension headers would be added or even 
strongly cautions against using extension headers. The way I see it, 
RFC2460 mentions that we can use either extension headers or options, 
but without mentioning the issues with adding new extension headers.

Thanks
Suresh

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Oct 2006 13:31:06 -0400

> has the option to request one, we need to tighten up the spec.

Actually, I disagree with your conclusion. Just because something
isn't explicitely disallowed, doesn't mean we need to clarify anything
(unless there was a real, actual, problem). That is an endless (and
possibly pointless) task.

First, let's be pragmatic. If there is no real problem to fix here,
can we please spend our cycles on problems where we might actually
make a difference in the real world?

> I would be just as happy if a new document or RFC2460bis (if any)
> would explicitly state that no new extension headers would be added

Why should we rule that out? Besides, such a proclamation would be
useless, since we could easily overrule it if we ever came up with a
justification for defining a new extension header.

> or even strongly cautions against using extension headers.

Why? If someone later comes up with a problem, and extension headers
(despite any drawbacks w.r.t. deployed code) seem like the best
answer, we can have a conversation about the pros and cons then.

> The way I see it, RFC2460 mentions that we can use either extension
> headers or options, but without mentioning the issues with adding
> new extension headers.

Again, no standard is 100% complete and covers every imaginable
scenario.

You yourself admit that you don't have a real need for an extension to
point to.

If there is no real, compelling problem to solve, can we please just
drop the discussion and move on to something with some actual
importance?

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Oct 2006 09:34:18 +0300 (EEST)

> answer, we can have a conversation about the pros and cons then.

When some other WG designs a solution like this, they are not going to 
ask IPv6 WG and not necessarily even any IPv6 expert on guidance for 
this, because they don't think they're designing an extension header 
-- rather a new IP protocol which just happens to support (or be 
extended to support) Next Header types other than IPPROTO_NONE.

We can always push back at IETF last call or IESG review, but without 
having a backing of an IETF consensus document to say "you really 
shouldn't be doing this unless you have very good reasons for it" 
would be helpful in that dialogue.

It'd be even more helpful because folks could be pointed to it (or 
could find it themselves) before the issue even arose at the end of 
the process (when it's usually much too late to fix it in any case).

(FWIW I'd like to see a similar consensus document on Router Alert 
option..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Oct 2006 15:27:37 +0200

> extended to support) Next Header types other than IPPROTO_NONE.

One "new" extension header is shim6. Would it have made more sense as a
destination option?

Stig