Network Working Group M. Gaynor
Request for Comments: 3093 S. Bradner
Category: Informational Harvard University
1 April 2001
Firewall Enhancement Protocol (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.
著作権（C）インターネット協会（2001）。全著作権所有。
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）を提案します。ファイアウォールのオペレータからのNO協力を得て、FEPは、任意のアプリケーションがファイアウォールを通過することができます。 HTTPパケットは、典型的にトランジットファイアウォールすることが可能であるので、我々の方法は、任意のアプリケーション層、伝送制御プロトコル/ユーザ・データグラム・プロトコル（TCP / UDP）、ハイパーテキスト転送プロトコル（HTTP）プロトコルを介してパケットを層にあります。ファイアウォールは、外部からの攻撃を阻止し、内部からの脅威を無視するように設計されているので、この方式では、ファイアウォールの実際のセキュリティ有用性に違反しません。それは、ファイアウォールの内側のホストからの協力を必要とするため、FEPの使用は、現在のファイアウォールのセキュリティモデルと互換性があります。 FEPは両方の世界の最高のことができます：ファイアウォールのセキュリティ、および透過的トンネリングは、ファイアウォールを考えました。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
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管理者のどのようなビジネスですか？これは、ウェブが作成された方法である：1人の才能を持つ男、いくつかの良いアイデア、および革新する能力。
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エンコーディングは、人間の読みやすさ、新しいアプリケーションのdebuggabilityが増加し、パケット情報を簡単にログを含め、多くの利点があります。これは、広く採用になった場合は、tcpdumpのようなツールは廃止になります。
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.
図1は、我々のプロトコルの高レベルの図を示しています。 （ファイアウォールの外側）ホストA内のアプリケーション（1）（ファイアウォール内）BをホストするためのTCP / IPデータグラムを送信します。 TCP / IPデータグラムがHTTPメッセージ内のデータグラムをコード我々のFEPソフトウェア（2）にルーティングされるトンネルインターフェイスを使用。このメッセージは、（4）（3）通常のHTTPポートにBをホストするためにHTTP / TCP / IPトンネルを介して送信されます。それがホストBに到達すると、このパケットは、パケットをデコードし、宿主のBのプロトコルスタックに挿入するためのTCP / IPデータグラムを作成FEPソフトウェア（5）へのトンネルを介してルーティングされる（6）。ファイアウォールは、（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
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コマンドを確認してみてくださいファイアウォールでうまく動作します。
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パケットは、2つ（又は必要に応じて3つ）のステップでHTTPコマンドに符号化されます。 [3]で指定されるように、まず、IPパケットは、MIME形式でメッセージボディとして符号化されます。次に、TCP [4]パケットヘッダが解析され、新たなHTTPヘッダに符号化されます。最後に、オプションとして、IPヘッダは、新しいオプションのHTTPヘッダにエンコードすることができます。 TCPをコードし、全体のIPデータグラムがHTTPコマンドの本体部で符号化されるので、IPヘッダは、人間の可読性のために厳密である任意。
This proposal defines the following new HTTP headers for representing TCP header information.
この提案は、TCPヘッダ情報を表現するため、次の新しいHTTPヘッダーを定義します。
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 - フィールドの値の16進表現のASCII表現。
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 - シーケンス番号のHex値を表すASCII文字列として符号化された32ビットのシーケンス番号。それは緊急ではないため、このフィールドは小文字として送らなければなりません。
TCP_Ackl - The 32-bit Acknowledgement Number, encoded as ASCII string representing the value of the Acknowledgement number.
TCP_Ackl - 32ビットの確認応答番号、確認応答番号の値を表すASCII文字列として符号化されます。
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_6Os - 6 ASCII文字の文字列としてエンコード6予約ビット、。 「O」（「あ」）はビット「オン」を表す（「あ」）ビットと「O」「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}]. Capital letters imply the flag is set, lowercase means the flag is not set.
TCP_FlgBts - TCPフラグ、5カンマで区切られたASCII文字列のセットとしてコード化：[{URG | URG}、{ACK | ACK}、{PSH | PSH}、{RST | RST}、{SYN | SYN}、{ 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 - 16ビットTCPウィンドウサイズ、ウィンドウのバイト数の値を表すASCII文字列として符号化されます。
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 - 16ビットTCPチェックサムフィールド、チェックサムフィールドのうち、補体の10進値を表すASCII文字列として符号化されます。
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進表現として符号化されます。それが緊急であるため、16進数文字列は大文字でなければなりません。
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"]
オプションオプションの終わり：[「オプションの終わり」]
Window scale option: ["Window scale", shift_count], where shift_count is the window scaling factor represented as the ASCII string in decimal.
ウィンドウスケールオプション：[「ウィンドウスケール」、ある。shift_count]、ある。shift_countは10進数でASCII文字列として表現ウィンドウ・スケーリング係数です。
This proposal defines the following new HTTP headers for representing IPv4 header information:
この提案は、IPv4ヘッダ情報を表現するため、次の新しいHTTPヘッダーを定義します。
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バージョン番号、。文字列のための正当な値は「4」、「5」であり、「6。」値が「4」である場合、IPヘッダ内のフィールドのカプセル化は、このセクションで定義され、セクション3.3の値が「6」である場合。右の注文が受信された場合、「5」のIP_Ver値を持つヘッダのカプセル化が開発されます。 「8」のIP_Ver値を持つヘッダのカプセル化は空です。実装は、これらの文字列のための任意のネイティブ言語をサポートできなければなりません。
IP4_Hlen - The IP Internet Header Length field, it is encoded in the same way as TCP_DODO.
IP4_Hlen - IPインターネットヘッダ長フィールドは、それがTCP_DODOと同じ方法で符号化されています。
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ビットの差別化サービスフィールド、。
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フィールドの下位2ビットであった2ビットのフィールド。このフィールドは、現在の実験に使用されているので、それはこのようにして、それがフォームの2つのASCII文字列として符号化され、可能な限り最も一般的な方法で符号化されなければならない「ビット0 = X」および「ビット1は= X」、「X」は "でありますオン」または 『オフ。』そのビット0がMSBであることに注意してください。
IP4_Total - The 16-bit Total Length field, encoded as an ASCII string representing the value of the field.
IP4_Total - 16ビット全長フィールド、フィールドの値を表すASCII文字列として符号化されます。
IP4_SSN - The IP Identification field, encoded as an ASCII string representing the value of the field.
IP4_SSN - IP識別フィールド、フィールドの値を表すASCII文字列として符号化されます。
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 - IPフラグ、3コンマのセットは、ASCII文字列を区切りとしてエンコード：[{「ゼロでなければならない」}、{「フラグメントがある」|「フラグメントはいけない」}、{「最後のフラグメント」|「ほかのかけら」 }]
IP4_Frager - The 13-bit Fragment Offset field, encoded as an ASCII string representing the value of the field.
IP4_Frager - 13ビットのフラグメントオフセットフィールド、フィールドの値を表すASCII文字列として符号化されます。
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 - 8ビットのタイム・ツー・ライブ・フィールド、フォームのUTF-8文字列としてエンコードされた「Xは破壊にホップ。」どこで「X」は、フィールドの小数点値-1です。実装は、この文字列の任意の言語をサポートできなければなりません。
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 - 8ビット・プロトコル・フィールド、ヘッダ、IPヘッダを以下のプロトコルの共通名を表すUTF-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 - と同様に符号化された32ビットの宛先アドレスフィールドは、IP4_Apparent_Sourceあります。
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"]
オプションオプションの終わり：[「オプションの終わり」]
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.
長さとポインタがそれらのフィールドの値を表すASCII文字列である[「ルーズソースルーティング」、長さ、ポインタ、IP4_addr1、IP4_addr2、...]、：ルーズソースルーティングオプション。
This proposal defines the following new HTTP headers for representing IPv6 header information:
この提案は、IPv6ヘッダー情報を表すために、次の新しいHTTPヘッダーを定義します。
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ビットの差別化サービスフィールド - 上記参照
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ビットのフローラベルフィールド。このフィールドは、現在使用されていないので、それは「気にしない」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 - 16ビットのペイロード長フィールド、フィールドの値を表すASCII文字列として符号化されます。 IPv6ジャンボグラムとFEPの使用は推奨されません。
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文字列としてエンコードされます。ドメイン名自体は、ファイアウォールによってブロックされる可能性があるときに使用する代替形式は、企業ユーザーの無実を保護するためにプログラムされ、IPv6アドレスを表すの合法的な形のいずれか1つを表すASCII文字列です。
IP6_Dest_Addr - The 128-bit Destination Address field, encoded the same way as IP6_Apparent_Source.
IP6_Dest_Addr - 128ビットの宛先アドレスフィールドには、IP6_Apparent_Sourceと同じようにエンコードされました。
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.
このようなパケットのサイズは愚かであるので、我々はそれを無視爆発この1などのプロトコルの顔にTCPヘッダを圧縮します。
Since this protocol deals with Firewalls there are no real security considerations.
ファイアウォールでこのプロトコルディールので、本当のセキュリティ上の考慮事項はありません。
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.
私たちは、ファイアウォールが提供するセキュリティのセロハンイチジクの葉をあきらめずに、インターネットは偉大作っ革新を再度有効にするには、私たちの仕事を支えてきた多くのファイアウォールベンダーに感謝したいです。
Mark Gaynor Harvard University Cambridge MA 02138
マーク・ゲイナーハーバード大学ケンブリッジMA 02138
EMail gaynor@eecs.harvard.edu
Eメールgaynor@eecs.harvard.edu
Scott Bradner Harvard University Cambridge MA 02138
スコット・ブラッドナーハーバード大学ケンブリッジMA 02138
Phone +1 617 495 3864 EMail sob@harvard.edu
電話+1 617 495 3864 Eメールsob@harvard.edu
References
リファレンス
[1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[1]大工、B.、 "インターネットの透明性"、RFC 2775、2000年2月。
[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.
[2] Saltzer、J.、リード、D.、およびD.クラーク、 "システム設計におけるエンド・ツー・エンドの引数"。分散システム、パリ、フランス、1981年4月に第2回国際会議。
[3] Eastlake, D., "IP over MIME", Work in Progress.
[3]イーストレイク、D.、 "IP MIMEオーバー" が進行中で働いています。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[6] Clark, D. and M. Blumenthal, "Rethinking the Design of the Internet: The end-to-end argument vs. the brave new world". 2000.
[6]「インターネットのデザイン再考：勇敢な新しい世界対エンド・ツー・エンドの引数を」クラーク、D.とM.ブルーメンソール、。 2000。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。