RFC 3792 - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents 日本語訳

URL : https://tools.ietf.org/html/rfc3792
タイトル : RFC 3792 - IPv4の調査は、現在展開IETFセキュリティエリア標準化過程と実験ドキュメント内のアドレス
翻訳編集 : 自動生成

Network Working Group                                      P. Nesser, II
Request for Comments: 3792                    Nesser & Nesser Consulting
Category: Informational                                A. Bergstrom, Ed.
                                              Ostfold University College
                                                               June 2004

            Survey of IPv4 Addresses in Currently Deployed
     IETF Security 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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。

Abstract

抽象

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security 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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Document Organisation. . . . . . . . . . . . . . . . . . . . .  2
   3.  Full Standards . . . . . . . . . . . . . . . . . . . . . . . .  2
   4.  Draft Standards. . . . . . . . . . . . . . . . . . . . . . . .  2
   5.  Proposed Standards . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Summary of Results . . . . . . . . . . . . . . . . . . . . . . 22
       7.1.  Standards. . . . . . . . . . . . . . . . . . . . . . . . 23
       7.2.  Draft Standards. . . . . . . . . . . . . . . . . . . . . 23
       7.3.  Proposed Standards . . . . . . . . . . . . . . . . . . . 23
       7.4.  Experimental RFCs. . . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 24
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24

   10. Normative Reference. . . . . . . . . . . . . . . . . . . . . . 24
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25

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 and Management, Routing, Security, Sub-IP, and Transport).

この文書は、IETF標準でIPv4アドレスのすべての使用を文書化することを目指し、文書セットの一部です。管理しやすい形式で情報を持っているための努力では、現在IETFエリア（アプリケーション、インターネット、運用管理、ルーティング、セキュリティ、サブIP、および交通）に準拠した7つの文書に分割されています。

For a full introduction, please see the introduction [1].

完全な概要については、導入[1]を参照してください。

2.0. Document Organization

2.0. マニュアルの構成

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。

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.

（最も一般的に、単に「基準」という。）のフルインターネット規格は広く実装し、インターネット全体で使用されている完全に成熟したプロトコル仕様です。

3.1. A One-Time Password System

3.1. ワンタイムパスワードシステム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

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.

ドラフト規格は、IETFにおける最後から二番目の標準レベルを表します。プロトコルは、複数の独立した、相互運用可能な実装がある場合にドラフト標準を達成することができます。ドラフト規格は通常、非常に成熟し、広く使用されています。

4.1. The Content-MD5 Header Field

4.1. コンテンツ-MD5ヘッダーフィールド

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

4.2. HTTP Authentication: Basic and Digest Access Authentication

4.2. HTTP認証：基本とダイジェストアクセス認証

      Section 3.2.1 The WWW-Authenticate Response Header include he
      following text:

(Note: including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard.)

（注：プロキシファームを破るただし、サーバーにもともとそれを得た同じクライアントへのナンスの再利用を制限する機能を提供するように思われるナンスで、クライアントのIPアドレス、単一の要求を含みますユーザーは、多くの場合、ファーム内の別のプロキシを通過します。また、IPスプーフィングは難しいことではありません。）

Section 4.5 Replay Attacks contains the text:

4.5節リプレイ攻撃のテキストが含まれています。

Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a time-stamp, the resource ETag, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which does not maintain state between transactions.

このように、いくつかの目的のために、リプレイ攻撃から保護する必要があります。良いダイジェスト実装は、さまざまな方法でこれを行うことができます。サーバー作成された「ナンス」値は実装に依存するが、（上記の推奨のように）、それは、クライアントのIP、タイムスタンプ、リソースのETag、およびプライベートサーバキーのダイジェストが含まれているならば、リプレイ攻撃は簡単ではありません。攻撃者は、要求が偽のIPアドレスから来ていると、サーバは、それが文書を送信していると考えているためにアドレスとは異なるIPアドレスに文書を届けるために起こす必要があるサーバーを説得しなければなりません。タイムスタンプの有効期限が切れる前に攻撃が期間だけで成功することができます。ナンスで、クライアントのIPおよびタイムスタンプを消化することは、トランザクション間の状態を維持しない実装が可能になります。

Both of these statements are IP version independent and must rely on the implementers discretion.

これらのステートメントの両方がIPバージョン独立しており、実装者の裁量に依存する必要があります。

4.3. Remote Authentication Dial In User Service (RADIUS)

4.3. ユーザーサービス（RADIUS）でリモート認証ダイヤル

Section 3. Packet Format has the following notes:

第3節パケットフォーマットは以下の点に注意してください。

Identifier

識別

The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.

識別子フィールドは1つのオクテットであり、要求と応答のマッチングを助けます。それは時間の短いスパン内の同じクライアントの送信元IPアドレスと送信元UDPポートと識別子を持っている場合、RADIUSサーバは、重複要求を検出することができます。

and

そして

A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.

RADIUS要求をプロキシできるように、RADIUSサーバは、使用する秘密を共有したかを決定するためにRADIUS UDPパケットの送信元IPアドレスを使用する必要があります。

This text is version neutral but implementers should allow for the use of both IPv4 and IPv6 addresses.

このテキストは、バージョン中性であるが、実装者は、IPv4とIPv6の両方のアドレスを使用することを可能にする必要があります。

Section 5. Attributes defines a number of IP specific attributes:

第5節属性は、IP特定の属性の数を定義します。

             4      NAS-IP-Address
             8      Framed-IP-Address
             9      Framed-IP-Netmask
            10      Framed-Routing
            14      Login-IP-Host
            22      Framed-Route

and definitions for the "value" field of the following type:

以下のタイプの「値」フィールドの定義と：

address 32 bit value, most significant octet first.

最初の32ビット値、最も重要なオクテットに取り組みます。

