RFC 3719

Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)

📅 published February 2004, from ietf

RFC 3719 💖 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)

okay bestie, this one is from the Network Working Group, and the lead author is J. Parker, Ed., from Axiowave Networks 🦋

It's an Informational doc from February 2004, which means it shares info with the community and isn't an Internet standard 🌸 It has no Obsoletes or Updates lines in its header, so it doesn't replace or change any other RFC 💅

Status of This Memo ✨

This memo is for the Internet community to read as info. It does not specify an Internet standard of any kind, and it can be shared freely with no restrictions on distribution 🧚

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🌈

Okay so this doc looks at the ways IS-IS, as described in ISO 10589, differs from what people actually run today 🔥 It's here to help anyone implementing, testing, or deploying IS-IS. A companion doc covers RFC 1195 and how that version compares to real-world IP routing ✨

Table of Contents 🎀

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Constants That Are Variable . . . . . . . . . . . . . . . . .  2
3.  Variables That Are Constant . . . . . . . . . . . . . . . . .  4
4.  Alternative Metrics . . . . . . . . . . . . . . . . . . . . .  6
5.  ReceiveLSPBufferSize. . . . . . . . . . . . . . . . . . . . .  6
6.  Padding Hello PDUs. . . . . . . . . . . . . . . . . . . . . .  8
7.  Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . .  9
8.  Purging Corrupted LSPs. . . . . . . . . . . . . . . . . . . . 10
9.  Checking System ID in Received point-to-point IIH PDUs. . . . 10
10. Doppelganger LSPs . . . . . . . . . . . . . . . . . . . . . . 11
11. Generating a Complete Set of CSNPs. . . . . . . . . . . . . . 11
12. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
16. Author's  Address . . . . . . . . . . . . . . . . . . . . . . 14
17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15

1. Introduction 🫶

In theory, there is no difference between theory and practice. But in practice, there is. Jan L.A. van de Snepscheut

Ngl, that quote is so accurate 😭 Interior Gateway Protocols like IS-IS exist to give timely info about the best routes in a routing domain 🗺️ The original IS-IS design, from ISO 10589 [1], has held up really well 👑 Still, a bunch of the original design choices have been changed in practice. This doc covers the differences between ISO 10589 and what you can actually see on the wire today. The companion doc covers RFC 1195 [2] for routing IP traffic and current practice 💅

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [3] 🎀

2. Constants That Are Variable 🌸

Some parameters that ISO 10589 defined as constant get modified in practice, and the list is:

  1. MaxAge - the lifetime of a Link State PDU (LSP)
  2. ISISHoldingMultiplier - a parameter used to describe the generation of hello packets
  3. ReceiveLSPBufferSize - discussed in a later section

2.1. MaxAge ⏳

Every LSP has a RemainingLifetime field, which starts out set to MaxAge on the IS that generates it 🦋 That value counts down to show how much time has passed and how many times the LSP has been forwarded. When a foreign LSP's value hits 0, an IS starts a purge that flushes the LSP out of the network. This is the bit that makes sure corrupted or otherwise invalid LSPs don't hang around forever 🧹 How often the originating IS regenerates its LSPs is set by maximumLSPGenerationInterval.

MaxAge is defined in ISO 10589 as an Architectural constant of 20 minutes, and maximumLSPGenerationInterval is recommended to be 15 minutes. Those times turned out to be too short in some networks 🙈 They cause a steady stream of LSP updates even when nothing is changing. To cut down on how often LSPs get regenerated, some implementations let the network operator set these times.

The relationship between MaxAge and maximumLSPGenerationInterval is covered in section 7.3.21 of ISO 10589 🔍 If MaxAge is smaller than maximumLSPGenerationInterval, an LSP expires before it gets replaced, which is so not it 💀 And since RemainingLifetime goes down each time the LSP is forwarded, an LSP that's far from its origin looks older and gets removed sooner. So, for an LSP to survive long enough to be replaced, MaxAge should exceed maximumLSPGenerationInterval by at least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first term, ZeroAgeLifetime, estimates how long it takes to flood an LSP through the network. The second term, minimumLSPTransmissionInterval, covers how long a router might wait before it sends an LSP ⏱️ The original recommendation was that MaxAge be at least 5 minutes bigger than maximumLSPGenerationInterval, and honestly that's still valid today ✨

