Network Working Group M. Gaynor Request for Comments: 3093 S. Bradner Category: Informational Harvard University 1 April 2001 Firewall Enhancement Protocol (FEP) ｜ファイアウォール強化プロトコル (FEP) Status of this Memo ｜このメモの状態 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ｜このメモはインターネットコミュニティに情報を提供する。これは ｜インターネットのいかなる標準も規定するものではない。このメモの ｜配布に制限はない。 Copyright Notice ｜著作権表示 Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract ｜概要 Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse a Firewall. Our methodology is to layer any application layer Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, since HTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, since Firewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall. ｜インターネットのエンドツーエンド・アーキテクチャによるインターネット ｜の透過性は、新しい技術とサービスの著しい革新を可能にした[1]。しかし ｜ながら、このモデルに代わる近頃のファイアウォール技術の開発は、この革新 ｜を阻害しようとしている。我々はファイアウォールのセキュリティモデルを ｜破壊することなく革新を可能にするFEP（ファイアウォール強化プロトコル） ｜を提案する。FEPはファイアウォールのオペレータの力を借りることなく、 ｜いかなるアプリケーションもファイアウォールを通過することを可能にする。 ｜我々の方法論は、一般に、HTTPパケットはファイアウォールを通過することが ｜できるので、いかなるアプロケーション層のものも、HTTP（ハイパーテキスト・ ｜トランスファ・プロトコル）プロトコル上の TCP/UDP（トランスミッション・ ｜コントロール・プロトコル／ユーザ・データグラム・プロトコル）パケット ｜としてレイヤ化することである。この方法はファイアウォールの実質的な ｜セキュリティの有効性を破壊するものではなく、なぜならファイアウォールは ｜外部からの攻撃を避けるために設計されており、内部からの攻撃は無視して ｜いるからである。FEPの使用はファイアウォールの内側のホストの協力を要求 ｜するため、現在のファイアウォールのセキュリティモデルと同等である。FEP ｜はファイアウォールのセキュリティと、ファイアウォールを通す透過的トンネ ｜リングの両方を可能にする。 1.0 Terminology ｜用語 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ｜本ドキュメント内のキーワード MUST、MUST NOT、REQUIRED、SHALL、 ｜SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、及び OPTIONAL ｜は、RFC2119での定義で解釈される。 2.0 Introduction ｜はじめに The Internet has done well, considering that less than 10 years ago the telco's were claiming it could not ever work for the corporate environment. There are many reasons for this; a particularly strong one is the end-to-end argument discussed by Reed, Seltzer, and Clark [2]. Innovation at the ends has proven to be a very powerful methodology creating more value than ever conceived of. But, the world is changing as Clark notes in [6]. With the connection of the corporate world to the Internet, security concerns have become paramount, even at the expense of breaking the end-to-end paradigm. One example of this is the Firewall - a device to prevent outsiders from unauthorized access into a corporation. Our new protocol, the Firewall Enhancement Protocol (FEP), is designed to restore the end- to-end model while maintaining the level of security created by Firewalls. ｜10年も経たない前に、通信業者はインターネットは企業環境では十分に ｜動作しないと警告していたわりには、インターネットはうまく動作している。 ｜これには多くの理由がある；特に強い理由の一つは、リード、セルツァー、 ｜クラークによって検討されたエンドツーエンドの議論である[2]。 ｜末端における革新は、かつて想像されたもの以上に、より価値のあるもの ｜を生み出すことに非常にパワフルな方法であることが証明された。しかし ｜世界はクラークが[6]で記述したように変化している。インターネットに ｜企業が接続されるようになり、セキュリティへの関心は、エンドツーエンド ｜パラダイムの破壊という犠牲を払ってまでも、最重要視されている。 ｜この例の一つがファイアウォール〜外部から企業の中への許可されていない ｜アクセスを抑止する装置〜である。我々の新しいプロトコルFEP（ファイア ｜ウォール強化プロトコル)は、ファイアウォールによって構築されたセキュリ ｜ティレベルを維持しつつ、エンドツーエンドモデルを復活させるために設計 ｜された。 To see how powerful the end-to-end model is consider the following example. If Scott and Mark have a good idea and some implementation talent, they can create an artifact, use it, and send it to their friends. If it turns out to be a good idea these friends can adopt it and maybe make it better. Now enter the Firewall: if Mark happens to work at a company that installs a Firewall, he can't experiment with his friend Scott. Innovation is more difficult, maybe impossible. What business is it of an IT manager if Scott and Mark want to do some experiments to enable them to better serve their users? This is how the web was created: one guy with talent, a few good ideas, and the ability to innovate. ｜エンドツーエンドモデルがいかにパワフルであるかを知るために、 ｜以下の例について考察する。もし、スコットとマークが良いアイデアと ｜それを実装するいくらかの才能を持っているとすると、彼らは製作物を ｜作成し、それを使い、それを彼らの友人たちに送ることができる。もし ｜それが彼らの友人にとっても良いアイデアと判明したならば、彼らは ｜採用し、さらにそれをより良くすることができるであろう。今、ファイア ｜ウォールが入れられる：もしマークがファイアウォールがインストール ｜された会社で偶然にも働くことなったならば、彼は友人のスコットと ｜それを実験することができない。革新はより難しく、おそらく不可能に ｜なる。もしスコットとマークがそれらがよりよくそのユーザに役立つことを ｜可能にするために幾つかの実験を行ないたいとするならば、ITマネージャ ｜の仕事は何であるか？このようにして、ウェブは作成された：才能を持った ｜奴と、少しのよいアイデアと、革新を可能にするために。 Firewalls are important, and we do respect the right of anybody to protecting themselves any way they want (as long as others are not inconvenienced). Firewalls work, and have a place in the Internet. However, Firewalls are built to protect from external threats, not internal ones. Our proposed protocol does not break the security model of the Firewall; it still protects against all external risks that a particular Firewall can protect against. For our protocol to work someone inside the Firewall must run an application level protocol that can access TCP port 80. Our concept allows a consistent level of security while bypassing the IT manager in charge of the Firewall. We offer freedom to innovate without additionally compromising external security, and the best part, no need to waste time involving any managers for approval. ｜ファイアウォールは重要で、我々は、誰もが、どのような方法ででも ｜（他の者が迷惑しない限り）彼ら自分自身が保護されたいという正当な要求 ｜を尊重している。ファイアウォールは動作し、インターネット内に存在し ｜つづける。しかしながらファイアウォールは外部からの脅威から保護する ｜ために構築され、内部からのそれのためではない。我々の提案するプロト ｜コルはファイアウォールのセキュリティモデルを破壊するものではない； ｜これは全ての外部からの危険、特にファイアウォールが保護できるものに ｜対して、なお保護する。我々のプロトコルが作動するために、ファイア ｜ウォールの内側の人は、TCPポート80をアクセスできるアプリケーション ｜レベルプロトコルを作動させなければならない。我々のコンセプトは、 ｜ファイアウォールを預かるITマネージャをバイパスしながらも、一貫した ｜セキュリティレベルを可能にする。我々は外部のセキュリティや、一番 ｜良い部分を悪化させる追加をすることなく、また、承認を得るための ｜管理者を巻き込んだ無駄な時間を費やすことなく革新のための自由を得る。 We got this idea from the increasing number of applications that use HTTP specifically because it can bypass Firewall barriers. This piecemeal deployment of specific applications is not an efficient way to meet the challenge to innovation created by Firewalls. We decided to develop a process by which TCP/IP itself is carried over HTTP. ｜我々は、ファイアウォール障壁をバイパスすることが可能な、HTTPの仕様 ｜を使うアプリケーション数の増加からこのアイデアを得た。これら特定の ｜アプリケーションの断片的な開発は、ファイアウォールによって作り出された ｜革新に対する挑戦に対する効果的な方法ではない。我々は TCP/IPそれ自身が、 ｜HTTPで伝送される方法の開発を決意した。 With this innovation anyone can use any new TCP/IP application immediately without having to go through the laborious process of dealing with Firewall access for the particular application. An unintended byproduct of this proposal is that existing TCP/IP applications can also be supported to better serve the users. With FEP, the users can decide what applications they can run. ｜この革新によって、特定のアプリケーションのためにファイアウォール ｜のアクセスを処理する骨のおれる仕事を行なうことなく、誰でもすぐに ｜新しいTCP/IPアプリケーションを使用することが可能になる。この提案の ｜意図しない副産物はよりよくユーザに役立つために、さらに既存のTCP/IP ｜アプリケーションを支援することができるということである。FEPによって、 ｜ユーザはどのアプリケーションを実行するかを決定することが可能になる。 Our protocol is simple and is partly based on the Eastlake [3] proposal for MIME encoding of IP packets. We use the ubiquitous HTTP protocol format. The IP datagram is carried in the message body of the HTTP message and the TCP packet header information is encoded into HTTP headers of the message. This ASCII encoding of the header fields has many advantages, including human readability, increasing the debuggability of new applications, and easy logging of packet information. If this becomes widely adopted, tools like tcpdump will become obsolete. ｜我々のプロトコルはシンプルで、部分的にはIPパケットのMIMEエン ｜コーディングのためのイーストレイク[3]の提案に基づいている。 ｜我々はどこにでもあるHTTPプロトコルフォーマットを使用する。 ｜IPデータグラムは、HTTPメッセージのメッセージボディで運ばれ、 ｜TCPパケットヘッダ情報はメッセージのHTTPヘッダの中にエンコード ｜される。このヘッダフィールドのASCIIエンコーディングは、人に ｜よる可読性、新しいアプリケーションのデバッグ容易性の向上、更に ｜パケット情報の履歴保存の容易性を含め、多くの利点を持つ。もし ｜これが広く受け入れられるようになれば、tcpdump のようなツールは ｜時代遅れとなるであろう。 3.0 FEP Protocol ｜FEPプロトコル Figure 1 shows a high level view of our protocol. The application (1) in host A (outside the Firewall) sends a TCP/IP datagram to host B (within the firewall). Using a tunnel interface the TCP/IP datagram is routed to our FEP software (2), which encodes the datagram within a HTTP message. Then this message is sent via a HTTP/TCP/IP tunnel (3) to host B on the normal HTTP port (4). When it arrives at host B, this packet is routed via the tunnel to the FEP software (5), which decodes the packet and creates a TCP/IP datagram to insert into host's B protocol stack (6). This packet is routed to the application on host B (7), as if the Firewall (8) never existed. ｜図１は我々のプロトコルの鳥瞰図である。（ファイアウォールの外側の） ｜ホストAのアプリケーション(1)は、（ファイアウォールの内側の）ホストBに ｜TCP/IPデータグラムを送信する。トンネルインタフェースを使用して、 ｜TCP/IPデータグラムは、我々のFEPソフトウェア(2)に向けられ、データグラムは ｜HTTPメッセージの中にエンコードされる。そしてこのメッセージはHTTP/TCP/IP ｜トンネル(3)を経由して、ノーマルHTTPポート(4)の上のホストBに送信される。 ｜ホストBに到着したならば、このパケットはデコードされ、ホストBのプロトコル ｜スタック(6)に挿入するTCP/IPデータグラムを作成する。このパケットはファイア ｜ウォール(8)が存在しないかのようにホストB(7)のアプリケーションに向けられる。 host A host B ---------- ---------- | App | (1) | App | (7) |----------| |----------| | TCP | | TCP | |----------| |----------| | IP | | IP | (6) |----------| |----------| | FEP dvr | (2) | FEP dvr | (5) |----------| |----------| | TCP | | TCP | |----------| |----------| | IP | Firewall (8) | IP | ---------- --- ----------- | (3) | | ^ (4) +---------------->| |-----------------------+ | | | | --- Figure 1 3.1 HTTP Method ｜HTTPメソッド FEP allows either side to look like a client or server. Each TCP/IP packet is sent as either a HTTP GET request or a response to a GET request. This flexibility work well with firewalls that try to verify valid HTTP commands crossing the Firewall stopping the unwanted intercepting of FEP packets. ｜FEPはクライアント、サーバーのどちらに思うことも可能である。各TCP/IP ｜パケットは HTTP GETリクエストあるいはGETリクエストの応答として送ら ｜れる。この柔軟性は、希望しない、FEPパケットの中断を止める、ファイア ｜ウォールを通る正当なHTTPコマンドであるかの確認を行なうファイアウォール ｜でうまく動作する。 3.2 TCP Header Encapsulation: ｜TCPヘッダのカプセル化 The TCP/IP packet is encoded into the HTTP command in two (or optionally three) steps. First, the IP packet is encoded as the message body in MIME format, as specified in [3]. Next, the TCP [4] packet header is parsed and encoded into new HTTP headers. Finally, as an option, the IP header can also be encoded into new optional HTTP headers. Encoding the TCP and optionally the IP header is strictly for human readability, since the entire IP datagram is encoded in the body part of the HTTP command. ｜TCP/IPパケットはHTTPコマンドの中で2（又はオプションで3）ステップで ｜エンコードされる。最初に、IPパケットは[3]で示すような、MIMEフォー ｜マットで、メッセージボディとしてエンコードされる。次に、TCP[4] ｜パケットヘッダは解析され、新しいHTTPヘッダにエンコードされる。最後に ｜オプションとして、IPヘッダは新しいオプショナルHTTPヘッダにエンコード ｜することが可能である。TCPのエンコードと、オプションのIPヘッダは ｜直接、人によって読むことができる、なぜなら全体のIPデータグラムが ｜HTTPコマンドの一部としてボディにエンコードされるからである。 This proposal defines the following new HTTP headers for representing TCP header information. ｜この提案書は、以下の新しいHTTPヘッダをTCPヘッダ情報を表現するために ｜定義する。 TCP_value_opt - This ASCII string represents the encoding type for the TCP fields where a mandatory encoding type is not specified. The legitimate values are: ｜TCP_value_opt - このASCII文字列はエンコーディング形式が規定されない ｜　TCPフィールドのエンコーディング形式を表す。正当な値は： TCP_binary - ASCII representation of the binary representation of the value of the field. ｜TCP_binary - ASCIIはフィールドの値を２進数表現で表している。 TCP_hexed - ASCII representation of the hex representation of the value of the field. ｜TCP_hexed - ASCIIはフィールドの値を16進数表現で表している。 TCP_Sport - The 16-bit TCP Source Port number, encoded as an ASCII string representing the value of port number. ｜TCP_Sport - ポート番号の値をASCII文字列表現でエンコードした、 ｜　16ビットTCP送信元ポート番号。 TCP_Dport - The 16-bit TCP Destination Port number, encoded as an ASCII string representing the value of the port number. ｜TCP_Dport - ポート番号の値をASCII文字列表現でエンコードした、 ｜　16ビットTCP宛先ポート番号 TCP_SeqNum - The 32-bit Sequence Number, encoded as an ASCII string representing the hex value of the Sequence number. This field MUST be sent as lower case because it is not urgent. ｜TCP_SeqNum - シーケンス番号を16進の値で表現したASCII文字列で ｜　エンコードした32ビットシーケンス番号。このフィールドは ｜　緊急でないので、小文字で送信されなければならない[MUST]。 TCP_Ackl - The 32-bit Acknowledgement Number, encoded as ASCII string representing the value of the Acknowledgement number. ｜TCP_Ackl - 確認応答番号の値を表現したASCII文字列でエンコードした、 ｜　32ビット確認応答番号。 TCP_DODO - The 4-bit Data Offset value, encoded as an ASCII string representing the base 32 value of the actual length of TCP header in bits. (Normally this is the Data value times 32.) ｜TCP_DODO - ビットによるTCPヘッダの実際の長さを、32を単位にした値で ｜　表現したASCII文字列でエンコードした4ビットデータオフセット値。 ｜　（通常、データ値は32の倍数である。） TCP_6Os - The 6 reserved bits, encoded as a string of 6 ASCII characters. A "O" ("Oh") represents an "Off" bit and "O" ("Oh") represents an "On" bit. (Note these characters MUST all be sent as "off" and MUST be ignored on receipt.) ｜TCP_60s - 6文字のASCII文字でエンコードされた予約された6ビットで、 ｜　“O”（オー）は“Off”ビットを表し、かつ“O”（オー）は“On” ｜　ビットも表す。（これらのキャラクタは“Off”で全て送らなければ ｜　ならず、受信時に全て無視しなけれなならない。） TCP_FlgBts - The TCP Flags, encoded as the set of 5 comma-separated ASCII strings: [{URG|urg}, {ACK|ack}, {PSH|psh}, {RST|rst}, {SYN|syn}, {FIN|fin}]. The legitimate values are the same as for TCP_value_opt.. Capital letters imply the flag is set, lowercase means the flag is not set. ｜TCP_FlgBts - 以下の5つのカンマで分けられたASCII文字列のセットで ｜　エンコードしたTCPフラグ： [{URG|urg}、{ACK|ack}、{PSH|psh}、 ｜　{RST|rst}、{SYN|syn}, {FIN|fin}]。大文字はフラグがセットされて ｜　いることを示し、小文字はフラグがセットされていないことを意味する。 TCP_Windex - The 16-bit TCP Window Size, encoded as an ASCII string representing the value of the number of bytes in the window. ｜TCP_Windex - ウィンドウのバイト数の値を表現したASCII文字列で ｜　エンコードした、16ビットのTCPウィンドウサイズ。 TCP_Checkit - The 16-bit TCP Checksum field, encoded as an ASCII string representing the decimal value of the ones-complement of the checksum field. ｜TCP_Checkit - チェックサムフィールドの１の補数の10進数表記の値を ｜　ASCII文字列でエンコードした、16ビットTCPチェックサムフィールド。 TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex representation of the value of the field. The hex string MUST be capitalized since it is urgent. ｜TCP_UP - フィールドの値を16進数表現でエンコードした、TCP緊急ポインタ。 ｜　この16進数は、これが緊急であるので、大文字でなければならない[MUST]。 TCP_Opp_Lst - A comma-separated list of any TCP options that may be present. Each option is encoded as an ASCII string representing the name of the option followed by option-specific information enclosed in square brackets. Representative options and their encoding follow, other IP options follow the same form: ｜TCP_Opp_Lst - いくつかのTCPオプションをカンマで区切ったリストで示す。 ｜　各オプションは角括弧で囲まれたオプション記述情報によって、以下の ｜　ASCII文字列でエンコードされる。オプションの記述は以下のように ｜　エンコードはされ、他のIPオプションも同じ形式に従う。 End of Options option: ["End of Options"] ｜オプション終了オプション: ["End of Options"] Window scale option: ["Window scale", shift_count], where shift_count is the window scaling factor represented as the ASCII string in decimal. ｜ウィンドウスケールオプション：["Window scale", shift_count] ｜shift_countは、10進数でのASCII文字列で記述されたスケーリング ｜ファクタである。 3.2 IPv4 Header Encapsulation: ｜IPv4ヘッダのカプセル化 This proposal defines the following new HTTP headers for representing IPv4 header information: ｜この提案書は、以下の新しいHTTPヘッダをIPv4ヘッダ情報を表現するために ｜定義する。 These optional headers are used to encode the IPv4 [5] header for better readability. These fields are encoded in a manner similar to the above TCP header fields. ｜これらのオプショナルヘッダは、より可読性を高めるために IPv4[5]ヘッダを ｜定義する。これらのフィールドはTCPヘッダフィールドの上に同じような手順で ｜エンコードされる。 Since the base IP packet is already present in an HTTP header, the following headers are optional. None, some or all of them may be used depending on the whim of the programmer. ｜基本となるIPパケットが既にHTTPヘッダの中に表現されているので、以下の ｜ヘッダはオプションである。これらの全て又は一部は、プログラマの気分に ｜よって使用される。 IP_value_opt - This ASCII string represents the encoding type for the following fields where a mandatory encoding type is not specified. The legitimate values are the same as for TCP_value_opt. ｜IP_value_opt - このASCII文字列表現は、規定されたエンコーディング ｜　種別が指定されていない以下のフィールドのためのエンコーディング ｜　種別である。正当な値はTCP_value_optと同様である。 IP_Ver - The IP Version number, encoded as an UTF-8 string. The legitimate values for the string are "four", "five", and "six." The encapsulation of the fields in the IP header are defined in this section if the value is "four", and in section 3.3 if the value is "six". Encapsulations for headers with IP_Ver value of "five" will be developed if the right orders are received. Encapsulations for headers with the IP_Ver value of "eight" are empty. Implementations MUST be able to support arbitrary native languages for these strings. ｜IP_Ver - UTF-8文字列でエンコードされたIPバージョン番号。正当な値は ｜　“four”、“five”、“six”である。IPヘッダ内のこのフィールドの ｜　カプセル化は、この値が“four”ならこのセクションに、“six”ならば ｜　セクション3.3にある。IP_verの値が“five”のヘッダのカプセル化は、 ｜　正当な評価がえられたならば開発されるであろう。IP_verの値が“eight” ｜　のヘッダのカプセル化は何もない。実装はこれらの文字列を任意の母国語に ｜　変換したものもサポートしなければならない[MUST]。 IP4_Hlen - The IP Internet Header Length field, it is encoded in the same way as TCP_DODO. ｜IP4_Hlen - TCP_DODOと同様にエンコードされた、IPヘッダ長フィールド。 IP4_Type_of_Service (this name is case sensitive) - This is an obsolete name for a field in the IPv4 header, which has been replaced with IP_$$ and IP_CU. ｜IP4_Type_of_Service （この名前は微妙なケースだ）-　これはIP_$$と ｜　IP_CU で置換された、IPv4ヘッダ内のフィールドの別名である。 IP_$$ - The 6-bit Differentiated Services field, encapsulated as an UTF-8 string representing the name of the DS codepoint in the field. ｜IP_$$ - フィールド内のDSコードポイントの名前をUTF-8文字列表現で ｜　カプセル化した、6ビットのDiffサーブフィールド。 IP_CU - The 2-bit field that was the two low-order bits of the TOS field. Since this field is currently being used for experiments it has to be coded in the most general way possible, thus it is encoded as two ASCII strings of the form "bit0=X" and "bit1=X," where "X" is "on" or "off." Note that bit 0 is the MSB. ｜IP_CU - TOSフィールドの２つの下位２ビットフィールド。現在、この ｜　フィールドは広く実験に使用されているので、“bit0=X”と“bit1=X” ｜　の形で“X”には“on”又は“off”をいれた、2つのASCII文字列で ｜　エンコードされる。ビット0 がMSBであることに注意。 IP4_Total - The 16-bit Total Length field, encoded as an ASCII string representing the value of the field. ｜IP4_Total - フィールドの値を表現したASCII文字列でエンコードした、 ｜　16ビットのトータルレングスフィールド。 IP4_SSN - The IP Identification field, encoded as an ASCII string representing the value of the field. ｜IP4_SSN - フィールドの値を表現したASCII文字列でエンコードした、 ｜　IP識別子フィールド IP4_Flags - The IP Flags, encoded as the set of 3 comma separated ASCII strings: [{"Must Be Zero"}, {"May Fragment"|"Don't Fragment"}, {"Last Fragment"|"More Fragments"}] ｜IP4_Flags - 以下の3つのカンマで分けられたASCII文字列のセットで ｜　エンコードされたIPフラグ。 [{"Must Be Zero"}, {"May Fragment"| ｜　"Don't Fragment"}, {"Last Fragment"|"More Fragments"}] IP4_Frager - The 13-bit Fragment Offset field, encoded as an ASCII string representing the value of the field. ｜IP4_Frager - このフィールドの値をASCII文字列でエンコードした、 　 ｜　13ビットのフラグメントオフセットフィールド。 IP4_TTL - The 8-bit Time-to-Live field, encoded as an UTF-8 string of the form "X hops to destruction." Where "X" is the decimal value -1 of the field. Implementations MUST be able to support arbitrary languages for this string. ｜IP4_TTL - ”宛先へのXホップ”をUTF-8文字列でエンコードした8ビットの ｜　Time-to-Liveフィールド。この“X”はフィールドの10進の値-1である。 ｜　実装では任意の母国語のサポートが可能であること[MUST]。 IP4_Proto - The 8-bit Protocol field, encoded as an UTF-8 string representing the common name for the protocol whose header follows the IP header. ｜IP4_Proto - UTF-8としてエンコードされた、IPヘッダーに続くヘッダの、 ｜　プロトコルの共通の名前を表わす、UTF-8でエンコードした8ビットの ｜　プロトコル・フィールド。 IP4_Checkit - The 16-bit Checksum field, encoded in the same way as TCP_Checkit. ｜IP4_Checkit - TCP_Checkitと同じ方法でエンコードした、16ビットの ｜　チェックサムフィールド。 IP4_Apparent_Source - The 32-bit Source Address field. For user friendliness this is encoded as an UTF-8 string representing the domain name of the apparent sender of the packet. An alternate form, to be used when the domain name itself might be blocked by a firewall programmed to protect the innocence of the corporate users, is an ASCII string representing the dotted quad form of the IPv4 address. ｜IP4_Apparent_Source - 32ビットの送信元アドレスフィールド。ユーザの ｜　便利さのために、これはUTF-8としてコード化され、パケットの明確な ｜　送信機のドメインネームを表わす。ドメインネームそれ自身が企業ユーザを ｜　保護するためにプログラムされたファイアウォールによって隠蔽された場合、 ｜　代替の形として、IPv4アドレスをドット形式で表わしたASCII文字列が ｜　使用される。 IP4_Dest_Addr - The 32-bit Destination Address field, encoded in the same way as is IP4_Apparent_Source. ｜IP4_Dest_Addr - IP4_Apparent_Source　と同じ方法でエンコードした、 ｜　32ビット宛先アドレスフィールド。 IP4_Opp_Lst - A comma-separated list of all IPv4 options that are present. Each option is encoded as an ASCII string representing the name of the option followed by option-specific information enclosed in square brackets. Representative options and their encoding follow, other IP options follow the same form: ｜IP4_Opp_Lst - 全てのIPv4オプションをカンマで区切ったリストで示す。 ｜各オプションは角括弧で囲まれたオプション記述情報によって、以下の ｜オプション名で表現したASCII文字列でエンコードされる。オプションの ｜記述は以下のようにエンコードされ、他のIPオプションも同様である。 End of Options option: ["End of Options"] ｜オプション終了オプション: ["End of Options"] Loose Source Routing option: ["Loose Source Routing", length, pointer, IP4_addr1, IP4_addr2, ...], where length and pointer are ASCII strings representing the value of those fields. ｜ルーズソースルーティングオプション： ["Loose Source Routing", ｜　length, pointer, IP4_addr1, IP4_addr2, ...]、ここで length と ｜　pointer は、これらのフィールドの値を表現したASCII文字列である。 3.3 IPv6 Header Encapsulation: ｜IPv6ヘッダのカプセル化 This proposal defines the following new HTTP headers for representing IPv6 header information: ｜この提案書は、以下の新しいHTTPヘッダをIPv6ヘッダ情報を表現するために ｜定義する。 These optional headers encode the IPv6 [5] header for better readability. These fields are encoded in a manner similar to the above TCP header fields. ｜これらのオプショナルヘッダは、より可読性を高めるために IPv6[5]ヘッダを ｜定義する。これらのフィールドはTCPヘッダフィールドの上に同じような手順で ｜エンコードされる。 Since the base IP packet is already present in an HTTP header the following headers are optional. None, some or all of them may be used depending on the whim of the programmer. At this time only the base IPv6 header is supported. If there is sufficient interest, support will be developed for IPv6 extension headers. ｜基本となるIPパケットが既にHTTPヘッダの中に表現されているので、以下の ｜ヘッダはオプションである。これらの全て又は一部は、プログラマの気分に ｜よって使用される。今現在は、基本的なIPv6ヘッダだけをサポートしている。 ｜もしこれに十分な注目があれば、IPv6拡張ヘッダも開発されサポートされるで ｜あろう。 IP_$$ - the 6-bit Differentiated Services field - see above ｜IP_$$ - 6ビットのDiffサーブフィールド - 上を見よ。 IP_CU - the 2-bit unused field - see above ｜IP_CU - 2ビットの未使用フィールド - 上を見よ。 IP6_Go_with_the_Flow - The 20-bit Flow Label field. Since this field is not currently in use it should be encoded as the UTF-8 string "do not care". ｜IP6_Go_with_the_Flow - 20ビットのフローラベルフィールド。このフィールド ｜　は現在使用されていないので、“do not care”のUTF-8文字列でエンコード ｜　される。 IP6_PayLd - The 16-bit Payload Length field, encoded as an ASCII string representing the value of the field. The use of FEP with IPv6 jumbograms is not recommended. ｜IP6_PayLd - フィールドの値をASCII文字列表現でエンコードした、16ビットの ｜　ペイロード長。FEPを使用したIPv6ジャンボグラムは推奨されない。 IP6_NxtHdr - The 8-bit Next Header field, encoded in the same way as IP4_Proto. ｜IP6_NxtHdr - IP4_Protoと同じ方法でエンコードした、8ビットのネクスト ｜　ヘッダフィールド。 IP6_Hopping - The 8-bit Hop Limit field, encoded in the same way as IP4_TTL. ｜IP6_Hopping - IP4_TTLと同じ方法でエンコードした、8ビットのホップ ｜　リミットフィールド。 IP6_Apparent_Source - The 128-bit Source Address field. For user friendliness, this is encoded as an UTF-8 string representing the domain name of the apparent sender of the packet. An alternate form, to be used when the domain name itself might be blocked by a Firewall programmed to protect the innocence of the corporate users, is an ASCII string representing any one of the legitimate forms of representing an IPv6 address. ｜IP6_Apparent_Source - 128ビットの送信元アドレスフィールド。ユーザの ｜　便利さのために、これはUTF-8としてコード化され、パケットの明確な ｜　送信機のドメインネームを表わす。ドメインネームそれ自身が、企業 ｜　ユーザを保護するためにプログラムされたファイアウォールによって ｜　隠蔽された場合、代替の形として、IPv4アドレスをドット形式で ｜　表わしたASCII文字列が使用される。 IP6_Dest_Addr - The 128-bit Destination Address field, encoded the same way as IP6_Apparent_Source. ｜IP6_Dest_Addr - IP6_Apparent_Source と同じ方法でエンコードした、 ｜　128ビットの宛先アドレス。 3.4 TCP Header Compression ｜TCPヘッダ圧縮 Compressing TCP headers in the face of a protocol such as this one that explodes the size of packets is silly, so we ignore it. ｜このようなパケットサイズを爆発させるようなプロトコルに対して、TCP ｜ヘッダを圧縮することは愚かであり、よって我々はこれを無視する。 4.0 Security Considerations ｜セキュリティに関する考察 Since this protocol deals with Firewalls there are no real security considerations. ｜このプロトコルはファイアウォールを扱うので、真のセキュリティの ｜考察はない。 5.0 Acknowledgements ｜謝辞 We wish to thank the many Firewall vendors who have supported our work to re-enable the innovation that made the Internet great, without giving up the cellophane fig leaf of security that a Firewall provides. ｜我々は、ファイアウォールが提供する不完全な、大事なものを隠す機能 ｜（／セロハン製のイチジクの葉）を放棄することなく、インターネット ｜をグレートなものにするための革新を再度可能にするための我々の仕事を ｜支援してくれた多くのファイアウオール・ベンダーに感謝したい。 6.0 Authors' Addresses ｜著者の連絡先 Mark Gaynor Harvard University Cambridge MA 02138 EMail gaynor@eecs.harvard.edu Scott Bradner Harvard University Cambridge MA 02138 Phone +1 617 495 3864 EMail sob@harvard.edu References ｜参考 [1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [2] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design". 2nd International Conference on Distributed Systems, Paris, France, April 1981. [3] Eastlake, D., "IP over MIME", Work in Progress. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [6] Clark, D. and M. Blumenthal, "Rethinking the Design of the Internet: The end-to-end argument vs. the brave new world". 2000. Full Copyright Statement ｜著作権全文 Copyright (C) The Internet Society (2001). 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. 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. Acknowledgement ｜謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. ｜RFCエディタの仕事のための資金は、現在インターネットソサエティに ｜よって提供されている。 -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。