The attributes are further defined as follows:

次のように属性がさらに定義されています。

5.4. NAS-IP-Address

5.4. NAS-IP-アドレス

Description

説明

This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP-Address is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet.

この属性は、ユーザーの認証を要求しているNASの特定IPアドレスを示し、RADIUSサーバの範囲内でNASに一意である必要があります。 NAS-IP-addressが唯一のAccess-Requestパケットで使用されています。 NAS-IP-アドレスまたはNAS-IDのいずれかがアクセス要求パケット中に存在しなければなりません。

Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret.

NAS-IP-Addressは要求を認証するために使用される共有秘密を選択するために使用してはいけないことに注意してください。アクセス要求パケットの送信元IPアドレスは、共有秘密鍵を選択するために使用されなければなりません。

A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right.

NAS-IP-Address属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。

     0                   1                   2                   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      |    Length     |            Address
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Address (cont)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

タイプ

4 for NAS-IP-Address.

NAS-IP-addressには4。

Length

長さ

６

Address

住所

The Address field is four octets.

アドレスフィールドは4つのオクテットです。

5.8. Framed-IP-Address

5.8. フレームを選ぶ-IP-アドレス

Description

説明

This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint.

この属性は、ユーザーのために設定されるアドレスを示しています。これは、接続許可パケットで使用されるかもしれません。それは、それがそのアドレスを好むだろうサーバへのNASによってヒントとしてのAccess-Requestパケットで使用されるかもしれないが、サーバーはヒントを尊重する必要はありません。

A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right.

Framed-IP-Addressアトリビュートのフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。

    0                   1                   2                   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      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

タイプ

8 for Framed-IP-Address.

フレームを選ぶ-IP-addressには8。

Length

長さ

６

Address

住所

The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g., Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g., Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address.

アドレスフィールドは4つのオクテットです。値は0xFFFFFFFFは、NASは、ユーザがアドレス（例えば、ネゴシエーション）を選択することを可能にする必要があることを示しています。値0xFFFFFFFEは、NAS（例えば、NASによって維持アドレスのプールから割り当てられている）ユーザのアドレスを選択すべきであることを示しています。他の有効な値は、NASは、ユーザーのIPアドレスとしてその値を使用する必要があることを示しています。

5.9. Framed-IP-Netmask

5.9. フレームを選ぶ-IP-ネットマスク

Description

説明

This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint.

この属性は、ユーザがネットワークへのルータであるときに、ユーザーのために設定されるIPネットマスクを示します。これは、接続許可パケットで使用されるかもしれません。それは、それがそのネットマスクを好むだろうサーバへのNASによってヒントとしてのAccess-Requestパケットで使用されるかもしれないが、サーバーはヒントを尊重する必要はありません。

A summary of the Framed-IP-Netmask Attribute format is shown below. The fields are transmitted from left to right.

Framed-IP-Netmask属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。

    0                   1                   2                   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      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

タイプ

9 for Framed-IP-Netmask.

フレームを選ぶ-IP-ネットマスクのために9。

Length

長さ

６

Address

住所

The Address field is four octets specifying the IP netmask of the user.

アドレスフィールドには、ユーザーのIPネットマスクを指定する4つのオクテットです。

5.14. Login-IP-Host

5.14. ログイン-IP-ホスト

Description

説明

"This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint."

「この属性は、ログイン・サービス属性が含まれている場合、ユーザーを接続するシステムを示します。これは、Access-受け入れパケットで使用されるかもしれません。これは、サーバーへのヒントとしてのAccess-Requestパケットで使用されるかもしれNASは、そのホストを使用することを好むだろうが、サーバーはヒントを尊重する必要はありません。」

A summary of the Login-IP-Host Attribute format is shown below. The fields are transmitted from left to right.

ログイン-IP-host属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。

    0                   1                   2                   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      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

タイプ

14 for Login-IP-Host.

ログイン-IP-ホストのための14。

Length

長さ

６

Address

住所

The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to.

アドレスフィールドは4つのオクテットです。値は0xFFFFFFFFは、NASは、ユーザーがアドレスを選択できるようにする必要があることを示します。値0は、NASのにユーザを接続するホストを選択すべきであることを示しています。他の値はNASがユーザーに接続してくださいアドレスを示しています。

5.22. Framed-Route

5.22. フレームを選ぶ-ルート

Description

説明

This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times.

この属性は、NAS上のユーザのために設定されるルーティング情報を提供します。これは、接続許可パケットで使用され、複数回出現することができます。

A summary of the Framed-Route Attribute format is shown below. The fields are transmitted from left to right.

入れるルート属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

タイプ

22 for Framed-Route.

額縁・ルートのための22。

Length

長さ

>= 3

＞＝３

Text

テキスト

The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters.

テキストフィールドは1オクテット以上で、その内容は実装に依存しています。人間が読むことができるように意図されており、プロトコルの動作に影響してはいけません。メッセージがUTF-8が10646 [7]文字をコード含まれていることが推奨されます。

For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted, in which case it defaults to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".

IPルートのために、それは、必要に応じてスラッシュとプレフィックスの多くの上位ビットを使用する方法を述べ小数長さ指定に続く点線クワッド形態における宛先プレフィックスを含むべきです。すなわち空間、点線クワッド形態におけるゲートウェイアドレス、スペース、スペースで区切られた1つの以上のメトリックが続きます。例えば、 "192.168.1.0/24 192.168.1.1 1 2 -1 3 400"。長さ指定子は、クラスAのプレフィクスのための8ビット、クラスBのプレフィックスの16ビット、およびクラスC接頭語24ビット、その場合、それはデフォルトでは、省略されてもよいです。たとえば、 "192.168.1.0 192.168.1.1 1"。

Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address.