An implementation MAY use a value of MaxAge that is greater than 1200 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at least 300 seconds. An implementation SHOULD NOT use its value of MaxAge to discard LSPs from peers, as discussed below 🙅‍♀️

An implementation is not required to coordinate the RemainingLifetime it assigns to LSPs with the RemainingLifetime values it accepts. It MUST ignore the following sentence from section 7.3.16.3. of ISO 10589 💅

"If the value of Remaining Lifetime [of the received LSP] is greater than MaxAge, the LSP shall be processed as if there were a checksum error."

2.2. ISISHoldingMultiplier 🧚

An IS sends IS to IS Hello Protocol Data Units (IIHs) on a regular schedule over active circuits, so other attached routers can keep tabs on whether it's alive 👀 The IIH has a two-byte field called the Holding Time, which sets the time to live for an adjacency. If an IS doesn't hear a hello from an adjacent IS within that holding time, it assumes the neighbor is no longer operational and removes the adjacency. Rude, but efficient 💀

ISO 10589 defines ISISHoldingMultiplier as 10, and says the Holding Time should equal ISISHoldingMultiplier times iSISHelloTimer for ordinary systems, and times dRISISHelloTimer for a DIS. That means the neighbor has to lose 10 IIHs before the adjacency times out 🕰️

In practice, a value of 10 for ISISHoldingMultiplier turned out to be way too big 🙄 DECnet PhaseV had two related values. The variable holdingMultiplier, with a default of 3, was used for point-to-point IIHs, while the variable ISISHoldingMultiplier, with a default of 10, was used for LAN IIHs. Most implementations today set the default ISISHoldingMultiplier to 3 for both circuit types 🍓

Adjacent systems can use different Holding Time values, and they'll still form an adjacency even though the hold times aren't symmetric 🤷‍♀️

An implementation MAY let ISISHoldingMultiplier be configurable. Values lower than 3 are unstable, and they may cause adjacencies to flap 🦋⚠️

3. Variables That Are Constant 🌈

Some values that ISO 10589 defined as variables don't actually change in practice. The list is:

  1. ID Length - the length of the SystemID
  2. maximumAreaAddresses
  3. Protocol Version

3.1. ID Length 🆔

The ID Length is a field carried in all PDUs. It defines the length of the System ID, and it's allowed to take values from 0 to 8. A value of 0 is interpreted to mean a length of 6 bytes. As suggested in B.1.1.3 of [1], it's easy to use an Ethernet MAC address to make a unique 6-byte System ID 🔧 The SystemID only matters inside the IGP Domain, and 6 bytes has proven easy to use and plenty big in practice 💖 The new IS-IS Traffic Engineering TLVs also assume a 6-byte System ID. Other ID lengths are hard to support today ✨ Implementations can interoperate without being able to handle System IDs of any length other than 6.

An implementation MUST use an ID Length of 6, and it MUST check the ID Length defined in the IS-IS PDUs it receives. If a router runs into a PDU with an ID Length other than 0 or 6, section 7.3.15.a.2 says it MUST discard the PDU, and it SHOULD generate an appropriate notification 🚨 ISO 10589 defines the notification iDFieldLengthMismatch, while the IS-IS MIB [7] defines the notification isisIDLenMismatch.

3.2. maximumAreaAddresses 🏝️

The value of maximumAreaAddresses is defined to be an integer between 1 and 254. It sets how many synonymous Area Addresses can be in use in an L1 area, and it's advertised in the header of every IS-IS PDU 📮

Most deployed networks use one Area Address for an L1 area 🧘‍♀️ When areas get merged or split, a second address is needed for a seamless transition. The third area address was originally needed to support DECnet PhaseIV addresses alongside OSI addresses during a transition, which is such a throwback 🕰️

