Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!wb6rqn.UUCP!brian
From: brian@wb6rqn.UUCP (Brian Lloyd)
Newsgroups: comp.protocols.tcp-ip
Subject: Exchanging serial numbers
Message-ID: <8802251906.AA04676@wb6rqn.UUCP>
Date: 26 Feb 88 00:06:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

Here at Sirius Systems we have been discussing a means to protect our
TCP/IP software without placing undue strain on the users.  The primary
concern is that someone might purchase one copy of the package and then
copy it to all his/her systems.  The concept that we came up with is to
exchange serial number information as part of the options field in the
TCP header when two TCP's exchange SYNs at session establishment.  TCP
resets the connection and returns a protocol error if both versions of
the software have the same serial number. 

Our reading of MIL-1778 and RFC-793 leads us to believe that the only
predefined option types are 0 (End of option list), 1 (No-op), and 2
(MSS).  We propose a fourth option (type 3) for exchanging serial
numbers.  The option type would be 3, the length would be 8, the next
two octets would be a vendor code, and the last four octets would be the
serial number.

The separate vendor code and serial number permits vendors to have
identical serial numbers but still allow the overall value of the
combined fields to be unique.  This would prevent potential conflicts
when communicating between different vendors' software/hardware. 

Now comes the reason for this letter: is a strange option in a TCP
header likely to break others' TCP implementations or will other TCPs
ignore an unrecognized option?

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!