ゲートウェイアドレスが「0.0.0.0」として指定されるたびに、ユーザーのIPアドレスがゲートウェイアドレスとして使用してください。

There are also several example authentication sequences that use the attributes discussed above and hence have IPv4 addresses.

上記の属性を使用するので、IPv4アドレスを持っているいくつかの例認証シーケンスもあります。

Although the definitions in this RFC are limited to IPv4 addresses, the specification is easily extensible for new attribute types. It is therefore relatively simple to create new IPv6 specific attributes.

このRFCの定義は、IPv4アドレスに制限されていますが、仕様では、新しい属性タイプのため、容易に拡張可能です。新しいIPv6の特定の属性を作成することは比較的簡単です。

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.

提案された標準は、入門レベルの文書です。でも、単一の実装のための要件はありません。提案多くの場合、実装されることはありませんか、IETF標準化プロセスに進みました。したがって、これらは、多くの場合、インターネットコミュニティに提示されているだけで、提案のアイデアです。時には欠陥が露出したり、彼らが問題に多くの競合ソリューションの一つですされています。この後の例では、何の議論は、それがこの議論の目的を果たすないだろうと提示されていません。

5.001. RFC 1413 Identification Protocol

5.001。 RFC 1413の識別プロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.002. RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I

5.002。インターネット電子メールのためのRFC 1421のプライバシー増進：パートI

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.003. RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II

5.003。インターネット電子メールのためのRFC 1422のプライバシー増進：パートII

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.004. RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III

5.004。インターネット電子メールのためのRFC 1423のプライバシー増進：パートIII

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.005. RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV

5.005。インターネット電子メールのためのRFC 1424のプライバシー増進：パートIV

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.006. RFC 1510 The Kerberos Network Authentication Service (V5)

5.006。 RFC 1510ザ・ケルベロスネットワーク認証サービス（V5）

Although this specification specifies optional use of host addresses, there are no specific requirements that the addresses be IPv4. The specification has no IPv4 dependencies, but implementations might have issues.

この仕様は、ホストアドレスの任意の使用を指定しますが、アドレスがIPv4なる特別な要件はありません。仕様書にはIPv4の依存関係を持っていませんが、実装は問題がある可能性があります。

5.007. RFC 1731 IMAP4 Authentication Mechanisms

5.007。 RFC 1731 IMAP4認証メカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.008. RFC 1734 POP3 AUTHentication command

5.008。 RFC 1734 POP3認証コマンド

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.009. RFC 1828 IP Authentication using Keyed MD5

5.009。キー付きMD5を使用して、RFC 1828 IP認証

There are no IPv4 dependencies in this specification. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6.

この仕様にはIPv4の依存関係はありません。説明した動作は、IPパケットがIPv4またはIPv6であることを指定せずに全体のIPパケット上で動作します。

5.010. RFC 1829 The ESP DES-CBC Transform

5.010。 ESP DES-CBC変換をRFC 1829

There are no IPv4 dependencies in this specification. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6.

この仕様にはIPv4の依存関係はありません。説明した動作は、IPパケットがIPv4またはIPv6であることを指定せずに全体のIPパケット上で動作します。

5.011. RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

5.011。 MIMEのためのRFC 1847個のセキュリティマルチパート：マルチパート/署名およびマルチパート/暗号化

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.012. RFC 1848 MIME Object Security Services

5.012。 RFC 1848 MIMEオブジェクトセキュリティサービス

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.013. RFC 1928 SOCKS Protocol Version

5.013。 RFC 1928 SOCKSプロトコルバージョン

This specification is IPv6 aware and will function normally on either IPv4 and IPv6.

この仕様は、IPv6認識しており、IPv4とIPv6のいずれかに正常に機能します。

5.014. RFC 1929 Username/Password Authentication for SOCKS V5

5.014。 SOCKS V5のためのRFC 1929のユーザ名/パスワード認証

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.015. RFC 1961 GSS-API Authentication Method for SOCKS Version 5

5.015。 SOCKSバージョン5のためのRFC 1961 GSS-API認証方法

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.016. RFC 1964 The Kerberos Version 5 GSS-API Mechanism

5.016。 RFC 1964ザ・Kerberosバージョン5 GSS-APIメカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.017. RFC 1968 The PPP Encryption Control Protocol (ECP)

5.017。 RFC 1968 PPP暗号化制御プロトコル（ECP）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.018. RFC 2015 MIME Security with Pretty Good Privacy (PGP)

5.018。プリティグッドプライバシーとRFC 2015 MIMEセキュリティ（PGP）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.019. RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)

5.019。 RFC 2025シンプルな公開鍵GSS-APIメカニズム（SPKM）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.020. RFC 2082 RIP-2 MD5 Authentication

5.020。 RFC 2082 RIP-2 MD5認証

This RFC documents a security mechanism for an IPv4 only routing specification. It is expected that a similar (or better) mechanism will be developed for RIPng.

このRFCは、IPv4のみルーティング仕様のセキュリティメカニズムを説明します。同様の（またはそれ以上）のメカニズムは、RIPngのために開発されることが期待されます。

5.021. RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention

5.021。リプレイ防止とRFC 2085 HMAC-MD5 IP認証

This document defines an IP version independent specification and has no IPv4 dependencies.

この文書では、IPのバージョンに依存しない仕様を定義し、何のIPv4の依存関係を持っていません。

5.022. RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/ Response

5.022。シンプルチャレンジ/レスポンスのためのRFC 2195 IMAP / POP AUTHORIZE拡張

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.023. RFC 2203 RPCSEC_GSS Protocol Specification

5.023。 RFC 2203 RPCSEC_GSSプロトコル仕様

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.024. RFC 2222 Simple Authentication and Security Layer (SASL)

5.024。 RFC 2222簡易認証セキュリティー層（SASL）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.025. RFC 2228 FTP Security Extensions

