Internet Engineering Task Force (IETF) S. Kawamura
Request for Comments: 5952 NEC BIGLOBE, Ltd.
Updates: 4291 M. Kawashima
Category: Standards Track NEC AccessTechnica, Ltd.
ISSN: 2070-1721 August 2010
Internet Engineering Task Force (IETF) S. Kawamura
Request for Comments: 5952 NEC BIGLOBE, Ltd.
Updates: 4291 M. Kawashima
Category: Standards Track NEC AccessTechnica, Ltd.
ISSN: 2070-1721 August 2010
A Recommendation for IPv6 Address Text Representation
IPv6地址文本表示的建议
Abstract
摘要
As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.
随着IPv6部署的增加，在文本中使用IPv6地址的需求将急剧增加。虽然RFC 4291第2.2节中的IPv6地址体系结构描述了IPv6地址文本表示的灵活模型，但这种灵活性一直给运营商、系统工程师和用户带来问题。本文档定义了一种规范的文本表示格式。它不定义内部存储的格式，例如在应用程序或数据库中。预计人类和系统在将IPv6地址表示为文本时将遵循规范格式，但所有实现都必须接受并能够处理任何合法的RFC 4291格式。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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/rfc5952.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5952.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4
2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4
2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
3. Problems Encountered with the Flexible Model . . . . . . . . . 6
3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
3.1.4. Searching for an Address in a Network Diagram . . . . 7
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10
4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Text Representation of Special Addresses . . . . . . . . . . . 11
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4
2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4
2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
3. Problems Encountered with the Flexible Model . . . . . . . . . 6
3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
3.1.4. Searching for an Address in a Network Diagram . . . . 7
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10
4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Text Representation of Special Addresses . . . . . . . . . . . 11
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
A single IPv6 address can be text represented in many ways. Examples are shown below.
单个IPv6地址可以用多种方式进行文本表示。示例如下所示。
2001:db8:0:0:1:0:0:1
2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1
2001:DB8:0:0:1::1
All of the above examples represent the same IPv6 address. This flexibility has caused many problems for operators, systems engineers, and customers. The problems are noted in Section 3. A canonical representation format to avoid problems is introduced in Section 4.
以上所有示例都表示相同的IPv6地址。这种灵活性给运营商、系统工程师和客户带来了许多问题。第3节指出了这些问题。第4节介绍了避免问题的规范表示格式。
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]中所述进行解释。
Examples of flexibility in Section 2.2 of [RFC4291] are described below.
[RFC4291]第2.2节中的灵活性示例如下所述。
'It is not necessary to write the leading zeros in an individual field.'
'不必在单个字段中写入前导零。'
Conversely, it is also not necessary to omit leading zeros. This means that it is possible to select from representations such as those in the following example. The final 16-bit field is different, but all of these addresses represent the same address.
相反，也没有必要省略前导零。这意味着可以从以下示例中的表示中进行选择。最后的16位字段不同，但所有这些地址都表示相同的地址。
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
'A special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros.'
'一种特殊语法可用于压缩零。使用“：”表示一组或多组16位零
It is possible to select whether or not to omit just one 16-bit 0 field.
可以选择是否仅省略一个16位0字段。
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
In cases where there is more than one field of only zeros, there is a choice of how many fields can be shortened.
如果有多个字段只有零，则可以选择缩短多少字段。
2001:db8:0:0:0::1
2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8:0::1
2001:db8::1
2001:db8::1
In addition, Section 2.2 of [RFC4291] notes,
此外，[RFC4291]注释第2.2节，
'The "::" can only appear once in an address.'
“The”：：“在一个地址中只能出现一次。”
This gives a choice on where in a single address to compress the zero.
这样就可以选择在单个地址的何处压缩零。
2001:db8::aaaa:0:0:1
2001:db8::aaaa:0:0:1
2001:db8:0:0:aaaa::1
2001:db8:0:0:aaaa::1
[RFC4291] does not mention any preference of uppercase or lowercase.
[RFC4291]未提及大写或小写的任何首选项。
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
A search of an IPv6 address if conducted through a UNIX system is usually case sensitive and extended options that allow for regular expression use will come in handy. However, there are many applications in the Internet today that do not provide this capability. When searching for an IPv6 address in such systems, the system engineer will have to try each and every possibility to search for an address. This has critical impacts, especially when trying to deploy IPv6 over an enterprise network.
如果通过UNIX系统进行IPv6地址搜索，则通常区分大小写，允许使用正则表达式的扩展选项将派上用场。然而，当今互联网上有许多应用程序不提供这种功能。在此类系统中搜索IPv6地址时，系统工程师必须尽一切可能搜索地址。这会产生关键影响，尤其是在试图通过企业网络部署IPv6时。
Spreadsheet applications and text editors on GUI systems rarely have the ability to search for text using regular expression. Moreover, there are many non-engineers (who are not aware of case sensitivity and regular expression use) that use these applications to manage IP addresses. This has worked quite well with IPv4 since text representation in IPv4 has very little flexibility. There is no incentive to encourage these non-engineers to change their tool or learn regular expression when they decide to go dual-stack. If the entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was conducted as 2001:db8:0:0:1::1, this will show a result of no match. One example where this will cause a problem is, when the search is being conducted to assign a new address from a pool, and a check is being done to see if it is not in use. This may cause problems for the end-hosts or end-users. This type of address management is very often seen in enterprise networks and ISPs.
GUI系统上的电子表格应用程序和文本编辑器很少能够使用正则表达式搜索文本。此外，还有许多非工程师（他们不知道大小写敏感度和正则表达式的使用）使用这些应用程序来管理IP地址。这在IPv4中非常有效，因为IPv4中的文本表示几乎没有灵活性。当这些非工程师决定使用双堆栈时，并没有激励他们改变他们的工具或学习正则表达式。如果电子表格中的条目显示为，2001:db8:：1:0:0:1，但搜索是按2001:db8:0:0:1:：1进行的，这将显示不匹配的结果。这将导致问题的一个示例是，当执行搜索以从池中分配新地址时，正在进行检查以查看该地址是否未被使用。这可能会给最终主机或最终用户带来问题。这种地址管理在企业网络和ISP中非常常见。
The "whois" utility is used by a wide range of people today. When a record is set to a database, one will likely check the output to see if the entry is correct. If an entity was recorded as 2001:db8::/48,
“whois”实用程序现在被许多人使用。当一条记录被设置到数据库时，人们可能会检查输出以查看条目是否正确。如果实体记录为2001:db8:：/48，
but the whois output showed 2001:0db8:0000::/48, most non-engineers would think that their input was wrong and will likely retry several times or make a frustrated call to the database hostmaster. If there was a need to register the same prefix on different systems, and each system showed a different text representation, this would confuse people even more. Although this document focuses on addresses rather than prefixes, it is worth mentioning the prefix problems because the problems encountered with addresses and prefixes are mostly equal.
但是whois的输出显示为2001:0db8:0000:：/48，大多数非工程师会认为他们的输入是错误的，可能会重试几次，或者对数据库主机进行失败的调用。如果需要在不同的系统上注册相同的前缀，并且每个系统显示不同的文本表示，这将使人们更加困惑。尽管本文档关注的是地址而不是前缀，但值得一提的是前缀问题，因为地址和前缀遇到的问题基本相同。
Network diagrams and blueprints often show what IP addresses are assigned to a system devices. In times of trouble shooting there may be a need to search through a diagram to find the point of failure (for example, if a traceroute stopped at 2001:db8::1, one would search the diagram for that address). This is a technique quite often in use in enterprise networks and managed services. Again, the different flavors of text representation will result in a time-consuming search leading to longer mean times to restoration (MTTR) in times of trouble.
网络图和蓝图通常显示分配给系统设备的IP地址。在故障排除时，可能需要搜索图表以找到故障点（例如，如果跟踪路由在2001:db8:：1停止，则需要在图表中搜索该地址）。这是一种在企业网络和托管服务中经常使用的技术。同样，不同风格的文本表示将导致耗时的搜索，从而在出现故障时导致更长的平均恢复时间（MTTR）。
With all the possible methods of text representation, each application must include a module, object, link, etc. to a function that will parse IPv6 addresses in a manner such that no matter how it is represented, they will mean the same address. Many system engineers who integrate complex computer systems for corporate customers will have difficulties finding that their favorite tool will not have this function, or will encounter difficulties such as having to rewrite their macros or scripts for their customers.
对于所有可能的文本表示方法，每个应用程序都必须包括模块、对象、链接等，以解析IPv6地址的方式连接到一个函数，以便无论如何表示IPv6地址，它们都表示相同的地址。许多为公司客户集成复杂计算机系统的系统工程师将很难发现他们喜欢的工具不具备此功能，或者会遇到困难，例如必须为客户重写宏或脚本。
If an application were to output a log summary that represented the address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), the output would be highly unreadable compared to the IPv4 output. The address would have to be parsed and reformed to make it useful for human reading. Sometimes logging for critical systems is done by mirroring the same traffic to two different systems. Care must be taken so that no matter what the log output is, the logs should be parsed so they are equivalent.
如果应用程序要输出完整表示地址的日志摘要（例如2001:0db8:0000:0000:1111:2222:3333:4444），则与IPv4输出相比，该输出将非常不可读。必须对地址进行解析和修改，使其对人类阅读有用。有时，关键系统的日志记录是通过将相同的通信量镜像到两个不同的系统来完成的。必须注意，无论日志输出是什么，都应该对日志进行解析，使其等效。
When a router or any other network appliance machine configuration is audited, there are many methods to compare the configuration information of a node. Sometimes auditing will be done by just comparing the changes made each day. In this case, if configuration was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 0000:0000:0000:0001 just because the new engineer on the block felt it was better, a simple diff will show that a different address was configured. If this was done on a wide scale network, people will be focusing on 'why the extra zeros were put in' instead of doing any real auditing. Lots of tools are just plain diffs that do not take into account address representation rules.
在审核路由器或任何其他网络设备计算机配置时，有许多方法可以比较节点的配置信息。有时，审计只是通过比较每天所做的更改来完成。在这种情况下，如果配置完成后，2001:db8:：1更改为2001:0db8:0000:0000:0000:0000:0001，只是因为块上的新工程师觉得更好，那么简单的差异将显示配置了不同的地址。如果这是在一个大范围的网络上进行的，人们将把注意力集中在“为什么额外的零被放入”上，而不是进行任何真正的审计。许多工具只是简单的差异，没有考虑地址表示规则。
Node configurations will be matched against an information system that manages IP addresses. If output notation is different, there will need to be a script that is implemented to cover for this. The result of an SNMP GET operation, converted to text and compared to a textual address written by a human is highly unlikely to match on the first try.
节点配置将与管理IP地址的信息系统相匹配。如果输出符号不同，则需要实现一个脚本来覆盖这一点。将SNMP GET操作的结果转换为文本并与人工编写的文本地址进行比较，在第一次尝试时很可能不匹配。
Some protocols require certain data fields to be verified. One example of this is X.509 certificates. If an IPv6 address field in a certificate was incorrectly verified by converting it to text and making a simple textual comparison to some other address, the certificate may be mistakenly shown as being invalid due to a difference in text representation methods.
某些协议需要验证某些数据字段。其中一个例子是X.509证书。如果证书中的IPv6地址字段通过将其转换为文本并与其他地址进行简单的文本比较而被错误验证，则由于文本表示方法的不同，该证书可能会错误地显示为无效。
Sometimes, a system will take an address and modify it as a convenience. For example, a system may take an input of 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were input for a reason, the outcome may be somewhat unexpected.
有时，一个系统会接受一个地址并修改它作为一种方便。例如，系统可能接受2001:0db8:0:：1的输入，并使输出为2001:db8:：1。如果输入零是有原因的，那么结果可能有些出乎意料。
When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 0:0:1, the system may take the address and show the configuration result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address representation will know that the right address is set, but not everyone may understand this.
当操作员将系统的IPv6地址设置为2001:db8:0:0:1:0:0:1时，系统可能会获取该地址并将配置结果显示为2001:db8:：1:0:0:1。熟悉IPv6地址表示的人会知道设置了正确的地址，但并非每个人都理解这一点。
When a customer calls to inquire about a suspected outage, IPv6 address representation should be handled with care. Not all customers are engineers, nor do they have a similar skill level in IPv6 technology. The network operations center will have to take extra steps to humanly parse the address to avoid having to explain to the customers that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one thing that will never happen in IPv4 because IPv4 addresses cannot be abbreviated.
当客户打电话询问疑似停机时，应小心处理IPv6地址表示。并非所有客户都是工程师，他们在IPv6技术方面也没有类似的技能水平。网络运营中心将不得不采取额外的步骤来人工解析地址，以避免向客户解释2001:db8:0:1:：1与2001:db8:：1:0:0:1相同。这是IPv4中永远不会发生的事情，因为IPv4地址不能缩写。
Network abuse reports generally include the abusing IP address. This 'reporting' could take any shape or form of the flexible model. A team that handles network abuse must be able to tell the difference between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the placement of the "::" will result in a critical situation. A system that handles these incidents should be able to handle any type of input and parse it in a correct manner. Also, incidents are reported over the phone. It is unnecessary to report if the letter is uppercase or lowercase. However, when a letter is spelled uppercase, people tend to specify that it is uppercase, which is unnecessary information.
网络滥用报告通常包括滥用IP地址。这种“报告”可以采取灵活模式的任何形式。处理网络滥用的团队必须能够区分2001:db8:：1:0:1和2001:db8:1:：0:1之间的区别。放置“：”的错误将导致危急情况。处理这些事件的系统应该能够处理任何类型的输入并以正确的方式对其进行解析。此外，事件通过电话报告。如果字母大写或小写，则无需报告。然而，当字母拼写为大写时，人们倾向于指定它为大写，这是不必要的信息。
When an engineer decides to change the platform of a running service, the same code may not work as expected due to the difference in IPv6 address text representation. Usually, a change in a platform (e.g., Unix to Windows, Cisco to Juniper) will result in a major change of code anyway, but flexibility in address representation will increase the work load.
当工程师决定更改正在运行的服务的平台时，由于IPv6地址文本表示的差异，相同的代码可能无法按预期工作。通常，平台的更改（例如，Unix到Windows，Cisco到Juniper）将导致代码的重大更改，但地址表示的灵活性将增加工作负载。
A document that is edited by more than one author may become harder to read.
由多个作者编辑的文档可能更难阅读。
Capital case D and 0 can be quite often misread. Capital B and 8 can also be misread.
大写字母D和0经常被误读。大写字母B和8也可能被误读。
A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address.
本节介绍了IPv6地址的规范文本表示格式的建议。本文件中的建议完全符合[RFC4291]，由各种操作系统实施，且人性化。在生成以文本形式表示的地址时，系统应遵循本节中的建议，但所有实现必须接受并能够处理任何合法的[RFC4291]格式。建议人们在拼写地址时也遵循这些建议。
Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16- bit 0000 field MUST be represented as 0.
必须抑制前导零。例如，2001:0db8:：0001是不可接受的，必须表示为2001:db8:：1。单个16位0000字段必须表示为0。
The use of the symbol "::" MUST be used to its maximum capability. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1.
符号“：”的使用必须最大限度地使用。例如，2001:db8:0:0:0:0:2:1必须缩短为2001:db8:：2:1。同样，2001:db8:：0:1也不可接受，因为符号“：：”可能用于生成较短的表示形式2001:db8:：1。
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
符号“：”不得用于缩短一个16位0字段。例如，表示形式2001:db8:0:1:1:1:1:1是正确的，但2001:db8:：1:1:1:1不正确。
When there is an alternative choice in the placement of a "::", the longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., the sequence with three consecutive zero fields is shortened in 2001: 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct representation.
如果在放置“：”时有其他选择，则必须缩短连续16位0字段的最长运行时间（即，具有三个连续零字段的序列在2001年缩短为：0:0:1:0:0:0:1）。当连续16位0字段的长度相等时（即，2001:db8:0:0:1:0:0:1），必须缩短第一个零位序列。例如，2001:db8:：1:0:0:1是正确的表示形式。
The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase.
IPv6地址中的字符“a”、“b”、“c”、“d”、“e”和“f”必须用小写字母表示。
Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses embedded in the low-order 32 bits of the address. These addresses have a special representation that may mix hexadecimal and dot decimal notations. The decimal notation may be used only for the last 32 bits of the address. For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. Such prefixes are defined in [RFC4291] and [RFC2765] at the time of this writing. If it is known by some external method that a given prefix is used to embed IPv4, it MAY be represented as mixed notation. Tools that provide options to specify prefixes that are (or are not) to be represented as mixed notation may be useful.
诸如IPv4映射IPv6地址、ISATAP[RFC5214]和IPv4可翻译地址[ADDR-FORMAT]等地址的IPv4地址嵌入在地址的低位32位中。这些地址有一种特殊的表示法，可以混合使用十六进制和点十进制表示法。十进制表示法只能用于地址的最后32位。对于这些地址，如果满足以下条件，则建议使用混合表示法：通过使用已知前缀，可以将该地址区分为仅从地址字段中嵌入32位低位的IPv4地址。在撰写本文时，[RFC4291]和[RFC2765]中定义了此类前缀。如果某个外部方法知道某个给定前缀用于嵌入IPv4，则可以将其表示为混合表示法。提供选项以指定（或不）表示为混合表示法的前缀的工具可能很有用。
There is a trade-off here where a recommendation to achieve an exact match in a search (no dot decimals whatsoever) and a recommendation to help the readability of an address (dot decimal whenever possible) does not result in the same solution. The above recommendation is aimed at fixing the representation as much as possible while leaving the opportunity for future well-known prefixes to be represented in a human-friendly manner as tools adjust to newly assigned prefixes.
这里有一个折衷方案，即在搜索中实现精确匹配的建议（无小数点）和帮助地址可读性的建议（尽可能使用小数点）不会产生相同的解决方案。上述建议的目的是尽可能固定表示法，同时在工具调整到新分配的前缀时，为将来以人性化方式表示已知前缀留下机会。
The text representation method noted in Section 4 should be applied for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1).
第4节中所述的文本表示方法应适用于前导的十六进制部分（即：ffff:192.0.2.1，而不是0:0:0:0:0:ffff:192.0.2.1）。
There are many different ways to combine IPv6 addresses and port numbers that are represented in text. Examples are shown below.
有许多不同的方法可以组合文本中表示的IPv6地址和端口号。示例如下所示。
o [2001:db8::1]:80
o [2001:db8::1]:80
o 2001:db8::1:80
o 2001:db8::1:80
o 2001:db8::1.80
o 2001:db8::1.80
o 2001:db8::1 port 80
o 2001:db8::1 port 80
o 2001:db8::1p80
o 2001:db8::1p80
o 2001:db8::1#80
o 2001:db8::1#80
The situation is not much different in IPv4, but the most ambiguous case with IPv6 is the second bullet. This is due to the "::"usage in
IPv4的情况没有太大不同，但IPv6最不明确的情况是第二个子弹。这是由于“：”在
IPv6 addresses. This style is NOT RECOMMENDED because of its ambiguity. The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified. Other styles are acceptable when there is exactly one style for the given context and cross-platform portability does not become an issue. For URIs containing IPv6 address literals, [RFC3986] MUST be followed, as well as the rules defined in this document.
IPv6地址。不建议使用此样式，因为它具有模糊性。应采用[RFC3986]中表示的[]样式，除非另有规定，否则为默认样式。如果给定上下文只有一种样式，并且跨平台可移植性不成问题，则可以接受其他样式。对于包含IPv6地址文本的URI，必须遵循[RFC3986]以及本文档中定义的规则。
Problems with prefixes are the same as problems encountered with addresses. The text representation method of IPv6 prefixes should be no different from that of IPv6 addresses.
前缀问题与地址问题相同。IPv6前缀的文本表示方法应与IPv6地址的文本表示方法相同。
This document notes some examples where IPv6 addresses are compared in text format. The example on Section 3.2.5 is one that may cause a security risk if used for access control. The common practice of comparing X.509 data is done in binary format.
本文档记录了一些以文本格式比较IPv6地址的示例。第3.2.5节中的示例如果用于访问控制，则可能会导致安全风险。比较X.509数据的常见做法是以二进制格式进行的。
The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, and Toshimitsu Matsuura for their generous and helpful comments in kick starting this document. We also would like to thank Brian Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki Vatiainen, Dan Wing, and Doug Barton for their input. Also, a very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing this document to light in IETF working groups.
作者要感谢Jan Zorz、Randy Bush、Yuichi Minami和Toshimitsu Matsuura在启动本文档过程中慷慨而有益的评论。我们也要感谢布莱恩·卡彭特、阿基拉·加托、尤尔根·舍恩瓦埃尔德、安东尼奥·克鲁宾、戴夫·泰勒、布莱恩·海利、苏雷什·克里希南、杰瑞·黄、罗曼·唐琴科、海基·瓦蒂安、丹·温和道格·巴顿的投入。此外，还要特别感谢Ron Bonica、Fred Baker、Brian Haberman、Robert Hinden、Jari Arkko和Kurt Lindqvist在IETF工作组中对本文件的支持。
[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月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators", Work in Progress, July 2010.
[ADDR-FORMAT]Bao，C.，“IPv4/IPv6转换器的IPv6寻址”，正在进行的工作，2010年7月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
We recommend that developers use display routines that conform to these rules. For example, the usage of getnameinfo() with flags argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, except for the special addresses notes in Section 5. The function inet_ntop() of FreeBSD7.0 is a good C code reference, but should not be called directly. See [RFC4038] for details.
我们建议开发人员使用符合这些规则的显示例程。例如，在FreeBSD 7.0中使用带有标志参数NI_NumeriHost的getnameinfo（）将给出一致的输出，第5节中的特殊地址注释除外。FreeBSD7.0的函数inet_ntop（）是一个很好的C代码参考，但不应直接调用。详见[RFC4038]。
Authors' Addresses
作者地址
Seiichi Kawamura NEC BIGLOBE, Ltd. 14-22, Shibaura 4-chome Minatoku, Tokyo 108-8558 JAPAN
日本东京南部町县Shibaura 4-chome Minatoku 14-22号川村成一NEC BIGLOBE有限公司108-8558
Phone: +81 3 3798 6085
EMail: kawamucho@mesh.ad.jp
Phone: +81 3 3798 6085
EMail: kawamucho@mesh.ad.jp
Masanobu Kawashima NEC AccessTechnica, Ltd. 800, Shimomata Kakegawa-shi, Shizuoka 436-8501 JAPAN
日本静冈岛下田角川市川岛正步NEC配件技术有限公司800号，邮编436-8501
Phone: +81 537 23 9655
EMail: kawashimam@necat.nec.co.jp
Phone: +81 537 23 9655
EMail: kawashimam@necat.nec.co.jp