[ih] Protocol numbers (was IP version 7)
Bob Hinden
bob.hinden at gmail.com
Thu Dec 24 09:56:15 PST 2020
John,
> On Dec 22, 2020, at 6:04 PM, John Gilmore <gnu at toad.com> wrote:
>
> Bob Hinden via Internet-history <internet-history at elists.isoc.org> wrote:
>> BTW, I am not sure why 8 and 9 are labeled as historic, but 7 isn't.
>> I will ask IANA about this off list.
>
> While we're thinking about it, there is another small field that
> threatens to overflow sometime in the foreseeable future, the "Assigned
> Internet Protocol Numbers". These are 8 bits wide, and exist in every IPv4
> and IPv6 packet:
>
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
This topic comes up periodically. As Brian said, it it impossible to know what is being used on the Internet.
For example, Craig Partridge and I were involved in RDP (RFC908 and RFC1151). We were not aware of any active use, until someone pointed out it was a required part of the specification for eSIM used in mobile phones. See:
https://www.etsi.org/deliver/etsi_ts/102100_102199/102127/06.06.00_60/ts_102127v060600p.pdf
The other reason why I don’t think the space is at risk of filling up is is because most new protocols won’t make it through most NAT or Firewalls. People tend to do new stuff under UDP, TCP, or HTTP.
As far as I can tell, there has only been one new assignment in the last ten years.
Bob
>
> The frequently used ones are TCP (6), UDP (17), ICMP (1), etc. Then
> there is the dross. This registry is already more than half full, and
> it lists as actively in use such flashes-in-the-pan as the BR-SAT-MON
> (Backroom SATNET Monitoring), the Sun-ND PROTOCOL ("Temporary") from the
> early 1980s, Ipsilon Flow Management Protocol, Sprite-RPC from 1986,
> CPHB Computer Protocol Heart Beat, Source Demand Routing Protocol, 3PC
> 3rd Party Connect Protocol, and tons of other things that should have
> just gotten a UDP port number assigned from a 16-bit field. Half of
> these protocols don't even have an RFC that defines the protocol.
>
> There is no defined process for reclaiming them, other than having the
> original requester write an email to IANA and tell them that it isn't in
> use any more. That seems to be true even if the original requester
> worked for a company that the protocol was used by, and the company
> still exists (like Sun/Oracle) even though the requester has moved on
> decades ago. Probably, fewer than half of the people who got these
> protocol numbers assigned are now dead, but every year creates more
> such situations.
>
> I succeeded in asking John Ioannidis to release 2 of the 3 protocol
> numbers that he got assigned during the early packet encryption days.
> IANA wouldn't just de-allocate them, but they have at least marked them
> "deprecated". JI isn't sure if his IPIP, protocol 94, is in use
> anywhere. We think everybody encapsulating IPv4 in IPv4 or IPv6 packets
> is using protocol 4 nowadays, but how would one actually tell? So 94
> remains not deprecated.
>
> When designing IPv6, the designers made the address space huge, but the
> protocol space is *smaller* than in IPv4. Not only do the protocol
> numbers used in IPv4 overlap those used in IPv6, but both of them
> overlap the "IPv6 extension header" allocation space. Assigning a new
> protocol OR a new extension header burns up space for all three
> protocols.
>
> Could anybody who is reading this list, who at one point got a protocol
> number assigned, please check if it can be released? You can search the
> above IANA page for your name, to find out if IANA thinks you are in
> charge of any.
>
> Or, perhaps notify a retired researcher not on the list, (e.g. is
> anybody running Noel Chiappa's CHAOSnet, protocol 16, on top of IP? Or
> Zaw-Sing Su's Packet Radio Measurement protocol 21? Or the mystery
> EMCON protocol 14 with no known contact person or protocol spec?)
>
> And let's together think up a viable way to release the protocols that
> were used for some research project, and were then left behind by a
> person who has since departed the planet for realms where the protocol
> number space is infinite.
>
> John
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20201224/96f01d1f/attachment.asc>
More information about the Internet-history
mailing list