RFC4727 日本語訳
4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCPHeaders. B. Fenner. November 2006. (Format: TXT=19745 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Fenner Request for Comments: 4727 AT&T Labs - Research Category: Standards Track November 2006
コメントを求めるワーキンググループB.フェナーの要求をネットワークでつないでください: 4727のAT&T研究室--カテゴリについて研究してください: 標準化過程2006年11月
Experimental Values
in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers
IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
プロトコルを実験するか、または広げるとき、それは、閉じている環境でテストさえするとき、実際に新しい機能をテストするか、または実験するためにある種のプロトコル番号を使用するのにしばしば必要であるか、または一定です。 このドキュメントは実験をサポートする必要性が特定されて、それが他のドキュメントによって既に予約された数について説明する特定のプロトコルの実験目的のためのいくつかの範囲の数を予約します。
Fenner Standards Track [Page 1] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[1ページ]。
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]は、実験のオプション番号を割り当てて、テストすることを勧めます。 このドキュメントは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.
これらの値を使用するときには、慎重に[RFC3692]のセクション1と1.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は、どんな可能な闘争も避けるために明らかにこのためにポートを予約します。
2. Fields in the IPv4 Header
2. IPv4ヘッダーの分野
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によって割り当てられた値を運ぶ以下の分野を含んでいます: バージョン、サービス、プロトコル、ソースアドレス、送付先アドレス、およびオプションのタイプはタイプします。
2.1. IP Version Field in the IPv4 Header
2.1. IPv4ヘッダーのIPバージョン分野
The Version field in IPv4 packets is always 4.
いつもIPv4パケットのバージョン分野は4です。
2.2. IPv4 Type of Service Field
2.2. サービス分野のIPv4タイプ
[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]がPool2(すべてのコードが'x'が'0'か'1'について言及するxxxx11を指します)をExperimental/地方のUseと定義するので、どんな追加コード・ポイントも必要とするべきではありません。 Explicit Congestion Notification(電子証券取引ネットワーク)分野[RFC3168]には、割り当てるどんな無料のコード・ポイントもありません。
2.3. IPv4 Protocol Field
2.3. IPv4プロトコル分野
[RFC3692] allocates two experimental code points (253 and 254) for the IPv4 Protocol field.
[RFC3692]は2つの実験コード・ポイント(253と254)をIPv4プロトコル分野に割り当てます。
2.4. IPv4 Source and Destination Addresses
2.4. IPv4ソースと送付先アドレス
2.4.1. IPv4 Unicast
2.4.1. IPv4ユニキャスト
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]の兵士のInternetsに設定するアドレスは役に立つかもしれません。 実験に、他の専用IPv4アドレス[RFC3330]を使用するのは適切ではありません。
Fenner Standards Track [Page 2] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[2ページ]。
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.
この書くこと時点で、いくつかのインターネットRegistriesには、それらが制御する数の空間から実験的な課題を許容する方針があります。 実験、登録、およびそれらの方針によって、これは追求するのが適切である経路であるかもしれません。
2.4.2. IPv4 Multicast
2.4.2. IPv4マルチキャスト
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、およびaシングルに範囲親類グループ、254を配属します。
2.5. IPv4 Option Type Field
2.5. IPv4オプションタイプ分野
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つの異なったオプションタイプコードをもたらして。 割り当てられた値に関してセクション8を見てください。
3. Fields in the IPv6 Header
3. IPv6ヘッダーの分野
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 Hop OptionsとDestination Options拡張ヘッダーは値がIANAの管理された名前スペースから割り当てられているOption Type分野を入れます。 IPv6ルート設定Headerは現在でないときに、明白なIANA課題方針があるType分野を含んでいます。
3.1. IP Version Field in the IPv6 Header
3.1. IPv6ヘッダーのIPバージョン分野
The Version field in IPv6 packets is always 6.
いつもIPv6パケットのバージョン分野は6です。
3.2. IPv6 Traffic Class Field
3.2. IPv6トラフィック類体
[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]がPool2(すべてのコードが'x'が'0'か'1'について言及するxxxx11を指します)をExperimental/地方のUseと定義するので、どんな追加コード・ポイントも必要とするべきではありません。 電子証券取引ネットワーク分野[RFC3168]には、割り当てるどんな無料のコード・ポイントもありません。
3.3. IPv6 Next Header Field
3.3. IPv6次ヘッダーフィールド
[RFC3692] allocates two experimental code points (253 and 254) for the IPv6 Next Header field.
[RFC3692]は2つの実験コード・ポイント(253と254)をIPv6 Next Header分野に割り当てます。
Fenner Standards Track [Page 3] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[3ページ]。
3.4. IPv6 Source and Destination Addresses
3.4. IPv6ソースと送付先アドレス
3.4.1. IPv6 Unicast Addresses
3.4.1. IPv6ユニキャストアドレス
[RFC2928] defines a set of IPv6 addresses for testing and experimental usage:
[RFC2928]は1セットのテストするための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.
すなわち、Sub-TLA IDのブロックがIANAに割り当てた、(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登録を作成します。 ある実験に、Unique Local Addresses[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.
この書くこと時点で、いくつかのインターネットRegistriesには、それらが制御する数の空間から実験的な課題を許容する方針があります。 実験、登録、およびそれらの方針によって、これは追求するのが適切である経路であるかもしれません。
3.4.2. IPv6 Multicast Addresses
3.4.2. IPv6マルチキャストアドレス
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]があるアドレスが設定する他のマルチキャストは役に立つかもしれません。
3.5. IPv6 Hop-by-Hop and Destination Option Fields
3.5. IPv6ホップごとの目的地オプション・フィールド
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.
このドキュメントは単独のオプションタイプを選任します、「行為」と"chg"分野のすべての可能な値で、8つの異なったオプションタイプコードをもたらして。 割り当てられた値に関してセクション8を見てください。
3.6. IPv6 Routing Header Routing Type
3.6. IPv6ルート設定ヘッダールート設定タイプ
This document assigns two values for the Routing Type field in the IPv6 Routing Header, 253 and 254.
このドキュメントはIPv6ルート設定Header、253、および254におけるルート設定Type分野に2つの値を割り当てます。
Fenner Standards Track [Page 4] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[4ページ]。
4. Fields in the IPv4 ICMP Header
4. IPv4 ICMPヘッダーの分野
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コード値を割り当てるので、本書では実験値を割り当てるのは可能ではありません。
5. Fields in the IPv6 ICMP Header
5. IPv6 ICMPヘッダーの分野
[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]はInformational(200、201)とError(100、101)メッセージタイプのための実験ICMPv6タイプ値を含んでいます。 タイプ単位でICMPv6コード値を割り当てるので、本書では実験値を割り当てるのは可能ではありません。
5.1. IPv6 Neighbor Discovery Fields
5.1. IPv6隣人発見分野
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 Neighborディスカバリーヘッダー[RFC2461]はIANAによって管理された名前空間から割り当てられた値を運ぶ以下の分野を含んでいます: タイプ、コード、およびオプションタイプ。
5.1.1. IPv6 Neighbor Discovery Type
5.1.1. IPv6隣人発見タイプ
The Neighbor Discovery Type field is the same as the ICMPv6 Type field. See Section 5 for those code points.
NeighborディスカバリーType分野はICMPv6 Type分野と同じです。 セクション5をそれらのコード・ポイント見てください。
5.1.2. IPv6 Neighbor Discovery Code
5.1.2. IPv6隣人発見コード
The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no experimental code points are necessary.
ICMPv6 Code分野がIPv6 Neighborディスカバリーで使用されないので、どんな実験コード・ポイントも必要ではありません。
5.1.3. IPv6 Neighbor Discovery Option Type
5.1.3. IPv6隣人発見オプションタイプ
This document assigns two IPv6 Neighbor Discovery Option Types, 253 and 254.
このドキュメントはディスカバリーOption Types、253、および254を2IPv6 Neighborに割り当てます。
6. Fields in the UDP Header
6. UDPヘッダーの分野
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
2つのシステムポート(1021と1022)が、UDPとTCPのための実験のために予約されました。
Fenner Standards Track [Page 5] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[5ページ]。
7. Fields in the TCP Header
7. TCPヘッダーの分野
7.1. TCP Source and Destination Port Fields
7.1. TCPソースと仕向港分野
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
2つのシステムポート(1021と1022)が、UDPとTCPのための実験のために予約されました。
7.2. Reserved Bits in TCP Header
7.2. TCPヘッダーの予約されたビット
There are not enough reserved bits to allocate any for experimentation.
実験のためのいずれも割り当てることができるくらいの予約されたビットがありません。
7.3. TCP Option Kind Field
7.3. TCPオプション種類の分野
Two TCP options, 253 and 254, have been reserved for experimentation with TCP Options.
TCP Optionsとの実験のために2つのTCPオプション(253と254)を、控えてあります。
8. IANA Considerations
8. IANA問題
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 Multicast Addresses、(マルチキャストアドレス、(224.0、/24) 地方のNetwork Control Blockが区分する.0)(セクション2.4.2)
Group Address Name ------------- ---------------------------- 224.0.0.254 RFC3692-style Experiment (*)
グループアドレス名------------- ---------------------------- 224.0.0.254 RFC3692-スタイル実験(*)
IPv4 Multicast Addresses (multicast-addresses relative addresses section) (Section 2.4.2)
IPv4 Multicast Addresses(マルチキャストアドレス相対アドレス部)(セクション2.4.2)
Relative Description -------- ---------------------------- 254 RFC3692-style Experiment (*)
相対的な記述-------- ---------------------------- 254 RFC3692-スタイル実験(*)
IPv4 Option Numbers (ip-parameters initial section) (Section 2.5)
IPv4 Option民数記(ip-パラメタの初期の部)(セクション2.5)
Copy Class Number Value
---- ----- ------ -----
0 0 30 30
0 2 30 94
1 0 30 158
1 2 30 222
コピークラス番号価値---- ----- ------ ----- 0 0 30 30 0 2 30 94 1 0 30 158 1 2 30 222
Fenner Standards Track [Page 6] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[6ページ]。
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
HEX条例chg休息---- --- --- ----- 0x1e00 0 11110 0x3e00 1 11110 0x5e01 0 11110 0x7e01 1 11110 0x9e10 0 11110 0xbe10 1 11110 0xde11 0 11110 0xfe11 1、11110
IPv6 Neighbor Discovery Option Formats (icmpv6-parameters) (Section 5.1.3)
オプションが(icmpv6-パラメタ)をフォーマットするというIPv6隣人発見(セクション5.1.3)
Type Description ---- ------------------------------ 253 RFC3692-style Experiment 1 (*) 254 RFC3692-style Experiment 2 (*)
型記述---- ------------------------------ 253 RFC3692-スタイル実験1(*)254RFC3692-スタイル実験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 (*)
型記述---- ------------------------------ 253 RFC3692-スタイル実験1(*)254RFC3692-スタイル実験2(*)
ICMPv4 Type Numbers (icmp-parameters) (Section 4)
ICMPv4形式数(icmp-パラメタ)(セクション4)
Type Name ---- ------------------------------ 253 RFC3692-style Experiment 1 (*) 254 RFC3692-style Experiment 2 (*)
型名---- ------------------------------ 253 RFC3692-スタイル実験1(*)254RFC3692-スタイル実験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 (*)
キーワード小数記述------- -------- ------------------------------ exp1 1021/udp RFC3692-スタイルExperiment1(*)exp1 1021/tcp RFC3692-スタイルExperiment1(*)exp2 1022/udp RFC3692-スタイルExperiment2(*)exp2 1022/tcp RFC3692-スタイルExperiment2(*)
Fenner Standards Track [Page 7] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[7ページ]。
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 (*)
親切な長さの意味---- ------ ------------------------------ 253 N RFC3692-スタイル実験1(*)254N RFC3692-スタイル実験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.
(*) 明らかに構成された実験にこれらの値を単に使用するのは適切です。 実装におけるデフォルトとしてそれらを出荷してはいけません。 詳細に関してRFC3692を見てください。
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.
生産ネットワークは必ず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]計算に含まれていないので、人が彼らの使用を認証するのは、可能ではありません。 彼らの実験を設計するとき、実験者はこれを覚えておくべきです。 セクション3.5で定義された実験的なIPv6オプションのユーザは、オプションがAH計算に"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
実験コード・ポイントが行政上自己充足的なネットワークドメインの中で配布されるとき、ネットワーク管理者は、各コード・ポイントが実験の間の干渉を避けるのに一貫して使用されるのを保証するべきです。 実験コード・ポイントがトラフィックに使用されるとき、それは複数の管理ドメインに交差しています。
Fenner Standards Track [Page 8] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[8ページ]。
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.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、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.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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)のための隣人発見」、RFC2461、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分野)の定義」、RFC2474(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.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、BCP37、RFC2780(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課題」、RFC2928、2000年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
Fenner Standards Track [Page 9] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[9ページ]。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
2004年7月の[RFC3849]ヒューストンとG.と主、A.とP.スミス、「ドキュメンテーションのために予約されたIPv6アドレス接頭語」RFC3849。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、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.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
10.2. Informative References
10.2. 有益な参照
[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はカリフォルニア94025第メンローパーク(米国)をウイロにかけます。
Phone: +1 650 330-7893 EMail: fenner@research.att.com
以下に電話をしてください。 +1 650 330-7893 メールしてください: fenner@research.att.com
Fenner Standards Track [Page 10] RFC 4727 Experimental Values in Headers November 2006
フェナーStandardsは2006年11月にヘッダーでRFC4727の実験値を追跡します[10ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Fenner Standards Track [Page 11]
フェナー標準化過程[11ページ]
一覧
スポンサーリンク
