Network Working Group E. Warnicke
Request for Comments: 4183 Cisco Systems
Category: Informational September 2005
Network Working Group E. Warnicke
Request for Comments: 4183 Cisco Systems
Category: Informational September 2005
A Suggested Scheme for DNS Resolution of Networks and Gateways
网络和网关DNS解析的建议方案
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 [6] for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已自行决定发布本文件。有关更多信息，请参见RFC 3932[6]。
Abstract
摘要
This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.
本文档建议使用DNS确定包含指定IP地址的网络、该网络的网络掩码以及该网络上第一跳路由器的地址的方法。此方法支持可变长度子网掩码、非八位字节边界上的子网委派以及每个子网的多个路由器。
As a variety of new devices are introduced to the network, many of them not traditional workstations or routers, there are requirements that the first-hop router provide some network service for a host. It may be necessary for a third-party server in the network to request some service related to the host from the first-hop router(s) for that host. It would be useful to have a standard mechanism for such a third-party device to find the first-hop router(s) for that host.
随着各种新设备被引入网络，其中许多不是传统的工作站或路由器，因此要求第一跳路由器为主机提供一些网络服务。网络中的第三方服务器可能需要从该主机的第一跳路由器请求与该主机相关的一些服务。为这样的第三方设备找到该主机的第一跳路由器提供一种标准机制是很有用的。
DNS-based mechanisms have been defined for the resolution of router addresses for classful networks (RFC 1035 [1]) and of subnets (RFC 1101 [2]). RFC 1101 suffers from a number of defects, chief among
基于DNS的机制已被定义用于解析分级网络（RFC 1035[1]）和子网（RFC 1101[2]）的路由器地址。RFC1101有许多缺陷，其中最主要的是
which are that it does not support variable-length subnet masks, which are commonly deployed in the Internet. The present document defines DNS-based mechanisms to cure these defects.
它不支持可变长度的子网掩码，这些掩码通常部署在Internet上。本文档定义了基于DNS的机制来修复这些缺陷。
Since the writing of RFC 1101, DNS mechanisms for dealing with classless networks have been defined, for example, RFC 2317 [3]. This document describes a mechanism that uses notation similar to that of RFC 2317 to specify a series of PTR records enumerating the subnets of a given network in the RFC 2317 notation. This lookup process continues until the contents of the PTR records are not an in-addr.arpa.-derived domain name. These terminal PTR record values are treated as the hostname(s) of the router(s) on that network. This RFC also specifies an extension to the method of RFC 2317 to support delegation at non-octet boundaries.
自编写RFC 1101以来，已经定义了用于处理无类网络的DNS机制，例如RFC 2317[3]。本文档描述了一种机制，该机制使用类似于RFC 2317的表示法来指定一系列PTR记录，这些记录以RFC 2317表示法枚举给定网络的子网。此查找过程将继续，直到PTR记录的内容不是addr.arpa.-派生的域名。这些终端PTR记录值被视为该网络上路由器的主机名。该RFC还指定了对RFC 2317方法的扩展，以支持非八位字节边界的委派。
Using the Augmented BNF of RFC 2234 [4], we can describe a generic domain name for a network as follows:
使用RFC 2234[4]的扩充BNF，我们可以如下描述网络的通用域名：
networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet
".") "in-addr.arpa."
maskedoctet = decimaloctet "-" mask
mask = 1*2DIGIT ; representing a decimal integer value in the
; range 1-32
decimaloctet = 1*3DIGIT ; representing a decimal integer value in
; the range 0 through 255
networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet
".") "in-addr.arpa."
maskedoctet = decimaloctet "-" mask
mask = 1*2DIGIT ; representing a decimal integer value in the
; range 1-32
decimaloctet = 1*3DIGIT ; representing a decimal integer value in
; the range 0 through 255
By way of reference, an IPv4 CIDR notation network address would be written
作为参考，将写入IPv4 CIDR表示法网络地址
IPv4CIDR = decimaloctet "." decimaloctet "." decimaloctet "." decimaloctet "/" mask
IPv4CIDR=小数八位组“.”小数八位组“.”小数八位组“.”小数八位组“/”掩码
A "-" is used as a delimiter in a maskedoctet instead of a "/" as in RFC 2317 out of concern about compatibility with existing DNS servers, many of which do not consider "/" to be a valid character in a hostname.
在与现有的DNS服务器兼容的情况下，“--”被用作MaskDoTeTT中的分隔符，而不是RFC 2317中的“//”，其中许多不认为“/”是主机名中的有效字符。
In RFC 2317, there is no mechanism for non-octet boundary delegation. Networks would be represented as being part of the domain of the next octet.
在RFC2317中，没有非八位组边界委托的机制。网络将被表示为下一个八位组域的一部分。
Examples:
示例：
10.100.2.0/26 -> 0-26.2.100.10.in-addr.arpa. 10.20.128.0/23 -> 128-23.20.10.in-addr.arpa. 10.192.0.0/13 -> 192-13.10.in-addr.arpa.
10.100.2.0/26->0-26.2.100.10.in-addr.arpa。10.20.128.0/23->128-23.20.10.in-addr.arpa。10.192.0.0/13->192-13.10.in-addr.arpa。
In the event that the entity subnetting does not actually own the network being subnetted on an octet break, a mechanism needs to be available to allow for the specification of those subnets. The mechanism is to allow the use of maskedoctet labels as delegation shims.
如果实体子网实际上不拥有在八位组中断时被子网化的网络，则需要一种机制来允许指定这些子网。其机制是允许使用maskedocet标签作为委托垫片。
For example, consider an entity A that controls a network 10.1.0.0/16. Entity A delegates to entity B the network 10.1.0.0/18. In order to avoid having to update entries for entity B whenever entity B updates subnetting, entity A delegates the 0-18.1.10.in-addr.arpa domain (with an NS record in A's DNS tables as usual) to entity B. Entity B then subnets off 10.1.0.0/25. It would provide a domain name for this network of 0-25.0.0-18.1.10.in-addr.arpa (in B's DNS tables).
例如，考虑控制网络101.0/16的实体A。实体A将网络10.1.0.0/18委托给实体B。为了避免在实体B更新子网时必须更新实体B的条目，实体A将0-18.1.10.In-addr.arpa域（通常在A的DNS表中有NS记录）委托给实体B。实体B然后将子网从10.1.0.0/25中删除。它将为这个网络提供一个域名0-25.0.0-18.1.10.in-addr.arpa（在B的DNS表中）。
In order to speak about the non-octet boundary case more easily, it is useful to define a few terms.
为了更容易地讨论非八位组边界情况，定义一些术语是很有用的。
Network domain names that do not contain any maskedoctets after the first (leftmost) label are hereafter referred to as canonical domain names for that network. 0-25.0.1.10.in-addr.arpa. is the canonical domain name for the network 10.1.0.0/25.
在第一个（最左侧）标签之后不包含任何maskedocets的网络域名在下文中称为该网络的规范域名。0-25.0.1.10.in-addr.arpa。是网络10.1.0.0/25的规范域名。
Network domain names that do contain maskedoctet labels after the first (leftmost) label can be reduced to a canonical domain name by dropping all maskedoctet labels after the first (leftmost) label. They are said to be reducible to the canonical network domain name. So for example 0-25.0.0-18.1.10.in-addr.arpa. is reducible to 0-25.0.1.10.in-addr.arpa. Note that a network domain name represents the same network as the canonical domain name to which it can be reduced.
在第一个（最左侧）标签之后确实包含maskedoctet标签的网络域名可以通过在第一个（最左侧）标签之后删除所有maskedoctet标签而缩减为规范域名。据说它们可以简化为规范的网络域名。例如0-25.0.0-18.1.10.in-addr.arpa。可还原为0-25.0.1.10.in-addr.arpa。请注意，网络域名表示与规范域名相同的网络，可以将其缩减为规范域名。
1. Take the initial IP address x.y.z.w and create a candidate network by assuming a 24-bit subnet mask. Thus, the initial candidate network is x.y.z.0/24.
1. 采用初始IP地址x.y.z.w，并通过假设24位子网掩码来创建候选网络。因此，初始候选网络是x.y.z.0/24。
2. Given a candidate network of the form x.y.z.n/m create an in-addr.arpa candidate domain name:
2. 给定一个x.y.z.n/m形式的候选网络，创建一个in-addr.arpa候选域名：
1. If the number of mask bits m is greater than or equal to 24 but less than or equal to 32, then the candidate domain name is n-m.z.y.x.in-addr.arpa.
1. 如果掩码比特数m大于或等于24但小于或等于32，则候选域名为n-m.z.y.x.in-addr.arpa。
2. If the number of mask bits m is greater than or equal to 16 but less than 24, then the candidate domain name is z-m.y.x.in-addr.arpa.
2. 如果掩码比特数m大于或等于16但小于24，则候选域名为z-m.y.x.in-addr.arpa。
3. If the number of mask bits m is greater than or equal to 8 but less than 16, then the candidate domain name is y-m.x.in-addr.arpa.
3. 如果掩码比特数m大于或等于8但小于16，则候选域名为y-m.x.in-addr.arpa。
4. The notion of fewer than 8 mask bits is not reasonable.
4. 少于8个掩码位的概念是不合理的。
3. Perform a DNS lookup for a PTR record for the candidate domain name.
3. 对候选域名的PTR记录执行DNS查找。
4. If the PTR records returned from looking up the candidate domain name are of the form of a domain name for a network as defined previously (Section 2), then for each PTR record reduce that returned domain name to the canonical form p1-q1.z1.y1.x1.in-addr.arpa. This represents a network x1.y1.z1.p1/q1.
4. 如果查询候选域名返回的PTR记录的形式为之前定义的网络域名（第2节），则对于每个PTR记录，将返回的域名减少为规范形式p1-q1.z1.y1.x1.in-addr.arpa。这表示网络x1.y1.z1.p1/q1。
1. If one of the x1.y1.z1.p1/q1 subnets contains the original IP address x.y.z.w, then the PTR record return becomes the new candidate domain name. Repeat steps 3-4.
1. 如果x1.y1.z1.p1/q1子网之一包含原始IP地址x.y.z.w，则PTR记录返回将成为新的候选域名。重复步骤3-4。
2. If none of the x1.y1.z1.p1/q1 subnets contain the original IP address x.y.z.w, then this process has failed.
2. 如果x1.y1.z1.p1/q1子网均不包含原始IP地址x.y.z.w，则此过程失败。
5. If the PTR record(s) for the candidate network is not of the form of a network domain name, then they are presumed to be the hostname(s) of the gateway(s) for the subnet being resolved.
5. 如果候选网络的PTR记录不是网络域名的形式，则假定它们是正在解析的子网的网关主机名。
6. If the PTR lookup fails (no PTR records are returned).
6. 如果PTR查找失败（不返回PTR记录）。
1. If no candidate network PTR lookup for this IP address has succeeded in the past and the netmask for the last candidate network was 24 or 16 bits long, then presume a netmask of 8 fewer bits for the candidate network and repeat steps 2-4.
1. 如果过去没有成功查找该IP地址的候选网络PTR，并且最后一个候选网络的网络掩码长度为24或16位，则假定候选网络的网络掩码少8位，并重复步骤2-4。
2. If no candidate network PTR lookup for this IP address has succeeded in the past and the netmask of the last candidate network was not 24 or 16 bits long, then increase the netmask by 1 bit and repeat steps 2-4.
2. 如果过去没有成功查找此IP地址的候选网络PTR，并且最后一个候选网络的网络掩码不是24或16位长，则将网络掩码增加1位，然后重复步骤2-4。
3. If a candidate network PTR lookup for this IP address has succeeded in the past or the netmask of the last candidate network was 32 bits, then this process has failed.
3. 如果此IP地址的候选网络PTR查找过去已成功，或者最后一个候选网络的网络掩码为32位，则此过程失败。
7. Perform a DNS A record lookup for the domain name of the gateway to determine the IP number of the gateway.
7. 对网关的域名执行DNS a记录查找，以确定网关的IP号。
RFC 3513 [5] requires all IPv6 unicast addresses that do not begin with binary 000 have a 64-bit interface ID. From the point of view of identifying the last hop router for an IPv6 unicast address, this means that almost all hosts may be considered to live on a /64 subnet. Given the requirement that for any subnet there must be an anycast address for the routers on that subnet, the process described for IPv4 in this document can just as easily be achieved by querying the anycast address via SNMP. Therefore, this document does not speak to providing a DNS-based mechanism for IPv6.
RFC 3513[5]要求所有不以二进制000开头的IPv6单播地址具有64位接口ID。从标识IPv6单播地址的最后一跳路由器的角度来看，这意味着几乎所有主机都可以被视为位于/64子网上。鉴于任何子网都必须有该子网上路由器的选播地址的要求，本文档中描述的IPv4过程也可以通过SNMP查询选播地址轻松实现。因此，本文档不涉及为IPv6提供基于DNS的机制。
Imagine we begin with the IP number 10.15.162.3.
假设我们从IP号10.15.162.3开始。
1. Form a candidate network of 10.15.162.0/24.
1. 形成10.15.162.0/24的候选网络。
2. Form a domain name 0-24.162.15.10.in-addr.arpa.
2. 形成域名0-24.162.15.10.in-addr.arpa。
3. Look up the PTR records for 0-24.162.15.10.in-addr.arpa.
3. 查找0-24.162.15.10.in-addr.arpa的PTR记录。
4. Suppose the lookup fails ( no PTR records returned ), then
4. 假设查找失败（没有返回PTR记录），则
5. Form a new candidate network 10.15.0.0/16.
5. 形成新的候选网络10.15.0.0/16。
6. Form a domain name 0-16.15.10.in-addr.arpa.
6. 形成域名0-16.15.10.in-addr.arpa。
7. Look up the PTR records for 0-16.15.10.in-addr.arpa.
7. 查找0-16.15.10.in-addr.arpa的PTR记录。
8. Lookup returns: 1. 0-17.15.10.in-addr.arpa. 2. 128-18.15.10.in-addr.arpa. 3. 192-18.15.10.in-addr.arpa.
8. 查找返回：1。0-17.15.10.in-addr.arpa。2.128-18.15.10.in-addr.arpa。3.192-18.15.10.in-addr.arpa。
9. So 10.15.0.0/16 is subnetted into 10.15.0.0/17, 10.15.128.0/18, and 10.15.192.0/18.
9. 因此，10.15.0.0/16被分为10.15.0.0/17、10.15.128.0/18和10.15.192.0/18。
10. Since 10.15.162.3 is in 10.15.128.0/18, the new candidate domain name is 128-18.15.10.in-addr.arpa.
10. 由于10.15.162.3在10.15.128.0/18中，新的候选域名是128-18.15.10.in-addr.arpa。
11. Look up the PTR records for 128-18.15.10.in-addr.arpa.
11. 查找128-18.15.10.in-addr.arpa的PTR记录。
12. Lookup returns 1. 128-19.128-18.15.10.in-addr.arpa. 2. 0-25.160.128-18.15.10.in-addr.arpa. 3. 128-25.160.128-18.15.10.in-addr.arpa. 4. 0-24.161.128-18.15.10.in-addr.arpa. 5. 162-23.128-18.15.10.in-addr.arpa.
12. 查找返回1。128-19.128-18.15.10.in-addr.arpa。2.0-25.160.128-18.15.10.in-addr.arpa。3.128-25.160.128-18.15.10.in-addr.arpa。4.0-24.161.128-18.15.10.in-addr.arpa。5.162-23.128-18.15.10.in-addr.arpa。
13. The canonical network domains for these returned records are 1. 128-19.15.10.in-addr.arpa. 2. 0-25.160.15.10.in-addr.arpa. 3. 128-25.160.15.10.in-addr.arpa. 4. 0-24.161.15.10.in-addr.arpa. 5. 162-23.15.10.in-addr.arpa.
13. 这些返回记录的规范网络域为1。128-19.15.10.in-addr.arpa。2.0-25.160.15.10.in-addr.arpa。3.128-25.160.15.10.in-addr.arpa。4.0-24.161.15.10.in-addr.arpa。5.162-23.15.10.in-addr.arpa。
14. So the network 10.15.128.0/18 is subnetted into 10.15.128.0/19, 10.15.160.0/25, 10.15.160.128/25, 10.15.161.0/25, 10.15.162.0/ 23.
14. 因此，网络10.15.128.0/18被分为10.15.128.0/19、10.15.160.0/25、10.15.160.128/25、10.15.161.0/25、10.15.162.0/23。
15. Since 10.15.162.3 is in 10.15.162.0/23, the new candidate domain name is 162-23.128-18.15.10.in-addr.arpa.
15. 由于10.15.162.3位于10.15.162.0/23中，因此新的候选域名为162-23.128-18.15.10.in-addr.arpa。
16. Look up the PTR records for 162-23.128-18.15.10.in-addr.arpa.
16. 查找162-23.128-18.15.10.in-addr.arpa的PTR记录。
17. Lookup returns: 1. gw1.example.net. 2. gw2.example.net.
17. 查找返回：1。gw1.example.net。2.gw2.example.net。
18. Look up the A records for gw1.example.net. and gw2.example.net.
18. 查找gw1.example.net的A记录。和gw2.example.net。
19. Lookup returns 1. gw1.example.net: 10.15.162.1 2. gw2.example.net: 10.15.162.2
19. 查找返回1。gw1.example.net:10.15.162.12。gw2.example.net:10.15.162.2
So the 10.15.162.3 is in network 10.15.162.0/23, which has gateways 10.15.162.1 and 10.15.162.2.
因此，10.15.162.3位于网络10.15.162.0/23中，该网络具有网关10.15.162.1和10.15.162.2。
The example of the lookup procedure (Section 4.3) would require DNS records as follows:
查找过程的示例（第4.3节）要求DNS记录如下：
In entity A's DNS zone files: 0-16.15.10.in-addr.arpa. IN PTR 0-17.15.10.in-addr.arpa. 0-16.15.10.in-addr.arpa. IN PTR 128-18.15.10.in-addr.arpa. 0-16.15.10.in-addr.arpa. IN PTR 192-18.15.10.in-addr.arpa. 0-17.15.10.in-addr.arpa. IN NS ns1.example.org 128-18.15.10.in-addr.arpa. IN NS ns1.example.net 192-18.15.10.in-addr.arpa. IN NS ns1.example.com ns1.example.net IN A 10.15.0.50 ns1.example.org IN A 10.15.128.50 ns1.example.com IN A 10.15.192.50
在实体A的DNS区域文件中：0-16.15.10.In-addr.arpa。在PTR 0-17.15.10.IN-addr.arpa中。0-16.15.10.in-addr.arpa。在PTR 128-18.15.10.IN-addr.arpa中。0-16.15.10.in-addr.arpa。在PTR 192-18.15.10.IN-addr.arpa中。0-17.15.10.in-addr.arpa。在NS ns1.example.org 128-18.15.10.IN-addr.arpa中。在NS ns1.example.net 192-18.15.10.IN-addr.arpa中。在10.15.0.50 ns1.example.org中的NS ns1.example.com中，在10.15.192.50中的ns1.example.com中
In entity B's DNS zone files: 128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 128-25.160.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa. 128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa. 162-23.128-18.15.10.in-addr.arpa. IN PTR gw1.example.net. 162-23.128-18.15.10.in-addr.arpa. IN PTR gw2.example.net. gw1.example.net. IN A 10.15.162.1 gw2.example.net. IN A 10.15.162.2
在实体B的DNS区域文件中：128-18.15.10.In-addr.arpa。在PTR 128-19.128-18.15.10.IN-addr.arpa中。128-18.15.10.in-addr.arpa。在PTR 0-25.160.128-18.15.10.IN-addr.arpa中。128-18.15.10.in-addr.arpa。在PTR 128-25.160.128-18.15.10.IN-addr.arpa中。128-18.15.10.in-addr.arpa。在PTR 0-24.161.128-18.15.10.IN-addr.arpa中。128-18.15.10.in-addr.arpa。在PTR 162-23.128-18.15.10.IN-addr.arpa中。162-23.128-18.15.10.in-addr.arpa。在PTR gw1.example.net中。162-23.128-18.15.10.in-addr.arpa。在PTR gw2.example.net中。gw1.example.net。在10.15.162.1 gw2.example.net中。在A 10.15.162.2中
Proper functioning of this method may required the cooperation of upstream network providers. Not all upstream network providers may wish to implement this method. If an upstream provider does not wish to implement this method, the method may still be used with an alternate domain suffix.
该方法的正常运行可能需要上游网络提供商的合作。并非所有上游网络提供商都希望实现此方法。如果上游提供程序不希望实现此方法，则该方法仍可与备用域后缀一起使用。
For example, if the upstream network provider of example.com did not wish to provide glue records in its branch of the in-addr.arpa. domain, then example.com might elect to use the suffix in-addr.example.com as an alternate domain suffix for that purpose.
例如，如果example.com的上游网络提供商不希望在其in-addr.arpa分支中提供粘合记录。域，则example.com可能会选择使用后缀in-addr.example.com作为替代域后缀。
For this reason, implementations of clients intending to use this method should use in-addr.arpa. as the default suffix, but allow for configuration of an alternate suffix.
因此，打算使用此方法的客户端的实现应该使用in-addr.arpa。作为默认后缀，但允许配置备用后缀。
Any revelation of information to the public internet about the internal structure of your network may make it easier for nefarious persons to mount diverse attacks upon a network. Consequently, care should be exercised in deciding which (if any) of the DNS resource records described in this document should be made visible to the public internet.
任何向公共互联网披露有关您网络内部结构的信息都可能会使恶棍更容易对网络发起各种攻击。因此，在决定本文档中描述的哪些DNS资源记录（如果有）应在公共互联网上可见时，应小心谨慎。
[1] Mockapetris, P., "Domain Names - Implementation and Specficication", STD 13, RFC 1035, November 1987.
[1] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[2] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, April 1989.
[2] Mockapetris，P.，“网络名称和其他类型的DNS编码”，RFC1101，1989年4月。
[3] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", RFC 2317, March 1998.
[3] Eidens，H.，de Groot，G.和P.Vixie，“无类别地址ARPA代表团”，RFC 2317，1998年3月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[5] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[6] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[6] Alvestrand，H.，“IESG和RFC编辑文件：程序”，BCP 92，RFC 3932，2004年10月。
Author's Address
作者地址
Edward A. Warnicke Cisco Systems Inc. 12515 Research Blvd., Building 4 Austin, TX 78759 USA
Edward A.Warnicke Cisco Systems Inc.美国德克萨斯州奥斯汀市研究大道12515号4号楼，邮编78759
Phone: (919) 392-8489 EMail: eaw@cisco.com
电话：（919）392-8489电子邮件：eaw@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。