ISO 10589 requires that all Intermediate Systems in an area or domain use a consistent value for maximumAreaAddresses. Common practice is for an implementation to use the value 3, so an implementation that only supports 3 can expect to interoperate successfully with other conformant systems 🎀

ISO 10589 says an advertised value of 0 is treated as equivalent to 3. It also says the consistency check can be skipped if an implementation only supports the value 3 🧩

An implementation SHOULD use the value 3, and it SHOULD check the value advertised in the IS-IS PDUs it receives. If a router receives a PDU with a maximumAreaAddresses that is not 0 or 3, it MUST discard the PDU, as described in section 7.3.15.a.3, and it SHOULD generate an appropriate notification 🚫 ISO 10589 defines the notification maximumAreaAddressMismatch, while the IS-IS MIB [7] defines the notification isisMaxAreaAddressesMismatch.

3.3. Protocol Version 🔢

IS-IS PDUs include two one-byte fields in their headers: "Version/Protocol ID Extension" and "Version" 🧾

An implementation SHOULD set both fields to 1, and it SHOULD check the values of these fields in the IS-IS PDUs it receives. If a router receives a PDU with a value other than 1 in either field, it MUST drop the packet, and it SHOULD generate the isisVersionSkew notification 🌟

Part 1 of 3 done bestie 💜 Part 2 is coming next with Sections 4 through 9, so stay tuned! 🫶

4. Alternative Metrics ✨

Okay so, ISO 10589 (Section 7.2.2) gives us four metrics: Default Metric, Delay Metric, Expense Metric, and Error Metric. 🦋 Only the Default Metric is actually used in deployed networks, and most implementations only look at the Default Metric, so the other three are basically background characters 💅. In ISO 10589, the most significant bit of each 8-bit metric was the S (Supported) field, which said whether the metric was meaningful at all.

      If this IS does not support this metric it shall set bit S to 1
      to indicate that the metric is unsupported.

The Supported bit was always 0 for the Default Metric, since the Default Metric MUST always be supported 🔥. Plot twist though: RFC 2966 [5] uses that same bit in the Default Metric to mark L1 routes that got leaked from L1 to L2 and then back down into L1 again. Iconic reuse, no cap 🌀.

When you're using narrow metrics, implementations MUST generate the Default Metric, and they SHOULD ignore the other three metrics 💖. Implementations MUST assume the Default Metric is supported, even if the S bit is set. RFC 2966 also describes restrictions on leaking those routes learned from L1 into L2, so go read that too 🫶.

5. ReceiveLSPBufferSize 🎀

Okay, bestie, this one is serious. IS-IS doesn't allow segmentation of protocol PDUs, which means Link State PDUs (LSPs) have to be propagated without modification on every IS-IS enabled link throughout the area/domain 😭. So it's essential to configure a maximum size that all routers can forward, receive, and store. Everyone has to be on the same page or the whole thing gets messy.

This affects three things, and we'll go through them one at a time 🧚:

  1. The largest LSP we can receive (ReceiveLSPBUfferSize)
  2. The size of the largest LSP we can generate (originatingL1LSPBUfferSize and originatingL2LSPBufferSize)
  3. Available Link MTU for supported Circuits (MTU). Note this often differs from the MTU available to IP clients.

ISO 10589 defines the architectural constant ReceiveLSPBufferSize with value 1492 bytes, plus two private management parameters: originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating buffer size parameters set the maximum size of an LSP that a router can generate. ISO 10589 tells the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error 🙈.

It is crucial that:

originatingL1LSPBufferSize <= ReceiveLSPBufferSize
originatingL2LSPBufferSize <= ReceiveLSPBufferSize

and that, for all L1 links in the area:

originatingL1LSPBufferSize <= MTU

and for all L2 links in the domain:

originatingL2LSPBufferSize <= MTU

The original thinking was that operators could decrease the originating buffer size when they're dealing with smaller MTUs, but they wouldn't need to increase ReceiveLSPBufferSize past 1492. Classic 2000s vibes 💀.

