Network Working Group B. Aboba, Ed.
Request for Comments: 4840 E. Davies
Category: Informational D. Thaler
Internet Architecture Board
April 2007
Network Working Group B. Aboba, Ed.
Request for Comments: 4840 E. Davies
Category: Informational D. Thaler
Internet Architecture Board
April 2007
Multiple Encapsulation Methods Considered Harmful
被认为有害的多种封装方法
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.
本文档描述了由支持多种Internet协议封装方法的链路层协议引起的体系结构和操作问题。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Ethernet Experience ........................................4
1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation ...........6
1.2.2. Trailer Encapsulation ...............................7
1.3. PPP Experience ............................................10
1.4. Potential Mitigations .....................................10
2. Evaluation of Arguments for Multiple Encapsulations ............11
2.1. Efficiency ................................................11
2.2. Multicast/Broadcast .......................................12
2.3. Multiple Uses .............................................13
3. Additional Issues ..............................................15
3.1. Generality ................................................15
3.2. Layer Interdependence .....................................16
3.3. Inspection of Payload Contents ............................17
3.4. Interoperability Guidance .................................17
3.5. Service Consistency .......................................19
3.6. Implementation Complexity .................................19
3.7. Negotiation ...............................................19
3.8. Roaming ...................................................20
4. Security Considerations ........................................20
5. Conclusion .....................................................21
6. References .....................................................22
6.1. Normative Reference .......................................22
6.2. Informative References ....................................22
7. Acknowledgments ................................................25
Appendix A. IAB Members at the Time of This Writing ...............26
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Ethernet Experience ........................................4
1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation ...........6
1.2.2. Trailer Encapsulation ...............................7
1.3. PPP Experience ............................................10
1.4. Potential Mitigations .....................................10
2. Evaluation of Arguments for Multiple Encapsulations ............11
2.1. Efficiency ................................................11
2.2. Multicast/Broadcast .......................................12
2.3. Multiple Uses .............................................13
3. Additional Issues ..............................................15
3.1. Generality ................................................15
3.2. Layer Interdependence .....................................16
3.3. Inspection of Payload Contents ............................17
3.4. Interoperability Guidance .................................17
3.5. Service Consistency .......................................19
3.6. Implementation Complexity .................................19
3.7. Negotiation ...............................................19
3.8. Roaming ...................................................20
4. Security Considerations ........................................20
5. Conclusion .....................................................21
6. References .....................................................22
6.1. Normative Reference .......................................22
6.2. Informative References ....................................22
7. Acknowledgments ................................................25
Appendix A. IAB Members at the Time of This Writing ...............26
This document describes architectural and operational issues arising from the use of multiple ways of encapsulating IP packets on the same link.
本文档描述了由于在同一链路上使用多种封装IP数据包的方法而引起的体系结构和操作问题。
While typically a link-layer protocol supports only a single Internet Protocol (IP) encapsulation method, this is not always the case. For example, on the same cable it is possible to encapsulate an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A Standard for the Transmission of IP Datagrams over Ethernet Networks" [RFC894], the IEEE 802.2/802.3 LLC [IEEE-802.3.2002] Type 1 encapsulation defined in "Two Methods For The Transmission of IP Datagrams over IEEE 802.3 Networks" [RFC948], or the IEEE 802 [IEEE-802.1A.1990] encapsulation defined in "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks" [RFC1042]. Historically, a further encapsulation method was used on some Ethernet systems as specified in "Trailer Encapsulations" [RFC893]. Similarly, ATM (e.g., see [RFC2684]), the Point-to-Point Protocol (PPP) [RFC1661], and IEEE 802.16 [IEEE-802.16e.2005] also support multiple encapsulation mechanisms.
虽然链路层协议通常只支持单个Internet协议（IP）封装方法，但情况并非总是如此。例如，在同一根电缆上，可以使用“以太网IP数据报传输标准”[RFC894]中定义的以太网[DIX]封装来封装IPv4数据包，IEEE 802.2/802.3 LLC[IEEE-802.3.2002]中定义的类型1封装“通过IEEE 802.3网络传输IP数据报的两种方法”[RFC948]，或“通过IEEE 802.3网络传输IP数据报的标准”[RFC1042]中定义的IEEE 802[IEEE-802.1A.1990]封装。历史上，在一些以太网系统上使用了“拖车封装”中规定的进一步封装方法“[RFC893]。类似地，ATM（例如，参见[RFC2684]）、点对点协议（PPP）[RFC1661]和IEEE 802.16[IEEE-802.16e.2005]也支持多种封装机制。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Broadcast domain The set of all endpoints that receive broadcast frames sent by an endpoint in the set.
广播域接收集合中某个端点发送的广播帧的所有端点的集合。
Classification As defined in [IEEE-802.16e.2005], the process by which a Medium Access Control (MAC) Service Data Unit (SDU) is mapped into a particular transport connection for transmission between MAC peers.
如[IEEE-802.16e.2005]中定义的分类，将介质访问控制（MAC）服务数据单元（SDU）映射到特定传输连接以在MAC对等点之间传输的过程。
Connection Identifier (CID) In [IEEE-802.16e.2005] the connection identifier is a 16-bit value that identifies a transport connection or an uplink (UL)/downlink (DL) pair of associated management connections. A connection is a unidirectional mapping between base station (BS) and subscriber station (SS) MAC peers. Each transport connection has a particular set of associated parameters indicating characteristics such as the ciphersuite and quality-of-service.
[IEEE-802.16e.2005]中的连接标识符（CID）连接标识符是一个16位值，用于标识传输连接或相关管理连接的上行链路（UL）/下行链路（DL）对。连接是基站（BS）和用户站（SS）MAC对等点之间的单向映射。每个传输连接都有一组特定的相关参数，指示密码套件和服务质量等特征。
Link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP.
链路节点可在链路层（即IP下的一层）上进行通信的通信设施或介质。
Link Layer The conceptual layer of control or processing logic that is responsible for maintaining control of the link. The link-layer functions provide an interface between the higher-layer logic and the link. The link layer is the layer immediately below IP.
链路层：控制或处理逻辑的概念层，负责维护链路的控制。链路层功能提供高层逻辑和链路之间的接口。链路层是IP下的一层。
The fundamental issues with multiple encapsulation methods on the same link are described in [RFC1042] and "Requirements for Internet Hosts -- Communication Layers" [RFC1122]. This section summarizes the concerns articulated in those documents and also describes the limitations of approaches suggested to mitigate the problems, including encapsulation negotiation and use of routers.
[RFC1042]和“互联网主机要求——通信层”[RFC1122]中描述了同一链路上多种封装方法的基本问题。本节总结了这些文件中阐述的问题，并描述了为缓解这些问题而建议的方法的局限性，包括封装协商和路由器的使用。
[RFC1042] described the potential issues resulting from contemporaneous use of Ethernet and IEEE 802.3 encapsulations on the same physical cable:
[RFC1042]描述了在同一物理电缆上同时使用以太网和IEEE 802.3封装所产生的潜在问题：
Interoperation with Ethernet
与以太网的互操作
It is possible to use the Ethernet link level protocol [DIX] on the same physical cable with the IEEE 802.3 link level protocol. A computer interfaced to a physical cable used in this way could potentially read both Ethernet and 802.3 packets from the network. If a computer does read both types of packets, it must keep track of which link protocol was used with each other computer on the network and use the proper link protocol when sending packets.
可以在与IEEE 802.3链路级协议相同的物理电缆上使用以太网链路级协议[DIX]。以这种方式连接到物理电缆的计算机可能从网络中读取以太网和802.3数据包。如果一台计算机确实读取了这两种类型的数据包，它必须跟踪网络上其他计算机使用的链路协议，并在发送数据包时使用正确的链路协议。
One should note that in such an environment, link level broadcast packets will not reach all the computers attached to the network, but only those using the link level protocol used for the broadcast.
应该注意的是，在这种环境中，链路级广播数据包不会到达连接到网络的所有计算机，而只到达使用用于广播的链路级协议的计算机。
Since it must be assumed that most computers will read and send using only one type of link protocol, it is recommended that if such an environment (a network with both link protocols) is necessary, an IP gateway be used as if there were two distinct networks.
由于必须假设大多数计算机将仅使用一种链路协议进行读取和发送，因此建议如果需要这样的环境（具有两种链路协议的网络），则使用IP网关，如同有两个不同的网络一样。
Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram.
请注意，以太网的MTU允许1500个八位IP数据报，而802.3网络的MTU仅允许1492个八位IP数据报。
When multiple IP encapsulation methods were supported on a given link, all hosts could not be assumed to support the same set of encapsulation methods. This in turn implied that the broadcast domain might not include all hosts on the link. Where a single encapsulation does not reach all hosts on the link, a host needs to determine the appropriate encapsulation prior to sending. While a host supporting reception of multiple encapsulations could keep track of the encapsulations it receives, this does not enable initiation of communication; supporting initiation requires a host to support sending of multiple encapsulations in order to determine which one to use. However, requiring hosts to send and receive multiple encapsulations is a potentially onerous requirement. [RFC1122], Section 2.3.3, notes the difficulties with this approach:
当给定链路上支持多个IP封装方法时，不能假定所有主机都支持同一组封装方法。这又意味着广播域可能不包括链路上的所有主机。如果单个封装不能到达链路上的所有主机，则主机需要在发送之前确定适当的封装。虽然支持接收多个封装的主机可以跟踪其接收的封装，但这不支持通信的启动；支持启动需要主机支持多个封装的发送，以确定使用哪个封装。然而，要求主机发送和接收多个封装是一项潜在的繁重要求。[RFC1122]第2.3.3节指出了这种方法的困难：
Furthermore, it is not useful or even possible for a dual-format host to discover automatically which format to send, because of the problem of link-layer broadcasts.
此外，由于链路层广播的问题，双格式主机无法或甚至无法自动发现要发送的格式。
To enable hosts that only support sending and receiving of a single encapsulation to communicate with each other, a router can be utilized to segregate the hosts by encapsulation. Here only the router needs to support sending and receiving of multiple encapsulations. This requires assigning a separate unicast prefix to each encapsulation, or else all hosts in the broadcast domain would not be reachable with a single encapsulation.
为了使仅支持发送和接收单个封装的主机能够彼此通信，可以利用路由器通过封装隔离主机。这里只有路由器需要支持多个封装的发送和接收。这需要为每个封装分配单独的单播前缀，否则广播域中的所有主机将无法通过单个封装访问。
[RFC1122], Section 2.3.3, provided guidance on encapsulation support:
[RFC1122]第2.3.3节提供了封装支持指南：
Every Internet host connected to a 10Mbps Ethernet cable:
每个连接到10Mbps以太网电缆的Internet主机：
o MUST be able to send and receive packets using RFC-894 encapsulation;
o 必须能够使用RFC-894封装发送和接收数据包；
o SHOULD be able to receive RFC-1042 packets, intermixed with RFC-894 packets; and
o 应能接收RFC-1042数据包，与RFC-894数据包混合；和
o MAY be able to send packets using RFC-1042 encapsulation.
o 可以使用RFC-1042封装发送数据包。
An Internet host that implements sending both the RFC-894 and the RFC-1042 encapsulation MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC-894.
实现发送RFC-894和RFC-1042封装的Internet主机必须提供一个配置开关来选择要发送的，该开关必须默认为RFC-894。
By making Ethernet encapsulation mandatory to implement for both send and receive, and also the default for sending, [RFC1122] recognized Ethernet as the predominant encapsulation, heading off potential interoperability problems.
通过将以太网封装强制用于发送和接收，以及默认的发送，[RFC1122]将以太网识别为主要的封装，避免了潜在的互操作性问题。
Prior to standardization of the IEEE 802 encapsulation in [RFC1042], an IEEE 802.2/802.3 LLC Type 1 encapsulation was specified in [RFC948], utilizing 6 in the Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) fields of the IEEE 802.2 header. However, since the SSAP and DSAP fields are each only a single octet, and the Ethertype values for IP, ARP [RFC826], and RARP [RFC903] are greater than 1500, these values cannot be represented in the SSAP and DSAP fields. As a result, the encapsulation described in [RFC948] did not support protocols requiring distinct Ethertypes such as ARP or RARP, and implementations typically included support for alternatives to ARP such as the Probe [PROBE] protocol. Support for ARP, RARP and other IP protocols utilizing distinct Ethertypes was addressed in [RFC1042], which obsoleted [RFC948]. [RFC1042] utilized the Sub-Network Access Protocol (SNAP) form of the IEEE 802.2 Logical Link Control (LLC) with the SSAP and DSAP fields set to 170, including support for the Ethertype field. As noted in "Assigned Numbers" [RFC1010]:
在[RFC1042]中IEEE 802封装标准化之前，[RFC948]中规定了IEEE 802.2/802.3 LLC类型1封装，利用IEEE 802.2报头的源服务接入点（SSAP）和目标服务接入点（DSAP）字段中的6。但是，由于SSAP和DSAP字段都只是一个八位字节，并且IP、ARP[RFC826]和RARP[RFC903]的Ethertype值大于1500，因此这些值不能在SSAP和DSAP字段中表示。因此，[RFC948]中描述的封装不支持需要不同以太网类型（如ARP或RARP）的协议，实现通常包括对ARP替代方案（如Probe[Probe]协议）的支持。[RFC1042]中阐述了对ARP、RARP和其他使用不同以太网类型的IP协议的支持，该协议已被[RFC948]淘汰。[RFC1042]利用IEEE 802.2逻辑链路控制（LLC）的子网访问协议（SNAP）形式，将SSAP和DSAP字段设置为170，包括对Ethertype字段的支持。如“指定编号”[RFC1010]所述：
At an ad hoc special session on "IEEE 802 Networks and ARP", held during the TCP Vendors Workshop (August 1986), an approach to a consistent way to send DoD-IP datagrams and other IP related protocols on 802 networks was developed.
在TCP供应商研讨会（1986年8月）期间举行的关于“IEEE 802网络和ARP”的特别会议上，开发了一种在802网络上发送国防部IP数据报和其他IP相关协议的一致方法。
Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DoD-IP related protocols (such as the Address Resolution Protocol (ARP) on IEEE 802 network, the following new policy is established, which will replace the old policy (see RFC 960 and RFC 948 [108]).
由于IEEE 802.2标准的某些演变，以及需要提供一种标准方法来执行额外的国防部IP相关协议（如IEEE 802网络上的地址解析协议（ARP）），因此建立了以下新策略，以取代旧策略（参见RFC 960和RFC 948[108]）。
The new policy is for the Internet community to use the IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the EtherType code (where IP = 2048 (0800 hex), see Ethernet Numbers of Interest).
新的政策是让互联网社区在802.3、802.4和802.5网络上使用IEEE 802.2封装，方法是使用SNAP，其组织代码指示以下16位指定EtherType代码（其中IP=2048（0800十六进制），请参阅感兴趣的以太网编号）。
Header
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
Header
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice boundary.
SAP报头和SNAP报头的总长度为8个八位字节，这使得802.2协议的开销达到了一个很好的界限。
K1 is 170. The IEEE likes to talk about things in little-endian bit transmission order and specifies this value as 01010101. In big-endian order, as used in Internet specifications, this becomes 10101010 binary, or AA hex, or 170 decimal.
K1是170。IEEE喜欢以低位传输顺序讨论问题，并将该值指定为01010101。按照互联网规范中使用的大端顺序，这将变成10101010二进制，或AA十六进制，或170十进制。
K2 is 0 (zero).
K2为0（零）。
The use of the IP LSAP (K1 = 6) is to be phased out as quickly as possible.
IP LSAP（K1=6）的使用将尽快淘汰。
Many of the issues involved in coexistence of the [RFC948] and
[RFC1042] encapsulations are similar to those described in Section
1.2. For example, due to use of different SSAP/DSAP values, the
broadcast domain might not include all hosts on the link, and a host
would need to determine the appropriate encapsulation prior to
sending. However, the lack of support for ARP within the [RFC948]
encapsulation created additional interoperability and implementation
issues. For example, the lack of support for ARP in [RFC948] implied
that implementations supporting both [RFC948] and [RFC894] or
[RFC1042] encapsulations would need to implement both ARP and an
alternative address resolution mechanism such as Probe. Also, since
the address resolution mechanism for [RFC948] implementations was not
standardized, interoperability problems would likely have arisen had
[RFC948] been widely implemented.
Many of the issues involved in coexistence of the [RFC948] and
[RFC1042] encapsulations are similar to those described in Section
1.2. For example, due to use of different SSAP/DSAP values, the
broadcast domain might not include all hosts on the link, and a host
would need to determine the appropriate encapsulation prior to
sending. However, the lack of support for ARP within the [RFC948]
encapsulation created additional interoperability and implementation
issues. For example, the lack of support for ARP in [RFC948] implied
that implementations supporting both [RFC948] and [RFC894] or
[RFC1042] encapsulations would need to implement both ARP and an
alternative address resolution mechanism such as Probe. Also, since
the address resolution mechanism for [RFC948] implementations was not
standardized, interoperability problems would likely have arisen had
[RFC948] been widely implemented.
As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation was an optimization developed to minimize memory-to-memory copies on reception. By placing variable-length IP and transport headers at the end of the packet, page alignment of data could be more easily
正如“拖车封装”[RFC893]中所述，拖车封装是一种优化设计，旨在最大限度地减少接收时的内存到内存拷贝。通过将可变长度的IP和传输头放在数据包的末尾，数据的页面对齐会更加容易
maintained. Trailers were implemented in 4.2 Berkeley System Distribution (BSD), among others. While, in theory, trailer encapsulation could have been applied to the Ethernet [RFC894] or IEEE 802 [RFC1042] encapsulations (creating four potential encapsulations of IP!), in practice, trailer encapsulation was only supported for Ethernet. A separate Ethertype was utilized in order to enable IP packets in trailer encapsulation to be distinguished from [RFC894] encapsulation. Since the [RFC948] encapsulation did not support the Ethertype field (or ARP), this mechanism could not have been used in [RFC948] implementations.
保持。除其他外，4.2 Berkeley系统分发（BSD）中实施了拖车。虽然从理论上讲，拖车封装可以应用于以太网[RFC894]或IEEE 802[RFC1042]封装（创建四种可能的IP封装！），但实际上，拖车封装仅支持以太网。为了使拖车封装中的IP数据包与[RFC894]封装区别开来，使用了一个单独的Ethertype。由于[RFC948]封装不支持Ethertype字段（或ARP），因此该机制无法在[RFC948]实现中使用。
[RFC1122], Section 2.3.1, described the issues with trailer encapsulation:
[RFC1122]第2.3.1节描述了拖车封装的问题：
DISCUSSION
讨论
The trailer protocol is a link-layer encapsulation technique that rearranges the data contents of packets sent on the physical network. In some cases, trailers improve the throughput of higher layer protocols by reducing the amount of data copying within the operating system. Higher layer protocols are unaware of trailer use, but both the sending and receiving host MUST understand the protocol if it is used. Improper use of trailers can result in very confusing symptoms. Only packets with specific size attributes are encapsulated using trailers, and typically only a small fraction of the packets being exchanged have these attributes. Thus, if a system using trailers exchanges packets with a system that does not, some packets disappear into a black hole while others are delivered successfully.
拖车协议是一种链路层封装技术，用于重新排列物理网络上发送的数据包的数据内容。在某些情况下，拖车通过减少操作系统内的数据复制量来提高高层协议的吞吐量。更高层的协议不知道拖车的使用，但是发送和接收主机都必须理解协议（如果使用）。拖车使用不当会导致非常混乱的症状。只有具有特定大小属性的数据包才使用拖车进行封装，并且通常只有一小部分正在交换的数据包具有这些属性。因此，如果使用拖车的系统与不使用拖车的系统交换数据包，则一些数据包会消失在黑洞中，而其他数据包则会成功传递。
IMPLEMENTATION:
实施：
On an Ethernet, packets encapsulated with trailers use a distinct Ethernet type [RFC893], and trailer negotiation is performed at the time that ARP is used to discover the link-layer address of a destination system.
在以太网上，用拖车封装的数据包使用不同的以太网类型[RFC893]，拖车协商在ARP用于发现目标系统的链路层地址时执行。
Specifically, the ARP exchange is completed in the usual manner using the normal IP protocol type, but a host that wants to speak trailers will send an additional "trailer ARP reply" packet, i.e., an ARP reply that specifies the trailer encapsulation protocol type but otherwise has the format of a normal ARP reply. If a host configured to use trailers receives a trailer ARP reply message from a remote machine, it can add that machine to the list of machines that understand trailers, e.g., by marking the corresponding entry in the ARP cache.
具体地说，ARP交换是以通常的方式使用正常IP协议类型完成的，但是想要说出预告片的主机将发送额外的“预告片ARP应答”数据包，即指定预告片封装协议类型但具有正常ARP应答格式的ARP应答。如果配置为使用拖车的主机从远程机器接收到拖车ARP回复消息，它可以将该机器添加到理解拖车的机器列表中，例如，在ARP缓存中标记相应的条目。
Hosts wishing to receive trailers send trailer ARP replies whenever they complete exchanges of normal ARP messages for IP. Thus, a host that received an ARP request for its IP protocol address would send a trailer ARP reply in addition to the normal IP ARP reply; a host that sent the IP ARP request would send a trailer ARP reply when it received the corresponding IP ARP reply. In this way, either the requesting or responding host in an IP ARP exchange may request that it receive trailers.
希望接收预告片的主机在完成IP正常ARP消息交换时发送预告片ARP回复。因此，接收到针对其IP协议地址的ARP请求的主机将在正常IP ARP应答的基础上发送尾部ARP应答；发送IP ARP请求的主机在收到相应的IP ARP应答时将发送一个尾部ARP应答。这样，IP ARP交换中的请求主机或响应主机都可以请求接收拖车。
This scheme, using extra trailer ARP reply packets rather than sending an ARP request for the trailer protocol type, was designed to avoid a continuous exchange of ARP packets with a misbehaving host that, contrary to any specification or common sense, responded to an ARP reply for trailers with another ARP reply for IP. This problem is avoided by sending a trailer ARP reply in response to an IP ARP reply only when the IP ARP reply answers an outstanding request; this is true when the hardware address for the host is still unknown when the IP ARP reply is received. A trailer ARP reply may always be sent along with an IP ARP reply responding to an IP ARP request.
该方案使用额外的拖车ARP回复数据包，而不是发送拖车协议类型的ARP请求，旨在避免ARP数据包与行为不端的主机的连续交换，该主机违反任何规范或常识，以另一个IP ARP回复回复拖车ARP回复。只有当IP ARP应答应答未完成的请求时，才发送拖车ARP应答以响应IP ARP应答，从而避免了此问题；当接收到IP ARP应答时，主机的硬件地址仍然未知时，这是正确的。拖车ARP回复可能始终与响应IP ARP请求的IP ARP回复一起发送。
Since trailer encapsulation negotiation depends on ARP, it can only be used where all hosts on the link are within the same broadcast domain. It was assumed that all hosts supported sending and receiving ARP packets in standard Ethernet encapsulation [RFC894], so that negotiation between Ethernet and IEEE 802 encapsulations was not required, only negotiation between standard Ethernet [RFC894] and trailer [RFC893] encapsulation. Had hosts supporting trailer encapsulation also supported one or more IEEE 802 framing mechanisms, the negotiation would have been complicated still further. For example, since [RFC948] implementations did not support the Ethertype field or ARP, the trailer negotiation mechanism could not have been utilized, and additional difficulty would have been encountered in distinguishing trailer encapsulated data frames from normally encapsulated frames.
由于拖车封装协商依赖于ARP，因此它只能在链路上的所有主机都位于同一广播域的情况下使用。假设所有主机都支持在标准以太网封装[RFC894]中发送和接收ARP数据包，因此以太网和IEEE 802封装之间不需要协商，只需要在标准以太网[RFC894]和拖车[RFC893]封装之间协商。如果支持拖车封装的主机也支持一个或多个IEEE 802帧机制，那么协商将更加复杂。例如，由于[RFC948]实现不支持Ethertype字段或ARP，因此无法使用拖车协商机制，并且在区分拖车封装的数据帧和正常封装的帧时会遇到额外的困难。
[RFC1122], Section 2.3.1, provided the following guidance for use of trailer encapsulation:
[RFC1122]第2.3.1节为拖车封装的使用提供了以下指南：
The trailer protocol for link-layer encapsulation MAY be used, but only when it has been verified that both systems (host or gateway) involved in the link-layer communication implement trailers. If the system does not dynamically negotiate use of the trailer protocol on a per-destination basis, the default configuration MUST disable the protocol.
可使用用于链路层封装的拖车协议，但仅当已验证链路层通信中涉及的两个系统（主机或网关）均实现拖车时。如果系统未根据每个目的地动态协商拖车协议的使用，则默认配置必须禁用该协议。
4.2BSD did not support dynamic negotiation, only configuration of trailer encapsulation at boot time, and therefore [RFC1122] required that the trailer encapsulation be disabled by default on those systems.
4.2BSD不支持动态协商，仅在引导时配置拖车封装，因此[RFC1122]要求在这些系统上默认禁用拖车封装。
PPP can support both encapsulation of IEEE 802 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets. Multiple compression schemes are also supported.
PPP可以支持[RFC3518]中定义的IEEE 802帧的封装，以及IPv4和IPv6[RFC2472]数据包。还支持多种压缩方案。
In addition to PPP Data Link Layer (DLL) protocol numbers allocated for IPv4 (0x0021), IPv6 (0x0057), and Bridging PDU (0x0031), the following codepoints have been assigned:
除了为IPv4（0x0021）、IPv6（0x0057）和桥接PDU（0x0031）分配的PPP数据链路层（DLL）协议编号外，还分配了以下代码点：
o two for RObust Header Compression (ROHC) [RFC3095]: ROHC small-CID (0x0003) and ROHC large-CID (0x0005)
o 两个用于鲁棒头压缩（ROHC）[RFC3095]：ROHC小CID（0x0003）和ROHC大CID（0x0005）
o two for Van Jacobson compression [RFC1144]: Compressed TCP/IP (0x002d) and Uncompressed TCP/IP (002f)
o 两个用于Van Jacobson压缩[RFC1144]：压缩TCP/IP（0x002d）和未压缩TCP/IP（002f）
o one for IPv6 Header Compression [RFC2507]: (0x004f)
o 一个用于IPv6头压缩[RFC2507]：（0x004f）
o nine for RTP IP Header Compression [RFC3544]: Full Header (0x0061), Compressed TCP (0x0063), Compressed Non TCP (0x0065), UDP 8 (0x0067), RTP 8 (0x0069), Compressed TCP No Delta (0x2063), Context State (0x2065), UDP 16 (0x2067), and RTP 16 (0x2069)
o 九个用于RTP IP头压缩[RFC3544]：完整头（0x0061）、压缩TCP（0x0063）、压缩非TCP（0x0065）、UDP 8（0x0067）、RTP 8（0x0069）、压缩TCP无增量（0x2063）、上下文状态（0x2065）、UDP 16（0x2067）和RTP 16（0x2069）
Although PPP can encapsulate IP packets in multiple ways, typically multiple encapsulation schemes are not operational on the same link, and therefore the issues described in this document rarely arise. For example, while PPP can support both encapsulation of IEEE 802 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets, in practice, multiple encapsulation mechanisms are not operational on the same link. Similarly, only a single compression scheme is typically negotiated for use on a link.
尽管PPP可以以多种方式封装IP数据包，但通常在同一链路上不存在多个封装方案，因此本文档中描述的问题很少出现。例如，虽然PPP可以支持[RFC3518]中定义的IEEE 802帧的封装，以及IPv4和IPv6[RFC2472]数据包，但实际上，多个封装机制不能在同一链路上运行。类似地，通常仅协商单个压缩方案以在链路上使用。
In order to mitigate problems arising from multiple encapsulation methods, it may be possible to use switches [IEEE-802.1D.2004] or routers, or to attempt to negotiate the encapsulation method to be used. As described below, neither approach may be completely satisfactory.
为了缓解由多种封装方法引起的问题，可以使用交换机[IEEE-802.1D.2004]或路由器，或者尝试协商要使用的封装方法。如下文所述，两种方法都不可能完全令人满意。
The use of switches or routers to enable communication between hosts utilizing multiple encapsulation methods is not a panacea. If separate unicast prefixes are used for each encapsulation, then the choice of encapsulation can be determined from the routing table. If the same unicast prefix is used for each encapsulation method, it is necessary to keep state for each destination host. However, this may not work in situations where hosts using different encapsulations respond to the same anycast address.
使用交换机或路由器实现主机之间使用多种封装方法的通信并不是万灵药。如果每个封装使用单独的单播前缀，则可以从路由表中确定封装的选择。如果每个封装方法使用相同的单播前缀，则必须保持每个目标主机的状态。但是，在使用不同封装的主机响应同一选播地址的情况下，这可能不起作用。
In situations where multiple encapsulation methods are enabled on a single link, negotiation may be supported to allow hosts to determine how to encapsulate a packet for a particular destination host.
在单个链路上启用多个封装方法的情况下，可以支持协商，以允许主机确定如何封装特定目标主机的数据包。
Negotiating the encapsulation above the link layer is potentially problematic since the negotiation itself may need to be carried out using multiple encapsulations. In theory, it is possible to negotiate an encapsulation method by sending negotiation packets over all encapsulation methods supported, and keeping state for each destination host. However, if the encapsulation method must be dynamically negotiated for each new on-link destination, communication to new destinations may be delayed. If most communication is short, and the negotiation requires an extra round trip beyond link-layer address resolution, this can become a noticeable factor in performance. Also, the negotiation may result in consumption of additional bandwidth.
协商链路层上方的封装可能存在问题，因为协商本身可能需要使用多个封装来执行。理论上，可以通过在所有支持的封装方法上发送协商包，并保持每个目标主机的状态，来协商封装方法。然而，如果必须为每个新的链路上目的地动态协商封装方法，则到新目的地的通信可能会延迟。如果大多数通信都很短，并且协商需要链路层地址解析之外的额外往返，那么这可能会成为影响性能的一个显著因素。此外，协商可能导致额外带宽的消耗。
There are several reasons often given in support of multiple encapsulation methods. We discuss each in turn, below.
支持多种封装方法通常有几个原因。下面我们依次讨论每一个问题。
Claim: Multiple encapsulation methods allow for greater efficiency. For example, it has been argued that IEEE 802 or Ethernet encapsulation of IP results in excessive overhead due to the size of the data frame headers, and that this can adversely affect performance on wireless networks, particularly in situations where support of Voice over IP (VoIP) is required.
声明：多种封装方法可以提高效率。例如，有人认为，由于数据帧报头的大小，IP的IEEE 802或以太网封装会导致过多的开销，这会对无线网络的性能产生不利影响，特别是在需要支持IP语音（VoIP）的情况下。
Discussion: Even where these performance concerns are valid, solutions exist that do not require defining multiple IP encapsulation methods. For example, links may support Ethernet frame compression so that Ethernet Source and Destination Address fields are not sent with every packet.
讨论：即使这些性能问题是有效的，也存在不需要定义多个IP封装方法的解决方案。例如，链路可支持以太网帧压缩，以便以太网源地址和目的地址字段不会随每个数据包一起发送。
It is possible for link layers to negotiate compression without requiring higher-layer awareness; the Point-to-Point Protocol (PPP)
链路层可以协商压缩而不需要更高的层感知；点对点协议（PPP）
[RFC1661] is an example. "The PPP Compression Control Protocol (CCP)" [RFC1962] enables negotiation of data compression mechanisms, and "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP Header Compression over PPP" [RFC3544] enable negotiation of header compression, without Internet-layer awareness. Any frame can be "decompressed" based on the content of the frame, and prior state based on previous control messages or data frames. Use of compression is a good way to solve the efficiency problem without introducing problems at higher layers.
[RFC1661]就是一个例子。“PPP压缩控制协议（CCP）”[RFC1962]允许协商数据压缩机制，“PPP上的健壮报头压缩（ROHC）”[RFC3241]和“PPP上的IP报头压缩”[RFC3544]允许协商报头压缩，而无需互联网层感知。任何帧都可以基于帧的内容进行“解压缩”，并且先前的状态基于先前的控制消息或数据帧。使用压缩是解决效率问题的一个好方法，而不会在更高的层上引入问题。
There are also situations in which use of multiple encapsulations can degrade performance or result in packet loss. The use of multiple encapsulation methods with differing Maximum Transfer Units (MTUs) can result in differing MTUs for on-link destinations. If the link-layer protocol does not provide per-destination MTUs to the IP layer, it will need to use a default MTU; to avoid fragmentation, this must be less than or equal to the minimum MTU of on-link destinations. If the default MTU is too low, the full bandwidth may not be achievable. If the default MTU is too high, packet loss will result unless or until IP Path MTU Discovery is used to discover the correct MTU.
在某些情况下，使用多个封装可能会降低性能或导致数据包丢失。使用具有不同最大传输单元（MTU）的多种封装方法可能会导致链路上目的地的MTU不同。如果链路层协议未向IP层提供每个目的地MTU，则需要使用默认MTU；为避免碎片，这必须小于或等于链路上目标的最小MTU。如果默认MTU太低，则可能无法实现全部带宽。如果默认MTU过高，将导致数据包丢失，除非或直到使用IP路径MTU发现来发现正确的MTU。
Recommendation: Where encapsulation is an efficiency issue, use header compression. Where the encapsulation method or the use of compression must be negotiated, negotiation should either be part of bringing up the link, or be piggybacked in the link-layer address resolution exchange; only a single compression scheme should be negotiated on a link. Where the MTU may vary among destinations on the same link, the link-layer protocol should provide a per-destination MTU to IP.
建议：如果封装是一个效率问题，请使用头压缩。如果必须协商封装方法或压缩的使用，则协商应该是建立链接的一部分，或者在链接层地址解析交换中进行；一个链路上只能协商一个压缩方案。在同一链路上的目的地之间MTU可能不同的情况下，链路层协议应提供每个目的地到IP的MTU。
Claim: Support for Ethernet encapsulation requires layer 2 support for distribution of IP multicast/broadcast packets. In situations where this is difficult, support for Ethernet is problematic and other encapsulations are necessary.
声明：支持以太网封装需要第2层支持IP多播/广播数据包的分发。在这种困难的情况下，对以太网的支持是有问题的，需要其他封装。
Discussion: Irrespective of the encapsulation used, IP packets sent to multicast (IPv4/IPv6) or broadcast (IPv4) addresses need to reach all potential on-link receivers. Use of alternative encapsulations cannot remove this requirement, although there is considerable flexibility in how it can be met. Non-Broadcast Multiple Access (NBMA) networks can still support the broadcast/multicast service via replication of unicast frames.
讨论：无论使用何种封装，发送到多播（IPv4/IPv6）或广播（IPv4）地址的IP数据包都需要到达所有潜在的链路接收器。使用替代封装不能消除这一要求，尽管在如何满足这一要求方面有相当大的灵活性。非广播多址（NBMA）网络仍然可以通过复制单播帧来支持广播/多播服务。
Techniques are also available for improving the efficiency of IP multicast/broadcast delivery in wireless networks. In order to be receivable by any host within listening range, an IP
还可以使用技术来提高无线网络中IP多播/广播交付的效率。为了使侦听范围内的任何主机都能接收到IP
multicast/broadcast packet sent as link-layer multicast/broadcast over a wireless link needs to be sent at the lowest rate supported by listeners. If the sender does not keep track of the rates negotiated by group listeners, by default, multicast/broadcast traffic is sent at the lowest supported rate, resulting in increased overhead. However, a sender can also deliver an IP multicast/broadcast packet using unicast frame(s) where this would be more efficient. For example, in IEEE 802.11, multicast/broadcast traffic sent from the Station (STA) to the Access Point (AP) is always sent as unicast, and the AP tracks the negotiated rate for each STA, so that it can send unicast frames at a rate appropriate for each station.
作为无线链路上的链路层多播/广播发送的多播/广播数据包需要以侦听器支持的最低速率发送。如果发送方不跟踪组侦听器协商的速率，默认情况下，多播/广播流量将以支持的最低速率发送，从而增加开销。然而，发送方也可以使用单播帧交付IP多播/广播分组，这将更加有效。例如，在IEEE 802.11中，从站点（STA）发送到接入点（AP）的多播/广播流量始终作为单播发送，并且AP跟踪每个STA的协商速率，以便它能够以适合每个站点的速率发送单播帧。
In order to limit the propagation of link-scope multicast or broadcast traffic, it is possible to assign a separate prefix to each host.
为了限制链路范围多播或广播流量的传播，可以为每个主机分配单独的前缀。
Unlike broadcasts, which are received by all hosts on the link regardless of the protocol they are running, multicasts only need be received by those hosts belonging to the multicast group. In wired networks, it is possible to avoid forwarding multicast traffic on switch ports without group members, by snooping of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) traffic as described in "Considerations for IGMP and MLD Snooping Switches" [RFC4541].
与广播不同，广播由链路上的所有主机接收，而不管它们运行的是什么协议，多播只需要由属于多播组的主机接收。在有线网络中，可以通过侦听Internet组管理协议（IGMP）和多播侦听器发现（MLD）通信量来避免在没有组成员的交换机端口上转发多播通信量，如“IGMP和MLD侦听交换机的注意事项”[RFC4541]中所述。
In wireless media where data rates to specific destinations are negotiated and may vary over a wide range, it may be more efficient to send multiple frames via link-layer unicast than to send a single multicast/broadcast frame. For example, in [IEEE-802.11.2003] multicast/broadcast traffic from the client station (STA) to the Access Point (AP) is sent via link-layer unicast.
在无线媒体中，到特定目的地的数据速率是协商的，并且可能在很大范围内变化，通过链路层单播发送多个帧可能比发送单个多播/广播帧更有效。例如，在[IEEE-802.11.2003]中，从客户端站（STA）到接入点（AP）的多播/广播流量通过链路层单播发送。
Recommendation: Where support for link-layer multicast/broadcast is problematic, limit the propagation of link-scope multicast and broadcast traffic by assignment of separate prefixes to hosts. In some circumstances, it may be more efficient to distribute multicast/broadcast traffic as multiple link-layer unicast frames.
建议：如果对链路层多播/广播的支持存在问题，则通过向主机分配单独的前缀来限制链路范围多播和广播流量的传播。在某些情况下，将多播/广播业务作为多链路层单播帧分发可能更有效。
Claim: No single encapsulation is optimal for all purposes. Therefore, where a link layer is utilized in disparate scenarios (such as both fixed and mobile deployments), multiple encapsulations are a practical requirement.
声明：没有一种封装是所有用途的最佳选择。因此，当链路层用于不同的场景（如固定和移动部署）时，多个封装是一个实际需求。
Discussion: "Architectural Principles of the Internet" [RFC1958], point 3.2, states:
讨论：“互联网的体系结构原则”[RFC1958]，第3.2点指出：
If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.
如果有几种方法做同一件事，选择一种。如果以前的设计在互联网环境或其他地方成功地解决了相同的问题，请选择相同的解决方案，除非有充分的技术理由不这样做。应尽可能避免相同协议功能的重复，当然不要使用此参数来拒绝改进。
Existing encapsulations have proven themselves capable of supporting disparate usage scenarios. For example, the Point-to-Point Protocol (PPP) has been utilized by wireless link layers such as General Packet Radio Service (GPRS), as well as in wired networks in applications such as "PPP over SONET/SDH" [RFC2615]. PPP can even support bridging, as described in "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518].
现有的封装已经证明能够支持不同的使用场景。例如，点对点协议（PPP）已被诸如通用分组无线业务（GPRS）等无线链路层以及诸如“SONET/SDH上的PPP”[RFC2615]等应用中的有线网络使用。PPP甚至可以支持桥接，如“点对点协议（PPP）桥接控制协议（BCP）”[RFC3518]中所述。
Similarly, Ethernet encapsulation has been used in wired networks as well as Wireless Local Area Networks (WLANs) such as IEEE 802.11 [IEEE-802.11.2003]. Ethernet can also support Virtual LANs (VLANs) and Quality of Service (QoS) [IEEE-802.1Q.2003].
类似地，以太网封装已用于有线网络以及无线局域网（WLAN），如IEEE 802.11[IEEE-802.11.2003]。以太网还可以支持虚拟局域网（VLAN）和服务质量（QoS）[IEEE-802.1Q.2003]。
Therefore, disparate usage scenarios can be addressed by choosing a single encapsulation, rather than multiple encapsulations. Where an existing encapsulation is suitable, this is preferable to creating a new encapsulation.
因此，可以通过选择单个封装而不是多个封装来解决不同的使用场景。在现有封装适用的情况下，这比创建新封装更可取。
Where encapsulations other than IP over Point-to-Point Protocol (PPP) [RFC1661], Ethernet, or IEEE 802 are supported, difficulties in operating system integration can lead to interoperability problems.
如果支持点到点协议（PPP）[RFC1661]、以太网或IEEE 802以外的封装，操作系统集成的困难可能导致互操作性问题。
In order to take advantage of operating system support for IP encapsulation over PPP, Ethernet, or IEEE 802, it may be tempting for a driver supporting an alternative encapsulation to emulate PPP, Ethernet, or IEEE 802 support. Typically, PPP emulation requires that the driver implement PPP, enabling translation of PPP control and data frames to the equivalent native facilities. Similarly, Ethernet or IEEE 802 emulation typically requires that the driver implement Dynamic Host Configuration Protocol (DHCP) v4 or v6, Router Solicitation/Router Advertisement (RS/RA), Address Resolution Protocol (ARP), or IPv6 Neighbor Discovery (ND) in order to enable translation of these frames to and from native facilities.
为了利用操作系统对PPP、以太网或IEEE 802上的IP封装的支持，支持替代封装的驱动程序可能会模拟PPP、以太网或IEEE 802支持。通常，PPP仿真要求驱动程序实现PPP，从而将PPP控制和数据帧转换为等效的本机设施。类似地，以太网或IEEE 802仿真通常要求驱动程序实现动态主机配置协议（DHCP）v4或v6、路由器请求/路由器广告（RS/RA）、地址解析协议（ARP）或IPv6邻居发现（ND），以便能够将这些帧转换到本机设备或从本机设备转换。
Where drivers are implemented in kernel mode, the work required to provide faithful emulation may be substantial. This creates the temptation to cut corners, potentially resulting in interoperability problems.
如果驱动程序是在内核模式下实现的，那么提供可靠的仿真所需的工作可能是大量的。这就产生了偷工减料的诱惑，可能导致互操作性问题。
For example, it might be tempting for driver implementations to neglect IPv6 support. A driver emulating PPP might support only IP Control Protocol (IPCP), but not IPCPv6; a driver emulating Ethernet or IEEE 802 might support only DHCPv4 and ARP, but not DHCPv6, RS/RA, or ND. As a result, an IPv6 host connecting to a network supporting IPv6 might find itself unable to use IPv6 due to lack of driver support.
例如，驱动程序实现可能会忽略IPv6支持。模拟PPP的驱动程序可能只支持IP控制协议（IPCP），而不支持IPCPv6；模拟以太网或IEEE 802的驱动程序可能只支持DHCPv4和ARP，但不支持DHCPv6、RS/RA或ND。因此，连接到支持IPv6的网络的IPv6主机可能会发现由于缺少驱动程序支持而无法使用IPv6。
Recommendation: Support a single existing encapsulation where possible. Emulation of PPP, Ethernet, or IEEE 802 on top of alternative encapsulations should be avoided.
建议：尽可能支持单个现有封装。应避免在替代封装之上模拟PPP、以太网或IEEE 802。
There are a number of additional issues arising from use of multiple encapsulation methods, as hinted at in Section 1. We discuss each of these below.
如第1节所示，由于使用多种封装方法，还存在许多其他问题。我们将在下面讨论每一个问题。
Link-layer protocols such as [IEEE-802.1A.1990] and [DIX] inherently support the ability to add support for a new packet type without modification to the link-layer protocol.
链路层协议，如[IEEE-802.1A.1990]和[DIX]固有地支持添加对新分组类型的支持，而无需修改链路层协议。
IEEE 802.16 [IEEE-802.16.2004] splits the Media Access Control (MAC) layer into a number of sublayers. For the uppermost of these, the standard defines the concept of a service-specific Convergence Sublayer (CS). The two underlying sublayers (the MAC Common Part Sublayer and the Security Sublayer) provide common services for all instantiations of the CS.
IEEE 802.16[IEEE-802.16.2004]将媒体访问控制（MAC）层拆分为多个子层。对于其中最重要的部分，该标准定义了特定于服务的聚合子层（CS）的概念。两个底层子层（MAC公共部分子层和安全子层）为CS的所有实例化提供公共服务。
While [IEEE-802.16.2004] defined support for the Asynchronous Transfer Mode (ATM) CS and the Packet CS for raw IPv4, raw IPv6, and Ethernet with a choice of six different classifiers, [IEEE-802.16e.2005] added support for raw and Ethernet-framed ROHC Enhanced Compressed RTP (ECRTP) compressed packets. As a result, [IEEE-802.16e.2005] defines the ATM CS and multiple versions of the Packet CS for the transmission of raw IPv4, raw IPv6, 802.3/Ethernet, 802.1Q VLAN, IPv4 over 802.3/Ethernet, IPv6 over 802.3/Ethernet, IPv4 over 802.1Q VLAN, IPv6 over 802.1Q VLAN, raw ROHC-compressed packets, raw ECRTP-compressed packets, ROHC-compressed packets over 802.3/Ethernet. and ECRTP-compressed packets over 802.3/Ethernet.
虽然[IEEE-802.16.2004]定义了对原始IPv4、原始IPv6和以太网的异步传输模式（ATM）CS和数据包CS的支持，并选择了六种不同的分类器，[IEEE-802.16e.2005]增加了对原始和以太网帧ROHC增强压缩RTP（ECRTP）压缩数据包的支持。因此，[IEEE-802.16e.2005]定义了ATM CS和多个版本的数据包CS，用于传输原始IPv4、原始IPv6、802.3/以太网、802.1Q VLAN、802.3/以太网上的IPv4、802.3/以太网上的IPv6、802.1Q VLAN上的IPv4、802.1Q VLAN上的IPv6、原始ROHC压缩数据包、原始ECRTP压缩数据包，ROHC通过802.3/Ethernet压缩数据包。以及通过802.3/以太网的ECRTP压缩数据包。
As noted in [Generic], [IEEE-802.16.2004] appears to imply that the standard will need to be modified to support new packet types:
如[Generic]中所述，[IEEE-802.16.2004]似乎暗示需要修改该标准以支持新的数据包类型：
We are concerned that the 802.16 protocol cannot easily be extendable to transport new protocols over the 802.16 air interface. It would appear that a Convergence Sublayer is needed for every type of protocol transported over the 802.16 MAC. Every time a new protocol type needs to be transported over the 802.16 air interface, the 802.16 standard needs to be modified to define a new CS type. We need to have a generic Packet Convergence Sublayer that can support multi-protocols and which does not require further modification to the 802.16 standard to support new protocols. We believe that this was the original intention of the Packet CS. Furthermore, we believe it is difficult for the industry to agree on a set of CS's that all devices must implement to claim "compliance".
我们担心，802.16协议无法轻松扩展，无法通过802.16空中接口传输新协议。对于通过802.16 MAC传输的每种类型的协议，似乎都需要一个汇聚子层。每次需要通过802.16空中接口传输新的协议类型时，都需要修改802.16标准以定义新的CS类型。我们需要一个通用的数据包聚合子层，它可以支持多种协议，并且不需要进一步修改802.16标准来支持新的协议。我们认为，这是包CS的初衷。此外，我们认为，行业很难就所有设备必须实现的一套CS达成一致，以声明“合规性”。
The use of IP and/or upper-layer protocol specific classification and encapsulation methods, rather than a 'neutral' general purpose encapsulation, may give rise to a number of undesirable effects explored in the following subsections.
在“一般用途”和“非特定用途”中，所探索的IP和/或封装方法的数量可能会产生“非期望用途”和“非期望用途”的效果。
If the link layer does not provide a general purpose encapsulation method, deployment of new IP and/or upper-layer protocols will be dependent on deployment of the corresponding new encapsulation support in the link layer.
如果链路层不提供通用封装方法，则新IP和/或上层协议的部署将取决于链路层中相应新封装支持的部署。
Even if a single encapsulation method is used, problems can still occur if demultiplexing of ARP, IPv4, IPv6, and any other protocols in use, is not supported at the link layer. While it is possible to demultiplex such packets based on the Version field (first four bits on the packet), this assumes that IPv4-only implementations will be able to properly handle IPv6 packets. As a result, a more robust design is to demultiplex protocols in the link layer, such as by assigning a different protocol type, as is done in IEEE 802 media where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6.
即使使用单个封装方法，如果在链路层不支持ARP、IPv4、IPv6和任何其他正在使用的协议的解复用，也会出现问题。虽然可以根据版本字段（数据包的前四位）对此类数据包进行多路分解，但这假定仅IPv4实现将能够正确处理IPv6数据包。因此，更稳健的设计是在链路层中解复用协议，例如通过分配不同的协议类型，就像在IEEE 802介质中所做的那样，其中类型0x0800用于IPv4，类型0x86DD用于IPv6。
Recommendations: Link-layer protocols should enable network packets (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer.
建议：链路层协议应允许网络数据包（IPv4、IPv6、ARP等）在链路层中解复用。
Within IEEE 802.16, the process by which frames are selected for transmission on a connection identifier (CID) is known as "classification". Fields in the Ethernet, IP, and UDP/TCP headers can be used for classification; for a particular CS, a defined subset of header fields may be applied for that purpose.
在IEEE 802.16中，选择帧在连接标识符（CID）上传输的过程称为“分类”。以太网、IP和UDP/TCP报头中的字段可用于分类；对于特定CS，可为此目的应用定义的标题字段子集。
Utilizing IP and/or upper layer headers in link-layer classification will almost inevitably lead to interdependencies between link-layer and upper-layer specifications. Although this might appear to be
在链路层分类中使用IP和/或上层头几乎不可避免地会导致链路层和上层规范之间的相互依赖性。虽然这似乎是
desirable in terms of providing a highly specific (and hence interoperable) mapping between the capabilities provided by the link layer (e.g., quality-of-service support) and those that are needed by upper layers, this sort of capability is probably better provided by a more comprehensive service interface (Application Programming Interface) in conjunction with a single encapsulation mechanism.
为了在链路层提供的功能（例如，服务质量支持）和上层所需的功能之间提供高度特定（因此可互操作）的映射，这种功能最好由更全面的服务接口（应用程序编程接口）提供与单个封装机制结合使用。
IPv6, in particular, provides an extensible header system. An upper-layer-specific classification scheme would still have to provide a degree of generality in order to cope with future extensions of IPv6 that might wish to make use of some of the link layer services already provided.
特别是IPv6，它提供了一个可扩展的报头系统。上层特定分类方案仍需提供一定程度的通用性，以应对未来可能希望利用某些已提供的链路层服务的IPv6扩展。
Recommendations: Upper-layer-specific classification schemes should be avoided.
建议：应避免上层特定分类方案。
If a classification scheme utilizing higher-layer headers proposes to inspect the contents of the packet being encapsulated (e.g., IEEE 802.16 IP CS mechanisms for determining the connection identifier (CID) to use to transmit a packet), the fields available for inspection may be limited if the packet is compressed or encrypted before passing to the link layer. This may prevent the link layer from utilizing existing compression mechanisms, such as Van Jacobson Compression [RFC1144], ROHC [RFC3095][RFC3759], Compressed RTP (CRTP) [RFC2508], Enhanced Compressed RTP (ECRTP) [RFC3545], or IP Header Compression [RFC2507].
如果利用更高层报头的分类方案提议检查被封装的分组的内容（例如，用于确定用于传输分组的连接标识符（CID）的IEEE 802.16 IP CS机制），如果分组在传递到链路层之前被压缩或加密，则可用于检查的字段可能受到限制。这可防止链路层利用现有压缩机制，例如Van Jacobson压缩[RFC1144]、ROHC[RFC3095][RFC3759]、压缩RTP（CRTP）[RFC2508]、增强压缩RTP（ECRTP）[RFC3545]或IP报头压缩[RFC2507]。
Recommendations: Link-layer classification schemes should not rely on the contents of higher-layer headers.
建议：链接层分类方案不应依赖于更高层标题的内容。
In situations where multiple encapsulation methods are operational and capable of carrying IP traffic, interoperability problems are possible in the absence of clear implementation guidelines. For example, there is no guarantee that other hosts on the link will support the same set of encapsulation methods, or that if they do, that their routing tables will result in identical preferences.
在多个封装方法可操作且能够承载IP流量的情况下，在缺乏明确实施指南的情况下，互操作性问题是可能的。例如，无法保证链路上的其他主机将支持相同的封装方法集，或者如果它们支持，它们的路由表将产生相同的首选项。
In IEEE 802.16, the Subscriber Station (SS) indicates the Convergence Sublayers it supports to the Base Station (BS), which selects from the list one or more that it will support on the link. Therefore, it is possible for multiple CSes to be operational.
在IEEE 802.16中，用户站（SS）向基站（BS）指示其支持的汇聚子层，基站（BS）从列表中选择其将在链路上支持的一个或多个汇聚子层。因此，多个CSE可以运行。
Note that IEEE 802.16 does not provide multiple encapsulation methods for the same kind of data payload; it defines exactly one
请注意，IEEE 802.16没有为相同类型的数据有效载荷提供多种封装方法；它正好定义了一个
encapsulation scheme for each data payload. For example, there is one way to encapsulate a raw IPv4 packet into an IEEE 802.16 MAC frame, one encapsulation scheme for a raw IPv6 packet, etc. There is also one way to encapsulate an Ethernet frame, even when there are multiple possibilities for classifying an Ethernet frame for forwarding over a connection identifier (CID). Since support for multiple CSes enables IEEE 802.16 to encapsulate layer 2 frames as well as layer 3 packets, IP packets may be directly encapsulated in IEEE 802.16 MAC frames as well as framed with Ethernet headers in IEEE 802.16 MAC frames. Where CSes supporting both layer 2 frames as well as layer 3 packets are operational on the same link, a number of issues may arise, including:
每个数据有效负载的封装方案。例如，有一种将原始IPv4数据包封装到IEEE 802.16 MAC帧的方法，一种用于原始IPv6数据包的封装方案，等等。还有一种封装以太网帧的方法，即使在有多种可能对以太网帧进行分类以通过连接标识符（CID）进行转发时也是如此。由于对多个CSE的支持使IEEE 802.16能够封装第2层帧以及第3层数据包，因此IP数据包可以直接封装在IEEE 802.16 MAC帧中，也可以与IEEE 802.16 MAC帧中的以太网报头一起封装。当支持第2层帧以及第3层分组的cse在同一链路上运行时，可能会出现许多问题，包括：
Use of Address Resolution Protocol (ARP) Where both IPv4 CS and Ethernet CS are operational on the same link, it may not be obvious how address resolution should be implemented. For example, should an ARP frame be encapsulated over the Ethernet CS, or should alternative mechanisms be used for address resolution, utilizing the IPv4 CS?
地址解析协议（ARP）的使用当IPv4 CS和以太网CS在同一链路上运行时，地址解析的实现方式可能并不明显。例如，一个ARP帧应该封装在以太网CS上，还是应该利用IPv4 CS使用替代机制进行地址解析？
Data Frame Encapsulation When sending an IP packet, which CS should be used? Where multiple encapsulations are operational, multiple connection identifiers (CIDs) will also be present. The issue can therefore be treated as a multi-homing problem, with each CID constituting its own interface. Since a given CID may have associated bandwidth or quality-of-service constraints, routing metrics could be adjusted to take this into account, allowing the routing layer to choose based on which CID (and encapsulation) appears more attractive.
发送IP数据包时的数据帧封装，应使用哪个CS？在多个封装可操作的情况下，还将存在多个连接标识符（CID）。因此，可以将该问题视为多归宿问题，每个CID构成其自己的接口。由于给定的CID可能具有相关的带宽或服务质量约束，因此可以调整路由度量以将其考虑在内，从而允许路由层根据哪个CID（和封装）看起来更具吸引力进行选择。
This could lead to interoperability problems or routing asymmetry. For example, consider the effects on IPv6 Neighbor Discovery:
这可能导致互操作性问题或路由不对称。例如，考虑IPv6邻居发现的影响：
(a) If hosts choose to send IPv6 Neighbor Discovery traffic on different CSes, it is possible that a host sending an IPv6 Neighbor Discovery packet will not receive a reply, even though the target host is reachable over another CS.
(a) 如果主机选择在不同的CSE上发送IPv6邻居发现流量，则发送IPv6邻居发现数据包的主机可能不会收到回复，即使目标主机可以通过另一个CS访问。
(b) Where hosts all support the same set of CSes, but have different routing preferences, it is possible for a host to send an IPv6 Neighbor Discovery packet over one CS and receive a reply over another CS.
(b) 如果所有主机都支持同一组CSE，但具有不同的路由首选项，则主机可以通过一个CS发送IPv6邻居发现数据包，并通过另一个CS接收回复。
Recommendations: Given these issues, it is strongly recommended that only a single kind of CS supporting a single encapsulation method should be usable on a particular link.
建议：鉴于这些问题，强烈建议在特定链接上只能使用支持单一封装方法的单一类型的CS。
If a link-layer protocol provides multiple encapsulation methods, the services offered to the IP-layer and upper-layer protocols may differ qualitatively between the different encapsulation methods. For example, the 802.16 [IEEE-802.16.2004] link-layer protocol offers both 'native' encapsulation for raw IPv4 and IPv6 packets, and Ethernet encapsulation. In the raw case, the IP layer can be directly mapped to the quality-of-service (QoS) capabilities of the IEEE 802.16 transmission channels, whereas using the Ethernet encapsulation, an IP-over-Ethernet CS has to be deployed to circumvent the mapping of the IP QoS to the Ethernet header fields to avoid the limitations of Ethernet QoS. Consequently, the service offered to an application depends on the classification method employed and may be inconsistent between sessions. This may be confusing for the user and the application.
如果链路层协议提供了多种封装方法，则在不同的封装方法之间，提供给IP层和上层协议的服务可能在质量上有所不同。例如，802.16[IEEE-802.16.2004]链路层协议提供原始IPv4和IPv6数据包的“本机”封装，以及以太网封装。在原始情况下，IP层可以直接映射到IEEE 802.16传输信道的服务质量（QoS）能力，而使用以太网封装，必须部署以太网IP CS以避免IP QoS映射到以太网报头字段，从而避免以太网QoS的限制。因此，向应用程序提供的服务取决于所采用的分类方法，并且在会话之间可能不一致。这可能会混淆用户和应用程序。
Recommendations: If multiple encapsulation methods for IP packets on a single link-layer technology are deemed to be necessary, care should be taken to match the services available between encapsulation methods as closely as possible.
建议：如果认为有必要在单个链路层技术上对IP数据包采用多种封装方法，则应注意使封装方法之间的可用服务尽可能匹配。
Support of multiple encapsulation methods results in additional implementation complexity. Lack of uniform encapsulation support also results in potential interoperability problems. To avoid interoperability issues, devices with limited resources may be required to implement multiple encapsulation mechanisms, which may not be practical.
支持多个封装方法会导致额外的实现复杂性。缺乏统一的封装支持也会导致潜在的互操作性问题。为了避免互操作性问题，可能需要具有有限资源的设备来实现多个封装机制，这可能是不实际的。
When encapsulation methods require hardware support, implementations may choose to support different encapsulation sets, resulting in market fragmentation. This can prevent users from benefiting from economies of scale, precluding some uses of the technology entirely.
当封装方法需要硬件支持时，实现可能会选择支持不同的封装集，从而导致市场分裂。这可能会阻止用户从规模经济中获益，从而完全排除该技术的某些用途。
Recommendations: Choose a single encapsulation mechanism that is mandatory to implement for both sending and receiving, and make that encapsulation mechanism the default for sending.
建议：选择发送和接收都必须实现的单一封装机制，并将该封装机制设置为发送的默认封装机制。
The complexity of negotiation within ARP or IP can be reduced by performing encapsulation negotiation within the link layer.
通过在链路层内执行封装协商，可以降低ARP或IP内协商的复杂性。
However, unless the link layer allows the negotiation of the encapsulation between any two hosts, interoperability problems can still result if more than one encapsulation is possible on a given
但是，除非链路层允许在任意两台主机之间协商封装，否则，如果在给定的主机上可能存在多个封装，则仍然可能导致互操作性问题
link. In general, a host cannot assume that all other hosts on a link support the same set of encapsulation methods, so that unless a link-layer protocol only supports point-to-point communication, negotiation of multiple potential encapsulation methods will be problematic. To avoid this problem, it is desirable for link-layer encapsulation negotiation to determine a single IP encapsulation, not merely to indicate which encapsulation methods are possible.
链接通常，主机不能假设链路上的所有其他主机都支持相同的封装方法集，因此，除非链路层协议仅支持点对点通信，否则多个潜在封装方法的协商将有问题。为了避免这个问题，链路层封装协商需要确定单个IP封装，而不仅仅是指示哪些封装方法是可能的。
Recommendations: Encapsulation negotiation is best handled in the link layer. In order to avoid dependencies on the data frame encapsulation mechanism, it is preferable for the negotiation to be carried out using management frames, if they are supported. If multiple encapsulations are required and negotiation is provided, then the negotiation should result in a single encapsulation method being negotiated on the link.
建议：封装协商最好在链接层处理。为了避免对数据帧封装机制的依赖，如果支持管理帧，则最好使用管理帧执行协商。如果需要多个封装并提供协商，则协商应导致在链接上协商单个封装方法。
Where a mobile node roams between base stations or to a fixed infrastructure, and the base stations and fixed infrastructure do not all support the same set of encapsulations, then it may be necessary to alter the encapsulation method, potentially in mid-conversation. Even if the change can be handled seamlessly at the link and IP layer so that applications are not affected, unless the services offered over the different encapsulations are equivalent (see Section 3.5), the service experienced by the application may change as the mobile node crosses boundaries. If the service is significantly different, it might even require 'in-flight' renegotiation, which most applications are not equipped to manage.
如果移动节点在基站之间或到固定基础设施漫游，并且基站和固定基础设施不都支持相同的封装集，则可能需要改变封装方法，可能是在会话中。即使可以在链路层和IP层无缝地处理更改，以使应用程序不受影响，除非通过不同封装提供的服务是等效的（参见第3.5节），应用程序所经历的服务可能会随着移动节点跨越边界而更改。如果服务明显不同，它甚至可能需要“在运行中”重新协商，而大多数应用程序都无法进行管理。
Recommendations: Ensure uniformity of the encapsulation set (preferably only a single encapsulation) within a given mobile domain, between mobile domains, and between mobile domains and fixed infrastructure. If a link layer protocol offers multiple encapsulation methods for IP packets, it is strongly recommended that only one of these encapsulation methods should be in use on any given link or within a single wireless transmission domain.
建议：确保给定移动域内、移动域之间以及移动域和固定基础设施之间的封装集（最好仅单个封装）的一致性。如果链路层协议为IP数据包提供了多种封装方法，则强烈建议在任何给定链路或单个无线传输域中仅使用其中一种封装方法。
The use of multiple encapsulation methods does not appear to have significant security implications.
使用多种封装方法似乎没有重大的安全影响。
An attacker might be able to utilize an encapsulation method that was not in normal use on a link to cause a denial-of-service attack, which would exhaust the processing resources of interfaces if packets utilizing this encapsulation were passed up the stack to any significant degree before being discarded.
攻击者可能会利用链路上未正常使用的封装方法来引发拒绝服务攻击，如果利用此封装的数据包在丢弃之前被大量上传到堆栈，则会耗尽接口的处理资源。
An attacker might be able to force a more cumbersome encapsulation method between two endpoints, even when a lighter weight one is available, hence forcing higher resource consumption on the link and within those endpoints, or causing fragmentation. Since IP fragments are more difficult to classify than non-fragments, this may result in packet loss or may even expose security vulnerabilities [WEP].
攻击者可能会在两个端点之间强制使用更麻烦的封装方法，即使有更轻量级的封装方法可用，从而在链接上和这些端点内强制使用更高的资源消耗，或导致碎片。由于IP片段比非片段更难分类，这可能导致数据包丢失，甚至可能暴露安全漏洞[WEP]。
If different methods have different security properties, an attacker might be able to force a less secure method as an elevation path to get access to some other resource or data. Similarly, if one method is rarely used, that method is potentially more likely to have exploitable implementation bugs.
如果不同的方法具有不同的安全属性，攻击者可能会强制使用不太安全的方法作为提升路径来访问其他资源或数据。类似地，如果很少使用一种方法，则该方法可能更容易出现可利用的实现错误。
Since lower-layer classification methods may need to inspect fields in the packet being encapsulated, this might deter the deployment of end-to-end security, which is undesirable. Where encryption of upper layer headers (e.g., IPsec tunnel mode) is required, this may obscure headers required for classification. As a result, it may be necessary for all encrypted traffic to flow over a single connection.
由于较低层分类方法可能需要检查被封装的数据包中的字段，这可能会阻止端到端安全性的部署，这是不可取的。如果需要对上层头进行加密（例如，IPsec隧道模式），这可能会掩盖分类所需的头。因此，可能需要所有加密的通信流通过单个连接。
The use of multiple encapsulation methods on the same link is problematic, as discussed above.
如上所述，在同一链接上使用多个封装方法是有问题的。
Although multiple IP encapsulation methods were defined on Ethernet cabling, recent implementations support only the Ethernet encapsulation of IPv4 defined in [RFC894]. In order to avoid a repeat of the experience with IPv4, for operation of IPv6 on IEEE 802.3 media, only the Ethernet encapsulation was defined in "A Method for the Transmission of IPv6 Packets over Ethernet Networks" [RFC1972], later updated in [RFC2464].
尽管在以太网布线上定义了多种IP封装方法，但最近的实现仅支持[RFC894]中定义的IPv4的以太网封装。为了避免IPv4的重复使用，对于IEEE 802.3介质上的IPv6操作，在“通过以太网传输IPv6数据包的方法”[RFC1972]中仅定义了以太网封装，随后在[RFC2464]中更新。
In addition to the recommendations given earlier, we give the following general recommendations to avoid problems resulting from use of multiple IP encapsulation methods:
除了前面给出的建议外，我们还提供以下一般性建议，以避免使用多个IP封装方法导致的问题：
When developing standards for encapsulating IP packets on a link-layer technology, it is desirable that only a single encapsulation method should be standardized for each link-layer technology.
在制定链路层技术上封装IP数据包的标准时，希望每个链路层技术只标准化一种封装方法。
If a link-layer protocol offers multiple encapsulation methods for IP packets, it is strongly recommended that only one of these encapsulation methods should be in use within any given link.
如果链路层协议为IP数据包提供了多种封装方法，强烈建议在任何给定链路中只使用其中一种封装方法。
Where multiple encapsulation methods are supported on a link, a single encapsulation should be mandatory to implement for send and receive.
在一个链接上支持多个封装方法的情况下，发送和接收必须实现单个封装。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DIX] Digital Equipment Corporation, Intel Corporation, and Xerox Corporation, "The Ethernet -- A Local Area Network: Data Link Layer and Physical Layer (Version 2.0)", November 1982.
[DIX]数字设备公司、英特尔公司和施乐公司，“以太网——局域网：数据链路层和物理层（2.0版）”，1982年11月。
[Generic] Wang, L. et al, "A Generic Packet Convergence Sublayer (GPCS) for Supporting Multiple Protocols over 802.16 Air Interface", Submission to IEEE 802.16g: CB0216g_05_025r4.pdf, November 2005, <http://www.ieee802.org/16/netman/contrib/ C80216g-05_025r4.pdf>.
[通用]Wang，L.等人，“支持802.16空中接口多协议的通用分组汇聚子层（GPCS）”，提交至IEEE 802.16g:CB0216g_05_025r4.pdf，2005年11月<http://www.ieee802.org/16/netman/contrib/ C80216g-05_025r4.pdf>。
[IEEE-802.1A.1990] Institute of Electrical and Electronics Engineers, "Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1A, 1990.
[IEEE-802.1A.1990]电气和电子工程师协会，“局域网和城域网：网络标准概述和体系结构”，IEEE标准802.1A，1990年。
[IEEE-802.1D.2004] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges", IEEE Standard 802.1D, 2004.
[IEEE-802.1D.2004]电气和电子工程师协会，“信息技术-系统间电信和信息交换-局域网-媒体访问控制（MAC）网桥”，IEEE标准802.1D，2004年。
[IEEE-802.1Q.2003] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
【IEEE-802.1Q.2003】IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q-2003，2003年1月。
[IEEE-802.3.2002] Institute of Electrical and Electronics Engineers, "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Standard 802.3, 2002.
[IEEE-802.3.2002]电气和电子工程师协会，“带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范”，IEEE标准802.3，2002。
[IEEE-802.11.2003] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE-802.11.2003]电气和电子工程师协会，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11，2003。
[IEEE-802.16.2004] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Standard 802.16-2004, October 2004.
[IEEE-802.16.2004]电气和电子工程师协会，“信息技术-系统间的电信和信息交换-局域网和城域网，第16部分：固定宽带无线接入系统的空中接口”，IEEE标准802.16-2004，2004年10月。
[IEEE-802.16e.2005] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE P802.16e, September 2005.
[IEEE-802.16e.2005]电气和电子工程师学会，“信息技术.系统间远程通信和信息交换.局域网和城域网.第16部分：固定和移动宽带无线接入系统的空中接口.在许可频带内固定和移动组合操作的物理和介质接入控制层的修改，IEEE P802.16e，2005年9月。
[PROBE] Hewlett Packard, "A Primer on HP Probe", http://www.hp.com/rnd/support/manuals/pdf/ hp_probe.pdf, July 1993.
[PROBE]惠普，“HP PROBE入门”，http://www.hp.com/rnd/support/manuals/pdf/ hp_probe.pdf，1993年7月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April 1984.
[RFC893]Leffler，S.和M.Karels，“拖车封装”，RFC 893，1984年4月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1984.
[RFC894]Hornig，C.，“通过以太网传输IP数据报的标准”，STD 41，RFC894，1984年4月。
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[RFC903]Finlayson，R.，Mann，T.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，1984年6月。
[RFC948] Winston, I., "Two Methods for the Transmission of IP Datagrams over IEEE 802.3 Networks", RFC 948, June 1985.
[RFC948]Winston，I.“通过IEEE 802.3网络传输IP数据报的两种方法”，RFC 948，1985年6月。
[RFC1010] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1010, May 1987.
[RFC1010]Reynolds，J.和J.Postel，“分配的数字”，RFC1010，1987年5月。
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.
[RFC1042]Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，STD 43，RFC 1042，1988年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC1962]兰德，D.“PPP压缩控制协议（CCP）”，RFC1962，1996年6月。
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC1972]Crawford，M.，“通过以太网传输IPv6数据包的方法”，RFC 1972，1996年8月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615]Malis，A.和W.Simpson，“SONET/SDH上的PPP”，RFC 26151999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K。，
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[RFC3518] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[RFC3518]Higashiyama，M.，Baker，F.，和T.Liao，“点对点协议（PPP）桥接控制协议（BCP）”，RFC3518，2003年4月。
[RFC3544] Koren, T., Casner, S., and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[RFC3544]Koren，T.，Casner，S.，和C.Bormann，“PPP上的IP报头压缩”，RFC 3544，2003年7月。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[RFC3545]Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759]Jonsson，L-E，“鲁棒头压缩（ROHC）：术语和信道映射示例”，RFC 3759，2004年4月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[WEP] Bittau, A., Handley, M., and J. Lackey, "The Final Nail in WEP's Coffin", Proceedings of the 2006 IEEE Symposium on Security and Privacy, pp. 386-400.
[WEP]Bittau，A.，Handley，M.，和J.Lackey，“WEP棺材上的最后一颗钉子”，2006年IEEE安全和隐私研讨会论文集，第386-400页。
The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari Arkko, Max Riegel, Alfred Hoenes, and Phil Roberts for contributions to this document.
作者感谢Jeff Mandin、Bob Hinden、Jari Arkko、Max Riegel、Alfred Hoenes和Phil Roberts对本文件的贡献。
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B.Davies咨询公司Soham，英国剑桥
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。