RFC3513 日本語訳

3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R.Hinden, S. Deering. April 2003. (Format: TXT=53920 bytes) (Obsoletes RFC2373) (Obsoleted by RFC4291) (Status: PROPOSED STANDARD)

RFC一覧
英語原文

Network Working Group                                          R. Hinden
Request for Comments: 3513                                         Nokia
Obsoletes: 2373                                               S. Deering
Category: Standards Track                                  Cisco Systems
                                                              April 2003


       Internet Protocol Version 6 (IPv6) Addressing Architecture

Status of this Memo

   このドキュメントは、インターネット社会の為のインターネット標準トラッ
   クプロトコルを規定しており、改善の為の議論と提案を求めている。この 
   プロトコルの標準化の状態と状況については、"Internet Official       
   Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配 
   布は制限されない。 

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   この規約は、IP バージョン 6 (IPv6) プロトコルのアドレス体系を定義す
   る。このドキュメントは、IPv6 アドレッシングモデル、IPv6 アドレスの 
   テキスト表現、IPv6 ユニキャストアドレスの定義、エニイキャストアドレ
   ス、マルチキャストアドレス、IPv6 ノードの必須アドレスを含む。


Table of Contents

   1. 導入
   2. IPv6 アドレッシング
      2.1 アドレッシングモデル
      2.2 アドレスのテキスト表現
      2.3 アドレスプレフィクスのテキスト表現
      2.4 アドレスタイプ識別
      2.5 ユニキャストアドレス
          2.5.1 インタフェース識別子
          2.5.2 未指定アドレス
          2.5.3 ループバックアドレス
          2.5.4 グローバルユニキャストアドレス
          2.5.5 埋め込み IPv4 アドレスを持つ IPv6 アドレス
          2.5.6 ローカル使用 IPv6 ユニキャストアドレス
      2.6 エニイキャストアドレス
          2.6.1 エニイキャストアドレス要件
      2.7 マルチキャストアドレス
          2.7.1 あらかじめ定義されたマルチキャストアドレス
      2.8 ノードに要求されるアドレス
   3. セキュリティの考慮
   4. IANA の考慮
   5. 参照
      5.1  標準の参照
      5.2  情報の参照
   付録 A: 変更版 EUI-64 形式のインタフェース ID の作成
   付録 B: RFC-2373 からの変更点
   作者のアドレス
   完全なコピーライト宣言


1. 導入

   この規約は、IP バージョン 6 (IPv6) プロトコルのアドレス体系を定義す
   る。これは、IPv6 アドレスの様々なタイプ (ユニキャスト、エニイキャス
   ト、マルチキャスト) の基本形式を含む。

   編者は、Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter,   
   Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, 
   Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony  
   Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter,    
   Bill Simpson, Sue Thomson, Markku Savela, Larry Masinter の貢献に感
   謝する。 

