RFC 4727 ＩＰｖ４とＩＰｖ６とＩＣＭＰｖ４とＩＣＭＰｖ６とＵＤＰとＴＣＰヘッダの実験的な値

この文書はRFC 4727の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group B. Fenner
Request for Comments: 4727 AT&T Labs - Research
Category: Standards Track November 2006

Experimental Values
in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers
ＩＰｖ４とＩＰｖ６とＩＣＭＰｖ４とＩＣＭＰｖ６と
ＵＤＰとＴＣＰヘッダの実験的な値

Status of This Memo
この文書の状態

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化工程のプロ
トコルを指定し、そして改良のために議論と提案を求めます。標準化状態と
このプロトコルの状態については、「インターネット公式プロトコル標準」
（ＳＴＤ１）の最新版を参照してください。このメモの配布は無制限です。

Abstract
概要

When experimenting with or extending protocols, it is often necessary
to use some sort of protocol number or constant in order to actually
test or experiment with the new function, even when testing in a
closed environment. This document reserves some ranges of numbers
for experimentation purposes in specific protocols where the need to
support experimentation has been identified, and it describes the
numbers that have already been reserved by other documents.
プロトコルの実験や拡張するとき、閉じられた環境で試験する場合でも、新
しい機能をで実際に試験するか実験する時に、ある種のプロトコル番号ある
いは定数を使うことはしばしば必要です。この文書は実験のサポートが必要
が判断された特定のプロトコルで実験目的である範囲の番号の予約をします、
そしてこの文書はすでに他の文書によって予約された番号を記述します。

1. Introduction
1. はじめに

[RFC3692] recommends assigning option numbers for experiments and
testing. This document documents several such assignments for the
number spaces whose IANA considerations are documented in [RFC2780].
This document generally follows the form of [RFC2780].
[RFC3692]が実験や試験のためのオプション番号を割り当てることを勧めます。
この文書は[RFC2780]のＩＡＮＡの考慮で文書化される番号空間のためにいく
つかのこのような割当を文書化します。この文書は一般に[RFC2780]形式に従
います。

When using these values, carefully consider the advice in Sections 1
and 1.1 of [RFC3692]. It is not appropriate to simply select one of
these values and hard code it into a system.
これらの値を使うとき[RFC3692]の１章と１.１章の助言を慎重に考慮してくだ
さい。これらの値の１つを選択して、システムの中にハードコード化すること
は適当ではありません。

Note: while [RFC3692] says that it may not be necessary to allocate
values for UDP and TCP ports, Sections 6 and 7.1 explicitly reserve
ports for this purpose to avoid any possible conflict.
注意：[RFC3692]はＵＤＰとＴＣＰポートに値を割り当てることが必要ではな
いかもしれないと言いますが、６章と７.１章は明示的に衝突可能性を避ける
ために、この目的のポートを確保します。

2. Fields in the IPv4 Header
2. ＩＰｖ４ヘッダのフィールド

The IPv4 header [RFC0791] contains the following fields that carry
values assigned by the IANA: Version, Type of Service, Protocol,
Source Address, Destination Address, and Option Type.
ＩＰｖ４ヘッダ[RFC0791]はＩＡＮＡによって値を割り当てられた次のフィー
ルドを含んでいます：版数、サービス種別、プロトコル、ソースアドレス、
宛先アドレス、オプション種別。

2.1. IP Version Field in the IPv4 Header
2.1. ＩＰｖ４ヘッダのＩＰ版数フィールド

The Version field in IPv4 packets is always 4.
ＩＰｖ４パケットの版数フィールドは常に４です。

2.2. IPv4 Type of Service Field
2.2. ＩＰｖ４サービス種別フィールド

[RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to
either '0' or '1') as Experimental/Local Use, so no additional code
points should be needed. The Explicit Congestion Notification (ECN)
field [RFC3168] has no free code points to assign.
[RFC2474]が実験/ローカル使用としてプール２（すべてのxxxx11のコードポ
イント、xは0か1です）を定義します、追加のコードポイントが必要とされる
べきではありません。明示的混雑通知（ＥＣＮ）フィールド[RFC3168]は自由
に割り当てれるコードポイントを持っていません。

