Internet Engineering Task Force (IETF) S. Madanapalli
Request for Comments: 5948 iRam Technologies
Category: Standards Track S. Park
ISSN: 2070-1721 Samsung Electronics
S. Chakrabarti
IP Infusion
G. Montenegro
Microsoft Corporation
August 2010
Internet Engineering Task Force (IETF) S. Madanapalli
Request for Comments: 5948 iRam Technologies
Category: Standards Track S. Park
ISSN: 2070-1721 Samsung Electronics
S. Chakrabarti
IP Infusion
G. Montenegro
Microsoft Corporation
August 2010
Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16
在IEEE 802.16的IP汇聚子层上传输IPv4数据包
Abstract
摘要
IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.
IEEE 802.16是无线宽带接入的空中接口规范。IEEE 802.16规定了用于传输上层协议的多个特定于服务的汇聚子层。数据包CS（数据包汇聚子层）用于传输所有基于数据包的协议，如互联网协议（IP）和IEEE 802.3（以太网）。数据包CS的IP特定部分支持直接通过IEEE 802.16媒体访问控制（MAC）层传输IPv4数据包。
This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16.
本文件规定了帧格式、最大传输单元（MTU）和地址分配程序，用于通过IEEE 802.16数据包汇聚子层的IP特定部分传输IPv4数据包。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5948.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5948.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Typical Network Architecture for IPv4 over IEEE 802.16 ..........4
3.1. IEEE 802.16 IPv4 Convergence Sublayer Support ..............4
4. IPv4 CS Link in 802.16 Networks .................................4
4.1. IPv4 CS Link Establishment .................................5
4.2. Frame Format for IPv4 Packets ..............................5
4.3. Maximum Transmission Unit ..................................6
5. Subnet Model and IPv4 Address Assignment ........................8
5.1. IPv4 Unicast Address Assignment ...........................8
5.2. Address Resolution Protocol ...............................8
5.3. IP Broadcast and Multicast ................................8
6. Security Considerations .........................................8
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Multiple Convergence Layers -- Impact on Subnet
Model ................................................11
Appendix B. Sending and Receiving IPv4 Packets ...................11
Appendix C. WiMAX IPv4 CS MTU Size ...............................12
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Typical Network Architecture for IPv4 over IEEE 802.16 ..........4
3.1. IEEE 802.16 IPv4 Convergence Sublayer Support ..............4
4. IPv4 CS Link in 802.16 Networks .................................4
4.1. IPv4 CS Link Establishment .................................5
4.2. Frame Format for IPv4 Packets ..............................5
4.3. Maximum Transmission Unit ..................................6
5. Subnet Model and IPv4 Address Assignment ........................8
5.1. IPv4 Unicast Address Assignment ...........................8
5.2. Address Resolution Protocol ...............................8
5.3. IP Broadcast and Multicast ................................8
6. Security Considerations .........................................8
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Multiple Convergence Layers -- Impact on Subnet
Model ................................................11
Appendix B. Sending and Receiving IPv4 Packets ...................11
Appendix C. WiMAX IPv4 CS MTU Size ...............................12
IEEE 802.16 [IEEE802_16] is a connection-oriented access technology for the last mile. The IEEE 802.16 specification includes the Physical (PHY) and Media Access Control (MAC) layers. The MAC layer includes various Convergence Sublayers (CSs) for transmitting higher-layer packets, including IPv4 packets [IEEE802_16].
IEEE 802.16[IEEE802\u 16]是一种面向连接的最后一英里接入技术。IEEE 802.16规范包括物理层（PHY）和媒体访问控制层（MAC）。MAC层包括用于传输更高层分组的各种汇聚子层（CSs），包括IPv4分组[IEEE802\u 16]。
The scope of this specification is limited to the operation of IPv4 over the IP-specific part of the Packet CS (referred to as "IPv4 CS") for hosts served by a network that utilizes the IEEE Std 802.16 air interface.
本规范的范围仅限于IPv4在数据包CS（称为“IPv4 CS”）的IP特定部分上的操作，该数据包CS用于由利用IEEE Std 802.16空中接口的网络服务的主机。
This document specifies a method for encapsulating and transmitting IPv4 [RFC0791] packets over the IPv4 CS of IEEE 802.16. This document also specifies the MTU and address assignment method for hosts using IPv4 CS.
本文档规定了通过IEEE 802.16的IPv4 CS封装和传输IPv4[RFC0791]数据包的方法。本文档还指定了使用IPv4 CS的主机的MTU和地址分配方法。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
o Mobile Station (MS) -- The term "MS" is used to refer to an IP host. This usage is more informal than that in IEEE 802.16, in which "MS" refers to the interface implementing the IEEE 802.16 MAC and PHY layers and not to the entire host.
o 移动站（MS）——术语“MS”用于指代IP主机。这种用法比IEEE 802.16中的用法更为非正式，其中“MS”指实现IEEE 802.16 MAC和PHY层的接口，而不是指整个主机。
o Last mile -- The term "last mile" is used to refer to the final leg of delivering connectivity from a communications provider to a customer.
o 最后一英里——术语“最后一英里”用于指从通信提供商向客户提供连接的最后一段。
Other terminology in this document is based on the definitions in [RFC5154].
本文件中的其他术语基于[RFC5154]中的定义。
The network architecture follows what is described in [RFC5154] and [RFC5121]. Namely, each MS is attached to an Access Router (AR) through a Base Station (BS), a Layer 2 (L2) entity (from the perspective of the IPv4 link between the MS and the AR).
网络架构遵循[RFC5154]和[RFC5121]中所述。即，每个MS通过基站（BS）、第2层（L2）实体（从MS和AR之间的IPv4链路的角度）连接到接入路由器（AR）。
For further information on the typical network architecture, see [RFC5121], Section 5.
有关典型网络架构的更多信息，请参阅[RFC5121]，第5节。
As described in [IEEE802_16], the IP-specific part of the Packet CS allows the transmission of either IPv4 or IPv6 payloads. In this document, we are focusing on IPv4 over the Packet Convergence Sublayer.
如[IEEE802_16]所述，数据包CS的IP特定部分允许传输IPv4或IPv6有效负载。在本文档中，我们将重点讨论通过数据包聚合子层的IPv4。
For further information on the IEEE 802.16 Convergence Sublayer and encapsulation of IP packets, see Section 4 of [RFC5121] and [IEEE802_16].
有关IEEE 802.16汇聚子层和IP数据包封装的更多信息，请参阅[RFC5121]和[IEEE802\u 16]的第4节。
In 802.16, the transport connection between an MS and a BS is used to transport user data, i.e., IPv4 packets in this case. A transport connection is represented by a service flow, and multiple transport connections can exist between an MS and a BS.
在802.16中，MS和BS之间的传输连接用于传输用户数据，即在本例中为IPv4数据包。传输连接由服务流表示，MS和BS之间可以存在多个传输连接。
When an AR and a BS are co-located, the collection of transport connections to an MS is defined as a single IPv4 link. When an AR and a BS are separated, it is recommended that a tunnel be established between the AR and a BS whose granularity is no greater
当AR和BS位于同一位置时，到MS的传输连接集合被定义为单个IPv4链路。当AR和BS分离时，建议在AR和粒度不大于1的BS之间建立隧道
than "per MS" or "per service flow". (An MS can have multiple service flows, which are identified by a service flow ID.) Then the tunnel(s) for an MS, in combination with the MS's transport connections, forms a single point-to-point IPv4 link.
而不是“每毫秒”或“每服务流”。（MS可以有多个服务流，这些服务流由服务流ID标识。）然后，MS的隧道与MS的传输连接结合，形成单点对点IPv4链路。
Each host belongs to a different IPv4 link and is assigned a unique IPv4 address, similar to the recommendations discussed in "Analysis of IPv6 Link Models for IEEE 802.16 Based Networks" ([RFC4968]).
每个主机属于不同的IPv4链路，并被分配一个唯一的IPv4地址，类似于“基于IEEE 802.16网络的IPv6链路模型分析”（[RFC4968]）中讨论的建议。
In order to enable the sending and receiving of IPv4 packets between the MS and the AR, the link between the MS and the AR via the BS needs to be established. This section explains the link establishment procedure, as described in Section 6.2 of [RFC5121]. Steps 1-4 are the same as those indicated in Section 6.2 of [RFC5121]. In step 5, support for IPv4 is indicated. In step 6, a service flow is created that can be used for exchanging IP-layer signaling messages, e.g., address assignment procedures using DHCP.
为了能够在MS和AR之间发送和接收IPv4分组，需要通过BS在MS和AR之间建立链路。本节解释链接建立程序，如[RFC5121]第6.2节所述。步骤1-4与[RFC5121]第6.2节所述步骤相同。在步骤5中，指示对IPv4的支持。在步骤6中，创建可用于交换IP层信令消息的服务流，例如，使用DHCP的地址分配过程。
IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the data payloads of the 802.16 PDU (see Section 3.2 of [RFC5154]).
IPv4数据包在802.16 PDU数据有效载荷中的通用IEEE 802.16 MAC帧中传输（参见[RFC5154]第3.2节）。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| TYPE |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload /
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| TYPE |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload /
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) |
+-+-+-+-+-+-+-+-+
Figure 1. IEEE 802.16 MAC Frame Format for IPv4 Packets
图1。IPv4数据包的IEEE 802.16 MAC帧格式
Here, "MSB" means "most significant byte", and "LSB" means "least significant byte".
这里，“MSB”表示“最高有效字节”，“LSB”表示“最低有效字节”。
H: Header Type (1 bit). Shall be set to zero, indicating that it is a Generic MAC PDU.
H：标头类型（1位）。应设置为零，表示它是通用MAC PDU。
E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload is encrypted.
E:加密控制。0=有效负载未加密；1=有效负载已加密。
R: Reserved. Shall be set to zero.
R:保留。应设置为零。
C: Cyclic Redundancy Check (CRC) Indicator. 1 = CRC is included; 0 = No CRC is included.
C：循环冗余校验（CRC）指示器。1=包括CRC；0=不包括CRC。
EKS: Encryption Key Sequence.
EKS：加密密钥序列。
LEN: The Length, in bytes, of the MAC PDU, including the MAC header and the CRC, if present (11 bits).
LEN：MAC PDU的长度，以字节为单位，包括MAC头和CRC（如果存在）（11位）。
CID: Connection Identifier (16 bits).
CID：连接标识符（16位）。
HCS: Header Check Sequence (8 bits).
HCS：报头检查序列（8位）。
CRC: An optional 8-bit field. The CRC is appended to the PDU after encryption.
CRC：可选的8位字段。CRC在加密后附加到PDU。
TYPE: This field indicates the subheaders (Mesh subheader, Fragmentation subheader, Packing subheader, etc.) and special payload types (e.g., Automatic Repeat reQuest (ARQ)) present in the message payload.
类型：此字段指示消息有效负载中存在的子标题（网格子标题、碎片子标题、包装子标题等）和特殊有效负载类型（例如，自动重复请求（ARQ））。
The MTU value for IPv4 packets on an IEEE 802.16 link is configurable (e.g., see the end of this section for some possible mechanisms). The default MTU for IPv4 packets over an IEEE 802.16 link SHOULD be 1500 octets. Given the possibility for "in-the-network" tunneling, supporting this MTU at the end hosts has implications on the underlying network, for example, as discussed in [RFC4459].
IEEE 802.16链路上IPv4数据包的MTU值是可配置的（例如，有关一些可能的机制，请参阅本节末尾）。IEEE 802.16链路上IPv4数据包的默认MTU应为1500个八位字节。考虑到“网络内”隧道的可能性，在终端主机上支持此MTU会对底层网络产生影响，例如，如[RFC4459]中所述。
Per [RFC5121], Section 6.3, the IP MTU can vary to be larger or smaller than 1500 octets.
根据[RFC5121]第6.3节，IP MTU可以变化为大于或小于1500个八位字节。
If an MS transmits 1500-octet packets in a deployment with a smaller MTU, packets from the MS may be dropped at the link layer silently. Unlike IPv6, in which departures from the default MTU are readily advertised via the MTU option in Neighbor Discovery (via router advertisement), there is no similarly reliable mechanism in IPv4, as
如果MS在具有较小MTU的部署中传输1500个八位组分组，则来自MS的分组可以在链路层无声地丢弃。与IPv6不同的是，在IPv6中，通过邻居发现中的MTU选项（通过路由器公告），可以很容易地公布与默认MTU不同的内容，IPv4中没有类似的可靠机制，例如
the legacy IPv4 client implementations do not determine the link MTU by default before sending packets. Even though there is a DHCP option to accomplish this, DHCP servers are required to provide the MTU information only when requested.
传统IPv4客户端实现在发送数据包之前默认情况下不确定链路MTU。尽管有一个DHCP选项可以实现这一点，但DHCP服务器仅在请求时才需要提供MTU信息。
Discovery and configuration of the proper link MTU value ensures adequate usage of the network bandwidth and resources. Accordingly, deployments should avoid packet loss due to a mismatch between the default MTU and the configured link MTUs.
发现和配置适当的链路MTU值可确保充分利用网络带宽和资源。因此，部署应避免由于默认MTU和配置的链路MTU之间的不匹配而导致的数据包丢失。
Some of the mechanisms available for the IPv4 CS host to find out the link's MTU value and mitigate MTU-related issues are:
IPv4 CS主机可用于查找链路的MTU值并缓解MTU相关问题的一些机制包括：
o Recent revision of 802.16 by the IEEE (see IEEE 802.16-2009 [IEEE802_16]) to (among other things) allow the provision of the Service Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, such that clients that are compliant with IEEE 802.16 can infer and configure the negotiated MTU size for the IPv4 CS link. However, the implementation must communicate the negotiated MTU value to the IP layer to adjust the IP Maximum Payload Size for proper handling of fragmentation. Note that this method is useful only when the MS is directly connected to the BS.
o IEEE对802.16的最新修订（参见IEEE 802.16-2009[IEEE802\u 16]），以（除其他外）允许在IEEE 802.16 SBC-REQ/SBC-RSP阶段提供服务数据单元或MAC MTU，从而符合IEEE 802.16的客户端可以推断和配置IPv4 CS链路的协商MTU大小。但是，实现必须将协商的MTU值传递给IP层，以调整IP最大有效负载大小，以便正确处理碎片。注意，该方法仅在MS直接连接到BS时有用。
o Configuration and negotiation of MTU size at the network layer by using the DHCP interface MTU option [RFC2132].
o 使用DHCP接口MTU选项[RFC2132]在网络层配置和协商MTU大小。
This document recommends that implementations of IPv4 and IPv4 CS clients SHOULD use the DHCP interface MTU option [RFC2132] in order to configure its interface MTU accordingly.
本文档建议IPv4和IPv4 CS客户端的实现应使用DHCP接口MTU选项[RFC2132]，以便相应地配置其接口MTU。
In the absence of DHCP MTU configuration, the client node (MS) has two alternatives: 1) use the default MTU (1500 bytes), or 2) determine the MTU by the methods described in IEEE 802.16-2009 [IEEE802_16].
在没有DHCP MTU配置的情况下，客户端节点（MS）有两种选择：1）使用默认MTU（1500字节），或2）通过IEEE 802.16-2009[IEEE802\u 16]中描述的方法确定MTU。
Additionally, the clients are encouraged to run Path MTU (PMTU) Discovery [RFC1191] or Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]. However, the PMTU mechanism has inherent problems of packet loss due to ICMP messages not reaching the sender and IPv4 routers not fragmenting the packets due to the Don't Fragment (DF) bit being set in the IP packet. The above-mentioned path MTU mechanisms will take care of the MTU size between the MS and its correspondent node across different flavors of convergence layers in the access networks.
此外，鼓励客户机运行路径MTU（PMTU）发现[RFC1191]或打包层路径MTU发现（PLPMTUD）[RFC4821]。然而，由于ICMP消息没有到达发送方，并且由于IP数据包中设置了不分段（DF）位，IPv4路由器没有对数据包进行分段，因此PMTU机制存在数据包丢失的固有问题。上述路径MTU机制将在接入网络中的不同融合层中照顾MS与其对应节点之间的MTU大小。
The subnet model recommended for IPv4 over IEEE 802.16 using IPv4 CS is based on the point-to-point link between the MS and the AR [RFC4968]; hence, each MS shall be assigned an address with a 32-bit prefix length or subnet mask. The point-to-point link between the MS and the AR is achieved using a set of IEEE 802.16 MAC connections (identified by service flows) and an L2 tunnel (e.g., a Generic Routing Encapsulation (GRE) tunnel) for each MS between the BS and the AR. If the AR is co-located with the BS, then the set of IEEE 802.16 MAC connections between the MS and the BS/AR represent the point-to-point connection.
建议使用IPv4 CS的IEEE 802.16上IPv4的子网模型基于MS和AR之间的点对点链路[RFC4968]；因此，应为每个MS分配一个具有32位前缀长度或子网掩码的地址。MS和AR之间的点到点链路是使用一组IEEE 802.16 MAC连接（由服务流标识）和用于BS和AR之间的每个MS的L2隧道（例如，通用路由封装（GRE）隧道）来实现的。如果AR与BS位于同一位置，然后，MS和BS/AR之间的IEEE 802.16 MAC连接集表示点到点连接。
The "next hop" IP address of the IPv4 CS MS is always the IP address of the AR, because the MS and the AR are attached via a point-to-point link.
IPv4 CS MS的“下一跳”IP地址始终是AR的IP地址，因为MS和AR通过点对点链路连接。
DHCP [RFC2131] SHOULD be used for assigning an IPv4 address for the MS. DHCP messages are transported over the IEEE 802.16 MAC connection to and from the BS and relayed to the AR. In case the DHCP server does not reside in the AR, the AR SHOULD implement a DHCP relay agent [RFC1542].
DHCP[RFC2131]应用于为MS分配IPv4地址。DHCP消息通过IEEE 802.16 MAC连接传输到BS和从BS传输到AR。如果DHCP服务器不在AR中，AR应实现DHCP中继代理[RFC1542]。
The IPv4 CS does not allow for transmission of Address Resolution Protocol (ARP) [RFC0826] packets. Furthermore, in a point-to-point link model, address resolution is not needed.
IPv4 CS不允许传输地址解析协议（ARP）[RFC0826]数据包。此外，在点到点链路模型中，不需要地址解析。
Multicast or broadcast packets from the MS are delivered to the AR via the BS through the point-to-point link. This specification simply assumes that the broadcast and multicast services are provided. How these services are implemented in an IEEE 802.16 Packet CS deployment is out of scope of this document.
来自MS的多播或广播分组经由BS通过点到点链路传送到AR。本规范仅假设提供了广播和多播服务。如何在IEEE 802.16数据包CS部署中实现这些服务超出了本文档的范围。
This document specifies transmission of IPv4 packets over IEEE 802.16 networks with the IPv4 Convergence Sublayer and does not introduce any new vulnerabilities to IPv4 specifications or operation. The security of the IEEE 802.16 air interface is the subject of [IEEE802_16]. In addition, the security issues of the network
本文档规定了通过IEEE 802.16网络通过IPv4汇聚子层传输IPv4数据包，并且没有对IPv4规范或操作引入任何新的漏洞。IEEE 802.16空中接口的安全性是[IEEE802\u 16]的主题。此外，网络的安全问题
architecture spanning beyond the IEEE 802.16 Base Stations is the subject of the documents defining such architectures, such as the Worldwide Interoperability for Microwave Access (WiMAX) network architecture [WMF].
跨越IEEE 802.16基站的架构是定义此类架构的文件的主题，例如全球微波接入互操作性（WiMAX）网络架构[WMF]。
The authors would like to acknowledge the contributions of Bernard Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil, Paolo Narvaez, and Bruno Sousa for their review and comments. The working group members Burcak Beser, Wesley George, Max Riegel, and DJ Johnston helped shape the MTU discussion for the IPv4 CS link. Thanks to many other members of the 16ng Working Group who commented on this document to make it better.
作者感谢Bernard Aboba、Dave Thaler、Jari Arkko、Bachet Sarikaya、Basavaraj Patil、Paolo Narvaez和Bruno Sousa的评论和评论。工作组成员Burcak Beser、Wesley George、Max Riegel和DJ Johnston帮助形成了IPv4 CS链路的MTU讨论。感谢16ng工作组的许多其他成员，他们对本文件发表了意见，使其更加完善。
[IEEE802_16] "IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems", May 2009.
[IEEE802_16]“IEEE标准802.16-2009，局域网和城域网标准草案，第16部分：宽带无线接入系统的空中接口”，2009年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0826] 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.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542]Wimer，W.“引导协议的澄清和扩展”，RFC 1542，1993年10月。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation Methods Considered Harmful", RFC 4840, April 2007.
[RFC4840]Aboba，B.，Davies，E.，和D.Thaler，“认为有害的多种封装方法”，RFC 4840，2007年4月。
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007.
[RFC4968]Madanapalli，S.，“基于802.16网络的IPv6链路模型分析”，RFC 4968，2007年8月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121]Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月。
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 802.16 Problem Statement and Goals", RFC 5154, April 2008.
[RFC5154]Jee，J.，Madanapalli，S.，和J.Mandin，“IP over IEEE 802.16问题陈述和目标”，RFC 5154，2008年4月。
[WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/", January 2008.
[WMF]“WiMAX端到端网络系统架构第2-3阶段1.2版，http://www.wimaxforum.org/“，2008年1月。
Two different MSs using two different Convergence Sublayers (e.g., an MS using Ethernet CS only and another MS using IPv4 CS only) cannot communicate at the data link layer and require interworking at the IP layer. For this reason, these two nodes must be configured to be on two different subnets. For more information, refer to [RFC4840].
使用两个不同汇聚子层的两个不同MS（例如，一个MS仅使用以太网CS，另一个MS仅使用IPv4 CS）无法在数据链路层进行通信，需要在IP层进行互通。因此，必须将这两个节点配置为位于两个不同的子网上。有关更多信息，请参阅[RFC4840]。
IEEE 802.16 MAC is a point-to-multipoint connection-oriented air interface, and the process of sending and receiving IPv4 packets is different from multicast-capable shared-medium technologies like Ethernet.
IEEE 802.16 MAC是一种面向点对多点连接的空中接口，发送和接收IPv4数据包的过程不同于以太网等支持多播的共享媒体技术。
Before any packets are transmitted, an IEEE 802.16 transport connection must be established. This connection consists of an IEEE 802.16 MAC transport connection between the MS and the BS and an L2 tunnel between the BS and the AR (if these two are not co-located). This IEEE 802.16 transport connection provides a point-to-point link between the MS and the AR. All the packets originating at the MS always reach the AR before being transmitted to the final destination.
在传输任何数据包之前，必须建立IEEE 802.16传输连接。该连接包括MS和BS之间的IEEE 802.16 MAC传输连接，以及BS和AR之间的L2隧道（如果这两个通道不在同一位置）。此IEEE 802.16传输连接在MS和AR之间提供点对点链路。在MS发起的所有数据包在传输到最终目的地之前始终到达AR。
IPv4 packets are carried directly in the payload of IEEE 802.16 frames when the IPv4 CS is used. IPv4 CS classifies the packet based on upper-layer (IP and transport layers) header fields to place the packet on one of the available connections identified by the CID. The classifiers for the IPv4 CS are source and destination IPv4 addresses, source and destination ports, Type-of-Service, and IP Protocol field. The CS may employ Packet Header Suppression (PHS) after the classification.
当使用IPv4 CS时，IPv4数据包直接携带在IEEE 802.16帧的有效负载中。IPv4 CS基于上层（IP和传输层）报头字段对数据包进行分类，以将数据包放在CID标识的一个可用连接上。IPv4 CS的分类器是源和目标IPv4地址、源和目标端口、服务类型和IP协议字段。CS可在分类之后采用分组报头抑制（PHS）。
The BS optionally reconstructs the payload header if PHS is in use. It then tunnels the packet that has been received on a particular MAC connection to the AR. Similarly, the packets received on a tunnel interface from the AR would be mapped to a particular CID using the IPv4 classification mechanism.
如果PHS正在使用，BS选择性地重构有效负载报头。然后通过隧道将在特定MAC连接上接收到的数据包传输到AR。类似地，通过隧道接口从AR接收到的数据包将使用IPv4分类机制映射到特定CID。
The AR performs normal routing for the packets that it receives, processing them per its forwarding table. However, the DHCP relay agent in the AR MUST maintain the tunnel interface on which it receives DHCP requests so that it can relay the DHCP responses to the correct MS. The particular method is out of scope of this specification as it need not depend on any particularities of IEEE 802.16.
AR对其接收的数据包执行正常路由，并根据其转发表对其进行处理。但是，AR中的DHCP中继代理必须维护其接收DHCP请求的隧道接口，以便能够将DHCP响应中继到正确的MS。特定方法不在本规范的范围内，因为它不需要依赖于IEEE 802.16的任何特殊性。
The WiMAX (Worldwide Interoperability for Microwave Access) forum has defined a network architecture [WMF]. Furthermore, WiMAX has specified IPv4 CS support for transmission of IPv4 packets between the MS and the BS over the IEEE 802.16 link. The WiMAX IPv4 CS and this specification are similar. One significant difference, however, is that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets [WMF] as opposed to 1500 in this specification.
WiMAX（全球微波接入互操作性）论坛定义了一种网络架构[WMF]。此外，WiMAX已指定IPv4 CS支持通过IEEE 802.16链路在MS和BS之间传输IPv4数据包。WiMAX IPv4 CS与此规范类似。然而，一个显著的区别是WiMAX论坛[WMF]将IP MTU指定为1400个八位字节[WMF]，而不是本规范中的1500个八位字节。
Hence, if an IPv4 CS MS configured with an MTU of 1500 octets enters a WiMAX network, some of the issues mentioned in this specification may arise. As mentioned in Section 4.3, the possible mechanisms are not guaranteed to work. Furthermore, an IPv4 CS client is not capable of doing ARP probing to find out the link MTU. On the other hand, it is imperative for an MS to know the link MTU size. In practice, an MS should be able to sense or deduce the fact that it is operating within a WiMAX network (e.g., given the WiMAX-specific particularities of the authentication and network entry procedures), and adjust its MTU size accordingly. Even though this method is not perfect, and the potential for conflict may remain, this document recommends a default MTU of 1500. This represents the WG's consensus (after much debate) to select the best value for IEEE 802.16 from the point of view of the IETF, in spite of the WiMAX Forum's deployment.
因此，如果配置有1500个八位字节MTU的IPv4 CS MS进入WiMAX网络，则可能会出现本规范中提到的一些问题。如第4.3节所述，不保证可能的机制工作。此外，IPv4 CS客户端无法进行ARP探测以找出链路MTU。另一方面，MS必须知道链路MTU的大小。实际上，MS应该能够感知或推断其在WiMAX网络内运行的事实（例如，考虑到认证和网络进入程序的WiMAX特定特性），并相应地调整其MTU大小。尽管此方法并不完美，且可能存在冲突，但本文档建议默认MTU为1500。这代表了工作组的共识（经过多次辩论后），即从IETF的角度选择IEEE 802.16的最佳价值，尽管WiMAX论坛已经部署。
Authors' Addresses
作者地址
Syam Madanapalli iRam Technologies #H304, Shriram Samruddhi, Thubarahalli Bangalore - 560066 India
Syam Madanapalli iRam Technologies#H304，Shriram Samruddhi，Thubarahali Bangalore-560066印度
EMail: smadanapalli@gmail.com
EMail: smadanapalli@gmail.com
Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
Soohong Daniel Park三星电子416 Maetan-3dong，永通谷水原442-742韩国
EMail: soohong.park@samsung.com
EMail: soohong.park@samsung.com
Samita Chakrabarti IP Infusion 1188 Arques Avenue Sunnyvale, CA USA
Samita Chakrabarti IP输液美国加利福尼亚州桑尼维尔阿克斯大道1188号
EMail: samitac@ipinfusion.com
EMail: samitac@ipinfusion.com
Gabriel Montenegro Microsoft Corporation Redmond, WA USA
加布里埃尔黑山微软公司，华盛顿州雷德蒙
EMail: gabriel.montenegro@microsoft.com
EMail: gabriel.montenegro@microsoft.com