RFC 7794

IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability

📅 published March 2016, from ietf

RFC 7794: IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability 🎀

Okay bestie, so this one is RFC 7794 from the IETF (Internet Engineering Task Force) 🌈 The title is IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability. It's a Standards Track doc (so it's a real, official standard, no cap 💅) and it's dated March 2016, with ISSN 2070-1721.

Five authors worked on it. L. Ginsberg (Ed., so the editor) is from Cisco Systems, B. Decraene is from Orange, S. Previdi is also from Cisco Systems, X. Xu is from Huawei, and U. Chunduri is from Ericsson 🫶 The title block doesn't list anything it obsoletes or updates.

Abstract ✨

Okay so this doc adds new sub-TLVs (little add-on chunks that live inside the TLVs) so routers can advertise IPv4 and IPv6 prefix attribute flags, plus the source router ID of whichever router originally made a prefix advertisement. Main character energy 👑

Status of This Memo 📜

This is an Internet Standards Track document.

Lowkey the official stamp: this is an IETF product, the IETF community agreed on it, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want the background on Internet Standards, check out Section 2 of RFC 5741. For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7794 🔥

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🙏

Table of Contents 📑

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  New Sub-TLVs for Extended Reachability TLVs . . . . . . . . .   3
     2.1.  IPv4/IPv6 Extended Reachability Attribute Flags . . . . .   4
     2.2.  IPv4/IPv6 Source Router ID  . . . . . . . . . . . . . . .   5
     2.3.  Advertising Router IDs  . . . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🧚

IS-IS is a link-state routing protocol defined in [ISO10589] and [RFC1195]. Extensions for advertising new forms of IPv4/IPv6 prefix reachability are defined in [RFC5305], [RFC5308], and [RFC5120].

There are already real use cases where knowing extra attributes of a prefix is useful ✨

It's useful to know whether or not an advertised prefix is directly connected to the advertising router. With Segment Routing, as described in [SR], knowing that decides what action should be taken when processing the labels on an incoming packet. It's giving precision 🎯

It's also useful to know which addresses can be used as addresses of the node to support services, like a Remote Loop Free Alternate (RLFA) endpoint 🦋

Here's the tea: the current formats of the Extended Reachability TLVs for both IPv4 and IPv6 are fixed. They don't allow adding more flags without causing backwards compatibility issues 😭 So this document defines a new sub-TLV that advertises attribute flags associated with prefix advertisements.

When a router advertises several node addresses, it's also useful to tie all of them to a single Router ID, even when the prefixes get advertised outside the area where they started. So a new sub-TLV is introduced to advertise the Router ID of the originator of a prefix advertisement 💜

1.1. Requirements Language 🎀

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. New Sub-TLVs for Extended Reachability TLVs 🌸

Three new sub-TLVs are introduced:

  • Prefix Attribute Flags
  • IPv4 Source Router ID
  • IPv6 Source Router ID

All sub-TLVs are applicable to TLVs 135, 235, 236, and 237.

2.1. IPv4/IPv6 Extended Reachability Attribute Flags 🚩

This sub-TLV is how routers advertise extra flags for a given prefix advertisement. The behaviour of each flag when a prefix advertisement gets leaked from one level to another (upwards or downwards) is explicitly defined below 👀

All flags are applicable to TLVs 135, 235, 236, and 237, unless otherwise stated.

     Prefix Attribute Flags
     Type:   4
     Length: Number of octets of the Value field.
     Value:

          (Length * 8) bits.

       0 1 2 3 4 5 6 7...
      +-+-+-+-+-+-+-+-+...
      |X|R|N|          ...
      +-+-+-+-+-+-+-+-+...

Bits get defined and sent starting with Bit 0, which is defined below. Any additional bit definitions that get added in the future SHOULD be assigned in ascending bit order, so that as few bits as possible need to be transmitted 🧠

Undefined bits MUST be transmitted as 0 and MUST be ignored on receipt. ✅

Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.

X-Flag: External Prefix Flag (Bit 0) 🌍 Set when the prefix has been redistributed from another protocol. That includes the case where multiple virtual routers are supported and the redistributed prefix's source is another IS-IS instance.