5.025。 RFC 2228のFTPセキュリティ拡張

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.026. RFC 2243 OTP Extended Responses

5.026。 RFC 2243のOTP拡張応答

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.027. RFC 2245 Anonymous SASL Mechanism

5.027。 RFC 2245匿名SASLメカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.028. RFC 2246 The TLS Protocol Version 1.0

5.028。 RFC 2246ザ・TLSプロトコルバージョン1.0

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.029. RFC 2284 PPP Extensible Authentication Protocol (EAP)

5.029。 RFC 2284 PPP拡張認証プロトコル（EAP）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.030. RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option

5.030。 TCP MD5署名オプションを使用してBGPセッションのRFC 2385保護

Although the specification enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing specification.

仕様の拡張無しのIPv4依存性を持たないが、それは、IPv4のみ、ルーティング仕様への更新です。

5.031. RFC 2401 Security Architecture for the Internet Protocol

5.031。インターネットプロトコルのためのRFC 2401セキュリティアーキテクチャ

This specification is both IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6の両方が認識しています。

5.032. RFC 2402 IP Authentication Header

5.032。 RFC 2402 IP認証ヘッダ

This specification is both IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6の両方が認識しています。

5.033. RFC 2403 The Use of HMAC-MD5-96 within ESP and AH

5.033。 RFC 2403 ESPおよびAH内のHMAC-MD5-96の使用

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.034. RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH

5.034。 RFC 2404 ESPおよびAH内のHMAC-SHA-1-96の使用

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.035. RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV

5.035。 RFC 2405明示的なIV付ESP DES-CBC暗号アルゴリズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.036. RFC 2406 IP Encapsulating Security Payload (ESP)

5.036。 RFC 2406 IPカプセル化セキュリティペイロード（ESP）

This specification is both IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6の両方が認識しています。

5.037. RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP

5.037。 ISAKMPのための解釈のRFC 2407ザ・インターネットIPセキュリティドメイン

This specification is both IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6の両方が認識しています。

5.038. RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)

5.038。 RFC 2408インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）

This specification is both IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6の両方が認識しています。

5.039. RFC 2409 The Internet Key Exchange (IKE)

5.039。 RFC 2409インターネット鍵交換（IKE）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.040. RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec

5.040。 RFC 2410ザ・NULL暗号化アルゴリズムとIPsecでの使用

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.041. RFC 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis)

5.041。 RFC 2419 PPP DES暗号化プロトコルを、バージョン2（DESEビス）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.042. RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE)

5.042。 RFC 2420 PPPトリプルDES暗号化プロトコル（3DESE）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.043. RFC 2440 OpenPGP Message Format

5.043。 RFC 2440のOpenPGPメッセージフォーマット

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.044. RFC 2444 The One-Time-Password SASL Mechanism

5.044。 RFC 2444ワンタイムパスワードSASLメカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.045. RFC 2451 The ESP CBC-Mode Cipher Algorithms

5.045。 RFC 2451 ESP CBCモード暗号アルゴリズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.046. RFC 2478 The Simple and Protected GSS-API Negotiation Mechanism

5.046。 RFC 2478シンプルで保護されたGSS-API交渉メカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.047. RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols

5.047。 RFC 2510インターネットX.509公開鍵インフラストラクチャ証明書管理プロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.048. RFC 2511 Internet X.509 Certificate Request Message Format

5.048。 RFC 2511インターネットX.509証明書要求メッセージ形式

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.049. RFC 2535 Domain Name System Security Extensions

5.049。 RFC 2535ドメインネームシステムセキュリティ拡張

There are no IPv4 dependencies in this specification. There are discussions of A and AAAA records in the document, but have no real implications on IPv4 dependency or on any IP related address records.

この仕様にはIPv4の依存関係はありません。そこドキュメント内のAとAAAAレコードの議論がありますが、IPv4の依存関係上、または任意のIPアドレスに関連するレコードには本当の意味を持っていません。

5.050. RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)

5.050。 RFC 2536のDSA鍵とドメインネームシステム内のSIG（DNS）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.051. RFC 2538 Storing Certificates in the Domain Name System (DNS)

5.051。 RFC 2538ドメインネームシステムでの保管証明書（DNS）

Section 3.1 X.509 CERT RR Names

3.1節X.509 CERT RRの名前

Some X.509 versions permit multiple names to be associated with subjects and issuers under "Subject Alternate Name" and "Issuer Alternate Name". For example, x.509v3 has such Alternate Names with an ASN.1 specification as follows:

いくつかのX.509のバージョンは、「サブジェクト代替名」と「発行者代替名」の下のサブジェクトと発行者に関連付けられる複数の名前を許します。例えば、のX.509v3は、次のようにASN.1仕様のような代替名を有します。

            GeneralName ::= CHOICE {
               otherName                  [0] INSTANCE OF OTHER-NAME,
               rfc822Name                 [1] IA5String,
               dNSName                    [2] IA5String,
               x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
               directoryName              [4] EXPLICIT Name,
               ediPartyName               [5] EDIPartyName,
               uniformResourceIdentifier  [6] IA5String,
               iPAddress                  [7] OCTET STRING,
               registeredID               [8] OBJECT IDENTIFIER
            }

uses a potential IPv4 only address. It goes on with the following example:

可能性のIPv4アドレスのみを使用しています。これは、次の例にに行きます：

Example 2: Assume that an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker <hacker@mail.widget.foo.example>". Then the storage locations recommended, in priority order, would be (1) widget.foo.example, (2) 201.13.251.10.in-addr.arpa, and (3) hacker.mail.widget.foo.example.

