RFC3794 日本語訳
3794 Survey of IPv4 Addresses in Currently Deployed IETF TransportArea Standards Track and Experimental Documents. P. Nesser, II, A.Bergstrom, Ed.. June 2004. (Format: TXT=60001 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Nesser, II
Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
ワーキンググループP.Nesser、コメントを求めるII要求をネットワークでつないでください: 3794年のNesser&Nesserコンサルティングカテゴリ: エド情報のA.ベルイストローム、エーストフォールユニバーシティ・カレッジ2004年6月
Survey of IPv4 Addresses in Currently Deployed
IETF Transport Area Standards Track and Experimental Documents
IPv4の調査は、現在配布しているIETFで輸送が領域標準化過程と実験ドキュメントであると扱います。
Status of this Memo
この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).
Copyright(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 Transport Areaで記録された規格を扱うすべてを記録しようとします。 首尾よくすべてのIPv4インターネットからすべてのIPv6インターネットに移行するために、多くの中間の段階を取るでしょう。 これらのステップの1つはIPv4の依存を持っている現在のプロトコルの発展です。 これらのプロトコル(そして、それらの実装)がネットワーク・アドレス独立者であることが再設計されることが望まれていますが、それに失敗するのは二元的にIPv4とIPv6を少なくともサポートするでしょう。 このために、Experimental RFCsと同様にすべてのStandards(完全、Draft、およびProposed)が調査されるでしょう、そして、どんな依存も記録されるでしょう。
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
1.0. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2.0。 組織を記録してください。 . . . . . . . . . . . . . . . . . . . 2 3.0. 完全な規格. . . . . . . . . . . . . . . . . . . . . . . 2 4.0。 規格を作成してください。 . . . . . . . . . . . . . . . . . . . . . . 10 5.0. 提案された標準. . . . . . . . . . . . . . . . . . . . . 11 6.0。 実験的なRFCs。 . . . . . . . . . . . . . . . . . . . . . 22 7.0. 結果. . . . . . . . . . . . . . . . . . . . . 27 7.1の概要。 規格。 . . . . . . . . . . . . . . . . . . . . . . 27 7.2. 規格を作成してください。 . . . . . . . . . . . . . . . . . . . 27 7.3. 提案された標準. . . . . . . . . . . . . . . . . . 27 7.4。 実験的なRFCs。 . . . . . . . . . . . . . . . . . . 29 8.0. セキュリティ問題。 . . . . . . . . . . . . . . . . . . 30 9.0. 承認. . . . . . . . . . . . . . . . . . . . . . 30
Nesser II & Bergstrom Informational [Page 1] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[1ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30 11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
10.0. 引用規格。 . . . . . . . . . . . . . . . . . . . . 30 11.0. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 30 12.0。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 31
1.0. Introduction
1.0. 序論
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アドレスのすべての用法を記録することを目指す1人の文献集合の一部です。 処理しやすいフォームに情報を持つ取り組みでは、現在のIETF領域(アプリケーション、インターネット、Operations&Management、ルート設定、Security、Sub-IP、およびTransport)に一致している7通のドキュメントがそれに細かく分けられました。
For a full introduction, please see the introduction [1].
完全な序論に関しては、序論[1]を見てください。
2.0. Document Organization
2.0. ドキュメント組織
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はFull、Draft、Proposed Standards、およびExperimental RFCsの生の分析について説明します。 各RFCは自分の番になって、RFC1をきっかけに議論して、(around) RFC3100と共に終わっています。 各RFCのためのコメントは現実に「生です」。 真空ですなわち各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はセクション3、4、5、および6に提示されたデータの分析です。 結果のすべてが全体で考えられて、後のRFCsで解決された問題が関連されているのが、ここにそれがあります。
3.0. Full Standards
3.0. 完全な規格
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネットStandards(最も一般的に単に「規格」と呼ばれる)は広く履行されて、インターネット中で使用される完全に熟しているプロトコル仕様です。
3.1. RFC 768 User Datagram Protocol
3.1. RFC768ユーザー・データグラム・プロトコル
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モジュールはインターネットヘッダーからソース、送付先インターネットアドレス、およびプロトコル分野を決定できなければなりません。」 これは、プロトコルの書き直しを強制しませんが、明確に実装における変化を引き起こすでしょう。
Nesser II & Bergstrom Informational [Page 2] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[2ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
3.2. RFC 793 Transmission Control Protocol
3.2. RFC793通信制御プロトコル
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.
セクション3.1 TCPにヘッダー形式を指定する。 TCPヘッダーには、IPv4参照がありませんが、チェックサムの計算における矛盾があります。テキストは言います: 「また、チェックサムは概念的にTCPヘッダーへ前に置かれた96ビットの疑似ヘッダーをカバーしています。」 「この疑似ヘッダーはSource Address、Destination Address、プロトコル、およびTCPの長さを含んでいます。」 最初の単語と2番目の32ビットの単語は明確に32ビットのIPv4アドレスを指定することになっています。 TCPプロトコルの変更は全くこの問題によって必要とされませんが、補欠は、アップデートドキュメントとして、または、別のIPv6ドキュメントの一部として指定される必要があります。
3.3. RFC 907 Host Access Protocol specification
3.3. RFC907Host Accessプロトコル仕様
This is a layer 3 protocol, and has as such no IPv4 dependencies.
これは、層3のプロトコルであり、そういうものとしてIPv4の依存を全く持っていません。
3.4. NetBIOS Service Protocols. RFC1001, RFC1002
3.4. NetBIOSはプロトコルを修理します。 RFC1001、RFC1002
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A
TCP/UDP TRANSPORT: CONCEPTS AND METHODS
3.4.1. TCP/UDP輸送のNetBIOSサービスのRFC1001プロトコル標準: 概念とメソッド
Section 15.4.1. RELEASE BY B NODES defines:
セクション15.4.1。 RELEASE BY B NODESは以下を定義します。
A NAME RELEASE DEMAND contains the following information:
NAME RELEASE 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アドレス--Transaction ID
Section 15.4.2. RELEASE BY P NODES defines:
セクション15.4.2。 RELEASE BY P NODESは以下を定義します。
A NAME RELEASE REQUEST contains the following information:
NAME RELEASE REQUESTは以下の情報を含んでいます:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
- NetBIOS名(NetBIOS名の範囲)はタイプを命名します: ユニークであるかグループ--リリースノードのIPアドレス--Transaction ID
Nesser II & Bergstrom Informational [Page 3] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[3ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
A NAME RELEASE RESPONSE contains the following information:
NAME RELEASE RESPONSEは以下の情報を含んでいます:
- 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アドレス--Transaction ID--結果: - はい: 名前はリリースされました--、いいえ: 名前をリリースしないで、理由コードを提供します。
Section 16. NetBIOS SESSION SERVICE states:
セクション16。 NetBIOS SESSION SERVICE州:
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:
セッション・サービスには、三相があります:
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接続はリモートパーティーと共に確立されます。
6.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
6.1.1. セッション確立段階概要
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が命名する呼ぶこと(IPアドレス(注意を見る)と呼ばれる)は、NetBIOSを名前と呼びました。
NOTE: The IP addresses are obtained from the TCP service
interface.
以下に注意してください。 TCPサービスインタフェースからIPアドレスを得ます。
Nesser II & Bergstrom Informational [Page 4] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[4ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
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が存在していて、適切なリソースがあれば、セッションサーバは既存のTCP接続をNetBIOSデータセッションに変えるかもしれません。 あるいはまた、セッションサーバが向け直されるかもしれませんか、または"「再-目標」"は別の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接続は創造されます、そして、一方、呼ぶのと呼ばれたノードは資格証明書を交換します。 被呼者は、呼び出しを受け入れるか、呼び出しを拒絶するか、または一層のリダイレクションを作るかもしれません。
17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
17.1. NetBIOSデータグラムサービスの概要
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データグラムを送るなら、データグラムサービスは、目的地NetBIOS名のIPアドレスと属性を学ぶために名前質問操作を実行しなければなりません。 (この情報はその後のNetBIOSデータグラムの上に名前質問のオーバーヘッドを避けるためにキャッシュされるかもしれません。)
17.1.1. UNICAST, MULTICAST, AND BROADCAST
17.1.1. ユニキャスト、マルチキャスト、および放送
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名に扱われたNetBIOSデータグラム(1人以上の実際のメンバー)はマルチキャストです。 NetBIOS「ブロードキャスト・データグラムを送ってください」を原始的に使用させられるNetBIOSデータグラムは放送されます。
17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
17.1.2. 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.
- 20バイト(最小の)のIPヘッダー--8バイト--14バイトのNetBIOSデータグラムHeader--NetBIOSデータグラムデータのUDPヘッダー。
Nesser II & Bergstrom Informational [Page 5] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[5ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
18. NODE CONFIGURATION PARAMETERS
18. ノード設定パラメータ
- 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が使用中であるか否かに関係なく、ノードの永久的なユニークな名前はNetBIOSセッション生活費アリフが必要な(使用可能なUDPデータフィールド長(断片化を制御する))P NODESであるか否かに関係なく、使用するIPアドレスを放送しました: - ノードの永久的なユニークな名前--NBNSのIPアドレス--NBDDのIPアドレス--NetBIOSセッション生活費アリフが必要な(使用可能なUDPデータフィールド長(断片化を制御する))M NODESであるか否かに関係なく: - NetBIOSセッション生活費アリフが必要であるか否かに関係なく、IGMPが使用中であるか否かに関係なく、ノードの永久的なユニークな名前は使用するIPアドレス--NBNSのIPアドレス--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輸送のNetBIOSサービスのRFC1002プロトコル標準: 仕様詳細
Section 4.2.1.3. RESOURCE RECORD defines
セクション4.2 .1 .3。 RESOURCE RECORDは定義します。
RESOURCE RECORD RR_TYPE field definitions:
RESOURCE RECORD RR_TYPEは定義をさばきます:
Symbol Value Description:
シンボル値の記述:
A 0x0001 IP address Resource Record (See
REDIRECT NAME QUERY RESPONSE)
0×0001IPアドレスResource Record(再直接の名前質問応答を見ます)
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。 .3に要求、4.2と登録を命名してください。 .4に重ね書き要求と要求、4.2を命名してください。 名前は.5に要求、4.2をリフレッシュします。 正数は登録応答、4.2を.6と命名します。 ネガは登録応答、4.2を.7と命名します。 エンドノードは.9に登録応答、4.2に挑戦します。 .10にリリース要求と要求、4.2を命名してください。 積極的な名前は.11に応答、4.2をリリースします。 否定的名前リリース応答とセクション4.2.13。 積極的な名前質問
Nesser II & Bergstrom Informational [Page 6] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[6ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
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.
RESPONSEはIPv4アドレスセクション4.2.15のために明確に定義された「ネブラスカ_アドレス」とラベルされた32ビットの分野をすべて含んでいます。 REDIRECT NAME QUERY RESPONSEは分野「NSD_IP_ADDR」を含んでいます(また、IPv4アドレスのために設計されています)。
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
セクション4.3.5。 セッションRETARGET応答パケット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 旗| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RETARGET_IP_アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.1. NetBIOS DATAGRAM HEADER
セクション4.4.1。 NetBIOSデータグラムヘッダー
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー_はタイプされます。| 旗| ディー・ジー・エム_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_IP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ポート| ディー・ジー・エム_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット_オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nesser II & Bergstrom Informational [Page 7] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[7ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST
DATAGRAM
セクション4.4.2。 ダイレクト_ユニークで、ダイレクトな_グループ、およびブロードキャスト・データグラム
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 /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー_はタイプされます。| 旗| ディー・ジー・エム_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_IP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ポート| ディー・ジー・エム_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット_オフセット| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /ソース_名前///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /目的地_名前///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /ユーザ_データ///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.3. DATAGRAM ERROR PACKET
セクション4.4.3。 データグラム誤りパケット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー_はタイプされます。| 旗| ディー・ジー・エム_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_IP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ポート| 誤り_コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nesser II & Bergstrom Informational [Page 8] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[8ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
Section 4.4.4. DATAGRAM QUERY REQUEST
セクション4.4.4。 データグラム質問要求
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー_はタイプされます。| 旗| ディー・ジー・エム_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_IP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ポート| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | /目的地_名前///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
4.4.5. データグラムの積極的で否定的な質問応答
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー_はタイプされます。| 旗| ディー・ジー・エム_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_IP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ポート| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | /目的地_名前///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
5.3. NetBIOSデータグラムサービスプロトコル
The following are GLOBAL variables and should be NetBIOS user
configurable:
↓これは、GLOBAL変数であり、構成可能な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.
- _アドレスを放送してください: B-ノードがグループ名の目的地とブロードキャスト・データグラムデフォルトでデータグラムを送るのに使用するIPアドレスはただ一つのIPネットワークのためのIP放送演説です。
Nesser II & Bergstrom Informational [Page 9] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[9ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
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に、中間コードは有効であるかもしれません。
3.5. RFC 1006 ISO Transport Service on top of the TCP (Version: 3)
3.5. TCPの上のRFC1006ISO Transport Service(バージョン: 3)
Section 5. The Protocol defines a mapping specification
セクション5。 プロトコルはマッピング仕様を定義します。
Mapping parameters is also straight-forward:
また、パラメタを写像するのも簡単です:
network service TCP
------- ---
CONNECTION RELEASE
ネットワーク・サービスTCP------- --- コネクション解放
Called address server's IP address
(4 octets)
アドレスサーバのIPアドレスと呼ばれます。(4つの八重奏)
Calling address client's IP address
(4 octets)
アドレスをクライアントのIPアドレスと呼びます。(4つの八重奏)
4.0. Draft Standards
4.0. 草稿規格
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.
草稿StandardsはIETFに終わりから二番目の標準のレベルを表します。 複数の、そして、独立していて、共同利用できる実装があるときだけ、プロトコルは草稿規格を実現できます。 草稿Standardsは通常、かなり熟して広く使用されています。
4.1. RFC 3530 Network File System (NFS) version 4 Protocol
4.1. RFC3530ネットワークファイルシステム(NFS)バージョン4 プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.2. RFC 3550 RTP: A Transport Protocol for Real-Time Applications
4.2. RFC3550RTP: リアルタイムのアプリケーションのためのトランスポート・プロトコル
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. 最小量のコントロールがあるオーディオとテレビ会議システムのためのRFC3551RTPプロフィール。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 10] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[10ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.0. Proposed Standards
5.0. 提案された標準
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.
提案されたStandardsは紹介している平らなドキュメントです。 ただ一つの実装さえのための要件が全くありません。 多くの場合、ProposedはIETF標準化過程で実装されるか、または決して進められません。 したがって、それらはインターネットコミュニティに提示されるしばしばただ提案された考えです。 時々、欠点は暴露されるか、彼らが問題への多くの競争している解決の1つです。これらの後の場合では、この議論の目的に役立たないように議論は全く提示されません。
5.01. RFC 1144 Compressing TCP/IP headers for low-speed serial
links
5.01. 低速連続のリンクへのRFC1144Compressing 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ヘッダーのために同様のアルゴリズムで既に重要な仕事をしました。
5.02. RFC 1323 TCP Extensions for High Performance
5.02. 高性能のためのRFC1323TCP拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.03. RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)
5.03. 青白いメディアの上をIPXヘッダーに圧縮するRFC1553(CIPX)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.04. RFC 1692 Transport Multiplexing Protocol (TMux)
5.04. RFC1692輸送マルチプレクシングプロトコル(TMux)
Section 6. Implementation Notes is states:
セクション6。 実装Notesは州です:
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値あたり1つ。
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. RFC1831RPC: 遠隔手続き呼び出しプロトコル仕様バージョン2RPC
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 11] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[11ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.06. RFC 1833 Binding Protocols for ONC RPC Version 2
5.06. ONC RPCバージョン2のためのRFC1833の拘束力があるプロトコル
In Section 2.1 RPCBIND Protocol Specification (in RPC Language)
there is the following code fragment:
セクション2.1 RPCBINDプロトコルSpecification(RPC Languageの)に、以下のコード断片があります:
* 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 "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"
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扶養家族であることが明確に見えるのは、明確です。
5.07. RFC 1962 The PPP Compression Control Protocol (CCP)
5.07. RFC1962ppp圧縮制御プロトコル(CCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.08. RFC 2018 TCP Selective Acknowledgement Options
5.08. RFC2018のTCPの選択している承認オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.09. RFC 2029 RTP Payload Format of Sun's CellB Video Encoding
5.09. SunのCellBビデオのコード化のRFC2029RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 12] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[12ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.10. RFC 2032 RTP Payload Format for H.261 Video Streams
5.10. H.261ビデオストリームのためのRFC2032RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.11. RFC 2126 ISO Transport Service on top of TCP (ITOT)
5.11. TCPの上のRFC2126ISO Transport Service(ITOT)
This specification is IPv6 aware and has no issues.
この仕様は、IPv6意識していて、子種がありません。
5.12. RFC 2190 RTP Payload Format for H.263 Video Streams
5.12. H.263ビデオストリームのためのRFC2190RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.13. RFC 2198 RTP Payload for Redundant Audio Data
5.13. 余分なオーディオデータのためのRFC2198RTP有効搭載量
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.14. RFC 2205 Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification
5.14. RFC2205資源予約プロトコル(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の依存が全くありません。
5.15. RFC 2207 RSVP Extensions for IPSEC Data Flows
5.15. IPSECデータフローのためのRFC2207RSVP拡張子
The defined IPsec extensions are valid for both IPv4 & IPv6.
There are no IPv4 dependencies in this specification.
IPv4とIPv6の両方に、定義されたIPsec拡張子は有効です。 この仕様に基づくIPv4の依存が全くありません。
5.16. RFC 2210 The Use of RSVP with IETF Integrated Services
5.16. IETFの統合サービスとのRSVPのRFC2210使用
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.17. RFC 2211 Specification of the Controlled-Load Network
Element Service
5.17. 制御負荷ネットワーク要素サービスのRFC2211仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.18. RFC 2212 Specification of Guaranteed Quality of Service
5.18. 保証されたサービスの質のRFC2212仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 13] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[13ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.19. RFC 2215 General Characterization Parameters for
Integrated Service Network Elements
5.19. 統合サービスネットワークElementsへのRFC2215一般的性質パラメタ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.20. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
5.20. MPEG1/MPEG2ビデオのためのRFC2250RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.21. RFC 2326 Real Time Streaming Protocol (RTSP)
5.21. RFC2326のリアルタイムのストリーミングのプロトコル(RTSP)
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:」、)、」 RFCのセクション2.1によって1123円定義されるようにIPの<のA法的なインターネット」 ホスト[「:」 ポート][腹筋_経路]ホスト=ホスト・ドメイン名が扱う(ドット付き10進法フォームで)//は*>が移植するrfc1123=ケタを引用します。
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]).
可能であるときはいつも、IPアドレスでは、URL SHOULDで避けられてください。使用、(RFC1924[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/シューシューという音/foo RTSP/1.0CSeq: 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はCSeqを承認します: 312 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のコンテントタイプ: sdp Contentアプリケーション/長さ: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
セッション記述プロトコルのv=0 o=mhandley2890844526 2890842807IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar
Nesser II & Bergstrom Informational [Page 14] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[14ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
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
2873397496 2873404696a=recvonly mjh@isi.edu (マークハンドレー)c=IN IP4 224.2.17.12/127u= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=t=mが31mの3456年の0mのオーディオRTP/AVP=ビデオ2232RTP/AVP=ホワイトボードと等しい、32416UDP WB a、= : 肖像を適応させてください。
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 RFC2327について説明できるプロトコルにおける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.
IPv6の、しかし、確かに唯一のサポートが制限したメディア記述プロトコルがケースを使用する限り、IPv6の上でRTSPを使用できます。 完全な機能性のために、IPv6サポートの必要があります。 必要であるアップデートの量は少です。
5.22. RFC 2327 SDP: Session Description Protocol (SDP)
5.22. RFC2327SDP: セッション記述プロトコル(SDP)
This specification is under revision, and IPv6 support was added
in RFC 3266 which updates this specification.
この仕様は改正中でありました、そして、IPv6サポートはこの仕様をアップデートするRFC3266で加えられました。
5.23. RFC 2380 RSVP over ATM Implementation Requirements
5.23. 気圧実装要件の上のRFC2380RSVP
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. 気圧との制御負荷サービスと保証されたサービスのRFC2381Interoperation
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. 1998年のITU-T RecのバージョンのためのRFC2429RTP有効搭載量形式。 H.263ビデオ(H.263+)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.26. RFC 2431 RTP Payload Format for BT.656 Video Encoding
5.26. BT.656ビデオのコード化のためのRFC2431RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 15] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[15ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.27. RFC 2435 RTP Payload Format for JPEG-compressed Video
5.27. JPEGによって圧縮されたビデオのためのRFC2435RTP有効搭載量形式
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分野)のRFC2474定義
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. 低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮するRFC2508
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.30. RFC 2581 TCP Congestion Control
5.30. RFC2581TCP輻輳制御
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.31. RFC 2597 Assured Forwarding PHB Group
5.31. RFC2597相対的優先転送PHBグループ
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.32. RFC 2658 RTP Payload Format for PureVoice(tm) Audio
5.32. PureVoice(tm)オーディオのためのRFC2658RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.33. RFC 2678 IPPM Metrics for Measuring Connectivity
5.33. 測定の接続性のためのRFC2678IPPM測定基準
This specification only supports IPv4.
この仕様はIPv4をサポートするだけです。
5.34. RFC 2679 A One-way Delay Metric for IPPM
5.34. IPPMにおける、メートル法のRFC2679A One-道の遅れ
This specification only supports IPv4.
この仕様はIPv4をサポートするだけです。
5.35. RFC 2680 A One-way Packet Loss Metric for IPPM
5.35. IPPMにおける、メートル法のRFC2680A One-道のパケット損失
This specification only supports IPv4.
この仕様はIPv4をサポートするだけです。
5.36. RFC 2681 A Round-trip Delay Metric for IPPM
5.36. IPPMにおける、メートル法の往復の遅れあたりRFC2681
This specification only supports IPv4.
この仕様はIPv4をサポートするだけです。
5.37. RFC 2730 Multicast Address Dynamic Client Allocation Protocol
(MADCAP)
5.37. RFC2730のマルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)です。
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
Nesser II & Bergstrom Informational [Page 16] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[16ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.38. RFC 2733 An RTP Payload Format for Generic Forward Error
Correction
5.38. ジェネリック前進型誤信号訂正のためのRTP有効搭載量形式あたりRFC2733
This specification is dependent on SDP which has IPv4
dependencies. Once that limitation is fixed, then this
specification should support IPv6.
この仕様はIPv4の依存を持っているSDPに依存しています。 一度その制限が固定されている、そして、この仕様はIPv6をサポートするべきです。
5.39. RFC 2745 RSVP Diagnostic Messages
5.39. RFC2745RSVP診断メッセージ
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.40. RFC 2746 RSVP Operation Over IP Tunnels
5.40. IP Tunnelsの上のRFC2746RSVP操作
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.41. RFC 2750 RSVP Extensions for Policy Control
5.41. 方針コントロールのためのRFC2750RSVP拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.42. RFC 2793 RTP Payload for Text Conversation
5.42. テキストの会話のためのRFC2793RTP有効搭載量
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. RFC2814SBM(サブネット帯域幅マネージャ): IEEEの802スタイルのネットワークの上のRSVPベースのAdmission Controlのためのプロトコル
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.
まさしくずさんな言葉遣いであるかもしれません。 恐らく、テキストをはっきりさせる短いドキュメントは適切です。
5.44. RFC 2815 Integrated Service Mappings on IEEE 802 Networks
5.44. RFC2815はIEEE802ネットワークに関するサービス対応表を統合しました。
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ケタ、電話トーン、および電話信号のためのRFC2833RTP有効搭載量
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 17] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[17ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.46. RFC 2848 The PINT Service Protocol: Extensions to SIP and
SDP for IP Access to Telephone Call Services
5.46. RFC2848パイントサービスプロトコル: 通話サービスへのIPアクセスのためのちびちび飲む拡大と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をサポートするべきです。
5.47. RFC 2862 RTP Payload Format for Real-Time Pointers
5.47. リアルタイムの指針のためのRFC2862RTP有効搭載量形式
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との使用のための2872年のRFCアプリケーションと潜水艦アプリケーションアイデンティティ方針要素
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.49. RFC 2873 TCP Processing of the IPv4 Precedence Field
5.49. IPv4先行分野のRFC2873TCP処理
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. TCPのための選択している承認(袋)オプションへの1拡大あたりRFC2883
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.51. RFC 2907 MADCAP Multicast Scope Nesting State Option
5.51. RFC2907の向こう見ずなマルチキャスト範囲巣篭もり州のオプション
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.52. RFC 2960 Stream Control Transmission Protocol
5.52. RFC2960ストリーム制御伝動プロトコル
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.53. RFC 2961 RSVP Refresh Overhead Reduction Extensions
5.53. RFC2961RSVPは全般的な減少拡大をリフレッシュします。
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.54. RFC 2976 The SIP INFO Method
5.54. RFC2976一口インフォメーションメソッド
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.55. RFC 2988 Computing TCP's Retransmission Timer
5.55. TCPの再送信タイマーを計算するRFC2988
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 18] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[18ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.56. RFC 2996 Format of the RSVP DCLASS Object
5.56. RSVP DCLASSオブジェクトのRFC2996形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.57. RFC 2997 Specification of the Null Service Type
5.57. ヌルサービスタイプのRFC2997仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.58. RFC 3003 The audio/mpeg Media Type
5.58. RFC3003オーディオ/mpegメディアType
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.59. RFC 3006 Integrated Services in the Presence of
Compressible Flows
5.59. RFC3006は圧縮性の流れがあるときサービスを統合しました。
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つのオーディオの、または、視覚のストリームのためのRFC3016RTP有効搭載量形式
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. インターネットプロトコルのために示すQ.2957のQ.2941ジェネリック識別子とユーザからユーザの情報フィールドとプロトコル識別子のRFC3033課題
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.62. RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit
5.62. 株式会社を使用することでTCPの損失回復を機能アップするRFC3042が伝わります。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.63. RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1
5.63. ITU-T推薦G.722.1のためのRFC3047RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.64. RFC 3057 ISDN Q.921-User Adaptation Layer
5.64. RFC3057ISDN Q.921-ユーザ適合層
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 19] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[19ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.65. RFC 3095 Robust Header Compression (ROHC): Framework and four
profiles
5.65. RFC3095の体力を要しているヘッダー圧縮(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. Session記述プロトコル(SDP)のATM Bearerコネクションズの使用のためのRFC3108Conventions
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>による中で言い表されて、普通のドット付き10進法IPが、0.0からの表現が.0であると.0〜255.255に扱うということです。.255 .255。
and
そして
<rtcpIPaddr> IP address for receipt Dotted decimal,
7-15 chars of RTCP packets
RTCPパケットの領収書Dotted10進の7-15の雑用のための<rtcpIPaddr>IPアドレス
5.67. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio
5.67. MP3オーディオのための、より損失許容性があるRTP有効搭載量形式あたりRFC3119
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.68. RFC 3124 The Congestion Manager
5.68. RFC3124混雑マネージャ
This document is IPv4 limited since it uses the IPv4 TOS header
field.
このドキュメントはIPv4 TOSヘッダーフィールドを使用するので制限されたIPv4です。
5.69. RFC 3140 Per Hop Behavior Identification Codes
5.69. ホップ振舞い識別コードあたりのRFC3140
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.70. RFC 3173 IP Payload Compression Protocol (IPComp)
5.70. RFC3173IP有効搭載量圧縮プロトコル(IPComp)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.71. RFC 3181 Signaled Preemption Priority Policy Element
5.71. RFC3181は先取り優先権方針要素に合図しました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 20] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[20ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
5.72. RFC 3182 Identity Representation for RSVP
5.72. RSVPのRFC3182アイデンティティ表現
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.73. RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)
5.73. 完全優先転送PHBあたりRFC3246(1ホップあたりの振舞い)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.74. RFC 3261 SIP: Session Initiation Protocol
5.74. RFC3261はちびちび飲みます: セッション開始プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.75. RFC 3262 Reliability of Provisional Responses in Session
Initiation Protocol (SIP)
5.75. セッション開始プロトコルの暫定的な応答のRFC3262の信頼性(一口)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.76. RFC 3263 Session Initiation Protocol (SIP): Locating SIP
Servers
5.76. RFC3263セッション開始プロトコル(一口): 一口サーバの場所を見つけます。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.77. RFC 3264 An Offer/Answer Model with Session Description
Protocol (SDP)
5.77. セッション記述プロトコルがある申し出/答えモデルあたりRFC3264(SDP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.78. RFC 3265 Session Initiation Protocol (SIP)-Specific Event
Notification
5.78. RFC3265セッション開始プロトコル(一口)特定のイベント通知
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.79. RFC 3390 Increasing TCP's Initial Window
5.79. TCPの初期の窓を増強するRFC3390
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.80. RFC 3525 Gateway Control Protocol Version 1
5.80. RFC3525ゲートウェイ制御プロトコルバージョン1
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.81. RFC 3544 IP Header Compression over PPP
5.81. pppの上のRFC3544IPヘッダー圧縮
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 21] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[21ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
6.0. Experimental RFCs
6.0. 実験的なRFCs
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.
実験的なRFCsはインターネットにwidescale実装か用法を持っていないプロトコルを通常定義します。 しばしばそれらは限られたアリーナで自然か中古の正当です。 それらは、潜在的相互運用性かある他の潜在的役に立つシナリオを許容するためにインターネットコミュニティに記録されます。 いくつかの場合では、それらは主流のソリューションへの代替手段として承認された問題に提示されます。
6.1. RFC 908 Reliable Data Protocol (RDP)
6.1. RFC908確実な資料プロトコル(RDP)
This document is IPv4 limited as stated in the following section:
このドキュメントは以下のセクションで述べられているように制限されたIPv4です:
4.1. IP Header Format
4.1. IPヘッダー形式
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.
インターネット環境で使用すると、RDPセグメントにRFC791、「インターネットプロトコル」で説明されるようにバージョン4IPヘッダーを使用させます。 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. RFC938インターネットReliable Transactionプロトコル機能的、そして、インタフェース仕様(IRTP)
This specification states:
この仕様は以下を述べます。
4.1. State Variables
4.1. 州の変数
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)
レム_addr(32ビットのリモートインターネットアドレス)
A new specification that is IPv6 aware would need to be created.
IPv6意識している新しい仕様は、作成される必要があるでしょう。
Nesser II & Bergstrom Informational [Page 22] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[22ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
6.03. RFC 998 NETBLT: A bulk data transfer protocol
6.03. RFC998NETBLT: バルク・データ転送プロトコル
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がアドレシングであるとサポートするように容易に変更できました。
6.04. RFC 1045 VMTP: Versatile Message Transaction Protocol
6.04. RFC1045VMTP: 多能なメッセージトランザクションプロトコル
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の初期の使用のために、Domain識別子1は以下の通りで私たちはドメインを定義します:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器| インターネットアドレス| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
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.
インターネット・アドレスはこの実体イドが元々割り当てられるホストのインターネット・アドレスです。 Discriminatorはこのインターネットホスト・アドレスに比例してユニークな任意の値です。 さらに、ホストは、無効になった長い年月の間後にこの識別子が再利用されないのを保証しなければなりません。 (どんなVMTPモジュールも考えない「無効」の手段は実体にバウンドしています。) 1つのテクニックは1 2番目のビットが時間を計る下層階級を使用することです。 しかし、時計が表す必要はない、リアルタイムで、クラッシュの後に決して遅らせてはいけません。 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.
実体はホストの間を移住するかもしれません。 したがって、缶がキャッシュを維持するのに、実体の場所を見つけるように扱いますが、インターネットが準備されるべきである埋め込みを発見的に使用する実装は、移行が起こったのを示すNotify操作を、移行した実体のために向け直して、受け入れます。
Nesser II & Bergstrom Informational [Page 23] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[23ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
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:
Domain1の実体グループ識別子は2つのフォームの1つで構造化されます、それらがよく知られるかダイナミックに割り当てられた識別子であるかどうかによって。 よく知られるエンティティ識別名は以下として構造化されます。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器|インターネットホストグループAddr| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
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.
2番目の高位のビットで、(GRP)は1にセットしました。 このフォームに関するエンティティ識別名は下位の32ビットで指定されたインターネット・ホストグループアドレスに写像されます。 Discriminatorは、同じインターネット・ホストグループを使用することでグループ識別子を区別します。 グループのメンバーであるホストによって提供された基本サービスに相当するようによく知られる実体グループ識別子を割り当てるべきです、そのサービスがVMTPによって明確にない提供されるので。 例えば、ドメイン名サービスのためのよく知られる実体グループ識別子は埋め込まれたインターネット・ホストグループアドレスとしてDomain Nameサーバのためのホストグループを含むべきです。
A dynamically allocated entity identifier is structured as:
ダイナミックに割り当てられたエンティティ識別名は以下として構造化されます。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器| インターネットホストAddr| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
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.
2番目の高位のビットで、(GRP)は1にセットしました。 下位の32ビットのインターネット・アドレスはダイナミックにこの実体グループ識別子を割り当てるホストに割り当てられたインターネット・アドレスです。 ダイナミックに割り当てられた実体グループ識別子はX.X.Xが実体グループ識別子のDiscriminator部分体の下位の24ビットであるインターネット・ホストグループアドレス232.X.X.Xに写像されます。
We use the following notation for Domain 1 entity identifiers
<10> and propose it use as a standard convention.
それを提案してください。そして、私たちがDomain1エンティティ識別名<に以下の記法を使用する、10>、一般的なコンベンションとして、使用します。
<flags>-<discriminator>-<Internet address>
<が>に旗を揚げさせる、-、インターネットが>を扱う<弁別器>-<。
Nesser II & Bergstrom Informational [Page 24] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[24ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
where <flags> are [X]{BE,LE,RG,UG}[A]
<がどこで>に旗を揚げさせるかが、[X]である、LE、RG、UG[A]
X = reserved
BE = big-endian entity
LE = little-endian entity
RG = restricted group
UG = unrestricted group
A = alias
無制限な=ビッグエンディアン実体LE=リトルエンディアン実体RG=制限されたグループUG=グループAが=別名であったなら予約されたX=
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
+---------------------------+------------------------+ | インターネットアドレス| ローカルユーザー識別子| +---------------------------+------------------------+ 32ビット32ビット
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_マネージャ_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 BE1-224.0.1.0Clientエンティティ識別名は決定しないか、または少しのクライアントエンティティ識別名も割り当てられていません。
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 Clientエンティティ識別名は決定しないか、または少しのクライアントエンティティ識別名も割り当てられていません。
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ホストが属する。
6.05. RFC 1146 TCP alternate checksum options
6.05. RFC1146のTCPの代替のチェックサムオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 25] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[25ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
6.06. RFC 1151 Version 2 of the Reliable Data Protocol (RDP)
6.06. 確実な資料プロトコルのRFC1151バージョン2(RDP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.07. RFC 1644 T/TCP -- TCP Extensions for Transactions Functional
Specification
6.07. RFC1644T/TCP--、トランザクションに、機能的なTCP拡張子、仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.08. RFC 1693 An Extension to TCP : Partial Order Service
6.08. TCPへの1拡大あたりRFC1693: 部分的なオーダーサービス
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.09. RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
6.09. 固定経路MTUとのIPXネットワークの上のRFC1791TCPとUDP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.10. RFC 2343 RTP Payload Format for Bundled MPEG
6.10. 添付されたMPEGのためのRFC2343RTP有効搭載量形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.11. RFC 2582 The NewReno Modification to TCP's Fast Recovery
Algorithm
6.11. TCPの速い回復アルゴリズムへのRFC2582NewReno変更
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.12. RFC 2762 Sampling of the Group Membership in RTP
6.12. RTPのグループ会員資格のRFC2762標本抽出
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.13. RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
6.13. 時間引窓Three色のマーカーあたりRFC2859(TSWTCM)
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.14. RFC 2861 TCP Congestion Window Validation
6.14. RFC2861TCP混雑窓の合法化
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.15. RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
6.15. RFC2909マルチキャストアドレスセットクレーム(MASC)プロトコル
This specification is both IPv4 and IPv6 aware and needs no
changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
Nesser II & Bergstrom Informational [Page 26] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[26ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
7.0. Summary of Results
7.0. 結果の概要
In the initial survey of RFCs 24 positives were identified out of a total of 104, broken down as follows:
RFCs24の初期の調査では、正数は合計以下の通り破壊された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%
規格: 5%か60.00%のうちの3は規格を作成します: 2%か0.00%のうちの0は規格を提案しました: 82のうちの17か20.73%の実験的なRFCs: 4 15%か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.
多く特定されたものでは、彼らが時代遅れの、そして、未使用のプロトコルを記録するので、動作を全く必要としないでください、他のものは適切なワーキンググループによって活発にアップデートされているドキュメントプロトコルですが。 規格の多くのインスタンスがさらに、あります。SHOULDはアップデートしますが、それらをアップデートしないなら、どんな操作上の影響も引き起こしません。 残っているインスタンスは以下に記録されます。
7.1. Standards
7.1. 規格
7.1.1. STD 7 Transmission Control Protocol (RFC 793)
7.1.1. STD7通信制御プロトコル(RFC793)
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チェックサムを計算するためのテクニックを定義します。 この問題はRFC2460セクション8.1で扱われます。
7.1.2. STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002)
7.1.2. TCP/UDPの上のSTD19Netbios(RFCs1001と1002)
These two RFCs have many inherent IPv4 assumptions and a new set
of protocols must be defined.
これらの2RFCsには、多くの固有のIPv4仮定があります、そして、新しいセットのプロトコルを定義しなければなりません。
7.1.3. STD 35 ISO Transport over TCP (RFC 1006)
7.1.3. TCPの上のSTD35ISO輸送(RFC1006)
This problem has been fixed in RFC 2126, ISO Transport Service on
top of TCP.
RFC2126、TCPの上のISO Transport Serviceでこの問題を修正してあります。
7.2. Draft Standards
7.2. 草稿規格
There are no draft standards within the scope of this document.
このドキュメントの範囲の中に草稿規格が全くありません。
7.3. Proposed Standards
7.3. 提案された標準
7.3.01. TCP/IP Header Compression over Slow Serial Links (RFC 1144)
7.3.01. 遅い連続のリンクの上のTCP/IPヘッダー圧縮(RFC1144)
This problem has been resolved in RFC2508, Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509.
この問題はRFC2508で解決されて、Low-速度のためのCompressing IP/UDP/RTP HeadersはSerialリンクスです。 また、RFC2507とRFC2509を見てください。
Nesser II & Bergstrom Informational [Page 27] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[27ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
7.3.02. ONC RPC v2 (RFC 1833)
7.3.02. ONC RPC v2(RFC1833)
The problems can be resolved with a definition of the NC_INET6
protocol family.
NC_INET6プロトコルファミリーの定義で問題を解決できます。
7.3.03. RTSP (RFC 2326)
7.3.03. RTSP(RFC2326)
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開発者グループによって承認されて、ProposedからDraft Standardまでの移動で扱われるでしょう。 また、この問題はRFC2732、URLのIPv6 Literal Addressesで扱われます。
7.3.04. SDP (RFC 2327)
7.3.04. SDP(RFC2327)
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.
1つの問題がRFC2732、URLのIPv6 Literal Addressesで扱われます。 小さい方の原文の明確化でもう片方の問題を扱うことができます。 ProposedからDraftまでの変遷にドキュメントがあるなら、これをしなければなりません。 これらの問題は中の現在、Auth48かIESGが議論するドキュメントによって解決されています。
7.3.05. IPPM Metrics (RFC 2678)
7.3.05. IPPM測定基準(RFC2678)
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題を解決するために働いています。
7.3.06. IPPM One Way Delay Metric for IPPM (RFC 2679)
7.3.06. IPPMにおける、メートル法のIPPM一方通行の遅れ(RFC2679)
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)。
7.3.07. IPPM One Way Packet Loss Metric for IPPM (RFC 2680)
7.3.07. IPPMにおける、メートル法のIPPM一方通行のパケット損失(RFC2680)
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題を解決するために働いています。
7.3.09. Round Trip Delay Metric for IPPM (RFC 2681)
7.3.09. IPPMにおける、メートル法の周遊旅行遅れ(RFC2681)
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アクセスのためのちびちび飲む拡大とSDP(RFC2848)
This specification is dependent on SDP which has IPv4
dependencies. Once these limitations are fixed, then this
protocol should support IPv6.
この仕様はIPv4の依存を持っているSDPに依存しています。 一度これらの制限が固定されている、そして、このプロトコルはIPv6をサポートするべきです。
7.3.09. TCP Processing of the IPv4 Precedence Field (RFC 2873)
7.3.09. IPv4先行分野のTCP処理(RFC2873)
The problems are not being addressed.
問題は扱われていません。
Nesser II & Bergstrom Informational [Page 28] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[28ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
7.3.10. Integrated Services in the Presence of Compressible Flows
(RFC 3006)
7.3.10. 圧縮性の流れがあるとき統合サービス(RFC3006)
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の圧縮性の流れが定義されるとき、同様のテクニックは定義されるべきです。
7.3.11. SDP For ATM Bearer Connections (RFC 3108)
7.3.11. 気圧運搬人コネクションズのためのSDP(RFC3108)
The problems are not being addressed, but it is unclear whether
the specification is being used.
問題は扱われていませんが、仕様が使用されているかどうかが、不明瞭です。
7.3.12. The Congestion Manager (RFC 3124)
7.3.12. 混雑マネージャ(RFC3124)
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 Traffic Class分野の使用を定義することであるかもしれません。
7.4. Experimental RFCs
7.4. 実験的なRFCs
7.4.1. Reliable Data Protocol (RFC 908)
7.4.1. 確実な資料プロトコル(RFC908)
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. インターネットReliable Transactionプロトコル機能的、そして、インタフェース仕様(RFC938)
This specification relies on IPv4 and a new protocol standard may
be produced.
この仕様はIPv4を当てにします、そして、新しいプロトコル標準は生産されるかもしれません。
7.4.3. NETBLT: A bulk data transfer protocol (RFC 998)
7.4.3. NETBLT: バルク・データ転送プロトコル(RFC998)
This specification relies on IPv4 and a new protocol standard may
be produced.
この仕様はIPv4を当てにします、そして、新しいプロトコル標準は生産されるかもしれません。
7.4.4. VMTP: Versatile Message Transaction Protocol (RFC 1045)
7.4.4. VMTP: 多能なメッセージトランザクションプロトコル(RFC1045)
This specification relies on IPv4 and a new protocol standard may
be produced.
この仕様はIPv4を当てにします、そして、新しいプロトコル標準は生産されるかもしれません。
7.4.5. OSPF over ATM and Proxy-PAR (RFC 2844)
7.4.5. 気圧でのOSPFとプロキシ平価(RFC2844)
This specification relies on IPv4 and a new protocol standard may
be produced.
この仕様はIPv4を当てにします、そして、新しいプロトコル標準は生産されるかもしれません。
Nesser II & Bergstrom Informational [Page 29] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[29ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
8.0. Security Considerations
8.0. セキュリティ問題
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは仕様のIPv6-準備を調べます。 これには、本来、セキュリティ問題がありません。
9.0. Acknowledgements
9.0. 承認
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に感謝したがっています。 彼はこのドキュメントの諸点の有益なフィードバックについてさらにアリソン・マンキン、マグヌスWesterlund、およびコリン・パーキンスに感謝したがっています。
10.0. Normative Reference
10.0. 引用規格
[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.ベルイストローム、エディタ、「IPv4の調査への紹介は現在配布しているIETFで規格を扱います」、RFC3789、2004年6月。
11.0. Authors' Addresses
11.0. 作者のアドレス
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第100Ave Ne、#5202カークランド、98034
Phone: +1 425 481 4303 Fax: +1 425 48 EMail: phil@nesser.com
以下に電話をしてください。 +1 425 481、4303Fax: +1 425 48 メール: 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
Nesser II & Bergstrom Informational [Page 30] RFC 3794 IPv4 Addresses in the IETF Transport Area June 2004
IETFのNesser IIとベルイストローム情報[30ページ]のRFC3794IPv4Addressesは2004年6月に領域を輸送します。
12.0. Full Copyright Statement
12.0. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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機能のための基金は現在、インターネット協会によって提供されます。
Nesser II & Bergstrom Informational [Page 31]
Nesser IIとベルイストロームInformationalです。[31ページ]
一覧
スポンサーリンク
