職場で勉強会を行うということで、RFCについて調べたのですけど、多忙を言い訳に勉強会そのものが忘れ去られてしまいました。はしょった部分やきちんと理解できていないところも多いと思いますが、お蔵入りになってしまうのも悲しいのでココに上げておきます。元文書はWordで、そこからテキストのみ抽出しているため図表部分はめちゃくちゃです。
1.はじめに
ここではRFCの概略だけを説明する。RFCはRFCが必要になった時に読めば良い類のものであるし、必要になった場合でも代表的なプロトコルは日本語訳も多く存在している。RFCの存在とその位置付けを意識していただければ幸いである。
参考文献というかパクリ
「月間Interface 2003年6月号 TCP/IPの現在とVoIP技術の全貌」
2.RFCとは何か
RFCの多くはインターネットのためのプロトコル定義書である。多くと言うのはインターネットとTCP/IPプロトコルの公式な仕様だけでなく、コンピュータでの通信に関するさまざまなRFCが存在するからである(中には詩やジョークなども含まれている)。
RFCはIETF(Internet Engineering Task Force)により発行されるドキュメントである。インターネットプロトコルにはもう1つ大きな文化があり、国際電気通信連合のITU-T(International Telecommunication Union - Telecommunication Standardization Sector)勧告文書がそれにあたる。
RFCを理解するためにはITU-Tも知らなければならない。それぞれ、その文化ごとに設計されるプロトコルは異なる特徴をもつ。
3.ITU−Tによる勧告の決め方
ITU-T(http://www.itu.int/)は、通信分野のプロトコル標準化を行う国連の一組織である。以前は,国際電信電話諮問委員会CCITTと呼ばれていた。このメンバは各国の通信の主官庁(日本では総務省)や主管庁から承認された事業者、学術団体などである。また、各国にITU-Tに対応する組織があり、日本の場合には,(社)電信電話技術委員会TTC(The Telecommunication Technology Committee)がそれにあたる。これは民間標準化機関であるが、総務省によって国際標準のITU-T勧告に基づく、唯一の国内標準作成機関として認定されている。つまり誰でも参加できるわけではない。
ITU-Tにおける標準化の特徴は、face-to-faceでじっくりと議論をすることである。そして、その承認は投票で行われる。このため、承認には平均で9か月を要していたが、最近では電子メールを利用したりして、これを短縮する努力がなされている。ITU-Tに対応する日本の組織TTCでは、国内標準を決めるだけではなく、そのプロトコルを国際標準としてITU-Tに提案したり、逆にITU-Tで標準となったプロトコルに対応した国内のプロトコルの規定を行う。
ITU-Tでは、プロトコルの標準化はきわめて真面目に計画的かつ紳士的に行われる。標準化に参加している人たちは、自国の事情や技術を勧告にできるだけ盛り込もうとして努力する。この結果、豪華絢爛で機能に富み適用範囲が広いものができあがる。逆にいえば、大規模で複雑化することもあり、全部を実装することは到底かなわない。
ITU-Tの勧告名は、分野別に分類される。分野は勧告名の頭文字によって識別する。代表的な分野を表1に示す。たとえば、H.323はオーディオビジュアル/マルチメディア関連の勧告ということがわかる。また,G.729であれば、伝送システムか音声符号化の勧告であるということがわかる。
〔表1〕ITU-Tの代表的な勧告
勧告シリーズ名内 容
Hシリーズオーディオビジュアル/マルチメディア関連
Gシリーズ音声符号化方式関連
QシリーズISDNと電話網の交換方式および信号方式に関する勧告
Vシリーズアナログモデム関連
TシリーズG3/G4ファクシミリ関連
Xシリーズデータ通信網に関する勧告
Iシリーズサービス総合ディジタル網(ISDN)
4.IETFによるRFC
1)IETFは標準化組織である
ITU-Tと違いIETFには、誰でも参加可能である。やろうと思えば今すぐにでもプロトコルの提案ができる。ITU-Tが公的標準(De Dure Standard)を決定しようとするものであれば、IETFは事実上の標準(De Facto Standard)を決定するものである。IETFはインターネット協会ISOC(Internet Society)配下の組織である(http://ww.isoc.org/)。この構成を図1に示す。標準化のおおまかな方向性は,IAB(Internet Activity Board)委員会が示し、標準化を行う分野別にいくつものワーキンググループWG(Working Group)に別れている。ワーキンググループはボランティアベースであり、規格を提案したい人はワーキンググループにインターネットドラフトと呼ばれる文書を提出する。提案や議論はおもにメーリングリストで行われる。
〔図1〕ISOC構成図
2)RFCはRequest for Commentsの略である
インターネットドラフトが提案されると、これに対する意見などが広く求められる。「このプロトコルのドキュメントにコメントをください」という形でまとめられていく。その後、標準化されることになれば、Standards Track(標準化過程)に移行し、Proposed Standard(標準化提案)、Draft Standard(標準草案)、Standard(標準)という段階を経て、標準プロトコルとして認定されることになる。標準化のプロセスを経るとRFC番号が付けられる。たとえば、RFC791はIPのプロトコルを規定するRFC、RFC793はTCPのプロトコルを規定するRFCである。ただし、すべてのRFCが標準というわけではなく、いろいろな種類のものがある。たとえば、標準化の過程を経ずにプロトコルなどの情報を公開するInformational RFC、研究の結果や実験的な情報を公開するExperimental RFC、プロトコルの適用方法や利用ガイドラインなどの「その時点での最良の方法」を示すBCP(Best Current Practice)のRFCなどがある。図2にそれらを示す。
〔図2〕基本的な標準化のプロセス
3)標準化の過程
・Internet Draft
新しいインターネットのプロトコルが提案されると、IETFのワーキング グループにより仕様の検討が行われる。ワーキング グループによって検討中のプロトコルは「Internet Draft」と呼ばれ、Internet Standardsとしての基準(仕様が明確で完成されており、多くの人々に支持される見込みがある)を満たすまで繰り返し改訂が行われる。
Internet Standardsとしての基準を満たすと判断されると、Internet DraftはIESGに提出される。標準化の対象とみなされると「Standards Track」と呼ばれるカテゴリに移動し、やっと標準化の作業に入る。これに対し、基準を満たす可能性はあるが、長期的な研究が必要だと判断されると「Experimental」と呼ばれるカテゴリに移動する。
Internet Draftには6カ月間の期限があり、期限を越えても次の段階へ進む承認が得られなければ廃止される。
・Standards Track
標準化の過程にあるプロトコルは「Standards Track」と呼ばれるカテゴリに分類される。Standards Trackには「Proposed Standard」、「Draft Standard」、「Standard」と呼ばれる3つの段階がある。
このうち「Proposed Standard」は最初の段階で、独立した複数の実装を行い、相互運用のテストを行う。その後6カ月以上経過すると、IESGの承認によってDraft Standardに昇格する。もし、テストで何らかの問題が発生した場合は仕様を訂正するが、その変更が大きな場合は、新しい提案として作業を最初からやり直す。
「Draft Standard」は、広くそのプロトコルの有用性を問う段階である。仕様として十分に成熟したもので、実質的には標準とみなすことができる。この段階で4カ月以上経過し、運用実績を積み、有用であると分かれば、IESGの承認によってStandard、つまりインターネットで公式に認められたInternet Standardsプロトコルとなる。Standardに分類されるRFCは60個ほどである。
・Historic
別のプロトコルの出現と普及によって、置き換えられるなどして、使うべきではなくなったプロトコルは「Historic」と呼ばれるカテゴリに分類される。たとえば、現在、電子メールではPOP3というプロトコルが多く利用されているが、POP3の前バージョンのPOP2はHistoricになっている。
〔表2〕代表的なプロトコルのRFC番号
プロトコルおもなRFC旧版RFC
IP(Internet Protocol)RFC791RFC760
ICMP(Internet Control Message Protocol)RFC792RFC777,760
TCP(Transmission Control Protocol)RFC793RFC761
UDP(User Datagram Protocol)RFC768-
DNS(Domain Name System)RFC1035RFC882,883,973
HTTP(Hyper Text Transfer Protocol)RFC2616RFC2068
SMTP(Simple Mail Transfer Protocol)RFC2821RFC821,974,1869
TELNET(TELecommunication NETwork)RFC854-
FTP(File Transfer Protocol)RFC959RFC765
SIP(Session Initiation Protocol)RFC3261RFC2543
〔図3〕TCP/IPプロトコル群のレイヤ構造
4)プロトタイピング技法による実証
「標準化の過程」でもあるように、RFCではプロトコルが完全に定義される前から、そのプロトコルによる動作実績が必要とされる。「Rough consensus and running code(大まかな合意と、動作するコード)」という考え方で。これは『大まかな合意をまとめ、とりあえず動くものを作り、それを元にして最終的なプロトコルを完成させる』という考え方である。この考えもRFC2031に記述してある。
その他、RFCを記述するためのRFCを表3に示す。
〔表3〕RFCを書くためのRFCの代表
RFC題目おもなRFC
RFC の書き方RFC2223
要求レベルを指し示すため RFC で使用するためのキーワードRFC2119
インターネット標準化過程RFC2026
5)伝統としてのジョーク
毎年4月1日にはジョークRFCが発行される。理論的には可能かもしれないが実用性の無いものや詩などである。ただしこれらはジョークであるとは明言されていないので読む側できちんと判断しなければならない。
〔表4〕ジョークと思われるRFC
題目
TheSecurityFlagintheIPv4Header
BinaryLexicalOctetAd-hocTransport
ElectricityoverIP
FirewallEnhancementProtocol(FEP)
Etymologyof"Foo"
PiDigitGenerationProtocol
TheInifiniteMonkeyProtocolSuite(IMPS)
TheRomanStandardsProcess--RevisionIII
Y10KandBeyond
PoverAvianCarrierswithQualityofService
SMIv2を用いたドリップ式加熱飲料ハードウェアデバイスのために管理されたオブジェクトの定義
ハイパーテキストコーヒーポット制御プロトコル
IETFでの人物確認と安全性に関するガイドライン
洗濯バサミDHCPによるIPナンバーの管理
RITA--信頼性のあるインターネットワーク修理エージェント
ホスト名の付け方
関連文書のためのMIMEタイプ追加の提案
ATM上へのIPデータグラムカプセル化の実験
ネットワークに関する12の真実
IPv6アドレスの簡潔な表現
クリスマス前のテクノロジーの12日
TheAddressistheMessage
ToBe"On"theInternet
21世紀からの展望
IPバージョン9の利用の歴史的概観
SONETのソネット(14行詩)への変換
TheUniquenessofUniqueIdentifiers
退屈なIETF報告書
TheExtensionofMIMEContent-TypestoaNewMedium
Today'sProgrammingforKRFCAM1313InternetTalkRadio
RemembrancesofThingsPast
MemofromtheConsortiumforSlowCommotionResearch(CSCR)
ギガビットネットワーク経済学とパラダイムの転換
鳥類キャリアによるIPデータグラムの伝送規格
Actone-thepoems
Telnetサブリミナルメッセージオプション
スタートアップのまえのばん
Telnetランダム喪失オプション
ARPAWOCKY
5.RFCの例
1990 年のエープリルフール発行のジョーク RFC。この RFC には伝書鳩等を使ってインターネット上のデータ伝送するためのプロトコルを定義している。この RFC 1149 は、短い RFC なので、前述のRFC2223「RFCの書き方」にサンプルとして収録されている。
6.ITU−TとIETFの比較
最後にITU-TとIETFの比較をまとめる。
〔表3〕ITU-T文化とIETF文化
ITU-T文化IETF文化
優先事項プロトコルの仕様実装(ラニングコード)
プロトコル承認方投票ラフコンセンサス
ドキュメントの入手有料無料
標準の種類De Dure Standard(国際標準)De Facto Standard(事実上の標準)
2004年06月07日
この記事へのコメント
コメントを書く
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/196552
この記事へのトラックバック
http://blog.seesaa.jp/tb/196552
この記事へのトラックバック