2.3. IPv4 Protocol Field
2.3. ＩＰｖ４プロトコルフィールド

[RFC3692] allocates two experimental code points (253 and 254) for
the IPv4 Protocol field.
[RFC3692]がＩＰｖ４プロトコルフィールドに２つの実験的なコードポイント
（２５３と２５４）を割り当てます。

2.4. IPv4 Source and Destination Addresses
2.4. ＩＰｖ４ソースと宛先アドレス

2.4.1. IPv4 Unicast
2.4.1. ＩＰｖ４ユニキャスト

No experimental IPv4 addresses are defined. For certain experiments,
the address ranges set aside for Private Internets in [RFC1918] may
be useful. It is not appropriate to use other special-purpose IPv4
addresses [RFC3330] for experimentation.
実験的なＩＰｖ４アドレスが定義されません。ある特定の実験のために、
[RFC1918]でプライベートインターネットのために設定したアドレス範囲が
有用であるかもしれません。実験のために他の特別な目的のＩＰｖ４アドレ
ス[RFC3330]を使うことは適当ではありません。

At the time of this writing, some Internet Registries have policies
allowing experimental assignments from number spaces that they
control. Depending on the experiment, the registry, and their
policy, this may be an appropriate path to pursue.
この執筆の時点で、あるインターネット登記所は彼らがコントロールする番
号空間から実験的な割当を許すポリシーを持ちます。実験と登録と彼らのポ
リシーによって、これは追求するべき適切な進路であるかもしれません。

2.4.2. IPv4 Multicast
2.4.2. ＩＰｖ４マルチキャスト

The globally routable group 224.0.1.20 is set aside for
experimentation. For certain experiments, the administratively
scoped multicast groups defined in [RFC2365] may be useful. This
document assigns a single link-local scoped group, 224.0.0.254, and a
single scope-relative group, 254.
世界的規模でルーチングできるグループ224.0.1.20は実験のためです。ある
特定の実験のために、[RFC2365]で定義された管理範囲のマルチキャストグルー
プは有用であるかもしれません。この文書は１つのリンクローカル範囲グ
ループ224.0.0.254と、１つの範囲相対的なグループ254を割り当てます。

2.5. IPv4 Option Type Field
2.5. ＩＰｖ４オプションタイプフィールド

This document assigns a single option number, with all defined values
of the "copy" and "class" fields, resulting in four distinct option
type codes. See Section 8 for the assigned values.
この文書は、定義された「複製」と「クラス」フィールドを持ち、結果的に
４つ異なるオプションタイプコードをもたらす、１つのオプション番号を割
り当てます。割り当てられた値は８章を見てください。

3. Fields in the IPv6 Header
3. ＩＰｖ６ヘッダのフィールド

The IPv6 header [RFC2460] contains the following fields that carry
values assigned from IANA-managed name spaces: Version, Traffic
Class, Next Header, Source and Destination Address. In addition, the
IPv6 Hop-by-Hop Options and Destination Options extension headers
include an Option Type field with values assigned from an IANA-
managed name space. The IPv6 Routing Header contains a Type field
for which there is not currently an explicit IANA assignment policy.
ＩＰｖ６ヘッダ[RFC2460]はＩＡＮＡによって管理された名前空間から割り当
てられた値を運ぶ次のフィールドを含んでいます：版数、トラフィッククラ
ス、次のヘッダ、ソースと宛先アドレス。加えて、ＩＰｖ６ホップ毎オプショ
ンと宛先オプション拡張ヘッダはＩＡＮＡによって管理された名前空間から割
り当てられた値のオプション種別フィールドを含みます。ＩＰｖ６ルーティン
グヘッダは現在明示的なＩＡＮＡ割り当てポリシのない種別フィールドを含ん
でいます。

3.1. IP Version Field in the IPv6 Header
3.1. ＩＰｖ６ヘッダのＩＰ版数フィールド

The Version field in IPv6 packets is always 6.
ＩＰｖ６パケットの版数フィールドは常に６です。

