RFC 5308

(part 1 of 2 💖)

Routing IPv6 with IS-IS 🦋

okay bestie, the title block is giving: this is RFC 5308, "Routing IPv6 with IS-IS" 🎀 It's from the Network Working Group, written by C. Hopps (Christian E. Hopps) at Cisco Systems. It's a Standards Track doc, dated October 2008. The title block doesn't list anything it obsoletes or updates ✨

Status of This Memo

this one is an Internet standards track protocol for the whole Internet community, and it's asking for discussion and suggestions for improvements 🫶 for where it stands in standardization, go check the current edition of "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 💅

Abstract

the big idea 🔥 this doc describes how to swap IPv6 routing info using the IS-IS routing protocol. it uses two new TLVs, a reachability TLV and an interface address TLV, to spread the IPv6 info around a whole routing domain. the iconic part is that you can route IPv6 alongside IPv4 and OSI with one single intra-domain routing protocol 👑

1. Overview ✨

okay so IS-IS is an extendible intra-domain routing protocol 🧚 every router in the routing domain issues a Link State Protocol Data Unit (LSP) with info about that router itself. the LSP carries typed variable-length data, which people call TLVs (type-length-values). this doc extends the protocol with two new TLVs to carry the stuff you need for IPv6 routing 💜

[RFC1195] describes a method for routing both OSI and IPv4. we reuse that same method with some small changes so it works for IPv6 🌸 to pull that off we define two new TLVs, "IPv6 Reachability" and "IPv6 Interface Address", plus a brand new IPv6 protocol identifier. the new TLVs also use the extended metrics and up/down semantics from [RFC5305], which is so clean 😭

1.1. Requirements Language

this is the bit where the key words get their official meaning 🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. IPv6 Reachability TLV 🌈

the "IPv6 Reachability" TLV is TLV type 236 (0xEC) 🍓

[RFC1195] defines two Reachability TLVs, "IP Internal Reachability Information" and "IP External Reachability Information". this doc gives you the same data for IPv6 using the "IPv6 Reachability" TLV plus an "external" bit ✨

this TLV describes network reachability by spelling out a routing prefix, metric info, a bit that says whether the prefix is being advertised down from a higher level, a bit that says whether the prefix came in from another routing protocol, and OPTIONALLY the presence of Sub-TLVs so it can be extended later 🦋 here's the structure:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 236   |    Length     |          Metric ..            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          .. Metric            |U|X|S| Reserve |  Prefix Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prefix ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sub-TLV Len(*) | Sub-TLVs(*) ...
   * - if present

   U - up/down bit
   X - external original bit
   S - subtlv present bit

the IPv6 Reachability TLV MAY appear any number of times (including none) within an LSP 🫶 and link-local prefixes MUST NOT be advertised using this TLV 🙈 the original exact wording is "The above IPv6 Reachability TLV MAY appear any number of times (including none) within an LSP. Link-local prefixes MUST NOT be advertised using this TLV." lol so no link-locals here

the up/down bit comes straight from [RFC5305], which says:

"The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit SHALL be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels"

if the prefix got distributed into IS-IS from another routing protocol, the external bit SHALL be set to 1 🌸 this is super useful when you're pushing prefixes from IS-IS out to other protocols

if the Sub-TLV bit is set to 0, then the octets of Sub-TLVs are not present 💖 otherwise the bit is 1, and the octet right after the prefix holds the length of the Sub-TLV portion of the structure

the prefix is "packed" in the data structure, so only the number of prefix octets you actually need get sent 🧚 you can work that number out from the prefix length octet like this:

prefix octets = integer of ((prefix length + 7) / 8)

just like in [RFC5305], if a prefix is advertised with a metric bigger than MAX_V6_PATH_METRIC (0xFE000000), that prefix MUST not be considered during the normal Shortest Path First (SPF) computation 💅 this lets you advertise a prefix for stuff other than building the normal IPv6 routing table, which is lowkey genius

if Sub-TLVs are present, they look just like normal TLVs 👑

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |         Value(*) ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * - if present

Length tells you how many octets of value are present, and it can be 0 ✨

3. IPv6 Interface Address TLV 🎀

the "IPv6 Interface Address" TLV is TLV type 232 (0xE8) 💜

TLV 232 maps directly onto the "IP Interface Address" TLV in [RFC1195] 🦋 the contents do change, though: instead of 0-63 4-octet IPv4 interface addresses, it holds 0-15 16-octet IPv6 interface addresses 🌈

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 232   |    Length     |   Interface Address 1(*) ..   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Interface Address 1(*) ..   |   Interface Address 2(*) ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * - if present

the meaning gets tighter depending on where the TLV is advertised 🔥 in Hello PDUs, the "Interface Address" TLV MUST contain only the link-local IPv6 addresses assigned to the interface that is sending the Hello 💅 in LSPs, the "Interface Address" TLVs MUST contain only the non-link-local IPv6 addresses assigned to the IS 🫶

4. IPv6 NLPID 🍓

the IPv6 Network Layer Protocol ID (NLPID) is 142 (0x8E) 🧚

same as with [RFC1195] and IPv4: if the IS supports IPv6 routing using IS-IS, it MUST advertise this in the "NLPID" TLV by adding the IPv6 NLPID 💖

5. Operation ⭐

this section reuses the same changes to [RFC1195] that [RFC5305] made for processing prefix information 🌸 both of those changes are about the SPF calculation

the metric space got extended, so we have to redefine MAX_PATH_METRIC (1023) from the original spec in [RFC1195] 🫶 the new value, MAX_V6_PATH_METRIC, is the same as in [RFC5305] (0xFE000000). if a path metric would go over MAX_V6_PATH_METRIC during the SPF, it SHALL be considered to be MAX_V6_PATH_METRIC 🔥

the order of preference between paths for a given prefix MUST be modified to consider the up/down bit 👑 the new order of preference goes from best to worst like this:

1. Level 1 up prefix
2. Level 2 up prefix
3. Level 2 down prefix
4. Level 1 down prefix

if multiple paths tie on the best preference, the selection happens based on metric 💜 any leftover multiple paths SHOULD be considered for equal-cost multi-path routing if the router supports it 🦋 otherwise the router can select any one of the multiple paths ✨

part 2 picks up with Section 6 (IANA Considerations) 🎀

Intellectual Property ✨

okay so the IETF is taking zero position on whether any intellectual property rights that might be claimed over the tech in this doc are valid, or how far they reach 🙈 it's also not saying whether any licenses are even available, and it hasn't gone hunting for rights on its own either 💅 if you want the rules on rights for RFC docs, check out BCP 78 and BCP 79 🫶

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that'll be made available, or the results of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗

and the IETF is literally inviting anyone who knows about any copyrights, patents or patent applications, or other proprietary rights that might cover tech needed to implement this standard to speak up 📣 send that info to the IETF at ietf-ipr@ietf.org 💌 main character energy for whoever's got the receipts 💜