RFC3093 日本語訳
3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. April 1 2001. (Format: TXT=22405 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Gaynor
Request for Comments: 3093 S. Bradner
Category: Informational Harvard University
1 April 2001
コメントを求めるワーキンググループM.ゲイナー要求をネットワークでつないでください: 3093秒間ブラドナーカテゴリ: 情報のハーバード大学2001年4月1日
Firewall Enhancement Protocol (FEP)
ファイアウォールエンハンスプロトコル(FEP)
Status of this Memo
この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)インターネット協会(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.
終わりから終わりへのインターネットのアーキテクチャを通したインターネットTransparencyは広大な新技術の、そして、サービス[1]の革新を許しました。 しかしながら、Firewall技術における最近の進展は、このモデルを変更して、革新を抑制するために示されました。 私たちは、Firewallの機密保護モデルに違反しないで革新を許すために、Firewall Enhancementプロトコル(FEP)を提案します。 ファイアウォールオペレータからの協力がなければ、FEPはどんなアプリケーションにもFirewallを横断させます。 私たちの方法論はHyperText Transferプロトコル(HTTP)プロトコルの上でどんな応用層通信制御プロトコル/ユーザー・データグラム・プロトコル(TCP/UDP)パケットも層にすることです、HTTPパケットがトランジットFirewallsに通常できるので。 この体系はFirewallの実際のセキュリティの有用性に違反しません、Firewallsが外部から攻撃を阻んで、中から脅威を無視するように設計されているので。 Firewallの中のホストから協力を必要とするので、FEPの使用は現在のFirewall機密保護モデルと互換性があります。 FEPは両方の最善な世界を許容します: ファイアウォールのセキュリティ、およびファイアウォールであると考えられた透明なトンネリング。
1.0 Terminology
1.0 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Gaynor & Bradner Informational [Page 1] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[1ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
2.0 Introduction
2.0 序論
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]で注意するように世界は変化します。 インターネットへの実業界の接続によると、安全上の配慮は最高のになりました、終わりから終わりへのパラダイムを破ることを犠牲にしてさえ。 この1つの例がFirewallです--不正アクセスから会社に部外者を防ぐデバイス。 私たちの新しいプロトコル(Firewall Enhancementプロトコル(FEP))は、Firewallsによって作成されたセキュリティのレベルを維持している間、終わりまでの終わりのモデルを返すように設計されています。
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.
終わりから終わりへのモデルがどれくらい強力であるかを確認するには、以下の例を考えてください。 スコットとマークに名案と何らかの実装才能があるなら、彼らは、友人に人工物を作成して、それを使用して、それを送ることができます。 名案であると判明するなら、これらの友人は、それを採用して、多分それをより良くすることができます。 今度は、Firewallに入ってください: マークがFirewallをインストールする会社でたまたま働いているなら、彼は彼の友人スコットを実験できません。 多分、革新は、より難しくて、不可能です。 スコットとマークがいくつかをしたいならどんなビジネスが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.
ファイアウォールは重要です、そして、私たちは彼らが欲しいどんな方法でも我が身をかばうのにだれの右を尊敬します(他のものが迷惑をかけられない限り)。 ファイアウォールは、インターネットを扱って、位置を占めます。 しかしながら、Firewallsは、内部のものではなく、外的脅威から保護するために造られます。 私たちの提案されたプロトコルはFirewallの機密保護モデルを壊しません。 それはまだ、特定のFirewallが守ることができるすべての外部の危険から守っています。 私たちのプロトコルがFirewallの中でだれかを働かせるのがTCPポート80にアクセスできるアプリケーションレベルプロトコルを実行しなければなりません。 私たちの概念はFirewallを担当して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.
私たちはFirewallバリアを特に迂回させることができるのでHTTPを使用するアプリケーションの増加する数からこの考えを得ました。 特定のアプリケーションのこのばらばらの展開はFirewallsによって引き起こされた革新への挑戦を満たす効率的な方法ではありません。 私たちは、TCP/IP自体がHTTPの上まで運ばれるプロセスを開発すると決めました。
Gaynor & Bradner Informational [Page 2] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[2ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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.
この革新で、すぐFirewallアクセスに対処する困難なプロセスを通る必要はなくて、だれでも特定用途にどんな新しい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のようなツールは時代遅れになるでしょう。
3.0 FEP Protocol
3.0 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(Firewallの外の)のアプリケーション(1)はホストB(ファイアウォールの中の)にTCP/IPデータグラムを送ります。 トンネルのインタフェースを使用して、TCP/IPデータグラムは私たちのFEPソフトウェア(2)に発送されます。(それは、HTTPメッセージの中でデータグラムをコード化します)。 そして、正常なHTTPポート(4)でHTTP/TCP/IPトンネル(3)を通してこのメッセージをホストBに送ります。 ホストBに到着するとき、このパケットは、FEPソフトウェア(5)へのトンネルを通って発送されて、ホストBのプロトコル・スタック(6)に挿入するTCP/IPデータグラムを作成します。ソフトウェアはパケットを解読します。 まるでFirewall(8)が決して存在していないかのようにこのパケットはホストB(7)におけるアプリケーションに発送されます。
Gaynor & Bradner Informational [Page 3] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[3ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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
ホストAホストB---------- ---------- | 装置| (1) | 装置| (7) |----------| |----------| | TCP| | TCP| |----------| |----------| | IP| | IP| (6) |----------| |----------| | FEP dvr| (2) | FEP dvr| (5) |----------| |----------| | TCP| | TCP| |----------| |----------| | IP| ファイアウォール(8)| IP| ---------- --- ----------- | (3) | | ^ (4) +---------------->| |-----------------------+ | | | | --- 図1
3.1 HTTP Method
3.1 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はどちらの側をもクライアントかサーバに似させます。HTTP GET要求か応答のどちらかとしてそれぞれのTCP/IPパケットをGET要求に送ります。 よく有効なHTTPについて確かめようとするファイアウォールによるこの柔軟性仕事は、FEPパケットの求められていない妨害を止めるFirewallに交差しながら、命令します。
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におけるHTTPコマンドにコード化される、(任意に、3) 踏みます。 まず最初に、IPパケットはMIME形式におけるメッセージ本体、指定にされるとして[3]でコード化されます。 次に、TCP[4]パケットのヘッダーは、新しいHTTPヘッダに分析されて、コード化されます。 また、最終的に、オプションとして、新しい任意のHTTPヘッダにIPヘッダーをコード化できます。 任意にTCPをコード化して、IPヘッダーは厳密な人間の読み易さに賛成します、全体のIPデータグラムがHTTPコマンドの身体の部分でコード化されるので。
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_値の_は選ばれます--このASCIIストリングは義務的なコード化しているタイプが指定されないTCP分野のためのコード化しているタイプの代理をします。 正統の値は以下の通りです。
Gaynor & Bradner Informational [Page 4] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[4ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
TCP_binary - ASCII representation of the binary representation of the
value of the field.
TCP_バイナリー--分野の価値の2進法表示のASCII表現。
TCP_hexed - ASCII representation of the hex representation of the
value of the field.
魔法をかけられたTCP_--分野の価値の十六進法表現の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 Source Port番号。
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 Destination Port番号。
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--Sequence Numberであって、Sequence番号の十六進法値を表すASCIIストリングとしてコード化された32ビット。 それが緊急でないので、小文字としてこの野原を送らなければなりません。
TCP_Ackl - The 32-bit Acknowledgement Number, encoded as ASCII string
representing the value of the Acknowledgement number.
TCP_Ackl--Acknowledgement Numberであって、Acknowledgement番号の値を表す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ビットのData Offset値。 (通常、これは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.)
TCP_6Os--6は一連の6人のASCII文字としてコード化されたビットを予約しました。 「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}]. Capital letters imply the flag is set,
lowercase means the flag is not set.
TCP_FlgBts--5個のコンマで切り離されたASCIIストリングのセットとしてコード化されたTCP Flags: [フィン| URG| urg、ACK| ack、PSH| psh、RST| rst、SYN| syn、フィン。] 大文字は、旗が設定されるのを含意して、小文字で印刷します。設定されて、旗がないことを意味します。
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--TCP Window Sizeであって、窓のバイト数の値を表すASCIIストリングとしてコード化された16ビット。
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--チェックサム分野のもの補数のデシマル値を表すASCIIストリングとしてコード化された16ビットのTCP Checksum分野。
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--TCP Urgent Pointerであって、分野の価値の十六進法表現としてコード化された16ビット。 それが緊急であるので、16進数列を大文字で書かなければなりません。
Gaynor & Bradner Informational [Page 5] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[5ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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"]
Optionsオプションの終わり: [「オプションの終わり」]
Window scale option: ["Window scale", shift_count], where
shift_count is the window scaling factor represented as the
ASCII string in decimal.
窓のスケールオプション: [「窓のスケール」、シフト_カウント。](そこでは、シフト_カウントが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_値の_は選ばれます--このASCIIストリングは義務的なコード化しているタイプが指定されない以下の分野のためのコード化しているタイプの代理をします。 正統の値は_が選ぶTCP_値のように同じです。
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」であるならこのセクションで定義されます、そして、セクション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--TCP_DODOと同様に、IPインターネットHeader Length分野であり、それはコード化されます。
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.
_Service(この名前は大文字と小文字を区別している)のIP4_Type_--これはIPv4ヘッダーの分野への時代遅れの名前です。(ヘッダーはIP_$$とIP_CUに取り替えられました)。
Gaynor & Bradner Informational [Page 6] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[6ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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 codepointという名前を表すUTF-8ストリングとしてカプセル化されたIP。
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ストリングとしてコード化されます。そこでは、「X」は、“on"か「オフです」。 ビット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ビットのTotal Length分野。
IP4_SSN - The IP Identification field, encoded as an ASCII string
representing the value of the field.
IP4_SSN--分野の値を表すASCIIストリングとしてコード化されたIP Identification分野。
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 Flags: [「ゼロでなければならない」、「5月の断片」| 「断片化しないでください」、]
IP4_Frager - The 13-bit Fragment Offset field, encoded as an ASCII
string representing the value of the field.
IP4_フレーガー--分野の値を表すASCIIストリングとしてコード化された13ビットのFragment Offset分野。
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分野。 「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_プロト--ヘッダーがIPヘッダーについて来るプロトコルのために一般名を表すUTF-8ストリングとしてコード化された8ビットのプロトコル分野。
IP4_Checkit - The 16-bit Checksum field, encoded in the same way as
TCP_Checkit.
IP4_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.
IP4_Apparent_Source--32ビットのSource Address分野。 ユーザ友情において、これはパケットの見かけの送付者のドメイン名を表すUTF-8ストリングとしてコード化されます。 代替のフォームであり、使用されるために、ドメイン名自体がいつファイアウォールによって妨げられるかもしれないかは企業ユーザーの無実を保護するのはプログラムを作って、ASCIIストリングはIPv4アドレスの点を打たされた回路書式を表していますか?
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ビットのDestination Address分野。
Gaynor & Bradner Informational [Page 7] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[7ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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"]
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.
Sourceルート設定オプションを発射してください: [「ゆるいソースルート設定」、長さ、指針、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
6ビットのDifferentiated ServicesがさばくIP_$$ ―--上を見てください。
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".
__FlowとIP6_Go_--20ビットのFlow Label分野。 この分野が現在使用中に、それが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ビットの有効搭載量Length分野。 IPv6 jumbogramsとのFEPの使用は推薦されません。
IP6_NxtHdr - The 8-bit Next Header field, encoded in the same way as
IP4_Proto.
IP6_NxtHdr--IP4_プロトと同様に、コード化された8ビットのNext Header分野。
IP6_Hopping - The 8-bit Hop Limit field, encoded in the same way as
IP4_TTL.
IP6_Hopping--IP4_TTLと同様に、コード化された8ビットのHop Limit分野。
Gaynor & Bradner Informational [Page 8] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[8ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
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ビットのSource Address分野。 ユーザ友情において、これはパケットの見かけの送付者のドメイン名を表すUTF-8ストリングとしてコード化されます。 代替のフォームであり、使用されるために、ドメイン名自体がいつFirewallによって妨げられるかもしれないかは企業ユーザーの無実を保護するのはプログラムを作って、ASCIIストリングはIPv6アドレスを表す正統のフォームのどれかを表していますか?
IP6_Dest_Addr - The 128-bit Destination Address field, encoded the
same way as IP6_Apparent_Source.
IP6_Dest_Addr--ずっとIP6_Apparent_Sourceとして同じようにコード化された128ビットのDestination Address分野。
3.4 TCP Header Compression
3.4 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
4.0 セキュリティ問題
Since this protocol deals with Firewalls there are no real security considerations.
このプロトコルがFirewallsに対処するので、物上担保問題が全くありません。
5.0 Acknowledgements
5.0 承認
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.
Firewallが提供するのをセキュリティのセロハンイチジクの葉をあきらめないでインターネットをすばらしくした革新を再可能にするために私たちの仕事をサポートした多くのFirewallベンダーに感謝申し上げます。
6.0 Authors' Addresses
6.0 作者のアドレス
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 3864年の617 495メール sob@harvard.edu に電話をしてください。
Gaynor & Bradner Informational [Page 9] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[9ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
References
参照
[1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[1] 大工、B.、「インターネット透明」、RFC2775、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.、「MIMEの上のIP」が進行中で働いています。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[4] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、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.
Gaynor & Bradner Informational [Page 10] RFC 3093 Firewall Enhancement Protocol 1 April 2001
ゲイナーとブラドナー[10ページ]情報のRFC3093ファイアウォール増進プロトコル2001年4月1日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gaynor & Bradner Informational [Page 11]
ゲイナーとブラドナー情報です。[11ページ]
一覧
スポンサーリンク
