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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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.
で実験やプロトコルを拡張する場合、閉鎖された環境でテストするときにも、新しい機能を実際にテストするためか、実験でプロトコル番号または定数のいくつかの並べ替えを使用する必要があることが多いです。この文書では、実験をサポートする必要性が確認されている特定のプロトコルでの実験のために、番号の一部範囲を確保し、それがすでに他の文書によって予約されている数字を示しています。
[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]の実験とテストのためにオプション番号を割り当てることをお勧めします。このドキュメントの文書IANAの考察[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.
これらの値を使用する場合は、慎重にセクション1と[RFC3692]の1.1にアドバイスを検討します。単にシステムにそれをこれらの値のいずれかを選択し、ハードコードすることは適切ではありません。
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]は、UDPとTCPポートの値を割り当てることが必要ではないかもしれないと言いながら、セクション6および7.1には、明示的にすべての可能な競合を避けるために、この目的のためにポートを予約。
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.
バージョン、サービスの種類、プロトコル、送信元アドレス、宛先アドレス、およびオプションタイプ：IPv4ヘッダ[RFC0791]はIANAによって割り当てられた値を運ぶ以下の分野を含んでいます。
The Version field in IPv4 packets is always 4.
IPv4パケットのVersionフィールドは常に4です。
[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]はプール2（すべてのコードポイントxxxx11、「X」は「0」または「1」のいずれかを意味する）は、追加コードポイントが必要とされるべきではない、実験/ローカル使用のように。定義します明示的輻輳通知（ECN）フィールド[RFC3168]は割り当てる空きコードポイントを持っていません。
[RFC3692] allocates two experimental code points (253 and 254) for the IPv4 Protocol field.
[RFC3692]はIPv4のプロトコルフィールドの2つの実験コードポイント（253,254）を割り当てます。
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.
実験的なIPv4アドレスは定義されていません。特定の実験のために、[RFC1918]でプライベートなインターネットのために確保されたアドレスの範囲が有用である可能性があります。実験のために、他の特別な目的のIPv4アドレス[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.
この記事の執筆時点では、いくつかのインターネットレジストリは、それらが制御する数のスペースから実験的な割り当てを許可するポリシーを持っています。実験、レジストリ、およびそのポリシーに応じて、これは追求するための適切なパスかもしれません。
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を割り当てます。
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.
この文書では、4つの別個のオプション・タイプ・コードで、その結果、すべての定義された「コピー」の値と「クラス」フィールドで、1つのオプション番号を割り当てます。割り当てられた値については、セクション8を参照してください。
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.
バージョン、トラフィッククラス、次のヘッダ、送信元と送信先のアドレス：IPv6ヘッダ[RFC2460]はIANAが管理する名前空間から割り当てられた値を運ぶ以下のフィールドが含まれています。また、IPv6のホップバイホップオプションと宛先オプション拡張ヘッダは、IANAが管理するネームスペースから割り当てられた値を持つオプションタイプフィールドを含みます。 IPv6ルーティングヘッダは、現在、明示的なIANAの割り当てポリシーがされていないタイプのフィールドが含まれています。
The Version field in IPv6 packets is always 6.
IPv6パケットのVersionフィールドは常に6です。
[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]はプール2（すべてのコードポイントxxxx11、「X」は「0」または「1」のいずれかを意味する）は、追加コードポイントが必要とされるべきではない、実験/ローカル使用のように。定義しますECNフィールド[RFC3168]は割り当てる空きコードポイントを持っていません。
[RFC3692] allocates two experimental code points (253 and 254) for the IPv6 Next Header field.
[RFC3692]はIPv6の次ヘッダフィールドの2つの実験コードポイント（253,254）を割り当てます。
[RFC2928] defines a set of IPv6 addresses for testing and experimental usage:
[RFC2928]は、テストと実験の使用のためのIPv6アドレスの集合を定義します。
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.
IANAに割り当てられたサブTLA IDのブロック（すなわち、2001：0000 :: / 29から2001：01F8 :: / 29）試験など6boneのような活動をサポートするために実験的使用のため、および新しいアプローチのための割り当てのためのものです取引所のような。
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スタイル実験的なIPv6アドレスはありません。 【HUSTON05】今後、このような割り当てを含んでいてもよいIANAレジストリを作成します。特定の実験のために、ユニークローカルアドレス[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.
この記事の執筆時点では、いくつかのインターネットレジストリは、それらが制御する数のスペースから実験的な割り当てを許可するポリシーを持っています。実験、レジストリ、およびそのポリシーに応じて、これは追求するための適切なパスかもしれません。
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は、全てのスコープレベルでの実験のために確保されています。それらは実験の境界とすることができる所定の定義された境界の外に漏れないように定義されているので、より小さな範囲は、実験のために特に有用であり得ます。特定の実験のために、T（非永続的に割り当てられた又は「一過性」アドレス）ビット[RFC4291]が設定された他のマルチキャストアドレスが有用であり得ます。
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.
この文書は、8つの異なるオプションの種別コードをもたらす、「行為」と「CHG」フィールドのすべての可能な値と、1つのオプションタイプを割り当てます。割り当てられた値については、セクション8を参照してください。
This document assigns two values for the Routing Type field in the IPv6 Routing Header, 253 and 254.
この文書は、IPv6ルーティングヘッダ、253及び254にルーティングタイプフィールドの2つの値を割り当てます。
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.
この文書では、2つのICMPv4のタイプ番号を割り当て、253と254 ICMPv4のコード値は、タイプごとに割り当てられたので、それは、この文書で実験値を代入することは実現可能ではありませんされています。
[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]は、実験のICMPv6タイプの情報（200、201）の値とエラー（100、101）メッセージタイプとを含みます。 ICMPv6のコード値は、タイプごとに割り当てられているので、この文書で実験値を代入することは実現可能ではありません。
The IPv6 Neighbor Discovery header [RFC2461] contains the following fields that carry values assigned from IANA-managed name spaces: Type, Code, and Option Type.
タイプ、コード、およびオプションタイプ：IPv6近隣探索ヘッダ[RFC2461]はIANAが管理する名前空間から割り当てられた値を運ぶ次のフィールドを含んでいます。
The Neighbor Discovery Type field is the same as the ICMPv6 Type field. See Section 5 for those code points.
近隣探索Typeフィールドは、ICMPv6のTypeフィールドと同じです。これらのコードポイントについては、セクション5を参照してください。
The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no experimental code points are necessary.
ICMPv6のコードフィールドは、IPv6近隣探索に使用されていないので、何の実験コードポイントは必要ありません。
This document assigns two IPv6 Neighbor Discovery Option Types, 253 and 254.
この文書では、2つのIPv6近隣探索オプションの種類、253および254を割り当てます。
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
2つのシステムポート、1021と1022は、UDPおよびTCPのための実験のために予約されています。
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
2つのシステムポート、1021と1022は、UDPおよびTCPのための実験のために予約されています。
There are not enough reserved bits to allocate any for experimentation.
実験用のいずれかを割り当てる十分な予約ビットはありません。
Two TCP options, 253 and 254, have been reserved for experimentation with TCP Options.
2つのTCPオプション、253および254は、TCPオプションでの実験のために予約されています。
The new assignments are summarized below.
新しい割り当ては以下に要約されています。
IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local Network Control Block section) (Section 2.4.2)
IPv4マルチキャストアドレス（マルチキャストアドレス（224.0.0 / 24）ローカルネットワーク制御ブロック部）（2.4.2項）
Group Address Name
------------- ----------------------------
224.0.0.254 RFC3692-style Experiment (*)
IPv4 Multicast Addresses (multicast-addresses relative addresses section) (Section 2.4.2)
IPv4マルチキャストアドレス（マルチキャストアドレスの相対アドレス部）（2.4.2項）
Relative Description
-------- ----------------------------
254 RFC3692-style Experiment (*)
IPv4 Option Numbers (ip-parameters initial section) (Section 2.5)
IPv4のオプション番号（IPパラメータ初期区間）（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)
IPv6のオプションの種類（IPv6のパラメータのセクション5.b.）（3.5節）
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)
IPv6の近隣探索オプションフォーマット（ICMPv6のパラメータ）（5.1.3項）
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)
IPv6ルーティングヘッダルーティングタイプ（IPv6のパラメータセクション5.c.）（3.6節）
Type Description
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)
ICMPv4 Type Numbers (icmp-parameters) (Section 4)
ICMPv4のタイプ番号（ICMPパラメータ）（第4節）
Type Name
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)
System Port Numbers (port-numbers) (Sections 6 and 7.1)
システムポート番号（ポート番号）（セクション6および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オプション番号（TCP-パラメータ）（7.3節）
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.
（*）明示的に構成された実験では、これらの値を使用するだけで適切です。彼らは、実装でデフォルトとして出荷されてはなりません。詳細については、RFC 3692を参照してください。
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.
生産ネットワークは、必ずしもIPヘッダにおける実験コードポイントの使用をサポートしていません。実験値のための支援のネットワーク範囲は慎重にパブリックインターネットなどの拡張ネットワークドメイン、全体でどんな実験を展開する前に評価されるべきです。このようなコード・ポイントを使用して実験を計画する際に、サポートされていない実験的なコードポイントを使用して実験をホスティングしているネットワークの安定した動作を妨害する可能性が真剣に検討されます。
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.
セクション2.5で定義された実験的なIPv4オプションは、IPsecのAH [RFC4302]の計算には含まれていないので1がその使用を認証することは不可能です。実験者は、彼らの実験を設計するときは、この点に注意しておくべきです。 3.5節で定義された実験的なIPv6オプションのユーザーは、「CHG」フィールドの値を選択することで、オプションはAHの計算に含まれているかどうかを選択できます。
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.
実験的なコードポイントが管理自己完結型のネットワーク・ドメイン内に配置されている場合、ネットワーク管理者は、各コードポイントは実験間の干渉を回避するために一貫して使用されていることを確認すべきです。実験的なコードポイントが複数の管理ドメインを横断するトラフィックに使用される場合、実験者は、同じコードポイントが実験を妨害する可能性があることが他の実験によって同時に使用されるリスクがあると仮定すべきです。特に注意がこのような干渉を作成することがありますセキュリティ上の脅威に与えられるべきです。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[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.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]ブラドナー、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月。
[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.
[RFC2928] HindenとR.、デアリング、S.、フィンク、R.、およびT.ハイン、 "初期のIPv6サブTLA IDの割り当て"、RFC 2928、2000年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]ヒューストン、G.、主よ、A.、およびP.スミス、 "ドキュメンテーションのためのIPv6アドレスプレフィックス予約"、RFC 3849、2004年7月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[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.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[HUSTON05] Huston, G., "Administration of the IANA Special Purpose Address Block", Work in Progress, December 2005.
[HUSTON05]ヒューストン、G.、「IANA特別目的アドレスブロックの管理」、進歩、2005年12月に作業。
Author's Address
著者のアドレス
Bill Fenner AT&T Labs - Research 75 Willow Rd Menlo Park, CA 94025 USA
ビルフェナーAT＆T研究所 - 研究75ウィローRdのメンロパーク、CA 94025 USA
Phone: +1 650 330-7893 EMail: fenner@research.att.com
電話：+1 650 330-7893 Eメール：fenner@research.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。