ニュースレターNo.46/2010年11月発行

RFC5952-IPv6アドレスの推奨表記
IPv6アドレス表記の柔軟性が起こす問題とRFC5952の解説

2010年8月21日にIPv6関連のRFCとして、新たにRFC5952^※1が発行されました。本コーナーでは、前半でこのRFCで記述されているIPv6アドレスの推奨表記について、執筆者の一人であるＮＥＣアクセステクニカ株式会社の川島正伸氏に解説していただきます。

また後半では、RFC5952ができるまでの流れを、共著者であるＮＥＣビッグローブ株式会社の川村聖一氏に振り返っていただき、一つのRFCが世に出るまでの舞台裏をご紹介したいと思います。

IPv6アドレスの推奨表記
～RFC5952の解説～

ＮＥＣアクセステクニカ株式会社
川島正伸

IPv4アドレス在庫枯渇をきっかけとして、ISPをはじめとする多くの通信事業者にてIPv6の導入が進められています。しかし、具体的な検討やサービス開発を進める上で、IPv6アドレスのテキスト表記が統一されていないことによる諸問題が散見されるようになってきました。

このような状況を改善すべく、ＮＥＣビッグローブ株式会社の川村聖一さんと共同で、IETFに対してIPv6アドレスの推奨テキスト表記に関する提案を行うと同時に、製品開発者やシステム開発者の方々に対して、広く情報を周知する活動を行ってきました。

以下では、RFC5952^※1として発行された、IPv6アドレスの推奨テキスト表記について、要点解説を行います。

IPv6アドレス表記の柔軟性

IPv6アドレスのテキスト表記方法は、RFC4291^※2の2.2節にて既に仕様化されているのですが、表記としての柔軟性が高いため、実装者はさまざまな表記方法を選択することが可能になっています。

例えば、次のIPv6アドレスはいずれもRFC4291に準拠した表記となっていますが、“すべて同じ”IPv6アドレスを表しています。

RFC4291に準拠したIPv6アドレスの表記例

2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1

これらのIPv6アドレスを見れば、何か問題が起こるのではないかと、直感的に理解いただけるのではないかと思います。

顕在化する問題は？

前述したIPv6アドレス表記の柔軟性により顕在化する問題は多岐にわたります。

ISPや企業の多くは、表計算ソフトやテキストエディタを使用してIPアドレス管理を行っていますが、このようなアプリケーションの中には、正規表現を使用した検索を行うことができないものがあります。また、正規表現を使用できるアプリケーションであったとしても、エンジニアではない使用者の場合、正規表現を意識した検索を行わないことが想定されます。IPv4では、ほとんどのケースで正規表現を使用した検索は行われていませんから、当然のことと言えます。

＞traceroute6-I www.example.jp
traceroute6 to www.example.jp(2001:db8:2:b000::1:80)
from 2001:db8:10:200::2929:1129, 64 hops max, 16 byte packets

4: 2001:db8:50:1::9d6:cafe 4.343 ms^*5.022 ms
5: 2001:db8:0:1::9d6:6 5.459 ms 2.954 ms 2.880 ms
6: 2001:db8:0:1:0:1:9d6:7 4.589 ms 3.338 ms 3.236 ms
↑このアドレスがどのnodeで使用されているのか、管理表を検索しても一致しない。
7: 2001:db8:70:1::249:1 5.109 ms 4.081 ms 3.984 ms
8: tokyo01.example.jp 7.356 ms
tokyo02.example.jp 6.191 ms
tokyo03.example.jp 5.078 ms
9: osaka01.example.jp 6.699 ms 4.332 ms 4.361 ms
10: 2001:db8:1:a::29 6.607 ms
2001:db8:1:b::29 6.587 ms 4.589 ms
11: 2001:db8:2:b000::1:80 5.983 ms 4.324 ms 4.236 ms

管理表.txt
2001:0db8:0:0001:0:0001:09d6:7
2001:0db8:0:0001:0:0001:09d6:8

管理表.xls

?	A	B
1	2001:db8:0:1::1:9d6:7	Router
2	2001:db8:0:1::1:9d6:8	PC

図1　表記の柔軟性によりtraceroute実行時に問題が起こる例

