Network Working Group P. Nesser, II
Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed
IETF Transport Area Standards Track and Experimental Documents
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
この文書では、IPv4のすべての使用は、現在配備IETF交通エリアに文書化規格に対応し文書化することを目指しています。正常にすべてのIPv6インターネットにすべてのIPv4インターネットから移行するために、多くの中間ステップが取られます。これらのステップの一つは、IPv4の依存関係を持っている現在のプロトコルの進化です。これらのプロトコル（およびその実装は）独立したネットワークアドレスに再設計されることが期待され、それに失敗すると、少なくとも二重IPv4およびIPv6をサポートします。このためには、すべての標準（フル、ドラフト、および提案された）だけでなく、実験的RFCが調査され、すべての依存関係が記載されます。
Table of Contents
目次
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
This document is part of a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Operations & Management, Routing, Security, Sub-IP and Transport).
この文書は、IETF標準でIPv4アドレスのすべての使用を文書化することを目指し、文書セットの一部です。管理しやすい形式で情報を持っているための努力では、現在IETFエリア（アプリケーション、インターネット、運用と管理、ルーティング、セキュリティ、サブIPとトランスポート）に準拠した7つの文書に分割されています。
For a full introduction, please see the introduction [1].
完全な概要については、導入[1]を参照してください。
The rest of the document sections are described below.
ドキュメントのセクションの残りの部分は、以下に記載されています。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
セクション3、4、5、及び6はそれぞれフル、ドラフト、及び提案された標準、および実験RFCの生の分析を記載します。各RFCは、各RFCのコメントは、自然の中で「生」であり、RFC 1から始まり、（周り）RFC 3100で終わるその順番で説明されています。これは、各RFCは、問題はすでに修正されているかどうかを確認するために「先読み」していない議論真空や問題点や問題に議論されています。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
セクション7は、結果のすべてが全体としてみなされ、それ以降のRFCsで解決された問題が相関していることをここであり、セクション3に提示されたデータの分析である4、5、および6。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
（最も一般的に、単に「基準」という。）のフルインターネット規格は広く実装し、インターネット全体で使用されている完全に成熟したプロトコル仕様です。
Although UDP is a transport protocol there is one reference to the UDP/IP interface that states; "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." This does not force a rewrite of the protocol but will clearly cause changes in implementations.
UDPトランスポートプロトコルであるが述べUDP / IPインターフェースへの1つの基準があります。 「UDPモジュールは、インターネットヘッダから送信元と宛先のインターネットアドレス及びプロトコルフィールドを決定することができなければなりません」。これは、プロトコルの書き換えを強制しませんが、明らかな実装の変化の原因となります。
Section 3.1 which specifies the header format for TCP. The TCP header is free from IPv4 references but there is an inconsistency in the computation of checksums. The text says: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to specify 32-bit IPv4 addresses. While no modification of the TCP protocol is necessitated by this problem, an alternate needs to be specified as an update document, or as part of another IPv6 document.
TCPのヘッダフォーマットを指定する3.1節。 TCPヘッダは、IPv4の参照を含まないが、チェックサムの計算に矛盾があります。テキストは言う：「チェックサムはまた、概念的にTCPヘッダーに接頭辞96ビットの擬似ヘッダをカバーし、この疑似ヘッダは、送信元アドレス、宛先アドレス、プロトコル、およびTCPの長さが含まれています。」第一及び第二の32ビットワードが明らか32ビットのIPv4アドレスを指定することを意味します。 TCPプロトコルの修正は、この問題によって必要とされていないが、代替的には、更新文書として、または別のIPv6ドキュメントの一部として指定する必要があります。
This is a layer 3 protocol, and has as such no IPv4 dependencies.
これは、レイヤ3プロトコルであり、そのようななしのIPv4依存関係として有しています。
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS
3.4.1. 概念と方法：NetBIOSのTCP / UDPトランスポート上のサービスに対するRFC 1001プロトコル標準
Section 15.4.1. RELEASE BY B NODES defines:
セクション15.4.1。 BノードによってRELEASEを定義します：
A NAME RELEASE DEMAND contains the following information:
名前解放DEMANDは、以下の情報が含まれています。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- NetBIOS名 - NetBIOS名のスコープ - 名前のタイプ：ユニークまたはグループ - 解放するノードのIPアドレス - トランザクションID
Section 15.4.2. RELEASE BY P NODES defines:
セクション15.4.2。 PノードによるRELEASEを定義します：
A NAME RELEASE REQUEST contains the following information:
NAME解放要求には、次の情報が含まれています。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- NetBIOS名 - NetBIOS名のスコープ - 名前のタイプ：ユニークまたはグループ - 解放するノードのIPアドレス - トランザクションID
A NAME RELEASE RESPONSE contains the following information:
NAME解放応答は次の情報が含まれます。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID - Result: - Yes: name was released - No: name was not released, a reason code is provided
- NetBIOS名 - NetBIOS名のスコープ - 名前のタイプ：ユニークまたはグループ - 解放するノードのIPアドレス - トランザクションID - 結果： - はい：名前がリリースされなかった - いいえ：名前は、コードが提供される理由を発表していませんでした
Section 16. NetBIOS SESSION SERVICE states:
部16のNetBIOSセッションサービスの状態：
The NetBIOS session service begins after one or more IP addresses have been found for the target name. These addresses may have been acquired using the NetBIOS name query transactions or by other means, such as a local name table or cache.
1つまたは複数のIPアドレスは、ターゲット名のために発見された後にNetBIOSセッションサービスが開始されます。これらのアドレスは、NetBIOS名前クエリのトランザクションを使用して取得したり、ローカル名テーブルやキャッシュなどの他の手段によってされた可能性があります。
Section 16.1. OVERVIEW OF NetBIOS SESSION SERVICE
16.1節。 NetBIOSセッションサービスの概要
Session service has three phases:
セッションサービスは、次の3つのフェーズがあります。
Session establishment - it is during this phase that the IP address and TCP port of the called name is determined, and a TCP connection is established with the remote party.
セッション確立 - それはと呼ばれる名前のIPアドレスとTCPポートが決定されたこの段階で、TCP接続が相手で確立されています。
An end-node begins establishment of a session to another node by somehow acquiring (perhaps using the name query transactions or a local cache) the IP address of the node or nodes purported to own the destination name.
エンドノードは、何らかの形で（おそらく名前クエリトランザクションまたはローカル・キャッシュを使用して）宛先名を所有する主張ノードまたはノードのIPアドレスを取得することにより、別のノードへのセッションの確立を開始します。
Once the TCP connection is open, the calling node sends session service request packet. This packet contains the following information:
TCP接続が開いたら、呼び出し側のノードは、セッションサービス要求パケットを送信します。このパケットは、以下の情報が含まれています。
- Calling IP address (see note) - Calling NetBIOS name - Called IP address (see note) - Called NetBIOS name
- 呼び出しIPアドレス（注を参照） - 呼び出しNetBIOS名 - 呼び出さNetBIOS名 - IPアドレス（注を参照）と呼ばれます
NOTE: The IP addresses are obtained from the TCP service interface.
注：IPアドレスは、TCPサービス・インターフェースから取得されます。
If a compatible LISTEN exists, and there are adequate resources, then the session server may transform the existing TCP connection into the NetBIOS data session. Alternatively, the session server may redirect, or "retarget" the caller to another TCP port (and IP address).
互換性があるLISTEN、そして十分なリソースがある場合、セッションサーバは、NetBIOSデータセッションに既存のTCP接続を変換することができます。また、セッションサーバは、リダイレクトしたり、別のTCPポート（およびIPアドレス）に発信者を「再ターゲット」。
If the caller is redirected, the caller begins the session establishment anew, but using the new IP address and TCP port given in the retarget response. Again a TCP connection is created, and again the calling and called node exchange credentials. The called party may accept the call, reject the call, or make a further redirection.
呼び出し側がリダイレクトされた場合、呼び出し側は新たにセッションの確立を開始しますが、宛先再応答に与えられた新しいIPアドレスとTCPポートを使用して。再びTCP接続が作成され、再び呼び出し、ノード交換資格情報と呼ばれています。着信側がコールを拒否し、コールを受け入れる、またはさらにリダイレクトを行うことができます。
Every NetBIOS datagram has a named destination and source. To transmit a NetBIOS datagram, the datagram service must perform a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (This information may be cached to avoid the overhead of name query on subsequent NetBIOS datagrams.)
すべてのNetBIOSデータグラムは、指定された送信先と送信元を持っています。 NetBIOSのデータグラムを送信するには、データグラムサービスは、IPアドレスと送信先NetBIOS名の属性を学ぶために、名前のクエリ操作を実行する必要があります。 （この情報は、後続のNetBIOSデータグラム上の名前照会のオーバーヘッドを回避するためにキャッシュされる場合があります。）
NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datagram addressed to a group NetBIOS name, whether there are zero, one, or more actual members, is multicast. A NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.
NetBIOSのデータグラムは、ユニキャスト、マルチキャスト、またはブロードキャストであってもよいです。 NetBIOSのデータグラムは、ユニキャストであるユニークなNetBIOS名に宛て。 NetBIOSのデータグラムは、ゼロ、1つ、または複数の実際のメンバーが存在するかどうか、グループNetBIOS名宛てのマルチキャストです。原始的な「ブロードキャストデータグラムを送信する」NetBIOSを使用して送信されたNetBIOSデータグラムは放送です。
When the header and data of a NetBIOS datagram exceeds the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt.
NetBIOSのデータグラムのヘッダとデータをUDPパケットに許容されるデータの最大量を超えた場合、NetBIOSのデータグラムを送信する前に、断片化及び受信時に再組み立てしなければなりません。
A NetBIOS Datagram is composed of the following protocol elements:
NetBIOSのデータグラムは、以下のプロトコル要素から構成されています。
- IP header of 20 bytes (minimum) - UDP header of 8 bytes - NetBIOS Datagram Header of 14 bytes - The NetBIOS Datagram data.
- NetBIOSのデータグラムデータ - 14バイトのNetBIOSのデータグラムのヘッダー - 8バイトのUDPヘッダー - 20バイト（最小）のIPヘッダ。
- B NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - P NODES: - Node's permanent unique name - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - M NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation)
- Bノード： - ノードの恒久的な固有の名前 - かどうかIGMPが使用されている - 使用するブロードキャストIPアドレス - かどうかNetBIOSセッションキープアライブが必要とされている - 使用可能なUDPデータフィールド長（断片化を制御するために） - P・ノード： - ノードの恒久的な一意の名前 - NBNSのIPアドレス - NBDDのIPアドレス - かどうかNetBIOSセッションキープアライブが必要とされている - 使用可能なUDPデータフィールド長（断片化を制御するために） - M・ノード： - ノードの恒久的な固有の名前 - かどうかはIGMPを使用している - ブロードキャストIPアドレスへ使用 - NBNSのIPアドレス - NetBIOSセッションキープアライブが必要とされているかどうか - - NBDDのIPアドレスを使用可能なUDPデータフィールド長は、（断片化を制御するために）
All of the proceeding sections make implicit use of IPv4 addresses and a new specification should be defined for use of IPv6 underlying addresses.
進行セクションのすべては、IPv4アドレスと新しい仕様の暗黙の使用はIPv6の基礎となるアドレスの使用のために定義する必要があります。
3.4.2. RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS
3.4.2. TCP / UDP TRANSPORT ONのNetBIOSサービスのためのRFC 1002プロトコル標準：詳細な仕様
Section 4.2.1.3. RESOURCE RECORD defines
セクション4.2.1.3。リソースレコードの定義
RESOURCE RECORD RR_TYPE field definitions:
リソースレコードRR_TYPEフィールド定義：
Symbol Value Description:
記号値説明：
A 0x0001 IP address Resource Record (See REDIRECT NAME QUERY RESPONSE)
0x0001のIPは、リソースレコードを（名前クエリリダイレクト応答を参照してください）に対処します
Sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME OVERWRITE REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST, 4.2.5. POSITIVE NAME REGISTRATION RESPONSE, 4.2.6. NEGATIVE NAME REGISTRATION RESPONSE, 4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9. NAME RELEASE REQUEST & DEMAND, 4.2.10. POSITIVE NAME RELEASE RESPONSE, 4.2.11. NEGATIVE NAME RELEASE RESPONSE and Sections 4.2.13. POSITIVE NAME QUERY
セクション4.2.2。 NAME登録要求、4.2.3。 OVERWRITE REQUEST＆DEMAND、4.2.4に名前を付けます。 NAMEリフレッシュ要求、4.2.5。 POSITIVE NAME登録応答、4.2.6。 NEGATIVE NAME登録応答、4.2.7。 END-NODE CHALLENGE登録応答、4.2.9。 NAME解放要求＆DEMAND、4.2.10。 POSITIVE NAME解放応答、4.2.11。 NEGATIVE NAME解放応答とセクション4.2.13。 POSITIVE NAMEのQUERY
RESPONSE all contain 32 bit fields labeled "NB_ADDRESS" clearly defined for IPv4 addresses Sections 4.2.15. REDIRECT NAME QUERY RESPONSE contains a field "NSD_IP_ADDR" which also is designed for a IPv4 address.
応答はすべてのIPv4セクション4.2.15を解決するために、明確に定義された「NB_ADDRESS」というラベルの付いた32ビットのフィールドが含まれています。名前クエリ応答はまた、IPv4アドレスのために設計されているフィールド「NSD_IP_ADDR」が含まれてリダイレクトします。
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
4.3.5. SESSION再ターゲット応答パケット
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.1. NetBIOS DATAGRAM HEADER
4.4.1. NetBIOSのDATAGRAM HEADER
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST
DATAGRAM
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.3. DATAGRAM ERROR PACKET
4.4.3. DATAGRAMのエラーパケット
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.4. DATAGRAM QUERY REQUEST
セクション4.4.4。 DATAGRAM照会要求
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following are GLOBAL variables and should be NetBIOS user configurable:
次のグローバル変数があるとNetBIOSユーザ設定する必要があります：
- BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams with group name destinations and broadcast datagrams. The default is the IP broadcast address for a single IP network.
- BROADCAST_ADDRESS：IPアドレスB-ノードは、グループ名の宛先とブロードキャストデータグラムとデータグラムを送信するために使用します。デフォルトでは、単一のIPネットワークのIPブロードキャストアドレスです。
There is also a large amount of pseudo code for most of the protocols functionality that make no specific reference to IPv4 addresses. However they assume the use of the above defined packets. The pseudo code may be valid for IPv6 as long as the packet formats are updated.
IPv4アドレスには特に言及していないプロトコルの機能のほとんどのための擬似コードの大規模な量があります。しかし彼らは、上で定義されたパケットの使用を前提としています。擬似コードは限りパケットフォーマットが更新されるとIPv6のための有効な場合があります。
Section 5. The Protocol defines a mapping specification
第5節のプロトコルは、マッピング仕様を定義します
Mapping parameters is also straight-forward:
マッピングパラメータもストレートフォワードです。
network service TCP
------- ---
CONNECTION RELEASE
Called address server's IP address (4 octets)
呼ばれるアドレスサーバのIPアドレス（4つのオクテット）
Calling address client's IP address (4 octets)
呼び出しアドレス、クライアントのIPアドレス（4つのオクテット）
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
ドラフト規格は、IETFにおける最後から二番目の標準レベルを表します。プロトコルは、複数の独立した、相互運用可能な実装がある場合にドラフト標準を達成することができます。ドラフト規格は通常、非常に成熟し、広く使用されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.3. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control.
4.3. 最小量のコントロールがあるオーディオとビデオ会議のためのRFC 3551 RTPプロファイル。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
提案された標準は、入門レベルの文書です。でも、単一の実装のための要件はありません。提案多くの場合、実装されることはありませんか、IETF標準化プロセスに進みました。したがって、これらは、多くの場合、インターネットコミュニティに提示されているだけで、提案のアイデアです。時には欠陥が露出したり、彼らが問題に多くの競合ソリューションの一つですされています。この後の例では、何の議論は、それがこの議論の目的を果たすないだろうと提示されていません。
5.01. RFC 1144 Compressing TCP/IP headers for low-speed serial links
5.01. 低速シリアルリンクのためのRFC 1144の圧縮TCP / IPヘッダ
This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers.
このRFCは、特にTCP / IPv4パケットのヘッダの方に向いていると、それの現在のフォームでは動作しません。重要な仕事は、すでにTCP / IPv6のヘッダのために同様のアルゴリズムで行われました。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 6. Implementation Notes is states:
第6節実装の注意状態です。
Because the TMux mini-header does not contain a TOS field, only segments with the same IP TOS field should be contained in a single TMux message. As most systems do not use the TOS feature, this is not a major restriction. Where the TOS field is used, it may be desirable to hold several messages under construction for a host, one for each TOS value.
TMUXミニヘッダはTOSフィールドが含まれていないため、同一のIP TOSフィールドを持つ唯一のセグメントは、単一のTMUXメッセージに含まれるべきです。ほとんどのシステムは、TOS機能を使用しないように、これは主要な制限ではありません。 TOSフィールドが使用される場合、ホストの建設各TOS値のいずれかをいくつかのメッセージを保持することが望ましい場合があります。
Segments containing IP options should not be multiplexed.
IPオプションを含むセグメントは、多重化すべきではありません。
This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality.
これは明らかに特定のIPv4ですが、IPv6の用語で、簡単な修正再表示は、完全な機能をできるようになります。
5.05. RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC
5.05. RFC 1831 RPC：リモートプロシージャコールプロトコル仕様バージョン2 RPC
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there is the following code fragment:
セクション2.1（RPC言語）RPCBINDプロトコル仕様に次のコードがあります。
* Protocol family (r_nc_protofmly): * This identifies the family to which the protocol belongs. * The following values are defined: * NC_NOPROTOFMLY "-" * NC_LOOPBACK "loopback" * NC_INET "inet" * NC_IMPLINK "implink" * NC_PUP "pup" * NC_CHAOS "chaos" * NC_NS "ns" * NC_NBS "nbs" * NC_ECMA "ecma" * NC_DATAKIT "datakit" * NC_CCITT "ccitt" * NC_SNA "sna" * NC_DECNET "decnet" * NC_DLI "dli" * NC_LAT "lat" * NC_HYLINK "hylink" * NC_APPLETALK "appletalk" * NC_NIT "nit" * NC_IEEE802 "ieee802" * NC_OSI "osi" * NC_X25 "x25" * NC_OSINET "osinet" * NC_GOSIP "gosip"
*プロトコルファミリ（r_nc_protofmly）：*これは、プロトコルが属する家族を識別します。 *以下の値が定義されています* NC_NOPROTOFMLY " - " * NC_LOOPBACK "ループバック" * NC_INET "INET" * NC_IMPLINK "implink" * NC_PUP "子犬" * NC_CHAOS "混沌" * NC_NS "NS" * NC_NBS "ニッポン放送" * NC_ECMA」 ECMA "* NC_DATAKIT "datakit" * NC_CCITT "CCITT" * NC_SNA "SNA" * NC_DECNET "DECnetの" * NC_DLI "DLI" * NC_LAT "緯度" * NC_HYLINK "hylink" * NC_APPLETALK "AppleTalkの" * NC_NIT "NIT" * NC_IEEE802" IEEE802" * NC_OSI "OSI" * NC_X25 "X25" * NC_OSINET "osinet" * NC_GOSIP "GOSIP"
It is clear that the value for NC_INET is intended for the IP protocol and is seems clear that it is IPv4 dependent.
NC_INETの値はIPプロトコルのために意図されていることは明らかであり、それはIPv4のが依存していることは明らかであるようです。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is IPv6 aware and has no issues.
この仕様は、IPv6認識しており、何の問題もありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.14. RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
5.14. RFC 2205リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様
In Section 1. Introduction the statement is made:
セクション1.はじめに文が作られます。
RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack.
RSVPは、プロトコルスタックのトランスポートプロトコルの代わりを占め、IPv4またはIPv6の上で動作します。
Appendix A defines all of the header formats for RSVP and there are multiple formats for both IPv4 and IPv6.
付録Aは、RSVPのヘッダフォーマットのすべてを定義し、IPv4とIPv6の両方のための複数のフォーマットが存在します。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The defined IPsec extensions are valid for both IPv4 & IPv6. There are no IPv4 dependencies in this specification.
定義されたIPsecの拡張機能は、IPv4＆IPv6の両方のために有効です。この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.17. RFC 2211 Specification of the Controlled-Load Network Element Service
5.17. 制御負荷ネットワーク要素サービスのRFC 2211の仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.19. RFC 2215 General Characterization Parameters for Integrated Service Network Elements
5.19. 統合サービスネットワーク要素のためのRFC 2215個の一般的な特性評価パラメータ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 3.2 RTSP URL defines:
3.2節RTSPのURLを定義します。
The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs.
「RTSP」および「RTSPU」スキームがRTSPプロトコルを介してネットワークリソースを参照するために使用されます。このセクションでは、RTSP URLのスキーム固有の構文およびセマンティクスを定義します。
rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ] host = <A legal Internet host domain name of IP address (in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}> port = *DIGIT
rtsp_URL =（ "RTSP：" | "RTSPU："） "//" ホスト[ "：" ポート] [腹筋_経路]ホスト= <（ドット十進形式で）IPアドレスの法的インターネットホストドメイン名は、セクションで定義されていますRFC 1123の2.1 \引用{RFC1123}>ポート= * DIGIT
Although later in that section the following text is added:
後でそのセクションのが、次のテキストが追加されます。
The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1924 [19]).
URLでのIPアドレスの使用は、（RFC 1924 [19]を参照）可能な限り避けるべきです。
Some later examples show:
いくつかの後の例は示しています。
Example:
例：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg
C-> S：DESCRIBE RTSP：//server.example.com/fizzle/foo RTSP / 1.0のCSeq：312の受け入れ：アプリケーション/ SDP、アプリケーション/ RTSL、アプリケーション/ MHEG
S->C: RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 376
S-> C：RTSP / 1.0 200 OKのCSeq：312日付：1997年1月23日午後03時35分06秒GMTのコンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
which implies the use of the "IP4" tag and it should be possible to use an "IP6" tag. There are also numerous other similar examples using the "IP4" tag.
これは「IP4」タグの使用を意味し、「IP6」タグを使用することが可能でなければなりません。 「IP4」タグを使用して、他の多くの類似した例もあります。
RTSP is also dependent on IPv6 support in a protocol capable of describing media configurations, for example SDP RFC 2327.
RTSPは、例えば、SDPのRFC 2327のために、メディア設定を記述することが可能なプロトコルでもIPv6のサポートに依存しています。
RTSP can be used over IPv6 as long as the media description protocol supports IPv6, but only for certain restricted use cases. For full functionality there is need for IPv6 support. The amount of updates needed are small.
RTSPは、しかし、唯一の特定の制限されたユースケースのために、限り、メディア記述プロトコルがIPv6をサポートしているとして、IPv6の上で使用することができます。完全な機能のためにIPv6のサポートが必要です。必要なアップデートの量は小さいです。
This specification is under revision, and IPv6 support was added in RFC 3266 which updates this specification.
この仕様は改訂中であり、IPv6のサポートは、この仕様を更新RFC 3266で追加されました。
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方が認識しています。
5.24. RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM
5.24. RFC 2381制御されたロード・サービスの相互運用およびATMでの保証サービス
There does not seem any inherent IPv4 limitations in this specification, but it assumes work of other standards that have IPv4 limitations.
そこ任意の固有のIPv4の限界は、この仕様に思えるが、それはIPv4の限界を持っている他の標準の作業を想定していません。
5.25. RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
5.25. ITU-T勧告の1998バージョンについては、RFC 2429のRTPペイロードフォーマット。 H.263ビデオ（H.263 +）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.28. RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
5.28. IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）のRFC 2474の定義
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方が認識しています。
5.29. RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
5.29. 低速シリアルリンクのためのRFC 2508の圧縮IP / UDP / RTPヘッダ
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方が認識しています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方が認識しています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification only supports IPv4.
この仕様はIPv4のみをサポートしています。
This specification only supports IPv4.
この仕様はIPv4のみをサポートしています。
This specification only supports IPv4.
この仕様はIPv4のみをサポートしています。
This specification only supports IPv4.
この仕様はIPv4のみをサポートしています。
5.37. RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP)
5.37. RFC 2730のマルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
5.38. RFC 2733 An RTP Payload Format for Generic Forward Error Correction
5.38. 一般的なフォワードエラー訂正のためのRFC 2733アンRTPペイロードフォーマット
This specification is dependent on SDP which has IPv4 dependencies. Once that limitation is fixed, then this specification should support IPv6.
この仕様は、IPv4の依存関係を持っているSDPに依存しています。その制限が固定されると、この仕様はIPv6をサポートしなければなりません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.43. RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
5.43. RFC 2814 SBM（サブネット帯域幅マネージャー）：IEEE 802形式のネットワーク上でRSVPベースのアドミッション制御のためのプロトコル
This specification claims to be both IPv4 and IPv6 aware, but all of the examples are given with IPv4 addresses. That, by itself is not a telling point but the following statement is made:
この仕様は、IPv4とIPv6の両方を認識すると主張するが、実施例の全ては、IPv4アドレスが付与されています。それは、それ自体で占いポイントではなく、次のステートメントが行われます。
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information.
A）LocalDSBMAddrInfo - 現在のDSBMのIPアドレス（最初は、0.0.0.0）と優先順位。すべてのIPアドレスは、ネットワークバイト順であると想定されています。加えて、現在のDSBMのL2アドレスは、この状態情報の一部として記憶されます。
which could just be sloppy wording. Perhaps a short document clarifying the text is appropriate.
これだけのずさんな言葉遣いである可能性があります。おそらく、テキストを明確に短い文書が適切です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.45. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
5.45. DTMFケタ、電話トーン、および電話信号のためのRFC 2833 RTPペイロード
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.46. RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
5.46. RFC 2848ザ・パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this specification should support IPv6.
この仕様は、IPv4の依存関係を持っているSDPに依存しています。これらの制限が固定されると、その後、この仕様はIPv6をサポートする必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.48. RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP
5.48. RSVPで使用するためのRFC 2872のアプリケーションおよびサブアプリケーションIDポリシーエレメント
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6.
この仕様は、IPv4ヘッダを用いた手法を説明します。同様の技術は、必要に応じて、IPv6用に定義する必要があります。
5.50. RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP
5.50. RFC 2883 TCPのための選択確認応答（SACK）オプションの拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.59. RFC 3006 Integrated Services in the Presence of Compressible Flows
5.59. サービス統合型圧縮性流れの存在下でのRFC 3006
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
この文書では、圧縮性流れを説明したが、IPv4のみのコンテキストにおけるプロトコルを定義しています。 IPv6の圧縮性流れが定義されている場合、同様の技術はまた、定義されるべきです。
5.60. RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
5.60. MPEG-4オーディオ/ビジュアルストリームのRFC 3016 RTPペイロードフォーマット
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.61. RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
5.61. RFC 3033 Q.2941ジェネリック識別子で情報フィールドとプロトコル識別子の割り当てとインターネットプロトコルのためのQ.2957ユーザ間のシグナリング
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.65. RFC 3095 Robust Header Compression (ROHC): Framework and four profiles
5.65. RFC 3095ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
5.66. RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
5.66. ATMベアラ接続のためのセッション記述プロトコル（SDP）を使用するためのRFC 3108規則
This specification is currently limited to IPv4 as amplified below:
以下、増幅、本明細書は、現在のIPv4に限定されます。
The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255.
<rtcpPortNum>と<rtcpIPaddr>サブパラメータの範囲と形式が当たりである[1]。 <rtcpPortNum>は、それが奇数で1024〜65535の10進数です。この範囲の偶数を指定した場合、次の奇数番号が使用されます。 <rtcpIPaddr> 0.0.0.0から255.255.255.255まで、通常のドット付き10進IPアドレスの表現で表されます。
and
そして
<rtcpIPaddr> IP address for receipt Dotted decimal,
7-15 chars of RTCP packets
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This document is IPv4 limited since it uses the IPv4 TOS header field.
この文書は、IPv4のTOSヘッダフィールドを使用するためのIPv4が限られています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.75. RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)
5.75. セッション開始プロトコルにおける暫定的な応答のRFC 3262の信頼性（SIP）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.76. RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
5.76. RFC 3263セッション開始プロトコル（SIP）：SIPサーバーの検索
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.77. RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)
5.77. RFC 3264セッション記述プロトコル（SDP）とのオファー/アンサーモデル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.78. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
5.78. RFC 3265セッション開始プロトコル（SIP）特異的イベント通知
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem.
実験的RFCは、通常、インターネット上のwidescale実装や用法を持っていないプロトコルを定義します。彼らは多くの場合、自然の中で妥当または制限された競技場で使用されています。彼らは、潜在的な相互運用性またはいくつかの他の潜在的に有用なシナリオを可能にするためにインターネットコミュニティに文書化されています。いくつかのケースでは、彼らは認め問題の主流の解決策の代替として提示されています。
This document is IPv4 limited as stated in the following section:
次のセクションで述べたようにこの文書では、IPv4が制限されています。
When used in the internet environment, RDP segments are sent using the version 4 IP header as described in RFC791, "Internet Protocol." The RDP protocol number is ??? (decimal). The time-to-live field should be set to a reasonable value for the network.
インターネット環境で使用される場合RFC791に記載されているように、RDPセグメントは、バージョン4 IPヘッダを使用して送信された「インターネットプロトコル」。 RDPプロトコル番号は？ （10進数）。生存時間フィールドには、ネットワークのための合理的な値に設定する必要があります。
All other fields should be set as specified in RFC-791.
RFC-791で指定されている他のすべてのフィールドが設定されるべきです。
A new protocol specification would be needed to support IPv6.
新しいプロトコル仕様は、IPv6をサポートするために必要とされるであろう。
6.02. RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP)
6.02. RFC 938インターネット信頼性の高いトランザクションプロトコル機能とインタフェースの仕様（IRTP）
This specification states:
この仕様状態：
Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module must maintain the following information (called the connection table):
各IRTPは、単一のインターネットアドレスに関連付けられています。 IRTPの同期メカニズムは、各IRTPモジュールは、それが通信するすべてのモジュールのインターネットアドレスを知っている必要条件に依存しています。各リモートインターネットアドレスの場合は、IRTPモジュールは、（接続テーブルと呼ばれる）は、次の情報を維持する必要があります。
rem_addr (32 bit remote internet address)
rem_addr（32ビットリモートインターネットアドレス）
A new specification that is IPv6 aware would need to be created.
IPv6は認識している新しい仕様を作成する必要があります。
This RFC states:
このRFCは述べています：
The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number.
活性末端は、受動端が待機するクライアント固有の「既知の」16ビットポート番号を介して受動クライアントを指定します。活性末端は、32ビットインターネットアドレスと一意の16ビットポート番号を介して自分自身を識別する。
Clearly, this is IPv4 dependent, but could easily be modified to support IPv6 addressing.
明らかに、これは依存IPv4のですが、簡単にIPv6アドレスをサポートするように変更することができます。
This specification has many IPv4 dependencies in its implementation appendices. For operations over IPv6 a similar implementation procedure must be defined. The IPv4 specific information is show below.
この仕様は、その実装の付録に多くのIPv4の依存関係を持っています。 IPv6経由の操作では同様の実施手順を定義する必要があります。 IPv4の具体的な情報は、以下を示しています。
IV.1. Domain 1
IV.1。ドメイン1
For initial use of VMTP, we define the domain with Domain identifier 1 as follows:
VMTPの最初の使用のために、私たちは、ドメイン識別子1次のようにして、ドメインを定義します。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
The Internet address is the Internet address of the host on which this entity-id is originally allocated. The Discriminator is an arbitrary value that is unique relative to this Internet host address. In addition, the host must guarantee that this identifier does not get reused for a long period of time after it becomes invalid. ("Invalid" means that no VMTP module considers in bound to an entity.) One technique is to use the lower order bits of a 1 second clock. The clock need not represent real-time but must never be set back after a crash. In a simple implementation, using the low order bits of a clock as the time stamp, the generation of unique identifiers is overall limited to no more than 1 per second on average. The type flags were described in Section 3.1.
インターネットアドレスがこのエンティティ-idが元々割り当てられているホストのインターネットアドレスです。弁別器は、このインターネットホストアドレスに対して一意である任意の値です。また、ホストは、この識別子は、それが無効になった後、時間の長い期間のために再利用されないことを保証しなければなりません。 （「無効」はVMTPモジュールがエンティティにバインドさに考慮しないことを意味する。）一つの技術は、1秒のクロックの下位ビットを使用することです。クロックは、リアルタイムを表す必要はないが、バッククラッシュ後に設定してはいけません。タイムスタンプとしてクロックの下位ビットを使用した単純な実装では、一意の識別子の生成は、全体的な平均で毎秒せいぜい1に制限されています。タイプフラグは、セクション3.1で説明されました。
An entity may migrate between hosts. Thus, an implementation can heuristically use the embedded Internet address to locate an entity but should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred.
エンティティは、ホスト間で移動することができます。したがって、実装は、発見的エンティティを検索するために埋め込まれたインターネットアドレスを使用することができるが、移行エンティティのリダイレクトのキャッシュを維持し、プラスマイグレーションが発生したことを示す操作を通知受け入れるように準備されるべきです。
Entity group identifiers in Domain 1 are structured in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as:
ドメイン1内のエンティティグループ識別子は、それらが周知であるか、または動的に割り当てられた識別子かどうかに応じて、二つの形態のいずれかで構成されています。よく知られているエンティティの識別子は次のように構成されています。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator distinguishes group identifiers using the same Internet host group. Well-known entity group identifiers should be allocated to correspond to the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain as its embedded Internet host group address the host group for Domain Name servers.
第二の上位ビット（GRP）が1に設定して、エンティティ識別子のこの形態は、下位32ビットで指定されたインターネットホストグループアドレスにマッピングされます。弁別器は同じインターネットホストグループを使用してグループ識別子を区別します。そのサービスがVMTPによって提供されているため、よく知られているエンティティのグループ識別子ではなく、具体的に、グループのメンバーであるホストによって提供される基本サービスに対応するように割り当てられるべきです。たとえば、ドメインネームサービスのためのよく知られたエンティティグループの識別子は、その埋め込まれたインターネットホストグループアドレスとドメインネームサーバのホストグループを含める必要があります。
A dynamically allocated entity identifier is structured as:
動的に割り当てられたエンティティの識別子は次のように構成されています。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is a Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier.
第二の上位ビット（GRP）が1に設定して下位32ビットのインターネットアドレスを動的このエンティティグループ識別子を割り当て、ホストに割り当てられたインターネットアドレスです。動的に割り当てられたエンティティグループ識別子はX.X.Xエンティティグループ識別子のディスクリミネータサブフィールドの下位24ビットであるインターネットホストグループアドレス232.X.X.Xにマッピングされます。
We use the following notation for Domain 1 entity identifiers <10> and propose it use as a standard convention.
私たちは、ドメイン1エンティティ識別子<10>のために、次の表記を使用して、標準的な慣習として使用して提案しています。
<flags>-<discriminator>-<Internet address>
<フラグ> - <弁別> - <インターネットアドレス>
where <flags> are [X]{BE,LE,RG,UG}[A]
<フラグ>である[X] {BE、LE、RG、UG} [A]
X = reserved BE = big-endian entity LE = little-endian entity RG = restricted group UG = unrestricted group A = alias
X =予約BE =ビッグエンディアン実体LE =リトルエンディアン実体RG =制限されたグループUG =無制限のグループA =エイリアス
and <discriminator> is a decimal integer and <Internet address> is in standard dotted decimal IP address notation.
そして<弁別器は> 10進数の整数と<インターネットアドレス>は、標準ドット付き10進IPアドレス表記です。
V.1. Authentication Domain 1
V.1。認証ドメイン1
A principal identifier is structured as follows.
次のように主識別子が構成されています。
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
VI. IP Implementation
VI。 IPの実装
VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol (although it may also be implemented as a local network protocol directly in "raw" network packets.)
VMTPはDoDのIPインターネット・データグラム・プロトコル上で実装されるように設計されている（これは直接「生の」ネットワークパケット内のローカルネットワークプロトコルとして実装されてもよいです。）
The well-known entity identifiers specified to date are:
日付を指定し、よく知られているエンティティの識別子は、次のとおりです。
VMTP_MANAGER_GROUP RG-1-224.0.1.0 Managers for VMTP operations.
VMTP操作のためのVMTP_MANAGER_GROUP RG-1-224.0.1.0マネージャ。
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0 Client entity identifier to use when a (big-endian) host has not determined or been allocated any client entity identifiers.
VMTP_DEFAULT_BECLIENTはBE-1-224.0.1.0（ビッグエンディアン）ホストが決定していないか、任意のクライアントエンティティの識別子を割り当てられてときに使用するクライアントエンティティの識別子。
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Client entity identifier to use when a (little-endian) host has not determined or been allocated any client entity identifiers.
VMTP_DEFAULT_LECLIENT（リトルエンディアン）を使用するLE-1-224.0.1.0クライアントエンティティ識別子ホストが決定されていない、または任意のクライアントエンティティ識別子を割り当てられて。
Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong.
その224.0.1.0がVMTPにし、すべてのVMTPホストが属するに割り当てられたホストグループアドレスであることに注意してください。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.07. RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification
6.07. RFC 1644 T / TCP - 取引機能仕様のためのTCP拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.11. RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm
6.11. RFC 2582 NewRenoの変更TCPの高速リカバリアルゴリズムに
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
In the initial survey of RFCs 24 positives were identified out of a total of 104, broken down as follows:
RFCの初期調査では24個の陽性は、次のように分解、104の合計のうち、同定されました。
Standards: 3 out of 5 or 60.00%
Draft Standards: 0 out of 2 or 0.00%
Proposed Standards: 17 out of 82 or 20.73%
Experimental RFCs: 4 out of 15 or 26.67%
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that SHOULD be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below.
その中で、彼らは時代遅れで、未使用のプロトコルを文書化するため、他の人が積極的に適切なワーキンググループによって更新されている文書プロトコルですが、多くは、何のアクションを必要としない同定しました。さらに、更新されるべきではなく、彼らが更新されていない場合はすべての業務への影響を起こさない水準の多くのインスタンスがあります。残りのインスタンスは、以下の文書化されています。
Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1.
セクション3.1は、32ビットの送信元および宛先IPv4アドレスを使用してTCPチェックサムを計算するための手法を定義します。この問題は、RFC 2460のセクション8.1で扱われています。
These two RFCs have many inherent IPv4 assumptions and a new set of protocols must be defined.
これら二つのRFCは、多くの固有のIPv4の前提条件を持っているとプロトコルの新しいセットを定義する必要があります。
This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP.
この問題は、TCPの上にRFC 2126、ISOトランスポートサービスで修正されています。
There are no draft standards within the scope of this document.
この文書の範囲内にはドラフト基準はありません。
This problem has been resolved in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509.
この問題は、低速シリアルリンクのIP / UDP / RTPヘッダを圧縮、RFC2508で解決されました。また、RFC 2507＆RFC 2509を参照してください。
The problems can be resolved with a definition of the NC_INET6 protocol family.
問題はNC_INET6プロトコルファミリの定義で解決することができます。
Problem has been acknowledged by the RTSP developer group and will be addressed in the move from Proposed to Draft Standard. This problem is also addressed in RFC 2732, IPv6 Literal Addresses in URL's.
問題は、RTSPの開発者グループによって承認されており、標準のドラフトする案からの移動で対処されることになります。この問題は、URLの中にRFCで2732年、IPv6のリテラルアドレスをアドレス指定されています。
One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem can be addressed with a minor textual clarification. This must be done if the document is to transition from Proposed to Draft. These problems are solved by documents currently in Auth48 or IESG discuss.
一つの問題は、RFC 2732で対処され、IPv6のリテラルは、URLの中のアドレス。他の問題はマイナーテキストの明確化で対処することができます。文書はドラフトする案から移行する場合、これは実行する必要があります。これらの問題は、現在Auth48や議論IESGの文書によって解決されます。
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題を解決するために取り組んでいます。
The IPPM WG is working to resolve these issues. An ID is available (draft-ietf-ippm-owdp-03.txt).
IPPM WGは、これらの問題を解決するために取り組んでいます。 IDは（ドラフト-IETF-IPPM-owdp-03.txt）が利用可能です。
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題を解決するために取り組んでいます。
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題を解決するために取り組んでいます。
7.3.08. The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848)
7.3.08. パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張（RFC 2848）
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6.
この仕様は、IPv4の依存関係を持っているSDPに依存しています。これらの制限が固定されると、その後、このプロトコルは、IPv6をサポートする必要があります。
The problems are not being addressed.
問題が解決されていません。
7.3.10. Integrated Services in the Presence of Compressible Flows (RFC 3006)
7.3.10. 圧縮性流れの存在下での統合サービス（RFC 3006）
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
この文書では、圧縮性流れを説明したが、IPv4のみのコンテキストにおけるプロトコルを定義しています。 IPv6の圧縮性流れが定義されている場合、同様の技術はまた、定義されるべきです。
The problems are not being addressed, but it is unclear whether the specification is being used.
問題が解決されていないが、仕様が使用されているかどうかは不明です。
An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field.
このドキュメントの更新は、IPv4のTOSフィールドとまったく同じになるように定義されているので、単純にIPv6のトラフィッククラスフィールドの使用を定義することができます。
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様は、IPv4に依存し、新しいプロトコル標準を製造することができます。
7.4.2. Internet Reliable Transaction Protocol functional and interface specification (RFC 938)
7.4.2. インターネット信頼性の高いトランザクションプロトコル機能とインタフェースの仕様（RFC 938）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様は、IPv4に依存し、新しいプロトコル標準を製造することができます。
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様は、IPv4に依存し、新しいプロトコル標準を製造することができます。
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様は、IPv4に依存し、新しいプロトコル標準を製造することができます。
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様は、IPv4に依存し、新しいプロトコル標準を製造することができます。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは、仕様のIPv6対応の準備を調べます。これは、それ自体ではセキュリティ上の配慮を持っていません。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thanks his partner in all ways, Wendy M. Nesser.
著者は、この文書の研究と生産におけるインターネット協会の支援を承認したいと思います。さらに著者、フィリップJ. Nesser IIは、すべての方法で彼のパートナー、ウェンディーM. Nesser感謝したいと思います。
The editor, Andreas Bergstrom, would like to thank Pekka Savola for guidance and collection of comments for the editing of this document. He would further like to thank Allison Mankin, Magnus Westerlund and Colin Perkins for valuable feedback on some points of this document.
編集者、アンドレアスベルイストロームは、このドキュメントの編集のためのガイダンスやコメントを収集するためペッカSavolaに感謝したいと思います。さらに彼は、このドキュメントのいくつかの点で貴重なフィードバックのためのアリソンマンキン、マグヌスウェスターとコリンパーキンスに感謝したいと思います。
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser、II、P.およびA.ベルイストローム、エディタを、RFC 3789、2004年6月 "のIPv4の調査の概要は、現在展開IETF標準のアドレス"。
Please contact the authors with any questions, comments or suggestions at:
でご質問、コメントや提案を作者に連絡してください：
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ. Nesser II校長Nesser＆Nesserコンサルティング13501第百アヴェNE、＃5202カークランド、WA 98034
Phone: +1 425 481 4303 Fax: +1 425 48 EMail: phil@nesser.com
電話：+1 425 481 4303ファックス：+1 425 48 Eメール：phil@nesser.com
Andreas Bergstrom, Editor Ostfold University College Rute 503 Buer N-1766 Halden Norway
アンドレアスベルイストローム、エディタエースト大学ルートアーチ503 N-1766ハルデンノルウェー
EMail: andreas.bergstrom@hiof.no
メールアドレス：andreas.bergstrom@hiof.no
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。