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
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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_16]ラストマイルの接続指向のアクセス技術です。 IEEE 802.16仕様では、物理（PHY）及びメディアアクセス制御（MAC）層を含みます。 MAC層は、IPv4パケット[IEEE802_16]を含む上位層パケットを送信するための様々な収束サブレイヤ（CSS）を含みます。
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.
本明細書の範囲は、IEEE規格802.16エアインタフェースを利用してネットワークによってサービスホストに対してパケットCS（「IPv4のCS」とも呼ばれる）のIP固有部分上のIPv4の動作に限定されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ホストを指すために使用されます。この用法は、「MS」は、全体のホストにIEEE 802.16 MACおよびPHY層を実装していないインタフェースを意味する、IEEE 802.16におけるよりも非公式です。
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）、（MSとARとの間のIPv4リンクの観点から）、レイヤ2（L2）エンティティを介してアクセス・ルータ（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パケットのカプセル化の詳細については、[IEEE802_16] [RFC5121]のセクション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 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.
ARとBSが同一場所に配置されている場合、MSへの転送接続の集合は、単一のIPv4リンクとして定義されます。 ARとBSが分離されている場合には、トンネルがARとその粒度「MS当たり」または「サービス・フローごとの」よりも大きくないBSとの間で確立されることが推奨されます。 （MSがサービスフローIDによって識別される複数のサービスフローを有することができる。）次に、MSのためのトンネル（S）は、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リンクに属し、（[RFC4968]）「IEEE 802.16ベースのネットワークの分析のIPv6リンクのモデル」で説明した推奨事項と同様にユニークなIPv4アドレスが割り当てられています。
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において、サービスフローは、DHCPを用いてIP層シグナリングメッセージ、例えば、アドレス割当て手順を交換するために使用することができるが作成されます。
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パケットは、一般的なIEEE 802.16 PDUのデータペイロード内の802.16 MACフレームで送信される（セクション3.2参照[RFC5154]）。
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
IPv4のパケット図1. 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.
TYPE：このフィールドは、サブヘッダ（メッシュサブヘッダ、断片化サブヘッダ、パッキングサブヘッダ等）及びメッセージペイロード内に存在する特別なペイロードタイプ（例えば、自動再送要求（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 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.
MSが小さいMTUと展開1500オクテットのパケットを送信する場合、MSからのパケットは、黙っリンク層で滴下してもよいです。レガシーのIPv4クライアントの実装は、前にデフォルトでは、リンクのMTUを決定しないと、デフォルトMTUからの逸脱を容易に（ルータ広告を経由して）近隣探索におけるMTUオプションで宣伝されているIPv6のとは異なり、IPv4の同様に信頼性の高いメカニズムは、まったくありませんパケットを送信します。これを達成するための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:
リンクのMTU値を見つけると、MTU関連の問題を軽減するためのIPv4 CSホストの利用可能なメカニズムのいくつかは、次のとおりです。
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 SBC-REQ / SBC-RSP段階でのサービスデータユニットまたはMAC MTUの提供を許可する（とりわけ）へ（IEEE 802.16から2009 [IEEE802_16]を参照してください） IEEE 802.16に準拠しているクライアントは、IPv4 CSリンクのために交渉MTUサイズを推測して設定することができます。しかし、実装は断片化の適切な取扱いのためのIP最大ペイロードサイズを調整するためにIP層に交渉さMTU値を通信する必要があります。 MSが直接BSに接続されている場合にのみ、この方法が有用であることに留意されたいです。
o Configuration and negotiation of MTU size at the network layer by using the DHCP interface MTU option [RFC2132].
DHCPインターフェイスMTUオプション[RFC2132]を使用して、ネットワーク層でのMTUサイズのO構成と交渉。
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クライアントの実装は、それに応じてインターフェイスのMTUを設定するためにDHCPインターフェイスMTUオプション[RFC2132]を使用することをお勧めします。
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].
1）デフォルトMTU（1500バイト）を使用する、または2）IEEE802_16] IEEE 802.16から2009に記載の方法によってMTUを決定する：DHCP MTU構成の非存在下で、クライアント・ノード（MS）は、二つの選択肢を有しています。
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]を実行することをお勧めします。しかし、PMTUメカニズムは、IPパケットに設定されたビットにより、送信者に到達していないICMPメッセージと原因ないフラグメント（DF）にパケットを断片化しませIPv4ルーターのパケット損失の固有の問題があります。上記パス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接続のセット及びL2トンネルを使用して達成される（例えば、汎用ルーティングカプセル化（GRE）トンネル）との間の各MSについてBSとAR。 ARは、BSと同一場所に配置されている場合は、IEEE 802.16のセットは、MS及び/ AR BSとの間の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.
MSとARは、ポイントツーポイントリンクを介して結合されているので、IPv4のCS MSの「ネクストホップ」IPアドレスは、常にARのIPアドレスです。
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メッセージは、BSへとからIEEE 802.16 MAC接続を介して運ばれ、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に送達されます。この仕様は、単にブロードキャストおよびマルチキャストサービスが提供されていることを前提としています。どのようにこれらのサービスは、CSの展開は、このドキュメントの範囲外であるIEEE 802.16パケット内に実装されています。
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
この文書では、IPv4のコンバージェンス副層とIEEE 802.16ネットワーク上でIPv4パケットの送信を指定するとIPv4の仕様や動作に新たな脆弱性を導入しません。 IEEE 802.16エアインタフェースのセキュリティは[IEEE802_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.
作者は彼らのレビューとコメントのためのバーナードAboba、デーブターラー、ヤリArkko、Bachet Sarikaya、Basavarajパティル、パオロ・ナルバエス、そしてブルーノ・スーザの貢献を認めたいと思います。ワーキンググループのメンバーBurcak Beser、ウェズリー・ジョージ、マックスリーゲル、そしてDJジョンストンは、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]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年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]プラマー、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]、RFC 4459 Savola、P.、 "イン・ネットワークのトンネリングを使用したMTUと断片化の問題"、2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation Methods Considered Harmful", RFC 4840, April 2007.
[RFC4840] Aboba、B.、デイヴィス、E.、およびD.ターラー、 "有害と考えられ、複数のカプセル化メソッド"、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]パティル、B.、夏、F.、Sarikaya、B.、チェ、JH。、およびS. Madanapalli、 "IEEE 802.16ネットワークの上のIPv6コンバージェンスサブレイヤを介したIPv6の送信"、RFC 5121、2008年2月。
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 802.16 Problem Statement and Goals", RFC 5154, April 2008.
[RFC5154]ジヨン、J.、Madanapalli、S.、およびJ. Mandin、RFC 5154、2008年4月 "IP IEEE 802.16問題文と目標を超えます"。
[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月。
Appendix A. Multiple Convergence Layers -- Impact on Subnet Model
付録A.複数のコンバージェンスレイヤ - サブネットモデルへの影響
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つの異なる収束サブレイヤを使用して（例えば、IPv4のみCSを使用してのみ、イーサネットCSを使用して、別のMS MS）は、データリンク層で通信し、IP層でのインターワーキングを必要とすることができません。このため、これら2つのノードは2つの異なるサブネット上にあるように設定する必要があります。詳細については、[RFC4840]を参照。
Appendix B. Sending and Receiving IPv4 Packets
付録B.は、IPv4パケットを送受信します
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は、CIDによって識別された利用可能な接続のいずれかにパケットを配置するために、上位層（IP層とトランスポート層）ヘッダフィールドに基づいてパケットを分類します。 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は、必要に応じてペイロードヘッダを再構築します。その後、ARに特定のMAC接続で受信されたパケットをトンネルします。同様に、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リレーエージェントは、それが正しいMSへのDHCP応答を中継することができるように、それがDHCP要求を受信したトンネルインターフェースを維持しなければなりません。それはIEEE 802.16のいずれかの特殊性に依存しない必要があるとして、特定の方法は、この仕様の範囲外です。
Appendix C. WiMAX IPv4 CS MTU Size
付録C. WiMAXのIPv4のCS MTUサイズ
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は、MSとIEEE 802.16リンクを介してBSとの間のIPv4パケットの送信のIPv4 CSサポートを指定しています。 WiMAXのIPv4のCSと、この仕様は似ています。大きな違いの1つは、しかし、WiMAXフォーラムは[WMF】本明細書では1500年とは対照的に、1400オクテット[WMF]としてIP MTUを指定しているということです。
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.
したがって、IPv4のCS MSが1500オクテットのMTUで構成されている場合は、本明細書に記載された問題のいくつかが発生する可能性があり、WiMAXネットワークに入ります。 4.3節で述べたように、可能なメカニズムは、動作が保証されていません。さらに、IPv4のCSクライアントがリンクMTUを見つけるために、プロービングARPを行うことが可能ではありません。 MSは、リンクのMTUサイズを知っているため一方、それが不可欠です。実際には、MSは、センスまたはそれがWiMAXネットワーク（例えば、認証およびネットワークエントリ手順のWiMAXの固有の特殊所与）内で動作していることを推測し、それに応じてそのMTUサイズを調整することができなければなりません。この方法は完璧ではない、との競合の可能性が残っている場合でも、この文書は1500年のデフォルトMTUを推奨していますこれは、の観点から、IEEE 802.16のための最高の値を選択するために、（多くの議論の後）WGのコンセンサスを表しWiMAXフォーラムの展開にもかかわらずIETF、。
Authors' Addresses
著者のアドレス
Syam Madanapalli iRam Technologies #H304, Shriram Samruddhi, Thubarahalli Bangalore - 560066 India
560066、インド - シャムmadanapalli IRAMテクノロジーズ＃304ヘクタール、スリラムの豊富は、バンガロールをtubarahalli
EMail: smadanapalli@gmail.com
メールアドレス：smadanapalli@gmail.com
Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
Soohongダニエル・パークサムスン電子416 Maetan-3dong、霊通区水原442から742韓国
EMail: soohong.park@samsung.com
メールアドレス：soohong.park@samsung.com
Samita Chakrabarti IP Infusion 1188 Arques Avenue Sunnyvale, CA USA
スミスChakrabarti IPインフュージョン1188アルクアベニューサニーベール、CA USA
EMail: samitac@ipinfusion.com
メールアドレス：samitac@ipinfusion.com
Gabriel Montenegro Microsoft Corporation Redmond, WA USA
がｂりえｌ もんてねｇろ みｃろそｆｔ こｒぽらちおん れｄもんｄ、 わ うさ
EMail: gabriel.montenegro@microsoft.com
メールアドレス：gabriel.montenegro@microsoft.com