正規表現を使用した検索が行われない場合、本来存在するはずのIPv6アドレスを検索することができず、考えられるIPv6アドレス表記をいろいろと検索して、“検索に一致しません”のようなメッセージを何度も目にすることになるかもしれません。それだけでなく、そもそも検索に一致しなかったのだからと、既に存在するIPv6アドレスを使用して、アドレス重複の問題を引き起こすかもしれません。

また、トラブルシューティング等の目的で、ネットワーク図に記述されているIPv6アドレスを検索することがよくあります。この場合も同様に、考えられるIPv6アドレス表記を手当たり次第に検索することにより、トラブル復旧までに無駄な時間を費やすことになってしまいます。

その他、ISPのIPアドレス管理担当者はWHOISシステムを頻繁に使用しますが、入出力の結果が同じでなかった場合や、各地域のWHOISシステムの出力結果が統一されていないことで、混乱を招く担当者もいるでしょう。

ログ分析や設定情報の監査を行う場合にも、問題が顕在化します。複数のログをクロス分析する場合や、監査目的でログを照合するような場合、モジュールや機能間の差分を吸収するために正規化処理が必要となります。

顧客からの問い合わせや、Abuse対応等の運用面でも問題が顕在化します。顧客は必ずしもエンジニアではありませんし、IPv6技術に詳しくない可能性もありますので、顧客から伝えられたIPv6アドレスを正規化して把握する必要があります。同様にAbuse対応においても、IPv6アドレスの柔軟性を意識した対応が求められます。もし万が一、報告されたIPv66アドレス等を間違って認識してしまった場合には正常な通信を止めてしまうなど、想定外の深刻な状況に陥るかもしれません。

その他の問題として、OSやネットワーク機器を変更する場合に、IPv6アドレス表記の柔軟性を吸収するためのコード修正や、余分な作業が発生する可能性があります。

また、一つの文書を複数の著者にて執筆するような場合、IPv6アドレス表記に一貫性のない文書となってしまう可能性があります。

さらに、誤読の例として、大文字“D”と数字の“0”や、大文字“B”と数字の“8”が挙げられます。

IPv6アドレスの推奨テキスト表記

IPv6アドレスのテキスト表記を統一することにより、前述した問題の発生を低減することが期待できます。

次に、RFC5952で仕様化された推奨テキスト表記のルールを示します。

（1）16-Bit Field 内の先頭の“0”は省略すること。
※“0000”の場合は、“0”にします。

例．

2001:0db8::0001: → NG
2001:db8::1: → OK

（2）“::”を使用して可能な限り省略すること。

例．

2001:db8:0:0:0:0:2:1: → NG
2001:db8::0:2:1: → NG
2001:db8::2:1: → OK

例．

2001:db8:1:1:1::0: → NG
2001:db8:1:1:1::: → OK

（3）16-Bit 0 Field（＝“0000”）が一つだけの場合、“::”を使用して省略してはならない。

例．

2001:db8::1:1:1:1:1: → NG
2001:db8:0:1:1:1:1:1: → OK

（4）“::”を使用して省略可能なFieldが複数ある場合、最も多くの16-Bit 0 Fieldが省略できるFieldを省略すること。また、省略できるフィールド数が同じ場合は前方を省略すること。

例．

2001:0:0:1:0:0:0:1 の場合、

2001::1:0:0:0:1: → NG
2001:0:0:1::1: → OK

例．

2001:db8:0:0:1:0:0:1 の場合、

2001:db8:0:0:1::1: → NG
2001:db8::1:0:0:1: → OK

（5）“a”～“f”は小文字を使用すること。

例．

2001:DB8::ABCD:EF12: → NG
2001:db8::abcd:ef12: → OK

[参考]

IPv6 Addressing Architectureは、RFC1884 → RFC2373 → RFC3513 → RFC4291と過去3度にわたり改訂が行われてきましたが、RFC3513への改訂時点で上述の（3）の扱いが、“multiple groups”から“one or more groups”に修正されているため、IPv6対応製品の中でも準拠しているRFC番号により、IPv6アドレス表記が異なっています。つまり、RFC3513またはRFC4291に準拠した製品やシステムの場合は、RFC5952に準拠するための修正が必要となります。

なお、inet_ntop()やWSAAddressToString()のような、プログラミング言語におけるライブラリ関数の大半のバージョンでは、上記の推奨表記で出力する実装が行われています。

