Network Working Group E. Gray
Request for Comments: 4548 J. Rutemiller
Updates: 1888, 4048 Ericsson
Category: Standards Track G. Swallow
Cisco Systems, Inc.
May 2006
Network Working Group E. Gray
Request for Comments: 4548 J. Rutemiller
Updates: 1888, 4048 Ericsson
Category: Standards Track G. Swallow
Cisco Systems, Inc.
May 2006
Internet Code Point (ICP) Assignments for NSAP Addresses
NSAP地址的互联网代码点（ICP）分配
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments.
本文档旨在完成两项高度相关的任务：为网络服务接入点（NSAP）地址中的IPv4和IPv6地址编码建立“初始”互联网代码点（ICP）分配，并为当前未分配的ICP值推荐IANA分配策略。在第一项任务中，本文件部分替代了RFC 1888，尤其是RFC 1888的第6节。在第二项任务中，本文件纳入了ITU-T建议X.213中的措辞和规范，并进一步建议IANA在未来的ICP分配中使用“IETF共识”分配政策。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions ................................................2
1.2. Acronyms and Terminology ...................................3
2. IANA Considerations .............................................3
3. Initial Allocations and Uses ....................................4
3.1. IPv4 Address Encoding in an NSAPA ..........................4
3.2. IPv6 Address Encoding in an NSAPA ..........................5
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
1. Introduction ....................................................2
1.1. Conventions ................................................2
1.2. Acronyms and Terminology ...................................3
2. IANA Considerations .............................................3
3. Initial Allocations and Uses ....................................4
3.1. IPv4 Address Encoding in an NSAPA ..........................4
3.2. IPv6 Address Encoding in an NSAPA ..........................5
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Section 6 of RFC 1888 [1888] previously provided for assignment of the initial Internet Code Point (ICP) value '0' for encoding an IPv6 address in a Network Service Access (or Attachment) Point [NSAP] address. RFC 1888 also defined multiple means for restricted encoding of an NSAP address in an IPv6 address.
RFC 1888[1888]第6节先前规定了初始互联网代码点（ICP）值“0”的分配，用于在网络服务访问（或连接）点[NSAP]地址中编码IPv6地址。RFC 1888还为IPv6地址中NSAP地址的受限编码定义了多种方式。
The means RFC 1888 defined for encoding NSAP addresses in IPv6 address format was heavily annotated with warnings and limitations that apply should this encoding be used. Possibly as a result, these encodings are not used and appear never to have been used in any IPv6 deployment. In addition, section 6 contains minor errors. As a result of these various considerations, RFC 1888 [1888] has been obsoleted and declared Historic by RFC 4048 [4048].
定义用于以IPv6地址格式编码NSAP地址的方法RFC 1888带有大量的警告和限制注释，如果使用这种编码，这些警告和限制将适用。可能因此，这些编码未被使用，而且似乎从未在任何IPv6部署中使用过。此外，第6节还包含一些小错误。由于这些不同的考虑，RFC 1888[1888]已被淘汰，并被RFC 4048[4048]宣布为历史。
It is the belief of the authors of this document that the errors in section 6 of RFC 1888 resulted -- at least in part -- because the ITU-T specification [X.213] that originally assigned Authority and Format Identifier (AFI) '35' to IANA was not freely publicized, nor was it incorporated or explained using the mechanism commonly used in the IETF, i.e., an RFC.
本文件作者认为，RFC 1888第6节中的错误至少部分是由于最初向IANA分配权限和格式标识符（AFI）“35”的ITU-T规范[X.213]未自由公布，也未使用IETF中常用的机制对其进行合并或解释，即RFC。
It is therefore part of the purpose of this document to provide that explanation.
因此，本文件的目的之一就是提供这种解释。
In addition, because there are other documents that refer to the IPv6 ICP assignment in RFC 1888, it is necessary for the errors in section 6 of RFC 1888 to be corrected, irrespective of the RFC's ultimate status.
此外，由于RFC 1888中有其他文件涉及IPv6 ICP分配，因此有必要纠正RFC 1888第6节中的错误，而不管RFC的最终状态如何。
Finally, no previous RFC (including RFC 1888) has ever formalized an assignment of an IPv4 ICP. This may have been in part because of a lack of formal definition of an IANA assignment policy for ICP values under the IANA-allocated AFI ('35').
最后，以前的RFC（包括RFC1888）从未正式确定IPv4 ICP的分配。这可能部分是因为缺乏IANA分配AFI（“35”）下ICP值的IANA分配政策的正式定义。
This document replaces section 6 of RFC 1888 in defining the ICP for IPv6 address encoding in an NSAP address, and it formalizes the ICP assignment for IPv4 address encoding in an NSAP address.
本文件取代了RFC 1888第6节，定义了NSAP地址中IPv6地址编码的ICP，并正式规定了NSAP地址中IPv4地址编码的ICP分配。
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 [2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2119]中所述进行解释。
AFI - Authority and Format Identifier BCD - Binary Coded Decimal DSP - Domain Specific Part IANA - Internet Assigned Numbers Authority ICP - Internet Code Point IDI - Initial Domain Identifier IDP - Initial Domain Part IETF - Internet Engineering Task Force ISO - International Organization for Standardization NSAP - Network Service Access (or Attachment) Point (often NSAPA) NSAPA - NSAP Address; 20-Octet Address Format OSI - Open Systems Interconnection RFC - Request For Comments WIP - Work In Progress
AFI-权限和格式标识符BCD-二进制编码十进制DSP-域特定部分IANA-互联网分配号码管理局ICP-互联网代码点IDI-初始域标识符IDP-初始域部分IETF-互联网工程任务组ISO-国际标准化组织NSAP-网络服务访问（或附件）点（通常为NSAPA）NSAPA-NSAP地址；20位字节地址格式OSI-开放系统互连RFC-征求意见WIP-正在进行的工作
An ITU-T Recommendation [X.213] has allocated two AFIs designating IANA as the assignment authority. One of these two AFIs ('34') is allocated for assignment of NSAPA in Decimal Numeric Format. This document does not address allocation for this AFI as it is not clear what use (if any) can be made of this encoding format at this time. The other AFI ('35') is to be used for binary encoding except as noted below.
ITU-T建议[X.213]分配了两个AFI，指定IANA为分配机构。这两个AFI（“34”）中的一个被分配用于以十进制数字格式分配NSAPA。本文件未说明此AFI的分配，因为目前尚不清楚此编码格式的用途（如有）。另一个AFI（'35'）将用于二进制编码，以下说明除外。
The NSAPA format consists of an Initial Domain Part (IDP) and Domain Specific Part (DSP). The IDP, in turn, consists of an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI is defined to be a binary octet, and the IDI is defined to be a four decimal digit number encoded in two octets using Binary Coded Decimal format. Each nibble of the IDI is used to represent a decimal digit, using binary value '0000' through '1001'.
NSAPA格式由初始域部分（IDP）和域特定部分（DSP）组成。IDP又由授权和格式标识符（AFI）和初始域标识符（IDI）组成。AFI定义为二进制八位字节，IDI定义为使用二进制编码十进制格式以两个八位字节编码的四位十进制数字。IDI的每个半字节使用二进制值“0000”到“1001”表示一个十进制数字。
In assigning allocation authority for AFI '35' to IANA, the ITU-T Recommendation [X.213] specifies that the two-octet IDI will be used to hold an Internet Code Point (ICP) that, because of the decimal encoding, MUST be in the decimal range from '0' to '9999'.
在将AFI“35”的分配权限分配给IANA时，ITU-T建议[X.213]规定，两个八位组IDI将用于保存互联网代码点（ICP），由于十进制编码，该点必须在“0”到“9999”之间的十进制范围内。
The ITU-T recommendation assumes the assignment of ICP '0' (zero) for IPv6 address encoding in a Network Service Access Point Address (NSAPA, or often NSAP). In addition, ITU-T assumed that IANA would assign an ICP for IPv4 address encoding in an NSAPA and X.213 assumed that the ICP value for this purpose would be '1'.
IPv6或NSAP网络地址分配（建议为0）通常采用IPv6“0”接入点编码（建议为NSAP网络地址分配）。此外，ITU-T假设IANA将为NSAPA中的IPv4地址编码分配ICP，X.213假设用于此目的的ICP值为“1”。
In an NSAPA, the DSP is the remaining octets after the IDP. For AFI '35', this is 17 octets having a format as defined by IANA or as defined by another party and published with IANA consent.
在NSAPA中，DSP是IDP之后的剩余八位字节。对于AFI“35”，这是17个八位字节，其格式由IANA定义或由另一方定义，并经IANA同意发布。
IANA, as the authority responsible for AFI '35', SHOULD NOT assign an ICP unless there is a corresponding defined, and published, format at the time of the code point assignment.
IANA作为负责AFI“35”的机构，不应分配ICP，除非在分配代码点时有相应的定义和公布的格式。
The IANA has assigned the following ICP values:
IANA分配了以下ICP值：
ICP Value Address Encoding Format Definition
---------- ----------------- ----------------------------
'0' IPv6 RFC 4548, section 3.2
'1' IPv4 RFC 4548, section 3.1
ICP Value Address Encoding Format Definition
---------- ----------------- ----------------------------
'0' IPv6 RFC 4548, section 3.2
'1' IPv4 RFC 4548, section 3.1
Remaining decimal values '2' through '9999' MUST be assigned on an IETF consensus basis [2434].
剩余的十进制值“2”到“9999”必须在IETF一致同意的基础上分配[2434]。
This document continues the ICP assignment and format definition as previously defined in RFC 1888, and it formalizes the allocation of ICP value '1' for IPv4 encoding and the format to be used. The sections below describe the specific IPv4 and IPv6 address encoding formats.
本文件延续了RFC 1888中先前定义的ICP分配和格式定义，并正式确定了IPv4编码的ICP值“1”的分配和使用的格式。以下各节描述了特定的IPv4和IPv6地址编码格式。
If it is required, for whatever reason, to embed an IPv4 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage.
如果出于任何原因需要将IPv4地址嵌入20个八位组的NSAP地址中，则必须使用以下格式。注意：对齐是现有NSAPA使用的产物。
A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow Connectionless Network Protocol (CLNP) packets that encapsulate IPv4 packets to be routed in a CLNP network using the IPv4 address architecture. Several leading octets of the IPv4 address could be used as a CLNP routing prefix.
这种嵌入的一个具体可能用途是在ATM论坛地址格式中表示IP地址。另一种可能的用途是允许封装IPv4数据包的无连接网络协议（CLNP）数据包使用IPv4地址体系结构在CLNP网络中路由。IPv4地址的几个前导八位字节可以用作CLNP路由前缀。
An NSAPA with an AFI value of '35' and an ICP value of '1' (one) encodes a 4-octet IPv4 address in the first 4 octets of the DSP. The last 13 octets of the DSP are unspecified in this document. To maintain compatibility with both NSAP format and IPv4 addressing, these octets MUST be present, but have no intrinsic significance for IPv4. The default values for the unspecified octets is zero.
AFI值为“35”、ICP值为“1”（一）的NSAPA在DSP的前4个八位字节中编码4个八位字节的IPv4地址。本文件未指定DSP的最后13个八位字节。为了保持与NSAP格式和IPv4寻址的兼容性，这些八位字节必须存在，但对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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0001 | IPv4 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv4 (octets 1-3) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0001 | IPv4 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv4 (octets 1-3) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An NSAPA with the IANA AFI code and ICP set to '1' (one) is converted to an IPv4 address by stripping off the first 3 and the last 13 octets. If the NSAP-addressed contents are passed to a higher layer, the last 13 octets SHOULD be presented to the higher layer as well.
IANA AFI代码和ICP设置为“1”（一）的NSAPA通过剥离前3个和后13个八位字节转换为IPv4地址。如果NSAP寻址内容被传递到更高的层，那么最后13个八位组也应该呈现给更高的层。
If an NSAP address using this encoding is used for routing in an IPv4 routing architecture, only the 4-octet IPv4 address MAY be considered.
如果使用此编码的NSAP地址用于IPv4路由体系结构中的路由，则只能考虑4个八位组的IPv4地址。
If it is required, for whatever reason, to embed an IPv6 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage.
如果出于任何原因需要将IPv6地址嵌入20个八位组的NSAP地址中，则必须使用以下格式。注意：对齐是现有NSAPA使用的产物。
A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network using the IPv6 address architecture. Several leading octets of the IPv6 address could be used as a CLNP routing prefix.
这种嵌入的一个具体可能用途是在ATM论坛地址格式中表示IP地址。另一个可能的用途是允许使用IPv6地址体系结构在CLNP网络中路由封装IPv6数据包的CLNP数据包。IPv6地址的几个前导八位字节可以用作CLNP路由前缀。
An NSAPA with an AFI value of '35' and an ICP value of '0' (zero) encodes a 16-octet IPv6 address in the first 16 octets of the DSP. The last octet of the DSP is a selector. To maintain compatibility with both NSAP format and IPv6 addressing, this octet MUST be present, but it has no intrinsic significance for IPv6. Its default value is zero, but other values may be used as specified for any specific application. For example, this octet may be used to specify one of 255 possible port numbers.
AFI值为“35”、ICP值为“0”（零）的NSAPA在DSP的前16个八位字节中编码16个八位字节的IPv6地址。DSP的最后一个八位字节是选择器。为了保持与NSAP格式和IPv6寻址的兼容性，必须存在此八位组，但它对IPv6没有本质意义。其默认值为零，但其他值可按指定用于任何特定应用程序。例如，此八位字节可用于指定255个可能的端口号之一。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0000 | IPv6 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (octets 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (octets 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (octets 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (octets 13-15) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0000 | IPv6 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (octets 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (octets 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (octets 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (octets 13-15) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An NSAPA with the IANA AFI code and ICP set to '0' (zero) is converted to an IPv6 address by stripping off the first 3 octets and the 20th octet. If the NSAP-addressed contents are passed to a higher layer, the last octet SHOULD be presented to the higher layer as well.
IANA AFI代码和ICP设置为“0”（零）的NSPA通过剥离前3个八位字节和第20个八位字节转换为IPv6地址。如果NSAP寻址的内容被传递到更高层，那么最后一个八位组也应该呈现给更高层。
If an NSAP address using this encoding is used for routing in an IPv6 routing architecture, only the 16-octet IPv6 address MAY be considered.
如果使用此编码的NSAP地址用于IPv6路由体系结构中的路由，则只能考虑16个八位组的IPv6地址。
The NSAP encoding of IPv4 and IPv6 addresses is compatible with the corresponding security mechanisms of RFC 4301 [4301], hence this document introduces no new security exposure in the Internet.
IPv4和IPv6地址的NSAP编码与RFC 4301[4301]的相应安全机制兼容，因此本文档不会在Internet中引入新的安全暴露。
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[NSAP] International Organization for Standardization, "Information technology - Open Systems Interconnection - Network service Definition", ISO/IEC 8348:2002, 2002.
[NSAP]国际标准化组织，“信息技术-开放系统互连-网络服务定义”，ISO/IEC 8348:2002，2002。
[X.213] ITU-T Recommendation X.213, X-Series Recommendations, Data Networks and Open Systems Communications, October, 2001.
[X.213]ITU-T建议X.213，X系列建议，数据网络和开放系统通信，2001年10月。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[1888]Bound，J.，Carpenter，B.，Harrington，D.，Houldsworth，J.，和A.Lloyd，“OSI NSAP和IPv6”，RFC 18881996年8月。
[4048] Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048, April 2005.
[4048]Carpenter，B.，“RFC 1888已过时”，RFC 4048，2005年4月。
Authors' Addresses
作者地址
Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851
Eric Gray Ericsson马萨诸塞州洛厄尔切姆斯福德街900号，邮编01851
EMail: Eric.Gray@Marconi.com
EMail: Eric.Gray@Marconi.com
John Rutemiller Ericsson 3000 Marconi Drive Warrendale, PA, 15086-7502
约翰·鲁特米勒·爱立信宾夕法尼亚州沃伦代尔马可尼大道3000号，邮编：15086-7502
EMail: John.Rutemiller@Marconi.com
EMail: John.Rutemiller@Marconi.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719
乔治·斯沃诺思科系统公司，地址：马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编：01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。