Network Working Group C. Hopps
Request for Comments: 5308 Cisco Systems
Category: Standards Track October 2008
Network Working Group C. Hopps
Request for Comments: 5308 Cisco Systems
Category: Standards Track October 2008
Routing IPv6 with IS-IS
使用IS-IS路由IPv6
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol.
本文档指定了使用IS-IS路由协议交换IPv6路由信息的方法。所描述的方法利用两个新的TLV：可达性TLV和接口地址TLV在整个路由域中分发必要的IPv6信息。使用此方法，可以使用单个域内路由协议将IPv6与IPv4和OSI一起路由。
IS-IS is an extendible intra-domain routing protocol. Each router in the routing domain issues an Link State Protocol Data Unit (LSP) that contains information pertaining to that router. The LSP contains typed variable-length data, often referred to as TLVs (type-length-values). We extend the protocol with two new TLVs to carry information required to perform IPv6 routing.
IS-IS是一种可扩展的域内路由协议。路由域中的每个路由器都会发出一个链路状态协议数据单元（LSP），其中包含与该路由器相关的信息。LSP包含类型化的可变长度数据，通常称为TLV（类型长度值）。我们使用两个新的TLV扩展协议，以承载执行IPv6路由所需的信息。
In [RFC1195], a method is described to route both OSI and IPv4. We utilize this same method with some minor changes to allow for IPv6. To do so, we must define two new TLVs, namely "IPv6 Reachability" and "IPv6 Interface Address", and a new IPv6 protocol identifier. In our new TLVs, we utilize the extended metrics and up/down semantics of [RFC5305].
在[RFC1195]中，描述了一种路由OSI和IPv4的方法。我们使用了相同的方法，并做了一些小的更改，以支持IPv6。为此，我们必须定义两个新的TLV，即“IPv6可达性”和“IPv6接口地址”，以及一个新的IPv6协议标识符。在我们的新TLV中，我们利用[RFC5305]的扩展度量和上/下语义。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The "IPv6 Reachability" TLV is TLV type 236 (0xEC).
“IPv6可达性”TLV是TLV类型236（0xEC）。
[RFC1195] defines two Reachability TLVs, "IP Internal Reachability Information" and "IP External Reachability Information". We provide the equivalent IPv6 data with the "IPv6 Reachability" TLV and an "external" bit.
[RFC1195]定义了两个可达性TLV，“IP内部可达性信息”和“IP外部可达性信息”。我们提供具有“IPv6可达性”TLV和“外部”位的等效IPv6数据。
The "IPv6 Reachability" TLV describes network reachability through the specification of a routing prefix, metric information, a bit to indicate if the prefix is being advertised down from a higher level, a bit to indicate if the prefix is being distributed from another routing protocol, and OPTIONALLY the existence of Sub-TLVs to allow for later extension. This data is represented by the following structure:
“IPv6可达性”TLV通过指定路由前缀、度量信息、指示前缀是否从更高级别向下播发的位、指示前缀是否从另一个路由协议分发的位来描述网络可达性，以及可选的子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 236 | Length | Metric .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Metric |U|X|S| Reserve | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV Len(*) | Sub-TLVs(*) ...
* - if present
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 236 | Length | Metric .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Metric |U|X|S| Reserve | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV Len(*) | Sub-TLVs(*) ...
* - if present
U - up/down bit X - external original bit S - subtlv present bit
U-向上/向下位X-外部原始位S-子LV当前位
The above IPv6 Reachability TLV MAY appear any number of times (including none) within an LSP. Link-local prefixes MUST NOT be advertised using this TLV.
上述IPv6可达性TLV可能在LSP中出现任意次数（包括无）。不得使用此TLV播发链接本地前缀。
As is described in [RFC5305]: "The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit SHALL be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels".
如[RFC5305]所述：“当前缀首次注入is-is时，向上/向下位应设置为0。如果前缀从较高级别播发到较低级别（例如，级别2到级别1），位应设置为1，表示前缀已沿层次结构向下移动。向上/向下位设置为1的前缀只能沿层次结构向下播发，即向较低级别播发”。
If the prefix was distributed into IS-IS from another routing protocol, the external bit SHALL be set to 1. This information is useful when distributing prefixes from IS-IS to other protocols.
如果前缀是从另一个路由协议分配到IS-IS中的，则外部位应设置为1。当从is-is向其他协议分发前缀时，此信息非常有用。
If the Sub-TLV bit is set to 0, then the octets of Sub-TLVs are not present. Otherwise, the bit is 1 and the octet following the prefix will contain the length of the Sub-TLV portion of the structure.
如果子TLV位设置为0，则子TLV的八位字节不存在。否则，位为1，前缀后面的八位字节将包含结构子TLV部分的长度。
The prefix is "packed" in the data structure. That is, only the required number of octets of prefix are present. This number can be computed from the prefix length octet as follows:
前缀在数据结构中是“压缩”的。也就是说，只存在所需数量的前缀八位字节。可根据前缀长度八位字节计算此数字，如下所示：
prefix octets = integer of ((prefix length + 7) / 8)
prefix octets = integer of ((prefix length + 7) / 8)
Just as in [RFC5305], if a prefix is advertised with a metric larger than MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST not be considered during the normal Shortest Path First (SPF) computation. This will allow advertisement of a prefix for purposes other than building the normal IPv6 routing table.
正如在[RFC5305]中一样，如果使用大于MAX_V6_PATH_metric（0xFE000000）的度量播发前缀，则在正常最短路径优先（SPF）计算期间不得考虑该前缀。这将允许出于构建正常IPv6路由表以外的目的播发前缀。
If Sub-TLVs are present, they have the same form as normal TLVs, as shown below.
如果存在子TLV，则其形式与正常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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value(*) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* - if present
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value(*) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* - if present
Length indicates how many octets of value are present and can be 0.
长度表示存在多少个值的八位字节，可以是0。
The "IPv6 Interface Address" TLV is TLV type 232 (0xE8).
“IPv6接口地址”TLV是TLV类型232（0xE8）。
TLV 232 maps directly to "IP Interface Address" TLV in [RFC1195] . We necessarily modify the contents to be 0-15 16-octet IPv6 interface addresses instead of 0-63 4-octet IPv4 interface addresses.
TLV 232直接映射到[RFC1195]中的“IP接口地址”TLV。我们必须将内容修改为0-15 16八位IPv6接口地址，而不是0-63 4八位IPv4接口地址。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 232 | Length | Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address 1(*) .. | Interface Address 2(*) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* - if present
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 232 | Length | Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Interface Address 1(*) .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address 1(*) .. | Interface Address 2(*) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* - if present
We further restrict the semantics of this TLV depending on where it is advertised. For Hello PDUs, the "Interface Address" TLV MUST contain only the link-local IPv6 addresses assigned to the interface that is sending the Hello. For LSPs, the "Interface Address" TLVs MUST contain only the non-link-local IPv6 addresses assigned to the IS.
我们进一步限制这个TLV的语义，这取决于它的广告位置。对于Hello PDU，“接口地址”TLV必须仅包含分配给发送Hello的接口的链路本地IPv6地址。对于LSP，“接口地址”TLV必须仅包含分配给IS的非链路本地IPv6地址。
The value of the IPv6 Network Layer Protocol ID (NLPID) is 142 (0x8E).
IPv6网络层协议ID（NLPID）的值为142（0x8E）。
As with [RFC1195] and IPv4, if the IS supports IPv6 routing using IS-IS, it MUST advertise this in the "NLPID" TLV by adding the IPv6 NLPID.
与[RFC1195]和IPv4一样，如果IS支持使用IS-IS的IPv6路由，则它必须通过添加IPv6 NLPID在“NLPID”TLV中公布这一点。
We utilize the same changes to [RFC1195] as made in [RFC5305] for the processing of prefix information. These changes are both related to the SPF calculation.
我们使用与[RFC5305]中相同的[RFC1195]更改来处理前缀信息。这些变化都与SPF计算有关。
Since the metric space has been extended, we need to redefine the MAX_PATH_METRIC (1023) from the original specification in [RFC1195]. This new value MAX_V6_PATH_METRIC is the same as in [RFC5305] (0xFE000000). If, during the SPF, a path metric would exceed MAX_V6_PATH_METRIC, it SHALL be considered to be MAX_V6_PATH_METRIC.
由于度量空间已经扩展，我们需要从[RFC1195]中的原始规范重新定义MAX_PATH_度量（1023）。此新值MAX_V6_PATH_度量与[RFC5305]（0xFE000000）中的相同。如果在SPF期间，路径度量将超过MAX_V6_path_度量，则应将其视为MAX_V6_path_度量。
The order of preference between paths for a given prefix MUST be modified to consider the up/down bit. The new order of preference is as follows (from best to worst).
必须修改给定前缀的路径之间的优先顺序以考虑上/下比特。新的优先顺序如下（从最佳到最差）。
1. Level 1 up prefix
1. 一级上行前缀
2. Level 2 up prefix
2. 二级上行前缀
3. Level 2 down prefix
3. 二级向下前缀
4. Level 1 down prefix
4. 1级向下前缀
If multiple paths have the same best preference, then selection occurs based on metric. Any remaining multiple paths SHOULD be considered for equal-cost multi-path routing if the router supports this; otherwise, the router can select any one of the multiple paths.
如果多个路径具有相同的最佳首选项，则会根据度量进行选择。如果路由器支持，则应考虑任何剩余的多条路径进行等成本多路径路由；否则，路由器可以选择多条路径中的任意一条。
IANA has updated the IS-IS codepoint registry so that TLV codes 232 and 236 refer to this RFC.
IANA已更新IS-IS代码点注册表，以便TLV代码232和236引用此RFC。
IANA has also created the following new codepoint registry for Sub-TLVs of TLV 236. The range of values for Type is 0-255. Allocations within the registry require documentation of the use and requires approval by the Designated Expert assigned by the IESG [RFC5226]. All codepoints are currently unassigned.
IANA还为TLV 236的子TLV创建了以下新的代码点注册表。类型的值范围为0-255。注册中心内的分配需要使用文件，并需要获得IESG指定专家的批准[RFC5226]。所有代码点当前都未分配。
This document raises no new security considerations. Security considerations for the IS-IS protocol are covered in [ISO10589] and in [RFC5304].
本文件没有提出新的安全注意事项。IS-IS协议的安全注意事项见[ISO10589]和[RFC5304]。
[ISO10589] 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.
[ISO10589]ISO，“与提供无连接模式网络服务协议（ISO 8473）一起使用的中间系统到中间系统域内路由信息交换协议”，国际标准10589:2002，第二版，2002年。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
Author's Address
作者地址
Christian E. Hopps Cisco Systems 170 W. Tasman Dr. San Jose, California 95134 USA
Christian E.Hopps Cisco Systems 170 W.Tasman博士加利福尼亚州圣何塞95134
EMail: chopps@cisco.com
EMail: chopps@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.