RFC2428 日本語訳
2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C.Metz. September 1998. (Format: TXT=16028 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Allman Request for Comments: 2428 NASA Lewis/Sterling Software Category: Standards Track S. Ostermann Ohio University C. Metz The Inner Net September 1998
コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 2428年のNASAのルイス/りっぱなソフトウェアカテゴリ: 規格は内側のネットの1998年9月にS.オステルマン・オハイオ大学C.メスを追跡します。
FTP Extensions for IPv6 and NATs
IPv6とNATsのためのFTP拡大
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.
File Transferプロトコルのための仕様は、基本的なネットワーク・プロトコルが32ビットのネットワーク・アドレス(明確にIPバージョン4)を使用すると仮定します。 インターネットプロトコルのバージョン6の展開で、ネットワーク・アドレスはもう32ビットにならないでしょう。 この紙はプロトコルがIPv4とIPv6の上で働いているFTPに拡大を指定します。 さらに、定義されたフレームワークは将来、追加ネットワーク・プロトコルをサポートできます。
1. Introduction
1. 序論
The keywords, such as MUST and SHOULD, found in this document are used as defined in RFC 2119 [Bra97].
キーワードと、そのようなもの、そして、RFC2119[Bra97]で定義されるように使用されるこのドキュメントで見つけられたSHOULDでなければならない。
The File Transfer Protocol [PR85] only provides the ability to communicate information about IPv4 data connections. FTP assumes network addresses will be 32 bits in length. However, with the deployment of version 6 of the Internet Protocol [DH96] addresses will no longer be 32 bits long. RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. Unfortunately, the mechanism can fail in a multi-protocol environment. During the transition between IPv4 and IPv6, FTP needs the ability to negotiate the network protocol that will be used for data transfer.
File Transferプロトコル[PR85]はIPv4データ接続の情報を伝える能力を提供するだけです。 FTPは、長さがネットワーク・アドレスが32ビットになると仮定します。 しかしながら、インターネットプロトコル[DH96]のバージョン6の展開で、アドレスはもう長さ32ビットでないでしょう。 RFC1639[Pis94]は、様々なネットワーク・プロトコルの上の使用を可能にするためにFTPに拡大を指定します。 残念ながら、メカニズムはマルチプロトコル環境に失敗できます。 IPv4とIPv6の間の変遷の間、FTPはデータ転送に使用されるネットワーク・プロトコルを交渉する能力を必要とします。
Allman, et. al. Standards Track [Page 1] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[1ページ]RFC2428FTP拡張子とNATs1998年9月
This document provides a specification for a way that FTP can communicate data connection endpoint information for network protocols other than IPv4. In this specification, the FTP commands PORT and PASV are replaced with EPRT and EPSV, respectively. This document is organized as follows. Section 2 outlines the EPRT command and Section 3 outlines the EPSV command. Section 4 defines the utilization of these two new FTP commands. Section 5 briefly presents security considerations. Finally, Section 6 provides conclusions.
このドキュメントはFTPがIPv4以外のネットワーク・プロトコルのためのデータ接続終点情報を伝えることができる方法のための仕様を提供します。 この仕様では、それぞれFTPコマンドのPORTとPASVをEPRTとEPSVに取り替えます。 このドキュメントは以下の通りまとめられます。 セクション2はEPRTコマンドについて概説します、そして、セクション3はEPSVコマンドについて概説します。 セクション4はこれらの2つの新しいFTPコマンドの利用を定義します。 セクション5は簡潔にセキュリティ問題を提示します。 最終的に、セクション6は結論を提供します。
2. The EPRT Command
2. EPRTコマンド
The EPRT command allows for the specification of an extended address for the data connection. The extended address MUST consist of the network protocol as well as the network and transport addresses. The format of EPRT is:
EPRTコマンドはデータ接続に関して拡張アドレスの仕様を考慮します。 拡張アドレスはネットワークと輸送アドレスと同様にネットワーク・プロトコルから成らなければなりません。 EPRTの形式は以下の通りです。
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
ネットのprtのネットのaddrのEPRTの><d><<スペース><d><><d><tcp-ポート><d>。
The EPRT command keyword MUST be followed by a single space (ASCII 32). Following the space, a delimiter character (<d>) MUST be specified. The delimiter character MUST be one of the ASCII characters in range 33-126 inclusive. The character "|" (ASCII 124) is recommended unless it coincides with a character needed to encode the network address.
シングルスペース(ASCII32)はEPRTコマンドキーワードのあとに続かなければなりません。 スペースに続いて、デリミタキャラクタ(<d>)を指定しなければなりません。 デリミタキャラクタは範囲33-126で包括的なASCII文字のひとりであるに違いありません。 「キャラクタ」|「キャラクタがネットワーク・アドレスをコード化するのに必要である状態で一致しない場合、(ASCII124)はお勧めです。」
The <net-prt> argument MUST be an address family number defined by IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the writing of this document). This number indicates the protocol to be used (and, implicitly, the address length). This document will use two of address family numbers from [RP94] as examples, according to the following table:
<のネットのprtの>議論は最新のAssigned民数記RFC(このドキュメントの書くこと現在RFC1700[RP94])でIANAによって定義されたアドレスファミリーナンバであるに違いありません。 この数は、使用される(それとなくアドレスの長さ)ためにプロトコルを示します。 以下のテーブルに従って、このドキュメントは例として[RP94]から2つのアドレスファミリーナンバを使用するでしょう:
AF Number Protocol --------- -------- 1 Internet Protocol, Version 4 [Pos81a] 2 Internet Protocol, Version 6 [DH96]
AF数のプロトコル--------- -------- 1 インターネットプロトコル、バージョン4[Pos81a]2インターネットプロトコル、バージョン6[DH96]
The <net-addr> is a protocol specific string representation of the network address. For the two address families specified above (AF Number 1 and 2), addresses MUST be in the following format:
<のネットのaddrの>はネットワーク・アドレスのプロトコルの特定のストリング表現です。 (AF Number1と2)の上で指定された2つのアドレスファミリーにおいて、以下の形式にはアドレスがあるに違いありません:
AF Number Address Format Example --------- -------------- ------- 1 dotted decimal 132.235.1.2 2 IPv6 string 1080::8:800:200C:417A representations defined in [HD96]
AF数のアドレス形式の例--------- -------------- ------- 1 ドット付き10進法132.235.1.2 2IPv6は1080を結びます:、:8:800:200C: 中で定義された417A表現[HD96]
Allman, et. al. Standards Track [Page 2] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[2ページ]RFC2428FTP拡張子とNATs1998年9月
The <tcp-port> argument must be the string representation of the number of the TCP port on which the host is listening for the data connection.
<はストリングがホストがデータ接続の聞こうとしているTCPポートの数の表現であったに違いないなら>議論をtcp移植します。
The following are sample EPRT commands:
↓これはサンプルEPRTコマンドです:
EPRT |1|132.235.1.2|6275|
EPRT|1|132.235.1.2|6275|
EPRT |2|1080::8:800:200C:417A|5282|
EPRT|2|1080::8:800:200C: 417A|5282|
The first command specifies that the server should use IPv4 to open a data connection to the host "132.235.1.2" on TCP port 6275. The second command specifies that the server should use the IPv6 network protocol and the network address "1080::8:800:200C:417A" to open a TCP data connection on port 5282.
最初のコマンドが、サーバがデータ接続をホストに公開するのにIPv4を使用するべきであると指定する、「132.235 .1 TCPの上の0.2インチは6275をインチ移植します。 2番目のコマンドが、サーバがIPv6ネットワーク・プロトコルとネットワーク・アドレスを使用するべきであると指定する、「1080:、:、」ポートの上でTCPデータ接続を開く「8:800:200C: 417A」5282。
Upon receipt of a valid EPRT command, the server MUST return a code of 200 (Command OK). The standard negative error code 500 and 501 [PR85] are sufficient to handle most errors (e.g., syntax errors) involving the EPRT command. However, an additional error code is needed. The response code 522 indicates that the server does not support the requested network protocol. The interpretation of this new error code is:
有効なEPRTコマンドを受け取り次第、サーバは200(Command OK)のコードを返さなければなりません。 標準の否定的エラーコード500と501[PR85]は、EPRTコマンドにかかわりながらほとんどの誤り(例えば、構文エラー)を扱うために十分です。 しかしながら、追加エラーコードが必要です。 応答コード522は、サーバが要求されたネットワーク・プロトコルをサポートしないのを示します。 この新しいエラーコードの解釈は以下の通りです。
5yz Negative Completion x2z Connections xy2 Extended Port Failure - unknown network protocol
5yz Negative Completion x2zコネクションズxy2 Extended Port Failure--未知のネットワーク・プロトコル
The text portion of the response MUST indicate which network protocols the server does support. If the network protocol is unsupported, the format of the response string MUST be:
応答のテキスト部分は、サーバがどのネットワーク・プロトコルをサポートするかを示さなければなりません。 ネットワーク・プロトコルがサポートされないなら、応答ストリングの形式は以下の通りであるに違いありません。
<text stating that the network protocol is unsupported> \ (prot1,prot2,...,protn)
ネットワーク・プロトコルがサポートされない>\であると述べる<テキスト(prot1、prot2、…、protn)
Both the numeric code specified above and the protocol information between the characters '(' and ')' are intended for the software automata receiving the response; the textual message between the numeric code and the '(' is intended for the human user and can be any arbitrary text, but MUST NOT include the characters '(' and ')'. In the above case, the text SHOULD indicate that the network protocol in the EPRT command is not supported by the server. The list of protocols inside the parenthesis MUST be a comma separated list of address family numbers. Two example response strings follow:
上で指定された数字コードとキャラクタの間のプロトコル情報の両方、'、('')'は応答を受けるソフトウェアオートマトンのために意図します。 'キャラクタを含んではいけないのを除いて、人間のユーザのために意図して、どんな任意のテキストであることができますも'。そして、数字コードの間の原文のメッセージ、'、(('そして. 上の場合(EPRTコマンドにおけるネットワーク・プロトコルがサーバによってサポートされないSHOULDが示すテキスト)における、挿入句におけるプロトコルのリストが. アドレスファミリーナンバのコンマの切り離されたリストが2例の応答であったならそうしなければならない')'ストリングは以下に続きます'。
Network protocol not supported, use (1)
サポートされなかったネットワーク・プロトコル、使用(1)
Network protocol not supported, use (1,2)
サポートされなかったネットワーク・プロトコル、使用(1,2)
Allman, et. al. Standards Track [Page 3] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[3ページ]RFC2428FTP拡張子とNATs1998年9月
3. The EPSV Command
3. EPSVコマンド
The EPSV command requests that a server listen on a data port and wait for a connection. The EPSV command takes an optional argument. The response to this command includes only the TCP port number of the listening connection. The format of the response, however, is similar to the argument of the EPRT command. This allows the same parsing routines to be used for both commands. In addition, the format leaves a place holder for the network protocol and/or network address, which may be needed in the EPSV response in the future. The response code for entering passive mode using an extended address MUST be 229. The interpretation of this code, according to [PR85] is:
EPSVはサーバがデータポートの上で聴いて、接続を待っているという要求を命令します。 EPSVコマンドは任意の議論を取ります。 このコマンドへの応答は聴取接続のTCPポートナンバーだけを含んでいます。 しかしながら、応答の形式はEPRTコマンドの議論と同様です。 これは、同じ構文解析ルーチンが両方のコマンドに使用されるのを許容します。 さらに、形式は場所所有者をネットワーク・プロトコル、そして/または、ネットワーク・アドレスに置き去りにします。(それが、将来、EPSV応答で必要であるかもしれません)。 拡張アドレスを使用することで受け身の形態を入れるための応答コードは229でなければなりません。 [PR85]に従ったこのコードの解釈は以下の通りです。
2yz Positive Completion x2z Connections xy9 Extended Passive Mode Entered
2yz Positive Completion x2zコネクションズxy9 Extended Passive Mode Entered
The text returned in response to the EPSV command MUST be:
EPSVコマンドに対応して返されたテキストは以下の通りであるに違いありません。
<text indicating server is entering extended passive mode> \ (<d><d><d><tcp-port><d>)
サーバに入っているのを示す<テキストが受け身の形態>\を広げました。(<d><d><d><tcp-ポート><d>)
The portion of the string enclosed in parentheses MUST be the exact string needed by the EPRT command to open the data connection, as specified above.
括弧に同封されたストリングの一部がデータ接続を開くEPRTコマンドで必要である、正確なストリングであるに違いありません、上で指定されるとして。
The first two fields contained in the parenthesis MUST be blank. The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The network protocol used by the data connection will be the same network protocol used by the control connection. In addition, the network address used to establish the data connection will be the same network address used for the control connection. An example response string follows:
挿入句に含まれた最初の2つの分野が空白であるに違いありません。 3番目の分野はサーバがデータ接続の聞こうとしているTCPポートナンバーのストリング表現であるに違いありません。 データ接続によって使用されたネットワーク・プロトコルはコントロール接続によって使用された同じネットワーク・プロトコルになるでしょう。 さらに、データ接続を証明するのに使用されるネットワーク・アドレスはコントロール接続に使用される同じネットワーク・アドレスになるでしょう。 例の応答ストリングは続きます:
Entering Extended Passive Mode (|||6446|)
入るのは受け身の形態を広げました。(|||6446|)
The standard negative error codes 500 and 501 are sufficient to handle all errors involving the EPSV command (e.g., syntax errors).
標準の否定的エラーコード500と501は、EPSVコマンド(例えば、構文エラー)にかかわるすべての誤りを扱うために十分です。
When the EPSV command is issued with no argument, the server will choose the network protocol for the data connection based on the protocol used for the control connection. However, in the case of proxy FTP, this protocol might not be appropriate for communication between the two servers. Therefore, the client needs to be able to request a specific protocol. If the server returns a protocol that is not supported by the host that will be connecting to the port, the
議論なしでEPSVコマンドを発行するとき、サーバはコントロール接続に使用されるプロトコルに基づくデータ接続のためのネットワーク・プロトコルを選ぶでしょう。 しかしながら、プロキシFTPの場合では、2つのサーバのコミュニケーションには、このプロトコルは適切でないかもしれません。 したがって、クライアントは、特定のプロトコルを要求できる必要があります。 サーバがプロトコルを返すなら、それはポートに接続するホストによってサポートされません。
Allman, et. al. Standards Track [Page 4] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[4ページ]RFC2428FTP拡張子とNATs1998年9月
client MUST issue an ABOR (abort) command to allow the server to close down the listening connection. The client can then send an EPSV command requesting the use of a specific network protocol, as follows:
クライアントはサーバが聴取接続を閉鎖するのを許容するコマンドをABOR(中止になる)に発行しなければなりません。 次に、クライアントはEPSVコマンドに以下の通り特定のネットワーク・プロトコルの使用を要求させることができます:
EPSV<space><net-prt>
EPSV<スペースの>の<のネットのprtの>。
If the requested protocol is supported by the server, it SHOULD use the protocol. If not, the server MUST return the 522 error messages as outlined in section 2.
要求されたプロトコルはサーバによってサポートされて、それはSHOULD使用です。プロトコル。 そうでなければ、サーバはセクション2で概説されているように522のエラーメッセージを返さなければなりません。
Finally, the EPSV command can be used with the argument "ALL" to inform Network Address Translators that the EPRT command (as well as other data commands) will no longer be used. An example of this command follows:
最終的に、EPRTコマンド(他のデータコマンドと同様に)がもう使用されないことをネットワークアドレス変換機構に知らせるのに議論「すべて」と共にEPSVコマンドを使用できます。 このコマンドに関する例は従います:
EPSV<space>ALL
EPSV<スペース>、すべて
Upon receipt of an EPSV ALL command, the server MUST reject all data connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et al.). This use of the EPSV command is further explained in section 4.
EPSV ALLコマンドを受け取り次第、サーバはEPSV(すなわち、EPRT、PORT、PASV、他)以外のすべてのデータ接続設定命令を拒絶しなければなりません。 EPSVコマンドのこの使用はセクション4でさらに説明されます。
4. Command Usage
4. コマンド用法
For all FTP transfers where the control and data connection(s) are being established between the same two machines, the EPSV command MUST be used. Using the EPSV command benefits performance of transfers that traverse firewalls or Network Address Translators (NATs). RFC 1579 [Bel94] recommends using the passive command when behind firewalls since firewalls do not generally allow incoming connections (which are required when using the PORT (EPRT) command). In addition, using EPSV as defined in this document does not require NATs to change the network address in the traffic as it is forwarded. The NAT would have to change the address if the EPRT command was used. Finally, if the client issues an "EPSV ALL" command, NATs may be able to put the connection on a "fast path" through the translator, as the EPRT command will never be used and therefore, translation of the data portion of the segments will never be needed. When a client only expects to do two-way FTP transfers, it SHOULD issue this command as soon as possible. If a client later finds that it must do a three-way FTP transfer after issuing an EPSV ALL command, a new FTP session MUST be started.
すべてのFTP転送のために、コントロールとデータ接続が同じ2台のマシンの間で確立されているところでEPSVコマンドを使用しなければなりません。 EPSVコマンドを使用すると、ファイアウォールかNetwork Address Translators(NATs)を横断する転送の性能はためになります。 RFC1579[Bel94]は、ファイアウォールの後ろにあるとき、ファイアウォールが一般に、接続要求(PORT(EPRT)コマンドを使用するとき必要である)を許容しないので、受け身のコマンドを使用することを勧めます。 さらに、それを進めるとき、定義されるようにEPSVを使用するのは、NATsがトラフィックにおけるネットワーク・アドレスを変えるのを本書では必要としません。 EPRTコマンドが使用されるなら、NATはアドレスを変えなければならないでしょうに。 最終的にクライアント問題である、「EPSV、」 コマンド、NATsは翻訳者を通して「高速経路」に接続を置くことができるかもしれません、EPRTコマンドは決して使用されないでしょう、そして、したがって、セグメントのデータ部に関する翻訳は決して必要でないでしょう。 クライアントが、ツーウェイをすると予想するだけであるとき、FTPは移されて、それはこれができるだけ早く命令するSHOULD発行です。 クライアントが、後でEPSV ALLコマンドを発行した後にそれが3者間のFTP転送をしなければならないのがわかるなら、新しいFTPセッションを始めなければなりません。
Allman, et. al. Standards Track [Page 5] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[5ページ]RFC2428FTP拡張子とNATs1998年9月
5. Security Issues
5. 安全保障問題
The authors do not believe that these changes to FTP introduce new security problems. A companion Work in Progress [AO98] is a more general discussion of FTP security issues and techniques to reduce these security problems.
作者は、FTPへのこれらの変化が新しい警備上の問題を紹介すると信じていません。Progress[AO98]の仲間Workはこれらの警備上の問題を減少させるFTP安全保障問題の、より一般的な議論とテクニックです。
6. Conclusions
6. 結論
The extensions specified in this paper will enable FTP to operate over a variety of network protocols.
この紙で指定された拡大は、FTPがさまざまなネットワーク・プロトコルの上で作動するのを可能にするでしょう。
References
参照
[AO98] Allman, M., and S. Ostermann, "FTP Security Considerations", Work in Progress.
[AO98] 仕事進行中のオールマン、M.とS.オステルマン、「FTPセキュリティ問題。」
[Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
[Bel94] Bellovin、S.、「ファイアウォールに優しいFTP」、RFC1579、1994年2月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[DH96]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[HD96] Hinden、R.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[Pis94]Piscitello、D.、「大きいアドレス記録(FOOBAR)の上のFTP操作」、RFC1639、1994年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81a] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81b] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[PR85] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。
[RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[RP94] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
Allman, et. al. Standards Track [Page 6] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[6ページ]RFC2428FTP拡張子とNATs1998年9月
Authors' Addresses
作者のアドレス
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
マークオールマンNASAルイス・リサーチセンター/英貨のソフトウェア21000Brookpark通り MS54-2クリーブランド、OH 44135
Phone: (216) 433-6586 EMail: mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman/
以下に電話をしてください。 (216) 433-6586 メールしてください: mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman/
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701
電気工学のショーンオステルマン学校とHallアテネ、コンピュータサイエンスオハイオ大学416モートンOH 45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
以下に電話をしてください。 (740) 593-1234 メールしてください: ostermann@cs.ohiou.edu
Craig Metz The Inner Net Box 10314-1954 Blacksburg, VA 24062-0314
内側のネット箱10314-1954Blacksburg、クレイグ・メスヴァージニア24062-0314
Phone: (DSN) 754-8590 EMail: cmetz@inner.net
以下に電話をしてください。 (DSN) 754-8590 メールしてください: cmetz@inner.net
Allman, et. al. Standards Track [Page 7] RFC 2428 FTP Extensions for IPv6 and NATs September 1998
etオールマン、アル。 IPv6のための標準化過程[7ページ]RFC2428FTP拡張子とNATs1998年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Allman, et. al. Standards Track [Page 8]
etオールマン、アル。 標準化過程[8ページ]
一覧
スポンサーリンク