RFC 6119 PROPOSED STANDARD ROUTING · IS-IS · IPV6

IS-IS IPv6 TE: IPv6 Traffic Engineering in IS-IS

New IS-IS TLVs that let routers advertise traffic engineering information using IPv6 addresses.

RFC EDITOR

Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <https://www.rfc-editor.org/info/rfc6119>.

BIBTEX

@misc{rfc6119,
  series = {Request for Comments},
  number = 6119,
  howpublished = {RFC 6119},
  publisher = {RFC Editor},
  doi = {10.17487/RFC6119},
  url = {https://www.rfc-editor.org/info/rfc6119},
  author = {J. Harrison and J. Berger and M. Bartlett},
  title = {{IPv6 Traffic Engineering in IS-IS}},
  pagetotal = 10,
  year = 2011,
  month = feb,
}

PUBLISHED: February 2011
AUTHORS: J. Harrison, J. Berger, M. Bartlett
STREAM: IETF
IPV6 TE ROUTER ID TLV: Type 140, 16-octet address
IPV6 SRLG TLV: Type 139
IPV6 GLOBAL INTERFACE ADDRESS TLV: Type 233
INTERFACE / NEIGHBOR ADDRESS SUB-TLVS: Types 12 and 13, length 16
SRLG VALUE SIZE: 4 octets each
DOI: 10.17487/RFC6119

RFC text

Contents

Original text · RFC Editor View on rfc-editor.org ↗

Internet Engineering Task Force (IETF)                       J. Harrison
Request for Comments: 6119                                     J. Berger
Category: Standards Track                                    M. Bartlett
ISSN: 2070-1721                                      Metaswitch Networks
                                                           February 2011


                   IPv6 Traffic Engineering in IS-IS

Abstract

   This document specifies a method for exchanging IPv6 traffic
   engineering information using the IS-IS routing protocol.  This
   information enables routers in an IS-IS network to calculate traffic-
   engineered routes using IPv6 addresses.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6119.

Copyright Notice

   Copyright (c) 2011 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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to 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 are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

1.  Overview

   The IS-IS routing protocol is defined in [IS-IS].  Each router
   generates a Link State PDU (LSP) that contains information describing
   the router and the links from the router.  The information in the LSP
   is encoded in a variable length data structure consisting of a Type,
   Length, and Value.  Such a data structure is referred to as a TLV.

   [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow
   Traffic Engineering (TE) information to be disseminated by the IS-IS
   protocol [IS-IS].  The addressing information passed in these TLVs is
   IPv4 specific.

   [IPv6] describes how the IS-IS protocol can be used to carry out
   Shortest Path First (SPF) routing for IPv6.  It does this by defining
   IPv6-specific TLVs that are analogous to the TLVs used by IS-IS for
   carrying IPv4 addressing information.

   Multiprotocol Label Switching (MPLS) traffic engineering is very
   successful, and, as the use of IPv6 grows, there is a need to be able
   to support traffic engineering in IPv6 networks.

   This document defines the TLVs that allow traffic engineering
   information (including Generalized-MPLS (GMPLS) TE information) to be
   carried in IPv6 IS-IS networks.

2.  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 [KEYWORDS].

3.  Summary of Operation

3.1.  Identifying IS-IS Links Using IPv6 Addresses

   Each IS-IS link has certain properties -- bandwidth, shared risk link
   groups (SRLGs), switching capabilities, and so on.  The IS-IS
   extensions defined in [TE] and [GMPLS] describe how to associate
   these traffic engineering parameters with IS-IS links.  These TLVs
   use IPv4 addresses to identify the link (or local/remote link
   identifiers on unnumbered links).

   When IPv6 is used, a numbered link may be identified by IPv4 and/or
   IPv6 interface addresses.  The type of identifier used does not
   affect the properties of the link; it still has the same bandwidth,
   SRLGs, and switching capabilities.

   This document describes an approach for supporting IPv6 traffic
   engineering by defining TLV extensions that allow TE links and nodes
   to be identified by IPv6 addresses.

3.1.1.  IPv6 Address Types

   An IPv6 address can have global, unique-local, or link-local scope.

   -  A global IPv6 address is valid within the scope of the Internet.

   -  A unique-local IPv6 address is globally unique but is intended for
      local communication.

   -  A link-local IPv6 address is valid only within the scope of a
      single link and may only be referenced on that link.

   Because the IPv6 traffic engineering TLVs present in LSPs are
   propagated across networks, they MUST NOT use link-local addresses.

   IS-IS does not need to differentiate between global and unique-local
   addresses.

3.2.  IP Addresses Used in Traffic Engineering TLVs

   This section lists the IP addresses used in the TLVs defined in [TE]
   and [GMPLS] and gives an overview of the required IPv6 equivalents.

3.2.1.  TE Router ID TLV

   The TE Router ID TLV contains a stable IPv4 address that is routable,
   regardless of the state of each interface.

   Similarly, for IPv6, it is useful to have a stable IPv6 address
   identifying a TE node.  The IPv6 TE Router ID TLV is defined in
   Section 4.1.

3.2.2.  IPv4 Interface Address Sub-TLV

   This sub-TLV of the Extended IS Reachability TLV contains an IPv4
   address for the local end of a link.  The equivalent IPv6 Interface
   Address sub-TLV is defined in Section 4.2.

3.2.3.  IPv4 Neighbor Address Sub-TLV

   This sub-TLV of the Extended IS Reachability TLV is used for point-
   to-point links and contains an IPv4 address for the neighbor's end of
   a link.  The equivalent IPv6 Neighbor Address sub-TLV is defined in
   Section 4.3.

   A router constructs the IPv4 Neighbor Address sub-TLV using one of
   the IPv4 addresses received in the IS-IS Hello (IIH) PDU from the
   neighbor on the link.

   The IPv6 Neighbor Address sub-TLV contains a globally unique IPv6
   address for the interface from the peer (which can be either a global
   or unique-local IPv6 address).  The IPv6 Interface Address TLV
   defined in [IPv6] only contains link-local addresses when used in the
   IIH PDU.  Hence, a neighbor's IP address from the IPv6 Interface
   Address TLV cannot be used when constructing the IPv6 Neighbor
   Address sub-TLV.  Instead, we define an additional TLV, the IPv6
   Global Interface Address TLV in Section 4.5.  The IPv6 Global
   Interface Address TLV is included in IIH PDUs to provide the globally
   unique IPv6 address that a neighbor router needs in order to
   construct the IPv6 Neighbor Address sub-TLV.

3.2.4.  IPv4 SRLG TLV

   The SRLG TLV (type 138) defined in [GMPLS] contains the set of SRLGs
   associated with a link.  The SRLG TLV identifies the link using
   either local/remote IPv4 addresses or, for point-to-point unnumbered
   links, link-local/remote identifiers.  The SRLG TLV includes a flags
   field to indicate which type of identifier is used.

   When only IPv6 is used, IPv4 addresses and link-local/remote
   identifiers are not available to identify the link, but IPv6
   addresses can be used instead.

   There is no backward-compatible way to modify the SRLG TLV (type 138)
   to identify the link by IPv6 addresses; therefore, we need a new TLV.

   The IPv6 SRLG TLV is defined in Section 4.4.

4.  IPv6 TE TLVs

4.1.  IPv6 TE Router ID TLV

   The IPv6 TE Router ID TLV is TLV type 140.

   The IPv6 TE Router ID TLV contains a 16-octet IPv6 address.  A stable
   global IPv6 address MUST be used, so that the router ID provides a
   routable address, regardless of the state of a node's interfaces.

   If a router does not implement traffic engineering, it MAY include or
   omit the IPv6 TE Router ID TLV.  If a router implements traffic
   engineering for IPv6, it MUST include this TLV in its LSP.  This TLV
   MUST NOT be included more than once in an LSP.

   An implementation receiving an IPv6 TE Router ID TLV MUST NOT
   consider the router ID as a /128 reachable prefix in the standard SPF
   calculation because this can lead to forwarding loops when
   interacting with systems that do not support this TLV.

4.2.  IPv6 Interface Address Sub-TLV

   The IPv6 Interface Address sub-TLV of the Extended IS Reachability
   TLV has sub-TLV type 12.  It contains a 16-octet IPv6 address for the
   interface described by the containing Extended IS Reachability TLV.
   This sub-TLV can occur multiple times.

   Implementations MUST NOT inject a /128 prefix for the interface
   address into their routing or forwarding table because this can lead
   to forwarding loops when interacting with systems that do not support
   this sub-TLV.

   If a router implements the basic TLV extensions described in [TE], it
   MAY include or omit this sub-TLV.  If a router implements IPv6
   traffic engineering, it MUST include this sub-TLV (except on an
   unnumbered point-to-point link, in which case the Link-Local
   Interface Identifiers sub-TLV is used instead).

   This sub-TLV MUST NOT contain an IPv6 link-local address.

4.3.  IPv6 Neighbor Address sub-TLV

   The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV
   has sub-TLV type 13.  It contains a 16-octet IPv6 address for a
   neighboring router on the link described by the (main) TLV.  This
   sub-TLV can occur multiple times.

   Implementations MUST NOT inject a /128 prefix for the interface
   address into their routing or forwarding table because this can lead
   to forwarding loops when interacting with systems that do not support
   this sub-TLV.

   If a router implements the basic TLV extensions described in [TE], it
   MAY include or omit this sub-TLV.  If a router implements IPv6
   traffic engineering, it MUST include this sub-TLV for point-to-point
   links (except on an unnumbered point-to-point link, in which case the
   Link-Local Interface Identifiers sub-TLV is used instead).

   This sub-TLV MUST NOT contain an IPv6 link-local address.

4.4.  IPv6 SRLG TLV

   The IPv6 SRLG TLV has type 139.  The TLV carries the Shared Risk Link
   Group information (see the "Shared Risk Link Group Information"
   section of [GMPLS-ROUTING]).

   It contains a data structure consisting of the following:

    - 6 octets of System ID
    - 1 octet of pseudonode number
    - 1 octet flags
    - 16 octets of IPv6 interface address
    - (optional) 16 octets of IPv6 neighbor address
    - (variable) list of SRLG values, where each element in the list has
      4 octets

   The following illustrates the encoding of the Value field of the IPv6
   SRLG TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          System ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            System ID (cont.)  | Pseudonode num|    Flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv6 interface address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 interface address (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 interface address (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 interface address (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           (optional) IPv6 neighbor address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 neighbor address (continued)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 neighbor address (continued)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IPv6 neighbor address (continued)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Shared Risk Link Group Value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ............                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Shared Risk Link Group Value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The neighbor is identified by its System ID (6 octets), plus one
   octet to indicate the pseudonode number if the neighbor is on a LAN
   interface.

   The 1-octet flags field is interpreted as follows.

      Flags (1 octet)

         0  1  2  3  4  5  6  7
        +--+--+--+--+--+--+--+--+
        |  Reserved          |NA|
        +--+--+--+--+--+--+--+--+

        NA - Neighbor Address included.

   The flags field currently contains one flag to indicate whether the
   IPv6 neighbor address is included (the NA bit is set to 1) or not
   included (the NA bit is set to 0).

   Other bits in the flags field are reserved for future use.  Any bits
   not understood by an implementation MUST be set to zero by the
   sender.  If a router receives an IPv6 SRLG TLV with non-zero values
   for any bit that it does not understand, it MUST ignore the TLV (in
   other words, it does not use the TLV locally but floods the TLV
   unchanged to neighbors as normal).

   Note that this rule for processing the flags octet allows for future
   extensibility of the IPv6 SRLG TLV.  In particular, it allows
   alternative means of identifying the corresponding link to be added
   in the future.  An implementation that does not understand such an
   extension will ignore the TLV rather than attempt to interpret the
   TLV incorrectly.

   The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if
   the IPv6 neighbor address is included).

   To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP
   from causing confusion of interpretation, the following rules are
   applied.

   -  The IPv6 SRLG TLV MAY occur more than once within the IS-IS
      logical LSP.

   -  There MUST NOT be more than one IPv6 SRLG TLV for a given link.

   -  The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the
      SRLGs for a given link if it is possible to use the SRLG TLV (type
      138).

   -  If both an SRLG TLV and an IPv6 SRLG are received describing the
      SRLGs for the same link, the receiver MUST apply the SRLG TLV and
      ignore the IPv6 SRLG TLV.

   In other words, if SRLGs are to be advertised for a link and if the
   Extended IS Reachability TLV describing a link contains IPv4
   interface/neighbor address sub-TLVs or the link-local identifiers
   sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV (type
   138).

4.5.  IPv6 Global Interface Address TLV

   The IPv6 Global Interface Address TLV is TLV type 233.  The TLV
   structure is identical to that of the IPv6 Interface Address TLV
   defined in [IPv6], but the semantics are different.  In particular,
   the TLV is included in IIH PDUs for those interfaces using IPv6 TE
   extensions.  The TLV contains global or unique-local IPv6 addresses
   assigned to the interface that is sending the Hello.

   The IPv6 Global Interface Address TLV is not used in LSPs.

5.  Security Considerations

   This document raises no new security issues for IS-IS; for general
   security considerations for IS-IS, see [ISIS-AUTH].

6.  IPv4/IPv6 Migration

   The IS-IS extensions described in this document allow the routing of
   GMPLS Label Switched Paths using IPv6 addressing through an IS-IS
   network.  There are no migration issues introduced by the addition of
   this IPv6 TE routing information into an existing IPv4 GMPLS network.
   Migration of Label Switched Paths from IPv4 to IPv6 is an issue for
   GMPLS signaling and is outside the scope of this document.

7.  IANA Considerations

   This document defines the following new IS-IS TLV types that IANA has
   reflected in the IS-IS TLV code-point registry:

          Type        Description              IIH   LSP   SNP
          ----        ----------------------   ---   ---   ---
           139        IPv6 SRLG TLV             n     y     n
           140        IPv6 TE Router ID         n     y     n
           233        IPv6 Global Interface     y     n     n
                      Address TLV

   This document also defines the following new sub-TLV types of top-
   level TLV 22 that IANA has reflected in the Sub-TLVs for TLV 22, 141,
   and 222 registry:

          Type        Description            22  141  222  Length
          ----        -----------            --  ---  ---  ------
            12        IPv6 Interface Address  y   y    y       16
            13        IPv6 Neighbor Address   y   y    y       16

8.  Normative References

   [IS-IS]     ISO, "Intermediate System to Intermediate System intra-
               domain routeing information exchange protocol for use in
               conjunction with the protocol for providing the
               connectionless-mode network service (ISO 8473)",
               International Standard 10589: 2002, Second Edition, 2002.

   [IPv6]      Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
               2008.

   [TE]        Li, T. and H. Smit, "IS-IS Extensions for Traffic
               Engineering", RFC 5305, October 2008.

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

   [ISIS-AUTH] Li, T. and R. Atkinson, "IS-IS Cryptographic
               Authentication", RFC 5304, October 2008.

   [GMPLS]     Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
               in Support of Generalized Multi-Protocol Label Switching
               (GMPLS)", RFC 5307, October 2008.

   [GMPLS-ROUTING]
               Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
               Extensions in Support of Generalized Multi-Protocol Label
               Switching (GMPLS)", RFC 4202, October 2005.

Authors' Addresses

   Jon Harrison
   Metaswitch Networks
   100 Church Street
   Enfield
   EN2 6BQ
   U.K.
   Phone: +44 20 8366 1177
   EMail: jon.harrison@metaswitch.com

   Jon Berger
   Metaswitch Networks
   100 Church Street
   Enfield
   EN2 6BQ
   U.K.
   Phone: +44 20 8366 1177
   EMail: jon.berger@metaswitch.com

   Mike Bartlett
   Metaswitch Networks
   100 Church Street
   Enfield
   EN2 6BQ
   U.K.
   Phone: +44 20 8366 1177
   EMail: mike.bartlett@metaswitch.com

AI ELI5

On this page

PROBLEMThe IS-IS traffic engineering TLVs identify routers and links with IPv4 addresses, so they cannot describe traffic-engineered links in IPv6 networks.

MECHANISMThe RFC defines IPv6 equivalents: an IPv6 TE Router ID TLV (type 140), IPv6 Interface Address and Neighbor Address sub-TLVs (types 12 and 13), an IPv6 SRLG TLV (type 139) and an IPv6 Global Interface Address TLV (type 233).

WHY IT MATTERSRouters in an IS-IS network can carry traffic engineering information, including GMPLS information, for IPv6 and calculate traffic-engineered routes with IPv6 addresses. The RFC is a Proposed Standard.

§1Why IS-IS Needs IPv6 TE TLVs

In IS-IS, each router generates a Link State PDU (LSP) describing itself and its links. The information is encoded as TLVs (Type, Length, Value). RFC 5305 and RFC 5307 define TLVs and sub-TLVs that carry traffic engineering (TE) and GMPLS information, but the addressing in them is IPv4 specific.

RFC 5308 shows how IS-IS can run Shortest Path First routing for IPv6 with IPv6-specific TLVs. This document does the same job for traffic engineering. As the RFC puts it, MPLS traffic engineering is very successful, and as IPv6 use grows there is a need to support it in IPv6 networks.

The old maps could only name roads using the old address style. This document adds a way to name them with the new address style.

§3Identifying Links with IPv6 Addresses

A link has properties such as bandwidth, shared risk link groups (SRLGs) and switching capabilities. When IPv6 is used, a numbered link may be identified by IPv4 and/or IPv6 interface addresses. The kind of identifier does not change the link's properties.

An IPv6 address can have global, unique-local or link-local scope. Because the IPv6 TE TLVs are propagated across networks, they MUST NOT use link-local addresses. IS-IS does not need to tell global and unique-local addresses apart.

Each IPv4 address used in the existing TE TLVs gets an IPv6 counterpart: the TE Router ID TLV, the Interface Address and Neighbor Address sub-TLVs, and the SRLG TLV.

Every road gets a name that works everywhere in the city, not a nickname that only makes sense on one street.

§4The Router ID and Address TLVs

The IPv6 TE Router ID TLV is type 140 and holds a 16-octet IPv6 address. It must be a stable global address, so the router ID stays routable whatever state the node's interfaces are in. A router that implements IPv6 TE MUST include it in its LSP, and it MUST NOT appear more than once in an LSP.

Two sub-TLVs of the Extended IS Reachability TLV carry link addresses. The IPv6 Interface Address sub-TLV is type 12 and the IPv6 Neighbor Address sub-TLV is type 13. Both hold a 16-octet address, can occur multiple times, and MUST NOT hold a link-local address. A router that implements IPv6 TE MUST include them, except on an unnumbered point-to-point link, where the Link-Local Interface Identifiers sub-TLV is used instead. The Neighbor Address sub-TLV is required for point-to-point links.

Receivers MUST NOT treat the router ID, or the interface addresses, as a /128 reachable prefix in routing or forwarding. Doing so can cause forwarding loops when interacting with systems that do not support these TLVs.

To learn the neighbor's global address, the RFC adds the IPv6 Global Interface Address TLV, type 233. It goes in IIH (Hello) PDUs, never in LSPs, and carries the global or unique-local addresses of the interface sending the Hello. This is needed because the IPv6 Interface Address TLV from RFC 5308 only holds link-local addresses in a Hello.

Each router gets a permanent name tag, and each road gets a label on both ends. Routers also say hello with their city-wide address so neighbors can write it down.

§5The IPv6 SRLG TLV

Links that would fail together, such as fibers in the same duct, share a risk. The IPv6 SRLG TLV (type 139) carries Shared Risk Link Group information. The older SRLG TLV (type 138) cannot be extended backward-compatibly to name a link by IPv6 addresses, so a new TLV was needed.

Its value holds a 6-octet System ID, 1 octet of pseudonode number, 1 octet of flags, a 16-octet IPv6 interface address, an optional 16-octet IPv6 neighbor address, and a list of 4-octet SRLG values. The length is 24 + 4 * (number of SRLG values), plus 16 if the neighbor address is included.

The flags octet has one defined bit, NA, which says whether the neighbor address is present. Unknown bits MUST be sent as zero. A receiver that sees a non-zero bit it does not understand MUST ignore the TLV, but still floods it unchanged. This leaves room for future ways of identifying a link.

To avoid confusion with type 138: the IPv6 SRLG TLV may occur more than once in an LSP, but there MUST NOT be more than one for a given link. It MUST NOT be used if the link can be described with the type 138 TLV, and if a receiver gets both for the same link it MUST apply the type 138 TLV and ignore the IPv6 one.

Some roads run through the same tunnel, so one landslide would block them all. This tells everyone which roads share a tunnel, using the new address style.

VALUE FIELD OF THE IPV6 SRLG TLV (RFC 6119)

081624

SYSTEM-ID SYSTEM-ID (cont.)PSEUDONODE FLAGS IFACE-ADDR IFACE-ADDR (cont.)IFACE-ADDR (cont.)IFACE-ADDR (cont.)NEIGHBOR-ADDR NEIGHBOR-ADDR (cont.)NEIGHBOR-ADDR (cont.)NEIGHBOR-ADDR (cont.)SRLG

IPv6 SRLG TLV value
Field	Name	Size	Description
`SYSTEM-ID`	System ID	6 bytes	Identifies the neighbor.
`PSEUDONODE`	Pseudonode num	1 byte	Pseudonode number if the neighbor is on a LAN interface.
`FLAGS`	Flags	1 byte	NA bit set to 1 when the neighbor address is included.
`IFACE-ADDR`	IPv6 interface address	16 bytes	16 octets.
`NEIGHBOR-ADDR`	IPv6 neighbor address (optional)	16 bytes	16 octets, present when NA is set.
`SRLG`	Shared Risk Link Group Value	4 bytes	Repeated, one per SRLG.

§6Security and Migration

The RFC says it raises no new security issues for IS-IS. For general IS-IS security it points to RFC 5304, which covers IS-IS cryptographic authentication.

On migration, the extensions allow routing of GMPLS Label Switched Paths using IPv6 addressing through an IS-IS network. Adding this IPv6 TE routing information to an existing IPv4 GMPLS network causes no migration issues. Moving Label Switched Paths from IPv4 to IPv6 is a GMPLS signaling matter and out of scope.

Nothing here makes the mail system less safe, and adding the new labels does not break the old ones.

§7Registered Code Points

IANA registered three new IS-IS TLV types: 139 (IPv6 SRLG, used in LSPs), 140 (IPv6 TE Router ID, used in LSPs) and 233 (IPv6 Global Interface Address, used in IIH PDUs). None of them are used in SNPs.

IANA also registered two new sub-TLVs of TLV 22: type 12 (IPv6 Interface Address) and type 13 (IPv6 Neighbor Address), each with length 16. They are also valid under TLVs 141 and 222.

Each new label got its own official number so every router reads it the same way.

NEW TLV AND SUB-TLV TYPES (RFC 6119)

139IPv6 SRLG TLV — LSPs only.
140IPv6 TE Router ID TLV — LSPs only.
233IPv6 Global Interface Address TLV — IIH PDUs only.
12IPv6 Interface Address sub-TLV — Sub-TLV of TLV 22; length 16.
13IPv6 Neighbor Address sub-TLV — Sub-TLV of TLV 22; length 16.

§7References

[IPv6]RFC 5308Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.October 2008 [TE]RFC 5305Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.October 2008 [ISIS-AUTH]RFC 5304Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.October 2008 [GMPLS]RFC 5307Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.October 2008 [GMPLS-ROUTING]RFC 4202Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.October 2005 [KEYWORDS]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997