3.2. IPv6 Traffic Class Field
3.2. ＩＰｖ６トラフィッククラスフィールド

[RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to
either '0' or '1') as Experimental/Local Use, so no additional code
points should be needed. The ECN field [RFC3168] has no free code
points to assign.
[RFC2474]が実験/ローカル使用としてプール２（すべてのxxxx11のコードポ
イント、xは0か1です）を定義します、追加のコードポイントが必要とされる
べきではありません。明示的混雑通知（ＥＣＮ）フィールド[RFC3168]は自由
に割り当てれるコードポイントを持っていません。

3.3. IPv6 Next Header Field
3.3. ＩＰｖ６の次のヘッダフィールド

[RFC3692] allocates two experimental code points (253 and 254) for
the IPv6 Next Header field.
[RFC3692]がＩＰｖ６の次のヘッダフィールドに２つの実験的なコードポイン
ト（２５３と２５４）を割り当てます。

3.4. IPv6 Source and Destination Addresses
3.4. ＩＰｖ６ソースと宛先アドレス

3.4.1. IPv6 Unicast Addresses
3.4.1. ＩＰｖ６ユニキャストアドレス

[RFC2928] defines a set of IPv6 addresses for testing and
experimental usage:
[RFC2928]が試験と実験的な使用のためのＩＰｖ６アドレスを定義します：

The block of Sub-TLA IDs assigned to the IANA (i.e.,
2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and
experimental usage to support activities such as the 6bone, and
for new approaches like exchanges.
ＩＡＮＡに割り当てられた副ＴＬＡ識別子のブロック（すなわち、
2001:0000::/29 - 2001:01F8::/29)は６ｂｏｎｅや交換の様な新しい方
法のような試験と実験的な使用のため割り当てられます。

However, at this writing, there are no RFC3692-style experimental
IPv6 addresses assigned. [HUSTON05] creates an IANA registry that
may in the future contain such assignments. For certain experiments,
Unique Local Addresses [RFC4193] may be useful. It is not
appropriate to use addresses in the documentation prefix [RFC3849]
for experimentation.
しかしながら、この執筆時点で、割り当てられたRFC3692形式の実験的なＩ
Ｐｖ６アドレスがありません。[HUSTON05]は将来このような割当を含むかも
しれないＩＡＮＡ登記所を作ります。ある特定の実験のために、一意なロー
カルアドレス[RFC4193]は有用であるかもしれません。実験のために文書化
プレフィックスのアドレス[RFC3849]を使うことは適当ではありません。

At the time of this writing, some Internet Registries have policies
allowing experimental assignments from number spaces that they
control. Depending on the experiment, the registry, and their
policy, this may be an appropriate path to pursue.
この執筆の時点で、あるインターネット登記所が彼らがコントロールする番
号空間から実験的な割当を許すポリシを持ちます。実験と登録と彼らのポリ
シに依存して、これは追求するべき適切な道であるかもしれません。

3.4.2. IPv6 Multicast Addresses
3.4.2. ＩＰｖ６マルチキャストアドレス

The group FF0X::114 is set aside for experimentation at all scope
levels. Smaller scopes may be particularly useful for
experimentation, since they are defined not to leak out of a given
defined boundary, which can be set to be the boundary of the
experiment. For certain experiments, other multicast addresses with
the T (non-permanently-assigned or "transient" address) bit [RFC4291]
set may be useful.
グループFF0X::114はすべての範囲レベルで実験のために設定されます。より
小さい範囲はそれらが実験の境界線とされた境界線から漏れないように定義さ
れるとき、特に実験に有用かもしれません。ある特定の実験で、Ｔビット（永
久割り当て、「一時的」アドレス）[RFC4291]を設定した他のマルチキャスト
アドレスが有用であるかもしれません。

3.5. IPv6 Hop-by-Hop and Destination Option Fields
3.5. ＩＰｖ６ホップ毎と宛先オプションフィールド

This document assigns a single option type, with all possible values
of the "act" and "chg" fields, resulting in eight distinct option
type codes. See Section 8 for the assigned values.
この文書は１つのオプション種別を割当て、"act"と"chg"フィールドの割当
の結果、８つの異なるオプション種別コードをもたらします。割り当てられ
た値は８章を見てください。