Then came new info to advertise in LSPs, like the Traffic Engineering TLVs, and suddenly the limited space of the LSP database each router can generate (256 * 1492 bytes at each level) became an actual problem 😩. Modern networks with MTUs bigger than 1492 on all links are not uncommon, so one way to expand the LSP database is to allow values of ReceiveLSPBUfferSize greater than 1492. Slay 👑.

Making ReceiveLSPBUfferSize a configurable parameter instead of an architectural constant has to be handled with care 🍓. If any system in the network doesn't support values larger than 1492, or if one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP any router may generate, then full propagation of all LSPs may not be possible. That can lead to routing loops and black holes, which is literally the worst case ngl 😭.

The steps below are recommended when you change ReceiveLSPBufferSize:

  1. Set the ReceiveLSPBufferSize to a consistent value throughout the network.
  2. The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level.
  3. Include an originatingLSPBufferSize TLV when generating LSPs, introduced in section 9.8 of ISO 10589:2002 [1].
  4. When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifications and Alarms.
  5. Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms.
  6. Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misconfigured network.

Steps 1 and 2 are enough by themselves, but mismatches have serious consequences that are also hard to detect. So steps 3 through 6 are recommended to help track down and fix problems 🔍✨.

6. Padding Hello PDUs 🌸

To prevent adjacencies from forming between systems that might not be able to successfully receive and propagate IS-IS PDUs (because of inconsistent settings for originatingLSPBufferSize and ReceiveLSPBufferSize), section 8.2.3 of [1] requires padding on point-to-point links 🫧.

On point-to-point links, the initial IIH is to be padded to the maximum of:

  1. Link MTU
  2. originatingL1LSPBufferSize if the link is to be used for L1 traffic
  3. originatingL2LSPBufferSize if the link is to be used for L2 traffic

ISO 10589 (section 6.7.2 e)) assumes this:

Provision that failure to deliver a specific subnetwork SDU
will result in the timely disconnection of the subnetwork
connection in both directions and that this failure will be
reported to both systems

With that service provided by the link layer, requiring only the initial IIH to be padded was enough to check that the MTU matched on both sides. If the PDU was too big to be received, the link would get reset 🔄. But link layer protocols used on point-to-point circuits today often don't have this service, so the padded initial PDU might be silently dropped without resetting the circuit 😬. That means requiring only the initial IIH to be padded doesn't give the guarantees ISO 10589 expected.

If an implementation uses padding to detect problems, point-to-point IIH PDUs SHOULD be padded until the sender declares the adjacency on the link to be in state Up 💜. If the implementation implements RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", then this is when the three-way state is Up. If the implementation uses the "classic" algorithm described in ISO 10589, this is when adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be resumed whenever the adjacency is torn down, and SHOULD continue until the sender declares the adjacency to be in state Up again 🔁.

If an implementation is using padding and originatingL1LSPBUfferSize or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be brought down and reestablished, so the protection provided by padding IIH PDUs stays consistent with the modified values 🛠️.

Some implementations choose not to pad, and padding doesn't solve every problem with misconfigured systems. In particular, it isn't transitive. Say A, B, and C all pad IIH PDUs, and A and B can establish an adjacency, and B and C can establish an adjacency. We still can't conclude that A and C could establish an adjacency, even if they were neighbors 🙃.

The presence or absence of padding TLVs MUST NOT be one of the acceptance tests applied to a received IIH, regardless of the state of the adjacency. No exceptions, periodt 💅.

7. Zero Checksum 🧊

A checksum of 0 is impossible if the checksum is computed according to the rules of ISO 8473 [8] 🙅.

ISO 10589, section 7.3.14.2(i), says:

A Link State PDU received with a zero checksum shall be treated
as if the Remaining Lifetime were zero.  The age, if not zero,
shall be overwritten with zero.

