バリアントやらグラフィムクラスターやらでUnicodeの混沌が加速しつつある現状、皆様いかがお過ごしでしょうか。
以下はこれらの諸問題を一挙に解決すべく2018年に公開されたRFC8369、Internationalizing IPv6 Using 128-Bit Unicodeの日本語訳です。
邦題は『128ビットUnicodeを用いたIPv6アドレスの国際化』で、文字コード問題を解決しつつIPv6問題への対処をも目指しています。
Internationalizing IPv6 Using 128-Bit Unicode
Abstract
現在のUnicodeは最終的に全てのコードポイントを使い果たし、さらに多くのコードポイントが必要になってしまうことは確定的に明らかです。
ISOとUnicode ConsortiumがIETFのプラクティスに従うと、次のUnicodeコードポイントサイズは128ビットになります。
このドキュメントでは、128ビットUnicodeをIPv6に適用し、IPv6アドレスを国際化する手順について解説します。
1 Introduction
Unicodeは現在、様々なエンコード形式でエンコードされる1,114,112個のコードポイントを持っています。
このドキュメントの発行時点では既に136,755個のコードポイントが割り当てられており、さらに多くの文字が承認プロセスに入っています。
毎年、スクリプトや記号や絵文字のコードが追加されますが、削除はされません。
数学者と相談した結果、将来的にUnicodeコードポイントは使い果たされることになるだろうと判断されました。
現在のコードポイント割り当て速度を見ると、枯渇するまでに十分な時間が残されているように見えますが、インターネットの歴史を紐解けば、一般的にこの手の数値は線形ではなく指数関数的に増大していくことが証明されています。
また、ある標準が定着すると、それを次のバージョンに移行するには数十年かかります。
従って、できるかぎり早くコードポイントの空きスペースを増やす必要があります。
UNICODEコードポイント空間を拡張するための仕様の詳細は、このドキュメントでは扱いません。
その部分はIETF、ISO、Unicode Consortium、神々の間で取り組む仕事です。
しかし、コードポイントの消費量は劇的に増加すると思われるため、UTF-32のような固定長符号化方式は今後も引き続き必要とされます。
もちろん、次の符号化はUTF-128になることに疑いの余地はありません。
従って、このドキュメントの残りの部分は、UTF-128であるという前提に従います。
この文書で説明されている変更が行われると、IETFは今後数十年にわたり作業に忙殺されることになります。
これは新しい雇用を生み出し、政府の税収を増加させ、最終的に地球温暖化防止に費やす資金を増加させることになります。
従って、このドキュメントの最終目的は地球温暖化の防止です。
1.1 Requirements Language
各キーワード『しなければならない( MUST )』『してはならない( MUST NOT )』『要求されている( REQUIRED )』『することになる( SHALL )』『することはない( SHALL NOT )』『する必要がある( SHOULD )』『しないほうがよい( SHOULD NOT )』『推奨される( RECOMMENDED )』してもよい( MAY )』『選択できる( OPTIONAL )』はBCP-14、RFC2119、RFC8174に従います。
それ以外の全ての単語はOxford English Dictionaryに従って解釈する必要があります(SHOULD)。
1.2 Definitions
UTF-128
128ビットUNICODEの固定長エンコード。エンディアン問題を回避するため、レガシーなIPv6アドレスと同じ方法でバイト列として実装される。
Short-Name Tag
:で囲まれたUNICODEコードポイントの短縮表記。たとえば:garfield:はGarfieldを表すImojiのコードポイントを示す。
Emoji
一般的な道具、概念、感情などを表現するためのUNICODE絵文字記号。
Imoji
個人、ペット、有名な動物など特定の対象を表現するためのUNICODE絵文字記号。
Amoji
外来種を表現するためのUNICODE絵文字記号。
Umoji
他の*mojiでは表現できない未知の存在を表すためのUNICODE絵文字記号。
Omoji
プライバシーのため、個人情報を難読化して表すためのUNICODE絵文字記号。
2 The Need for 128-Bit Code Points
UNICODEコードポイントの要求が急増することは、一見明らかではないかもしれません。
時間経過と共に言語数やスクリプトの数が急増することがないことは事実ですが、とあるひとつの文字種だけは例外で、それはEmojiです。
UNICODEは、現在使用されている多くのEmojiについてようやくコードポイントの支給を始めたところで、将来的には遙かに多くのEmojiが創られる可能性があります。
たとえばあらゆる種類の食べ物、飲み物、地球上の各都市や街の市町村旗、スポーツやレジャー活動およびそれらをプレイする選手、全ての動植物の種と性別。
さらに、一部のアプリケーションはユーザが独自のEmojiを作成できるようになっていますが、これによってユーザは新たな文字を提供することができるようになります。
例えば一部のユーザがCarlos Ramirezの有名なTrollfaceを作成し、短縮表記:trollface:を使ってチャットアプリケーションに登録します。
同じアプリの使用者は、全員がこの:trollface:のEmojiを使用し、表示することができるようになります。
しかしながら:trollface:のコードポイントは存在しないため、そのチャットアプリは該当のEmojiを他のIRCやXMPPプロトコル等にエクスポートすることができません。
これは相互運用上の問題点となります。
将来的には、名前と同じように、全ての個人に対して各々を特定するためのUNICODEコードポイントを割り当てるのが望ましいでしょう。
これらのコードポイントは、古典的な概念であるEmojiとは異なる意味合いを持つため、我々は混乱を避けるために新しい名前、Imojiと名付けることにしました。
名前とは異なり、Imojiのコードポイントは全ての種族と時間において、個人ごとに完全に一意になります。
ペットや、有名な動物個体などにもImojiを割り当てることができます。
最後に、他の惑星からの知覚生物に遭遇した場合、彼らを表現するためのUNICODEコードポイントが必要になります。
彼らの個人識別手法がどのような形でも対応できるように、既存のImojiではなくユニークなAmojiを割り当てます。
RFC8136のセクション4では、このようなシナリオをIPv6のUFOオプションを用いてサポートしています。
このような使用対象事例を含めると、現在の約100万しかないコードポイントではこれらを表すのに全く足りないことは明らかです。
現状では64ビットまで増やせば充分かもしれませんが、しかしビット数にかかわらず移行プロセスは困難を伴うため、一足飛びに128ビットまで増加させるのが適切な選択であると我々は考えています。
注意：現在UTF-16がエンコードできる限界値は約100万コードポイントです。制限を増やすには、UTF-16を非推奨にするか、多大なオーバーヘッドペナルティを払って128ビットサロゲートペアに対応しなければなりません。この文書の最終目的は地球温暖化の防止であるため、UTF-16の非推奨か、オーバーヘッドペナルティを支払うかは、比較するまでもない些細な選択肢です。
3 Unicode IPv6 Addresses
UNICODEコードポイントに128ビットを割り当てるとなると、下位互換性と将来の拡張のためのいくつかの予約ビットを除き、IPv6アドレスはそのままUNICODEコードポイントと置き換えが可能になるのは自明のことです。
これによって次のようなエキサイティングな変化が起こります。
・IPv6アドレスはもはや16進数の羅列として入力する必要がなく、かわりにそのコードポイントを表すキャラクタ、Emoji、もしくはImojiとして入力することができます。アプリケーションはそれをグリフとして表示するでしょう。これはRFC1924よりもずっとコンパクトな表記になります。
・ネットワークモニタリングソフトやトラブルシューティングツールは、醜いIPv6アドレスのかわりに綺麗なグリフを表示するようになり、ネットワーク管理者の目の負担を軽減します。
・IETFドキュメントのようにグラフィカルなグリフを使用できない場合でも、2001:db8:85a3::8a2e:370:7334のようなIPv6形式を、より単純なUnicodeテキスト形式でU+20010DB885A3000000008A2E03707334のように表すことができます。さらには:v6address-1:のような短縮表記も使用可能です。
IPv6アドレスがUNICODEコードポイントであるという性質上、RFC8135は廃止されます。
そうでなくともRFC8135は複雑すぎるため実装が困難でした。
3.1 Reserved Addresses
書式設定文字や制御コードなど、一部のUNICODEコードポイントはIPv6アドレスとして不適切です。
そのようなコードポイントはIPv6アドレスとして使用してはいけません(MUST NOT)。
またプライベートネットワークで使用するために、いくつかのコードポイントを予約しておかねばなりません。
火星には知的生命体が発見されなかったので、火星人のために割り当てられていたImojiをプライベートネットワークに割り当てることになりました。
従ってこれらのアドレスはMartians、もしくはBogonsと呼ばれます。
注意：今後火星人が見つかった場合、彼らには新しい別のコードポイントが割り当てられます。
混乱を避けるため、彼らに割り当てるアドレスはBarsoom Indigenous Glyph Off-world NetworkつまりBigons(発音はbye-gons)と呼ばれることになります。
3.2 Multicast
IPv4とIPv6のいずれにおいても、マルチキャストアドレスは予め定義されたIPアドレス範囲に指定されていて、同時に使用可能なマルチキャストグループ数は制限されています。
ブロードキャストスタイルのSNSプラットフォームの登場や、多数の個人が絶え間なく監視し続けている株式市場などの現状を考えると、いつでもどこでも常に無制限にマルチキャストできるようにしておかなければならないことは明白です。
この需要に対応するため、128ビットコードポイントの最上位ビットはマルチキャストを示すために予約されます(SHALL)。
この結果、全ての有効なコードポイント=IPv6アドレスは、対応するマルチキャストアドレスを有することになります。
たとえば:cat:のコードポイントはU+1F408であり、従って:cat:のマルチキャストグループはU+8000000000000000000000000001F408になります。
なお、これは一般的(general)なcatについてのコンテンツです。
joyなcatやgrinningなcat、poutyなcatやその他のcatについても、それぞれ固有のコードポイントを割り当てることができます。。
Garfieldのような特定のcatの場合、:garfield:コードポイントの最上位ビットをセットしたコードポイントが、Garfieldに関するマルチキャストグループとなります。
Source Specific Multicastも同様に動作します。
例えば:garfield:マルチキャストグループに参加し、取得対象の発信元を:garfield:に限定すると、Garfieldから発信されたコンテンツのみを受信します。
3.3 IPv6 Routing
コードポイントベースのIpv6アドレスを使用したルーティングについて与える影響はほとんどありません。
コードポイントの集約が困難であるため、ルーティングテーブルおよびIP転送表に指数関数的に増加する可能性はありますが、これはプロセッサやメモリの性能向上によって相殺されます。
これはネットワークハードウェアの頻繁なアップグレードが必要になるということを意味し、その結果として世界経済の拡大や地球温暖化の低減に繋がります。
RFC7511で定義されているscenicルーティングが改善されます。
EmojisおよびImojisがアドレッシングに利用可能になることで、経路を正確に指定することが可能になります。
またRFC6214によるキャリア経路も使用することができます。
ただしRFC1149はIPv4専用であるためサポートされないことに注意してください。
4 Using Unicode IPv6 Addresses
4.1 Uniform Resource Identifiers
Uniform Resource Identifiers(URI)およびUniform Resource Locators(URL)は、Internationalized Resource Identifiers(IRI)によってUnicodeサポートが保証されています。
しかしそれは単に、複数のUnicode文字を使って特定のリソースを指し示すことができる、というだけのことです。
128ビットUnicodeは、一文字だけであらゆるリソースを特定するのに十分な空間を持っています。
複数の文字を入力するためにスペースと時間を浪費する必要はもうありません。
URLについては、ホスト名に1文字のUnicode文字だけを使うようになるということです。
たとえば、従来のように企業ドメイン名を使うかわりに、企業ロゴなどを宛てることができます。
もしくは、ホスト名とパスを含めた全体にコードポイントを割り当てるかもしれません。
URLの指定方式がどうなるかは、IETFワーキンググループの決定に依ります。
このURI/URL方式の面白いところは、名前解決の必要がないということです。
何故ならば、128ビットUnicodeの1文字は、それ自身がIPv6アドレスであるからです。
プライベートUnicode文字やプライベート短縮表記をパブリックIPv6アドレスに割り当てたい場合にのみ、変換の手順が必要になります。
この場合は、プライベートコードポイントもしくは短縮表記から、パブリックコードポイントに変換を行うNetwork Address Translation(NAT)が必要です。
この変換はローカルで行うことができるため、従ってNATはインターネットの中で最もユーザに近い部分、すなわちユーザアプリケーションとして実装されるでしょう。
4.2 Address Allocation and Resolution
URIに128ビットUnicodeが用いられるようになれば、ドメインが即座に全く使われなくなることは火を見るより明らかです。
その際のドメイン業界の崩壊は、世界経済の脅威になりえます。
この危機の解決策のひとつは、Unicodeレジストリモデルと、付随するCode Point Unicode Resolution System、CPURS(発音はキーパーズ)を確立することです。
CPURSはDNSのかわりとなるもので、Unicodeコードポイントと短縮表記の相互解決を行うメカニズムを提供します。
旧来のドメイン名レジストリとレジストラは、Unicodeレジストリとレジストラに生まれ変わります。
これによって企業ロゴや製品アイコンのUnicodeコードポイントを登録することがブームとなり、結果的に地球温暖化を緩和して経済繁栄の黄金時代を迎えます。
UnicodeレジストリとCPURSが立ち上がると、今後IPv6アドレスはそのシステムを通じて登録することになります。
IANAやRIRは通さなくなってしまいます。
しかし、これは大きな問題ではありません。
いかなる経済的損失も、コードポイント割り当てを行うUnicodeレジストリの経済的利益によって相殺されるからです。
またCPURSを円滑に活用するために、Unicodeコードポイントの実際のグリフは知財に配慮し、多くのフォーマットやサイズで標準化する必要があります。
これによって弁護士やグラフィックアーティストの仕事が増大し、損失を超える経済収益が見込めます。
Unicode変換をローカルで行うならCPURSは必要ないのではないか、と賢明なユーザは考えるかもしれません。
それができない理由は量です。
日々割り当てられるEmoji、Imoji、UmojiのUnicodeコードポイントに対して、ホストアプリケーションが個々に追随することはほとんど不可能です。
アプリケーションとOSのアップデートはますます増加しており、近いうちに人間の出生数を追い越すことでしょう。
しかし、それが地球外生命体の量を含めた数に追いつくかは疑わしいものです。
従って、最初のコンタクトの前に、その拡張に耐えられるシステムを用意することが必要です。
さもなくば、外交の失敗から武力衝突へと繋がってしまう可能性があります。
地球外生命体との戦争は地球温暖化を加速させ、本RFCの目的を破ってしまうため、可能な限り避けなければなりません。
5 Summary
上記以外にも決定しなければならないことは多岐にわたって存在しますが、それらのほとんどは退屈なものです。
しかし、最終的には128ビットUnicodeコードポイントは必要であり、そしてIPv6アドレッシングも移行しなければなりません(MUST)。
今こそが、行動を起こす時です。
6 IANA Considerations
この文書には、IANAの行うべきアクションはありません。
7 Security Considerations
IPv6アドレッシングに128ビットUnicodeを使用することについての主なセキュリティ上の懸念点は、プライバシーの必要性です。
ImojiやAmojiアドレスから送られたIPv6パケットは、中間者攻撃によってパケットの送信者および受信者を完全に特定することができます。
このような脆弱性によって議論が白熱し、結果として地球温暖化に繋がります。
この問題に対処するため、IPv6アドレスはOmojiを使用して難読化することができます(MAY)。
Omojiは、最下位ビットが黒塗りにされているUnicodeコードポイントです。
他の全ての128ビットUnicodeコードポイントは最下位ビットがクリアされている必要があります。
Omojiのグリフは、それが黒塗りにされていること以外は元々のグリフと同じものです。
発信者もしくは宛先の最下位ビットを黒塗りにすることによって、IPv6アドレスは難読化されます。
実際の送受信者を識別することはできなくなりますが、IPv6ルータはパケットを適切にルーティングすることができます。
8 References
8.1 Normative References
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels
RFC 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
8.2 Informative References
OED Oxford English Dictionary
RFC 1149 Standard for the transmission of IP datagrams on avian carriers
RFC 1924 A Compact Representation of IPv6 Addresses
RFC 6214 Adaptation of RFC 1149 for IPv6
RFC 7511 Scenic Routing for IPv6
RFC 8135 Complex Addressing in IPv6
RFC 8136 nden, "Additional Transition Functionality for IPv6
TROLL Trollface
Unicode Unicode
Acknowledgements
この提案へのアイデアを提供してくれた、以下の方々に感謝します。
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
感想
ありとあらゆる文字にそれぞれ固有の文字コードを割り当てることで、異体字セレクタやらZWJシーケンスなどといった頭のおかしい仕様が全て不要になり、UNICODEの構造がきわめて簡潔になります。
そして次世代UNICODEは128ビット、IPv6アドレスも128ビットということで両者は一対一対応になります。
つまりどういうことかというと、UNICODE文字をそのままIPv6アドレスとして扱えるということです。
IPv6アドレスといえばこのような到底覚えきれない呪文のようなURLですが、これが今後は
のようになるということです。
上のロゴはもちろん画像ではなく、任天堂を表す絵文字です。
任天堂以外のあらゆる企業や個人も独自の絵文字を発行することができ、128ビットUNICODEわずか1文字だけでURLを表すことができるため非常にわかりやすい世界になります。
下の:nintendo:はCPURSが発行する短縮表記で、これをIPv6アドレスと相互変換するDNSのような仕組みをCPURSが提供します。
"a"や"あ"あたりの争奪戦は"sex.com"どころではないレベルになり、今後CPURSサービスが大繁盛して世界経済に寄与するのは間違いないでしょう。
128ビットUnicodeを使うことで、死ぬほどややこしい文字コード問題も、IPv6アドレス長過ぎ覚えられない問題も、一挙に解決となりした。
ついでに地球温暖化も経済対策も行えるということで、実に素晴らしいアイデアですね。
是非とも早急に普及してほしいRFCです。
しかしどうでもいいんだけど、RFCはいったいいつまでこのフォーマットを続けるつもりなんですかね。
いいかげんテキスト部分だけでも構造化してほしい。
あとGoogleはUmojiを何故か鵜飼と訳するのだが、本当にそんな意味があるのか？