doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6119.txt b/doc/rfc/rfc6119.txt
new file mode 100644
index 0000000..991b47a
--- /dev/null
+++ b/doc/rfc/rfc6119.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 1]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+   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].
+
+
+
+
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 2]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+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.
+
+
+
+
+
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 3]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+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.
+
+
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 4]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+   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.
+
+
+
+Harrison, et al.             Standards Track                    [Page 5]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 6]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+    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).
+
+
+
+Harrison, et al.             Standards Track                    [Page 7]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+   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.
+
+
+
+Harrison, et al.             Standards Track                    [Page 8]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+   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.
+
+
+
+
+Harrison, et al.             Standards Track                    [Page 9]
+
+RFC 6119            IPv6 Traffic Engineering in IS-IS      February 2011
+
+
+   [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
+
+
+
+
+
+Harrison, et al.             Standards Track                   [Page 10]
+