その他にRFC5952では、IPv4-Mapped IPv6 Address（IPv4射影アドレス）のような特別なIPv6アドレスの扱いや、IPv6アドレスとポートを併記する場合についても言及していますので、ご参照いただければ幸いです。

最後に

IPv6アドレスの推奨テキスト表記をRFCとして標準化できたことには大きな意味がありますが、この仕様に準拠した製品やシステムが増えることにより諸問題の発生を無くすことこそが、我々の本来の目的と考えていますので、引き続き広く情報の周知を行っていきたいと思います。

この記事を読んでいただき、IPv6アドレス表記に関して思い当たる点がありましたら、さっそく推奨表記の検討を開始いただけましたら幸いです。

最後に、RFC発行に至るまで多くのご支援をいただきました関係者の皆さまに、この場をお借りしてお礼申し上げます。

※1 [RFC5952] A Recommendation for IPv6 Address Text Representation: http://tools.ietf.org/html/rfc5952
※2 [RFC4291] IP Version 6 Addressing Architecture: http://tools.ietf.org/html/rfc4291

RFC5952までの道のり
～一つのRFCができるまで～

ＮＥＣビッグローブ株式会社
川村聖一

2009年3月13日、後にRFC5952となるメモ書きが生まれました。この時点では、まだInternet-Draft(I-D）の形にすらなっておらず、社内での検討事項や自らの経験談を書きなぐって、RFCのような段組を真似て整形したテキストファイルでした。当時のタイトルは、“A Strict IPv6 Address Representation Model”でした。

IETFが策定しているRFCシリーズは、仕事上読むことは多々ありましたが、まさか自分がインターネットプロトコルの標準化活動に加わることなんて、全く考えていませんでした。私は、ISPネットワークを運用する仕事に就いているため、RFCはどこかの偉い人が策定した技術であり、運用者とはあまり縁が無いものと考えていました。ISPで運用を担当している側のほとんどの人が、おそらくIETFに対して同様の距離感を持っているのではないかと思います。「餅は餅屋」、私が技術者としてインターネットに関わり出した2004年には、既にそういう風潮でした。もちろん、すべての方がそうではありませんが、IETFと運用現場には、埋めがたいほどの距離ができていたと感じます。

きっかけ

長年IPv6のネットワークを運用していて、機器の出力するログ、コンフィグレーションファイルの表示、WHOISなどのインターネット上にあるデータベース、さらには人と人の間で伝えるアドレスの書き方がバラバラであることは、インターネットに関わる人々、エンジニアだけでなく営業や顧客、事務職員なども含め、全員にとって一つもメリットが無く、むしろ障害時間を長引かせたり、誤りを増やしたり、デメリットばかりだということに気付きました。

「どうすればこれを正すことができるのか」

IPv6が関係するすべての人・物に共通の基準を、標準化として策定するしかないと感じました。

しかし、IETFになんて参加したことがない……どうすれば良いのだろうか。オペレーターが標準化なんて場違いなのでは。そんな時に私を助けてくれたのは一人の友人でした。

Internet-Draft(I-D）初版提出

この業界で、Randy Bushという名前をご存じの方は多いと思います。IETFのワーキンググループ（WG）チェアを務め、世界各地のNOG^※1の運営に携わったり、発展途上国のインターネット発展に貢献したりするなど、功績を挙げるとキリがありません。

どうやってIETFに提案してよいかわからない私は、RFCを真似たメモ書きを彼に送り、二つお願いをしました。

IETFに提案したいので、相談に乗ってください。また、他に相談に乗ってくれそうな人を紹介してください。
I-Dを提出するためにはどうすればいいでしょう。

Randyはメモの内容に賛同してくれ、すぐ力になってくれました。まず、正しいI-Dの形式に仕上げるためのツールと、力になってくれる知人を紹介してくれました。その時に紹介された知人は、今では会うたびに、一緒に夜遅くまでお酒を飲む仲です。

この段階で、実装面での相談をしていた、共著者であるＮＥＣアクセステクニカ株式会社川島正伸さんも加わり、周りの手厚い支援のおかげもあって、I-D初版が完成しました。初版提出の時点で、現在のRFC5952のタイトル“A Recommendation for IPv6 Address Text Representation”になっています。

IETFの洗礼

I-Dの提出はごく簡単なもので、XMLファイルとテキストファイルを、IETFのWebページにあるツールからアップロードするだけです。XMLファイルで原稿を書き、xml2rfcというツールを使い、テキストファイルに整形しました。XMLのひな型は、IETFのページで探してきたものをベースに作成しました。

提出した後、通常は想定しているWGのメーリングリスト（ML）に、「こういうDraft書きました。ぜひ読んでコメントください」と投げるのが一般的なようです。このような慣例を全く知らず、出しっ放しにしていました。しかし、提出した時点からすぐに、たくさんの賛同、コメント、修正案が、知らない人からメールで届くようになります。私はこれには感激しました。いただいたコメントの中に、IPv6に関するオペレーション技術や、移行技術に関する議論を行う、v6ops WG（IPv6 Operations WG）で取り上げる方がよいのではないか、という提案がありました。

そこで、何のツテもコネも無い私は、Ccに友人のRandyを入れ、IPv6のプロトコルそのもののメンテナンスを実施する6man WG（IPv6 Maintenance WG）と、v6ops WGの、チェアとエリアディレクターの方々に、どのWGに、どのような形で紹介するのが良いか、相談メールを出しました。

今までIETFで登場したこともない人間が、よくもこんな怖いもの知らずな行動を起こしたものです。最初は、ほとんど相手にしてもらえませんでした。しかし、提出当初にコメントをいただいた方のうちの一人が、「こんなDraft出たんだけど、とても良いと思います」というコメントを、v6opsのMLに出してくれました。そこからWGチェアも少し注目してくれるようになり、チェアとディレクターの間で議論した結果、6man WGの題材として、IETFのミーティングで取り上げることが決まりました。

感動の初IETF参加

初めてのIETF参加で、初めてのInternet-Draftで、初めてのヨーロッパ。初めて尽くしの中、体調不良により、予定している飛行機に乗れないアクシデントもあり、1日遅れでIETF75開催地のスウェーデン入りしました。周りは知らない人ばかり。その中で初発表です。Draftについて発表を終えた途端、たくさんの人がマイクに並びました。感動的なことに、一つもネガティブな意見は無く、満場一致で6man WG Draftとなることが、その場で決まりました。後々知ったのですが、初回提案で、個人執筆のI-DがWG Draft^※2となることは、かなりレアケースのようです。

初回でこれだけ成功したのは、初版を提出した2009年3月から7月までの間、何十通のメールをさまざまな方々に個別で書いたり、アドバイスを聞いたりした結果と、大切な友人に支えられていたからだと思います。

日本開催IETFでの成果

6man WG Draftとして、ラストコール^※3をホームである日本で迎えたい、という思いは初版を作成した時からありました。願いはかない、広島で開催されたIETF76で無事ラストコール状態に持っていくことができ、RFCまでの道のりは順調かと思いました。IETFをよく知る日本人の方々にも「おめでとう」と言われ、正直あまりピンときませんでしたが、周りの人が言うなら、これでほぼ終わりなのかな？と思っていました。

苦難の連続

しかし、ここからが本当の戦いの始まりでした。ラストコールは、6man WGとしてのラストコールの他に、“Standards Track”^※4として進められる文書は、IETF全体でのラストコールにかかります。このIETFラストコール中に、他WGからさまざまな変更、追加依頼が加えられます（RFC5952のSection5、Section6は、この時点で大きく変わりました）。ラストコール中の調整もかなり大変だったのですが、その後のIESG reviewという状態が最も大変でした。IESG（Internet Engineering Steering Group）^※5は、RFCを承認する機能を持っている組織であり、IETFの技術活動すべての責任を負っています。そのIESGからストップがかかりました。

IESGとの調整は難航します。IESGはそもそも忙しい人の集まりなので、なかなか調整が進まない他、技術的な責任を負っているため、かなりチェックが厳しいのです。結果として、IESGの承認を通すのに数ヶ月かかり、文書の表現は厳格な言い回しに変更することになりました。この間、数々のクレームやネガティブなコメントを、さまざまな方にいただきました。この時点では、I-Dを最初に発表した時の純粋な気持ちよりも、いかにして標準化を押し通すか、挙げられた課題を解決するか、承認が取れるように働きかけるか、ということを、優先して考える必要がありました。会社内の動きと同じです。なかなか思うように進まない状態に、心が折れそうになることが多々ありましたが、標準化する重みと責任を感じながら、何とか承認を得ることができました。

RFCの発行と振り返り

2010年8月21日、最初のメモ書きができ上がってから約1年半後、RFC5952としてIETFから正式に発行されました。最初に感じたのは安堵、そして感謝の気持ちが止まりませんでした。

1年半の活動を通して、さまざまな方に支えられてきました。RFC5952がRFCにたどりついたのは、周囲に支えられたことが最大の成功要因でした。筆者二人の力ではありません。本当に仲間に恵まれていて、良い仲間に巡り会える運があったのだと思います。全員の名前を挙げることはできませんが、支えていただいたみなさまに、ここであらためて御礼を申し上げます。

メモ書き作成当初より、RFCにすることがゴールではありませんでした。「実装、および人々の慣例が共通化されること」がゴールです。RFC化することにより、参照できるインターネットコミュニティのコンセンサスを代表する文献ができ上がり、この目的を達成しやすくなりました。ここからまた、さまざまな方々に協力いただきながら、よりインターネットが運用しやすい環境になるよう普及努力を続けていくつもりです。

IETFについて思うこと

IETFで活動するために必要なのは、重要度の高い順に以下の要素だと私は感じています。

1.強い気持ち
1.1 技術的な思いの強さ
1.2 心の強さ

2.仲間

3.英語力（これはかなり高いレベルが要求されます）

強い気持ちというのは、二つの要素があります。一つは、技術的にこれは本当に必要だという信念です。これさえあれば、IETFにアイデアを持ち込む価値がありますし、絶対にそうするべきです。もう一つは、心の強さ。IETFでの活動は、本当に疲れます。会議では、1,000人を超えるさまざまな国のエンジニアが集まり、WGのMLには何千人も参加しています。それだけ人がいれば、さまざまなことを言われます。Yes、Thank youだけでは、絶対に前に進めません。場合によっては断る勇気、戦う勇気が必要です。もし技術的な思いはあるが議論に自信の無い方は、心の強い共著者を見つけることが大事だと思います。
仲間は、最初からいる必要はありませんが、仲間を作る活動はとても大切です。困った際には仲間は必ず助けてくれますし、助言もしてくれます。IETFにもコネの原理は働きます。時間はかかってもよいので、仲間を作る時間は大切にする必要があります。ただし、自分の目的を達成するためだけの活動では、なかなか仲間は増えません。インターネットに貢献する気持ちを持って、他の方の活動にもしっかり目を向けることが大事です。
最後に、IETFでは高いレベルの英語力が必要です。もし英語に自信が無いなら、英語に強い共著者を見つけるべきでしょう。私は米国出身であることが幸いしましたが、それでも日本に住んでいるだけで多少のハンデがあると感じています。ネイティブの方と打ち解けて、一緒にDraftを書くのが最もよいと思います。もしそれができない場合でも、仲間を増やす程度の英語力は必要です。
また、日本人らしい謙虚な気持ちを忘れないで活動すれば、外国の方々によりよく接してもらえるのではないかと思います。日本は素晴らしい国、日本には素晴らしい技術者がいるということを、大いに世界にアピールしていきましょう！

See you at IETF!

※1 NOG（Network Operator's Group）: 地域毎に開催されている特徴があり、日本はJANOG、北米はNANOGなど、xxNOGという名前になっていることが多いです。
※2 標準化までの過程: I-Dは一般的に、個人としての提案からWG Draftを経てRFCとなります。個人としての提案がそのままRFCとなるケースもありますが、そのたぐいの文書はIETFの中でも、一般的な標準RFCと扱いが異なります。
https://www.nic.ad.jp/ja/rfc-jp/Std-track.html
※3 ラストコール（Last Call）: ワーキンググループとして「完成」状態にもっていく前に行われる、最後の意見募集のことです。
※4 RFCの種類: RFCは大きく二つの種類、いわゆる「標準化」であるStandards TrackとNon-Standards Trackに分かれます。Standards Trackは、より厳しいプロセスを通すことになります。
https://www.nic.ad.jp/ja/rfc-jp/RFC-Category.html
※5 IESG（Internet Engineering Steering Group）: IETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループです。