運用者目線からの IETF 標準化～ RFC5952 への軌跡 ～2010年 12月 10日
ＮＥＣビッグローブ株式会社 川村 聖一
ＮＥＣアクセステクニカ株式会社 川島 正伸

目次▐ Kawashima’s viewRFC5952解説とその過程など▐ Kawamura’s view
RFC発行までの道のりと裏話など

2001:db8:café::2

Kawashima’s view75th IETF Welcome Reception 会場にて
2001:db8:café::3

自己紹介▐ NECアクセステクニカ アクセスネットワーク技術部勤務。
 http://www.necat.co.jp/
 モバイルルータ（UNIVERGE WA1020） や IPv6関連製品の企画、開発業務に従事。最近だと IPv4／IPv6 トランスレート HGWなど。

▐ 2000年頃から IPv6 に取り組み始める。
 2004年には、Aterm IPv6 Prototype で IPv6 Ready Logo 取得。
 現在も、IPv6普及・高度化推進協議会 IPv6家庭用ルータSWGなどの業界活動に参加中。

▐ もともとは、ネットワークエンジニア。
 証券系大規模ネットワーク設計（ルータだけで 5,000台以上）や
ISP での BGP オペレーションも経験。IPアドレス申請やAS申請も経験。オペレータ視点の考え方は今でも持っているはず。
2001:db8:café::4

IPv6アドレス表記のおさらい （RFC4291 Section2.2）▐ 128bit を 16bit 毎に 8分割。16進数表記して、“ : ”（コロン）で区切る。
00100000000000010000110110111000000000000000000000000000000000000000001000000110001010011111111111111110000111100100100000101110↓
2001:0db8:0000:0000:0206:29ff:fe1e:482e▐ 先行する 0 は省略可能。但し、各フィールドには少なくとも 1つの数値を含むこと。
2001:0db8:0000:0000:0206:29ff:fe1e:482e↓
2001:db8:0:0:206:29ff:fe1e:482e▐ 16bit の 0 または、16bit の 0 が複数連続するフィールドを 1箇所のみ” :: ” を用いて省略可能。
2001:db8:0:0:206:29ff:fe1e:482e↓
2001:db8::206:29ff:fe1e:482e
2001:db8:café::5

RFC4291 におけるアドレス表記の柔軟性 （1）▐ Leading zeros
 先行する 0 は、省略可能 ＝ 省略しなくてもよい 以下は全て同じアドレスである
2001:0db8::0001← 省略しない
2001:0db8::1← 部分的に省略
2001:db8::0001← 部分的に省略
2001:db8::1← 完全に省略▐ 特殊な表記 ” :: ”
 16bit の 0 または、16bit の 0 が複数連続するフィールドを 1箇所のみ” :: ” を用いて省略可能。
＝ 16bit の 0 が 1フィールドだけある場合、省略してもよいし、省略しなくてもよい つまり、以下は同じアドレスである
2001:db8:a:b:c:d::1←省略する
2001:db8:a:b:c:d:0:1←省略しない2001:db8:café::6

RFC4291 におけるアドレス表記の柔軟性 （2）▐ 特殊な表記 ” :: ”
 16bit の 0 または、16bit の 0 が複数連続するフィールドを 1箇所のみ” :: ” を用いて省略可能。
＝ 複数連続するフィールド全てを省略しなくてもよい つまり、以下は全て同じアドレスである
2001:db8:0:0:0:0:0:1←省略しない2001:db8:0:0:0:0::1←部分的に省略
2001:db8:0:0:0::1←部分的に省略
2001:db8:0:0::1←部分的に省略
2001:db8:0::1←部分的に省略
2001:db8:0::0:1←部分的に省略
2001:db8::1←完全に省略2001:db8:café::7

RFC4291 におけるアドレス表記の柔軟性 （3）▐ 特殊な表記 ” :: ”
 16bit の 0 または、16bit の 0 が複数連続するフィールドを 1箇所のみ” :: ” を用いて省略可能。
＝ 省略可能なフィールドが 2箇所ある場合に、前方／後方のどちらを省略してもよい つまり、以下は同じアドレスである
2001:db8::a:0:0:1←前方を省略2001:db8:0:0:a::1←後方を省略▐ 大文字／小文字 RFC4291では、大文字／小文字のどちらを使用すべきかの記述はない。
＝ どちらを使用してもよい つまり、以下は同じアドレスである
2001:db8::0d8b←小文字
2001:DB8::0D8B←大文字
2001:db8:café::8

RFC4291 におけるアドレス表記の柔軟性 （4）▐ 前述したアドレス表記の柔軟性により、様々なアドレス表記が可能。
 以下は全て同じアドレスである
2001:0db8:0000:0000:abcd:0000:0000:0001
2001:db8:0:0:abcd:0:0:1
2001:db8:0:0:abcd::0:1
2001:db8::abcd:0:0:1
2001:db8:0:0:abcd::1
2001:DB8::ABCD:0:0:1
etc…

2001:db8:café::9

アドレス表記の柔軟性により生じる問題と実例 （1）▐ アドレス検索における問題
 表計算ソフトやテキストファイル上での検索> 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 b e packets

このアドレスがどの node で使用されているのか、管理表を検索しても簡単には一致しない。

4
5
6
7
8

2001:db8:50:1::9d6:cafe 4.343
5.022 ms
2001:db8:0:1::9d6:6 5.45 ms 2.954 ms 2.880 管理表.txt
2001:db8:0:1:0:1:9d6:7 4.589 ms 3.338 ms 3.
2001:0db8:0:0001:0:0001:09d6:7
2001:db8:70:1::249:1 5.109 ms 4.081 ms 3.98
2001:0db8:0:0001:0:0001:09d6:8
tokyo01.example.jp 7.356 ms
tokyo02.example.jp 6.191 ms
tokyo03.example.jp 5.078 ms
管理表.xls
9 osaka01.example.jp 6.699 ms 4.332 ms 4.3
AB
10 2001:db8:1:a::29 6.607 ms
2001:db8:1:b::29 6.587 ms 4.589 ms
1 2001:db8:0:1::1:9d6:7 Router
11 2001:db8:2:b000::1:80 5.983 ms 4.324 ms

2
2001:db8:café::10

2001:db8:0:1::1:9d6:8

PC

アドレス表記の柔軟性により生じる問題と実例 （2）▐ アドレス検索における問題
 whois を使用した検索
入力

出力

2001:db8:aaa:/48

2001:0db8:0aaa:/48
Whois Database A

入力

出力

2001:db8:bbb:/48

2001:DB8:BBB:/48
Whois Database B

Whois Database への登録内容と出力結果が一致しないことによる混乱
2001:db8:café::11？

アドレス表記の柔軟性により生じる問題と実例 （3）▐ アドレス解析における問題
 異なるログ出力• 複数のログをクロス分析する場合や、ログ監査目的での照合時に問題となる
ため、アプリケーションやデーモンにおける差分を吸収する必要がある。

 X.509証明書の検証• 証明書内のIPv6アドレスをテキストに変換し、単純比較を行うことで適切に検証されなかった場合、証明書が無効であると誤判定される可能性あり。

▐ 運用現場における問題 カスタマーサポート• 顧客からのエスカレーションは通常電話で行われ、表示されているアドレスを申告するため、2001:db8::1:0:0:0:1 と 2001:db8:0:1::1 が同じアドレスである
ことが理解できないことによる意思疎通の問題がある。

 ネットワークの不正利用（Abuse対応）• ネットワークの不正利用を取り扱うチームは、2001:db8::1:0:1 と
2001:db8:1::0:1 の違いを正確に把握しなければならない。
万が一、間違ったアドレスの通信を遮断してしまうとクリティカルな問題が発生する可能性がある。
2001:db8:café::12

推奨表記を IETF に提案▐ 散見される問題の発生を減らすために、
IETF （The Internet Engineering Task Force） に対して
IPv6アドレスの推奨テキスト表記に関する提案を行うと同時に、製品開発者やシステム開発者の方々に対して、
広く情報を周知する活動を行いました。
約1年半にわたる標準化活動の結果、［RFC5952］ A Recommendation for IPv6
Address Text Representation として、2010年8月に発行されました。
※RFC4291 を Update

2001:db8:café::13

RFC5952 における IPv6アドレスの推奨テキスト表記 （1）▐ 16bit の各フィールド内の先頭の “0“ は省略すること
2001:0db8:0000:aaaa::0001 → NG
2001:db8:0:aaaa::1 → OK

▐ ” :: ” を使用して可能な限り省略すること。
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

▐ 16bit 0 フィールド(＝“0000”)が1つだけの場合、” :: ” を使用して省略してはならない。
2001:db8::1:1:1:1:1 → NG
2001:db8:0:1:1:1:1:1 → OK
2001:db8:café::14

RFC5952 における IPv6アドレスの推奨テキスト表記 （2）▐ ” :: ” を使用して省略可能なフィールドが複数ある場合、最も多くの16bit 0 フィールドが省略できるフィールドを省略すること。
また、省略できるフィールド数が同じ場合は前方を省略すること。
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

▐ 小文字を使用すること。
2001:DB8::ABCD:EF12 → NG
2001:db8::abcd:ef12 → OK

2001:db8:café::15

特殊用途アドレスのテキスト表記▐ IPv4-Mapped IPv6 address[RFC4291]、ISATAP[RFC5214]、
IPv4-translatable address[draft-ietf-behave-address-format]のようなアドレスでは、IPv6アドレスの下位32bitにIPv4アドレスが埋め込まれており、16進と10進による混在表記が可能です。
 IPv4-Mapped IPv6 address の例 ： ::ffff:192.0.2.1▐ アドレスがwell-known prefixとして（RFC4291、RFC2765のように）定義されている場合、16進と10進による混在表記が推奨されます。
尚、任意のprefixが何か別の外部方式等により、IPv4アドレスの埋め込みを識別できる場合、この場合も混在表記が可能です。
▐ 検索時の完全一致（16進表記）と、高い可読性（混在表記）とを両立することはできませんので、使用環境等に応じていずれかを選択する必要があります。

2001:db8:café::16

IPv6アドレスとポート番号の結合表記▐ IPv6アドレスとポート番号を結合して表記する場合、以下のような表記が実際に使用されています。
[2001:db8::1]:80
2001:db8::1:80
2001:db8::1.80
2001:db8::1 port 80
2001:db8::1p80
2001:db8::1#80▐ RFC3986 Uniform Resource Identifier （URI）： Generic Syntaxに記述されている [ ] （上記例では、[2001:db8::1]:80）を使用すべきであり、“ : ” による結合（上記例では、 2001:db8::1:80）は不明瞭なため、推奨されません。
その他の表記については、他の形式と混在せず、他のプラットフォームへの移植性の点で問題にならなければ許容されます。
2001:db8:café::17

開発者向け情報▐ FreeBSD 7.0 において、getnameinfo() の引数に NI_NUMERICHOST フラグを指定して使用する場合、RFC5952 に準拠した出力結果が得られます。
（一部の特殊用途アドレスを除く）▐ FreeBSD 7.0 の inet_ntop() は、参照コードとしては有用ですが、プロトコル依存のため直接呼び出すべきではありません。
 詳細については RFC 4038 Application Aspects of IPv6 Transition
をご確認ください。

▐ その他の参考情報
 Perl による reference code
http://tools.bgp4.jp/IPv6canonical/IPv6canonical.txt

 IPv6 Address Validator
http://intermapper.com/ipv6validator

 ipv6calc
http://www.deepspace6.net/projects/ipv6calc.html

 The ip6addr package
http://hackage.haskell.org/package/ip6addr
2001:db8:café::18

RFC5952 発行までの過程▐ Document Timeline

IPv6協議会にてプレゼン/議論

第16回JPINIC
Open Policy
Meetingにてプレゼン/議論Internet Draft 提出
2001:db8:café::1975th IETF
at Swedenにてプ
レゼン/議論

第24回JANOG
Meetingにてプレゼン/議論

76th IETF
at 広島にてプレゼン/議論
28th APNIC
at Beijingにてプレゼン/議論2010 / 08 / 212010 / 07 / 252010 / 05 / 22

RFC Editor Processing

2010 / 04 / 22

IESG Processing

2009 / 12 / 21

2009 / 11 / 102009 / 08 / 242009 / 08 / 26

Working Group Draft

2009 / 07 / 29

2009 / 07 / 01
2009 / 07 / 09

2009 / 04 / 03

2009 / 03 / 26

Individual Draft

OSC仙台にてプレゼン/議論
78th IETF
at Netherlands
にて最終調整[RFC5952]
A Recommendation for IPv6
Address Text Representation
として正式発行
http://www.rfc-editor.org/rfc/rfc5952.txt

Internet Draft 発行前 （～2009/03/26）▐ 主要OS、ルータ等の実装を調査し、推奨表記を検討
 “ :: ” を使用して複数省略可能な場合の扱い（前方？後方？）• 原案時点では後方省略としていたが、ホストでは RFC4941 Privacy Extensions for SLAAC in IPv6 があるので前方省略の方がよいとか、ネットワーク機器やサーバは手動設定を行うので後方省略の方がよいなど意見が分かれた。

 16bit 0 の扱い（省略必要？）• RFC3513 前後でルールが変わった為、複数の実装があることを確認。
• 省略されていると感覚的には複数のフィールドがあると思ってしまうなど。

 大文字／小文字• 某大手ネットワーク機器ベンダをはじめ、一部のみ大文字。大半は小文字表記。
• RFC4291 の大文字記述に起因？

▐ 検討の結果、多くのOSや機器が採用しており、de fact standard である inet_ntop() の出力ルールを推奨表記として提案することとした。
2001:db8:café::20

Individual Draft 期間 （～2009/08/24） ： 148 days
▐ netmod （NETCONF Data Modeling Language） WG にて、
IPv6アドレス表記に関する議論をしているとのコメントあり。
 Common YANG Data Types [draft-ietf-netmod-yang-types]• “ :: ” は使用していない、Leading Zeros も省略しない。

 まもなく WGLC （Working Group Last Call） なので、オペレータから意見をもらえるのは良い機会であるとコメントいただき、
我々の推奨表記を反映してもらえた。
※2010年10月に RFC6021 Common YANG Data Types として発行。

▐ 電話等でアドレスを伝える際、Phonetic code が有効だよと、某教授よりアドバイスを受ける。
 A ： Alfa、B ： Bravo、C ： Charlie、D ： Delta、・・・・
 -01版に記述するも、すぐに反対コメントが出て、-03版で削除。

▐ IPv4 embedded address などの特殊なアドレスや、アドレスとポートの結合表記についても言及すべきとのコメント。
 -03版に記述を追加。
2001:db8:café::21

Working Group Draft 期間 （～2009/12/21） ： 117 days
▐ X.509証明書に関する問題について情報提供あり。
 Subject Alternative Name に IPv6アドレスが含まれるので、正規化した上で検証しないと、証明書が無効であると誤判定をしてしまう問題があるとのこと。
 -01版で記述を追加。

▐ Technical Document にお金の話（対応するには費用がかかる等）は、書くべきではないとコメントあり。
 -02版で関連する記述を削除。

▐ behave WG で議論している draft-ietf-behave-address-format にて
IPv4 embedded address （IPv4-translatable addresses）があるとのコメント。また、下位32bit だけでなく途中に埋め込まれるケースもあり、外部手段により識別可能ならば IPv4表記すべきとのコメントあり。
 -03版で記述を追加。
2001:db8:café::22

IESG Process 期間 （～2010/04/22） ： 126 days
▐ ISEG Member より多くのコメント。IESG の壁は高かった。
 RFC2119 Key words for use in RFCs to Indicate Requirement Levels
表現で書くべき。”SHOULD”,”MUST”,等
 Standards Track よりも BCP にすべき。
 実装者のために reference code が必要。
• C言語で書かれた inet_ntop() 以外にも、Perl の reference code を準備した。

▐ IPv4 embedded address などの特殊なアドレスに関する記述が曖昧との指摘を受け、6man WG で再度議論するも紛糾。
 最終的に、検索の一致と可読性はトレードオフであるとの説明を加筆することで議論は収束。

▐ US のとあるソフトウェアベンダより、IPv6 Address の正規化を行う
Web Page と Perl Script の紹介があり、Draft の影響範囲の広がりを実感。
2001:db8:café::23

RFC Editor Process 期間 （～2010/08/21） ： 212 days
▐ AUTH48 期間中に “ :: ” の扱いに関する表現を明確化して、Section 4.2.1 と 4.2.2 を merge しようとしたところ、それは AUTH48 の範疇ではないとの指摘あり。
IESG Process からやり直すべきとか、Errata で対応すべきなど、いろいろな意見が出て、最後の最後でまた紛糾。
 議論の結果、Section 4.2.1 に軽微な修正を加える形で収束。
 AUTH48 期間中に 6man WG に確認を求めたのは誤りだったが、結果的に、より明確な文書としてRFC化するという目的を達成することができた。
（曖昧な形でRFC化を行っても後に混乱を招くだけで意味がない。）

2001:db8:café::24

RFC5952 発行後 （2010/08/21～現在）▐ フランス人の Haskell developer より、RFC5952 に準拠すべくtool を修正したのでチェックして欲しいとの連絡あり。
 IPv4 embedded address の扱いなど、いろいろとアドバイスを実施。
• 現在、 ip6addr-0.3.2 として公開中。
Command-line tools to deal with IPv6 Addresses text representation
http://hackage.haskell.org/package/ip6addr▐ Technical Errata の報告あり。（2010/12/03）
 小文字（lower case）推奨は問題なのでは？との指摘。
 6man WG にて議論中。Reject でよいのではとの意見多数。

▐ RFC発行後もいろいろあります。。。

2001:db8:café::25

IETFでの標準化活動（RFC発行）を経験して思うこと▐ HGWベンダと標準化は、近くにあるものだと再認識。
 標準や規格などは研究者、学者など一部の有識者が作成するもので、ベンダは既に決定した仕様に従って開発を行うのみで、仕様自体を変えることは到底できないという固定観念が強かったが、それは間違い。
強い意思と強力なパートナー、そして提案に賛同してくれる仲間の存在により、目標は達成できる！

▐ 今回の活動をきっかけに、今後も積極的に標準化活動を行いたい。
 Broadband Forum、Home Gateway Initiative、UPnP Forum、DLNA、IEEE、
ITU-T、OSGi Alliance、Wi-Fi Alliance など、HGWベンダが関連する数多くのSDOs （Standards Developing Organizations） が存在。
 IETF でも、v6ops WG や homenet WG （まもなく始動）など、HGW に関する議論が数多く行われるようになってきている。
宅内におけるULAの扱いや、DNS Proxyのあり方など、まだまだ課題も多い。
 国内で共有した知見などは積極的に海外に発信して、共有していきたい。

▐ IETF には 「運用者目線」 がもっと必要。
 特に IPv6 や周辺技術はまだまだ経験不足で、理論思考に陥りやすいので、運用者からのフィードバックがとても重要！ そして相互理解も、もちろん重要。
2001:db8:café::26

Kawamura’s view75th IETF 会場近くの Café にて

2001:db8:café::27

自己紹介▐ NECビッグローブ株式会社勤務▐ BIGLOBEのバックボーンネットワーク構築/運用、ドメイ
ン運用、IPアドレス運用を担当
 2004年～：IPv6ネットワーク構築担当
 2006年～：法人サービス(主にVPN)+IPv6担当
 2008年～：バックボーン担当▐ JANOG運営委員

2001:db8:café::28

IETFって何だろう
The goal of the IETF is to make the Internet work
better.
The mission of the IETF is to produce high quality,
relevant technical and engineering documents that
influence the way people design, use, andmanage the Internet in such a way as to make theInternet work better.
出典：RFC3935
RFC 35▐ Internetをより良くする 技術的な文書(RFC) を作成することで• 設計、運用に影響を与える• 利用に影響を与える
2001:db8:café::29

IETFの印象▐ 多くの日本人が持っている印象 研究者とベンダーが集まって標準を作る場所
 運用者は関係ない
 機器メーカーのサポート状況を確認する際に気にすればいい RFPの条件に入っていればチェックする▐ 実際大企業でもITUはチェックしてもIETFはスルーな場合が多い。
 ITUは省庁も関連している
 IETFは「誰でも」参加できるいわゆる「得体のしれない」団体

2001:db8:café::30

The Internet Ecosystem

出展: http://www.isoc.org/internet/issues/ecosystem.shtml

私からみた”勝手な”相関図
ISOC

ICANN

レジストリ

Root

IAB

IANA

IETF

IETFの技術活動を監督する立場

RIR
NIR
名前空間

番号資源

プロトコル

ISP/LIR/xSP
運用
ユーザ
2001:db8:café::32

IESG

Better Internetworkingのために
IPアドレスの管理
AS番号の管理
Incidentの対応
情報の展開
Coordination

BCPの共有
問題の提起
人脈の形成
運用情報共有Education
標準の策定
Governance総合的な目線が重要。特に「利用者」「運用者」への影
響は常に考慮する必要がある
2001:db8:café::33

