Re: Payload Type number assignments

[Steve Deering <[e-mail]>]

> Given that the SIP header itself is distinguishable from Pip
> and everything else by virtue of the first nibble, is it
> necessary to have a separate number for each of SIP, Pip, CLNP,
> and IPv7 encapsulated over IP?

Good point, Paul.  SIP clearly needed its own Protocol ID when it
didn't have a version number field, and if there is any chance that
the version number field still might disappear, we should keep a
distinct Protocol ID for SIP.  (For those who didn't read the minutes
of the last SIP meeting, we re-examined the issue of version number
vs. ethertype demuxing of SIP packets, and decided to stay with
the version number.  It is remotely possible that we may yet reverse
that decision, based on experience with the prototype implementations.)

If we want to treat Pip, SIP, and IPv7 as simply different versions of IP,
there are already 3(!) different IP Protocol IDs specified for encapsulating
IP within IP:

	 4  IP		assigned to Jon Postel; specification unknown to me
	94  IPIP	specified in the Columbia Mobile IP draft
	98  ENCAP	RFC-1241

I suppose one possible reason for using multiple, different Protocol IDs
is if you need to know the *reason* why a packet is encapsulated (e.g.,
tunneling for transition purposes vs. tunneling for mobility support),
but that might be better handled by having a Reason field in an
"encapsulation header" (a header that goes between the two IP headers).
Protocols 94 and 98 both have encapsulation headers, though it is optional
in protocol 94.

I suggest that you do not re-use the SIP protocol ID (41) for Pip, but
rather choose one of 4, 94, or 98; we should think about doing the same
thing for SIP.

Steve