The flag MUST be preserved when leaked between levels.

In TLVs 236 and 237, this flag SHOULD always be sent as 0 and MUST be ignored on receipt. The reason is that these TLVs already have an existing X flag in their fixed format, as specified in [RFC5308] and [RFC5120] 🙈

R-Flag: Re-advertisement Flag (Bit 1) 🔁 Set when the prefix has been leaked from one level to another (upwards or downwards).

N-flag: Node Flag (Bit 2) 🪞 Set when the prefix identifies the advertising router. In other words, the prefix is a host prefix advertising a globally reachable address, typically associated with a loopback address.

The advertising router MAY choose not to set this flag, even when the above conditions are met.

If the flag is set and the prefix length is not a host prefix (/32 for IPV4, /128 for IPv6), then the flag MUST be ignored. The flag MUST be preserved when leaked between levels.

2.2. IPv4/IPv6 Source Router ID 🆔

When a reachability advertisement is leaked from one level to another, the source of the original advertisement is unknown. If the advertisement identifies the advertising router (for example, with the N-flag set in the Prefix Attribute Flags sub-TLV, as described in Section 2.1), it can be useful for other routers to know where the advertisement came from. The sub-TLVs defined below provide that info 💖

Note that the Router ID advertised is always the Router ID of the IS-IS instance that originated the advertisement. That stays true even if the prefix was learned from another protocol (in other words, with the X-flag set, as defined in Section 2.1).

     IPv4 Source Router ID
     Type:   11
     Length: 4
     Value:  IPv4 Router ID of the source of the advertisement

Inclusion of this TLV is optional and MAY occur in TLVs 135, 235, 236, or 237. When it's included, the value MUST be identical to the value advertised in the Traffic Engineering router ID (TLV 134) defined in [RFC5305].

If it's present, the sub-TLV MUST be included when the prefix advertisement is leaked to another level.

     IPv6 Source Router ID
     Type:   12
     Length: 16
     Value: IPv6 Router ID of the source of the advertisement

Inclusion of this TLV is optional and MAY occur in TLVs 135, 235, 236, or 237. When it's included, the value MUST be identical to the value advertised in the IPv6 TE Router ID (TLV 140) defined in [RFC6119].

If it's present, the sub-TLV MUST be included when the prefix advertisement is leaked to another level.

2.3. Advertising Router IDs 📣

[RFC5305] and [RFC6119] define how router IDs get advertised for IPv4 and IPv6, respectively. Both documents talk about router IDs in the context of Traffic Engineering (TE), but advertising router IDs is explicitly allowed for purposes other than TE. Using router IDs to identify the source of a prefix advertisement, as defined in Section 2.2, is one such use case 🌟

So, whenever an IPv4 or IPv6 Source Router ID sub-TLV (as defined in Section 2.2) is used, the originating router SHOULD also advertise the matching address-family-specific router ID TLV. 🫶

5.1. Normative References 📚✨

Okay bestie, these are the normative refs 🫶 basically the docs this one leans on the hardest, so they're kinda the foundation of the whole thing 💅

5.2. Informative References 🦋

These ones are the extra reading 🌸 they're helpful background, but this doc isn't leaning on them the same way.

  • [SR] Previdi, S., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-06, December 2015.

Contributors 🎀

Okay, shoutout to these people, who gave a substantial contribution to the content of this document 🫶✨

Clarence Filsfils
Cisco Systems

Email: cf@cisco.com


Stephane Litkowski
Orange Business Service

Email: stephane.litkowski@orange.com

Authors' Addresses 💜

And here are the authors and how to reach them 💌 Iconic squad, honestly 👑

Les Ginsberg (editor)
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA  95035
United States

Email: ginsberg@cisco.com


Bruno Decraene
Orange
38 rue du General Leclerc
Issy Moulineaux cedex 9  92794
France

Email: bruno.decraene@orange.com


Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome  0144
Italy

Email: sprevidi@cisco.com


Xiaohu Xu
Huawei

Email: xuxiaohu@huawei.com


Uma Chunduri
Ericsson

Email: uma.chunduri@ericsson.com
📦 where this page comes from