summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7794.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7794.txt')
-rw-r--r--doc/rfc/rfc7794.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7794.txt b/doc/rfc/rfc7794.txt
new file mode 100644
index 0000000..65e0a1a
--- /dev/null
+++ b/doc/rfc/rfc7794.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Ginsberg, Ed.
+Request for Comments: 7794 Cisco Systems
+Category: Standards Track B. Decraene
+ISSN: 2070-1721 Orange
+ S. Previdi
+ Cisco Systems
+ X. Xu
+ Huawei
+ U. Chunduri
+ Ericsson
+ March 2016
+
+
+ IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability
+
+Abstract
+
+ This document introduces new sub-TLVs to support advertisement of
+ IPv4 and IPv6 prefix attribute flags and the source router ID of the
+ router that originated a prefix advertisement.
+
+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/rfc7794.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 1]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+Copyright Notice
+
+ 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) 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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 2]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+1. Introduction
+
+ IS-IS is a link-state routing protocol defined in [ISO10589] and
+ [RFC1195]. Extensions in support of advertising new forms of
+ IPv4/IPv6 prefix reachability are defined in [RFC5305], [RFC5308],
+ and [RFC5120].
+
+ There are existing use cases in which knowing additional attributes
+ of a prefix is useful.
+
+ It is useful to know whether or not an advertised prefix is directly
+ connected to the advertising router. In the case of Segment Routing
+ as described in [SR], knowing whether or not a prefix is directly
+ connected determines what action should be taken as regards
+ processing of labels associated with an incoming packet.
+
+ It is useful to know what addresses can be used as addresses of the
+ node in support of services (e.g., Remote Loop Free Alternate (RLFA)
+ endpoint).
+
+ Current formats of the Extended Reachability TLVs for both IPv4 and
+ IPv6 are fixed and do not allow the introduction of additional flags
+ without backwards compatibility issues. Therefore, this document
+ defines a new sub-TLV that supports the advertisement of attribute
+ flags associated with prefix advertisements.
+
+ In cases where multiple node addresses are advertised by a given
+ router, it is also useful to be able to associate all of these
+ addresses with a single Router ID even when prefixes are advertised
+ outside of the area in which they originated. Therefore, 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
+
+ The following new sub-TLVs are introduced:
+
+ o Prefix Attribute Flags
+
+ o IPv4 Source Router ID
+
+ o IPv6 Source Router ID
+
+
+
+Ginsberg, et al. Standards Track [Page 3]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+ All sub-TLVs are applicable to TLVs 135, 235, 236, and 237.
+
+2.1. IPv4/IPv6 Extended Reachability Attribute Flags
+
+ This sub-TLV supports the advertisement of additional flags
+ associated with a given prefix advertisement. The behavior of each
+ flag when a prefix advertisement is 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 are defined/sent starting with Bit 0 defined below. Additional
+ bit definitions that may be defined in the future SHOULD be assigned
+ in ascending bit order so as to minimize the number of bits that will
+ 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 if the prefix has been redistributed from another protocol.
+ This includes the case where multiple virtual routers are
+ supported and the source of the redistributed prefix 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. This is because there is an existing X
+ flag defined in the fixed format of these TLVs as specified in
+ [RFC5308] and [RFC5120].
+
+
+
+
+Ginsberg, et al. Standards Track [Page 4]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+ 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, i.e., the
+ prefix is a host prefix advertising a globally reachable address
+ typically associated with a loopback address.
+
+ The advertising router MAY choose to NOT 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. In
+ cases where the advertisement is an identifier for the advertising
+ router (e.g., with the N-flag set in the Prefix Attribute Flags sub-
+ TLV as described in Section 2.1), it may be useful for other routers
+ to know the source of the advertisement. The sub-TLVs defined below
+ provide that information.
+
+ Note that the Router ID advertised is always the Router ID of the
+ IS-IS instance that originated the advertisement. This would be true
+ even if the prefix had been learned from another protocol (i.e., 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 included, the value MUST be identical to the value
+ advertised in the Traffic Engineering router ID (TLV 134) defined in
+ [RFC5305].
+
+ If 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
+
+
+
+Ginsberg, et al. Standards Track [Page 5]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+ Inclusion of this TLV is optional and MAY occur in TLVs 135, 235,
+ 236, or 237. When included, the value MUST be identical to the value
+ advertised in the IPv6 TE Router ID (TLV 140) defined in [RFC6119].
+
+ If 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 the advertisement of router IDs for
+ IPv4 and IPv6, respectively. Although both documents discuss the use
+ of router ID in the context of Traffic Engineering (TE), the
+ advertisement of router IDs is explicitly allowed for purposes other
+ than TE. The use of router IDs to identify the source of a prefix
+ advertisement as defined in Section 2.2 is one such use case.
+ Therefore, 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 corresponding address-family-specific router ID TLV.
+
+3. IANA Considerations
+
+ This document adds the following new sub-TLVs to the registry of sub-
+ TLVs for TLVs 135, 235, 236, and 237.
+
+ Value: 4
+ Name: Prefix Attribute Flags
+
+ Value: 11
+ Name: IPv4 Source Router ID
+
+ Value: 12
+ Name: IPv6 Source Router ID
+
+ This document also introduces a new registry for bit values in the
+ Prefix Attribute Flags sub-TLV. The registration policy is Expert
+ Review as defined in [RFC5226]. This registry is part of the "IS-IS
+ TLV Codepoints" registry. The name of the registry is "Bit Values
+ for Prefix Attribute Flags Sub-TLV". The defined values are:
+
+ Bit # Name
+ ----- ------------------------------
+ 0 External Prefix Flag (X-flag)
+ 1 Re-advertisement Flag (R-flag)
+ 2 Node Flag (N-flag)
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 6]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+4. Security Considerations
+
+ Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
+
+ Advertisement of the additional information defined in this document
+ introduces no new security concerns.
+
+5. References
+
+5.1. Normative References
+
+ [ISO10589] International Organization for Standardization,
+ "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)",
+ ISO/IEC 10589:2002, Second Edition, Nov. 2002.
+
+ [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+ dual environments", RFC 1195, DOI 10.17487/RFC1195,
+ December 1990, <http://www.rfc-editor.org/info/rfc1195>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
+ Topology (MT) Routing in Intermediate System to
+ Intermediate Systems (IS-ISs)", RFC 5120,
+ DOI 10.17487/RFC5120, February 2008,
+ <http://www.rfc-editor.org/info/rfc5120>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
+ Authentication", RFC 5304, DOI 10.17487/RFC5304, October
+ 2008, <http://www.rfc-editor.org/info/rfc5304>.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, DOI 10.17487/RFC5305, October
+ 2008, <http://www.rfc-editor.org/info/rfc5305>.
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 7]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+ [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
+ DOI 10.17487/RFC5308, October 2008,
+ <http://www.rfc-editor.org/info/rfc5308>.
+
+ [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+ and M. Fanto, "IS-IS Generic Cryptographic
+ Authentication", RFC 5310, DOI 10.17487/RFC5310, February
+ 2009, <http://www.rfc-editor.org/info/rfc5310>.
+
+ [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
+ Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
+ February 2011, <http://www.rfc-editor.org/info/rfc6119>.
+
+5.2. Informative References
+
+ [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
+
+ The following people 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 8]
+
+RFC 7794 IS-IS Prefix Attributes March 2016
+
+
+Authors' Addresses
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 9]
+