Network Working Group S. Venkata
Request for Comments: 5642 Google Inc.
Category: Standards Track S. Harwani
C. Pignataro
Cisco Systems
D. McPherson
Arbor Networks, Inc.
August 2009
Network Working Group S. Venkata
Request for Comments: 5642 Google Inc.
Category: Standards Track S. Harwani
C. Pignataro
Cisco Systems
D. McPherson
Arbor Networks, Inc.
August 2009
Dynamic Hostname Exchange Mechanism for OSPF
OSPF的动态主机名交换机制
Abstract
摘要
This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3.
本文档定义了一个新的OSPF路由器信息（RI）TLV，它允许OSPF路由器通过OSPF网络将其主机名映射到路由器ID，从而为运行OSPF的路由器提供一种简单而动态的机制，以了解符号主机名，就像运行IS-IS的路由器一样。该机制适用于OSPFv2和OSPFv3。
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，其衍生作品可能会
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.
不得在IETF标准流程之外创建，除非将其格式化以RFC形式发布，或将其翻译成英语以外的语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 4
3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . . 5
4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 4
3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . . 5
4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
OSPF uses a 32-bit Router ID to uniquely represent and identify a node in the network. For management and operational reasons, network operators need to check the status of OSPF adjacencies, entries in the routing table, and the content of the OSPF link state database. When looking at diagnostic information, numerical representations of Router IDs (e.g., dotted-decimal or hexadecimal representations) are less clear to humans than symbolic names.
OSPF使用32位路由器ID唯一地表示和标识网络中的节点。出于管理和操作原因，网络运营商需要检查OSPF邻接的状态、路由表中的条目以及OSPF链路状态数据库的内容。当查看诊断信息时，路由器ID的数字表示（例如，点十进制或十六进制表示）对人类来说不如符号名称清晰。
One way to overcome this problem is to define a hostname-to-Router-ID mapping table on a router. This mapping can be used bidirectionally (e.g., to find symbolic names for Router IDs and to find Router IDs for symbolic names) or unidirectionally (e.g., to find symbolic hostnames for Router IDs). Thus, every router has to maintain a table with mappings between router names and Router IDs.
克服此问题的一种方法是在路由器上定义主机名到路由器ID的映射表。此映射可以双向使用（例如，查找路由器ID的符号名称和查找符号名称的路由器ID），也可以单向使用（例如，查找路由器ID的符号主机名）。因此，每个路由器都必须维护一个表，其中包含路由器名称和路由器ID之间的映射。
These tables need to contain all names and Router IDs of all routers in the network. If these mapping tables are built by static definitions, it can currently become a manual and tedious process in operational networks; modifying these static mapping entries when additions, deletions, or changes occur becomes a non-scalable process very prone to error.
这些表需要包含网络中所有路由器的所有名称和路由器ID。如果这些映射表是通过静态定义构建的，那么在操作网络中，它目前可能会成为一个手动且繁琐的过程；在发生添加、删除或更改时修改这些静态映射条目将成为一个不可伸缩的过程，很容易出错。
This document analyzes possible solutions to this problem (see Section 2) and provides a way to populate tables by defining a new
本文档分析了此问题的可能解决方案（参见第2节），并提供了通过定义新的
OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see Section 3). This mechanism is applicable to both OSPFv2 and OSPFv3.
OSPF路由器信息TLV针对OSPF，动态主机名TLV（见第3节）。该机制适用于OSPFv2和OSPFv3。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
There are various approaches to providing a name-to-Router-ID mapping service.
提供名称到路由器ID映射服务有多种方法。
One way to build this table of mappings is by static definitions. The problem with static definitions is that the network administrator needs to keep updating the mapping entries manually as the network changes; this approach does not scale as the network grows, since there needs to be an entry in the mapping table for each and every router in the network, on every router in the network. Thus, this approach greatly suffers from maintainability and scalability considerations.
构建此映射表的一种方法是通过静态定义。静态定义的问题是，网络管理员需要在网络更改时手动更新映射条目；这种方法不会随着网络的增长而扩展，因为网络中的每个路由器都需要在映射表中有一个条目。因此，这种方法极大地受到可维护性和可伸缩性考虑的影响。
Another approach is having a centralized location where the name-to-Router-ID mapping can be kept. The DNS could be used for this. A disadvantage with this centralized solution is that it is a single point of failure; and although enhanced availability of the central mapping service can be designed, it may not be able to resolve the hostname in the event of reachability or network problems, which can be particularly problematic in times of problem resolution. Also, the response time can be an issue with the centralized solution, which can be equally problematic. If the DNS is used as the centralized mapping table, a network operator may desire a different name mapping than the existing mapping in the DNS, or new routers may not yet be in the DNS.
另一种方法是有一个集中的位置，在那里可以保持名称到路由器ID的映射。DNS可用于此目的。这种集中式解决方案的一个缺点是它是一个单点故障；而且，尽管可以设计增强的中央映射服务可用性，但在出现可达性或网络问题时，它可能无法解析主机名，这在解决问题时可能特别有问题。此外，对于集中式解决方案，响应时间可能是一个问题，这也可能是一个同样的问题。如果DNS用作集中映射表，则网络运营商可能需要与DNS中现有映射不同的名称映射，或者新路由器可能尚未位于DNS中。
Additionally, for OSPFv3 in native IPv6 deployments, the 32-bit Router ID value will not map to IPv4-addressed entities in the network, nor will it be DNS resolvable (see Section 4).
此外，对于本机IPv6部署中的OSPFv3，32位路由器ID值不会映射到网络中的IPv4寻址实体，也不会是DNS可解析的（请参阅第4节）。
The third solution that we have defined in this document is to make use of the protocol itself to carry the name-to-Router-ID mapping in a TLV. Routers that understand this TLV can use it to create the symbolic name-to-Router-ID mapping, and routers that don't understand it can simply ignore it. This specification provides these semantics and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF Router Information (RI) Link State Advertisement (LSA) ([RFC4970]).
我们在本文档中定义的第三个解决方案是利用协议本身在TLV中携带名称到路由器ID的映射。理解这个TLV的路由器可以使用它来创建符号名到路由器ID的映射，不理解它的路由器可以忽略它。本规范利用OSPF路由器信息（RI）链路状态公告（LSA）（[RFC4970]），为OSPFv2和OSPFv3提供了这些语义和映射机制。
This extension makes use of the Router Information (RI) Opaque LSA, defined in [RFC4970], for both OSPFv2 and OSPFv3, by defining a new OSPF Router Information (RI) TLV: the Dynamic Hostname TLV.
此扩展通过定义新的OSPF路由器信息（RI）TLV（动态主机名TLV），为OSPFv2和OSPFv3使用[RFC4970]中定义的路由器信息（RI）不透明LSA。
The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt of the TLV, a router may decide to ignore this TLV or to install the symbolic name and Router ID in its hostname mapping table.
动态主机名TLV（见第3.1节）是可选的。收到TLV后，路由器可能会决定忽略此TLV，或在其主机名映射表中安装符号名和路由器ID。
The format of the Dynamic Hostname TLV is as follows:
动态主机名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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hostname ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hostname ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Dynamic Hostname TLV Type (7; see Section 6)
类型动态主机名TLV类型（7；参见第6节）
Length Total length of the hostname (Value field) in octets, not including the optional padding.
长度主机名（值字段）的总长度（以八位字节为单位），不包括可选的填充。
Value Hostname, a string of 1 to 255 octets, padded with zeroes to 4-octet alignment, encoded in the US-ASCII charset.
值Hostname，一个由1到255个八位字节组成的字符串，用0填充到4个八位字节对齐，用US-ASCII字符集编码。
Routers that do not recognize the Dynamic Hostname TLV Type ignore the TLV (see [RFC4970]).
不识别动态主机名TLV类型的路由器会忽略TLV（请参阅[RFC4970]）。
The Value field identifies the symbolic hostname of the router originating the LSA. This symbolic name can be the Fully Qualified Domain Name (FQDN) for the Router ID, it can be a subset of the FQDN, or it can be any string that operators want to use for the router. The use of FQDN or a subset of it is strongly recommended since it can be beneficial to correlate the OSPF dynamic hostname and the DNS hostname. The format of the DNS hostname is described in [RFC1035] and [RFC2181]. If there is no DNS hostname for the Router ID, if the Router ID does not map to an IPv4-addressed entity (e.g., see Section 4), or if an alternate OSPF dynamic hostname naming convention is desired, any string with significance in the OSPF routing domain can be used. The string is not null-terminated. The Router ID of this router is derived from the LSA header, in the Advertising Router field of the Router Information (RI) Opaque LSA.
值字段标识发起LSA的路由器的符号主机名。此符号名可以是路由器ID的完全限定域名（FQDN），也可以是FQDN的子集，也可以是操作员希望用于路由器的任何字符串。强烈建议使用FQDN或其子集，因为将OSPF动态主机名和DNS主机名关联起来可能会有好处。DNS主机名的格式如[RFC1035]和[RFC2181]所述。如果路由器ID没有DNS主机名，如果路由器ID没有映射到IPv4寻址实体（例如，请参见第4节），或者如果需要备用OSPF动态主机名命名约定，则可以使用OSPF路由域中具有重要意义的任何字符串。字符串不是以null结尾的。此路由器的路由器ID来自路由器信息（RI）不透明LSA的广告路由器字段中的LSA报头。
The Value field is encoded in 7-bit ASCII. If a user-interface for configuring or displaying this field permits Unicode characters, that user-interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC3490] to achieve the correct format for transmission or display.
值字段以7位ASCII编码。如果用于配置或显示此字段的用户界面允许使用Unicode字符，则该用户界面负责应用[RFC3490]中所述的ToASCII和/或ToUnicode算法，以获得正确的传输或显示格式。
The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3.
动态主机名TLV同时适用于OSPFv2和OSPFv3。
The Dynamic Hostname TLV MAY be advertised within an area-local or autonomous system (AS)-scope Router Information (RI) LSA. But the Dynamic Hostname TLV SHOULD NOT be advertised into an area in more than one RI LSA, irrespective of the scope of the LSA.
动态主机名TLV可以在区域本地或自治系统（AS）作用域路由器信息（RI）LSA内公布。但动态主机名TLV不应在多个RI LSA中的一个区域中播发，无论LSA的范围如何。
In other words, if a router originates a Dynamic Hostname TLV with an IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped Dynamic Hostname TLVs except into any attached Not-So-Stubby Area (NSSA) area(s). Similarly, if a router originates an area-scoped Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT send an AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname TLV is advertised in more than one LSA (e.g., multiple area-scoped LSAs, or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname SHOULD be the same.
换句话说，如果路由器使用IGP域（AS）泛洪作用域创建动态主机名TLV，则它不应发送区域作用域动态主机名TLV，除非发送到任何附加的非短存根区域（NSSA）区域。类似地，如果路由器发起区域范围的动态主机名TLV（NSSA区域范围除外），则不应发送AS范围的动态主机名TLV。当动态主机名TLV在多个LSA（例如，多区域作用域LSA，或作用域LSA加NSSA区域作用域LSA）中播发时，主机名应相同。
If a router is advertising any AS-scope LSA (other than Dynamic Hostname TLV RI LSA), such router SHOULD advertise Dynamic Hostname TLV RI LSA in AS scope. Otherwise, it SHOULD advertise Dynamic Hostname TLV RI LSA in area scope. For example, an AS boundary router (ASBR) SHOULD send an AS-scope Dynamic Hostname TLV, whereas area boundary router (ABRs) and internal routers SHOULD send an area-scope Dynamic Hostname TLV.
如果路由器正在播发任何AS作用域LSA（动态主机名TLV RI LSA除外），则该路由器应在AS作用域中播发动态主机名TLV RI LSA。否则，它应该在区域范围内公布动态主机名TLV RI LSA。例如，AS边界路由器（ASBR）应发送AS作用域动态主机名TLV，而区域边界路由器（ABRs）和内部路由器应发送区域作用域动态主机名TLV。
The flooding scope is controlled by the Opaque LSA type in OSPFv2 and by the S1 and S2 bits in OSPFv3. For area scope, the Dynamic Hostname TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an OSPFv3 RI LSA with the S1 bit set and the S2 bit clear. If the flooding scope is the entire routing domain (AS scope), the Dynamic Hostname TLV MUST be carried within an OSPFv2 Type 11 RI LSA or OSPFv3 RI LSA with the S1 bit clear and the S2 bit set.
泛洪范围由OSPFv2中的不透明LSA类型以及OSPFv3中的S1和S2位控制。对于区域范围，动态主机名TLV必须在设置了S1位且清除了S2位的OSPFv2类型10 RI LSA或OSPFv3 RI LSA中携带。如果泛洪作用域是整个路由域（AS作用域），则动态主机名TLV必须在清除S1位并设置S2位的OSPFv2类型11 RI LSA或OSPFv3 RI LSA中携带。
When an OSPF Router Information (RI) LSA, including the Dynamic Hostname TLV, is advertised in multiple OSPF instances, the hostname SHOULD either be preserved or include a common base element. It may be useful for debugging or other purposes to assign separate instances different hostnames with a consistent set of suffixes or
当在多个OSPF实例中公布OSPF路由器信息（RI）LSA（包括动态主机名TLV）时，应保留主机名或包含公共基本元素。对于调试或其他目的，使用一组一致的后缀或名称为单独的实例分配不同的主机名可能很有用
prefixes that can be associated with a specific instance -- in particular, when an instance is used for a discrete address family or non-routing information.
可与特定实例关联的前缀，特别是当实例用于离散地址族或非路由信息时。
Both OSPFv2 and OSPFv3 employ Router IDs with a common size of 32 bits. In IPv4, the Router ID values were typically derived automatically from an IPv4 address either configured on a loopback or physical interface defined on the local system or explicitly defined within the OSPF process configuration. With broader deployment of IPv6, it's quite likely that OSPF networks will exist that have no native IPv4-addressed interfaces. As a result, a 32-bit OSPF Router ID will need to be either explicitly specified or derived in some automatic manner that avoids collisions with other OSPF routers within the local routing domain.
OSPFv2和OSPFv3都使用路由器ID，其公共大小为32位。在IPv4中，路由器ID值通常是从IPv4地址自动派生的，该地址可以是在本地系统上定义的环回或物理接口上配置的，也可以是在OSPF进程配置中明确定义的。随着IPv6的广泛部署，很可能存在没有本机IPv4寻址接口的OSPF网络。因此，32位OSPF路由器ID需要以某种自动方式明确指定或派生，以避免与本地路由域内的其他OSPF路由器发生冲突。
Because this 32-bit value will not map to IPv4-addressed entities in the network, nor will it be DNS resolvable, it is considered extremely desirable from an operational perspective that some mechanism exist to map OSPF Router IDs to more easily interpreted values -- ideally, human-readable strings. This specification enables a mapping functionality that eases operational burdens that may otherwise be introduced with native deployment of IPv6.
由于此32位值不会映射到网络中的IPv4寻址实体，也不会是DNS可解析的，因此从操作角度来看，存在一些机制将OSPF路由器ID映射到更易于解释的值（理想情况下是人类可读的字符串），这被认为是非常理想的。此规范支持映射功能，以减轻IPv6本机部署可能带来的操作负担。
Since the hostname-to-Router-ID mapping relies on information provided by the routers themselves, a misconfigured or compromised router can inject false mapping information, including a duplicate hostname for different Router IDs. Thus, this information needs to be treated with suspicion when, for example, doing diagnostics about a suspected security incident.
由于主机名到路由器ID的映射依赖于路由器本身提供的信息，因此配置错误或受损的路由器可能会注入错误的映射信息，包括不同路由器ID的重复主机名。因此，例如，在对可疑的安全事件进行诊断时，需要对这些信息进行怀疑。
There is potential confusion from name collisions if two routers use and advertise the same dynamic hostname. Name conflicts are not crucial, and therefore there is no generic conflict detection or resolution mechanism in the protocol. However, a router that detects that a received hostname is the same as the local one can issue a notification or a management alert.
如果两个路由器使用并公布相同的动态主机名，则可能会因名称冲突而产生混淆。名称冲突并不重要，因此协议中没有通用的冲突检测或解决机制。但是，检测到接收到的主机名与本地主机名相同的路由器可以发出通知或管理警报。
The use of the FQDN as OSPF dynamic hostname potentially exposes geographic or other commercial information that can be deduced from the hostname when sent in the clear. OSPFv3 supports confidentiality via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated over IPsec tunnels if confidentiality is required.
将FQDN用作OSPF动态主机名可能会暴露地理信息或其他商业信息，这些信息在以明文形式发送时可以从主机名中推断出来。OSPFv3支持通过传输模式IPsec进行保密（请参阅[RFC4552]）。如果需要保密，OSPFv2可以通过IPsec隧道进行操作。
This document raises no other new security issues for OSPF. Security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340]. The use of authentication for the OSPF routing protocols is encouraged.
本文件没有为OSPF提出其他新的安全问题。[RFC2328]和[RFC5340]中介绍了基本OSPF协议的安全注意事项。鼓励对OSPF路由协议使用身份验证。
IANA maintains the "OSPF Router Information (RI) TLVs" registry [IANA-RI]. An additional OSPF Router Information TLV Type is defined in Section 3. It has been assigned by IANA from the Standards Action allocation range [RFC4970].
IANA维护“OSPF路由器信息（RI）TLV”注册表[IANA-RI]。第3节定义了额外的OSPF路由器信息TLV类型。它由IANA从标准行动分配范围[RFC4970]分配。
Registry Name: OSPF Router Information (RI) TLVs
注册表名称：OSPF路由器信息（RI）TLV
Type Value Capabilities Reference
----------- -------------------------------------- ---------
7 OSPF Dynamic Hostname This document
Type Value Capabilities Reference
----------- -------------------------------------- ---------
7 OSPF Dynamic Hostname This document
The authors of this document do not make any claims on the originality of the ideas described. This document adapts format and text from similar work done in IS-IS [RFC5301] (which obsoletes [RFC2763]); we would like to thank Naiming Shen and Henk Smit, authors of [RFC2763].
本文件的作者不对所述想法的独创性提出任何主张。本文件采用IS-IS[RFC5301]（淘汰[RFC2763]）中类似工作的格式和文本；我们要感谢[RFC2763]的作者沈乃明和亨克·斯密特。
The authors would also like to thank Acee Lindem, Abhay Roy, Anton Smirnov, and Dave Ward for their valuable comments and suggestions.
作者还要感谢Acee Lindem、Abhay Roy、Anton Smirnov和Dave Ward提出的宝贵意见和建议。
[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月。
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970]Lindem，A.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 49702007年7月。
[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path First v2 (OSPFv2) Parameters", <http://www.iana.org>.
[IANA-RI]互联网分配号码管理局，“开放最短路径优先v2（OSPFv2）参数”<http://www.iana.org>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763, February 2000.
[RFC2763]Shen，N.和H.Smit，“IS-IS的动态主机名交换机制”，RFC2763，2000年2月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, October 2008.
[RFC5301]McPherson，D.和N.Shen，“IS-IS的动态主机名交换机制”，RFC 5301，2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
Authors' Addresses
作者地址
Subbaiah Venkata Google Inc.
Subbaiah Venkata谷歌公司。
EMail: svenkata@google.com
URI: http://www.google.com
EMail: svenkata@google.com
URI: http://www.google.com
Sanjay Harwani Cisco Systems
桑杰·哈瓦尼思科系统公司
EMail: sharwani@cisco.com
URI: http://www.cisco.com
EMail: sharwani@cisco.com
URI: http://www.cisco.com
Carlos Pignataro Cisco Systems
卡洛斯·皮格纳塔罗思科系统公司
EMail: cpignata@cisco.com
URI: http://www.cisco.com
EMail: cpignata@cisco.com
URI: http://www.cisco.com
Danny McPherson Arbor Networks, Inc.
丹尼·麦克弗森阿伯网络公司。
EMail: danny@arbor.net
EMail: danny@arbor.net