[要約] RFC 8369は、IPv6アドレスを128ビットのUnicodeで国際化するための標準を提案しています。その目的は、異なる言語や文字セットをサポートし、インターネットのグローバルな普及を促進することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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]は現在、さまざまなエンコード形式（UTF-8、UTF-16、UTF-32など）でエンコードされた1,114,112コードポイントに制限されています。このドキュメントの公開時点では、136,755のコードポイントが割り当てられており、さらに多くが承認プロセスにあります。毎年、より多くの書き込みスクリプト、シンボル、絵文字が追加されますが、削除されるものはありません。専門家の数学者に相談した結果、将来的には世界がコードポイントを使い果たすと判断しました。
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に関する未解決の問題の1つに対処できます。標準化する余地はほとんどありません。このドキュメントで説明されている変更により、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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。他のすべての単語は、オックスフォード英語辞書OED [OED]で説明されているように解釈する必要があります。
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：」は、ガーフィールドの猫の絵文字の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.
絵文字：Unicodeでエンコードされた絵文字シンボル。個人、特定のものを表すために使用されます：特定の人間、好きなペット、有名な動物など。
Amoji: Pictographic symbol encoded in Unicode, used to represent an individual of an alien species.
Amoji：Unicodeでエンコードされた絵文字シンボル。外来種の個体を表すために使用されます。
Umoji: Pictographic symbol encoded in Unicode, used to represent unknown things not covered by the other mojis.
Umoji：Unicodeでエンコードされた絵文字記号。他の文字でカバーされていない未知のものを表すために使用されます。
Omoji: Pictographic symbol encoded in Unicode, used to represent obfuscated identities, used as addresses for the purpose of privacy.
Omoji：Unicodeでエンコードされた絵文字シンボル。難読化されたIDを表すために使用され、プライバシーの目的でアドレスとして使用されます。
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文字コードポイントに対する指数関数的に増加する需要は、一見しただけでは明らかではない場合があります。言語の数とそれを書くスクリプトが時間の経過とともに急速に増加しないことは事実ですが、「文字」の1つのタイプは絵文字です。 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.
さらに、一部のアプリケーションでは、ユーザーがカスタム絵文字を作成できるようになり、ユーザーが新しい「キャラクター」に表示するグラフィックを提供できるようになりました。たとえば、ユーザーはチャットアプリケーションで短い名前のタグ「：trollface：」を使用して、カルロスラミレスの人気の「トロールフェイス」ミーム[TROLL]のグラフィックを表示するようにチャットアプリケーションを設定することができます。同じチャットアプリの他のすべてのユーザーは、同じカスタムトロールフェイス絵文字を表示して使用できます。
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の絵文字を他のチャットアプリやインターネットリレーチャット（IRC）やExtensible Messaging and Presence Protocol（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コードポイントを割り当て、グリフを顔の写真またはカスタムグラフィックにすることも望ましいでしょう。これらのパーソナルコードポイントは、一般的な概念であるという古典的な意味での「絵文字」ではないため、混乱を避けるために、新しい名前を付けることにしました。人間の名前とは異なり、絵文字のコードポイントは、すべての空間と時間について、人間ごとに一意になります。お気に入りのペットや有名な動物にも絵文字を割り当てることができます。
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コードポイントを必要とします。そして、彼らはそれぞれ、彼らの個々のアイデンティティが取るかもしれないどんな形のためにも、ユニークなアモジ（エイリアンのためのイモジ）を必要とします。 RFC 8136 [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.
注：現在の最大100万コードポイントの制限は、現在UTF-16でエンコードできるため、正式な制限です。制限を増やすには、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アドレスを16進値として入力する必要がなくなりました。代わりに、その文字を表すスクリプト文字、記号、絵文字、または絵文字のグリフをユーザーが入力でき、アプリケーションによってグラフィック自体として表示されます。 。ユーザーの観点から見ると、これは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 + 20010DB885A3000000008A2E03707334 '。 '：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アドレスに使用してはなりません（MUST NOT）。
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 Indigenous Glyph Off-world Network」アドレスまたは「Bigons」（「バイバイ」と発音）と呼ばれます。私たちは火星人がボゴンを別れ、ビゴンをビゴンにすることを確信しています。
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 + 8000000000000000000000000001F408は、猫に関するコンテンツ用です。これは一般的な猫のコンテンツ用であることに注意してください。他のコードポイントは、喜び猫、ニヤリと猫、プーティ猫など、特定の猫のコンテンツに割り当てられます。ガーフィールドのような個々の猫では、上位ビットをコードポイントに設定します。 ：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：マルチキャストグループに参加し、それを：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.
考慮すべきルーティングの改善点の1つは、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?
Uniform Resource Identifier（URI）およびUniform Resource Locator（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.
単一の128ビットUnicode文字がアドレスとURIに使用されると、ドメイン名の使用がすぐに時代遅れになることは明らかです。ドメイン名業界のその後の崩壊は、対処されなければならない世界経済への脅威を提示します。
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.
この危険に対する1つの解決策は、Unicodeレジストリモデルとそれに付随するCode Point Unicode解決システム（CPURS、「キーパー」と発音）を確立することです。 CPURSは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レジストリとCPURSが配置されると、そのシステムを介してコードポイントを登録することにより、IPv6アドレスが割り当てられます。それらは、IANAおよびRIRによって登録されなくなります。ただし、税収の損失は、コードポイントを割り当てるUnicodeレジストリによって相殺される以上であるため、これは大きな問題ではありません。さらに、CPURSを可能にするために、グリフの実際のグラフィックファイルを標準化し、さまざまな知的財産権規則を使用して、さまざまな形式とサイズで作成する必要があります。これにより、グラフィックアーティストや弁護士の仕事が増え、税収がさらに増加します。
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変換がローカルで実行されている場合、鋭い読者はなぜCPURSが必要なのかと尋ねるでしょう。答えはボリュームです。ホストアプリケーションが、絵文字、絵文字、およびumojiに割り当てられている新しい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を使用する場合の主なセキュリティ上の懸念は、匿名性の観点からプライバシーの必要性です。 IPv6パケットがimojiまたはamojiアドレスで送信される場合、ネットワーク内の中間者デバイスは、パケットを送信または受信した特定の人間またはエイリアンを認識します。そのような情報を使用すると、議論が激しくなり、地球温暖化が進む可能性があります。
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 graphical representation of an omoji is the same as its unobfsucated moji counterpart, except that it is covered over by a solid black block.
この問題に対処するために、IPv6アドレスは、オモジを使用して難読化される場合があります。 omojiは単純に元のUnicodeコードポイントですが、最下位ビットが設定されています。他のすべてのタイプの128ビットUnicodeコードポイントでは、最下位ビットをクリアする必要があります。おもじのグラフィカル表現は、単色の黒いブロックで覆われていることを除いて、その難読化されていないもじの対応物と同じです。
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アドレスは難読化され、真のIDを判別できなくなりますが、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>.
[OED] Oxford University Press、「Oxford English Dictionary」、<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、「Adaptation of RFC 1149 for 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。、「Scenic Routing for IPv6」、RFC 7511、DOI 10.17487 / RFC7511、2015年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>.
[TROLL] The Meme Wikia、「Trollface」、<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.
著者は、この作品のインスピレーションを提供してくれた次の人々に感謝します：Cal Henderson、Carlos Ramirez、Graham Linehan、Agnetha Faltskog、Bjorn Ulvaeus、Benny Andersson、Anni-Frid Lyngstad。
Author's Address
著者のアドレス
Hadriel Kaplan 128 Technology Burlington, MA United States of America
ハドリエルカプラン128テクノロジーバーリントン、マサチューセッツ州アメリカ合衆国
Email: hadriel@128technology.com