例2：X.509v3証明書が発行されると仮定する/ CN =ジェームス・ハッカー/ L =ベイジングストークは/ O =ウィジェットINC / C = GB /（A）ドメイン名widget.foo.exampleのサブジェクト代替名を持つ、（Bまで）IPv4アドレス10.251.13.201、および（c）は、文字列 "ジェームズ・ハッカー<hacker@mail.widget.foo.example>"。次に推奨保管場所には、優先順に、（1）widget.foo.example、（2）201.13.251.10.in-addr.arpa、及び（3）hacker.mail.widget.foo.exampleあろう。

Since the definition of X.509v3 certificates is not discussed in this document it is unclear if IPv6 addresses are also supported in the above mentioned field. The document does however refer to RFC 2459 for the definition of a certificate, and RFC 2459 is IPv6 and IPv4 aware -- so it seems this specification is IPv4 and IPv6 aware.

X.509v3証明書の定義は、この文書で説明されていないので、IPv6アドレスも上記の分野でサポートされているかどうかは不明です。文書は、しかし、証明書の定義については、RFC 2459を参照しない、とRFC 2459は、IPv6とIPv4を認識している - この仕様は、IPv4とIPv6が認識しているようですので。

5.052. RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)

5.052。ドメインネームシステムでのDiffie-Hellmanの鍵のRFC 2539ストレージ（DNS）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.053. RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Specification - OCSP

5.053。 RFC 2560 X.509インターネットの公開鍵暗号基盤のオンライン証明書状態仕様 - OCSP

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.054. RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

5.054。 RFC 2585のインターネットX.509公開鍵基盤運用プロトコル：FTPやHTTP

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.055. RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema

5.055。 RFC 2587インターネットX.509公開鍵インフラストラクチャのLDAPv2スキーマ

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.056. RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5

5.056。 RFC 2623 NFSバージョン2およびバージョン3のセキュリティ問題とRPCSEC_GSSとケルベロスV5のNFSプロトコルの使用

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.057. RFC 2631 Diffie-Hellman Key Agreement Method

5.057。 RFC 2631のDiffie-Hellman鍵方式

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.058. RFC 2632 S/MIME Version 3 Certificate Handling

5.058。 RFC 2632 S / MIMEバージョン3証明書の取り扱い

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.059. RFC 2633 S/MIME Version 3 Message Specification

5.059。 RFC 2633 S / MIMEバージョン3メッセージ仕様

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.060. RFC 2634 Enhanced Security Services for S/MIME

5.060。 RFC 2634は、S / MIMEのためのセキュリティサービスを強化します

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.061. RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)

5.061。 Layer Security（TLS）を輸送するためのケルベロス暗号スイートのRFC 2712の追加

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.062. RFC 2743 Generic Security Service Application Program Interface Version 2 Update 1

5.062。 RFC 2743ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2アップデート1

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.063. RFC 2744 Generic Security Service API Version 2: C-bindings

5.063。 RFC 2744ジェネリックセキュリティサービスAPIバージョン2：C-バインディング

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.064. RFC 2747 RSVP Cryptographic Authentication

5.064。 RFC 2747 RSVP暗号化認証

This specification is both IPv4 and IPv6 aware and needs no changes.

この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。

5.065. RFC 2797 Certificate Management Messages over CMS

5.065。 CMSを超えるRFC 2797証明書管理メッセージ

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.066. RFC 2817 Upgrading to TLS Within HTTP/1.1

5.066。 HTTP / 1.1の中でTLSにRFC 2817のアップグレード

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.067. RFC 2829 Authentication Methods for LDAP

5.067。 RFC 2829認証方法LDAPのための

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.068. RFC 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security (LDAP)

5.068。 RFC 2830ライトウェイトディレクトリアクセスプロトコル（v3の）：トランスポート層セキュリティのための拡張（LDAP）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.069. RFC 2831 Using Digest Authentication as a SASL Mechanism

5.069。 SASLメカニズムとしてダイジェスト認証を使用したRFC 2831

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.070. RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)

5.070。 DNSのためのRFC 2845の秘密鍵トランザクション認証（TSIG）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.071. RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

5.071。 RFC 2847 LIPKEY - SPKMを用いた低インフラストラクチャ公開鍵メカニズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.072. RFC 2853 Generic Security Service API Version 2 : Java Bindings

5.072。 RFC 2853ジェネリックセキュリティサービスAPIバージョン2：Javaのバインディング

The document uses the InetAddress variable which does not necessarily limit it to IPv4 addresses so there are no IPv4 dependencies in this specification.

文書は、IPv4はので、この仕様にはIPv4の依存関係が存在しないアドレスに必ずしもそれを制限するものではありませんInetAddressの変数を使用しています。

5.073. RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH

5.073。 RFC 2857 ESPおよびAH内のHMAC-RIPEMD-160-96の使用

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.074. RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms

5.074。 RFC 2875のDiffie-Hellman証明-の所持アルゴリズム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.075. RFC 2930 Secret Key Establishment for DNS (TKEY RR)

5.075。 RFC 2930 DNSのための秘密鍵確立（TKEYのRR）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.076. RFC 2931 DNS Request and Transaction Signatures (SIG(0)s)

5.076。 RFC 2931 DNS要求とトランザクション署名（SIG（0）秒）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.077. RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement

5.077。 RFC 2935インターネットオープン取引プロトコル（IOTP）HTTPサプリメント

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.078. RFC 2941 Telnet Authentication Option

5.078。 RFC 2941のTelnet認証オプション

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.079. RFC 2942 Telnet Authentication: Kerberos Version 5

5.079。 RFC 2942のTelnet認証：Kerberosバージョン5

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.080. RFC 2943 TELNET Authentication Using DSA

5.080。 DSAを使用したRFC 2943 TELNET認証

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.081. RFC 2944 Telnet Authentication: SRP

5.081。 RFC 2944のTelnet認証：SRP

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.082. RFC 2945 The SRP Authentication and Key Exchange System

