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
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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規格802.16は、固定およびモバイルブロードバンドワイヤレスアクセスシステムのためのエアインターフェース仕様です。上位層プロトコルインタフェースサービス特有収束サブレイヤは、IEEE 802.16 MAC（媒体アクセス制御）の一部です。パケットコンバージェンスサブレイヤ（CS）は、インターネット・プロトコル（IP）およびIEEE 802.3 LAN / MAN CSMA / CDアクセス方式（イーサネット）など、すべてのパケットベースのプロトコルを搬送するために使用されます。 IPv6パケットは、パケットCSのIP固有部分を介して送受信することができます。このドキュメントでは、IEEE規格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で指定されているが、エアインタフェースを介してIPv4とIPv6の動作の詳細については含まれていません。このドキュメントでは、IEEE 802.16無線インタフェースでのIPv6の動作を指定します。
IPv6 packets can be carried over the IEEE Std 802.16 specified air interface via:
IPv6パケットは、IEEE規格802.16指定エアインタフェースを介して上に実施することができます。
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標準802.16エアインタフェースを介して接続されています。 MSからIPv6リンクは、BSを超えてBSまたはエンティティの一部であってもよいアクセスルータで終端します。基地局は、（MSとアクセスルータ（AR）との間のIPv6リンクの観点から）レイヤ2エンティティであり、エアインタフェースを介してポイントツーポイント接続を介して、ARとホストとの間のIPv6パケットを中継します。
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [PS-GOALS].
この文書に記載されている用語は[PS-GOALS]「802.16問題文と目標を超えるIP」の定義に基づいています。
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つのサービス固有の収束サブレイヤを指定します。
The Packet CS is used for the transport of packet-based protocols, which include:
パケットCSを含むパケットベースのプロトコルを搬送するために使用されます。
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:
図1に示すように、サービス固有のCSは、サービス固有のCSが担当するMAC共通部分副層（CPS）の上に常駐します：
o accepting packets (Protocol Data Units, PDUs) from the upper layer,
上位レイヤからのパケット（プロトコルデータユニット、PDU）を受け入れ、O、
o performing classification of the packet/PDU based on a set of defined classifiers that are service specific,
サービス特定され定義された分類器のセットに基づいてパケット/ PDUの分類を実行O、
o delivering the CS PDU to the appropriate service flow and transport connection, and
適切なサービスフローとトランスポート接続にCS PDUを配信、およびo
o receiving PDUs from the peer entity.
ピアエンティティからのPDUを受信し、O。
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のそれぞれについて分類は、上位レイヤからのパケットは、パケットCSの適切なサービス固有の部分で処理されることを可能にするIEEE 802.16仕様で定義されています。 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
（2）IPv6の上（1）IPv6のIP固有部分802.3 /イーサネットのパケットCSのパケットCS特定部分上
Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CS
図2：パケットCSのIPv6のIPベース上及び802.3固有部品
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でオーバー802.16]で指定されています。 IP CS上のIPv4の送信は、[IPv4のオーバー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のようなサポートを暗示能力ネゴシエーションメッセージ（REG-REQ及びREG-RSP）でIPv6をサポートビットがパラメータ「分類/ PHSオプションとSDU（サービスに示されている場合にのみ、MS及びBSによってサポートされていますデータユニット）カプセル化のサポート」（[802.16]を参照してください）。また、IPv6パケットを輸送するためのトランスポートコネクションの確立、DSA-REQ（動的サービス追加）およびDSA-RSP中にBSとMSとの間のメッセージは、設定された接続を使用しなければならないことを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
MSとBSは、IP CS上のIPv6プロトコルのサポートを示す場合1. 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、MS及びBSのIPv6パケットを送信及び受信するための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パケットを送受信することができないホストをレンダリングする失敗をもたらすであろう。 BSはまた、このような機能をサポートしているとき、IPv6パケットを輸送する複数のメソッドを実装しているホストの場合、デフォルトの選択は、どの方法（すなわち、802.3オーバーIP CSまたはIPv6を介したIPv6）は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,
IEEE 802.16、直接802.16 MACとのIPv6層インターフェイス上にIP CSを介してIPv6パケットの送信のために。 IPv6の層は、IEEE 802.16 MACのパケットCSにIPv6パケットを提供します。パケットCSは、パケットを処理する方法を決定するために使用される分類器のセットを定義します。 MACで使用されるIP分類は、IPヘッダとトランスポートプロトコルのフィールドで動作し、これらは、IPトラフィッククラス、次ヘッダフィールドを含みます
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.
仮面の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は、ネットワーク内の複数のBSに取り付けることができます。 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：IPv6のAR BSの一体部分として
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とBSが同じ場所に配置されている場合、MSへの転送接続の収集は、単一のリンクとして定義されます。 ARとBSが分離されている場合には、トンネルがARとその粒度「MS当たり」または「サービス・フローごと」（MSが識別された複数のサービスフローを有することができ、より大きくないBSとの間で確立されることが推奨されます）サービスフローIDによる。次いで、MSのためのトンネル（S）は、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動作のためのポイントツーポイントリンクモデルを用いるべきです。リンク（MS /ホスト）ごとに一意のIPv6プレフィックス（ES）を割り当てなければなりません。
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:
802.16で指定されたMSは、ネットワークエントリ手順を通過します。次のようにネットワークエントリ手順の高レベルの記述です。
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規格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は、CS能力パラメータのビット＃2（[802.16]参照）で示されているのIP固有部分上IPv6のサポート。
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.
MSとBSは、IP CS上でIPv6をサポートするための機能を確認している場合6. MSはIP CSを超えるIPv6パケットのためのサービスフローの確立を要求しなければなりません。サービスフローはまた、事前プロビジョニングの結果としてネットワークによってトリガされてもよいです。サービスフローは、IPv6パケットを送受信することができる上にMSとARとの間のリンクを確立します。
7. The AR and MS SHOULD send router advertisements and solicitations as specified in neighbor discovery [RFC4861].
近隣探索[RFC4861]で指定されるように7 ARとMSは、ルータ広告や勧誘を送信すべきです。
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は、ヘッダとペイロードを覆う任意ペイロードおよび任意のCRCに続く6バイトのヘッダで構成されています。 PDUの長さは、一般的なMACヘッダ内レンパラメータによって示されます。 lenパラメータは、11ビットのサイズを有します。したがって、総MAC PDUのサイズは2048バイトです。 IPv6のペイロードサイズは変えることができます。特定の展開シナリオでは、MTU値をデフォルトよりも大きくすることができます。 1500は異なる値が使用される場合、IPv6の近隣探索[RFC4861]は、ルータ広告（RA）を介して、ARが宣伝しなければならないことがMTUオプションを規定します。 [RFC4861]で定義されているMNは、このオプションを処理します。パス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（顧客宅内機器）のタイプは、接続のエンドポイントであってもよいです。したがって、一つ以上の/ 64プレフィックスがリンクに割り当てられるべきです。プレフィックスは[RFC4861]で指定されるように設定上のリンク（Lビット）フラグでアドバタイズされます。接頭辞の大きさと数は構成の問題です。また、動的ホスト構成プロトコル（DHCP）または認証、許可、およびアカウンティング（AAA）ベースのプレフィックス委譲は802.16を介して接続されたARのためのMSへの1つの以上のプレフィックスを提供するために使用され得ます。プレフィックスの他の特性は、構成を介して対処されます。
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は、IPv6仕様[RFC4861]のために近隣探索ごとに必要な情報を取得するためにARからのルータ広告メッセージを要請するルータ要請メッセージを送信することができます。ネットワークが接続されているMSはまた、任意の時点でルーター要請を送信することができます。多くの場合、MSのIP層での動き検出は、周期的なルータ広告を受信に基づいています。 MSは、リンクのトリガーまたは他の手段を介して、その添付ファイルの変更を検出してもよいです。 MSはルーター要請を送信することにより、このようなトリガに基づいて行動することができます。ルーター要請は、以前に確立されたIPv6リンクを介して送信されます。 MSは、全ルーターマルチキャストアドレスにルーター要請を送信します。これは、BSを介したARへのポイントツーポイントリンク上で行われます。 MSは、いつでもルータ要求を送信するために、ARのリンクローカルアドレスを意識する必要はありません。定期的なルータ通知の頻度として802.16リンクを介して接続されているのMNが高くなければならないであろうため、動き検出手段としてのルータ広告の使用は推奨されません。
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にパケットを配信する必要がある場合に必要とされます。アイドルモードにある移動をウェイクし、エアインタフェース上のリソースを消費しないようにするためには、定期的なルータアドバタイズメントの間隔が非常に高く設定しなければなりません。この文書で指定MaxRtrAdvInterval値は[RFC4861「IPバージョン6（IPv6）のための近隣探索」の推奨を上書き。 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のノードの要件」[RFC4294]で指定したホストのためのIETFの勧告に従っています。 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におけるステートレスアドレス自動構成のためのプライバシー拡張」[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:
DADは、[RFC4861]との "IPv6ステートレスアドレス自動設定" [RFC4862 "IPバージョン6（IPv6）のための近隣探索" に従って行われるべきです。 802.16の上にIPv6リンクは、ポイントツーポイントリンクとして、この文書で指定されています。この基準に基づいて、EUI-64を使用して設定またはRFC 4941に従って生成されたグローバルユニキャストアドレスでDADを実行するために冗長であってもよいのIPv6ステートレスアドレス自動設定プロトコルの一部としてインタフェースのための[RFC4941]、[RFC4862]として次の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].
ステートレスアドレス自動設定を行う場合、[RFC4861]及び[RFC4862]で指定されるように、それが実行されなければなりません。
When stateful address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC3315].
ステートフルアドレス自動設定を行う場合、[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.
802.16リンクを介して相互に接続されたホストとルータによって指定される「IPv6のためのマルチキャストリスナ発見バージョン2（MLDv2の）」[RFC3810]はサポートされる必要があります。ホストがアイドル/休止モードにある場合、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、ステージ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ワーキンググループの貢献を認めたいSoohongダニエル・パークやガブリエルモンテネグロだけでなく、ヤリArkko、Jonne Soininen、マックスリーゲル、プラカシュアイヤル、DJジョンストン、デーブターラー、ブルーノ・スーザ、アレクサンドル・ペトレスク、マーガレットワッサーマンの議長を務め、そして彼らのレビューとコメントのためのペッカSavola。フィル・バーバーレビューやコメントは、文書の質の向上に役立っています。
[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規格802.16e通信：ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格、ライセンスバンドで固定結合され、モバイル運用のための物理的および媒体アクセス制御層のための改正」、2005年10月、<http://standards.ieee.org / getieee802 /ダウンロード/ 802.16eの-2005.pdf>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[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月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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でオーバー802.16]チョン、H.、リーゲル、M.、およびS.チョン、 "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のオーバーIPCS] Madanapalli、S.、公園、S.、およびS. Chakrabarti、 "IEEE 802.16のIPコンバージェンス・サブレイヤオーバー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]ジヨン、J.、Madanapalli、S.、およびJ. Mandin、 "IP 802.16以上の問題文と目標"、進歩、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[WMF] "WiMAX Forum", <http://www.wimaxforum.org>.
[WMF] "WiMAXフォーラム"、<http://www.wimaxforum.org>。
[WiMAXArch] "WiMAX End-to-End Network Systems Architecture", September 2007.
[WiMAXArch]「WiMAXのエンドツーエンドのネットワークシステムアーキテクチャ」、2007年9月。
Appendix A. WiMAX Network Architecture and IPv6 Support
付録A. WiMAXのネットワークアーキテクチャおよびIPv6のサポート
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】エアインタフェースは、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ネットワーク・アーキテクチャは、アクセスサービスネットワーク（ASN）とコネクティビティサービスネットワーク（CSN）から構成されています。 ASNは、無線を提供するために必要なネットワーク機能の完全なセットとして定義され、BSと等ASNをAAA、モバイルIPフォーリンエージェント、ページング・コントローラ、ロケーションレジスタなどの他の機能に加えて、ARを含むアクセスネットワークであります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:
プロファイルと呼ばれるASNの実現の3種類は、アーキテクチャによって定義されています。プロファイル・タイプAとCののASNは、R6インタフェースを介して互いに接続されているBS」とASNゲートウェイ（S）（ASN-GW）を含みます。プロファイルタイプBのASNは、BSと他のASN機能の機能が一緒にマージされたものです。いいえASN-GWは、具体的には、プロファイルBのASNに定義されていません。 R6インタフェースが存在しないことは、プロファイルBの特定の特性です。 IPv6の層におけるMSがASNにおけるARと関連しています。 ARは、プロファイルA及びCの場合には、ASN-GWの機能であるとBSとARは、別々のエンティティとR6インタフェースのIPv6を介して結合されたプロファイルBの場合のASN内の関数であることができますBSとARとの間のパケットは総称ルーティングカプセル化（GRE）トンネルを介して搬送されます。 GREトンネルの粒度は、（MSがサービスフローIDによって一意に識別され、それぞれが複数のサービスフローを有することができる）ごと-MSに基づいて、またはサービスごとのフローベースであるべきです。 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
MS BS ON / 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リンクの下位層の接続性を提供します。
Appendix B. IPv6 Link in WiMAX
WiMAXの付録B. 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規格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
IPv6パケットを搬送BSとARとの間の2 A 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は、ポイントツーポイントリンクによって接続されています。 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つのMSが同じリンクに属していません。異なるプレフィックスは、それぞれ独自のリンクに割り当てる必要があります。このリンクは、例外なく、標準のIPリンクと完全に一致しており、[RFC4861]にポイントツーポイントリンクの定義に準拠します。
Appendix C. IPv6 Link Establishment in WiMAX
WiMAXの付録C. IPv6のリンク確立
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.
移動局は、802.16で指定された初期ネットワークエントリを実行します。ネットワークエントリー手順が正常に完了すると、ASNゲートウェイ/ ARは、MSに向かってIPv6の初期サービスフロー（ISF）の確立をトリガします。 ISFは、ASN-GW / ARとBSとの間のGREトンネルです。ターンでのBSは、エアインタフェースを介してトランスポート接続を確立するためにMSを要求します。最終結果は、IPv6パケット及びIPv6パケットを中継するBSとARとの間のGREトンネルを搬送するためのエアインタフェースを介してトランスポート接続です。 ISFの確立が正常に完了すると、IPv6パケットは、MSとARとの間で送受信することができます。 ISFは、ホストの設定手順についてARと通信するMSを可能にします。 ISFの確立後、ARは、MSにルータ広告を送信することができます。 MSは、複数のサービスがサービス（QoS）の特性の異なる品質で流れる確立することができます。 ISFは、プライマリサービスフローとして考えることができます。 ASN-GW / ARは、（仮想）インタフェースとして管理されているユニークなリンクとして、他のサービスが同じMSに流れると共に、各ISFを扱います。
Appendix D. Maximum Transmission Unit in WiMAX
WiMAXの付録D.最大伝送単位
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] 1522個のオクテットとして最大SDUサイズを指定しています。したがって、IPv6の経路MTUは1500個のオクテットであることができます。しかし、1500の値を使用してBSとARとエアインタフェースを介して6バイトのMACヘッダとの間のIPv6パケットを転送するために使用されるGREトンネルのオーバーヘッドのパケットのフラグメンテーションをもたらすであろう。 IPv6のMTUは、WiMAXネットワーク1400オクテットに設定することが推奨され、そして（デフォルトとは異なる）、この値はMSに伝達します。 1522オクテットの仕様は、WiMAXフォーラムの仕様としない上限を持つ802.16を介して送信することができるSDUのサイズであることに留意されたいです。
Authors' Addresses
著者のアドレス
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア・シーメンス・ネットワーク6000接続のドライブアーヴィング、TX 75039 USA
EMail: basavaraj.patil@nsn.com
メールアドレス：basavaraj.patil@nsn.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
フランク・ξああUA USA 1700アルマ博士スイート500プラノ、TX 75075 USAについて
EMail: xiayangsong@huawei.com
メールアドレス：xiayangsong@huawei.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
ベーチェットSarikaya Huawei社USA 1700アルマ博士スイート500プラノ、TX 75075 USA
EMail: sarikaya@ieee.org
メールアドレス：sarikaya@ieee.org
JinHyeock Choi Samsung AIT Networking Technology Lab P.O.Box 111 Suwon, Korea 440-600
JinHyeockチェ・サムスンAITネットワーキングテクノロジーラボP.O.Box 111水原、韓国440から600
EMail: jinchoe@samsung.com
メールアドレス：jinchoe@samsung.com
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL. Off Airport Road Bangalore, India 560066
Syam Madanapalli Ordynテクノロジーズ1階、クリエータービル、ITPL。エアポートロードバンガロール、インド560066オフ
EMail: smadanapalli@gmail.com
メールアドレス：smadanapalli@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。