RFC2374-JP.txt 2000/09/27 (initial version)
(C)JPNIC RFC-JP project, 2000. All rights reserved.
Network Working Group R. Hinden
Request for Comments: 2374 Nokia
Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
IPv6の集約可能グローバルユニキャストアドレス形式
1.0 導入
本文書では、インターネット上で使用される集約可能なIPv6グローバルユニ
キャストアドレス形式を定義する。本文書で定義されているアドレス形式は、
IPv6プロトコル[IPV6]および「IPv6 Addressing Architecture（IPv6アドレ
スアーキテクチャ）」[ARCH]と整合性が保たれている。このアドレス形式を
利用することで、インターネットにおいてスケーラブルな経路制御を行える
ようになるだろう。
本文書は、RFC2073「An IPv6 Provider-Based Unicast Address Format
（プロバイダ型IPv6ユニキャストアドレス形式）」を置き換えるものである。
RFC2073は歴史的（historic）RFCとなる。集約可能グローバルユニキャスト
アドレス形式は、RFC2073で定義されている形式をさまざまな点から改良し
ている。主な変更点は、
o レジストリビットの除去（経路集約には必要ないため）
o EUI-64に基づいたインターフェイス識別子のサポート
o プロバイダ型およびIX（Internet eXchange）型集約のサポート
o 外部トポロジーとサイト内部トポロジーの分割
o 集約に関する新たな用語群の利用
である。
本文書中の「MUST（しなければならない）」「MUST NOT（してはならない）」
「REQUIRED（要求される）」「SHALL（すべきである）」「SHALL NOT（すべ
きでない）」「SHOULD（したほうがよい）」「SHOULD NOT（しないほうがよ
い）」「RECOMMENDED（推奨される）」「MAY（してもよい）」「OPTIONAL
（選択できる）」というキーワード群は、RFC2119での記述のとおりに解釈
される。
Hinden, et. al. Standards Track [Page 1]
RFC 2374 IPv6 Global Unicast Address Format July 1998
2.0 IPv6アドレスの概要
IPv6アドレスは、インターフェイスおよびインターフェイス群に対応する
128ビットの識別子である。IPv6アドレスには、
o ユニキャスト
o エニーキャスト
o マルチキャスト
の3種類がある。本文書では、ユニキャストアドレスのなかの特別な形式を
定義している。
本文書では、アドレス中のフィールドには特定の名称が付けられている（例：
「サブネット（subnet）」）。この名称の後ろに「ID（識別子）」を付けて
使用する場合（例：「subnet ID」）は、名称が指すフィールドの内容に言
及している。一方、この名称に「プリフィックス（prefix）」を付けて使用
する場合（例：「サブネット・プリフィックス（subnet prefix）」）には、
そのフィールドを含めた左側全体のアドレスビットについて言及している。
IPv6ユニキャストアドレスは以下の仮定のもとで設計されている。
o インターネットの経路制御システムは、任意のビット境界での「最長プ
リフィックス合致（longest prefix match）」アルゴリズムに基づいて
転送先を決定する。
o インターネットの経路制御システムは、IPv6アドレスの内部構造に関す
る知識を持たない。
IPv6アドレスは、アドレス割り当ておよびアドレス配置のための構造が存在
する。唯一の例外としては、ユニキャストアドレスとマルチキャストアドレ
スが区別されているということだけである。
IPv6アドレスの型は、アドレスの上位ビット列で区別される。これらのビッ
ト群を含んだ可変長フィールドは、「形式プリフィックス（FP：Format
Prefix）」と呼ばれる。
本文書では、「形式プリフィックス“001”（2進数）」のアドレス形式を定
義している。この形式プリフィックスは、集約可能グローバルユニキャスト
アドレスに利用される。IPv6ユニキャストアドレスに利用される形式プリフィッ
クスならば、同じアドレス形式をその形式プリフィックスに利用することも
できる。本文書では、形式プリフィックス“001”のみが定義される。
3.0 IPv6の集約可能グローバルユニキャストアドレス形式
本文書では、IPv6の集約可能グローバルユニキャストアドレス割り当て用の
アドレス形式を定義している。インターネットに接続されるIPv6ノードでは、
本アドレス形式が広く利用されると考えている。本アドレス形式は、現行の、
集約をプロバイダごとに行う手法と、新しいIXごとに集約する手法の双方を
サポートしている。これらのふたつの方式を組み合わせることで、プロバイ
ダに直接接続しているサイトおよびIXに接続しているサイトの両方で効率的
な経路集約ができる。サイトはどちらのタイプの集約エンティティに接続す
るかを選択することになるだろう。
Hinden, et. al. Standards Track [Page 2]
RFC 2374 IPv6 Global Unicast Address Format July 1998
本アドレス形式は現行のプロバイダ型集約に加えて、IX型集約をサポートし
ている。しかし、全体的な経路集約を行う手段としてIXに依存しておらず、
プロバイダ型集約だけを利用しても効率的な経路集約が可能である。
集約可能アドレスは以下の3階層構成になっている。
- パブリックトポロジー
- サイトトポロジー
- インターフェイス識別子
パブリックトポロジーは、公共的なインターネット配送サービスを提供する
プロバイダおよびIXの集合である。サイトトポロジーは、サイト外のノード
へは配送サービスを提供しない組織および特定のサイトのみを指す。インター
フェイス識別子はリンク上にあるインターフェイスを識別する。
______________ ______________
--+/ \+--------------+/ \+----------
( P1 ) +----+ ( P3 ) +----+
+\______________/ | |----+\______________/+--| |--
| +--| X1 | +| X2 |
| ______________ / | |-+ ______________ / | |--
+/ \+ +-+--+ \ / \+ +----+
( P2 ) / \ +( P4 )
--+\______________/ / \ \______________/
| / \ | |
| / | | |
| / | | |
_|_ _/_ _|_ _|_ _|_
/ \ / \ / \ / \ / \
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
\___/ \___/ \___/ \___/ \___/
| / \
_|_ _/_ \ ___
/ \ / \ +-/ \
( S.D ) ( S.E ) ( S.F )
\___/ \___/ \___/
上の図を見てわかるように、集約可能なアドレス形式は、長距離プロバイダ
（P1、P2、P3、P4）、IX（X1、X2）、さまざまな階層に位置するプロバイダ
（P5、P6）、利用者（S.AからS.F）をサポートするように設計されている。
IXは（現行のNAP、FIXなどとは異なり）IPv6アドレスを割り当てる。これら
のIXに接続する組織は、ひとつ以上の長距離プロバイダからの長距離サービ
スにも（直接的に、もしくはIXを通じて間接的に）登録することになる。
Hinden, et. al. Standards Track [Page 3]
RFC 2374 IPv6 Global Unicast Address Format July 1998
その際、該当組織は長距離配送プロバイダとは別のアドレスを利用する。長
距離プロバイダを変更する場合にも組織のアドレスを変更する必要はない。
またIXを通してひとつ以上の長距離プロバイダに複数接続する場合にも、各
長距離プロバイダからアドレスプリフィックスを取得する必要はない。（注：
本文書では、このようなプロバイダ選択や移動で利用される機構については
論じていない。）
3.1 集約可能グローバルユニキャストアドレス構造
集約可能グローバルユニキャストアドレス形式は以下のとおりである。
| 3| 13 | 8 | 24 | 16 | 64ビット |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | インターフェイスID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
<-パブリックトポロジー-> サイト
<-------->
トポロジー
<----インターフェイス識別子----->
FP 形式プリフィックス（001）
TLA ID 最上位レベル集約識別子（TLA）
RES 将来の使用のため予約済
NLA ID 次レベル集約識別子（NLA）
SLA ID サイトレベル集約識別子（SLA）
INTERFACE ID インターフェイス識別子
以下の章では、IPv6の集約可能グローバルユニキャストアドレス形式の各部
分について詳細に記述している。
3.2 最上位レベル集約ID
最上位レベル集約識別子（TLA ID）は経路制御における階層の最上位に位置
する。デフォルト経路の設定されていないルータでは、すべての有効なTLA
IDに対するエントリが経路表内になければならない(MUST)。それに加えて、
おそらく、当該ルータが位置するTLA ID用の経路制御情報を提供するエント
リもなければならないだろう。当該ルータが存在するトポロジーへの経路制
御を最適化するためにも別のエントリが必要な場合がある(MAY)。しかし、
どのレベルの経路制御トポロジーについても、デフォルトが設定されていな
い経路表に対する追加エントリ数を極小化するように設計しなければならな
い(MUST)。
Hinden, et. al. Standards Track [Page 4]
RFC 2374 IPv6 Global Unicast Address Format July 1998
このアドレス形式は8,192（2^13）個のTLA IDをサポートしている。下位の
予約済フィールドまでTLAフィールドを拡大したり、追加の形式プリフィッ
クスにこの形式を利用することで、TLA IDをさらに追加できる。
TLA ID割り当てに関する論点は本文書の範囲外である。これらの問題につい
ては準備中の文書で記述される予定である。
3.3 予約済フィールド
予約済フィールドは将来の使用のために予約されており、ゼロ（0）に設定
しなければならない(MUST)。
予約済フィールドを利用することで、将来の必要に応じてTLAフィールドや
NLAフィールドを適切に拡大できる。これに関する議論については4.0章を参
照のこと。
3.4 次レベル集約識別子
次レベル集約識別子（NLA ID）は、TLA IDを割り当てられている組織におい
て、下部のアドレス階層の作成やサイトの識別のために利用される。組織の
ネットワークに合ったアドレス階層を作成するために、NLA IDの最上位部分
を割り当てることができる。NLA IDフィールドの残りのビットは、その組織
内のサイトの識別に利用できる。NLA IDフィールドは以下のようになってい
る。
| n | 24-nビット | 16 | 64ビット |
+-----+--------------------+--------+--------------------+
|NLA1 | サイトID | SLA ID | インターフェイスID |
+-----+--------------------+--------+--------------------+
TLA IDを割り当てられている各組織は24ビットのNLA ID空間を取得する。各
組織は、NLA ID空間を利用することで、現在のIPv4インターネットで提供で
きるすべてのネットワークとほぼ同じ数の組織にサービスを提供できる。
TLA IDを割り当てられている組織は、サイトID空間内でNLA IDをサポートす
ることもできる(MAY)。これによって、TLA IDを割り当てられている組織は、
パブリック配送サービスを提供する組織にもパブリック配送サービスを提供
しない組織にもサービスを提供できる。また、NLA IDを割り当てられている
組織がサイトID空間を利用して別のNLA IDをサポートしてもよい(MAY)。こ
の場合のNLA IDフィールドは以下のようになる。
Hinden, et. al. Standards Track [Page 5]
RFC 2374 IPv6 Global Unicast Address Format July 1998
| n | 24-nビット | 16 | 64ビット |
+-----+--------------------+--------+--------------------+
|NLA1 | サイトID | SLA ID | インターフェイスID |
+-----+--------------------+--------+--------------------+
| m | 24-n-m | 16 | 64ビット |
+-----+--------------+--------+--------------------+
|NLA2 | サイトID | SLA ID | インターフェイスID |
+-----+--------------+--------+--------------------+
| o |24-n-m-o| 16 | 64ビット |
+-----+--------+--------+--------------------+
|NLA3 |サイトID| SLA ID | インターフェイスID |
+-----+--------+--------+--------------------+
TLA ID内のNLA ID空間のビット配置は、そのTLA IDに対して責任を負う組織
が設計する。同様に、次レベルNLA IDのビット配置は、直前レベルのNLA ID
が設計することになる。NLAアドレス空間を割り当てる組織は、RFC2050にお
ける方法と同じ「スロースタート」割り当てを行うことが推奨されている
(RECOMMENDED)。
NLA ID割り当て計画の設計には、経路集約の効率と自由度の間のトレードオ
フがある。NLA ID割り当てを階層化すると集約度が上がりより小さな経路表
を生成できる。一方、無階層な割り当てでは、配置や連結の自由度が上がる
が経路表の大きさが肥大化してしまう。
3.5 サイトレベル集約識別子
サイトレベル集約識別子（SLA ID）フィールドは、個々の組織において自組
織内のアドレス階層を作り、サブネットを識別するために利用される。これ
は、各組織がずっと多くのサブネットを持つことを除いては、IPv4における
サブネットに類似している。16ビットのSLA IDフィールドは65,535個のサブ
ネットをサポートしている。
各組織は自組織のSLA IDの配置方法を以下のふたつから選択できる(MAY)。
- 「無階層（flat）」に配置する（例：SLA ID間の論理関係を作らない）
（大きな経路表が生成される）
- 2レベル以上の階層化を行う
（より小さな経路表が生成される）
後者の場合は以下のようになる。
Hinden, et. al. Standards Track [Page 6]
RFC 2374 IPv6 Global Unicast Address Format July 1998
| n | 16-n | 64ビット |
+-----+---------------+----------------------------------+
|SLA1 | サブネット | インターフェイスID |
+-----+---------------+----------------------------------+
| m | 16-n-m | 64ビット |
+----+----------+----------------------------------+
|SLA2|サブネット| インターフェイスID |
+----+----------+----------------------------------+
SLA IDフィールドの構造は、それぞれの組織が決定する。
このアドレス形式でサポートされるサブネットの数は、（最大級の組織を除
いた）大部分の組織に対して必要十分な数にすべきである。サブネットを追
加しなければならない場合には、その組織にインターネットサービスを提供
している組織と交渉して、サイト識別子を追加してもらう。
3.6 インターフェイスID
インターフェイス識別子（ID）は、リンク上のインターフェイスを一意に識
別するために利用される。インターフェイス識別子はリンク上で一意である
ことが要求される(REQUIRED)。スコープを越えた範囲で一意であってもよい
(MAY)。多くの場合、インターフェイス識別子は当該インターフェイスのリ
ンク層アドレス自体、もしくはそのアドレスから演繹される値が用いられる。
集約可能グローバルユニキャストアドレス形式で利用されるインターフェイ
スIDはIEEE EUI-64形式[EUI-64]の64ビット長の値である(REQUIRED)。この
値は、グローバルトークン（例：IEEE 48ビットMAC）が利用できる場合はグ
ローバルスコープとなり、グローバルトークンが利用できない場所（例：シ
リアルリンク、トンネルの終端など）ではローカルスコープとなる。グロー
バルスコープおよびローカルスコープの識別に利用されるEUI-64識別子の
“u”ビット（IEEE EUI-64用語で、ユニバーサル/ローカルビット）は、
[ARCH]で定義されているように正確に設定されなければならない(MUST)。
EUI-64に基づくインターフェイス識別子を生成する手続きは[ARCH]で定義さ
れている。インターフェイス識別子生成についての詳細は、「IPv6 over
Ethernet（Ethernet上のIPv6）」[ETHER]、「IPv6 over FDDI（FDDI上の
IPv6）」[FDDI]などの適当な「<リンク>上のIPv6」仕様で定義されている。
4.0 技術的動機
集約可能なアドレス形式のフィールドの大きさを決定するにあたって、さま
ざまな技術的な要求を検討する必要があった。それらについて説明する。
Hinden, et. al. Standards Track [Page 7]
RFC 2374 IPv6 Global Unicast Address Format July 1998
最上位レベル集約識別子（TLA ID）の大きさは13ビットであり、8,192個の
TLA IDを利用できる。この大きさは、現在の経路制御技術から考えて、イン
ターネットの最上位レベルに位置するルータにおいて、十分な余裕を持って
デフォルト経路が設定されていない経路表を維持できるように決定されてい
る。デフォルトが設定されていないルータは、TLAへの内部経路やTLA間の経
路を最適化するために非常に多くの比較的長い（例：特別なネットワークの）
プリフィックスを搬送することもあるので、この余裕は重要である。
重要なのは、デフォルト経路が設定されていない経路表の大きさだけではな
い。トポロジーの複雑さも重要な論点である。ルータは、転送テーブルの計
算中に、デフォルトが設定されていない経路の複製を検査しなければならな
い。この複製の数は、トポロジーの複雑度によって決定される。IPv4におけ
る今までの経験では、単一のプレフィクスがしばしば15もの異なった経路を
経由して告知されている。
インターネットトポロジーの複雑さは将来まちがいなく増大するだろう。
IPv6のデフォルト経路がない経路制御においては、さらなる複雑さと、相当
大規模になるインターネットをサポートすることが重要である。
比較のために記しておくと、本文書執筆時（1998年春）には、IPv4における
デフォルト経路の設定されていない経路表は約5万のプリフィックスを含ん
でいる。この現状から経路を8,192以上サポートすることが可能であること
がわかるが、その一方で、「現在IPv4で扱われているプリフィックス数は、
すでに現在の経路制御技術には多すぎるのではないか」ということが議論の
争点となっている。経路の安定性に関する議論や、すべての最上位レベルプ
リフィックスをサポートするわけではないプロバイダに関する議論もある。
技術的要求は、IPv4で利用されている大きさより小さいTLA ID空間の大きさ
を、十分な余裕を持った値に設定することである。
TLAフィールド用に13ビットを選択したのは設計上の折衷案である。これ以
下のビット数では、十分な数の最上位レベル組織をサポートできないので小
さすぎるし、これ以上のビット数では、本文書でこれまで論じてきたような
論点を扱うために、現在の経路制御技術で十分な余裕を持って扱えるビット
数を越えてしまう。
将来、経路制御技術が、デフォルトの設定されていない経路表でより多くの
最上位レベル経路をサポートできるまでに発展した場合に、TLA識別子の数
を増やす方法はふたつある。第1の方法は、TLA IDフィールドを予約済フィー
ルドまで拡大することである。これによりTLA IDの数は約200万個に増加す
る。第2の方法は、このアドレス形式で利用できる別の形式プリフィックス
（FP）を割り当てることである。これらの方法のどちらか、もしくはその結
合したものを利用すれば、TLA IDの数を大幅に増加させることができる。
予約フィールドの大きさは8ビットである。この大きさが選ばれたのは、TLA
IDフィールドとNLA IDフィールドの双方もしくはどちらかを十分に拡大でき
るからである。
次レベル集約識別子（NLA ID）フィールドの大きさは24ビットである。
Hinden, et. al. Standards Track [Page 8]
RFC 2374 IPv6 Global Unicast Address Format July 1998
これにより、階層を作らない流儀で利用された場合には、約1,600万個のNLA
IDが割り当て可能である。階層化した場合、（平均的なネットワークサイズ
を254インターフェイスと仮定した場合）IPv4アドレス空間とほぼ同じ複雑
さを扱える。将来NLA IDにおいてさらに複雑さを扱う余地が必要となった場
合、NLA IDを予約済フィールドまで拡大することで対処できる。
サイトレベル集約識別子（SLA ID）フィールドの大きさは16ビットである。
これは、サイトごとに65,535個のサブネットをサポートする。このフィール
ドの大きさに関する設計の目的は、最大級の組織を除くすべてに十分である
ことだった。追加のサブネットが必要な組織は、自組織にインターネットサー
ビスを提供している組織と打ち合わせて追加のサイト識別子を取得し、これ
を利用して追加のサブネットを作ることが可能である。
サイトを特定するプリフィックスの長さはすべて同じ長さ（例：48ビット）
とされるため、サイトレベル集約識別子フィールドは固定長となった。これ
によって、トポロジー中のサイトの移動が容易になる（例：サービスプロバ
イダの変更や複数のサービスプロバイダへの複数接続）。
インターフェイスID（インターフェイス識別子）フィールドは64ビットであ
る。この大きさは、EUI-64に基づくインターフェイス識別子をサポートする
ためにRFC2373中で定義された要求に見合うように選択された。
5.0 謝辞
本文書に関する批評および建設的な助言をいただいた以下の諸氏に感謝の意
を表明する。
Thomas Narten、Bob Flink、Matt Crawford、Allison Mankin、Jim Bound、
Christian Huitema、Scott Bradner、Brian Carpenter、John Stewart、
Daniel Karrenberg
6.0 参考資料
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management（IPv6
アドレス割り当て管理）",
RFC 1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture（IPv6
アドレス体系）",
RFC 2373, July 1998.
[AUTH] Atkinson, R., "IP Authentication Header（IP認証ヘッダ）",
RFC 1826, August 1995.
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
Autoconfiguration（IPv6ステートレスアドレス自動設定）",
RFC 1971, August 1996.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks（Ethernetネットワーク上でのIPv6パケットの伝送）",
規格制定中
Hinden, et. al. Standards Track [Page 9]
RFC 2374 IPv6 Global Unicast Address Format July 1998
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier（EUI-64）
Registration Authority（64ビットグローバル識別子（EUI-64）
用のガイドライン）",
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks（FDDI上でのIPv6パケットの伝送）", 規格制定中
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
（IPv6）Specification（インターネットプロトコル第6版（IPv6）
仕様）", RFC 1883, December 1995.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
and J. Postel, "Internet Registry IP Allocation Guidelines
（インターネットレジストリIP割り当てに関するガイドライン）",
BCP 12, RFC 1466, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels（要求レベルを表す際にRFCにおいて利用され
るキーワード）", BCP 14, RFC 2119, March 1997.
7.0 セキュリティに関する考察
IPv6のアドレスに関する文書は、インターネット通信基盤のセキュリティ
に直接影響しない。
IPv6パケットの認証はRFC1826で定義されている。
Hinden, et. al. Standards Track [Page 10]
RFC 2374 IPv6 Global Unicast Address Format July 1998
8.0 執筆者の連絡先
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: 1 408 990-2004
EMail: hinden@iprg.nokia.com
Mike O'Dell
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22030
USA
Phone: 1 703 206-5890
EMail: mo@uunet.uu.net
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
Hinden, et. al. Standards Track [Page 11]
RFC 2374 IPv6 Global Unicast Address Format July 1998
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
完全な著作権表示（抄訳――正確な理解には本文を参照すること）
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。また、この文
書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示
およびこの節を付加していれば、全体あるいは一部であってもいっさいの制
約を課されることなく作成、複製、発表、配布できる。ただし、この文書自
体に対して、著作権表示やインターネット・ソサエティ、もしくは他のイン
ターネット関連団体への参照を取り除くなどの変更を加えてはならない。イ
ンターネット標準化過程で定義されている著作権のための手続きに従って、
インターネット標準を開発するために必要な場合や、RFCを英語以外の言語
に翻訳する必要がある場合はその限りではない。
上記の制限は永続的なものであり、インターネット・ソサエティもしくはそ
の継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は（無保証（AS IS））で提供され、インター
ネット・ソサエティおよびIETFはすべての保証を明示的にも暗黙的にも行わ
ない。そのなかには、この情報がいかなる権利も侵害していないという保証
や、商用利用および特定目的における適合性への保証が含まれる。
Hinden, et. al. Standards Track [Page 12]
RFC-JP日本語翻訳物の著作権に関する告知
本文書は、インターネット技術の正しい普及と振興を目的として、社団法人
日本ネットワークインフォメーションセンター(JPNIC)が行っているRFC翻訳
プロジェクト(RFC-JP)の成果物である。rfc-copyright-storyに従い、
RFC2220以降のものについては“Full Copyright Statement”を含め、
RFC2219以前のものについては原著者の了解を得て翻訳している。これによ
り作成された二次的著作物である本文書の著作権はJPNICが保持するが、こ
の権利の設定は原文から新たな翻訳を作成し公開することを妨げるものでは
ない。
また、RFC-JPとしてこの文書に記載された情報の内容が正確であることに努
めているが、正確性を含めいっさいの品質についてこれを保証するものでは
ない。したがって、この文書に記載された情報に基づいて貴方あるいは貴組
織がとられた行動によって引き起こされる結果に対して、JPNICは何ら保証
を与えない。
本文書は、本著作権表示を含めて改変しないことを条件に再配布を許可する。
ただし日本語訳は固定ではなく、誤りの発見や正確性の向上のために必要に
応じて適宜更新される可能性がある。常に最新の版を入手するようにしてい
ただきたい。最新版は<URL:http://rfc-jp.nic.ad.jp/>から入手できる。
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