5.082。 RFC 2945 SRP認証と鍵交換システム

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.083. RFC 2946 Telnet Data Encryption Option

5.083。 RFC 2946のTelnetデータ暗号化オプション

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.084. RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback

5.084。 RFC 2947のTelnet暗号化：DES3 64ビット暗号フィードバック

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.085. RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback

5.085。 RFC 2948のTelnet暗号化：DES3 64ビット出力フィードバック

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.086. RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback

5.086。 RFC 2949のTelnet暗号化：CAST-128 64ビットの出力フィードバック

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.087. RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback

5.087。 RFC 2950のTelnet暗号化：CAST-128 64ビット暗号フィードバック

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.088. RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS

5.088。 CMSでのCAST-128暗号化アルゴリズムのRFC 2984を使用します

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.089. RFC 3007 Secure Domain Name System (DNS) Dynamic Update

5.089。 RFC 3007セキュアなドメインネームシステム（DNS）動的更新

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.090. RFC 3008 Domain Name System Security (DNSSEC) Signing Authority

5.090。 RFC 3008ドメインネームシステムセキュリティ（DNSSEC）の署名機関

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.091. RFC 3012 Mobile IPv4 Challenge/Response Extensions

5.091。 RFC 3012モバイルIPv4チャレンジ/レスポンス拡張機能

This document is specifically designed for IPv4.

この文書は、特にIPv4のために設計されています。

5.092. RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile

5.092。 RFC 3039インターネットX.509公開鍵インフラストラクチャ資格証明書のプロフィール

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.093. RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6

5.093。 IPv6におけるステートレスアドレス自動設定のためのRFC 3041のプライバシー拡張

This is an IPv6 related document and is not discussed in this document.

これは、IPv6関連の文書であり、この文書で説明されていません。

5.094. RFC 3062 LDAP Password Modify Extended Operation

5.094。 RFC 3062 LDAPパスワード変更拡張操作を

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.095. RFC 3090 DNS Security Extension Clarification on Zone Status

5.095。ゾーンのステータスのRFC 3090 DNSセキュリティ拡張の明確化

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.096. RFC 3097 RSVP Cryptographic Authentication -- Updated Message Type Value

5.096。 RFC 3097 RSVP暗号化認証 - 更新メッセージタイプの値

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.097. RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)

5.097。 RFCドメインネームシステム（DNS）における3110 RSA / SHA-1のSIGとRSA鍵

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.098. RFC 3118 Authentication for DHCP Messages

5.098。 DHCPメッセージのRFC 3118の認証

This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6.

この文書は、IPv4のみのために指定されています。同様の機能がDHCPv6のに利用可能であることが予想されます。

5.099. RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security

5.099。トランスポート層セキュリティの安全なSMTPのためのRFC 3207のSMTPサービス拡張

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.100. RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing

5.100。 RFC 3275、XML（Extensible Markup Language）に-署名構文と処理

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

5.101. RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

5.101。 RFC 3280インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール

This specification is IPv4 and IPv6 aware.

この仕様は、IPv4とIPv6を認識しています。

5.102. RFC 3369 Cryptographic Message Syntax (CMS)

5.102。 RFC 3369暗号メッセージ構文（CMS）

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.0. Experimental RFCs

6.0. 実験のRFC

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実装や用法を持っていないプロトコルを定義します。彼らは多くの場合、自然の中で妥当または制限された競技場で使用されています。彼らは、潜在的な相互運用性またはいくつかの他の潜在的に有用なシナリオを可能にするためにインターネットコミュニティに文書化されています。いくつかのケースでは、彼らは認め問題の主流の解決策の代替として提示されています。

6.01. RFC 1004 Distributed-protocol authentication scheme

6.01. RFC 1004分散プロトコルの認証方式

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.02. RFC 1411 Telnet Authentication: Kerberos Version 4

6.02. RFC 1411のTelnet認証：Kerberosバージョン4

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.03. RFC 1412 Telnet Authentication: SPX

6.03. RFC 1412のTelnet認証：SPX

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.04. RFC 1507 DASS - Distributed Authentication Security Service

6.04. RFC 1507 DASS - 分散認証セキュリティサービス

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.05. RFC 1851 The ESP Triple DES Transform

6.05. RFC 1851 ESPトリプルDESを変換

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.06. RFC 1949 Scalable Multicast Key Distribution (SMKD)

6.06. RFC 1949スケーラブルマルチキャスト鍵配送（SMKD）

This specification assumes the use of IGMP and is therefore limited to IPv4 multicast. It is assumed that a similar mechanism may be defined for IPv6 multicasting.

この仕様は、IGMPの使用を想定し、したがってたIPv4マルチキャストに限定されます。同様のメカニズムは、IPv6マルチキャストのために定義されてもよいことが想定されます。

6.07. RFC 2093 Group Key Management Protocol (GKMP) Specification

6.07. RFC 2093、グループ鍵管理プロトコル（GKMP）仕様

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.08. RFC 2094 Group Key Management Protocol (GKMP) Architecture

6.08. RFC 2094、グループ鍵管理プロトコル（GKMP）アーキテクチャ

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.09. RFC 2154 OSPF with Digital Signatures

6.09. デジタル署名付きRFC 2154 OSPF

This OSPF option is IPv4 limited. See the following packet format:

このOSPFオプションは、IPv4が限られています。以下のパケットフォーマットを参照してください。

7.2. Router Public Key Certificate

7.2. ルータの公開鍵証明書

A router public key certificate is a package of data signed by a Trusted Entity. This certificate is included in the router PKLSA and in the router configuration information. To change any of the values in the certificate, a new certificate must be obtained from a TE.

