はじめに
- この文書は RFC3093 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
Firewall Enhancement Protocol (FEP)（ファイアーウォール拡張プロトコル）
- Network Working Group
- Request for Comments: 3093
- Category: Informational
- M. Gaynor
- S. Bradner
- Harvard University
- 1 April 2001
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]。
しかし、近年のファイアウォール技術の発展は、このモデルを変化させ、イノベーションを阻害することが明らかになっている。
我々は、ファイアウォールのセキュリティモデルを侵害することなく、イノベーションを可能にするファイアウォール拡張プロトコル (Firewall Enhancement Protocol; FEP) を提案する。
FEP は、ファイアウォールオペレータの協力なしに、あらゆるアプリケーションにファイアウォールを通過させることができる。
HTTP パケットは通常ファイアウォールを通過することができるので、私たちの方法論は、任意のアプリケーション層 TCP/UDP パケットをハイパーテキスト転送プロトコル (HTTP) に重ね合わせることである。
ファイアウォールは外部からの攻撃を阻止し、内部からの脅威を無視するように設計されているため、この方式はファイアウォールの実際のセキュリティ上の有用性を侵害するものではない。
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」は RFC 2119 に記載されている通りに解釈される。
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 年も前に、通信事業者がインターネットは企業環境には使えないと主張していたことを考えると、インターネットはうまくいっていると言えるだろう。
これには多くの理由がある。特に強力なのは、Reed、Seltzer、Clark によって議論されたエンドツーエンドの議論である [2]。
末端での革新は、これまで考えられていた以上の価値を生み出す非常に強力な方法論であることが証明されている。
しかし、Clark が [6] で指摘しているように、世界は変化している。
企業の世界がインターネットに接続されたことで、エンドツーエンドのパラダイムを壊すことを犠牲にしてでも、セキュリティの懸念が最優先されるようになった。
その一例がファイアウォールであり、企業への部外者の不正アクセスを防止する装置である。
我々の新しいプロトコル、ファイアーウォール拡張プロトコル (Firewall Enhancement Protocol; 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 エンコーディングに関する Eastlake [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.
図 1 は、我々のプロトコルのハイレベルなビューを示したものである。
ホスト A (ファイアウォールの外側) のアプリケーション (1) は、ホスト B (ファイアウォールの内側) へ TCP/IP データグラムを送信する。
トンネルインターフェイスを使用して、TCP/IP データグラムは、HTTP メッセージ内でデータグラムをエンコードする我々の FEP ソフトウェア (2) にルーティングされる。
このメッセージは、HTTP/TCP/IP トンネル (3) を経由して、通常の HTTP ポート (4) 上のホスト B に送信される。
ホスト B に到着すると、このパケットはトンネル経由で FEP ソフトウェア (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
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 パケットは 2 段階 (オプションで 3 段階) で HTTP コマンドにエンコードされる。
まず、IP パケットは [3] で規定されているように 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_binary - ASCII representation of the binary representation of the value of the field.
TCP_hexed - ASCII representation of the hex representation of the value of the field.
この ASCII 文字列は、必須の符号化方式が指定されていない TCP フィールドの符号化方式を表す。
正当な値は以下の通りである：
-
TCP_binary - フィールドの値のバイナリ表現をASCIIで表現したもの。
-
TCP_hexed - フィールドの値の16進数表現のASCII表現。
TCP_Sport
The 16-bit TCP Source Port number, encoded as an ASCII string representing the value of port number.
16 ビットの TCP ソースポート番号。ポート番号の値を表す ASCII 文字列としてエンコードされる。
TCP_Dport
The 16-bit TCP Destination Port number, encoded as an ASCII string representing the value of the port number.
16 ビットの TCP 宛先ポート番号。ポート番号の値を表す ASCII 文字列としてエンコードされる。
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.
32ビットのシーケンス番号。シーケンス番号の 16 進数値を表す ASCII 文字列としてエンコードされる。
このフィールドは、緊急性がないため、小文字で送信されなければならない (MUST)。
TCP_Ackl
The 32-bit Acknowledgement Number, encoded as ASCII string representing the value of the Acknowledgement number.
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.)
4 ビットのデータオフセット値で、TCP ヘッダーの実際の長さを 32 ビットで表した ASCII 文字列としてエンコードされる。
(通常、これは Data の値の 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.)
ASCII 文字列として符号化された予約ビット 6 個。
「O」（「Oh」）は「Off」ビットを表し、「O」（「Oh」）は「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}].
Capital letters imply the flag is set, lowercase means the flag is not set.
TCP Flags。カンマで区切られた 5 つの ASCII 文字列のセットとしてエンコードされている。[{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.
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.
16 ビットの TCP チェックサムフィールドで、チェックサムフィールドの 1 補数の 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.
16 ビットの TCP 緊急ポインターで、フィールドの値の 16 進表現としてエンコードされる。
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:
End of Options option:
["End of Options"]Window scale option:
["Window scale", shift_count], whereshift_countis the window scaling factor represented as the ASCII string in decimal.
TCP オプションのカンマ区切りのリスト。
各オプションは、オプション名と角括弧で囲まれたオプション固有の情報を表す ASCII 文字列としてエンコードされる。
代表的なオプションとそのエンコーディングを次に示し、他の IP オプションも同じ形式に従う。
-
オプションの終了：
["End of Options"] -
ウィンドウスケールオプション：
["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:
本提案では、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.
この 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.
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.
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.
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.
6 ビットの Differentiated Services フィールドで、フィールド内の DS コードポイント名を表す UTF-8 文字列としてカプセル化される。
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.
TOS フィールドの下位 2 ビットであった 2 ビットフィールド。
このフィールドは現在実験に使用されているため、最も一般的な方法でコード化する必要があり、"bit0=X" と "bit1=X" という形式の 2 つの ASCII 文字列としてコード化されている。"X" は "on" または "off" である。
ビット 0 は MSB であることに注意すること。
IP4_Total
The 16-bit Total Length field, encoded as an ASCII string representing the value of the field.
16 ビットのトータル長フィールドで、フィールドの値を表す ASCII 文字列としてエンコードされる。
IP4_SSN
The IP Identification field, encoded as an ASCII string representing the value of the field.
IP の ID フィールド。フィールドの値を表す 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"}]
IP フラグ。カンマで区切られた 3 つの ASCII 文字列のセットとしてエンコードされる：[{"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.
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.
8 ビットの Time-to-Live フィールド。"X hops to destruction" という形式の UTF-8 文字列としてエンコードされる。
ここで、"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.
8 ビットのプロトコルフィールドは、IP ヘッダーの後に続くヘッダーを持つプロトコルの共通名を表す UTF-8 文字列としてエンコードされる。
IP4_Checkit
The 16-bit Checksum field, encoded in the same way as TCP_Checkit.
TCP_Checkit と同じ方法でエンコードされた 16 ビットの Checksum フィールド。
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.
32 ビットのソースアドレスフィールド。
ユーザーフレンドリーなように、これはパケットの送信者と思われるドメイン名を表す UTF-8 文字列としてエンコードされる。
企業ユーザーの無実を守るためにプログラムされたファイアウォールによってドメイン名自体がブロックされる可能性がある場合に使用される別の形式は、IPv4 アドレスのドットで区切られた 4 つの数字で表す形式の ASCII 文字列である。
IP4_Dest_Addr
The 32-bit Destination Address field, encoded in the same way as is IP4_Apparent_Source.
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:
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.
存在するすべての IPv4 オプションのカンマ区切りのリスト。
各オプションは、オプション名と角括弧で囲まれたオプション固有の情報を表す ASCII 文字列として符号化される。
代表的なオプションとそのエンコーディングが続き、他の IP オプションも同じ形式である。
- オプションの終了：
["End of Options"] - ルーズソースルーチングオプション：
["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:
本提案では、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
6 ビットの Differentiated Services フィールド - 上記参照
IP_CU
the 2-bit unused field - see above
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".
20 ビットのフローラベルフィールド。
このフィールドは現在使用されていないため、UTF-8 文字列 "do not care" として符号化されるべきである。
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.
16 ビットのペイロード長フィールドで、フィールドの値を表す ASCII 文字列としてエンコードされる。
IPv6 のジャンボグラムで FEP を使用することは推奨されない。
IP6_NxtHdr
The 8-bit Next Header field, encoded in the same way as IP4_Proto.
8 ビットの Next Header フィールドで、IP4_Proto と同じ方法でエンコードされる。
IP6_Hopping
The 8-bit Hop Limit field, encoded in the same way as IP4_TTL.
8 ビットの Hop Limit フィールドで、IP4_TTL と同じ方法でエンコードされる。
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.
128 ビットのソースアドレスフィールド。
ユーザーフレンドリーなように、これはパケットの送信者と思われるドメイン名を表す UTF-8 文字列としてエンコードされる。
企業ユーザーの無実を守るためにプログラムされたファイアウォールによってドメイン名自体がブロックされる可能性がある場合に使用される代替形式は、IPv6 アドレスを表す正当な形式のいずれかを表す ASCII 文字列である。
IP6_Dest_Addr
The 128-bit Destination Address field, encoded the same way as IP6_Apparent_Source.
128 ビットの宛先アドレスフィールドで、IP6_Apparent_Source と同じようにエンコードされる。
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.