[要約] RFC 3093は、ファイアウォールの機能を強化するためのプロトコルであり、要約すると以下のようになります。1. FEPは、ファイアウォールの機能を拡張するためのプロトコルです。 2. 目的は、ファイアウォールの性能やセキュリティを向上させることです。 3. FEPは、ファイアウォールの管理者がより効果的にネットワークトラフィックを制御できるように支援します。
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.
Copyright（c）The Internet Society（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）を提案します。ファイアウォールオペレーターからの協力がないため、FEPにより、あらゆるアプリケーションがファイアウォールを通過できます。私たちの方法論は、HTTPパケットが通常ファイアウォールを通過できるため、HyperText Transfer Protocol（HTTP）プロトコル上のアプリケーションレイヤー伝送制御プロトコル/ユーザーデータグラムプロトコル（TCP/UDP）パケットをレイヤー化することです。ファイアウォールは外部からの攻撃を妨害し、内部からの脅威を無視するように設計されているため、このスキームはファイアウォールの実際のセキュリティの有用性に違反しません。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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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年も前に電話会社が企業環境では機能しないと主張していたことを考えると、順調に進んでいます。これには多くの理由があります。特に強力なのは、Reed、Seltzer、およびClark [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.
エンドツーエンドモデルがどれほど強力であるかを確認するには、次の例を考慮してください。スコットとマークが良いアイデアといくつかの実装の才能を持っている場合、彼らはアーティファクトを作成し、それを使用し、友人に送ることができます。これらの友人がそれを採用し、それを改善することができるのが良い考えであることが判明した場合。ここでファイアウォールを入力します。マークがたまたまファイアウォールをインストールしている会社で働いている場合、彼は友人のスコットと実験できません。イノベーションはより困難であり、おそらく不可能です。ScottとMarkがユーザーに適切にサービスを提供できるようにいくつかの実験をしたい場合、ITマネージャーのビジネスはどのようなビジネスですか？これがWebの作成方法です。才能を持つ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エンコードに関するEastLake [3]提案に基づいています。ユビキタスHTTPプロトコル形式を使用します。IPデータグラムは、HTTPメッセージのメッセージ本文に掲載され、TCPパケットヘッダー情報はメッセージのHTTPヘッダーにエンコードされています。ヘッダーフィールドのこのASCIIエンコードには、人間の読みやすさ、新しいアプリケーションのデバッグ性の向上、パケット情報の簡単な記録など、多くの利点があります。これが広く採用されると、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）は、TCP/IPデータグラムをホストB（ファイアウォール内）に送信します。トンネルインターフェイスを使用して、TCP/IPデータグラムはFEPソフトウェア（2）にルーティングされ、HTTPメッセージ内のデータグラムをエンコードします。次に、このメッセージは、HTTP/TCP/IPトンネル（3）を介して送信され、通常のHTTPポート（4）でBをホストします。ホストBに到着すると、このパケットはトンネルを介してFEPソフトウェア（5）にルーティングされます（5）。これにより、パケットがデコードされ、TCP/IPデータグラムが作成され、ホストのBプロトコルスタックに挿入されます（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コマンドを確認しようとするファイアウォールでうまく機能します。
3.2 TCP Header Encapsulation:
3.2 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パケットは、2つ（またはオプションで3つの）ステップでHTTPコマンドにエンコードされます。まず、[3]で指定されているように、IPパケットはMime形式のメッセージ本文としてエンコードされます。次に、TCP [4]パケットヘッダーが解析され、新しいHTTPヘッダーにエンコードされます。最後に、オプションとして、IPヘッダーを新しいオプションのHTTPヘッダーにエンコードすることもできます。IPデータグラム全体がHTTPコマンドのボディ部分にエンコードされているため、TCPおよびオプションで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 -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 -32ビットシーケンス番号。シーケンス番号のhex値を表すASCII文字列としてエンコードされています。このフィールドは、緊急ではないため、小文字として送信する必要があります。
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_6OS -6 ASCII文字の文字列としてエンコードされた6つの予約ビット。「o」（「oh」）は「オフ」ビットを表し、「o」（ "oh"）は「on」を表します。（これらのキャラクターはすべて「オフ」として送信され、領収書で無視する必要があります。）
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}、{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-16ビットTCPチェックサムフィールドは、チェックサムフィールドの1つの修正の小数値を表す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進表現としてエンコードされた16ビットTCP緊急ポインター。HEXストリングは緊急であるため大文字にする必要があります。
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:
3.2 IPv4ヘッダーカプセル化：
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」です。IPヘッダー内のフィールドのカプセル化は、値が「4」の場合はこのセクションで定義され、値が「6」の場合はセクション3.3で定義されます。適切な注文を受け取った場合、「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ビットフィールド。このフィールドは現在実験に使用されているため、可能な限り最も一般的な方法でコード化する必要があるため、「bit0 = x」と「bit1 = x」の2つのASCII文字列としてエンコードされます。on "または" off "。ビット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_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-8ビットの時間からliveフィールド。「xは破壊する」フォームのUTF-8文字列としてエンコードされています。ここで、「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-ヘッダーが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アドレスの点線のQuad形式を表す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.
ソースルーティングのルーティングオプション：[「ルーズソースルーティング」、長さ、ポインター、IP4_ADDR1、IP4_ADDR2、...]、長さとポインターはそれらのフィールドの値を表すASCII文字列です。
3.3 IPv6 Header Encapsulation:
3.3 IPv6ヘッダーカプセル化：
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-フィールドの値を表すASCII文字列としてエンコードされた16ビットペイロード長さフィールド。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アドレスを表す正当なフォームのいずれかを表す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ビットの宛先アドレスフィールド。
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ヘッダーを圧縮することはばかげているので、私たちはそれを無視します。
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
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電子メール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.、Reed、D。、およびD. Clark、「システム設計におけるエンドツーエンドの議論」。1981年4月、フランス、パリの分散システムに関する第2回国際会議。
[3] Eastlake, D., "IP over MIME", Work in Progress.
[3] Eastlake、D。、「MimeのIP」、進行中の作業。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] Postel、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] Clark、D。およびM. Blumenthal、「インターネットのデザインを再考する：エンドツーエンドの議論と勇敢な新しい世界」。2000。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。