[要約] RFC 7794は、IS-ISプロトコルにおける拡張IPv4およびIPv6到達性のためのプレフィックス属性に関する情報を提供しています。このRFCの目的は、IS-ISネットワークでの拡張IPアドレスのルーティングをサポートするためのプレフィックス属性の定義と使用方法を提供することです。
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
拡張IPv4およびIPv6到達可能性のIS-ISプレフィックス属性
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.
このドキュメントでは、IPv4およびIPv6プレフィックス属性フラグのアドバタイズと、プレフィックスアドバタイズを発信したルータのソースルータIDをサポートする新しいサブTLVを紹介します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7794で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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].
IS-ISは、[ISO10589]および[RFC1195]で定義されたリンクステートルーティングプロトコルです。 IPv4 / IPv6プレフィックス到達可能性の新しい形式のアドバタイズをサポートする拡張機能は、[RFC5305]、[RFC5308]、および[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.
アドバタイズされたプレフィックスがアドバタイズルータに直接接続されているかどうかを知ることは有用です。 [SR]で説明されているセグメントルーティングの場合、プレフィックスが直接接続されているかどうかがわかると、着信パケットに関連付けられたラベルの処理に関してどのようなアクションを実行する必要があるかが決まります。
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).
サービス（リモートループフリーオルタネート（RLFA）エンドポイントなど）をサポートするノードのアドレスとして使用できるアドレスを知ることは有用です。
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.
IPv4とIPv6の両方の拡張到達可能性TLVの現在の形式は修正されており、下位互換性の問題なしに追加のフラグを導入することはできません。したがって、このドキュメントでは、プレフィックスアドバタイズに関連付けられた属性フラグのアドバタイズをサポートする新しいサブTLVを定義しています。
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.
特定のルーターによって複数のノードアドレスがアドバタイズされる場合、プレフィックスが発信元のエリア外でアドバタイズされた場合でも、これらすべてのアドレスを単一のルーターIDに関連付けることができると便利です。したがって、プレフィックスアドバタイズメントの発信者のルータIDをアドバタイズするために、新しいサブTLVが導入されています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The following new sub-TLVs are introduced:
次の新しいサブTLVが導入されました。
o Prefix Attribute Flags
o プレフィックス属性フラグ
o IPv4 Source Router ID
o IPv4ソースルーターID
o IPv6 Source Router ID All sub-TLVs are applicable to TLVs 135, 235, 236, and 237.
o IPv6ソースルーターIDすべてのサブTLVは、TLV 135、235、236、および237に適用されます。
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.
このサブTLVは、特定のプレフィックスアドバタイズに関連付けられた追加フラグのアドバタイズをサポートします。プレフィックスアドバタイズメントがあるレベルから別のレベルに（上向きまたは下向きに）リークされるときの各フラグの動作は、以下で明示的に定義されています。
All flags are applicable to TLVs 135, 235, 236, and 237, unless otherwise stated.
特に明記しない限り、すべてのフラグはTLV 135、235、236、および237に適用されます。
Prefix Attribute Flags Type: 4 Length: Number of octets of the Value field. Value:
プレフィックス属性フラグタイプ：4長さ：値フィールドのオクテット数。値：
(Length * 8) bits.
（長さ* 8）ビット。
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.
ビットは以下で定義されているビット0から定義/送信されます。将来的に定義される可能性のある追加のビット定義は、送信する必要のあるビット数を最小限に抑えるために、昇順のビット順に割り当てる必要があります（SHOULD）。
Undefined bits MUST be transmitted as 0 and MUST be ignored on receipt.
未定義のビットは0として送信する必要があり、受信時に無視する必要があります。
Bits that are NOT transmitted MUST be treated as if they are set to 0 on receipt.
送信されないビットは、受信時に0に設定されているかのように処理する必要があります。
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.
Xフラグ：外部プレフィックスフラグ（ビット0）プレフィックスが別のプロトコルから再配布された場合に設定されます。これには、複数の仮想ルーターがサポートされ、再配布されたプレフィックスのソースが別のIS-ISインスタンスである場合が含まれます。
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].
TLV 236および237では、このフラグは常に0として送信する必要があり（SHOULD）、受信時に無視する必要があります。これは、[RFC5308]と[RFC5120]で指定されているように、これらのTLVの固定形式で定義された既存のXフラグがあるためです。
R-Flag: Re-advertisement Flag (Bit 1) Set when the prefix has been leaked from one level to another (upwards or downwards).
Rフラグ：再広告フラグ（ビット1）接頭辞があるレベルから別のレベルに（上方または下方に）リークされたときに設定されます。
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.
Nフラグ：ノードフラグ（ビット2）プレフィックスがアドバタイジングルーターを識別するときに設定されます。つまり、プレフィックスは、通常ループバックアドレスに関連付けられているグローバルに到達可能なアドレスをアドバタイズするホストプレフィックスです。
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.
フラグが設定されていて、プレフィックス長がホストプレフィックスでない場合（IPV4の場合は/ 32、IPv6の場合は/ 128）、フラグを無視する必要があります。レベル間でリークされた場合、フラグは保持されなければなりません。
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.
到達可能性の広告が1つのレベルから別のレベルに漏洩した場合、元の広告のソースは不明です。アドバタイズがアドバタイジングルータの識別子である場合（たとえば、セクション2.1で説明されているように、プレフィックス属性フラグサブTLVにNフラグが設定されている場合）、他のルータがアドバタイズのソースを知っていると役立つ場合があります。以下に定義するサブTLVはその情報を提供します。
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).
アドバタイズされるルーターIDは常に、アドバタイズを発信したIS-ISインスタンスのルーターIDであることに注意してください。これは、プレフィックスが別のプロトコルから学習された場合（つまり、セクション2.1で定義されているXフラグが設定されている場合）でも当てはまります。
IPv4 Source Router ID Type: 11 Length: 4 Value: IPv4 Router ID of the source of the advertisement
IPv4ソースルーターIDタイプ：11長さ：4値：アドバタイズメントのソースのIPv4ルーターID
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].
このTLVの包含はオプションであり、TLV 135、235、236、または237で発生する可能性があります。含める場合、値は、[RFC5305]で定義されているトラフィックエンジニアリングルーターID（TLV 134）で通知された値と同じでなければなりません。
If present the sub-TLV MUST be included when the prefix advertisement is leaked to another level.
存在する場合、プレフィックスアドバタイズメントが別のレベルにリークされるときにサブTLVを含める必要があります。
IPv6 Source Router ID Type: 12 Length: 16 Value: IPv6 Router ID of the source of the advertisement
IPv6ソースルーターIDタイプ：12長さ：16値：アドバタイズメントのソースのIPv6ルーターID
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].
このTLVを含めることはオプションであり、TLV 135、235、236、または237で発生する場合があります。含める場合、値は[RFC6119]で定義されているIPv6 TEルーターID（TLV 140）で通知された値と同じでなければなりません。
If present, the sub-TLV MUST be included when the prefix advertisement is leaked to another level.
存在する場合、プレフィックスアドバタイズメントが別のレベルにリークされるときにサブTLVを含める必要があります。
[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.
[RFC5305]と[RFC6119]は、それぞれIPv4とIPv6のルーターIDの通知を定義しています。どちらのドキュメントでもトラフィックエンジニアリング（TE）のコンテキストでのルーターIDの使用について説明していますが、ルーターIDの通知はTE以外の目的で明示的に許可されています。セクション2.2で定義されているプレフィックスアドバタイズメントのソースを識別するためのルーターIDの使用は、そのような使用例の1つです。したがって、IPv4またはIPv6ソースルータIDサブTLV（セクション2.2で定義）が使用される場合は常に、発信元ルータも対応するアドレスファミリ固有のルータID TLVをアドバタイズする必要があります（SHOULD）。
This document adds the following new sub-TLVs to the registry of sub-TLVs for TLVs 135, 235, 236, and 237.
このドキュメントでは、TLV 135、235、236、および237のサブTLVのレジストリに、次の新しいサブTLVを追加します。
Value: 4 Name: Prefix Attribute Flags
値：4名前：プレフィックス属性フラグ
Value: 11 Name: IPv4 Source Router ID
値：11名前：IPv4ソースルーターID
Value: 12 Name: IPv6 Source Router ID
値：12名前：IPv6ソースルーター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:
このドキュメントでは、Prefix Attribute FlagsサブTLVのビット値の新しいレジストリも紹介します。登録ポリシーは、[RFC5226]で定義されているExpert Reviewです。このレジストリは、「IS-IS TLVコードポイント」レジストリの一部です。レジストリの名前は、「プレフィックス属性フラグのサブTLVのビット値」です。定義されている値は次のとおりです。
Bit # Name
----- ------------------------------
0 External Prefix Flag (X-flag)
1 Re-advertisement Flag (R-flag)
2 Node Flag (N-flag)
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
IS-ISのセキュリティ上の問題は、[RFC5304]と[RFC5310]で対処されています。
Advertisement of the additional information defined in this document introduces no new security concerns.
このドキュメントで定義されている追加情報のアドバタイズは、新しいセキュリティ上の懸念をもたらしません。
[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.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO / IEC 10589：2002、第2エディション、2002年11月。
[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>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<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>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<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>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<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>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <http://www.rfc-editor.org/info/rfc5308>.
[RFC5308] Hopps、C。、「Routing IPv6 with IS-IS」、RFC 5308、DOI 10.17487 / RFC5308、2008年10月、<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>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<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>.
[RFC6119] Harrison、J.、Berger、J。、およびM. Bartlett、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、DOI 10.17487 / RFC6119、2011年2月、<http：//www.rfc-editor。 org / info / rfc6119>。
[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.
[SR] Previdi、S.、Ed。、Filsfils、C.、Bashandy、A.、Gredler、H.、Litkowski、S.、Decraene、B。、およびJ. Tantsura、「セグメントルーティングのIS-IS拡張機能」 、Work in Progress、draft-ietf-isis-segment-routing-extensions-06、2015年12月。
Contributors
貢献者
The following people gave a substantial contribution to the content of this document:
次の人々は、このドキュメントの内容にかなりの貢献をしました：
Clarence Filsfils Cisco Systems
Clarence Filsfils Cisco Systems
Email: cf@cisco.com
Stephane Litkowski Orange Business Service
ステファンリトコウスキーオレンジビジネスサービス
Email: stephane.litkowski@orange.com
Authors' Addresses
著者のアドレス
Les Ginsberg (editor) Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States
Les Ginsberg（編集者）Cisco Systems 510 McCarthy Blvd.ミルピタス、CA 95035アメリカ合衆国
Email: ginsberg@cisco.com
Bruno Decraene Orange 38 rue du General Leclerc Issy Moulineaux cedex 9 92794 France
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
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144イタリア
Email: sprevidi@cisco.com
Xiaohu Xu Huawei
ξアウトバックXええとUAは
Email: xuxiaohu@huawei.com
Uma Chunduri Ericsson
ウマチャンドゥリエリクソン
Email: uma.chunduri@ericsson.com