Date: Tue, 16 Oct 2001 22:23:31 +0300 (EEST)
From: Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
