Yesterday, I mentioned that a Cisco router running pre-standard IS-IS 3-way handshake (this is why you need it) interoperates with multiple implementations of RFC 5303. How’s that possible, and does it matter whether you configure the ancient Cisco routers (release 15.x) to use IETF 3-way handshake instead of the “proprietary” one?

I took a trip to the Wireshark land to figure out the details (you can download the capture file):

Here’s a pre-standard (cisco) IS-IS P2P hello sent by a Cisco router running IOSv release 15.9:

And here’s a standard (RFC 5303) IS-IS P2P hello sent by FRRouting release 10.3:

The only difference between the two is the extra values in TLV 240, starting with Extended Local Circuit ID. It’s nice of Cisco IOS to ignore the fields it does not understand, but why do other implementations accept the shorter version of TLV 240? Welcome the magic powers of SHOULD (and a judicious application of the Robustness Principle that some vendors sometimes forget about). Straight from RFC 5303:

Any system that supports this mechanism MUST include the Adjacency Three-Way State field in this option. The other fields in this option SHOULD be included as explained below in section 3.2.

Let’s see what we can do with those fields. Section 3.2 says:

If the option with a valid Adjacency Three-Way State is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, SHALL be examined.

Let me rephrase: It’s perfectly OK if those fields are missing. This makes pre-standard Cisco IS-IS hello compliant with RFC 5303, but if you configure Cisco IOS to use IETF handshake, you get the extra fields.

But at least if the fields are present, we use them:

If they are present, and the Neighbor System ID contained therein does not match the local system’s ID, or the Neighbor Extended Local Circuit ID does not match the local system’s extended circuit ID, the PDU SHALL be discarded and no further action is taken.

On a totally tangential topic, while I know the two words are equivalent under the rules of RFC 2119, I would much prefer MUST over SHALL to make it more obvious to international audiences¹.

Anyway, isn’t that a great way to write standards? Everyone can claim compliance, regardless of the details of what they do. On a more realistic front, I experienced how the RFC sausage is made, and understand why things sometimes have to be written that way to get the job done (hint: vendors or obstinate individuals).

Revision History

2025-07-01:

Sander Stefann quickly pointed out that I mixed up SHALL and SHOULD (at least I can claim that English is not my native language 😜), prompting me to rewrite the second half of the blog post. It’s not as bad as I thought it was.