[要約] RFC 5948は、IEEE 802.16のIP収束サブレイヤーを介してIPv4パケットを転送するための仕様です。このRFCの目的は、IPv4パケットの効率的な転送と相互運用性の向上を実現することです。
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（Packet Convergence Sublayer）は、インターネットプロトコル（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.
このドキュメントは、IEEE 802.16のパケットコンバージェンスサブレイヤーのIP固有の部分にIPv4パケットを送信するためのフレーム形式、最大送信ユニット（MTU）、およびアドレス割り当て手順を指定します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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 STD 802.16エアインターフェイスを利用するネットワークが提供するホストのパケットCSのIP固有の部分（「IPv4 CS」と呼ばれる）の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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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）エンティティを介してアクセスルーター（AR）に接続されます（MSとARの間のIPv4リンクの観点から）。
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 Convergence SublayerとIPパケットのカプセル化の詳細については、[RFC5121]および[IEEE802_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 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とBSの間にトンネルを確立することをお勧めします。（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リンクに属し、「IEEE 802.16ベースのネットワークのIPv6リンクモデルの分析」（[RFC4968]）で説明されている推奨事項と同様に、一意の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パケットは、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) |
+-+-+-+-+-+-+-+-+
Figure 1. IEEE 802.16 MAC Frame Format for IPv4 Packets
図1. IEEE 802.16 IPv4パケット用の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：存在する場合（11ビット）の場合、MacヘッダーとCRCを含むMac PDUの長さ、バイト単位の長さ。
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 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からのパケットがリンクレイヤーで静かにドロップされる場合があります。デフォルトのMTUからの出発が近隣発見のMTUオプション（ルーター広告を介して）を介して容易に宣伝されるIPv6とは異なり、Legacy IPv4クライアントの実装は以前にデフォルトでリンクMTUを決定しないため、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:
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_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クライアントの実装は、それに応じてインターフェイス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].
DHCP MTU構成がない場合、クライアントノード（MS）には2つの選択肢があります。1）デフォルトのMTU（1500バイト）を使用するか、2）IEEE 802.16-2009 [IEEE802_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.
さらに、クライアントは、PATH MTU（PMTU）ディスカバリー[RFC1191]またはパケット化レイヤーパスMTUディスカバリー（PLPMTUD）[RFC4821]を実行することをお勧めします。ただし、PMTUメカニズムには、ICMPメッセージに届かないICMPメッセージによるパケット損失の固有の問題があり、IPパケットで設定されていない（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トンネルのセット（例：各MSの汎用ルーティングカプセル化（GRE）トンネル）を使用して達成されます。BSおよびAR。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.
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メッセージは、IEEE 802.16 Mac接続を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 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].
このドキュメントは、IPV4 Convergence Sublayerを備えたIEEE 802.16ネットワークを介したIPv4パケットの送信を指定し、IPv4仕様または操作に新しい脆弱性を導入しません。IEEE 802.16エアインターフェイスのセキュリティは、[IEEE802_16]の主題です。さらに、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.
著者は、バーナード・アボバ、デイブ・タラー、ジャリ・アークコ、バシェット・サリカヤ、バサヴァラジ・パティル、パオロ・ナルヴェズ、ブルーノ・スーサのレビューとコメントの貢献を認めたいと思います。ワーキンググループのメンバーである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 STD 802.16-2009、ローカルおよびメトロポリタンエリアネットワークのドラフト標準、パート16：ブロードバンドワイヤレスアクセスシステムのエアインターフェイス」、2009年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、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 2132、1997年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、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年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 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] 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].
2つの異なる収束サブレイヤーを使用した2つの異なるMSS（たとえば、イーサネットCSのみを使用してMSとIPv4 CSのみを使用して別のMSを使用する）は、データリンクレイヤーで通信できず、IPレイヤーでインターワーキングを必要とします。このため、これらの2つのノードは、2つの異なるサブネット上にあるように構成する必要があります。詳細については、[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トンネルで構成されています（これら2つが共同で配置されていない場合）。この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によって識別された利用可能な接続の1つにパケットを配置します。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.
BSは、PHSが使用されている場合、オプションでペイロードヘッダーを再構築します。次に、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リレーエージェントは、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は、IEEE 802.16リンクを介したMSとBS間のIPv4パケットの送信のためのIPv4 CSサポートを指定しています。WIMAX IPv4 CSとこの仕様は似ています。ただし、重要な違いの1つは、Wimaxフォーラム[WMF]が、この仕様で1500ではなく1500であるのではなく、IP MTUを1400オクテット[WMF]として指定したことです。
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クライアントは、リンクMTUを見つけるためにARPプロービングを行うことはできません。一方、MSがリンクMTUサイズを知ることが不可欠です。実際には、MSは、WIMAXネットワーク内で動作しているという事実（たとえば、認証およびネットワーク入力手順のWIMAX固有の特殊性を考慮する）を感知または推測し、それに応じてMTUサイズを調整できる必要があります。この方法は完全ではなく、競合の可能性が残っている可能性がありますが、このドキュメントはデフォルトのMTUの1500を推奨しています。これは、WGのコンセンサス（多くの議論の後）を表して、IEEE 802.16に最適な価値を選択することを表しています。IETFは、WIMAXフォーラムの展開にもかかわらず。
Authors' Addresses
著者のアドレス
Syam Madanapalli iRam Technologies #H304, Shriram Samruddhi, Thubarahalli Bangalore - 560066 India
Syam Madanapalli IRAM Technologies＃H304、Shriram Samruddhi、Thubarahalli Bangalore -560066 India
EMail: smadanapalli@gmail.com
Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
スーホンダニエルパークサムスンエレクトロニクス416 Maetan-3dong、Yeongtong-gu Suwon 442-742 Korea
EMail: soohong.park@samsung.com
Samita Chakrabarti IP Infusion 1188 Arques Avenue Sunnyvale, CA USA
Samita Chakrabarti IP Infusion 1188 Arques Avenue Sunnyvale、CA米国
EMail: samitac@ipinfusion.com
Gabriel Montenegro Microsoft Corporation Redmond, WA USA
Gabriel Montenegro Microsoft Corporation Redmond、WA USA
EMail: gabriel.montenegro@microsoft.com