Subject: (IPng 7249) RE: loose end...

From: Brian Zill <[email-masked]>
Date: Mon, 1 Mar 1999 18:28:11 -0800

Peter,

Could you be more specific about what you perceive to be the problem?  You
seem to be using the terms "headers" and "options" interchangeably, when
they are very different things in IPv6.  I believe you always mean
"headers", but it's not completely clear.

Packets with unrecognized headers must be dropped because there is no way to
skip over them.  Options, however, have a bit specifying whether they should
be dropped or skipped over if the receiving host does not recognize them.

Obviously, new headers are not expected to be created lightly.  The fact
that they will not work with stacks that don't understand them will serve to
restrict their development.  This is no different than it was for creating
new IPv4 protocols.  I don't see the problem.

In our stack, what you call the "header demultiplexor" and the "protocol
demultiplexor" are the same thing.  They're all headers, there is no reason
to treat "protocols" as different things.

--Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 01, 1999 17:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: (IPng 7248) loose end...
> 
> 
> 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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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]
--------------------------------------------------------------------