2. IPv6 アドレッシング

   IPv6 アドレスは、インタフェースやインタフェースの集合のための 128  
   ビット識別子である (この場合の "インタフェース" は、[IPV6] のセクショ
   ン 2 で定義されている)。以下の三つのタイプのアドレスが存在する。 

   ユニキャスト:   単一のインタフェースの識別子。ユニキュストアドレス 
                   に送信されるパケットは、そのアドレスによって識別さ 
                   れるインタフェースに配送される。 

   エニイキャスト: 一組のインタフェースの識別子 (通常、異なるノードに 
                   属する)。エニイキャストアドレスに送信されるパケット
                   は、そのアドレスによって識別されるインタフェースの 
                   一つ (ルーティングプロトコルの距離計測に従って "最 
                   も近い" もの) に配送される。 

   マルチキャスト: 一組のインタフェースの識別子 (通常、異なるノードに 
                   属する)。マルチキャストアドレスに送信されるパケット
                   は、そのアドレスによって識別されるインタフェースの 
                   全てに配送される。 

   IPv6 ではブロードキャストアドレスは存在せず、その機能はマルチキャス
   トアドレスによって代替される。

   このドキュメントでは、アドレス中のフィールドは例えば "subnet" といっ
   た特定の名前が付与される。この名前が、名前の後ろに識別子として "ID"
   という用語が付いて使用される場合 (例えば "subnet ID")、その名前のフィ
   ールドの内容を指し示す。"prefix" という用語が付いて使用される場合  
   (例えば "subnet prefix")、左からこのフィールドを含むこのフィールド 
   までのアドレス全てを指し示す。

   IPv6 では、全て 1 と全て 0 は、特に禁止していなければどのフィールド
   においても正しい値である。特に、プレフィクスは 0 値のフィールドを含
   んでもよいし、それで終わってもよい。 

2.1 アドレッシングモデル

   全てのタイプの IPv6 アドレスは、ノードではなくインタフェースに割り 
   当てられる。IPv6 ユニキャストアドレスは、単一のインタフェースを示す。
   各々のインタフェースは単一のノードに属すので、ノードのインタフェー 
   スのユニキャストアドレスはいずれも、ノードの識別子として使用してよ 
   い。 

   全てのインタフェースは、少なくとも一つのリンクローカルユニキャスト 
   アドレスを持つ必要がある (追加の必須アドレスについてはセクション 2.
   8 参照)。単一インタフェースは、如何なるタイプ (ユニキャスト、エニイ
   キャスト、マルチキャスト)、あるいはスコープの IPv6 アドレスを複数持っ
   てもよい。リンクスコープより大きいスコープを持つユニキャストアドレ 
   スは、非隣接者宛て/からの IPv6 パケットの送信元か宛先として使用され
   ないインタフェースには必要ではない。これは、時にはポイントツーポイ 
   ントインタフェースで都合がよい。このアドレッシングモデルには、一つ 
   の例外がある:

      もし実装体が、複数の物理インタフェースをインターネット層に見せる
      時に一つのインタフェースとして扱うのであれば、一つのユニキャスト
      アドレス、あるいは一組のユニキャストアドレスを複数の物理インタフェ
      ースに割り当ててもよい。これは、複数の物理インタフェース上で負荷
      分散する際に都合がよい。

   現在 IPv6 は、サブネットプレフィクスが一つのリンクに割り当てられる 
   という IPv4 モデルを引き継いでいる。複数のサブネットプレフィクスを 
   同じリンクに割り当ててもよい。 

2.2 アドレスのテキスト表現

   IPv6 アドレスをテキスト文字列で表現するのに、三つの慣例形式が存在す
   る。 

   1. 好ましい形式は x:x:x:x:x:x:x:x で、'x' はアドレスの 8 個の 16 ビッ
      ト部分の 16 進値である。

      例:

         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

         1080:0:0:0:8:800:200C:417A

      個々のフィールドの頭の 0 は書く必要が無いが、全てのフィールドに 
      は少なくとも一つの数字が存在しなければならない (2 で説明されてい
      るケースを除く)。 

   2. IPv6 アドレスのあるスタイルを割り当てる幾つかの方法のために、ア 
      ドレスが 0 ビットの長い文字列を含むことは普通であろう。0 ビット 
      を含むアドレスの記述を容易にするために、0 を圧縮する特殊な記法を
      利用することができる。

      "::" の使用は、0 の 16 ビットの一つ以上のグループを示す。"::" は
      アドレス中に一回だけ現れることができる。"::" はアドレス中の頭の、
      あるいは後の 0 を圧縮するために使用できる

      例えば、以下のアドレスは、

         1080:0:0:0:8:800:200C:417A  ユニキャストアドレス
         FF01:0:0:0:0:0:0:101        マルチキャストアドレス
         0:0:0:0:0:0:0:1             ループバックアドレス
         0:0:0:0:0:0:0:0             未指定アドレス

      は、下記のように記述してもよい。

         1080::8:800:200C:417A       ユニキャストアドレス
         FF01::101                   マルチキャストアドレス
         ::1                         ループバックアドレス
         ::                          未指定アドレス

   3. IPv4 と IPv6 ノードの混在環境を扱う時に便利な代替形式は
      x:x:x:x:x:x:d.d.d.d で、'x' はアドレスの 6 個の上位 16 ビット部 
      分の 16 進値であり、'd' はアドレスの 4 個の下位 8 ビット部分の  
      10 進値 (標準的な IPv4 表現) である。例えば、 

         0:0:0:0:0:0:13.1.68.3

         0:0:0:0:0:FFFF:129.144.52.38

      あるいは圧縮形式で、

         ::13.1.68.3

         ::FFFF:129.144.52.38

2.3 アドレスプレフィクスのテキスト表現

   IPv6 アドレスプレフィクスのテキスト表現は、IPv4 のアドレスプレフィ 
   クスが CIDR 記法 [CIDR] で記述される方法と同様である。IPv6 アドレス
   プレフィクスは、以下の記法で表現される。

      ipv6-address/prefix-length

   この場合

      ipv6-address    は、セクション 2.2 で一覧化されている記法のいず 
                      れかの IPv6 アドレスである。 

      prefix-length   は、アドレスの最も左の連続したビットの幾つがプレ
                      フィクスを構成するかを示す 10 進値である。 

   例えば、以下は 60 ビットプレフィクス 12AB00000000CD3 (16 進) の正し
   い表現である。

      12AB:0000:0000:CD30:0000:0000:0000:0000/60
      12AB::CD30:0:0:0:0/60
      12AB:0:0:CD30::/60

   以下は、上記プレフィクスの不正な表現である。

      12AB:0:0:CD3/60   は、アドレスの 16 ビットの部分の中で頭の 0 は 
                        落としてもよいが、後の 0 は落としてはならない。

      12AB::CD30/60     アドレスの "/" の左側は、
                        12AB:0000:0000:0000:0000:000:0000:CD30 に展開 
                        される。 

      12AB::CD3/60      アドレスの "/" の左側は、
                        12AB:0000:0000:0000:0000:000:0000:0CD3 に展開 
                        される。 

   ノードアドレスとそのノードアドレスのプレフィクスの両方を記述する時 
   (例えばノードのサブネットプレフィクス)、その二つは以下のように結合 
   される。

      ノードアドレス        12AB:0:0:CD30:123:4567:89AB:CDEF
      サブネット番号        12AB:0:0:CD30::/60

      は、12AB:0:0:CD30:123:4567:89AB:CDEF/60 のように省略して記述でき
      る。

2.4 アドレスタイプ識別

   IPv6 アドレスのタイプは、以下のようにアドレスの上位ビットによって識
   別される。

   アドレスタイプ       2 進数プレフィクス   IPv6 表記       セクション
   --------------       ------------------   ---------       ----------
   未指定               00...0  (128 bits)   ::/128          2.5.2
   ループバック         00...1  (128 bits)   ::1/128         2.5.3
   マルチキャスト       11111111             FF00::/8        2.7
   リンクローカル       1111111010           FE80::/10       2.5.6
   ユニキャスト
   リンクローカル       1111111011           FEC0::/10       2.5.6
   ユニキャスト
   グローバル           (その他全て)
   ユニキャスト

   エニイキャストアドレスは (あるスコープの) ユニキャストアドレス空間 
   からとられ、記法上はユニキャストと区別できない。

   グローバルユニキャストアドレスの一般的な形式は、セクション 2.5.4 で
   規定されている。(IPv4-IPv6 相互運用のための) 埋め込み IPv4 アドレス
   を含むグローバルユニキャストアドレスの特殊目的のサプタイプについて 
   は、セクション 2.5.5 で規定されている。

   将来の規定は、別の目的でグローバルユニキャストアドレス空間の一つ以 
   上のサブレンジを再定義するかもしれない。しかしそうなるまでは、実装 
   体は上記の一覧にあるどのプレフィクスからも始まらない全てのアドレス 
   を、グローバルユニキャストとして扱わなければならない。

2.5 ユニキャストアドレス

   IPv6 ユニキャストアドレスは、クラスレスドメイン間ルーティングに基づ
   く IPv4 アドレスと同様に、任意のビット長のプレフィクスで集約できる。

   IPv6 にはユニキャストアドレスの幾つかのタイプがあり、特にグローバル
   ユニキャスト、サイトローカルユニキャスト、リンクローカルユニキャス 
   トが該当する。また、グローバルユニキャストの幾つかの特殊目的サブタ 
   イプもあり、例えば埋め込み IPv4 アドレスを持つ IPv6 アドレスや、符 
   号化された NSAP アドレスが該当する。将来、追加のアドレスタイプやサ 
   ブタイプが定義されることはありえる。

   IPv6 ノードは、IPv6 アドレスの内部構造についてかなりの、あるいはわ 
   ずかの知識を持ってもよく、それはノードの果たす役割 (例えばホスト対 
   ルータ) に依存する。最小限では、ノードは (自分自身を含む) ユニキャ 
   ストアドレスは内部構造を持たないと考えてもよい。

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

   若干洗練されたホスト (しかしまだ単純) は、付加的に自分が接続されて 
   いるリンクのサブネットプレフィクスを知ってもよい。その場合、異なる 
   アドレスが異なる n の値を持ってもよい。

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | interface ID   |
   +------------------------------------------------+----------------+

   非常に単純なルータは IPv6 ユニキャストアドレスの内部構造の知識を持 
   たないが、ルータは、より一般的には、ルーティングプロトコルの処理の 
   ために一つ以上の階層的な境界の知識を持つだろう。既知の境界は、ルー 
   ティング階層でルータが保持する位置によって、ルータ毎に異なるかもし 
   れない。

2.5.1 インタフェース識別子

   IPv6 ユニキャストアドレスのインタフェース識別子は、リンク上のインタ
   フェースを識別するために使用される。それらは、サブネットプレフィク 
   ス内でユニークである必要がある。リンク上の異なるノードに同じインタ 
   フェース識別子を割り当てないことが推奨される。それらは、より広いス 
   コープでユニークであってもよい。ある場合、インタフェースの識別子は 
   リンク層アドレスから直接引き出されるかもしれない。異なるサブネット 
   に接続されるならば、単一のノードの複数のインタフェースに対して同じ 
   インタフェース識別子を使用してもよい。

   インタフェース識別子のユニークさは、IPv6 アドレスのユニークと関係が
   無いことに注意されたい。例えば、グローバルユニキャストアドレスは非 
   グローバルスコープのインタフェース識別子で作成してもよく、サイトロ 
   ーカルアドレスはグローバルスコープのインタフェース識別子で作成して 
   もよい。

   2 進値 000 から始まるものを除く全てのユニキャストアドレスは、インタ
   フェース ID が 64 ビット長で、変更版 EUI-64 形式で構成する必要があ 
   る。

   インタフェース識別子に基づく変更版 EUI-64 形式は、グローバルトーク 
   ンから引き出す場合 (例えば IEEE 802 48 ビット MAC や IEEE EUI-64 識
   別子 [EUI64])、グローバルスコープを持ってもよく、グローバルトークン
   が利用できない場合 (例えばシリアル回線やトンネルの終点など)、あるい
   はグローバルトークンが望ましくない場合 (例えばプライバシーのための 
   一時的トークン [PRIV])、ローカルスコープを持ってもよい。

   EUI-64 ベースのインタフェース識別子は、グローバルトークンが利用可能
   な場合 (例えば IEEE 48 ビット MAC) は、グローバルな適用範囲を持って
   もよく、グローバルトークンが利用不可能な場合 (例えばシリアル回線や 
   終点トンネル等) は、ローカルな適用範囲を持ってもよい。

   IEEE EUI-64 識別子からインタフェース識別子を構成する場合、変更版   
   EUI-64 形式のインタフェース識別子は、"u" ビット (IEEE EUI-64 の用語
   で汎用/ローカルビット) を反転することによって構成される。結果的に作
   成された変更版 EUI-64 形式では、"u" ビットは、グローバルスコープを 
   示すために 1 に設定され、ローカルスコープを示すために 0 に設定され 
   る。IEEE EUI-64 識別子の 2 進の最初の 3 オクテットは、以下の様に

       0       0 0       1 1       2
      |0       7 8       5 6       3|
      +----+----+----+----+----+----+
      |cccc|ccug|cccc|cccc|cccc|cccc|
      +----+----+----+----+----+----+

   インターネット標準のビット順序で記述され、"u" は汎用/ローカルビット
   であり、"g" は個別/グループビットであり、"c" は company_id のビット
   である。付録 A: "変更版 EUI-64 形式のインタフェース識別子の作成" は、
   変更版 EUI-64 形式ベースのインタフェース識別子の生成例を提供してい 
   る。

   インタフェース識別子を構成する時に "u" ビットを反転する動機は、ハー
   ドウェアトークンが利用できない時に、システム管理者が非グローバルス 
   コープの識別子を手動で設定することを容易にすることである。さもなく 
   ば、ずっと簡単な 1, 2 等の代わりに、0200:0:0:1, 0200:0:0:2 等の形式
   とすることになっただろう。

   変更版 EUI-64 形式の汎用/ローカルビットを使用することにより、グロー
   バルスコープを持つインタフェース識別子を利用できる将来の技術の開発 
   を可能にする。

   インタフェース識別子の形式の詳細は、例えば "IPv6 over Ethernet" 
   [ETHER], "IPv6 over FDDI" [FDDI] 等の適切な "IPv6 over " 規約
   で定義される。

2.5.2 未指定アドレス

   0:0:0:0:0:0:0:0 は、未指定アドレスと呼ばれる。それは、如何なるノー 
   ドにも割り当ててはならない。それは、アドレスが無いことを示す。それ 
   を使用する一つの例は、自分自身のアドレスを知る前に初期化中のホスト 
   が送信した IPv6 パケットの送信元アドレスフィールドである。

   未指定アドレスは、IPv6 パケットや IPv6 ルーティングヘッダで宛先アド
   レスとして使用してはならない。未指定の送信元アドレスを持つ IPv6 パ 
   ケットは、IPv6 ルータによって転送してはならない。

2.5.3 ループバックアドレス

   ユニキャストアドレス 0:0:0:0:0:0:0:1 は、ループバックアドレスと呼ば
   れる。それは、ノードが自分自身に IPv6 パケットを送信するために使用 
   してよい。それは、如何なる物理インタフェースにも割り当てられない。 
   それは、リンクローカルスコープを持つものとして扱われ、どこにも行か 
   ない想像上のリンクへの仮想インタフェース (一般的に "ループバックイ 
   ンタフェース" と呼ばれる) のリンクローカルユニキャストアドレスと考 
   えてもよい。

   ループバックアドレスは、単一ノードの外側に送信する IPv6 パケットの 
   送信元アドレスとして使用してはならない。ループバックの宛先アドレス 
   を持つ IPv6 パケットは、単一ノードの外側に送信してはならず、IPv6 ル
   ータは転送してはならない。ループバックの宛先アドレスを持つインタフェ
   ース上で受信したパケットは落とさなければならない。

2.5.4 グローバルユニキャストアドレス

   IPv6 グローバルユニキャストアドレスの一般的な形式は、以下の通り。

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

   global routing prefix はサイト (サブネット/リンクのクラスタ) に割り
   当てられた (一般に階層構造を持つ) 値であり、subnet ID はサイト内の 
   リンクの識別子であり、interface ID はセクション 2.5.1 で定義された 
   ものである。

   2 進値 000 から始まるもの以外の全てのグローバルユニキャストアドレス
   は、セクション 2.5.1 で規定されている形式の 64 ビットのインタフェー
   ス ID フィールド (すなわち n + m = 64) を持つ。2 進値 000 から始ま 
   るグローバルユニキャストアドレスは、インタフェース ID フィールドの 
   サイズや構造に関する制約を持たない。

   2 進値 000 から始まるグローバルユニキャストアドレスの例は、セクショ
   ン 2.5.5 で規定されている埋め込み IPv4 アドレスを持つ IPv6 アドレス
   と、[NSAP] で規定されている符号化された NSAP アドレスを含む IPv6 ア
   ドレスである。2 進値 000 以外の値から始まる (それ故に 64 ビットイン
   タフェース ID フィールドを持つ) グローバルアドレスの例は、[AGGR] に
   ある。

2.5.5 埋め込み IPv4 アドレスを持つ IPv6 アドレス

   IPv6 変換メカニズム [TRAN] は、ホストとルータが動的に IPv6 パケット
   を IPv4 ルーティング基盤上にトンネル化する技術を含む。この技術を使 
   用する IPv6 ノードは、下位 32 ビットでグローバルな IPv4 アドレスを 
   運ぶ特殊な IPv6 ユニキャストアドレスを割り当てられる。アドレスのこ 
   のタイプは、"IPv4-互換 IPv6 アドレス" と称され、以下の形式を持つ。

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|    IPv4 address     |
   +--------------------------------------+----+---------------------+

   注記: "IPv4-互換 IPv6 アドレス" で使用される IPv4 アドレスは、グロ 
   ーバルにユニークな IPv4 アドレスでなければならない。

   埋め込み IPv4 アドレスを保持する IPv6 アドレスの二番目のタイプもま 
   た定義される。アドレスのこのタイプは、"IPv4-マッピング IPv6 アドレ 
   ス" と呼ばれ、以下の形式を持つ。


   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

2.5.6 ローカル使用 IPv6 ユニキャストアドレス

   定義されたローカル使用ユニキャストアドレスには、二つのタイプが存在 
   する。これらは、リンクローカルとサイトローカルである。リンクローカ 
   ルは単一のリンクで使用するためのもので、サイトローカルは単一のサイ 
   トで使用するためのものである。リンクローカルアドレスは、以下の形式 
   を持つ。

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   リンクローカルアドレスは、例えば自動アドレス設定、隣接者検出、ルー 
   タが存在しない時などの目的で、単一のリンク上のアドレッシングで使用 
   するために設計されている。

   ルータは、リンクローカルな送信元あるいは宛先アドレスを持つパケット 
   を他のリンクに転送してはならない。

   サイトローカルアドレスは、以下の形式を持つ。

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

   サイトローカルアドレスは、グローバルなプレフィクスを持つ必要の無い 
   サイトの代わりのアドレッシングで使用するために設計されている。     
   subnet ID は 54 ビット長まで許されているが、グローバルに接続された 
   サイトはサイトローカルとグローバルプレフィクスで同じ subnet ID を使
   うことが期待される。

   ルータは、サイトローカルな送信元あるいは宛先アドレスを持つパケット 
   を他のサイトに転送してはならない。

2.6 エニイキャストアドレス

   IPv6 エニイキャストアドレスは、 (通常異なるノードに属する) 一つ以上
   のインタフェースに割り当てられるアドレスであり、エニイキャストアド 
   レスに送信されたパケットは、ルーティングプロトコルの距離計測に従っ 
   て、そのアドレスを持つ "最も近い" インタフェースに振り分けられると 
   いう特性を持つ。

   エニイキャストアドレスは、定義されたユニキャストアドレス形式のいず 
   れかを使用して、ユニキャストアドレス空間から割り当てられる。従って、
   エニイキャストアドレスは文法的にユニキャストアドレスと区別できない。
   ユニキャストアドレスが一つ以上のインタフェースに割り当てられ、その 
   ためにエニイキャストアドレスに変わる時、そのアドレスが割り当てられ 
   たノードは、それがエニイキャストアドレスであることを認識できるよう 
   明示的に設定しなければならない。

   割り当てられたエニイキャストアドレスには全て、そのエニイキャストア 
   ドレスに属する全てのインタフェースが存在するトポロジーの範囲を識別 
   する、アドレスの最長プレフィクス P が存在する。P によって識別される
   範囲内では、エニイキャストアドレスは (通常 "ホスト経路" と呼ばれる)
   ルーティングシステム中の別々のエントリとして保持しなければならない。
   P によって識別される範囲外では、エニイキャストアドレスはプレフィク 
   ス P のルーティングエントリに集約させてもよい。

   最悪のケースでは、エニイキャストセットのプレフィクス P はヌルプレフィ
   クスかもしれないことに注意されたい。すなわち、そのセットのメンバが 
   トポロジー上の場を持たないかもしれない。その場合、そのエニイキャス 
   トアドレスはインターネット全体に渡って別々のルーティングエントリと 
   して保持しなければならず、そうした "グローバルな" エニイキャストセッ
   トを幾つサポートするかについて、厳しい規模制限が存在する。従って、 
   グローバルエニイキャストセットのサポートは利用できない、あるいは非 
   常に制限されると予想される。

   エニイキャストアドレスの期待された一つの使用方法は、インターネット 
   サービスを提供している組織に属するルータの組みを識別することである。
   そのようなアドレスは、IPv6 ルーティングヘッダの中間アドレスとして使
   用でき、特定のサービス提供者あるいは一連のサービス提供者を経由して 
   パケットを配送させることができる。

   他の有り得る使用方法は、特定のサブネットに接続されたルータの組みや、
   特定のルーティングドメインへのエントリを提供しているルータの組みを 
   識別することである。

   広範囲に、任意にインターネットエニイキャストアドレスを使用する経験 
   はほとんど無く、完全に一般的にそれらを使用する場合、既知の複雑な問 
   題や障害が存在する [ANYCAST]。より多くの経験を積み、解決方法が規定 
   されるまでは、以下の制限が IPv6 エニイキャストアドレスに課せられる。

   o  エニイキャストアドレスは、IPv6 パケットの送信元アドレスとして使 
      用してはならない。

   o  エニイキャストアドレスは IPv6 ホストに割り当ててはならない。すな
      わち、IPv6 ルータにのみ割り当ててよい。

2.6.1 エニイキャストアドレス要件

   サブネットルータエニイキャストアドレスは、あらかじめ定義されている。
   その形式は下記の通り。

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | 00000000000000 |
   +------------------------------------------------+----------------+

   エニイキャストアドレス中の "subnet prefix"  は、特定のリンクを識別 
   するプレフィクスである。このエニイキャストアドレスは、文法的にイン 
   タフェース識別子を 0 に設定したリンク上のインタフェースのためのユニ
   キャストアドレスと同じである。

   サブネットルータエニイキャストアドレスに送信されるパケットは、その 
   サブネット上の一つのルータに配送されるだろう。全てのルータは、イン 
   タフェースを持つサブネットのサブネットルータエニイキャストアドレス 
   をサポートする必要がある。

   サブネットルータエニイキャストアドレスは、ノードがルータの組み一つ 
   と通信する必要のあるアプリケーションで使用されることを意図している。

2.7 マルチキャストアドレス

   IPv6 マルチキャストアドレスは、(通常は異なるノード上の) インタフェ 
   ースのグループのための識別子である。インタフェースは、如何なる数の 
   マルチキャストグループに属してもよい。マルチキャストアドレスは、以 
   下の形式を持つ。

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

         アドレスの開始部分の 2 進値 11111111 は、そのアドレスがマルチ
         キャストアドレスであることを示す。


                                       +-+-+-+-+
         flgs は 4 つのフラグの        |0|0|0|T|
         組みである                    +-+-+-+-+

            上位 3 フラグは予約されており、0 に初期化しなければならな 
            い。

            T = 0 は、インタフェース番号割り当て機関 (IANA) によって永
            久に割り当てられた ("よく知られた") マルチキャストアドレス
            を示す。

            T = 1 は、永久に割り当てられたものではない ("一時的な") マ
            ルチキャストアドレスを示す。

         scop は、マルチキャストグループのスコープを限定するために使用
         される 4 ビットのマルチキャストスコープ値である。その値は、

            0  予約
            1  インタフェースローカルスコープ
            2  リンクローカルスコープ
            3  予約
            4  管理ローカルスコープ
            5  サイトローカルスコープ
            6  (未割当て)
            7  (未割当て)
            8  組織ローカルスコープ
            9  (未割当て)
            A  (未割当て)
            B  (未割当て)
            C  (未割当て)
            D  (未割当て)
            E  グローバルスコープ
            F  予約

            インタフェースローカルスコープは、一つのノード上の単一のイ
            ンタフェースにのみ及び、マルチキャストのループバック転送で
            のみ有効である。

            リンクローカルとサイトローカルマルチキャストスコープは、対
            応するユニキャストスコープと同じトポロジ上の範囲に及ぶ。

            管理ローカルスコープは、管理上設定しなければならない、すな
            わち物理的な接続性等から自動的に導き出されない非マルチキャ
            スト関連の設定である最も狭いスコープである。

            組織ローカルスコープは、単一の組織に属している複数のサイト
            に及ぶことを意図している。

            "(未割当て)" と記述されているスコープは、管理者が追加のマ 
            ルチキャスト範囲を定義するために利用できる。

         group ID は、所定のスコープ内で、永久的か一時的かのいずれかの
         マルチキャストグループを識別する。

   永久的に割り当てられたマルチキャストアドレスの "意味" は、スコープ 
   値に依存しない。例えば、もし "NTP サーバグループ" が 101 (16進)の  
   group ID を持つ永久的なマルチキャストアドレスを割り当てられたら:

      FF01:0:0:0:0:0:0:101 は、送信者と同じインタフェース (すなわち同 
      じノード) 上の全ての NTP サーバを意味する。

      FF02:0:0:0:0:0:0:101 は、送信者と同じリンク上の全ての NTP サーバ
      を意味する。

      FF05:0:0:0:0:0:0:101 は、送信者と同じサイト上の全ての NTP サーバ
      を意味する。

      FF0E:0:0:0:0:0:0:101 は、インターネットの全ての NTP サーバを意味
      する。

   永久に割り当てられたものではないマルチキャストアドレスは、所定のス 
   コープ内でしか意味を持たない。例えばあるサイトにおいて、非永久的と 
   識別されるグループでサイトローカルなマルチキャストアドレス 
   FF15:0:0:0:0:0:0:101 は、異なるサイトで同じアドレスを使用するグルー
   プや、異なるスコープで同じ group ID を持つ非永久的なグループや、同 
   じ group ID を持つ永久的なグループとなんら関係が無い。

   マルチキャストアドレスは IPv6 パケットの送信元アドレスで使用しては 
   ならず、如何なるルーティングヘッダにも現れてはならない。

   ルータは、宛先マルチキャストアドレスの scop フィールドによって識別 
   されるスコープを超えて、マルチキャストパケットを転送してはならない。

   ノードは、scop フィールドが予約値 0 を含むマルチキャストアドレスへ 
   のパケットを生成してはならない。もしそのようなパケットを受信したら、
   黙って破棄しなければならない。ノードは、scop フィールドが予約値 F  
   を含むマルチキャストアドレスへのパケットを生成すべきではない。もし 
   そのようなパケットを送信または受信したら、グローバル (scop E) マル 
   チキャストアドレス宛てのパケットと同じように扱わなければならない。

2.7.1 あらかじめ定義されたマルチキャストアドレス

   以下の良く知られたマルチキャストアドレスが、あらかじめ定義されてい 
   る。このセクションで定義される group ID は、明示的なスコープ値で定 
   義される。

   0 と等しい T フラグを持って、他のスコープ値でこれらの group ID を使
   用することは許されていない。

      予約マルチキャストアドレス:     FF00:0:0:0:0:0:0:0
                                      FF01:0:0:0:0:0:0:0
                                      FF02:0:0:0:0:0:0:0
                                      FF03:0:0:0:0:0:0:0
                                      FF04:0:0:0:0:0:0:0
                                      FF05:0:0:0:0:0:0:0
                                      FF06:0:0:0:0:0:0:0
                                      FF07:0:0:0:0:0:0:0
                                      FF08:0:0:0:0:0:0:0
                                      FF09:0:0:0:0:0:0:0
                                      FF0A:0:0:0:0:0:0:0
                                      FF0B:0:0:0:0:0:0:0
                                      FF0C:0:0:0:0:0:0:0
                                      FF0D:0:0:0:0:0:0:0
                                      FF0E:0:0:0:0:0:0:0
                                      FF0F:0:0:0:0:0:0:0

   上記のマルチキャストアドレスは予約されており、如何なるマルチキャス 
   トグループにも割り当てるべきではない。

      全ノードアドレス:       FF01:0:0:0:0:0:0:1
                              FF02:0:0:0:0:0:0:1

   上記のマルチキャストアドレスは、スコープ 1 (インタフェースローカル)
   か 2 (リンクローカル) の範囲内で、全ての IPv6 ノードのグループを識 
   別する。

      全ルータアドレス:        FF01:0:0:0:0:0:0:2
                               FF02:0:0:0:0:0:0:2
                               FF05:0:0:0:0:0:0:2

   上記のマルチキャストアドレスは、スコープ 1 (インタフェースローカル)
   か 2 (リンクローカル) か 3 (サイトローカル) の範囲内で、全ての IPv6
   ルータのグループを識別する。

      要請ノードアドレス:      FF02:0:0:0:0:1:FFXX:XXXX

   要請ノードマルチキャストアドレスは、ノードのユニキャストとエニイキャ
   ストアドレスの機能として算出される。要請ノードマルチキャストアドレ 
   スは、(ユニキャストかエニイキャスト) アドレスの下位 24 ビットを取り、
   それらのビットをプレフィクス FF02:0:0:0:0:1:FF00::/104 に付加するこ
   とによって形成され、結果以下の範囲のアドレスとなる。

      FF02:0:0:0:0:1:FF00:0000

   〜

      FF02:0:0:0:0:1:FFFF:FFFF

   例えば、IPv6 アドレス 4037::01:800:200E:8C6C に対応する要請ノードマ
   ルチキャストアドレスは、FF02::1:FF0E:8C6C である。例えば異なる集約 
   に割り当てられた複数の上位プレフィクスのために、上位ビットのみが異 
   なる IPv6 アドレスは、同じ要請ノードアドレスにマッビングされ、それ 
   によってノードが参加しなければならないマルチキャストアドレスの数を 
   減らしている、

   ノードは、(適切なインタフェース上で) 割り当てられた全てのユニキャス
   トとエニイキャストアドレスのための、関連する要請ノードマルチキャス 
   トアドレスを算出し、参加する必要がある。

2.8 ノードに要求されるアドレス

   ホストは、以下のアドレスを自分自身を識別するアドレスとして認識する 
   必要がある。

      o  各インタフェースの必要なリンクローカルアドレス
      o  ノードのインタフェースに (手動あるいは自動で) 設定された追加 
         のユニキャストとエニイキャストアドレス
      o  ループバックアドレス
      o  セクション 2.7.1 で定義されている全ノードマルチキャストアドレ
         ス
      o  ユニキャストとエニイキャストの各々の要請ノードマルチキャスト 
         アドレス
      o  ノードが属する他の全てのグループのマルチキャストアドレス

   ルータはホストが認識する必要のあるアドレス全てに加え、以下のアドレ 
   スを自分自身を識別するアドレスとして認識する必要がある。

      o  ルータとして動作するよう設定された全てのインタフェースのサブ 
         ネットルータエニイキャストアドレス
      o  ルータに設定された他の全てのエニイキャストアドレス
      o  セクション 2.7.1 で定義されている全ルータマルチキャストアドレ
         ス

3. セキュリティの考慮

   IPv6 アドレッシングドキュメントは、インターネット基盤セキュリティに
   は直接影響しない。IPv6 パケットの認証は [AUTH] で定義されている。

4. IANA の考慮

   http://www.isi.edu/in-notes/iana/assignments/ipv6-address-space.txt
   の表と注記は、以下のように置き換えるべきである。

   インターネットプロトコルバージョン 6 アドレス空間

   IPv6 アドレス空間の初期割り当ては以下の通り。

   割当て                                プレフィクス   アドレス空間
                                         (2 進)         の部分
   -----------------------------------   --------       -------------
   未割当て (以下の注記 1 参照)          0000 0000      1/256
   未割当て                              0000 0001      1/256
   NSAP 割当てのために予約               0000 001       1/128 [RFC1888]
   未割当て                              0000 01        1/64
   未割当て                              0000 1         1/32
   未割当て                              0001           1/16
   グローバルユニキャスト                001            1/8   [RFC2374]
   未割当て                              010            1/8
   未割当て                              011            1/8
   未割当て                              100            1/8
   未割当て                              101            1/8
   未割当て                              110            1/8
   未割当て                              1110           1/16
   未割当て                              1111 0         1/32
   未割当て                              1111 10        1/64
   未割当て                              1111 110       1/128
   未割当て                              1111 1110 0    1/512
   リンクローカルユニキャストアドレス    1111 1110 10   1/1024
   サイトローカルユニキャストアドレス    1111 1110 11   1/1024
   マルチキャストアドレス                1111 1111      1/256

   注記:

   1. "未指定アドレス"、ループバックアドレス、埋め込み IPv4 アドレスを
      持つ IPv6 アドレスは、0000 0000 の 2 進プレフィクス空間から割り 
      当てられる。

   2. 今のところ、IANA は IPv6 ユニキャストアドレス空間の割り当てを、
      2 進値 001 から始まるアドレスの範囲に制限すべきである。残りのグ 
      ローバルユニキャストアドレス空間 (IPv6 アドレス空間のほぼ 85%)  
      は、将来の定義や使用のために予約され、現時点では IANA によって割
      り当てられていない。

5. 参照

5.1  標準の参照

   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9 , RFC 2026, October 1996.

5.2  情報の参照

   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
             Service", RFC 1546, November 1993.

   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
             Global Unicast Address Format", RFC 2374, July 1998.

   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
             Inter-Domain Routing (CIDR): An Address Assignment and
             Aggregation Strategy", RFC 1519, September 1993.

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", RFC 2464, December 1998.

   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority",
             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
             March 1997.

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", RFC 2467, December 1998.

   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
             Assignments", RFC 2375, July 1998.

   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.

   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
             Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
             IPv6 Packets over Token Ring Networks", RFC 2470, December
             1998.

   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 2893, August 2000.


付録 A: 変更版 EUI-64 形式のインタフェース ID の作成

   特定のリンクやノードの特性により、変更版 EUI-64 形式のインタフェー 
   ス識別子を生成するためのアプローチは数多く存在する。この付録では、 
   これらのアプローチの幾つかについて説明する。

IEEE EUI-64 識別子を持つリンクやノード

   IEEE EUI-64 識別子をインタフェース識別子に変換するのに必要な唯一の 
   変更点は、"u" (汎用/ローカル) ビットを反転することである。例えば、 
   以下の形式のグローバルにユニークな IEEE EUI-64 識別子では、

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   "c" は 割り当てられた company_id のビットであり、"0" はグローバルス
   コープを示す汎用/ローカルビットの値であり、"g" は個別/グループビッ 
   トであり、"m" は製造者選択の拡張識別子のビットである。IPv6 インタフェ
   ース識別子は以下の形式になるだろう。

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   唯一の変更は、汎用/ローカルビットの値を反転することである。


IEEE 802 48 ビット MAC を持つリンクやノード

   [EUI64] は、IEEE EUI-64 識別子を IEEE 48 ビット MAC 識別子から生成 
   するための方法を定義する。これは、0xFF と 0xFE の 16 進値を持つ二オ
   クテットを、48 ビット MAC の中間 (company_id とベンタ供給 id との  
   間) に挿入することである。例えば、以下のグローバルスコープの 48 ビッ
   ト IEEE MAC では、

   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+

   "c" は 割り当てられた company_id のビットであり、"0" はグローバルス
   コープを示す汎用/ローカルビットの値であり、"g" は個別/グループビッ 
   トであり、"m" は製造者選択の拡張識別子のビットである。インタフェー 
   ス識別子は以下の形式になるだろう。

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   IEEE 802 48ビット MAC アドレスが (インタフェースかノード上で) 利用 
   可能である場合、それらは有効性やとユニークさの特性を持つので、実装 
   体はインタフェース識別子を生成するためにそれらを使用してもよい。


他の種類の識別子を持つリンク

   IEEE EIU-64 や IEEE 802 48 ビット MAC 以外のリンク層インタフェース 
   識別子を持つ数多くのタイプのリンクが存在する。例は、LocalTalk と   
   Arcnet を含む。変更版 EUI-64 形式の識別子を生成する方法は、リンク識
   別子 (例えば LocalTalk 8 ビットノード識別子) を取って、左側に 0 を 
   埋めることである。例えば、16 進値 0x4F の LocalTalk 8 ビットノード 
   識別子は、結果として以下のインタフェース識別子になる。

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

   これは、ローカルスコープを示すために汎用/ローカルビットを "0" に設 
   定した結果であることに注意されたい。

識別子の無いリンク

   組み込み識別子のタイプを持たない数多くのリンクが存在する。これらの 
   最も一般的なものは、シリアル回線と設定されたトンネルである。インタ 
   フェース識別子は、サブネットプレフィクスの中でユニークであるよう選 
   択しなければならない。

   組み込み識別子がリンク上で利用できない場合、好ましいアプローチは、 
   別のインタフェースかノード自身に割り当てられたものからグローバルな 
   インタフェース識別子を使用することである。このアプローチを使用する 
   場合、同じノードを同じサブネットプレフィクスに接続する他のインタフェ
   ースは、同じインタフェースを使用してはならない。

   もしリンク上で使用できるグローバルなインタフェース識別子が存在しな 
   いならば、実装体はローカルスコープのインタフェース識別子を生成する 
   必要がある。唯一の要件は、サブネットプレフィクスの中でユニークであ 
   ることである。サブネットプレフィクスでユニークなインタフェース識別 
   子を選択するための可能なアプローチは数多く存在する。これらは以下を 
   含む。

      手動設定
      ノードシリアル番号
      他のノード特定トークン

   サブネットプレフィクスでユニークなインタフェースは、ノードの再起動 
   後やノードにインタフェースを追加したり削除した場合に変更されない方 
   法で生成すべきである。

   適切なアルゴリズムの選択は、リンクや実装に依存する。インタフェース 
   識別子を形成する詳細は、適切な "<リンク>上の IPv6" 規約で定義される。
   自動アルゴリズムの一部として、衝突検出アルゴリズムを実装することが 
   強く推奨される。

付録 B: RFC-2373 からの変更点

   以下の変更点は、RFC-2373 "IP バージョン 6 アドレス体系" からの変更 
   点である。

   -  0 の 16 ビットの一つ以上のグループを表すために "::" を許す、セク
      ション 2.2 のテキストを明確化した。
   -  インタフェース識別子のユニークさの要件を、リンク上でユニークから
      サブネットプレフィクスの中でユニークに変更した。さらに、同じイン
      タフェース識別子をリンク上の異なるマシンに割り当てないことの推奨
      を追加した。
   -  サイトローカル形式を変更し、subnet ID フィールドを 54 ビット長に
      し、38 ビットの 0 のフィールドを削除した。
   -  マルチキャスト scop 値の説明と、予約された scop 値 0 を扱うため 
      の規則を追加した。
   -  セクション 2.4 と 2.5.6 を改訂し、異なるアドレスタイプの識別方法
      を明確化した。これは、実装体がグローバルユニキャスト形式のプレフィ
      クスに関する知識を組み込まないことを保証するために行われた。変更
      は以下を含む。
         o  形式プレフィクス (FP: Format Prefix) という用語を削除した。
         o  アドレスタイプの一覧を改訂し、グローバルユニキャストと他の
            全てをグローバルユニキャストと識別する単一のエントリの例外
            を含むのみとした。
         o  定義されたプレフィクス例外の一覧をセクション 2.5.6 から削 
            除した。これは現在セクション 2.4 の主要部分のため。
   -  EUI-64 識別子に関するテキストを明確化し、IPv6 の "変更版 EUI-64 
      形式" 識別子と IEEE EUI-64 識別子とを区別した。
   -  グローバルユニキャストアドレスと NSAP アドレスのセクションをグロ
      ーバルユニキャストアドレスのセクションに統合し、グローバルユニキャ
      スト形式を汎用化して、例として [AGGR] と [NSAP] を引用した。
   -  セクション 2.5.4 と 2.5.5 の順序を変えた。
   -  セクション 2.7.2 新しい IPv6 マルチキャストアドレスの割当てを削 
      除した。他の場所で再定義されているため。
   -  IANA IPv6 アドレス割り当てを更新し、NSAP と AGGR 割り当てをドキュ
      メント化した IANA 考慮のセクションを追加した。
   -  "IPv4 互換の IPv6 アドレス" は、グローバルな IPv4 ユニキャストア
      ドレスを使わなければならないという説明を追加した。
   -  参照を標準と非標準のセクションに分割した。
   -  セクション 2.5.1 で [PRIV] への参照を追加した。
   -  ルータは、マルチキャストパケットをマルチキャストアドレスで示され
      たスコープの外側に転送してはならないという説明を追加した。
   -  ルータは、未指定アドレスの送信元アドレスを持つパケットを転送して
      はならないという説明を追加した。
   -  ルータは、ループバックの宛先アドレスを持つインタフェースで受信し
      たパケットを破棄しなければならないという説明を追加した。
   -  IPv4 マッピングアドレスの定義を明確化した。
   -  テキスト表現の付録の ABNF 規定を削除した。
   -  IPX アドレスのために予約されたアドレスプロックを削除した。
   -  マルチキャストスコープを以下のように変更した。
         o  スコープ値 1 の名称を "ノードローカル" から "インタフェー 
            スローカル" に変更した。
         o  スコープ値 4 を "管理ローカル" と定義した。
   -  RFC1933 への参照を修正し、参照を更新した。
   -  明確化のために数多くの小さい変更を施し、テキストをより一貫性を高
      めた。

作者のアドレス

   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: +1 650 625-2004
   EMail: hinden@iprg.nokia.com


   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone: +1 408 527-8213
   EMail: deering@cisco.com

完全なコピーライト宣言

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   (このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、
   上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生 
   作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説 
   明したり、実装を援助するといった派生作業を準備、コピー、出版、配布 
   してもよい。しかし、このドキュメント自身は、インターネット標準プロ 
   セスで定義された手続きに従わなければならず、インターネット標準を開 
   発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合 
   を除いて、コピーライト記述やインターネット社会、他のインターネット 
   組織への参照等を、如何なる方法でも修正してはならない。

   上記で認められた制限された許可は永久的であり、インターネット社会や 
   継承者や割当て者によって無効にされることはないだろう。)

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

謝辞

   RFC 編集者の務めに対する資金は、インターネット社会によって提供され 
   ている。

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Revisions

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る