ルータの公開鍵証明書は、信頼できるエンティティによって署名されたデータのパッケージです。この証明書は、ルータPKLSAにし、ルータコンフィギュレーション情報に含まれています。証明書のいずれかの値を変更するには、新しい証明書がTEから取得する必要があります。

                           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
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Router Id                            |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |     TE Id     |   TE Key Id   |   Rtr Key Id  |    Sig Alg    |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Create Time                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |        Key Field Length       |  Router Role  |  #Net Ranges  |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                         Address Mask                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |           IP Address/Address Mask for each Net Range ...      /
      | ...                                                           /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                       Router Public Key                       |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                         Certification                         /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

#NET RANGES The number of network ranges that follow. A network range is defined to be an IP Address and an Address Mask. This list of ranges defines the addresses that the Router is permitted to advertise in its Router Links LSA. Valid values are 0-255. If there are 0 ranges the router cannot advertise anything. This is not generally useful. One range with address=0 and mask=0 will allow a router to advertise any address.

#NETは続くネットワーク範囲の数の範囲です。ネットワークの範囲は、IPアドレスとアドレスマスクになるように定義されます。範囲のこのリストは、ルータがそのルータのリンクLSAで広告を掲載することが許可されているアドレスを定義します。有効な値は0〜255です。 0の範囲がある場合、ルータは何を宣伝することはできません。これは、一般的に有用ではありません。アドレス= 0とマスク= 0の一つの範囲では、ルータは任意のアドレスを宣伝することができます。

IP ADDRESS & ADDRESS MASK Define a range of addresses that this router may advertise. Each is a 32 bit value. One range with address=0 and mask=0 will allow a router to advertise any address.

IPアドレス＆ADDRESS MASKは、このルータアドバタイズするアドレスの範囲を定義します。各々が32ビットの値です。アドレス= 0とマスク= 0の一つの範囲では、ルータは任意のアドレスを宣伝することができます。

6.10. RFC 2522 Photuris: Session-Key Management Protocol

6.10. RFC 2522のPhoturis：セッション鍵管理プロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.11. RFC 2523 Photuris: Extended Schemes and Attributes

6.11. RFC 2523のPhoturis：拡張スキームおよび属性

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.12. RFC 2659 Security Extensions For HTML

6.12. HTMLについてはRFC 2659個のセキュリティ拡張機能

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.13. RFC 2660 The Secure HyperText Transfer Protocol

6.13. RFC 2660セキュアハイパーテキスト転送プロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.14. RFC 2692 SPKI Requirements

6.14. RFC 2692 SPKI要件

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.15. RFC 2693 SPKI Certificate Theory

6.15. RFC 2693 SPKI証明論

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.16. RFC 2716 PPP EAP TLS Authentication Protocol

6.16. RFC 2716 PPP EAP TLS認証プロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

6.17. RFC 2773 Encryption using KEA and SKIPJACK

6.17. KEAとSKIPJACKを使用してRFC 2773の暗号化

This specification is both IPv4 and IPv6 aware and needs no changes.

この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。

6.18. RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols

6.18. RFC 3029インターネットX.509公開鍵インフラストラクチャデータの検証と認証サーバプロトコル

There are no IPv4 dependencies in this specification.

この仕様にはIPv4の依存関係はありません。

7.0. Summary of Results

7.0. 結果のまとめ

In the initial survey of RFCs 4 positives were identified out of a total of 124, broken down as follows:

RFCの初期調査で4つの陽性は、次のように分解、124の合計のうち、同定されました。

         Standards:                              0 out of   1 or  0.00%
         Draft Standards:                        1 out of   3 or 33.33%
         Proposed Standards:                     1 out of 102 or  0.98%
         Experimental RFCs:                      2 out of  18 or 11.11%

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.

また、更新する必要がありますが、それらが更新されていない場合はすべての業務への影響を起こさない水準の多くのインスタンスがあります。残りのインスタンスは、以下の文書化されています。

7.1. Standards

7.1. 規格

7.2. Draft Standards

7.2. ドラフト規格

7.2.1. RADIUS (RFC 2865)

7.2.1. RADIUS（RFC 2865）

The problems have been resolved in RFC 3162, RADIUS and IPv6.

問題は、RFC 3162、RADIUSとIPv6で解決されています。

7.3. Proposed Standards

7.3. 提案された標準

7.3.1. RIPv2 MD5 Authentication (RFC 2082)

7.3.1. RIPv2のMD5認証（RFC 2082）

This functionality has been assumed by the use of the IPsec AH header as defined in RFC 2402, IP Authentication Header.

RFC 2402、IP認証ヘッダで定義されるように、この機能は、IPsec AHヘッダの使用が想定されています。

7.3.2. Mobile IPv4 Challenge Response Extension (RFC 3012)

7.3.2. モバイルIPv4チャレンジレスポンス拡張（RFC 3012）

The problems are not being addressed and similar functions may be needed in Mobile IPv6.

問題が解決されていないと同様の機能は、モバイルIPv6で必要とすることができます。

7.3.3. Authentication for DHCP Messages (RFC 3118)

7.3.3. DHCPメッセージの認証（RFC 3118）

This problem has been fixed in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).

この問題は、RFC 3315、IPv6の動的ホスト構成プロトコル（DHCPv6）で修正されています。

7.4. Experimental RFCs

7.4. 実験のRFC

7.4.1. Scalable Multicast Key Distribution (RFC 1949)

7.4.1. スケーラブルマルチキャスト鍵配布（RFC 1949）

This specification relies on IPv4 IGMP Multicast and a new specification may be produced; however, the SMKD is not believed to be in use.

この仕様は、IPv4 IGMPマルチキャストに依存しており、新たな仕様を生成することができます。しかし、SMKDが使用中であるとは考えられません。

7.4.2. OPSF with Digital Signatures (RFC 2154)