3.6. IPv6 Routing Header Routing Type
3.6. ＩＰｖ６ルーティングヘッダルーティング種別

This document assigns two values for the Routing Type field in the
IPv6 Routing Header, 253 and 254.
この文書はＩＰｖ６ルーティングヘッダのルーティング種別フィールドに、
２５３と２５４の２つの値を割り当てます。

4. Fields in the IPv4 ICMP Header
4. ＩＰｖ４ ＩＣＭＰヘッダのフィールド

This document assigns two ICMPv4 type numbers, 253 and 254. ICMPv4
code values are allocated per type, so it's not feasible to assign
experimental values in this document.
この文書は２つのＩＣＭＰｖ４種別番号２５３と２５４を割り当てます。
ＩＣＭＰｖ４コード値が種別毎に割り当てられるので、この文書で実験的
な値を割り当てることは可能ではありません。

5. Fields in the IPv6 ICMP Header
5. ＩＰｖ６ ＩＣＭＰヘッダのフィールド

[RFC4443] includes experimental ICMPv6 type values for Informational
(200, 201) and Error (100, 101) message types. ICMPv6 code values
are allocated per type, so it's not feasible to assign experimental
values in this document.
[RFC4443]は実験的なＩＣＭＰｖ６種別値として、情報（２００、２０１）
とエラー（１００、１０１）メッセージ種別を含めます。ＩＣＭＰｖ６コー
ド値がタイプ毎に割り当てられるので、この文書で実験的な値を割り当てる
ことは可能ではありません。

5.1. IPv6 Neighbor Discovery Fields
5.1. ＩＰｖ６近隣探索フィールド

The IPv6 Neighbor Discovery header [RFC2461] contains the following
fields that carry values assigned from IANA-managed name spaces:
Type, Code, and Option Type.
ＩＰｖ６近隣探索ヘッダ[RFC2461]はＩＡＮＡによって管理された名前空間か
ら割り当てられた値を運ぶ次のフィールドを含んでいます：種別とコードと
オプション種別。

5.1.1. IPv6 Neighbor Discovery Type
5.1.1. ＩＰｖ６近隣探索種別

The Neighbor Discovery Type field is the same as the ICMPv6 Type
field. See Section 5 for those code points.
近隣探索種別フィールドはＩＣＭＰｖ６種別フィールドと同じです。それら
のコードポイントは５章を見てください。

5.1.2. IPv6 Neighbor Discovery Code
5.1.2. ＩＰｖ６近隣探索コード

The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no
experimental code points are necessary.
ＩＣＭＰｖ６コードフィールドはＩＰｖ６近隣探索で使われません、それで
実験的なコードポイントが必要ではありません。

5.1.3. IPv6 Neighbor Discovery Option Type
5.1.3. ＩＰｖ６近隣探索オプション種別

This document assigns two IPv6 Neighbor Discovery Option Types, 253
and 254.
この文書は、２つのＩＰｖ６近隣探索オプション種別２５３と２５４を割り
当てます。

6. Fields in the UDP Header
6. ＵＤＰヘッダのフィールド

Two system ports, 1021 and 1022, have been reserved for
experimentation for UDP and TCP.
２つのシステムポート、１０２１と１０２２が、実験のためにＵＤＰとＴＣ
Ｐで確保されました。

7. Fields in the TCP Header
7. ＴＣＰヘッダのフィールド

7.1. TCP Source and Destination Port Fields
7.1. ＴＣＰソースと宛先ポートフィールド

7.2. Reserved Bits in TCP Header
7.2. ＴＣＰヘッダの予約ビット

There are not enough reserved bits to allocate any for
experimentation.
実験のために割り当てるのに十分な予約ビットがありません。

7.3. TCP Option Kind Field
7.3. ＴＣＰオプション種別フィールド

Two TCP options, 253 and 254, have been reserved for experimentation
with TCP Options.
２つのＴＣＰオプション、２５３と２５４、がＴＣＰオプションでの実験の
ために確保されました。

