Subject: (IPng 7250) Re: loose end...

From: [email-masked] (Peter R. Tattam)
Date: Tue, 2 Mar 1999 14:04:47 +1100

In article <4FD6422BE942D111908D00805F3158DF07222A97@RED-MSG-52> Brian Zill <[email-masked]> writes:
>From: Brian Zill <[email-masked]>
>To: "[email-masked]'" <[email-masked]>, [email-masked]
>Cc: [email-masked]
>Subject: RE: (IPng 7248) loose end...
>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.

I do indeed mean headers.  I thought I had removed all references to the word 
"options" as I was aware of the confusion but obviously not :)

>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.

I have observed that the current header structure follows some kind of pattern 
and have utilized that to my advantage.  Given that headers adhere to the 
pattern, I could arbitrarily skip unknown headers if I could distinguish a 
header from a 

>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.

There is a subtle difference between a header and a protocol in that requires 
slightly different processing i.e. the packet must be reprocessed.  If a 
protocol is missing, it can be implemented via a raw socket in my stack.  The 
model is fairly clean for unimplemented protocols, but not so for 
unimplemented headers.  

>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.

I guess I could have processed headers as generic protocols using raw sockets, 
but I believe that most stacks will tend to optimize these frequent operations 
(especially fragmentation) through the use of specific header recognition at 
the IP packet processing layer, which is in fact what I do in my stack.

I brief look at the ICMPV6 RFC indicates that there is no distinction between 
protocols and headers since it only refers to an invalid next header field 
when sending a parameter problem message.

With that in mind, perhaps it needs to be stated more clearly that it is 
deliberate that the distinction between protocols and headers is supposed to 
be blurry, and that stacks should be designed with that concept in mind.  If I 
had known this at the time, my implementation could indeed have been 
simplified - indeed the modification needed is basic and I may implement it if 
I can get a definite answer on the issue of whether there needs to be any 
distinction between headers and payloads.

>--Brian

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]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Tue, 02 Mar 1999 15:13:01 +1100

Date:        Tue, 2 Mar 1999 14:04:47 +1100
    From:        [email-masked] (Peter R. Tattam)
    Message-ID:  <[email-masked]>

  | I have observed that the current header structure follows some kind
  | of pattern and have utilized that to my advantage.

As I recall, the routing header is different from the others, and when the
draft for the payload header was around, it also was quite different.
There's no guarantee at all that a header that you don't recognise can be
parsed according to any rules that you think you can infer from the headers
that you can recognise.

  | There is a subtle difference between a header and a protocol in that
  | requires slightly different processing

I can't imagine what that difference is.  The (now defunct) payload header
carried (one or more instances of) TCP, UDP (or anything else) in its body.

The only oddity is that we have a set of legacy headers that are required to
come last in the packet processing, as they carry no "next header" field.

  | If a protocol is missing, it can be implemented via a raw socket

So could processing of a missing header.

  | I guess I could have processed headers as generic protocols using raw
  | sockets, but I believe that most stacks will tend to optimize these
  | frequent operations

yes, they will, just as most stacks optimise UDP TCP and (most) ICMP by
including their processing in the kernel.  It seems unlikely that a
not-yet-invented header will be a frequent operation - or not within the
timeframe before general deployment of stacks that support it well.

Implementors might want to make sure they have a mechanism that allows a
packet that has been passed out for raw processing of an unknown header to
be dropped back into the kernel for processing of later headers though.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 02 Mar 1999 09:16:49 -0600

Peter, the key to the answer is this paragraph from RFC 2460:

   Next Header          8-bit selector.  Identifies the type of header
                        immediately following the IPv6 header.  Uses the
                        same values as the IPv4 Protocol field [RFC-1700
                        et seq.].

The 8-bit field that identifies IPv6 extension headers is drawn from
the same space that identifies "higher-level protocols" such as TCP,
IP-in-IP, ESP, and so on.  So if you customer X got an assigned
number, he's safe.  If he pulled an unassigned number out of thin
air, he's not safe, but he wouldn't have been safe anyway since his
number could have been given to a new thing-that-you're-calling-a-
protocol.

And Brian, remember that we do still have options in v6, but they're
wrapped in specific extension headers: the hob-by-hop and destination
options headers.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------