So ISO 10589 tells the receiver to purge the LSP. In practice this has proved to be disruptive 😤. An implementation SHOULD treat all LSPs with a zero checksum and a non-zero remaining lifetime as if they had a checksum error. Those packets SHOULD be discarded 🗑️.

8. Purging Corrupted PDUs 🫠

ISO 10589 requires, in section 7.3.14.2 e), that any LSP received with an invalid PDU checksum should be purged. This has been found to be disruptive too, so most implementations today follow the revised specification and just drop the LSP 🙌.

ISO 10589:2002 [1], Section 7.3.14.2, says:

(e)  An Intermediate system receiving a Link State PDU with an
     incorrect LSP Checksum or with an invalid PDU syntax SHOULD

     1) generate a corruptedLSPReceived circuit event,

     2) discard the PDU.

9. Checking System ID in Received point-to-point IIH PDUs 🔐

In section 8.2.4.2, ISO 10589 doesn't explicitly require comparing the source ID of a received IIH with the neighbourSystemID associated with an existing adjacency on a point-to-point link. Oops 🙈.

To fix that gap, implementations that receive an IIH PDU on a point-to-point circuit with an established adjacency SHOULD check the Source ID field and compare it with the neighbourSystemID of the adjacency. If they differ, an implementation SHOULD delete the adjacency 🧹.

Here's the catch: IIH PDUs as specified in ISO 10589 don't include a checksum. So a corrupted IIH could falsely suggest the neighbor's System ID changed 😵‍💫. The subnetwork guarantees required for point-to-point links, described in 6.7.2 g) 1), assume undetected corrupted PDUs are very rare (one event per four years). But a link with frequent errors that produce corrupted data could end up flapping an adjacency 📉. An optional checksum TLV, specified in "Optional Checksums in IS-IS" [6], can be used to detect this kind of corruption ✅. Hello packets that carry this TLV and are corrupted PDUs SHOULD be silently dropped, rather than dropping the adjacency.

Some implementations have chosen to discard received IIHs where the source ID differs from the neighbourSystemID. That can prevent needless flapping caused by undetected PDU corruption 🦋. But if an actual administrative change to the neighbor's system ID has happened, this strategy may mean the existing adjacency has to time out before an adjacency with the new neighbor can be established ⏳. That gets sped up if the neighbor resets the circuit, as ISO 10589 anticipates after a System ID change, or resets the 3-way adjacency state, as RFC 3373 anticipates 🎀.

10. Doppelganger LSPs 👻✨

Okay so, when an Intermediate System shuts down, it can leave old LSPs floating around the network. 👻 Normally, when a router reboots, it clears them out by reissuing those fragments with a higher sequence number, or by purging the fragments it isn't currently generating. Tidy! 🧹

Now the tricky bit. A received LSP or SNP entry and an LSP in the local database can have the same LSP ID, the same sequence number, non-zero remaining lifetimes, and different non-zero checksums. When that happens, the rules in [1] can't tell you which one is "newer." 😵‍💫 So an implementation may run an extra tie breaker by comparing the checksums. If it does, it MUST treat the LSP/SNP entry with the higher checksum as newer. When comparing, the checksum field is read as a 16 bit unsigned integer in network byte order (most significant byte first). 🔢

Why higher and not lower? It's arbitrary, honestly, but it matches existing implementations, so everyone stays compatible. 🤝

Also, a purged LSP (one with remaining lifetime set to 0) is always considered newer than a non-purged copy of the same LSP. Purge wins, periodt. 💅

11. Generating a Complete Set of CSNPs 📋

There are a bunch of situations where you have to generate a complete set of CSNPs. The DIS on a LAN, two IS's peering over a P2P link, and an IS helping another IS do graceful restart all need to do it so everyone's LSP Databases stay consistent. 🧩 Section 7.3.15.3 of [1] defines a complete set of CSNPs like this:

"A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e., there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). "

Strict adherence is required here, bestie. 🚨 Deviating can cause subtle defects that are super hard to catch. It's NOT enough to just cover the LSPIDs that are in your local database. The set has to cover the complete possible range of LSPIDs. Main character energy means covering everything, not just what you can see. 👑