8. IANA Considerations
8. ＩＡＮＡの考慮

The new assignments are summarized below.
新しい割当は下に要約されます。

IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local
Network Control Block section) (Section 2.4.2)
ＩＰｖ４マルチキャストアドレス（マルチキャストアドレス(224.0.0/24)
ローカルネットワーク制御ブロックセクション）（セクション２.４.２章）

Group Address Name
------------- ----------------------------
224.0.0.254 RFC3692-style Experiment (*)

IPv4 Multicast Addresses (multicast-addresses relative addresses
section) (Section 2.4.2)
ＩＰｖ４マルチキャストアドレス（マルチキャストアドレス相対的
アドレスセクション）（２.４.２章）

Relative Description
-------- ----------------------------
254 RFC3692-style Experiment (*)

IPv4 Option Numbers (ip-parameters initial section) (Section 2.5)
ＩＰｖ４オプション番号（ＩＰパラメータ開始セクション）（２.５章）

Copy Class Number Value
---- ----- ------ -----
0 0 30 30
0 2 30 94
1 0 30 158
1 2 30 222

IPv6 Option Types (ipv6-parameters Section 5.b.) (Section 3.5)
ＩＰｖ６オプションタイプ（ＩＰｖ６パラメータセクション5.b）（３.５章）

HEX act chg rest
---- --- --- -----
0x1e 00 0 11110
0x3e 00 1 11110
0x5e 01 0 11110
0x7e 01 1 11110
0x9e 10 0 11110
0xbe 10 1 11110
0xde 11 0 11110
0xfe 11 1 11110

IPv6 Neighbor Discovery Option Formats (icmpv6-parameters)
(Section 5.1.3)
ＩＰｖ６近隣探索オプションフォーマット（icmpv6パラメータ）
（５.１.３章）

Type Description
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)

IPv6 Routing Header Routing Types (ipv6-parameters Section 5.c.)
(Section 3.6)
ＩＰｖ６ルーティングヘッダルーティング種別（ＩＰｖ６パラメータ
セクション5.c） （３.６章）

Type Description
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)

ICMPv4 Type Numbers (icmp-parameters) (Section 4)
ＩＣＭＰｖ４種別番号（icmpパラメータ）（４章）

Type Name
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)

System Port Numbers (port-numbers) (Sections 6 and 7.1)
システムポート番号（ポート番号）（６章と７.１章）

Keyword Decimal Description
------- -------- ------------------------------
exp1 1021/udp RFC3692-style Experiment 1 (*)
exp1 1021/tcp RFC3692-style Experiment 1 (*)
exp2 1022/udp RFC3692-style Experiment 2 (*)
exp2 1022/tcp RFC3692-style Experiment 2 (*)

TCP Option Numbers (tcp-parameters) (Section 7.3)
ＴＣＰオプション番号（tcpパラメータ）（７.３章）

Kind Length Meaning
---- ------ ------------------------------
253 N RFC3692-style Experiment 1 (*)
254 N RFC3692-style Experiment 2 (*)

Each of these registrations is accompanied by the following footnote:
これらの登録のそれぞれが次の脚注を伴います：

(*) It is only appropriate to use these values in explicitly-
configured experiments; they MUST NOT be shipped as defaults in
implementations. See RFC 3692 for details.
(*) 明示的に設定された実験でこれらの値を使うことだけが適切なだけで
す；これらは実装でデフォルトとして出荷されてはなりません。詳細に
ついてはＲＦＣ３６９２を見てください。

9. Security Considerations
9. セキュリティの考察

Production networks do not necessarily support the use of
experimental code points in IP headers. The network scope of support
for experimental values should carefully be evaluated before
deploying any experiment across extended network domains, such as the
public Internet. The potential to disrupt the stable operation of
the network hosting the experiment through the use of unsupported
experimental code points is a serious consideration when planning an
experiment using such code points.
商用ネットワークがＩＰヘッダの実験的なコードポイントの使用を必ずしも
サポートする必要がありません。公共インターネットのような、広範囲のネッ
トワークドメインを超えて実験を動かす前に、ネットワーク範囲での実験的
な値に対するサポートのは慎重に評価されるべきです。このようなコードポ
イントを使った実験を計画するとき、サポートされていない実験的なコード
ポイントの使用により、実験を主催しているネットワークの安定したオペレー
ションを混乱させる可能性は重大な考慮事項です。

