戻る
Since 2002/4/30, Final update 2005/8/16
RFC 1883「インターネットプロトコルバージョン６（IPv6）の仕様」（日本語訳）と
RFC 1885「インターネット・プロトコルバージョン６（IPv6）インターネット制御メッセージ
プロトコル（ICMPv6）仕様」（日本語訳）が
ＩＰｖ６の基本仕様として最初に定義されました。
これはRFC 2460とRFC 2463の出現で時代遅れになりました。
RFC 2460「インターネットプロトコルバージョン６（IPv6）の仕様」（日本語訳）と
RFC 2463「インターネット・プロトコルバージョン６（IPv6）インターネット
制御メッセージプロトコル（ICMPv6）仕様」（日本語訳）が
現在のＩＰｖ６の基本仕様になります。
RFC 3697「ＩＰｖ６フローラベル仕様」（日本語訳）
ＩＰｖ６の使い方が明確でないフローラベルの最低条件を規定しています。
RFC 1970「ＩＰバージョン６（ＩＰｖ６）の近隣探索」で、
近隣探索（Neighbor Discovery ＝ND）と呼ばれる、ルータの検出、リンク上の他のノードの発見や、
リンクアドレスの調査などの一般論が記述されました。これは
RFC 2461「ＩＰバージョン６（ＩＰｖ６）の近隣探索」（日本語訳）
に置き換えられています。
RFC 3122「逆探索のためのＩＰｖ６近隣探索の拡張仕様書」（日本語訳）
で逆近隣探索（ＩＮＤ）と呼ばれる、リンクアドレスから対応するＩＰｖ６アドレスを知る方が書かれています。
RFC 3756「ＩＰｖ６近隣探索（ＮＤ）信頼モデルと脅威」（日本語訳）
で近隣探索のセキュリティが議論されています。
RFC 1981「IPバージョン6のためのパスMTU探索」（日本語訳）で、 パスＭＴＵ探索と呼ばれる、通信パスの最大パケット長の調査方法が記述されます。
RFC 1972「イーサネットネットワーク上のＩＰｖ６パケット送信の方法」で
イーサネット上でのＩＰｖ６の扱い方が記述されました。これは、
RFC 2464「イーサネット上でのIPv6パケット転送」（日本語訳）で
置き換えられています。
RFC 2019「ＦＤＤＩネットワーク上のＩＰｖ６パケットの送信の方法」で
ＦＤＤＩ上でのＩＰｖ６の扱い方が記述されました。これは、
RFC 2467「ＦＤＤＩネットワーク上でのＩＰｖ６パケット伝送」（日本語訳）
に置き換えられました。
RFC 2470「トークンリングネットワーク上でのＩＰｖ６パケット伝送」（日本語訳）
でトークンリング上でのＩＰｖ６の扱い方が書かれています。
RFC 2023「ＰＰＰ上のＩＰｖ６」でPPP上でのＩＰｖ６の扱い方が記述されました。これは
RFC 2472「ＰＰＰ上のＩＰｖ６」（日本語訳）に置き換えられています。
RFC 2491「非ブロードキャスト多数アクセス（NBMA）ネットワーク上のＩＰｖ６」で、
ＮＢＭＡ（非ブロードキャストマルチアクセス≒公衆電話網）リンク上でのＩＰｖ６の扱い方が書かれています。
RFC 2492「ATMネットワーク上のＩＰｖ６」でATM上でのＩＰｖ６の扱い方が書かれています。
RFC 2497「ARCnetネットワーク上のＩＰｖ６パケットの伝達方法」でARCnet上でのＩＰｖ６の扱い方が書かれています。
RFC 2590「ＩＰｖ６パケットをフレームリレー上で転送する仕様書」（日本語訳）で
フレームリレー上でのＩＰｖ６の扱い方が書かれています。
RFC 3146「ＩＥＥＥ１３９４ネットワーク上でのＩＰｖ６パケット転送」（日本語訳）で
ＩＥＥＥ１３９４上でのＩＰｖ６の扱い方が書かれています。
RFC 3572 「ＭＡＰＯＳ上のインターネット・プロトコルバージョン６（ＳＯＮＥＴ／ＳＤＨ上の多数アクセスプロトコル）」（日本語訳）で
ＭＡＰＯＳ上でのＩＰｖ６の扱い方が書かれています。
RFC 1971「ＩＰｖ６ステートレスアドレス自動設定」でルータ広告に基づくステートレスアドレス自動設定と、アドレスを使用する前に行うアドレス重複検出（DAD)が規定されています。
これは、
RFC 2462「ＩＰｖ６ステートレスアドレス自動設定」（日本語訳）に置き換えられています。
RFC 3041「ＩＰｖ６ステートレスアドレス自動設定のプライバシー拡張」（日本語訳）で ステートレスアドレス自動設定に、ＭＡＣアドレスを隠すためのプライバシー拡張が書かれています。
RFC 3315「ＩＰｖ６の動的ホスト設定プロトコル（ＤＨＣＰｖ６）」（日本語訳）で
ステートフルな動的アドレス自動設定（ＤＨＣＰ）が規定されています。
RFC 3736「ＩＰｖ６のための状態なし動的ホスト設定プロトコル（ＤＨＣＰ）サービス」（日本語訳）で
ＤＨＣＰをステートレスに使い、情報を得るだけの方法が書かれています。
RFC 3484「インターネット・プロトコルバージョン６（ＩＰｖ６）のためのデフォルトアドレス選択」（日本語訳）で 複数のＩＰｖ６アドレスを持つホストが通信をする際の、デフォルトのＩＰアドレスの選択方法が書かれています。
巨大ペイロードオプションは、６５５３６オクテット以上のリンクMTUを持つリンクで使うもので、
RFC 1883でＩＰｖ６の仕様の一部として書かれていたが、RFC 2460では書かれていません。
RFC 2147「ＩＰｖ６巨大パケット上のＴＣＰとＵＤＰ」で
巨大ペイロードオプションサポートするためのＴＣＰとＵＤＰの仕様が書かれています。RFC 1883とRFC 2147の記述は
RFC 2675「ＩＰｖ６ジャンボ(データ)グラム 」（日本語訳）で一本化されています。
RFC 2711「ＩＰｖ６ルータ警告オプション」（日本語訳） Multicast Listener Discovery, RSVP, Active Networksなど、ＩＰデータグラムの中身をより厳密に調査する必要がある場合に、 これをルータへ通知するためのルーや警告オプションが規定されます。
圧縮についてはＩＰｖ４とＩＰｖ６共通で定義されているようです。
RFC 2507「ＩＰヘッダ圧縮」は、PPPや無線で使用を想定して、
低中速度リンクでのパケットヘッダの影響を押さえ伝送効率を上げるためのヘッダ圧縮を規定します。
RFC 3173「ＩＰペイロード圧縮プロトコル（ＩＰＣｏｍｐ）」（日本語訳）
は エンドエンドノード間でのＩＰペイロード（上位プロトコルのデータ）の圧縮方法を規定します。
RFC 2473「ＩＰｖ６の中の総括的なパケット・トンネリング明細」（日本語訳）で
ＩＰｖ６上でのカプセル化（トンネル）の一般論が書かれています。
RFC 2529「明示的トンネルなしでＩＰｖ４ドメイン上でのＩＰｖ６の転送」で
ＩＰｖ４マルチキャストドメインをリンクの様に使ってＩＰｖ６パケットを転送する方法です。
RFC 3056「ＩＰｖ４網を経由してのＩＰｖ６ドメインの接続 」（日本語訳）で
６ｔｏ４と呼ばれる孤立ＩＰｖ６サイトをＩＰｖ６インターネットへ接続する方法が書かれています。
RFC 1933「ＩＰｖ６ホストとルータの移行メカニズム」で主な移行メカニズムがかかれています。これは
RFC 2893「ＩＰｖ６ホストとルータの移行メカニズム」（日本語訳）に置き換えられました。
これは、デュアルスタックホスト、ＩＰｖ４上のＩＰｖ６手動設定トンネル、
孤立ＩＰｖ６ホストを接続するためのＩＰｖ６自動設定トンネルとＩＰｖ４互換ＩＰｖ６アドレス（0::a.b.c.d）を含んでいます。
RFC 2765「ステートレスＩＰ／ＩＣＭＰ翻訳アルゴリズム（ＳＩＩＴ） 」（日本語訳）
でＳＩＩＴと呼ばれる、デュアルスタックノードでＩＰｖ４とＩＰｖ６のヘッダを書き換えるメカニズムを規定します。
ＩＰｖ４マップＩＰｖ６アドレス（0::ffff:a.b.c.d）や
ＩＰｖ４翻訳ＩＰｖ６アドレス（0::ffff:0:a.b.c.d）を使用します。
RFC 2766「ネットワークアドレス翻訳−プロトコル翻訳(NAT-PT)」（日本語訳）
でＮＡＴ−ＰＴと呼ばれる、ＩＰｖ４でよく使われているＮＡＴを応用したＩＰｖ４とＩＰｖ６のアドレス変換メカニズムを規定します。
RFC 2767「二重のスタックホストで「Bump-In-the-Stack」（ＢＩＳ）テクニックを使う 」（日本語訳）
でＢＩＳと呼ばれる、ＩＰｖ６スタック上でＩＰｖ４アプリケーションを動かす方法を規定します。
ＮＡＴ−ＰＴをホスト内に作ったようなメカニズムです。
RFC 3089「ＳＯＣＫＳを基にしたＩＰｖ６／ＩＰｖ４ゲートウェイメカニズム」（日本語訳）は、
ＳＯＣＫＳプロトコル（RFC 1928）に基づくＩＰｖ６／ＩＰｖ４相互接続メカニズムを規定します。
RFC 3142「ＩＰｖ６からＩＰｖ４へ転送リレー翻訳者」（日本語訳）は、
プロキシーの様に動作するＩＰｖ６／ＩＰｖ４相互接続メカニズムを規定します。
RFC 1771「BGPバージョン４の基本仕様書」 （日本語訳） がＢＧＰ４の基本的な仕様書です。 元々ＢＧＰ４はＩＰｖ４のルーチングのみをサポートし、 新たな機能追加を想定していませんので、ＩＰｖ６のルーチングはできません。
RFC 2842「ＢＧＰ４の能力通知」（日本語訳）で ＢＧＰ４に能力交渉機能を追加し、新たな機能の追加に対応しやすくしました。これは
RFC 3392「ＢＧＰ４の能力通知」（日本語訳）に置き換えられました。
RFC 2283「マルチプロトコル対応拡張」（日本語訳）で、
能力交渉機能を用いてＩＰｖ４以外のプロトコルのルーチングを可能にしました。これは
RFC 2858「マルチプロトコル対応拡張」（日本語訳）
に置き換えられました。このＢＧＰをＭＢＧＰと言いいます。
RFC 2545「ＩＰｖ６ルーチングでのBGP４マルチプロトコル拡張の使い方」（日本語訳）で マルチプロトコル対応をＩＰｖ６へ応用する方法を規定しています。 このＢＧＰをＢＧＰ４＋と言いいます。 ＩＰｖ６アドレスには有効範囲（スコープ）があり、次にパケットを転送するルータを示すのに、 グローバルアドレスとリンクローカルアドレスの両方が使えるのがＩＰｖ６の特殊な点です。 能力交渉とマルチプロトコル対応は汎用的な機能ですが、実際はＩＰｖ６のために規定した様です。
RFC 2080「ＩＰｖ６のためのＲＩＰｎｇ」（日本語訳） でＲＩＰｎｇを規定しています。
ＩＰｖ４のＲＩＰとほとんど同じです。
RFC 2081「RIPng プロトコル適用性声明」（日本語訳） は
RFC 2080の標準化を応援するものみたいです。
RFC 2740「ＩＰｖ６のためのOSPF」で、ＯＳＰＦの ＩＰｖ６への対応（ＯＳＰＦバージョン３）を規定します。
RFC 2710「ＩＰｖ６のためのマルチキャスト聞き手探索（MLD）」（日本語訳）で、
ＩＰｖ６のマルチキャスト聞き手探索（ＭＬＤ）を規定します。
ＭＬＤは、リンク範囲全ノードアドレスや範囲０（予約）や範囲１（ノードローカル） を除く、すべての受信マルチキャストで必要だそうです。
RFC 3810「ＩＰｖ６のためのマルチキャスト聞き手探索２版（MLDv2）」で、第２版が作られています。
RFC 3590「マルチキャスト受信者探索（ＭＬＤ）プロトコルのためのソースアドレス選択」（日本語訳）で ＭＬＤを見るスイッチ（ブリッジ）を考慮して、リンクローカルアドレスが使用できない時、つまりホストが起動してからアドレス重複検出（ＤＡＤ）が完了するまでの間、ＭＬＤをどうするかが規定されたいます。
RFC 1886「IPバージョン６をサポートするためのDNS拡張」（日本語訳） は
ＤＮＳにＩＰｖ６アドレス用のＡＡＡＡレコードを追加し、
逆引きのためのIP6.INTドメインの使い方を規定します。
RFC 2874「ＩＰｖ６アドレス集約サポートとリナンバリングへのＤＮＳ拡張 」（日本語訳）は
ＩＰｖ６アドレスのリナンバリングに備えてＤＮＳの新たな
ＩＰｖ６アドレスレコード（Ａ６レコード）とビットマップラベルを使った
逆引きドメインを規定しました。
しかし、
RFC 3363「インターネットプロトコルバージョン６（ＩＰｖ６）アドレスのドメインネームシステム（DNS）での表現」（日本語訳）と
RFC 3364「インターネットプロトコルバージョン６（ＩＰｖ６）に対するドメインネームシステム（ＤＮＳ）サポートでのトレードオフ」（日本語訳）
で、Ａ６レコードやビットマップラベルは実用的な意味があるか疑問、という事で実験的となってしまいました。
RFC 3152「IP6.ARPAの委任 」（日本語訳） で
逆引きにIP6.INTではなく、IP6.ARPAを使うように勧告しています。
ARPAドメインを使う理由は
RFC 3172「アドレスとルーティングパラメータエリアドメイン("arpa")
のための管理ガイドライン＆操作上の必要条件」（日本語訳）に記載しています。
なおARPAはARPANETで有名なAdvanced Research Projects Agency
（現在のDefense Advanced Research Projects Agency）の頭文字ではなく
Address and Routing Parameters Areaの頭文字で、
Defense Advanced Research Projects Agencyとは関係がないと再定義されています。
RFC 1886とRFC 3152は１つにまとめられて、
RFC 3596「ＩＰバージョン６をサポートするためのＤＮＳ拡張」（日本語訳）
として発行し直されています。
RFC 3646「ＩＰｖ６のための動的ホスト設定プロトコル（ＤＨＣＰｖ６）のＤＮＳ設定オプション」（日本語訳） は、ホストがＤＮＳリゾルバを発見する方法の１つです。
RFC 3162「ＲＡＤＩＵＳとＩＰｖ６」（日本語訳）は ＲＡＤＩＵＳプロトコルをIPv6対応にするための属性を規定します。
ＳＮＭＰ自体をＩＰｖ６対応にするための規定は特にないようですが（必要もない？）、
ＩＰｖ６もＭＩＢが規定されています。
RFC 2465「IPバージョン６ のための管理情報ベース：テキスト表現と一般的なグループ」でＩＰｖ６一般のＭＩＢを規定します。
RFC 2466「IPバージョン６のための管理情報ベース：ICMPv６ グループ」でＩＣＭＰｖ６のＭＩＢを規定します。
RFC 2452「伝送制御プロトコルのためのＩＰｖ６管理情報ベース」でＴＣＰｖ６のＭＩＢを規定します。
RFC 2454「ユーザーデータグラムプロトコルのためのＩＰｖ６管理情報ベース」でＵＤＰｖ６のＭＩＢを規定します。
RFC 2851「インターネットネットワークアドレスのテキスト表現」でＭＩＢでのアドレス表現を規定します。これは、
RFC 3291「インターネットネットワークアドレスのテキスト表現」で置き換えられています。
RFC 3019「マルチキャスト聞き手探索プロトコルのためのIPバージョン６管理情報ベース」で
マルチキャストリスナーディスカバリ（ＭＬＤ）のＭＩＢを規定します。
RFC 1884「ＩＰバージョン６のアドレス体系」（日本語訳）で
ＩＰｖ６のアドレス構造が最初に定義されました。 これは
RFC 2373「ＩＰバージョン６のアドレス体系」（日本語訳）で置き換えられました。
さらに
RFC 3513「インターネットプロトコルバージョン６（ＩＰｖ６）のアドレス体系
」（日本語訳）が
現在のＩＰｖ６アドレスの基本構造をしめします。
RFC 1881「ＩＰｖ６アドレス割り当て管理」（日本語訳） がＩＰｖ６アドレスの基本的な管理はＩＡＮＡがし、 ＩＡＮＡがアドレス空間を分割して地域レジストリに管理を委任するべきと宣言しています。
RFC 2732「ＵＲＬでのリテラルＩＰｖ６アドレスのフォーマット」（日本語訳）は、 ＵＲＬでのＩＰｖ６アドレスの表記を記述します。ＵＲＬではホスト名とポート番号の区切りなどで':'を使います。 ＩＰｖ６のテキスト表現でも':'を使うので、ＵＲＬ内でアドレスをそのまま記述すると、混乱します。 このためＵＲＬ内ではhttp://[1080:0:0:0:8:800:200C:417A]/index.htmlの様に'[]'でくくります。
RFC 2374
「ＩＰｖ６の集約可能グローバルユニキャストアドレス形式」（日本語訳） が
現在の商用のＩＰｖ６アドレス（2001(HEX)で始まるアドレス）のフォーマットを指定しています。
これは
RFC 3587「ＩＰｖ６グローバルユニキャストアドレスフォーマット」（日本語訳）に
置き換えられました。
このフォーマットで具体的にどのような団体にIPｖ６アドレスを付与するかが
RFC 2450「ＴＬＡとＮＬＡの割当て規則の提案」（日本語訳）で
規定され、さらに具体的にどの範囲のアドレスを使うかが
RFC 2928「最初のＩＰｖ６サブＴＬＡ識別子割当」（日本語訳）で
規定されています。
ＩＰｖ６グローバルアドレスのフォーマットはＩＥＴＦからＩＣＡＮＮに議論が移っており、
これらのＲＦＣは時代遅です。
RFC 3531「ＩＰｖ６アドレスブロックのビットの割当てを管理する柔軟な方法」（日本語訳）で、 拡張性を考慮したＩＰｖ６アドレスの割当手順が示されています。
RFC 1897「IPｖ６テストアドレスの割り当て」（日本語訳）で
テスト用のIPｖ６アドレスが規定されています。多分これは無効になっています。
RFC 2471「IPｖ６テストアドレスの割り当て」（日本語訳）
でIPｖ６実験網（６ｂｏｎｅ）のアドレス（3ffe(HEX)で始まるアドレス）が規定されています。
これは
RFC 2921「テストアドレスの割り当て」（日本語訳）に改定されました。
６ｂｏｎｅのメーリングリストによるとRFC 2921も２００２年３月６日に改定されています。
６ｂｏｎｅでは当初実験ＩＳＰに/24を割当てていましたが、
６ｂｏｎｅの拡大とともに新規ISPの割当が/28に変更され、現在は新規ISPの割当が/32になっています。
RFC 3701「６ｂｏｎｅ（ＩＰｖ６試験アドレス割当て）段階的廃止」（日本語訳） は６ｂｏｎｅの終了を書いています。
RFC 3849「文書化のために予約されるＩＰｖ６アドレスプレフィックス 」（日本語訳）で ＲＦＣやその他の文書で例示をする場合に2001:DB8::/32を使うように薦められています。
RFC 2375「ＩＰｖ６マルチキャストアドレスの割り当て」（日本語訳） はグローバルに定義されたマルチキャストアドレスの初期割り当てを記述します。
RFC 2526「予約されたＩＰｖ６サブネットエニキャストアドレス」（日本語訳） で リンクローカルアドレスうち１２８個がエニキャスト用に予約されています。 通常のリンクであれば、下64ビットがfdff:ffff:ffff:ffxx (xx=80〜ff)の アドレスがエニキャストになります。
RFC 3068「６to４リレールーターのためのエニキャストプレフィックス」（日本語訳） は６to４リレーエニキャストアドレス192.88.99.1と、 ６to４ＩＰｖ６リレーエニキャストアドレス2002:c058:6301::を規定します。
RFC 3306「ユニキャストプレフィックスに基づくＩＰｖ６マルチキャストアドレス」（日本語訳） は（多分ローカルに使用する）ユニキャストプレフィックスを埋め込んだＩＰｖ６マルチキャストアドレスを規定します。
RFC 1715「アドレス割当て効率のためのＨ比率」（日本語訳）は
ＩＰｖ６のアドレス割当て議論のため、アドレス割当て効率を示すＨ率を定義し、その有効性を示しています。
RFC 3194「アドレス割当効率のためのホスト密度比率：Ｈ比率の更新」（日本語訳）
はＨ比率を理解しやすくしたＨＤ比率を定義します。
RFC 2894「ＩＰｖ６のためのルーターリナンバリング」（日本語訳） は、ルーターリナンバリング（"RR"）と呼ばれる、サイト内の全ルータのアドレス情報を書き換えるためのメカニズムを定義します。
RFC 2133「ＩＰｖ６の基本ソケットインターフェース拡張」（日本語訳）で、
プログラムとＯＳ間で広範囲に使われているソケットＡＰＩの基本部分のＩＰｖ６対応が書かれ、
RFC 2553「ＩＰｖ６のための基本ソケットインターフェース拡張」（日本語訳）に
置き換えられ、
RFC 3493「ＩＰｖ６のための基本ソケットインターフェース拡張」（日本語訳）に
置き換えられました。
RFC 2292「ＩＰｖ６のための高等ソケットＡＰＩ」（日本語訳）で
ＩＰｖ６特有機能を使うためのＲＡＷソケットＡＰＩが書かれ
RFC 3542「ＩＰｖ６のための高等ソケットアプリケーションプログラムインターフェース（ＡＰＩ）」
（日本語訳）に置き換えられています。
とりあえずＩＰｖ６関連っぽいタイトルのＲＦＣをリストアップしてみました。 多くは、ＩＰｖ６プロトコルが固まるまでの間にいろいろ出た文書だと思います。
RFC 1287 未来のインターネットアーキテクチャに向かって
RFC 1338 スーパーネット：アドレス割当と集約作戦
RFC 1347 大きいアドレスのＴＣＰとＵＤＰ、インターネットアドレスとルーティングの単純な提案
RFC 1375 ＩＰアドレスの新しいクラスの示唆
RFC 1454 次のＩＰバージョンの提案の比較
RFC 1475 TP/IX：次のインターネット
RFC 1550 ＩＰ：次世代（IPng）ホワイトペーパー要請
RFC 1560 マルチプロトコルインターネット
RFC 1629 インターネットでのOSI NSA割当のガイドライン
RFC 1639 大きいアドレスレコード上でのＦＴＰオペレーション（FOOBAR）
RFC 1667 IPngのモデルとシミュレーション条件
RFC 1668 IPngの統一ルーティング条件
RFC 1669 IPng基準のマーケット現実性
RFC 1670 IPng技術的考察のインプット
RFC 1671 移行についてのIPngホワイトペーパーと他の考察
RFC 1673 IPngについての電力調査協会コメント
RFC 1674 IPngのセルラー業界の見解
RFC 1675 IPngのセキュリティの考慮
RFC 1680 ATMサービスに対するIPngサポート
RFC 1683 IPngでのマルチプロトコル互換性
RFC 1686 IPng必要条件：ケーブルテレビ産業の観点
RFC 1687 大企業ユーザーのIPngの観点
RFC 1688 次世代IPのモバイル性考察
RFC 1705 残った６つの仮想インチ：IPngにおける問題
RFC 1707 CATNIP：インターネットの共通構造
RFC 1719 IPng の方向
RFC 1726 IPの次世代（IPng）を選ぶ専門的な基準
RFC 1744 インターネットアドレス空間の管理上の考察
RFC 1752 ＩＰ次世代プロトコルのための推薦
RFC 1768 CLNPマルチキャストのためのホストグループ拡張
RFC 1809 ＩＰｖ６でフローラベルフィールドの使用
RFC 1888 OSI NSAPとＩＰｖ６
RFC 1955 IPNGのためにインターネットルーティングと割当の新しい案（ENCAPS）
RFC 2030 IPv4、IPv6、OSIに適合した簡易ネットワーク時刻プロトコル(SNTP)バージョン4
RFC 2185 ＩＰｖ６移行のルーティング面
RFC 2428 ＩＰｖ６とNATのFTP拡張
RFC 3582 ＩＰｖ６サイトマルチホームアーキテクチャの目標
|
戻る
|
記述内容について一切保障しません。リンクは自由に行ってかまいません。 Since 2002/4/30, Final update 2005/8/16 |