4

I am unable to understand the meaning behind the following extract from the ARP RFC 826:

For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is taken from the set ether_type$. This is a natural reuse of the assigned protocol types. Combining this with the opcode (ar$op) would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor/debugger more complex (see Network Monitoring and Debugging below). It is hoped that we will never see 32768 protocols, but Murphy made some laws which don't allow us to make this assumption.

How is this method restricting the protocols that can be resolved to half? The way i see it we can resolve 2^16 protocols using this method.

Please suggest.

Thanks

1
  • I tried to look to see if I could find it but couldn't. I imagine it has to do with one of the bits in the 16-bit field being used for another purpose. That would reduce it to 15-bit field, which would match the 32768. I did see mention of the Op code being inserted into the Protocols field, but later found the opcode had its own dedicated 16 bits. – Eddie Jan 12 '16 at 21:30
2

The ARP opcode could be expressed as a single bit (REQUEST or REPLY). The argument could be made (and was, at the time) that 16-bits for both arp$pro and arp$op was wasteful, and that arp$op should simply be the high bit of the arp$pro field. Doing this would have restricted the available arp$pro space for ethernet to 15-bits.

35 years ago this was a much more significant concern than it is today, and that is why the discussion is called out specifically in the RFC.

1
  • @Rajat If this answer satisfied you, consider marking it as the accepted answer so Nick can get his credit. – Eddie Jan 13 '16 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.