それぞれの仕事の立場から考えてみる▐ 運用者が リソース管理ポリシーを適切に把握し利用する
 プロトコルや装置に要求条件を出す
 セキュリティインシデントにすぐ対応する▐ メーカーが オペレーターの要求を取り込んでくれる
 脆弱性をすぐなおす リソースの状態に応じて適切な新技術を導入する
 万人に有益な技術を標準化する▐ リソース管理者(NIR,RIR）が リソースについて適切な情報を提供する
 運用者のニーズを取り込む
 リソース運用関連プロトコルをタイムリーにサポートする
2001:db8:café::34

本来アドレスを取得してネットワークを運用する人達にとって、IETFが策定するプロトコルはJPNICの運用ポリシーやJPRS(など)が示す指針と同じくらい大事なはず
2001:db8:café::35

「IETFってよくわからない」「参加しにくい」「参加メリットがわからない」
そう思う方のためにRFC5952の裏話

2001:db8:café::36

RFC5952のきっかけ▐ Operationの実経験から出てきた問題
ログの突合が大変• ルータでは“2001:db8::1:0:0:1”だけどサーバでは”2001:0DB:0:0:1::1”

検索で引っかからず障害箇所の特定が長引いた• tracerouteの結果とコンフィグの検索が合わない• tracerouteとアドレス管理が合わない

設定の記述がバラバラで可読性が悪い

なんとかしたい、、、しかしどうすればいい？
2001:db8:café::37

Internet Draftの作成▐ 「こうなってほしい」という思いをメモ書き▐ Operation(JANOG)で知り合った友人Randyに相談 ツール、協力者を紹介してもらう xml2rfc http://xml.resource.org/を使って整形▐ Internet Draftの形に仕上げて数名の信頼できる人に相談 Co-author川島さんにもこの時点で相談

2001:db8:café::38

「メモ書き」から抜粋
4. A strict text representation model
4.1 Handling 'leading zero's
All leading zeros MUST NOT be used in IPv6 address text representation.
2001:0db8::/32 MUST be represented as 2001:db8::/32. "0000" MUST be
represented as "0".
4.2 Lower case
All letters MUST be in lower case.
4.3 "::" usage
The use of "::" MUST NOT be used to shorten only one 16bit 0 field.
2001:db8::1:1:1:1:1/128 MUST be represented as 2001:db8:0:1:1:1:1:1/128. Also,
when there is a case where "::" can be used twice, "::" MUST be used in the latterpart (i.e 2001:db8:0:0:1::1/128 instead of 2001:db8::1:0:0:1/128). Whenever there
are two or more 16bit 0 fields, "::" MUST be used and MUST be shortened to its
maximum capability (i.e. 2001:db8::0:1/128 is wrong).
2001:db8:café::39

IETFへのアプローチ▐ 作法と文化 Operationの世界にはないIETF独特の雰囲気
 主要ワーキンググループチェアへの相談• 議論に適したWG, Intended Status• 感触

 強くバックアップしてくれる大物の存在▐ メーリングリストでの議論
 タイムリーで丁寧な返信
 複数WGへの「飛び火」にも対応
 膨大な数のOff-listメール対応
2001:db8:café::40

標準化までの出来事 in 1 slide▐ IETF75＠ストックホルムで初プレゼン
 賛同多数でWGアイテムとして採用▐ 地元開催(IETF76@広島)でラストコール▐ IESGの壁
 細かい文言含め多数のポイントを書き直し
 なかなか進まない承認プロセス
 IESGの人員交代▐ 2010年8月ついにRFC発行！
2001:db8:café::41

こんなにいいことありました▐ 多数のベンダーさんがRFC対応してくれました▐ IETFの他の活動に目がいくようになり、今まで抱えていた課題の解決策が良く見えるようになりました▐ メーカーのコア開発者と仲良くなれました▐ 結果、RFCと関係ない開発要求もしやすくなりました▐ 今日この場でみなさんのお時間をいただくことができました
2001:db8:café::42

標準化活動を振り返って■ 強い気持ち、強い思いが一番大切
・Yes, Thank youだけでは何もなせない・自分だけでなく、Internetのためになること■ 仲間は大事・IETF外での交流が助けてくれた■ 英語力・高いレベルでみんな戦っている・助けてくれる仲間がいれば何とかなる
2001:db8:café::43

標準化活動を振り返って：運用者目線とRFC5952
Operation

・ アドレスの表記が統一されていない課題がある・ この課題は運用現場で様々な問題の原因となっている
・ 解決策が必要

・ 現状実装を考慮すると最も影響が少なそうな案はinet_ntop風・ 今後の拡張も考慮した案が必要

Protocol・ オペレーターも、ベンダーも両方の因果関係を意識した目線を持つことが大切
・ RFC5952はこれが実現できた
2001:db8:café::44

標準化活動を振り返って：ToDo▐ IPv6には、実質解決されていない問題がまだある▐ AAAA&Aを同一ドメインで対応 (happy eyeballs)▐ 「プライベート利用」アドレス▐ RA Security▐ etc…
▐ 運用目線で見て問題と感じる点は、早くIETFに持ちこんで解決させる必要がある▐ 同じ過ちを繰り返さないために

2001:db8:café::45

まとめ
1. Operation影響を考慮した「運用者目線」を持つ事は重要
2. Resource、Operation、Protocol、Securityは相互に深く関係している
3. Operationからのフィードバック無くして良いプロトコル
はありえない4. 良いプロトコルなくしてユーザが満足できるInternetは提供できない
5. 問題を抱えているなら、IETFにチャレンジしてみてはどうだろう

2001:db8:café::46