Subject: (IPng 7248) loose end...

From: [email-masked] (Peter R. Tattam)
Date: Tue, 2 Mar 1999 12:50:00 +1100

This has been thrashed out before I bet, but I'm concerned over a particular 
issue relating to IPv6 headers.

In the implementation of my stack, I came across an issue as to how to 
recognize and deal with undefined headers.

say stack A implements the standard IPv6 headers.  Stack B also implements 
the same options and the two stacks communicate without a problem.  Customer X 
is utilizing a protocol outside the mainstream, it could be listed in the 
assigned numbers, but not necessarily so.

Some time later, IPv6 is updated and new headers are implemented in 
stack B.  This new header however is indistiguishable from the protocol 
that customer X has.  Stack A cannot be updated easily for any number of 
reasons.

The issue is two fold.  Firstly how is an IPv6 option distinguishable from a 
regular IP protocol.  Secondly if it is unknown, how do we not know that there 
are known protocols further along the chain.

The RFC says that seeing an unknown header options implies that the packet be 
dropped and a parameter problem message be sent back to the originating host, 
but I personally think that is unacceptable.  Firstly, the unrecognized header 
may actually be recognizable as a valid IP payload.  Secondly, it may result 
in well known IP payloads not getting through simply because the originating 
host threw a new header in.  Indeed a router may insert a header too, or is 
that forbidden.

The issue manifests itself in my stack as a clash between two data 
structures/algorithms, the first being the header demultiplexor and the second 
the protocol demultiplexor.

The issue I believe is resolvable if there is a sure fire way of 
distinguishing between header options and between payloads.  As it stands, the 
know values for IPv6 headers are quite assorted and follow no pattern as far 
as I can see.

While some may see the issue as purely academic as it might be suggested that 
there will be no more IPv6 header classes in the foreseeable future, I believe 
that the issue may eventually bite us in the bottom.  It also cuts right 
across the grain of the Internet protocols being rugged in nature.  IPv4 was 
different in this regard in that options are always recognizable and can be 
parsed out simply.

Have got it plain wrong? or have I missed something that is obvious.  Please 
feel free to correct me if necessary.

If I haven't got it wrong, I believe it to be a flaw in the protocol and we 
need to do something to control the issue.

Peter

--
Peter R. Tattam - Managing Director          
Trumpet Software International Pty Ltd.
Phone: +61-3-6245-0220     Fax: +61-3-6245-0210
--------------------------------------------------------------------
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]
--------------------------------------------------------------------