Let's look at an example. Say the current Level 1 LSP database on a router has these non pseudo-node LSPs:

From system 1111.1111.1111 LSPs numbered 0-89(59H)
From system 2222.2222.2222 LSPs numbered 0-89(59H)

If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can fit into a single CSNP PDU. This is a correctly formatted complete set:

Start LSPID              End LSPID
0000.0000.0000.00-00     1111.1111.1111.00-59
1111.1111.1111.00-5A     FFFF.FFFF.FFFF.FF-FF

These are incomplete sets, so no thank you 🙅‍♀️:

Start LSPID              End LSPID
0000.0000.0000.00-00     1111.1111.1111.00-59
1111.1111.1111.00-5A     2222.2222.2222.00-59

That one has a gap after the second entry. 💀

Start LSPID              End LSPID
0000.0000.0000.00-00     1111.1111.1111.00-59
2222.2222.2222.00-00     FFFF.FFFF.FFFF.FF-FF

That one has a gap between the first and second entry. Not it. 🙈

Sending a CSNP with no actual LSP entry TLVs is legal, but you should never need to do it to conform to the specification. 🫠

12. Overload Bit 🚧

Okay, so some IS's can't store all the LSPs they receive because of transient problems. ISO 10589 handles this with an LSP Database Overload condition, defined in section 7.3.19. When an IS is in that condition, it sets a flag called the Overload Bit in the non-pseudonode LSP number Zero it generates. 🚩 Section 7.2.8.1 of ISO 10589 tells the other systems not to use the overloaded IS as a transit router. Why? Because it doesn't have complete info, so it might pick the wrong routes, and routing loops could show up. 🌀 Yikes.

An overloaded router could end up becoming the DIS. An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. ✨

13. Security Considerations 🔐

The clarifications in this document don't bring in any new security concerns, because the underlying protocol described in ISO 10589 [1] hasn't changed at all. 🫶 Nothing new to panic about, but the protocol itself still deserves respect, okay?

14. References 📚

14.1. Normative References

[1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002.

[2] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[4] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.

[5] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.

[6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002.

14.2. Informative References

[7] Parker, J., "Management Information Base for IS-IS", Work in Progress, January 2004.

[8] ITU, "Information technology - Protocol for providing the connectionless-mode network service", ISO/IEC 8473-1, 1998.

15. Acknowledgments 🫶🌸

This document is the work of so many people, and it's basically the distillation of over a thousand mail messages. 📨 Thanks to Vishwas Manral, who pushed to create it. Thanks to Danny McPherson, the original editor, for kicking things off. 🚀 Thanks to Mike Shand for his work creating the protocol, and his uncanny ability to remember what everything is for. 🧠 Thanks to Micah Bartell and Philip Christian, who showed everyone how to document difference without displaying discord. 🕊️ Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, who spent many hours educating the editor. 📖 Thanks to Radia Perlman, who is always ready to explain anything. 💡 Thanks to Satish Dattatri, who was tenacious about seeing things written up correctly. 💪 Thanks to Russ White, whose writing improved the treatment of every topic he touched. ✍️ Thanks to Shankar Vemulapalli, who read several drafts with close attention. 👀 Thanks to Don Goodspeed for his close reading of the text. 🔍 Thanks to Aravind Ravikumar, who pointed out that we should check Source ID on point-to-point IIH packets. 🙌 Thanks to Michael Coyle for identifying the quotation from Jan L.A. van de Snepscheut. 💜 Thanks for Alex Zinin's ministrations behind the scenes. 🪄 Thanks to Tony Li and Tony Przygienda, who kept us on track whenever the discussions veered into the weeds. 🌿 And thanks to everyone who contributed but whose names I have carelessly left off this list. 🥹

16. Author's Address 📮

Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA

EMail: jparker@axiowave.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 📜

This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙃

Intellectual Property

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. For the procedures on rights in RFC documents, see BCP 78 and BCP 79. ⚖️

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from