Independent Submission H. Kaplan
Request for Comments: 8369 128 Technology
Category: Informational 1 April 2018
ISSN: 2070-1721
Independent Submission H. Kaplan
Request for Comments: 8369 128 Technology
Category: Informational 1 April 2018
ISSN: 2070-1721
Internationalizing IPv6 Using 128-Bit Unicode
使用128位Unicode实现IPv6国际化
Abstract
摘要
It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.
很明显，Unicode最终将耗尽其提供的代码点，而且还需要更多。假设ISO和Unicode联盟遵循IETF的实践，下一个Unicode代码点大小将为128位。本文档描述了如何利用未来的128位Unicode来改进IPv6的采用，并最终为IPv6带来国际化支持。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8369.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8369.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Need for 128-Bit Code Points . . . . . . . . . . . . . . 4
3. Unicode IPv6 Addresses . . . . . . . . . . . . . . . . . . . 6
3.1. Reserved Addresses . . . . . . . . . . . . . . . . . . . 6
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. IPv6 Routing . . . . . . . . . . . . . . . . . . . . . . 7
4. Using Unicode IPv6 Addresses . . . . . . . . . . . . . . . . 8
4.1. Uniform Resource Identifiers . . . . . . . . . . . . . . 8
4.2. Address Allocation and Resolution . . . . . . . . . . . . 8
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Need for 128-Bit Code Points . . . . . . . . . . . . . . 4
3. Unicode IPv6 Addresses . . . . . . . . . . . . . . . . . . . 6
3.1. Reserved Addresses . . . . . . . . . . . . . . . . . . . 6
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. IPv6 Routing . . . . . . . . . . . . . . . . . . . . . . 7
4. Using Unicode IPv6 Addresses . . . . . . . . . . . . . . . . 8
4.1. Uniform Resource Identifiers . . . . . . . . . . . . . . 8
4.2. Address Allocation and Resolution . . . . . . . . . . . . 8
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
Unicode [Unicode] is currently limited to 1,114,112 code points, encoded in various encoding formats (e.g., UTF-8, UTF-16, UTF-32). At the time of this document's publication, 136,755 code points have been allocated, with more already in the approval process. Every year, more writing scripts, symbols, and emojis are added, while none are removed. After consulting expert mathematicians, we have determined that the world will run out of code points someday in the future.
Unicode[Unicode]目前仅限于1114112个代码点，以各种编码格式（例如UTF-8、UTF-16、UTF-32）进行编码。在本文件发布时，已分配136755个代码点，更多代码点已在审批过程中。每年都会添加更多的书写脚本、符号和表情符号，但没有一个被删除。在咨询了数学家专家之后，我们已经确定，未来的某一天，世界将耗尽代码点。
While it might appear that the current rate of code point allocation gives us plenty of time to deal with the exhaustion problem, the Internet's history has shown that popular number spaces do not fill up linearly, but rather exponentially. And once the size of a particular number space becomes entrenched, it takes decades to migrate to a larger one. Therefore, the code point number space must be increased as soon as possible.
虽然目前代码点分配的速度似乎给了我们足够的时间来处理耗尽问题，但互联网的历史表明，流行的数字空间并不是线性填充的，而是指数填充的。一旦一个特定数字空间的大小变得根深蒂固，迁移到一个更大的数字空间需要几十年的时间。因此，必须尽快增加代码点编号空间。
The details for expanding the Unicode code point space are not covered in this document. Such details need to be worked out between the IETF, ISO, the Unicode Consortium, and various gods. We assume, however, that the code point space will need to grow dramatically, and there will continue to be a need for a fixed-length encoding scheme similar to UTF-32. Naturally, the next size increment should go from UTF-32 to UTF-128, and thus the rest of this document follows this assumption.
扩展Unicode代码点空间的详细信息不在本文档中介绍。这些细节需要在IETF、ISO、Unicode联盟和各种各样的组织之间解决。然而，我们假设代码点空间需要急剧增长，并且仍然需要类似于UTF-32的固定长度编码方案。当然，下一个大小增量应该从UTF-32增加到UTF-128，因此本文的其余部分遵循这一假设。
This new 128-bit Unicode code point space can be leveraged by the IETF to address one of the lingering issues with IPv6: there's not much left to standardize. With the changes described in this document, the IETF will be kept busy for decades to come. It also enables new features and market opportunities, to help the global economy. This in turn will increase tax revenues for governments, which eventually may lead to increased funds for combating global warming. Therefore, the ultimate goal of this document is to reduce global warming.
IETF可以利用这一新的128位Unicode代码点空间来解决IPv6的一个遗留问题：没有多少东西需要标准化。随着本文件所述的变化，IETF将在未来几十年保持忙碌。它还提供新功能和市场机会，以帮助全球经济。这反过来又会增加政府的税收收入，最终可能导致增加抗击全球变暖的资金。因此，本文件的最终目标是减少全球变暖。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. All other words SHOULD be interpreted as described by the Oxford English Dictionary OED [OED], which MAY be considered almost as authoritative for word definitions as the IETF.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。所有其他单词应按照牛津英语词典OED[OED]的描述进行解释，该词典对单词定义的权威性几乎与IETF相同。
UTF-128: A fixed-length encoding for 128-bit Unicode. It is implemented as an array of bytes in the same manner as legacy IPv6 addresses to avoid endianness issues.
UTF-128：128位Unicode的固定长度编码。它以与传统IPv6地址相同的方式实现为字节数组，以避免端性问题。
Short-Name Tag: A short descriptive name for a Unicode character code point, surrounded by colons (:). For example ":garfield:" represents the Unicode code point for the Garfield cat imoji.
短名称标记：Unicode字符代码点的短描述性名称，由冒号（：）包围。例如“：garfield:”表示garfield cat imoji的Unicode代码点。
Emoji: Pictographic symbol encoded in Unicode, used to express a general item, concept, or emotion.
表情符号：用Unicode编码的象形符号，用于表达一般项目、概念或情感。
Imoji: Pictographic symbol encoded in Unicode, used to represent an individual, specific thing: a specific human, a favorite pet, a famous animal, etc.
Imoji：用Unicode编码的象形符号，用于表示个人、特定的事物：特定的人、喜爱的宠物、著名的动物等。
Amoji: Pictographic symbol encoded in Unicode, used to represent an individual of an alien species.
变形虫：用Unicode编码的象形符号，用来表示外来物种的个体。
Umoji: Pictographic symbol encoded in Unicode, used to represent unknown things not covered by the other mojis.
Umoji：用Unicode编码的象形文字符号，用于表示其他Moji未涵盖的未知事物。
Omoji: Pictographic symbol encoded in Unicode, used to represent obfuscated identities, used as addresses for the purpose of privacy.
Omoji：用Unicode编码的象形文字符号，用于表示模糊的身份，用作隐私地址。
The exponentially increasing demand for Unicode character code points might not be obvious at first glance. While it is true that the number of languages and their writing scripts do not grow quickly over time, one type of "character" will: emojis. Unicode has barely begun providing code points for all of the various emojis currently in use, and it is likely that more emojis will be created in the future. For example, there are still missing emoji symbols for most types of food and drink, the flags of each town and city on Earth, all human sporting and leisure activities including all local and national sports teams and players, and every plant and animal species and gender.
对Unicode字符代码点的需求呈指数级增长，乍一看可能并不明显。虽然语言及其书写脚本的数量确实不会随着时间的推移而迅速增长，但有一种类型的“字符”会出现：表情符号。Unicode刚刚开始为目前使用的各种表情符号提供代码点，而且将来可能会创建更多的表情符号。例如，大多数类型的食品和饮料、地球上每个城镇的旗帜、所有人类体育和休闲活动（包括所有地方和国家体育队和运动员）以及所有植物和动物物种和性别的表情符号仍然缺失。
Furthermore, it has become common for some applications to allow their users to create custom emojis, whereby the user can provide the graphic to display for a new "character". For example, a user might set their chat application to display a graphic of Carlos Ramirez's popular "Trollface" meme [TROLL], using the short-name tag ':trollface:' in their chat application. All other users of the same chat app will be able to see and use the same custom trollface emoji.
此外，对于一些应用程序来说，允许用户创建自定义表情已经变得很常见，用户可以通过这些表情为新的“字符”提供图形来显示。例如，用户可以设置他们的聊天应用程序来显示Carlos Ramirez流行的“Trollface”meme[TROLL]的图形，在他们的聊天应用程序中使用简短的名称标记：Trollface:。同一聊天应用程序的所有其他用户将能够看到并使用相同的自定义表情符号。
However, since there is no Unicode code point for :trollface:, the chat app cannot export the trollface emoji to other chat apps or protocols, such as Internet Relay Chat (IRC) or the Extensible Messaging and Presence Protocol (XMPP). This represents a clear interoperability issue.
但是，由于：trollface:没有Unicode代码点，聊天应用程序无法将trollface表情符号导出到其他聊天应用程序或协议，例如Internet中继聊天（IRC）或可扩展消息和状态协议（XMPP）。这是一个明确的互操作性问题。
In the future, it might also become desirable to assign each human a Unicode code point to represent them, similar to names, with the glyph being a picture of their face or a custom graphic. These personal code points are not truly "emojis" in the classical sense of being generic concepts, so we've decided to give them a new name to avoid confusion: imoji. Unlike human names, code points for imojis will be unique per human, for all space and time. Favorite pets and famous animals can also be assigned imojis.
将来，也可能需要为每个人指定一个Unicode代码点来表示他们，类似于名字，字形是他们的脸的图片或自定义图形。这些个人代码点并不是经典意义上的泛型概念中真正的“表情符号”，因此我们决定给它们起一个新名字以避免混淆：imoji。与人名不同，imojis的代码点对于每个人来说都是唯一的，无论在任何空间还是时间。喜爱的宠物和著名的动物也可以被指定为伊莫吉。
Lastly, if we ever encounter sentient species from other planets, they too will need Unicode code points for their writing scripts and emojis; and they will each need unique amojis (imojis for aliens), for whatever form their individual identity might take. Section 4 of RFC 8136 [RFC8136] clearly supports such a scenario, with the new UFO IPv6 option.
最后，如果我们遇到来自其他星球的有知觉物种，它们也需要Unicode代码点来编写脚本和表情符号；他们每个人都需要独特的阿莫吉（外国人的伊莫吉），无论他们的个人身份可能采取何种形式。RFC8136[RFC8136]的第4节清楚地支持这样一种场景，使用了新的UFO IPv6选项。
Based on the above obvious use cases, it is clear that the current ~1 million code points are nowhere near enough. Increasing to 64 bits might be sufficient for now, but since this will be a painful transition process no matter the size, we believe jumping to 128 bits is the appropriate choice.
基于上述明显的用例，很明显，目前的~100万个代码点远远不够。现在增加到64位可能就足够了，但由于这将是一个痛苦的转换过程，无论大小如何，我们相信跳到128位是合适的选择。
Note: The current limit of ~1 million code points is a formal limit due to what UTF-16 can encode today. Increasing the limit will either require deprecating UTF-16 or paying a hefty overhead penalty to encode 128 bits across many pairs of surrogate code points. Since the ultimate goal of this document is to reduce global warming, the challenge of choosing between deprecating UTF-16 or paying the overhead price is a trivial dilemma to solve by comparison.
注：由于UTF-16目前可以编码，目前约100万个代码点的限制是正式限制。增加该限制将需要弃用UTF-16，或者支付高昂的开销代价，以便跨多对代理代码点编码128位。由于本文件的最终目标是减少全球变暖，因此在弃用UTF-16还是支付间接费用之间做出选择是一个需要通过比较来解决的小难题。
Assuming the new Unicode code point space is 128 bits -- excluding some reserved bits for backwards compatibility and future expansion -- it seems only natural to use Unicode code points for IPv6 addresses, and vice versa. This leads to some exciting changes, such as:
假设新的Unicode代码点空间为128位（不包括一些用于向后兼容和将来扩展的保留位），那么在IPv6地址中使用Unicode代码点似乎很自然，反之亦然。这导致了一些令人兴奋的变化，例如：
o IPv6 addresses no longer need to be typed as hex values -- instead, the glyph for the script character, symbol, emoji, or imoji representing that address can be input by the user, and it will be displayed by the application as the graphic itself. From the user's perspective, this will also be more compact than the representation described in RFC 1924 [RFC1924].
o IPv6地址不再需要键入十六进制值——相反，用户可以输入表示该地址的脚本字符、符号、表情符号或imoji的标志符号，应用程序将其显示为图形本身。从用户的角度来看，这也将比RFC 1924[RFC1924]中描述的表示更加紧凑。
o Network monitoring and troubleshooting tools can now display pretty glyphs in place of ugly IPv6 addresses, leading to less stress on the eyes of network administrators.
o 网络监控和故障排除工具现在可以显示漂亮的标志符号来代替难看的IPv6地址，从而减轻网络管理员的压力。
o For cases where graphical glyphs cannot be used, such as IETF documents, we can deprecate the legacy textual notation of IPv6 addresses of the style '2001:db8:85a3::8a2e:370:7334' to the simpler Unicode textual notation 'U+20010DB885A3000000008A2E03707334'. Using the short-name tag is also possible, such as ':v6address-1:'.
o 对于无法使用图形符号的情况，例如IETF文档，我们可以将样式为“2001:db8:85a3:：8a2e:370:7334”的IPv6地址的传统文本表示法弃用为更简单的Unicode文本表示法“U+20010DB885A3000000008A2E0370734”。也可以使用短名称标记，例如“：v6address-1:”。
Due to the nature of having IPv6 addresses be Unicode code points, RFC 8135 [RFC8135] is made obsolete by this document. It was found to be too complex to implement anyway.
由于IPv6地址是Unicode码点的性质，RFC 8135[RFC8135]已被本文档淘汰。结果发现它太复杂，无论如何都无法实现。
Some address code points will be inappropriate for IPv6 addressing, such as formatting characters and control codes. Such code points MUST NOT be used for IPv6 addresses.
某些地址代码点不适合IPv6寻址，例如格式化字符和控制代码。此类代码点不得用于IPv6地址。
We do, however, still need to reserve some code points for private network use. Since no sentient life has been found on Mars, the code points that would have been allocated for Martian imojis are hereby allocated for this private use. These addresses are thus called "Martians", also known as "Bogons" due to them being bogus.
然而，我们仍然需要保留一些代码点供专用网络使用。由于在火星上没有发现有知觉的生命，因此本应分配给火星伊莫吉的代码点在此分配给该私人用途。因此，这些地址被称为“火星人”，也被称为“博根人”，因为它们是假的。
Note: Should life be found on Mars in the future, new code points will be allocated for them. To avoid confusion, they will be called "Barsoom Indigenous Glyph Off-world Network" addresses, or "Bigons" (pronounced "bye-gons"). We're certain the Martians will let Bogons be bygones, and Bigons be Bigons.
注意：如果将来在火星上发现生命，将为它们分配新的代码点。为了避免混淆，它们将被称为“Barsoom土著雕文脱离世界网络”地址或“Bigons”（发音为“bye gons”）。我们确信火星人会让博贡人成为过去，而比贡人将成为比贡人。
In both IPv4 and IPv6, multicast addresses have been relegated to predefined IP address ranges, limiting how many multicast groups could be used simultaneously. Given the rise of broadcasting-style social media platforms, and the market demand for individuals to be watched/followed by numerous random strangers constantly, it seems clear that we need to be able to multicast everything, all the time.
在IPv4和IPv6中，多播地址都已降级到预定义的IP地址范围，从而限制了可以同时使用的多播组的数量。考虑到广播式社交媒体平台的兴起，以及市场对个人不断被无数随机陌生人关注/跟踪的需求，我们显然需要能够随时广播所有内容。
To address this need, the high-order bit of the 128-bit code point space SHALL be reserved to indicate multicast. All valid code points (i.e., IPv6 addresses) will thus have multicast counterparts. For example, the code point allocated for :cat: is U+1F408. The multicast group U+8000000000000000000000000001F408 is thus for content about cats. Note that this is for general cat content -- other code points are allocated for specific cat content, such as joy cat, grinning cat, pouty cat, etc. For an individual cat like Garfield, setting the high-order bit to the code point allocated for :garfield: will indicate that it is multicast content about Garfield.
为了满足这一需求，应保留128位代码点空间的高阶位以指示多播。因此，所有有效的代码点（即IPv6地址）都将具有多播副本。例如，为：cat:分配的代码点为U+1F408。因此，多播组U+80000000000000000001F408用于有关猫的内容。请注意，这是针对一般cat内容的——其他代码点分配给特定的cat内容，例如joy cat、grinning cat、pouty cat等。对于像加菲猫这样的单个猫，将高阶位设置为分配给：Garfield:的代码点将指示它是关于加菲猫的多播内容。
Source-specific multicast also plays a role; for example, joining the :garfield: multicast group and restricting it to a source of :garfield: results in only receiving content about Garfield, from Garfield.
源特定的多播也发挥了作用；例如，加入：garfield:multicast组并将其限制为：garfield:的源只会导致从garfield接收有关garfield的内容。
There should be little impact on routing using code-point-based IPv6 addresses. There might be some exponential growth in routing and forwarding tables due to difficulties in aggregating code points; hopefully, this will be offset by increases in processor and memory capacity. Of course this will also drive the need to frequently upgrade networking hardware, resulting in a boost to the global economy, and thus a reduction in global warming.
使用基于代码点的IPv6地址对路由的影响应该很小。由于聚合代码点的困难，路由和转发表可能会呈指数级增长；希望这将被处理器和内存容量的增加所抵消。当然，这也将推动频繁升级网络硬件的需求，从而提振全球经济，从而减少全球变暖。
One improvement to routing that MAY be considered is for scenic routing as defined by RFC 7511 [RFC7511]. With emojis and imojis being available for addressing, we can now specify which exact type of scenery to visit along the way, or even which exact avian carrier [RFC6214] to ride with. Note that avian carriers as described in RFC 1149 [RFC1149] are not supported, since they only support IPv4.
可考虑的路线改进之一是RFC 7511[RFC7511]定义的风景路线。由于可以使用表情符号和表情符号进行寻址，我们现在可以指定沿途游览哪种类型的风景，甚至可以指定乘坐哪种鸟类载体[RFC6214]。请注意，不支持RFC 1149[RFC1149]中描述的鸟类载体，因为它们只支持IPv4。
Uniform Resource Identifiers (URIs) and Uniform Resource Locators (URLs) already support Unicode through Internationalized Resource Identifiers (IRIs), but these are merely a means to use multiple Unicode characters to indicate a resource. With 128-bit Unicode, the number space is large enough to identify each resource with a single Unicode character. Why waste space and time typing out multiple characters, when you can just use one?
统一资源标识符（URI）和统一资源定位器（URL）已经通过国际化资源标识符（IRI）支持Unicode，但这些仅仅是使用多个Unicode字符表示资源的一种方法。对于128位Unicode，数字空间足够大，可以用单个Unicode字符标识每个资源。既然你可以只使用一个字符，为什么还要浪费时间和空间来输入多个字符呢？
For URLs, this new model might only mean using a single Unicode character for the hostname portion -- for example, a corporate logo in place of the legacy corporate domain name. Another alternative is to allocate a code point for the entire host and path, possibly even including the scheme. These types of decisions can be made in future IETF Working Groups.
对于URL，这个新模型可能只意味着主机名部分使用一个Unicode字符——例如，用公司徽标代替传统的公司域名。另一种选择是为整个主机和路径分配一个代码点，甚至可能包括该方案。这些类型的决定可以在未来的IETF工作组中做出。
The interesting aspect of this change for URIs/URLs is that no address lookup needs to be performed. The single 128-bit Unicode for the URL *is* the IPv6 address. An additional step is only needed if the user inputs a private Unicode character or short-name tag that needs to be converted to a publicly allocated one. This would require Network Address Translation (NAT) from the private code point or short-name tag to a public Unicode code point. This can be done locally, thus finally bringing NATs into the last part of the Internet in which they are not currently deployed: the user's application.
URI/URL的这一变化的有趣之处在于不需要执行地址查找。URL*的单个128位Unicode是IPv6地址。仅当用户输入需要转换为公共分配的专用Unicode字符或短名称标记时，才需要额外的步骤。这将需要从专用代码点或短名称标记到公共Unicode代码点的网络地址转换（NAT）。这可以在本地完成，从而最终将NAT引入当前未部署NAT的最后一部分：用户的应用程序。
It is obvious that once a single 128-bit Unicode character is used for addresses and URIs, using domain names will quickly become obsolete. The subsequent collapse of the domain name industry presents a threat to the world economy, which MUST be addressed.
很明显，一旦地址和URI使用单个128位Unicode字符，使用域名很快就会过时。随后域名行业的崩溃对世界经济构成了威胁，必须加以解决。
One solution to this danger is to establish a Unicode registry model and an accompanying Code Point Unicode Resolution System (CPURS, pronounced "keepers"). CPURS would replace DNS and provide an architecture and resolution mechanism to resolve Unicode code points to their registered glyphs and short-name tags, and vice versa. The new Unicode registries and registrars would thus replace the legacy domain name counterparts. This would lead to a new gold rush for registering Unicode code points for corporate logos and product icons, and thus usher in an era of economic prosperity, which would eventually reduce global warming.
解决这种危险的一个方法是建立一个Unicode注册表模型和一个附带的代码点Unicode解析系统（CPURS，发音为“keepers”）。CPUR将取代DNS，并提供一种体系结构和解析机制，将Unicode代码点解析为其注册的标志符号和短名称标记，反之亦然。因此，新的Unicode注册中心和注册中心将取代传统的域名注册中心。这将导致为企业标识和产品图标注册Unicode代码点的新一轮淘金热，从而迎来一个经济繁荣的时代，最终将减少全球变暖。
Once Unicode registries and CPURS are in place, IPv6 addresses would be allocated by registering code points through that system; they would no longer be registered by IANA and RIRs. This is not a major concern, however, because any tax revenue loss will be more than offset by Unicode registries allocating code points. Furthermore, in order to make CPURS possible, the actual graphic files for the glyphs need to be standardized and created in numerous formats and sizes, with various intellectual property rules. This will provide more work for graphic artists and lawyers, further increasing tax revenue.
一旦Unicode注册和CPUR到位，IPv6地址将通过该系统注册代码点进行分配；它们将不再由IANA和RIRs注册。然而，这并不是一个主要问题，因为任何税收损失都将被分配代码点的Unicode注册中心所抵消。此外，为了使CPUR成为可能，字形的实际图形文件需要标准化，并使用各种知识产权规则以多种格式和大小创建。这将为平面艺术家和律师提供更多的工作，进一步增加税收。
The astute reader might ask why we need CPURS if Unicode translation is performed locally on hosts today. The answer is volume: it is unlikely that host applications can keep up with the rate of new Unicode code points being allocated for emojis, imojis, and umojis. While application and operating system updates have been occurring at an ever-increasing rate, and will soon reach the same rate as human births, it is doubtful that it will ever reach the rate of sentient extraterrestrial births. Therefore, we need a system that can scale to reach such volume before we make first contact; otherwise, the diplomatic failure to quickly provide the aliens with amojis of their own may lead to armed conflict. An armed conflict with other sentient beings capable of reaching Earth might increase global warming, defeating this document's ultimate purpose.
精明的读者可能会问，如果今天在主机上本地执行Unicode转换，为什么我们需要CPUR。答案是数量：主机应用程序不太可能跟上为emojis、imojis和umojis分配的新Unicode代码点的速度。虽然应用程序和操作系统的更新速度一直在不断提高，并且很快将达到与人类出生相同的速度，但它是否会达到有知觉的外星出生率仍值得怀疑。因此，我们需要一个系统，能够在我们第一次接触之前达到这样的规模；否则，外交上未能迅速向外国人提供他们自己的阿莫吉可能导致武装冲突。与能够到达地球的其他有情生物的武装冲突可能会加剧全球变暖，破坏本文件的最终目的。
There is still much to be decided on, most of which is frankly rather boring. It is clear, however, that 128-bit Unicode code points will be needed eventually, and IPv6 addressing MUST be migrated to it. Thus, the time to act is now!
还有很多事情要做决定，坦率地说，其中大部分相当无聊。然而，很明显，最终将需要128位Unicode代码点，IPv6寻址必须迁移到它。因此，现在是采取行动的时候了！
This document has no IANA actions.
本文档没有IANA操作。
The main security concern with using 128-bit Unicode for IPv6 addressing is the need for privacy, in terms of anonymity. If an IPv6 packet is sent with an imoji or amoji address, then man-in-the-middle devices in the network will know the specific human or alien that sent or received the packet. Using such information might lead to heated discussions, thereby increasing global warming.
在IPv6寻址中使用128位Unicode的主要安全问题是匿名性方面的隐私需求。如果使用imoji或amoji地址发送IPv6数据包，则网络中的中间人设备将知道发送或接收数据包的特定人或外国人。使用这些信息可能导致激烈的讨论，从而加剧全球变暖。
To address this concern, an IPv6 address MAY be obfuscated by using an omoji. An omoji is simply the original Unicode code point but with the least-significant bit set; all other types of 128-bit Unicode code points MUST have the least-significant bit cleared. The
为了解决这个问题，可以使用omoji对IPv6地址进行模糊处理。omoji只是原始Unicode代码点，但具有最低有效位集；所有其他类型的128位Unicode代码点必须清除最低有效位。这个
graphical representation of an omoji is the same as its unobfsucated moji counterpart, except that it is covered over by a solid black block.
omoji的图形表示法与其未受教育的moji对应物相同，只是它被一个黑色实心块覆盖。
By setting the least-significant bit of the source or destination and thus turning it into an omoji, the IPv6 address is obfuscated and the true identity cannot be determined, while IPv6 routers can still route the packet appropriately. Note that this only provides a bit of privacy, but every bit helps.
通过设置源或目标的最低有效位，并将其转换为omoji，IPv6地址被混淆，无法确定真实身份，而IPv6路由器仍然可以适当地路由数据包。请注意，这只提供了一点隐私，但每一点都有帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[OED] Oxford University Press, "Oxford English Dictionary", <http://www.oed.com>.
牛津大学出版社，《牛津英语词典》<http://www.oed.com>.
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, DOI 10.17487/RFC1149, April 1990, <https://www.rfc-editor.org/info/rfc1149>.
[RFC1149]Waitzman，D.，“鸟类载体上IP数据报传输标准”，RFC 1149，DOI 10.17487/RFC1149，1990年4月<https://www.rfc-editor.org/info/rfc1149>.
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, DOI 10.17487/RFC1924, April 1996, <https://www.rfc-editor.org/info/rfc1924>.
[RFC1924]Elz，R.，“IPv6地址的紧凑表示”，RFC 1924，DOI 10.17487/RFC1924，1996年4月<https://www.rfc-editor.org/info/rfc1924>.
[RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011, <https://www.rfc-editor.org/info/rfc6214>.
[RFC6214]Carpenter，B.和R.Hinden，“RFC 1149对IPv6的适应”，RFC 6214，DOI 10.17487/RFC6214，2011年4月<https://www.rfc-editor.org/info/rfc6214>.
[RFC7511] Wilhelm, M., "Scenic Routing for IPv6", RFC 7511, DOI 10.17487/RFC7511, April 2015, <https://www.rfc-editor.org/info/rfc7511>.
[RFC7511]Wilhelm，M.，“IPv6的风景路由”，RFC 7511DOI 10.17487/RFC75112015年4月<https://www.rfc-editor.org/info/rfc7511>.
[RFC8135] Danielson, M. and M. Nilsson, "Complex Addressing in IPv6", RFC 8135, DOI 10.17487/RFC8135, April 2017, <https://www.rfc-editor.org/info/rfc8135>.
[RFC8135]Danielson，M.和M.Nilsson，“IPv6中的复杂寻址”，RFC 8135，DOI 10.17487/RFC8135，2017年4月<https://www.rfc-editor.org/info/rfc8135>.
[RFC8136] Carpenter, B. and R. Hinden, "Additional Transition Functionality for IPv6", RFC 8136, DOI 10.17487/RFC8136, April 2017, <https://www.rfc-editor.org/info/rfc8136>.
[RFC8136]Carpenter，B.和R.Hinden，“IPv6的附加转换功能”，RFC 8136，DOI 10.17487/RFC8136，2017年4月<https://www.rfc-editor.org/info/rfc8136>.
[TROLL] The Meme Wikia, "Trollface", <http://meme.wikia.com/wiki/Rule_63?oldid=23602>.
[巨魔]迷因维基，“巨魔脸”<http://meme.wikia.com/wiki/Rule_63?oldid=23602>.
[Unicode] The Unicode Consortium, "Unicode", <http://unicode.org>.
[Unicode]Unicode联盟，“Unicode”<http://unicode.org>.
Acknowledgements
致谢
The authors wish to thank the following people for providing the inspiration for this work: Cal Henderson, Carlos Ramirez, Graham Linehan, Agnetha Faltskog, Bjorn Ulvaeus, Benny Andersson, and Anni-Frid Lyngstad.
作者希望感谢以下为这项工作提供灵感的人：卡尔·亨德森、卡洛斯·拉米雷斯、格雷厄姆·莱恩汉、阿格尼莎·法尔茨科格、比约恩·乌尔瓦伊斯、本尼·安德森和安妮·弗里德·林斯塔德。
Author's Address
作者地址
Hadriel Kaplan 128 Technology Burlington, MA United States of America
美国马萨诸塞州伯灵顿市Hadriel Kaplan 128科技公司
Email: hadriel@128technology.com
Email: hadriel@128technology.com