Network Working Group M. Gaynor
Request for Comments: 3093 S. Bradner
Category: Informational Harvard University
1 April 2001
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.
版权所有（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），以允许创新，而不违反防火墙的安全模型。没有防火墙操作员的合作，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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
要查看端到端模型的强大功能，请考虑下面的示例。如果Scott和Mark有一个好主意和一些实现天赋，他们可以创建一个工件，使用它，并将其发送给他们的朋友。如果这是一个好主意，这些朋友可以采纳它，也许会让它变得更好。现在进入防火墙：如果马克碰巧在一家安装防火墙的公司工作，他就不能和他的朋友斯科特一起试验。创新更加困难，也许不可能。如果Scott和Mark想做一些实验，使他们能够更好地为用户服务，那么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，因为它可以绕过防火墙。这种特定应用程序的零碎部署并不是应对防火墙带来的创新挑战的有效方式。我们决定开发一个通过HTTP传输TCP/IP的过程。
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.
我们的协议很简单，部分基于Eastlake[3]提出的IP数据包MIME编码方案。我们使用无处不在的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）向主机B（防火墙内）发送TCP/IP数据报。使用隧道接口，TCP/IP数据报被路由到我们的FEP软件（2），该软件在HTTP消息中对数据报进行编码。然后通过HTTP/TCP/IP隧道（3）将此消息发送到正常HTTP端口（4）上的主机B。当它到达主机B时，该数据包通过隧道路由到FEP软件（5），该软件解码该数据包并创建TCP/IP数据报以插入主机B协议栈（6）。该数据包被路由到主机B（7）上的应用程序，就好像防火墙（8）不存在一样。
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
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请求的响应发送。这种灵活性适用于防火墙，这些防火墙尝试验证通过防火墙的有效HTTP命令，以阻止不必要的FEP数据包拦截。
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数据包分两步（或三步）编码到HTTP命令中。首先，IP数据包以MIME格式编码为消息体，如[3]中所述。接下来，TCP[4]数据包头被解析并编码为新的HTTP头。最后，作为一个选项，IP报头也可以编码为新的可选HTTP报头。由于整个IP数据报在HTTP命令的主体部分进行编码，因此对TCP和可选的IP报头进行编码完全是为了人类可读性。
This proposal defines the following new HTTP headers for representing TCP header information.
此建议定义了以下新的HTTP头，用于表示TCP头信息。
TCP_value_opt - This ASCII string represents the encoding type for the TCP fields where a mandatory encoding type is not specified. The legitimate values are:
TCP_value_opt-此ASCII字符串表示未指定强制编码类型的TCP字段的编码类型。合法的价值观是：
TCP_binary - ASCII representation of the binary representation of the value of the field.
TCP_binary-字段值的二进制表示形式的ASCII表示形式。
TCP_hexed - ASCII representation of the hex representation of the value of the field.
TCP_hexed-字段值的十六进制表示形式的ASCII表示形式。
TCP_Sport - The 16-bit TCP Source Port number, encoded as an ASCII string representing the value of port number.
TCP_Sport—16位TCP源端口号，编码为代表端口号值的ASCII字符串。
TCP_Dport - The 16-bit TCP Destination Port number, encoded as an ASCII string representing the value of the port number.
TCP_Dport—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.
TCP_SeqNum—32位序列号，编码为代表序列号十六进制值的ASCII字符串。此字段必须以小写形式发送，因为它不是紧急字段。
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—4位数据偏移量值，编码为ASCII字符串，表示TCP标头实际长度的32位基值（以位为单位）。（通常这是数据值乘以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”（“Oh”）表示“关”位，“O”（“Oh”）表示“开”位。（注意：这些字符必须全部以“关闭”的形式发送，并且在收到时必须忽略。）
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|u FlgBts-TCP标志，编码为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.
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校验和字段，编码为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紧急指针，编码为字段值的十六进制表示形式。十六进制字符串必须大写，因为它是紧急的。
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_计数]，其中shift_计数是以十进制ASCII字符串表示的窗口比例因子。
3.2 IPv4 Header Encapsulation:
3.2 IPv4标头封装：
This proposal defines the following new HTTP headers for representing IPv4 header information:
此建议定义了以下新的HTTP头，用于表示IPv4头信息：
These optional headers are used to encode the IPv4 [5] header for better readability. These fields are encoded in a manner similar to the above TCP header fields.
这些可选标头用于对IPv4[5]标头进行编码，以提高可读性。这些字段的编码方式与上述TCP头字段类似。
Since the base IP packet is already present in an HTTP header, the following headers are optional. None, some or all of them may be used depending on the whim of the programmer.
由于基本IP数据包已经存在于HTTP头中，因此以下头是可选的。根据程序员的心血来潮，可以不使用、部分使用或全部使用。
IP_value_opt - This ASCII string represents the encoding type for the following fields where a mandatory encoding type is not specified. The legitimate values are the same as for TCP_value_opt.
IP_value_opt-此ASCII字符串表示未指定强制编码类型的以下字段的编码类型。合法值与TCP_value_opt的值相同。
IP_Ver - The IP Version number, encoded as an UTF-8 string. The legitimate values for the string are "four", "five", and "six." The encapsulation of the fields in the IP header are defined in this section if the value is "four", and in section 3.3 if the value is "six". Encapsulations for headers with IP_Ver value of "five" will be developed if the right orders are received. Encapsulations for headers with the IP_Ver value of "eight" are empty. Implementations MUST be able to support arbitrary native languages for these strings.
IP版本-IP版本号，编码为UTF-8字符串。字符串的合法值为“四”、“五”和“六”。如果值为“四”，则IP头中字段的封装在本节中定义，如果值为“六”，则在第3.3节中定义。如果收到正确的订单，将开发IP\u Ver值为“5”的标头封装。IP版本值为“八”的头的封装为空。实现必须能够支持这些字符串的任意本机语言。
IP4_Hlen - The IP Internet Header Length field, it is encoded in the same way as TCP_DODO.
IP4_Hlen-IP Internet头长度字段，其编码方式与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_类型_of_服务（此名称区分大小写）-这是IPv4标头中某个字段的过时名称，已替换为IP_$$和IP_CU。
IP_$$ - The 6-bit Differentiated Services field, encapsulated as an UTF-8 string representing the name of the DS codepoint in the field.
IP$$-6位区分服务字段，封装为UTF-8字符串，表示字段中DS代码点的名称。
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-2位字段，是TOS字段的两个低位。由于此字段当前用于实验，因此必须以最通用的方式对其进行编码，因此将其编码为两个ASCII字符串，格式为“bit0=X”和“bit1=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 - 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—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位协议字段，编码为UTF-8字符串，表示协议的通用名称，该协议的头在IP头之后。
IP4_Checkit - The 16-bit Checksum field, encoded in the same way as TCP_Checkit.
IP4_Checkit-16位校验和字段，编码方式与TCP_Checkit相同。
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_源-32位源地址字段。为了便于用户使用，将其编码为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—32位目标地址字段，编码方式与IP4_源相同。
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.
松散源路由选项：[“松散源路由”，长度，指针，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:
此建议定义了以下新的HTTP头，用于表示IPv6头信息：
These optional headers encode the IPv6 [5] header for better readability. These fields are encoded in a manner similar to the above TCP header fields.
这些可选标头对IPv6[5]标头进行编码，以提高可读性。这些字段的编码方式与上述TCP头字段类似。
Since the base IP packet is already present in an HTTP header the following headers are optional. None, some or all of them may be used depending on the whim of the programmer. At this time only the base IPv6 header is supported. If there is sufficient interest, support will be developed for IPv6 extension headers.
由于基本IP数据包已经存在于HTTP报头中，因此以下报头是可选的。根据程序员的心血来潮，可以不使用、部分使用或全部使用。此时仅支持基本IPv6标头。如果有足够的兴趣，将开发对IPv6扩展头的支持。
IP_$$ - the 6-bit Differentiated Services field - see above
IP$$-6位区分服务字段-见上文
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_和_流-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字符串。不建议将FEP与IPv6巨型程序一起使用。
IP6_NxtHdr - The 8-bit Next Header field, encoded in the same way as IP4_Proto.
IP6_NxtHdr-8位下一个报头字段，编码方式与IP4_Proto相同。
IP6_Hopping - The 8-bit Hop Limit field, encoded in the same way as IP4_TTL.
IP6_跳跃-8位跳跃限制字段，编码方式与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.
IP6_源-128位源地址字段。为了方便用户，将其编码为UTF-8字符串，表示数据包的明显发送方的域名。当域名本身可能被防火墙阻止以保护公司用户的清白时，可使用另一种形式，即ASCII字符串，表示IPv6地址的任何一种合法形式。
IP6_Dest_Addr - The 128-bit Destination Address field, encoded the same way as IP6_Apparent_Source.
IP6_Dest_Addr—128位目标地址字段，编码方式与IP6_源相同。
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] Carpenter，B.，“互联网透明度”，RFC 27752000年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月。
[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] 《传输控制协议》，标准7，RFC 793，1981年9月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] Postel，J.，“互联网协议”，STD 5，RFC 7911981年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.
版权所有（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编辑功能的资金目前由互联网协会提供。