7.4.2. デジタル署名付きOPSF（RFC 2154）

This specification is IPv4-only, and relies on an IPv4-only routing protocol, OSPFv2. Due to increased focus on routing security, this specification may need to be revisited, and in that case it should support both OSPFv2 and OPSFv3.

この仕様は、IPv4のみであり、IPv4専用のルーティングプロトコル、OSPFv2のに依存しています。セキュリティ上のルーティングの増加焦点に、この仕様は再検討する必要があり、その場合には、それはのOSPFv2とOPSFv3の両方をサポートする必要があります。

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.

編集者、アンドレアスベルイストロームは、このドキュメントの編集のためのガイダンスやコメントを収集するためペッカSavolaに感謝したいと思います。

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.ベルイストローム、エディタを、RFC 3789、2004年6月 "のIPv4の調査の概要は、現在展開IETF標準のアドレス"。

11.0. Authors' Addresses

11.0. 著者のアドレス

Please contact the author 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

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.

著作権（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機能のための基金は現在、インターネット協会によって提供されます。

RFC 3792 - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents 日本語訳

1.0. Introduction

1.0. 前書き

2.0. Document Organization

2.0. マニュアルの構成

3.0. Full Standards

3.0. フル規格

3.1. A One-Time Password System

3.1. ワンタイムパスワードシステム

4.0. Draft Standards

4.0. ドラフト規格

4.1. The Content-MD5 Header Field

4.1. コンテンツ-MD5ヘッダーフィールド

4.3. Remote Authentication Dial In User Service (RADIUS)

4.3. ユーザーサービス（RADIUS）でリモート認証ダイヤル

5.4. NAS-IP-Address

5.4. NAS-IP-アドレス

5.8. Framed-IP-Address

5.8. フレームを選ぶ-IP-アドレス

5.9. Framed-IP-Netmask

5.9. フレームを選ぶ-IP-ネットマスク

5.14. Login-IP-Host

5.14. ログイン-IP-ホスト

5.22. Framed-Route

5.22. フレームを選ぶ-ルート

5.0. Proposed Standards

5.0. 提案された標準

5.001. RFC 1413 Identification Protocol

5.001。 RFC 1413の識別プロトコル

5.006. RFC 1510 The Kerberos Network Authentication Service (V5)

5.006。 RFC 1510ザ・ケルベロスネットワーク認証サービス（V5）

5.007. RFC 1731 IMAP4 Authentication Mechanisms

5.007。 RFC 1731 IMAP4認証メカニズム

5.008. RFC 1734 POP3 AUTHentication command

5.008。 RFC 1734 POP3認証コマンド

5.009. RFC 1828 IP Authentication using Keyed MD5

5.009。キー付きMD5を使用して、RFC 1828 IP認証

5.010. RFC 1829 The ESP DES-CBC Transform

5.010。 ESP DES-CBC変換をRFC 1829

5.012. RFC 1848 MIME Object Security Services

5.012。 RFC 1848 MIMEオブジェクトセキュリティサービス

5.013. RFC 1928 SOCKS Protocol Version

5.013。 RFC 1928 SOCKSプロトコルバージョン

5.014. RFC 1929 Username/Password Authentication for SOCKS V5

5.014。 SOCKS V5のためのRFC 1929のユーザ名/パスワード認証

5.015. RFC 1961 GSS-API Authentication Method for SOCKS Version 5

5.015。 SOCKSバージョン5のためのRFC 1961 GSS-API認証方法

5.016. RFC 1964 The Kerberos Version 5 GSS-API Mechanism

5.016。 RFC 1964ザ・Kerberosバージョン5 GSS-APIメカニズム

5.017. RFC 1968 The PPP Encryption Control Protocol (ECP)

5.017。 RFC 1968 PPP暗号化制御プロトコル（ECP）

5.018. RFC 2015 MIME Security with Pretty Good Privacy (PGP)

5.018。プリティグッドプライバシーとRFC 2015 MIMEセキュリティ（PGP）

5.019. RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)

5.019。 RFC 2025シンプルな公開鍵GSS-APIメカニズム（SPKM）

5.020. RFC 2082 RIP-2 MD5 Authentication

5.020。 RFC 2082 RIP-2 MD5認証

5.021. RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention

5.021。リプレイ防止とRFC 2085 HMAC-MD5 IP認証

5.023. RFC 2203 RPCSEC_GSS Protocol Specification

5.023。 RFC 2203 RPCSEC_GSSプロトコル仕様

5.024. RFC 2222 Simple Authentication and Security Layer (SASL)

5.024。 RFC 2222簡易認証セキュリティー層（SASL）

5.025. RFC 2228 FTP Security Extensions

5.025。 RFC 2228のFTPセキュリティ拡張

5.026. RFC 2243 OTP Extended Responses

5.026。 RFC 2243のOTP拡張応答

5.027. RFC 2245 Anonymous SASL Mechanism

5.027。 RFC 2245匿名SASLメカニズム

5.028. RFC 2246 The TLS Protocol Version 1.0

5.028。 RFC 2246ザ​​・TLSプロトコルバージョン1.0

5.029. RFC 2284 PPP Extensible Authentication Protocol (EAP)

5.029。 RFC 2284 PPP拡張認証プロトコル（EAP）

5.031. RFC 2401 Security Architecture for the Internet Protocol

5.031。インターネットプロトコルのためのRFC 2401セキュリティアーキテクチャ

5.032. RFC 2402 IP Authentication Header

5.032。 RFC 2402 IP認証ヘッダ

5.033. RFC 2403 The Use of HMAC-MD5-96 within ESP and AH

5.033。 RFC 2403 ESPおよびAH内のHMAC-MD5-96の使用

5.034. RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH

5.028。 RFC 2246ザ・TLSプロトコルバージョン1.0