Security analyzers such as firewalls and network intrusion detection
monitors often rely on unambiguous interpretations of the fields
described in this memo. As new values for the fields are assigned,
existing security analyzers that do not understand the new values may
fail, resulting in either loss of connectivity, if the analyzer
declines to forward the unrecognized traffic, or in loss of security
if it does forward the traffic and the new values are used as part of
an attack. Assigning known values for experiments can allow such
analyzers to take a known action for explicitly experimental traffic.
ファイアウォールとネットワーク侵入検出モニタのようなセキュリティーア
ナライザがしばしばこのメモで記述されたフィールドの明確な解釈に依存し
ます。フィールドのための新しい値が割り当てられるとき、、新しい価値を
理解しない既存のセキュリティーアナライザは、もしアナライザが認識でき
ないトラフィックやセキュリティの損失のあるを転送を断わるなら接続性を
失い、もしそれがトラフィックを転送するなら新しい値が攻撃の一部として
使用され接続性のいずれかの敗北をもたらして、失敗するかもしれません。
実験のために周知の値を割り当てることは、このようなアナライザが実験的
なトラフィックに対し明示的に周知の動きをとることを許すことができます。

Because the experimental IPv4 options defined in Section 2.5 are not
included in the IPsec AH [RFC4302] calculations, it is not possible
for one to authenticate their use. Experimenters ought to keep this
in mind when designing their experiments. Users of the experimental
IPv6 options defined in Section 3.5 can choose whether or not the
option is included in the AH calculations by choosing the value of
the "chg" field.
２.５章で定義された実験的なＩＰｖ４オプションはＩＰｓｅｃ ＡＨ
[RFC4302]計算に含められないから、それらの使用を認証することはできま
せん。それらの実験を設計するとき、実験者がこれを念頭におくべきです。
３.５章で定義された実験的なＩＰｖ６オプションのユーザは、「chg」フィー
ルドの値を選択することによって、オプションがＡＨ計算に含められるかど
うか決めることができます。

When experimental code points are deployed within an administratively
self-contained network domain, the network administrators should
ensure that each code point is used consistently to avoid
interference between experiments. When experimental code points are
used in traffic that crosses multiple administrative domains, the
experimenters should assume that there is a risk that the same code
points will be used simultaneously by other experiments and thus that
there is a possibility that the experiments will interfere.
Particular attention should be given to security threats that such
interference might create.
実験的なコードポイントが管理的に独立なネットワークドメインの間で設定
されるとき、ネットワーク管理者はそれぞれのコードポイントが整合性をもっ
て実験間で干渉を避けて使えることを保証するべきです。実験的なコードポ
イントが多数の管理ドメインを横切るトラフィックで使われるとき、実験者
は同じコードポイントが同時に他の実験によって使われて、実験が邪魔され
る可能性の危険性を想定するべきです。このような干渉が作るかもしれない
セキュリティ脅威に特別な注意をすべきです。

10. References
10. 参考文献

10.1. Normative References
10.1. 参照する参考文献

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.

[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.

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

[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.

[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial
IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.

[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.

[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.

10.2. Informative References
10.2. 益な参考文献

[HUSTON05] Huston, G., "Administration of the IANA Special Purpose
Address Block", Work in Progress, December 2005.

Author's Address
著者のアドレス

Bill Fenner
AT&T Labs - Research
75 Willow Rd
Menlo Park, CA 94025
USA

Phone: +1 650 330-7893
EMail: fenner@research.att.com

Full Copyright Statement
完全著作権表示

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とＩＥＴＦ信託とインターネット技術標準化タスクフォースは、明確にも暗
黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
の利用に適当である事の保障を含め、全ての保証を拒否します。

Intellectual Property
知的所有権

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。

Acknowledgement
謝辞

Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So