TEXT LENGTH - 16 bits
These bits count the number of octets in the text of the packet,
not including octets in the header (which is fixed in length for
any particular format).
DESTINATION ADDRESS - 48 bits 
These bits could be allocated in the following way: Destination
Network Identifier - 8 bits; Destination Host Identifier - 8 bits;
Destination IMP identifier - 16 bits; Reserved- 16 bits.
SOURCE ADDRESS - 48 bits
These bits would be used in a fashion similar to the destination
The resulting packet is 144 bits long and adding the present 40-bit
Host-to-Host header results in a total of 184 bits, which is not very
pleasant. A temporary fix (until we can introduce a new NCP design)
might be to squeeze out the reserved 16-bit fields in the source and
destination address fields, giving 32 bits to carry the byte size and
byte count information for the present Host/Host protocol.
Alternatively, the length field of the packet header and one of the
facilities flags (or a whole field) could be used to indicate byte
size and byte count. Either idea would require some fairly
substantial modification of existing NCP programs, so is probably not
Another alternative would be to add a dummy byte after the 144th bit
of header, followed by 40 bits of NCP header, giving a total length
of message leader and NCP header of 192 bits, a number divisible by
12, 16, 24, 32, 48.
With respect to the proposed text length field, although bit lengths
are the most flexible, it seems reasonable to admit that nearly all
data transmission is done in 8-bit quantities, and therefore that bit
lengths are, in fact, an unnecessary luxury. This is a weak argument
when 36-bit and 32-bit machines must interface.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 11/99 ]