[要約] RFC 5121は、IEEE 802.16ネットワーク上でのIPv6の伝送に関する標準化されたプロトコルです。このRFCの目的は、IPv6の効率的な伝送を実現し、IEEE 802.16ネットワーク上でのIPv6の利用を促進することです。
Network Working Group B. Patil
Request for Comments: 5121 Nokia Siemens Networks
Category: Standards Track F. Xia
B. Sarikaya
Huawei USA
JH. Choi
Samsung AIT
S. Madanapalli
Ordyn Technologies
February 2008
Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks
IEEE 802.16ネットワークを介したIPv6コンバージェンスサブレイヤーを介したIPv6の送信
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
概要
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet-based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers.
IEEE STD 802.16は、固定およびモバイルブロードバンドワイヤレスアクセスシステムのエアインターフェイス仕様です。上層層プロトコルインターフェイスがIEEE 802.16 MAC（ミディアムアクセス制御）の一部であるサービス固有の収束サブレーヤー。パケットコンバージェンスサブレイヤー（CS）は、インターネットプロトコル（IP）やIEEE 802.3 LAN/MAN CSMA/CDアクセス法（イーサネット）などのすべてのパケットベースのプロトコルの輸送に使用されます。IPv6パケットは、パケットCSのIP固有の部分を介して送信および受信できます。このドキュメントは、IEEE STD 802.16エアインターフェイスを利用するネットワークが提供するホストのパケットCSのIP固有の部分におけるIPv6のアドレス指定と操作を指定します。各ホストに一意のプレフィックス（またはプレフィックス）を割り当てることを推奨し、ランダムに生成されたインターフェイス識別子のサポートを含む、ホストがそのプレフィックス内で複数の識別子を使用できるようにします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. IEEE 802.16 Convergence Sublayer Support for IPv6 . . . . . . 4
4.1. IPv6 Encapsulation over the IP CS of the MAC . . . . . . . 7
5. Generic Network Architecture Using the 802.16 Air Interface . 8
6. IPv6 Link . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. IPv6 Link in 802.16 . . . . . . . . . . . . . . . . . . . 9
6.2. IPv6 Link Establishment in 802.16 . . . . . . . . . . . . 10
6.3. Maximum Transmission Unit in 802.16 . . . . . . . . . . . 11
7. IPv6 Prefix Assignment . . . . . . . . . . . . . . . . . . . . 12
8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 12
8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 12
8.3. Router Lifetime and Periodic Router Advertisements . . . . 13
9. IPv6 Addressing for Hosts . . . . . . . . . . . . . . . . . . 13
9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 13
9.2. Duplicate Address Detection . . . . . . . . . . . . . . . 13
9.3. Stateless Address Autoconfiguration . . . . . . . . . . . 14
9.4. Stateful Address Autoconfiguration . . . . . . . . . . . . 14
10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. WiMAX Network Architecture and IPv6 Support . . . . . 17
Appendix B. IPv6 Link in WiMAX . . . . . . . . . . . . . . . . . 19
Appendix C. IPv6 Link Establishment in WiMAX . . . . . . . . . . 19
Appendix D. Maximum Transmission Unit in WiMAX . . . . . . . . . 20
IEEE 802.16e is an air interface for fixed and mobile broadband wireless access systems. The IEEE 802.16 [802.16] standard specifies the air interface, including the Medium Access Control (MAC) layer and multiple physical layer (PHY) specifications. It can be deployed in licensed as well as unlicensed spectrum. While the PHY and MAC are specified in IEEE 802.16, the details of IPv4 and IPv6 operation over the air interface are not included. This document specifies the operation of IPv6 over the IEEE 802.16 air interface.
IEEE 802.16Eは、固定およびモバイルブロードバンドワイヤレスアクセスシステムのエアインターフェイスです。IEEE 802.16 [802.16]標準は、中間アクセス制御（MAC）層と複数の物理層（PHY）仕様を含むエアインターフェイスを指定しています。ライセンスと免許のないスペクトルで展開できます。PHYとMACはIEEE 802.16で指定されていますが、AIRインターフェイス上のIPv4およびIPv6操作の詳細は含まれていません。このドキュメントは、IEEE 802.16 AIRインターフェイスを介したIPv6の動作を指定しています。
IPv6 packets can be carried over the IEEE Std 802.16 specified air interface via:
IPv6パケットは、IEEE STD 802.16指定されたエアインターフェイスを介して持ち運ぶことができます。
1. the IP-specific part of the Packet CS or
1. パケットCSのIP固有の部分または
2. the 802.3[802.3]-specific part of the Packet CS
2. 802.3 [802.3] - パケットCSの特異的部分
The scope of this specification is limited to the operation of IPv6 over IP CS only.
この仕様の範囲は、IP CSのみのIPv6の操作に限定されます。
The IEEE 802.16 specification includes the PHY and MAC details. The convergence sublayers are a part of the MAC. The packet convergence sublayer includes the IP-specific part that is used by the IPv6 layer.
IEEE 802.16仕様には、PhyおよびMacの詳細が含まれています。収束サブレイヤーはMACの一部です。パケット収束サブレイヤーには、IPv6レイヤーが使用するIP固有の部分が含まれています。
The mobile station (MS)/host is attached to an access router via a base station (BS). The host and the BS are connected via the IEEE Std 802.16 air interface at the link and physical layers. The IPv6 link from the MS terminates at an access router that may be a part of the BS or an entity beyond the BS. The base station is a layer 2 entity (from the perspective of the IPv6 link between the MS and access router (AR)) and relays the IPv6 packets between the AR and the host via a point-to-point connection over the air interface.
モバイルステーション（MS）/ホストは、ベースステーション（BS）を介してアクセスルーターに接続されています。ホストとBSは、リンクと物理層のIEEE STD 802.16エアインターフェイスを介して接続されます。MSからのIPv6リンクは、BSまたはBSを超えたエンティティの一部である可能性のあるアクセスルーターで終了します。ベースステーションは、レイヤー2エンティティ（MSとアクセスルーター（AR）の間のIPv6リンクの観点から）であり、ARとホストの間のIPv6パケットをエアインターフェイス上のポイントツーポイント接続を介してリレーします。
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [PS-GOALS].
このドキュメントの用語は、「802.16を超える問題の声明と目標を超えるIP」[PS-Goals]の定義に基づいています。
o IP CS - The IP-specific part of the Packet convergence sublayer is referred to as IP CS. IPv6 CS and IP CS are used interchangeably.
o IP CS-パケットコンバージェンスサブレイヤーのIP固有の部分は、IP CSと呼ばれます。IPv6 CSとIP CSは同じ意味で使用されます。
o Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) - The terms subscriber station, mobile station, and mobile node are used interchangeably in this document and mean the same, i.e., an IP host.
o サブスクライバーステーション（SS）、モバイルステーション（MS）、モバイルノード（MN） - サブスクライバーステーション、モバイルステーション、モバイルノードという用語は、このドキュメントで同じ意味で使用され、同じ、つまりIPホストです。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The IEEE 802.16 MAC specifies two main service-specific convergence sublayers:
IEEE 802.16 MACは、2つの主要なサービス固有の収束崇高なサブレーヤーを指定します。
1. ATM convergence sublayer
1. ATM収束サブレイヤー
2. Packet convergence sublayer
2. パケット収束サブレイヤー
The Packet CS is used for the transport of packet-based protocols, which include:
パケットCSは、パケットベースのプロトコルの輸送に使用されます。
1. IEEE Std 802.3(Ethernet)
1. IEEE STD 802.3（イーサネット）
2. Internet Protocol (IPv4 and IPv6)
2. インターネットプロトコル（IPv4およびIPv6）
The service-specific CS resides on top of the MAC Common Part Sublayer (CPS) as shown in Figure 1. The service-specific CS is responsible for:
サービス固有のCSは、図1に示すように、Mac Common Part Sublayer（CPS）の上に存在します。サービス固有のCSは次の責任があります。
o accepting packets (Protocol Data Units, PDUs) from the upper layer,
o
o performing classification of the packet/PDU based on a set of defined classifiers that are service specific,
o サービス固有の定義された分類器のセットに基づいて、パケット/PDUの分類を実行する、
o delivering the CS PDU to the appropriate service flow and transport connection, and
o CS PDUを適切なサービスフローと輸送接続に配信し、
o receiving PDUs from the peer entity.
o ピアエンティティからPDUを受信します。
Payload header suppression (PHS) is also a function of the CS but is optional.
ペイロードヘッダー抑制（PHS）もCSの関数ですが、オプションです。
The figure below shows the concept of the service-specific CS in relation to the MAC:
以下の図は、Macに関連するサービス固有のCSの概念を示しています。
------------------------------\
| ATM CS | Packet CS | \
------------------------------ \
| MAC Common Part Sublayer | \
| (Ranging, scheduling, etc.)| 802.16 MAC
------------------------------ /
| Security | /
|(Auth, encryption, key mgmt)| /
------------------------------/
| PHY |
------------------------------
Figure 1: IEEE 802.16 MAC
図1：IEEE 802.16 Mac
Classifiers for each of the specific upper-layer protocols, i.e., Ethernet and IP, are defined in the IEEE 802.16 specification, which enable the packets from the upper layer to be processed by the appropriate service-specific part of the Packet CS. IPv6 can be transported directly over the IP-specific part of the Packet CS (IP CS). IPv4 packets also are transported over the IP-specific part of the Packet CS. The classifiers used by IP CS enable the differentiation of IPv4 and IPv6 packets and their mapping to specific transport connections over the air interface.
特定の上部層プロトコルのそれぞれ、つまりイーサネットとIPの分類器は、IEEE 802.16仕様で定義されており、上層からのパケットをパケットCSの適切なサービス固有の部分によって処理できるようにします。IPv6は、パケットCS（IP CS）のIP固有の部分に直接輸送できます。IPv4パケットは、パケットCSのIP固有の部分にも輸送されます。IP CSで使用される分類器は、IPv4とIPv6パケットの区別と、エアインターフェイス上の特定の輸送接続へのマッピングを可能にします。
The figure below shows the options for IPv6 transport over the packet CS of IEEE 802.16:
以下の図は、IEEE 802.16のパケットCS上のIPv6輸送のオプションを示しています。
+-------------------+
| IPv6 |
+-------------------+ +-------------------+
| IPv6 | | Ethernet |
+-------------------+ +-------------------+
| IP-specific | | 802.3-specific |
| part of Packet CS | | part of Packet CS |
|...................| |...................|
| MAC | | MAC |
+-------------------+ +-------------------+
| PHY | | PHY |
+-------------------+ +-------------------+
(1) IPv6 over (2) IPv6 over
IP-specific part 802.3/Ethernet-
of Packet CS specific part
of Packet CS
Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CS
図2：パケットCSのIP-および802.3固有の部分を超えるIPv6
The figure above shows that while there are multiple methods by which IPv6 can be transmitted over an 802.16 air interface, the scope of this document is limited to IPv6 operation over IP CS only. Transmission of IP over Ethernet is specified in [IPoE-over-802.16]. Transmission of IPv4 over IP CS is specified in [IPv4-over-IPCS].
上の図は、IPv6を802.16エアインターフェイスに渡ることができる複数の方法があるが、このドキュメントの範囲はIP CSのみのIPv6操作に限定されていることを示しています。イーサネットを介したIPの伝送は、[IPOE-Over-802.16]で指定されています。IP CSを介したIPv4の伝送は、[IPv4-over-IPCS]で指定されています。
It should be noted that immediately after ranging (802.16 air interface procedure) and exchange of SBC-REQ/RSP messages (802.16 specific), the MS and BS exchange their capabilities via REG-REQ (Registration Request) and REG-RSP (Registration Response) 802.16 MAC messages. These management frames negotiate parameters such as the Convergence Sublayer supported by the MS and BS. By default, Packet, IPv4, and 802.3/Ethernet are supported. IPv6 via the IP CS is supported by the MS and the BS only when the IPv6 support bit in the capability negotiation messages (REG-REQ and REG-RSP) implying such support is indicated in the parameter "Classification/PHS options and SDU (Service Data Unit) encapsulation support" (refer to [802.16]). Additionally, during the establishment of the transport connection for transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition) and DSA-RSP messages between the BS and MS indicate via the CS-Specification TLV the CS that the connection being set up shall use. When the IPv6 packet is preceded by the IEEE 802.16 6-byte MAC header, there is no specific indication in the MAC header itself about the payload type. The processing of the packet is based entirely on the classifiers. Based on the classification rules, the MAC layer selects an appropriate transport connection for the transmission of the packet. An IPv6 packet is transported over a transport connection that is specifically established for carrying such packets.
範囲（802.16エアインターフェイス手順）とSBC-REQ/RSPメッセージの交換（802.16固有）の直後に、MSとBSはreg-Req（登録要求）とreg-RSP（登録応答）を介してその機能を交換することに注意する必要があります。）802.16 Macメッセージ。これらの管理フレームは、MSおよびBSでサポートされている収束サブレイヤーなどのパラメーターをネゴシエートします。デフォルトでは、パケット、IPv4、および802.3/イーサネットがサポートされています。IP CSを介したIPv6は、MSとBSによってサポートされています。IPv6が機能ネゴシエーションメッセージ（reg-reqとreg-RSP）のサポートビットがパラメーター「分類/phsオプションとSDU（サービス）に示されていることを意味します。データユニット）カプセル化サポート」（[802.16]を参照）。さらに、IPv6パケットを輸送するための輸送接続の確立中に、BSとMSの間のDSA-REQ（ダイナミックサービスの追加）とDSA-RSPメッセージは、CS仕様TLVを介して、セットアップされている接続が使用するCSを示しています。。IPv6パケットの前にIEEE 802.16 6バイトMacヘッダーが先行する場合、Macヘッダー自体にペイロードタイプに関する特定の兆候はありません。パケットの処理は、完全に分類器に基づいています。分類ルールに基づいて、MACレイヤーはパケットの送信に適した輸送接続を選択します。IPv6パケットは、そのようなパケットを運ぶために特別に確立された輸送接続を介して輸送されます。
Transmission of IPv6 as explained above is possible via multiple methods, i.e., via IP CS or via Ethernet interfaces. Every Internet host connected via an 802.16 link:
上記のIPv6の送信は、複数の方法、つまりIP CSまたはイーサネットインターフェイスを介して可能です。802.16リンクを介して接続されたすべてのインターネットホスト：
1. MUST be able to send and receive IPv6 packets via IP CS when the MS and BS indicate IPv6 protocol support over IP CS
1. MSとBSがIP CSよりもIPv6プロトコルサポートを示している場合、IP CSを介してIPv6パケットを送信および受信できる必要があります
2. MUST be able to send and receive IPv6 packets over the Ethernet (802.3)-specific part of the Packet CS when the MS and BS indicate IPv6 protocol support over Ethernet CS. However, when the MS and BS indicate IPv6 protocol support over both IP CS and Ethernet CS, the MS and BS MUST use IP CS for sending and receiving IPv6 packets.
2. MSとBSがイーサネットCSよりもIPv6プロトコルサポートを示す場合、パケットCSのイーサネット（802.3）固有の部分を介してIPv6パケットを送信および受信できる必要があります。ただし、MSとBSがIP CSとイーサネットCSの両方でIPv6プロトコルサポートを示している場合、MSとBSはIP CSを使用してIPv6パケットを送信および受信する必要があります。
When the MS and BS support IPv6 over IP CS, it MUST be used as the default mode for transporting IPv6 packets over IEEE 802.16 and the recommendations in this document that are followed. Inability to negotiate a common convergence sublayer for IPv6 transport between the MS and BS will result in failure to set up the transport connection and thereby render the host unable to send and receive IPv6 packets. In the case of a host that implements more than one method of transporting IPv6 packets, the default choice of which method to use (i.e., IPv6 over the IP CS or IPv6 over 802.3) is IPv6 over IP CS when the BS also supports such capability.
MSとBSがIP CSを介してIPv6をサポートする場合、IEEE 802.16を介してIPv6パケットを輸送するためのデフォルトモードとして、およびその後のこのドキュメントの推奨事項として使用する必要があります。MSとBSの間のIPv6輸送のための一般的な収束崇高な崇高な属性を交渉できないと、輸送接続のセットアップに失敗し、それによりホストがIPv6パケットを送信および受信できません。IPv6パケットを輸送する複数の方法を実装するホストの場合、使用する方法のデフォルトの選択（つまり、IP CSまたは802.3を超えるIPv6を超えるIPv6）は、BSがそのような機能をサポートする場合のIP CSよりもIPv6です。。
In any case, the MS and BS MUST negotiate at most one convergence sublayer for IPv6 transport on a given link.
いずれにせよ、MSとBSは、特定のリンク上のIPv6トランスポートのために、最大で1つの収束サブレイヤーを交渉する必要があります。
In addition, to ensure interoperability between devices that support different encapsulations, it is REQUIRED that BS implementations support all standards-track encapsulations defined for 802.16 by the IETF. At the time of writing this specification, this is the only encapsulation, but additional specifications are being worked on. It is, however, not required that the BS implementations use all the encapsulations they support; some modes of operation may be off by configuration.
さらに、さまざまなカプセルをサポートするデバイス間の相互運用性を確保するために、BS実装は、IETFによって802.16のために定義されたすべての標準トラックカプセルをサポートする必要があります。この仕様を書く時点では、これが唯一のカプセル化ですが、追加の仕様が機能しています。ただし、BS実装がサポートするすべてのカプセルを使用することは必須ではありません。一部の操作モードは、構成によってオフになる場合があります。
The IPv6 payload when carried over the IP-specific part of the Packet CS is encapsulated by the 6-byte IEEE 802.16 generic MAC header. The format of the IPv6 packet encapsulated by the generic MAC header is shown in the figure below. The format of the 6-byte MAC header is described in the [802.16] specification. The CRC (cyclic redundancy check) is optional. It should be noted that the actual MAC address is not included in the MAC header.
パケットCSのIP固有の部分を介した場合のIPv6ペイロードは、6バイトIEEE 802.16ジェネリックMacヘッダーによってカプセル化されます。ジェネリックMacヘッダーによってカプセル化されたIPv6パケットの形式を以下の図に示します。6バイトMacヘッダーの形式については、[802.16]仕様で説明します。CRC（環状冗長チェック）はオプションです。実際のMACアドレスはMacヘッダーに含まれていないことに注意する必要があります。
---------/ /-----------
| MAC SDU |
--------/ /------------
||
||
MSB \/ LSB
---------------------------------------------------------
| Generic MAC header| IPv6 Payload | CRC |
---------------------------------------------------------
Figure 3: IPv6 encapsulation
図3：IPv6カプセル化
For transmission of IPv6 packets via the IP CS over IEEE 802.16, the IPv6 layer interfaces with the 802.16 MAC directly. The IPv6 layer delivers the IPv6 packet to the Packet CS of the IEEE 802.16 MAC. The Packet CS defines a set of classifiers that are used to determine how to handle the packet. The IP classifiers that are used at the MAC operate on the fields of the IP header and the transport protocol, and these include the IP Traffic class, Next header field, Masked IP source and destination addresses, and Protocol source and destination port ranges. Next header in this case refers to the last header of the IP header chain. Parsing these classifiers, the MAC maps an upper-layer packet to a specific service flow and transport connection to be used. The MAC encapsulates the IPv6 packet in the 6-byte MAC header (MAC SDU) and transmits it. The figure below shows the operation on the downlink, i.e., the transmission from the BS to the host. The reverse is applicable for the uplink transmission.
IIEE 802.16を介したIP CSを介したIPv6パケットの送信の場合、IPv6レイヤーは802.16 Macを直接挿入します。IPv6レイヤーは、IEEE 802.16 MacのパケットCSにIPv6パケットを配信します。パケットCSは、パケットの処理方法を決定するために使用される分類子のセットを定義します。MACで使用されるIP分類器は、IPヘッダーとトランスポートプロトコルのフィールドで動作します。これらには、IPトラフィッククラス、次のヘッダーフィールド、マスクされたIPソースと宛先アドレス、プロトコルソースおよび宛先ポート範囲が含まれます。この場合の次のヘッダーは、IPヘッダーチェーンの最後のヘッダーを指します。これらの分類子を解析するMACは、使用する特定のサービスフローと輸送接続に上層層パケットをマッピングします。Macは、6バイトMacヘッダー（Mac SDU）のIPv6パケットをカプセル化し、送信します。以下の図は、ダウンリンクの操作、つまりBSからホストへのトランスミッションを示しています。逆はアップリンク送信に適用されます。
----------- ----------
| IPv6 Pkt| |IPv6 Pkt|
----------- ----------
| | /|\
| | |
--[SAP]--------------------- ---------[SAP]--------
||-| |----------| | | /|\ |
|| \ / 0---->[CID1] | | --- |-------- |
|| Downlink 0\/-->[CID2] | | |Reconstruct| |
|| classifiers0/\-->[....] | | | (undo PHS)| |
|| 0---->[CIDn] | | --- ------- |
||--------------| | | /|\ |
| | | | |
| {SDU, CID,..} | | {SDU, CID,..} |
| | | | /|\ |
| v | | | |
------[SAP]----------------- |-------[SAP]---------
| 802.16 MAC CPS |------>| 802.16 MAC CPS |
---------------------------- ----------------------
BS MS
Figure 4: IPv6 packet transmission: Downlink
図4：IPv6パケット送信：ダウンリンク
In a network that utilizes the 802.16 air interface, the host/MS is attached to an IPv6 access router (AR) in the network. The BS is a layer 2 entity only. The AR can be an integral part of the BS or the AR could be an entity beyond the BS within the access network. An AR may be attached to multiple BSs in a network. IPv6 packets between the MS and BS are carried over a point-to-point transport connection which is identified by a unique Connection Identifier (CID). The transport connection is a MAC layer link between the MS and the BS. The figures below describe the possible network architectures and are generic in nature. More esoteric architectures are possible but not considered in the scope of this document.
802.16エアインターフェイスを利用するネットワークでは、ホスト/MSがネットワーク内のIPv6アクセスルーター（AR）に接続されています。BSはレイヤー2エンティティのみです。ARはBSの不可欠な部分であるか、ARがアクセスネットワーク内のBSを超えたエンティティになる可能性があります。ARは、ネットワーク内の複数のBSSに接続される場合があります。MSとBSの間のIPv6パケットは、一意の接続識別子（CID）によって識別されるポイントツーポイントトランスポイント接続に掲載されます。トランスポート接続は、MSとBSの間のMACレイヤーリンクです。以下の図は、可能なネットワークアーキテクチャを説明しており、本質的に一般的です。より多くの難解なアーキテクチャが可能ですが、このドキュメントの範囲では考慮されていません。
Option A:
オプションA：
+-----+ CID1 +--------------+
| MS1 |------------/| BS/AR |-----[Internet]
+-----+ / +--------------+
. /---/
. CIDn
+-----+ /
| MSn |---/
+-----+
Figure 5: IPv6 AR as an integral part of the BS
図5：BSの不可欠な部分としてのIPv6AR
Option B:
オプションB：
+-----+ CID1 +-----+ +-----------+
| MS1 |----------/| BS1 |----------| AR |-----[Internet]
+-----+ / +-----+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
Figure 6: IPv6 AR is separate from the BS
図6：IPv6 ARはBSとは別です
The above network models serve as examples and are shown to illustrate the point-to-point link between the MS and the AR.
上記のネットワークモデルは例として機能し、MSとARの間のポイントツーポイントリンクを説明することが示されています。
"Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] defines link as a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. A link is bounded by routers that decrement the Hop limit field in the IPv6 header. When an MS moves within a link, it can keep using its IP addresses. This is a layer 3 definition, and note that the definition is not identical with the definition of the term '(L2) link' in IEEE 802 standards.
「IPバージョン6（IPv6）の近隣発見」[RFC4861]は、リンクを通信施設または中程度として定義します。通信施設は、ノードがリンクレイヤーで通信できる、つまりIPのすぐ下のレイヤーです。リンクは、IPv6ヘッダーのホップリミットフィールドを減少させるルーターに囲まれています。MSがリンク内で移動すると、IPアドレスを使用し続けることができます。これはレイヤー3の定義であり、IEEE 802標準の用語「（L2）リンク」の定義と定義は同一ではないことに注意してください。
In 802.16, the transport connection between an MS and a BS is used to transport user data, i.e., IPv6 packets in this case. A transport connection is represented by a CID, and multiple transport connections can exist between an MS and a BS.
802.16では、MSとBSの間の輸送接続を使用して、ユーザーデータ、つまりこの場合のIPv6パケットの輸送に使用されます。輸送接続はCIDで表され、MSとBSの間に複数の輸送接続が存在する可能性があります。
When an AR and a BS are colocated, the collection of transport connections to an MS is defined as a single 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 link.
ARとA BSがコロケーションされると、MSへの輸送接続のコレクションは単一のリンクとして定義されます。ARとBSを分離する場合、ARとBSの間にトンネルを確立することをお勧めします。サービスフローIDによって）。次に、MSの輸送接続と組み合わせて、MSのトンネルが単一のポイントツーポイントリンクを形成します。
The collection of service flows (tunnels) to an MS is defined as a single link. Each link that uses the same higher-layer protocol has only an MS and an AR. Each MS belongs to a different link. A different prefix should be assigned to each unique link. This link is fully consistent with a standard IP link, without exception, and conforms with the definition of a point-to-point link in neighbor discovery for IPv6 [RFC4861]. Hence, the point-to-point link model for IPv6 operation over the IP-specific part of the Packet CS in 802.16 SHOULD be used. A unique IPv6 prefix(es) per link (MS/host) MUST be assigned.
MSへのサービスフロー（トンネル）のコレクションは、単一のリンクとして定義されます。同じ高層プロトコルを使用する各リンクには、MSとARのみがあります。各MSは異なるリンクに属します。独自のリンクごとに別のプレフィックスを割り当てる必要があります。このリンクは、例外なく標準のIPリンクと完全に一致しており、IPv6 [RFC4861]の近隣発見におけるポイントツーポイントリンクの定義に準拠しています。したがって、802.16のパケットCSのIP固有の部分を介したIPv6操作のポイントツーポイントリンクモデルを使用する必要があります。リンクあたりの一意のIPv6プレフィックス（ES）（MS/ホスト）を割り当てる必要があります。
In order to enable the sending and receiving of IPv6 packets between the MS and the AR, the link between the MS and the AR via the BS needs to be established. This section illustrates the link establishment procedure.
MSとAR間のIPv6パケットの送信と受信を有効にするために、BSを介したMSとARの間のリンクを確立する必要があります。このセクションでは、リンクの確立手順を示します。
The MS goes through the network entry procedure as specified by 802.16. A high-level description of the network entry procedure is as follows:
MSは、802.16で指定されたネットワークエントリ手順を通過します。ネットワークエントリ手順の高レベルの説明は次のとおりです。
1. The MS performs initial ranging with the BS. Ranging is a process by which an MS becomes time aligned with the BS. The MS is synchronized with the BS at the successful completion of ranging and is ready to set up a connection.
1. MSは、BSで初期範囲を実行します。範囲は、MSがBSと整合する時間になるプロセスです。MSは、範囲が正常に完了するとBSと同期され、接続をセットアップする準備ができています。
2. The MS and BS exchange basic capabilities that are necessary for effective communication during the initialization using SBC-REQ/ RSP (802.16 specific) messages.
2. MSとBSは、SBC-REQ/ RSP（802.16固有）メッセージを使用した初期化中に効果的な通信に必要な基本機能を交換します。
3. The MS progresses to an authentication phase. Authentication is based on Privacy Key Management version 2 (PKMv2) as defined in the IEEE Std 802.16 specification.
3. MSは認証フェーズに進みます。認証は、IEEE STD 802.16仕様で定義されているプライバシーキー管理バージョン2（PKMV2）に基づいています。
4. On successful completion of authentication, the MS performs 802.16 registration with the network.
4. 認証が正常に完了すると、MSはネットワークで802.16登録を実行します。
5. The MS and BS perform capability exchange as per 802.16 procedures. Protocol support is indicated in this exchange. The CS capability parameter indicates which classification/PHS options and SDU encapsulation the MS supports. By default, Packet, IPv4, and 802.3/Ethernet shall be supported; thus, absence of this parameter in REG-REQ (802.16 message) means that named options are supported by the MS/SS. Support for IPv6 over the IP-specific part of the Packet CS is indicated by Bit #2 of the CS capability parameter (refer to [802.16]).
5. MSとBSは、802.16の手順に従って機能交換を実行します。この交換では、プロトコルサポートが示されています。CS機能パラメーターは、MSがサポートする分類/PHSオプションとSDUカプセル化を示します。デフォルトでは、パケット、IPv4、および802.3/イーサネットをサポートするものとします。したがって、reg-req（802.16メッセージ）にこのパラメーターがないことは、名前付きオプションがMS/SSによってサポートされることを意味します。パケットCSのIP固有の部分を介したIPv6のサポートは、CS機能パラメーターのビット＃2で示されています（[802.16]を参照）。
6. The MS MUST request the establishment of a service flow for IPv6 packets over IP CS if the MS and BS have confirmed capability for supporting IPv6 over IP CS. The service flow MAY also be triggered by the network as a result of pre-provisioning. The service flow establishes a link between the MS and the AR over which IPv6 packets can be sent and received.
6. MSとBSがIP CSよりもIPv6をサポートする機能を確認した場合、MSはIP CSを介したIPv6パケットのサービスフローの確立を要求する必要があります。また、サービスフローは、事前プロビジョニングの結果としてネットワークによってトリガーされる場合があります。サービスフローは、IPv6パケットを送信および受信できるMSとARの間にリンクを確立します。
7. The AR and MS SHOULD send router advertisements and solicitations as specified in neighbor discovery [RFC4861].
7. ARとMSは、近隣発見[RFC4861]で指定されているように、ルーターの広告と勧誘を送信する必要があります。
The above flow does not show the actual 802.16 messages that are used for ranging, capability exchange, or service flow establishment. Details of these are in [802.16].
上記のフローは、範囲、能力交換、またはサービスフローの確立に使用される実際の802.16メッセージを示していません。これらの詳細は[802.16]にあります。
The MTU value for IPv6 packets on an 802.16 link is configurable. The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500 octets.
802.16リンク上のIPv6パケットのMTU値は構成可能です。802.16リンク上のIPv6パケットのデフォルトのMTUは、1500オクテットでなければなりません。
The 802.16 MAC PDU is composed of a 6-byte header followed by an optional payload and an optional CRC covering the header and the payload. The length of the PDU is indicated by the Len parameter in the Generic MAC header. The Len parameter has a size of 11 bits. Hence, the total MAC PDU size is 2048 bytes. The IPv6 payload size can vary. In certain deployment scenarios, the MTU value can be greater than the default. Neighbor discovery for IPv6 [RFC4861] defines an MTU option that an AR MUST advertise, via router advertisement (RA), if a value different from 1500 is used. The MN processes this option as defined in [RFC4861]. Nodes that implement Path MTU Discovery [RFC1981] MAY use the mechanism to determine the MTU for the IPv6 packets.
802.16 Mac PDUは、6バイトのヘッダーで構成され、その後にオプションのペイロードと、ヘッダーとペイロードをカバーするオプションのCRCが続きます。PDUの長さは、一般的なMacヘッダーのLENパラメーターで示されます。LENパラメーターのサイズは11ビットです。したがって、合計MAC PDUサイズは2048バイトです。IPv6ペイロードサイズは異なる場合があります。特定の展開シナリオでは、MTU値はデフォルトよりも大きくなります。IPv6 [RFC4861]の近隣発見は、1500とは異なる値が使用されている場合、Router Advertisement（RA）を介してARが宣伝しなければならないMTUオプションを定義します。MNは、[RFC4861]で定義されているようにこのオプションを処理します。PATH MTUディスカバリー[RFC1981]を実装するノードは、メカニズムを使用してIPv6パケットのMTUを決定する場合があります。
The MS and the AR are connected via a point-to-point connection at the IPv6 layer. Hence, each MS can be considered to be on a separate subnet. A CPE (Customer Premise Equipment) type of device that serves multiple IPv6 hosts may be the end point of the connection. Hence, one or more /64 prefixes SHOULD be assigned to a link. The prefixes are advertised with the on-link (L-bit) flag set as specified in [RFC4861]. The size and number of the prefixes are a configuration issue. Also, Dynamic Host Configuration Protocol (DHCP) or Authentication, Authorization, and Accounting (AAA)-based prefix delegation MAY be used to provide one or more prefixes to MS for an AR connected over 802.16. The other properties of the prefixes are also dealt with via configuration.
MSとARは、IPv6レイヤーのポイントツーポイント接続を介して接続されています。したがって、各MSは別のサブネット上にあると見なすことができます。複数のIPv6ホストにサービスを提供するCPE（顧客前提機器）タイプのデバイスは、接続のエンドポイントである場合があります。したがって、1つ以上の /64プレフィックスをリンクに割り当てる必要があります。接頭辞は、[RFC4861]で指定されているように、オンリンク（L-BIT）フラグセットで宣伝されています。プレフィックスのサイズと数は構成の問題です。また、ダイナミックホスト構成プロトコル（DHCP）または認証、承認、および会計（AAA）ベースのプレフィックス委任を使用して、802.16を超えるARに1つ以上のプレフィックスをMSに提供することができます。プレフィックスの他のプロパティも、構成を介して扱われます。
On completion of the establishment of the IPv6 link, the MS may send a router solicitation message to solicit a router advertisement message from the AR to acquire necessary information as per the neighbor discovery for IPv6 specification [RFC4861]. An MS that is network attached may also send router solicitations at any time. Movement detection at the IP layer of an MS in many cases is based on receiving periodic router advertisements. An MS may also detect changes in its attachment via link triggers or other means. The MS can act on such triggers by sending router solicitations. The router solicitation is sent over the IPv6 link that has been previously established. The MS sends router solicitations to the all-routers multicast address. It is carried over the point-to-point link to the AR via the BS. The MS does not need to be aware of the link-local address of the AR in order to send a router solicitation at any time. The use of router advertisements as a means for movement detection is not recommended for MNs connected via 802.16 links as the frequency of periodic router advertisements would have to be high.
IPv6リンクの確立が完了すると、MSはRouter Solicitationメッセージを送信して、IPv6仕様[RFC4861]の近隣発見に従って、必要な情報を取得するためにARからのルーター広告メッセージを求めます。ネットワークが添付されているMSは、いつでもルーターの勧誘を送信する場合があります。多くの場合、MSのIPレイヤーでの移動検出は、定期的なルーター広告の受信に基づいています。また、MSは、リンクトリガーまたはその他の手段を介して、付着の変更を検出する場合があります。MSは、ルーターの勧誘を送信することにより、そのようなトリガーに作用できます。ルーターの勧誘は、以前に確立されたIPv6リンクを介して送信されます。MSは、ルーターの勧誘をすべてのルーターマルチキャストアドレスに送信します。BSを介してARへのポイントツーポイントリンクを越えて運ばれます。MSは、いつでもルーターの勧誘を送信するために、ARのリンクローカルアドレスに注意する必要はありません。周期的なルーター広告の頻度が高いため、802.16リンクを介して接続されたMNSには、移動検出の手段としてルーター広告を使用することは推奨されません。
The AR SHOULD send a number (configurable value) of router advertisements to the MS as soon as the IPv6 link is established. The AR sends unsolicited router advertisements periodically as per [RFC4861]. The interval between periodic router advertisements is however greater than the specification in neighbor discovery for IPv6, and is discussed in the following section.
ARは、IPv6リンクが確立されるとすぐに、ルーター広告の数（構成可能な値）をMSに送信する必要があります。ARは、[RFC4861]に従って定期的に未承諾ルーター広告を送信します。ただし、定期的なルーター広告間の間隔は、IPv6の近隣発見の仕様よりも大きく、次のセクションで説明します。
The router lifetime SHOULD be set to a large value, preferably in hours. This document overrides the specification for the value of the router lifetime in "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval.
ルーターの寿命は、できれば数時間で大きな値に設定する必要があります。このドキュメントは、「IPバージョン6（IPv6）の近隣発見」[RFC4861]のルーター寿命の値の仕様をオーバーライドします。ルーター広告のadvdefaultlifetimeは、ゼロまたはmaxrtradvintervalと43200秒のいずれかでなければなりません。デフォルト値は2 * maxrtradvintervalです。
802.16 hosts have the capability to transition to an idle mode, in which case, the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile that is in idle mode and consuming resources on the air interface, the interval between periodic router advertisements SHOULD be set quite high. The MaxRtrAdvInterval value specified in this document overrides the recommendation in "Neighbor Discovery for IP Version 6 (IPv6)"[RFC4861]. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds.
802.16ホストには、アイドルモードに移行する機能があります。その場合、BSとMSの間の無線リンクが取り壊されます。ネットワークがMSにパケットを配信する必要がある場合に備えて、ページングが必要です。アイドルモードのモバイルを目覚めさせ、AIRインターフェイスでリソースを消費することを避けるために、周期的なルーター広告間の間隔を非常に高く設定する必要があります。このドキュメントで指定されているMaxrtradvinterval値は、「IPバージョン6（IPv6）の近隣発見」[RFC4861]の推奨事項をオーバーライドします。maxrtradvintervalは4秒以上、21600秒以下でなければなりません。maxrtradvintervalのデフォルト値は10800秒です。
The addressing scheme for IPv6 hosts in 802.16 networks follows the IETF's recommendation for hosts specified in "IPv6 Node Requirements" [RFC4294]. The IPv6 node requirements [RFC4294] specify a set of RFCs that are applicable for addressing, and the same is applicable for hosts that use 802.16 as the link layer for transporting IPv6 packets.
802.16ネットワークのIPv6ホストのアドレス指定スキームは、「IPv6ノード要件」で指定されたホストに対するIETFの推奨に従います[RFC4294]。IPv6ノード要件[RFC4294]は、アドレス指定に適用可能なRFCのセットを指定し、IPv6パケットを輸送するためのリンクレイヤーとして802.16を使用するホストに同じことが適用されます。
The MS has a 48-bit globally unique MAC address as specified in 802.16 [802.16]. This MAC address MUST be used to generate the modified EUI-64 format-based interface identifier as specified in "IP Version 6 Addressing Architecture" [RFC4291]. The modified EUI-64 interface identifier is used in stateless address autoconfiguration. As in other links that support IPv6, EUI-64-based interface identifiers are not mandatory and other mechanisms, such as random interface identifiers, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], MAY also be used.
MSには、802.16 [802.16]で指定されているように、48ビットのグローバルに一意のMACアドレスがあります。このMACアドレスは、「IPバージョン6アドレス指定アーキテクチャ」[RFC4291]で指定されているように、変更されたEUI-64形式ベースのインターフェイス識別子を生成するために使用する必要があります。修正されたEUI-64インターフェイス識別子は、ステートレスアドレスの自動構成で使用されます。IPv6をサポートする他のリンクと同様に、EUI-64ベースのインターフェイス識別子は必須ではなく、ランダムインターフェイス識別子、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」[RFC4941]などの他のメカニズムも使用できます。
DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6 (IPv6)", [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862]. The IPv6 link over 802.16 is specified in this document as a point-to-point link. Based on this criteria, it may be redundant to perform DAD on a global unicast address that is configured using the EUI-64 or generated as per RFC 4941 [RFC4941] for the interface as part of the IPv6 Stateless Address Autoconfiguration Protocol [RFC4862] as long as the following two conditions are met:
お父さんは、「IPバージョン6（IPv6）の近隣発見」、[RFC4861]、および「IPv6 Stateless Address Autoconfiguration」[RFC4862]に従って実行する必要があります。802.16を超えるIPv6リンクは、このドキュメントでポイントツーポイントリンクとして指定されています。この基準に基づいて、IPv6ステートレスアドレスオートコンチュレーションプロトコル[RFC4862]として、IPv6 Stateless Autoconfiguration Protocol [RFC4862]の一部として、EUI-64を使用して構成するか、RFC 4941 [RFC4941]に従って生成されたグローバルユニキャストアドレスでDADを実行することが冗長である場合があります。次の2つの条件が満たされている限り：
1. The prefixes advertised through the router advertisement messages by the access router terminating the 802.16 IPv6 link are unique to that link.
1. 802.16 IPv6リンクを終了するアクセスルーターによってルーター広告メッセージを介して宣伝されている接頭辞は、そのリンクに固有のものです。
2. The access router terminating the 802.16 IPv6 link does not autoconfigure any IPv6 global unicast addresses from the prefix that it advertises.
2. 802.16 IPv6リンクを終了するアクセスルーターは、宣伝するプレフィックスのIPv6グローバルユニキャストアドレスを自動構成しません。
When stateless address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC4862].
StatelessアドレスAutoconfigurationが実行される場合、[RFC4861]および[RFC4862]で指定されているように実行する必要があります。
When stateful address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC3315].
ステートフルアドレスAutoconfigurationが実行される場合、[RFC4861]および[RFC3315]で指定されているように実行する必要があります。
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] SHOULD be supported as specified by the hosts and routers attached to each other via an 802.16 link. The access router that has hosts attached to it via a point-to-point link over an 802.16 SHOULD NOT send periodic queries if the host is in idle/dormant mode. The AR can obtain information about the state of a host from the paging controller in the network.
「IPv6用のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」[RFC3810]は、802.16リンクを介して互いに接続されているホストとルーターによって指定されているようにサポートする必要があります。802.16を超えるポイントツーポイントリンクを介してホストが接続されているアクセスルーターは、ホストがアイドル/休止モードにある場合、定期的なクエリを送信してはなりません。ARは、ネットワーク内のページングコントローラーからホストの状態に関する情報を取得できます。
This document does not introduce any new vulnerabilities to IPv6 specifications or operation. The security of the 802.16 air interface is the subject of [802.16]. It should be noted that 802.16 provides capability to cipher the traffic carried over the transport connections. A traffic encryption key (TEK) is generated by the MS and BS on completion of successful authentication and is used to secure the traffic over the air interface. An MS may still use IPv6 security mechanisms even in the presence of security over the 802.16 link. In addition, the security issues of the network architecture spanning beyond the 802.16 base stations are the subject of the documents defining such architectures, such as WiMAX Network Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2, Part 2.
このドキュメントでは、IPv6の仕様や操作に新しい脆弱性を導入しません。802.16エアインターフェイスのセキュリティは[802.16]の主題です。802.16は、輸送接続の上に運ばれるトラフィックを暗号化する機能を提供することに注意する必要があります。トラフィック暗号化キー（TEK）は、成功した認証の完了時にMSおよびBSによって生成され、エアインターフェイス上のトラフィックを保護するために使用されます。MSは、802.16リンクを介してセキュリティが存在する場合でも、IPv6セキュリティメカニズムを使用する場合があります。さらに、802.16のベースステーションを超えたネットワークアーキテクチャのセキュリティ問題は、ステージ2のセクション7.2および7.3のWimaxネットワークアーキテクチャ[Wimaxarch]など、そのようなアーキテクチャを定義するドキュメントの対象です。
The authors would like to acknowledge the contributions of the 16NG working group chairs Soohong Daniel Park and Gabriel Montenegro as well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret Wasserman, and Pekka Savola for their review and comments. Review and comments by Phil Barber have also helped in improving the document quality.
著者は、16ngのワーキンググループチェア、ソーホンダニエルパークとガブリエルモンテネグロの貢献と、ジャリアークコ、ジョンヌソイニネン、マックスリーゲル、プラカシュイアー、DJジョンストン、デイブサラー、ブルーノソーサそして、彼らのレビューとコメントについてペッカ・サヴォラ。Phil Barberによるレビューとコメントも、ドキュメントの品質の向上に役立ちました。
[802.16] "IEEE Std 802.16e: IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", October 2005, <http://standards.ieee.org/ getieee802/download/802.16e-2005.pdf>.
[802.16] "IEEE STD 802.16E：ローカルおよびメトロポリタンエリアネットワークのIEEE標準、ライセンスバンドでの固定およびモバイル操作の物理的および中程度のアクセス制御レイヤーの修正、2005年10月、<http://standards.ieeee.org/getieee802/download/802.16e-2005.pdf>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[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月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[802.3] "IEEE Std 802.3-2005: IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks--Specific requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", December 2005, <http://standards.ieee.org/getieee802/ 802.3.html>.
[802.3] "IEEE STD 802.3-2005：IEEE標準情報技術の標準システムとメトロポリタンエリアネットワーク間の情報技術と情報交換パート3：衝突検出による複数アクセス（CSMA/CD）アクセス法とキャリアセンス物理層の仕様 "、2005年12月、<http://standards.ieee.org/getieee802/ 802.3.html>。
[IPoE-over-802.16] Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP over Ethernet over IEEE 802.16 Networks", Work in Progress, January 2008.
[Ipoe-over-802.16] Jeon、H.、Riegel、M。、およびS. Jeong、「IEEE 802.16ネットワークを介したイーサネット上のIPの送信」、2008年1月の作業。
[IPv4-over-IPCS] Madanapalli, S., Park, S., and S. Chakrabarti, "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", Work in Progress, November 2007.
[IPv4-Over-IPCS] Madanapalli、S.、Park、S。、およびS. Chakrabarti、「IEEE 802.16のIP Convergence Sublayerを介したIPv4パケットの送信」、2007年11月の作業。
[PS-GOALS] Jee, J., Madanapalli, S., and J. Mandin, "IP over 802.16 Problem Statement and Goals", Work in Progress, December 2007.
[PS-Goals] Jee、J.、Madanapalli、S。、およびJ. Mandin、「802.16を超える問題声明と目標を超えるIP」、2007年12月、進行中の作業。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6ノード要件」、RFC 4294、2006年4月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[WMF] "WiMAX Forum", <http://www.wimaxforum.org>.
[WMF]「Wimax Forum」、<http://www.wimaxforum.org>。
[WiMAXArch] "WiMAX End-to-End Network Systems Architecture", September 2007.
[Wimaxarch]「Wimaxのエンドツーエンドネットワークシステムアーキテクチャ」、2007年9月。
The WiMAX (Worldwide Interoperability for Microwave Access) forum [WMF] has defined a network architecture in which the air interface is based on the IEEE 802.16 standard. The addressing and operation of IPv6 described in this document are applicable to the WiMAX network as well.
WIMAX（マイクロ波アクセスの世界的な相互運用性）フォーラム[WMF]は、AIRインターフェイスがIEEE 802.16標準に基づいているネットワークアーキテクチャを定義しました。このドキュメントで説明されているIPv6のアドレス指定と動作は、WiMaxネットワークにも適用できます。
WiMAX is an example architecture of a network that uses the 802.16 specification for the air interface. WiMAX networks are also in the process of being deployed in various parts of the world, and the operation of IPv6 within a WiMAX network is explained in this appendix.
Wimaxは、エアインターフェイスの802.16仕様を使用するネットワークのアーキテクチャの例です。WIMAXネットワークは、世界のさまざまな地域に展開されている過程にあり、WIMAXネットワーク内でのIPv6の動作についてこの付録で説明しています。
The WiMAX network architecture consists of the Access Service Network (ASN) and the Connectivity Service Network (CSN). The ASN is the access network that includes the BS and the AR in addition to other functions such as AAA, mobile IP foreign agent, paging controller, location register, etc. The ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX subscriber. The ASN is the access network to which the MS attaches. The IPv6 access router is an entity within the ASN. The term ASN is specific to the WiMAX network architecture. The CSN is the entity that provides connectivity to the Internet and includes functions such as mobile IP home agent and AAA. The figure below shows the WiMAX reference model:
WIMAXネットワークアーキテクチャは、Access Service Network（ASN）とConnectivity Service Network（CSN）で構成されています。ASNは、AAA、モバイルIP外国人エージェント、ページングコントローラー、ロケーションレジスタなど、他の機能に加えてBSとARを含むアクセスネットワークです。ASNは、ラジオを提供するために必要な完全なネットワーク関数のセットとして定義されます。WIMAXサブスクライバーへのアクセス。ASNは、MSが付着するアクセスネットワークです。IPv6アクセスルーターは、ASN内のエンティティです。ASNという用語は、WIMAXネットワークアーキテクチャに固有です。CSNは、インターネットへの接続を提供し、モバイルIPホームエージェントやAAAなどの機能を含むエンティティです。以下の図は、WIMAXリファレンスモデルを示しています。
-------------------
| ---- ASN | |----|
---- | |BS|\ R6 -------| |---------| | CSN|
|MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | |
---- | |R8 /--|------|----| |-----|Home|
| ---- / | | visited| | NSP|
| |BS|/ | | NSP | | |
| ---- | |---------| | |
| NAP | \ |----|
------------------- \---| /
| | /
| (--|------/----)
|R4 ( )
| ( ASP network )
--------- ( or Internet )
| ASN | ( )
--------- (----------)
Figure 7: WiMAX network reference model
図7：WIMAXネットワークリファレンスモデル
Three different types of ASN realizations called profiles are defined by the architecture. ASNs of profile types A and C include BS' and ASN-gateway(s) (ASN-GW), which are connected to each other via an R6 interface. An ASN of profile type B is one in which the functionality of the BS and other ASN functions are merged together. No ASN-GW is specifically defined in a profile B ASN. The absence of the R6 interface is also a profile B specific characteristic. The MS at the IPv6 layer is associated with the AR in the ASN. The AR may be a function of the ASN-GW in the case of profiles A and C and is a function in the ASN in the case of profile B. When the BS and the AR are separate entities and linked via the R6 interface, IPv6 packets between the BS and the AR are carried over a Generic Routing Encapsulation (GRE) tunnel. The granularity of the GRE tunnel should be on a per-MS basis or on a per-service-flow basis (an MS can have multiple service flows, each of which is identified uniquely by a service flow ID). The protocol stack in WiMAX for IPv6 is shown below:
プロファイルと呼ばれる3つの異なるタイプのASN実現は、アーキテクチャによって定義されます。プロファイルタイプAおよびCのASNには、R6インターフェイスを介して互いに接続されているBSおよびASN-Gateway（S）（ASN-GW）が含まれます。プロファイルタイプBのASNは、BSおよびその他のASN関数の機能がマージされるものです。ASN-GWはプロファイルB ASNで特異的に定義されていません。R6インターフェイスの欠如は、プロファイルB固有の特性でもあります。IPv6層のMSは、ASNのARに関連付けられています。ARは、プロファイルAおよびCの場合のASN-GWの関数であり、プロファイルBの場合のASNの関数です。BSとARが別々のエンティティであり、R6インターフェイスを介してリンクされている場合、IPv6BSとARの間のパケットは、一般的なルーティングカプセル化（GRE）トンネルの上に運ばれます。GREトンネルの粒度は、MSごとに、またはサービスごとのフローベースである必要があります（MSには複数のサービスフローがあり、それぞれがサービスフローIDによって一意に識別されます）。IPv6のWIMAXのプロトコルスタックを以下に示します。
|-------|
| App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| |
|-------| /------ -------
| | / IPv6 | | |
| IPv6 |- - - - - - - - - - - - - - - - / | | |-->
| | --------------- -------/ | | IPv6|
|-------| | \Relay/ | | | |- - - | |
| | | \ / | | GRE | | | |
| | | \ /GRE | - | | | | |
| |- - - | |-----| |------| | | |
| IPv6CS| |IPv6CS | IP | - | IP | | | |
| ..... | |...... |-----| |------|--------| |-----|
| MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 |
|-------| |------ |-----| |----- |--------| |-----|
| PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 |
-------- --------------- ----------------- -------
MS BS AR/ASN-GW CSN Rtr
Figure 8: WiMAX protocol stack
図8：WIMAXプロトコルスタック
As can be seen from the protocol stack description, the IPv6 end-points are constituted in the MS and the AR. The BS provides lower-layer connectivity for the IPv6 link.
プロトコルスタックの説明からわかるように、IPv6エンドポイントはMSおよびARで構成されています。BSは、IPv6リンクに低層接続を提供します。
WiMAX is an example of a network based on the IEEE Std 802.16 air interface. This section describes the IPv6 link in the context of a WiMAX network. The MS and the AR are connected via a combination of:
WIMAXは、IEEE STD 802.16エアインターフェイスに基づくネットワークの例です。このセクションでは、WIMAXネットワークのコンテキストでのIPv6リンクについて説明します。MSとARは、次の組み合わせで接続されています。
1. The transport connection that is identified by a Connection Identifier (CID) over the air interface, i.e., the MS and BS, and
1. エアインターフェイス上の接続識別子（CID）によって識別される輸送接続、つまりMSおよびBS、および
2. A GRE tunnel between the BS and AR that transports the IPv6 packets
2. IPv6パケットを輸送するBSとARの間のGREトンネル
From an IPv6 perspective, the MS and the AR are connected by a point-to-point link. The combination of transport connection over the air interface and the GRE tunnel between the BS and AR creates a (point-to-point) tunnel at the layer below IPv6.
IPv6の観点からは、MSとARはポイントツーポイントリンクによって接続されています。AIRインターフェイスとBSとARの間のGREトンネル上の輸送接続の組み合わせにより、IPv6の下の層に（ポイントツーポイント）トンネルが作成されます。
The collection of service flows (tunnels) to an MS is defined as a single link. Each link has only an MS and an AR. Each MS belongs to a different link. No two MSs belong to the same link. A different prefix should be assigned to each unique link. This link is fully consistent with a standard IP link, without exception, and conforms with the definition of a point-to-point link in [RFC4861].
MSへのサービスフロー（トンネル）のコレクションは、単一のリンクとして定義されます。各リンクにはMSとARのみがあります。各MSは異なるリンクに属します。同じリンクに属する2つのMSSはありません。独自のリンクごとに別のプレフィックスを割り当てる必要があります。このリンクは、例外なく標準のIPリンクと完全に一致しており、[RFC4861]のポイントツーポイントリンクの定義に準拠しています。
The mobile station performs initial network entry as specified in 802.16. On successful completion of the network entry procedure, the ASN gateway/AR triggers the establishment of the initial service flow (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the ASN-GW/AR and the BS. The BS in turn requests the MS to establish a transport connection over the air interface. The end result is a transport connection over the air interface for carrying IPv6 packets and a GRE tunnel between the BS and AR for relaying the IPv6 packets. On successful completion of the establishment of the ISF, IPv6 packets can be sent and received between the MS and AR. The ISF enables the MS to communicate with the AR for host configuration procedures. After the establishment of the ISF, the AR can send a router advertisement to the MS. An MS can establish multiple service flows with different quality of service (QoS) characteristics. The ISF can be considered as the primary service flow. The ASN-GW/AR treats each ISF, along with the other service flows to the same MS, as a unique link that is managed as a (virtual) interface.
The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. Hence, the IPv6 path MTU can be 1500 octets. However, because of the overhead of the GRE tunnel used to transport IPv6 packets between the BS and AR and the 6-byte MAC header over the air interface, using a value of 1500 would result in fragmentation of packets. It is recommended that the MTU for IPv6 be set to 1400 octets in WiMAX networks, and this value (different from the default) be communicated to the MS. Note that the 1522-octet specification is a WiMAX forum specification and not the size of the SDU that can be transmitted over 802.16, which has a higher limit.
Wimaxフォーラム[WMF]は、最大SDUサイズを1522オクテットとして指定しています。したがって、IPv6 Path MTUは1500オクテットになります。ただし、BSとARと6バイトMACヘッダーの間でIPv6パケットをエアインターフェイス上に輸送するために使用されるGREトンネルのオーバーヘッドのため、1500の値を使用すると、パケットが断片化されます。IPv6のMTUをWimaxネットワークで1400オクテットに設定することをお勧めし、この値（デフォルトとは異なる）をMSに通知することをお勧めします。1522-OCTET仕様は、802.16を超えるSDUのサイズではなく、Wimaxフォーラム仕様であり、上限が高いことに注意してください。
Authors' Addresses
著者のアドレス
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nsn.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
フランク・シア・ホーウェイUSA 1700 ALMA DR. SUITE 500 PLANO、TX 75075 USA
EMail: xiayangsong@huawei.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano、TX 75075 USA
EMail: sarikaya@ieee.org
JinHyeock Choi Samsung AIT Networking Technology Lab P.O.Box 111 Suwon, Korea 440-600
Jinhyeock Choi Samsung Ait Networking Technology Lab P.O.Box 111 Suwon、Korea 440-600
EMail: jinchoe@samsung.com
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL. Off Airport Road Bangalore, India 560066
SYAM MADANAPALLI ORDYN TECHNOLOGIES 1st Floor、Creator Building、ITPL。オフエアポートロードバンガロール、インド560066
EMail: smadanapalli@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。