drw@pascal.mit.edu (Dale R. Worley) (08/31/90)
Is there any standard for how a TCP/IP implementation ignores options that it does not understand and/or implement? Of course, that doesn't happen now, because there are only three options, and all implementations are required to implement them, but this might not always be true. What I'm proposing is that an implementation can ignore an unimplemnted option, which requires that there be a convention to tell whether an option has an argument or not. If I remember correctly, among the current options, 0 and 1 don't have arguments, and 2 does, so we should establish the convention that the '2' bit (second-lowest) is 0 if the option has no argument and 1 if it does. Is this a good idea? Is it worth worrying about? (Please reply by e-mail, as I don't read this newsgroup regularly.) Dale Worley drw@math.mit.edu
zweig@casca.cs.uiuc.edu (Johnny Zweig) (08/31/90)
Ignoring Unimplemented TCP Options -- it's not just a good idea; it's the Law.
postel@VENERA.ISI.EDU (08/31/90)
Dale Worley: The statement has been made that the only options that will ever exist with out a length field are the end-of-options (0) and no-operation (1) options. All other options now and defined in the future will have a length field as their second byte. " so we should establish the convention that the '2' bit (second-lowest) is 0 if the option has no argument and 1 if it does. Is this a good idea?" NO. This is a bad idea. Just treat special case option codes 0 and 1. Look for the length field for all other option codes. --jon.
braden@VENERA.ISI.EDU (08/31/90)
From tcp-ip-RELAY@NIC.DDN.MIL Fri Aug 31 08:43:17 1990 Date: 31 Aug 90 05:23:28 GMT From: math.mit.edu!drw@bloom-beacon.mit.edu (Dale R. Worley) Organization: MIT Dept. of Mathematics, Cambridge, MA, USA Subject: Unknown TCP/IP options Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is there any standard for how a TCP/IP implementation ignores options that it does not understand and/or implement? Dale, Yes. Please see sections 3.2.1.8, 4.1.3.2, and 4.2.2.5 of RFC-1122 for option processing in IP, UDP, and TCP, respectively. Bob Braden