Subject: Extension Header Capability Discovery needed?

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 22:23:31 +0300 (EEST)

Hello folks,

RFC2460 specifies that if an unknown extension header is encountered, the
packet must be dropped.  (note: in IPv4, options MUST be ignored if not
recognized; the chaining makes this different, though).

In practise this seems to suggest that the sending node must always be
sure beforehand which extension headers the recipient supports (think e.g.
some MIPv6 feature or new ISPEC feature or whatever).

In practise this seems to mean either:
 1) never define new extension headers (except in _very_ controlled 
scenarios, like new payload protocols)
 2) implement some form of 'extension header capability discovery'.

A workaround is to stuff everything you'd want in an extension header into
destination options instead where you can define its discard/ignore
behaviour.

Was this side-effect of header chaining considered when specifying IPv6?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 17 Oct 2001 17:29:24 +0700

Date:        Tue, 16 Oct 2001 22:23:31 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

When I saw your message (its Subject anyway) I thought you might have
going to propose a method for...

  |  2) implement some form of 'extension header capability discovery'.

which might be a useful thing to have.

But all you really did was ask...

  | Was this side-effect of header chaining considered when specifying IPv6?

to which the answer is yes, and ...

  |  1) never define new extension headers (except in _very_ controlled 
  | scenarios, like new payload protocols)

was essentially the response - there are just 256 header codes, no-one
wanted defining a new one to be something easy.

  | A workaround is to stuff everything you'd want in an extension header into
  | destination options

Where what is needed fits as an option, that works just fine.

The real problem of course is that there's no fixed header layout format,
and given that TCP, UDP (and encapsulated IP of various flavours) are
some of the headers, there never was a chance for there to have been one.

That means that we can't predict the length of the header, nor where in
it to find the next header field.

What we could do, which I don't recall being explored, is to define a
couple of prototype header layouts, perhaps one for cases where an 8 bit
length (counting 64 bit units) will do, and one for a 16 bit length
(counting bytes probably), and set aside a range of header numbers that
we define will only include headers of a defined format (and headers that
can be safely ignored, or perhaps the defined format also gets an ignore/drop
bit as well).

That is, perhaps headers numbers 192-255 could be ones with a defined format
with a 16 bit length field, and 128-191 could be ones with a defined format
and an 8 bit length field.   Headers with id numbers < 128 would be of any
random format (as now), and the "must drop if unknown" semantics would continue.

Then, if there was a need to define a new header, and the use of the header
makes it rational for the recipient to simply ignore the header and continue
processing the rest of the packet, then the header could be designed to fit
one of the known format layouts, so it could be safely ignored.

Whether this would go too far towards making it too easy to define new
headers though I'm not sure - possibly.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Oct 2001 18:40:02 +0200 (CEST)

>  2) implement some form of 'extension header capability discovery'.

My personal opinions - and see philosophical question at end.

In some cases new extensions headers can be viewed the same way as new
transport protocols - how does an application know whether the peer implements
SCTP or whether it must fall back to TCP? In some cases this is handed by out
of band communication.

In other cases the desire might be to use extension headers might be more 
like destination options. The suggestion in mobile-ip is to carry optional
information as an extension header since IPsec selectors can operate on
the next header but isn't as specified capable of looking at individual
options.

There is a mechanism which *can* be used to determine if the peer is 
supporting a new extension header. If it isn't supported is
ICMP parameter problem with code = unrecognized Next Header type encountered
will be returned.

The philosophical question is whether ICMP parameter problem is
intended for this purpose, or whether it is a debugging tool i.e.
protocols shouldn't respond to this ICMP error by altering their
behavior.

   Erik