RFC5121 日本語訳
5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S.Madanapalli. February 2008. (Format: TXT=50092 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.パティルの要求をネットワークでつないでください: 5121 ノキアシーメンスはカテゴリをネットワークでつなぎます: 規格はF.シャーB.Sarikaya Huawei米国JHを追跡します。 チェ三星オート麦S.Madanapalli Ordyn技術2008年2月
Transmission of IPv6 via the IPv6 Convergence Sublayer
over IEEE 802.16 Networks
IEEE802.16Networksの上のIPv6 Convergence Sublayerを通した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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Std802.16は修理されてモバイルのBroadband Wireless Access Systemsのための空気インターフェース仕様です。上側の層のプロトコルが連結するサービス特有の集合副層はIEEE802.16MAC(中型のAccess Control)の一部です。 Packet集合副層(CS)はパケットインターネットプロトコル(IP)やIEEE802.3LAN/MAN CSMA/CD Access Method(イーサネット)などのベースのプロトコルの輸送に使用されます。 Packet CSのIP特有の部分でIPv6パケットを送って、受け取ることができます。 このドキュメントはIEEE Std802.16空気インタフェースを利用するネットワークによって役立たれたホストにIPv6のアドレシングと操作をPacket CSのIP特有の部分の上指定します。 それは、ユニークな接頭語(または、接頭語)の課題を各ホストに推薦して、ホストがその接頭語の中で複数の識別子を使用するのを許容します、手当たりしだいに発生しているインタフェース識別子のサポートを含んでいて。
Patil, et al. Standards Track [Page 1] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[1ページ]RFC5121IPv6
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 コンベンションは本書では.4 4を使用しました。 IPv6. . . . . . 4 4.1のIEEE802.16集合副層サポート。 MAC. . . . . . . 7 5のIP Csの上のIPv6カプセル化。 802.16空気インタフェース. 8 6を使用するジェネリックネットワークアーキテクチャ。 IPv6は.96.1をリンクします。 IPv6は802.16で.96.2にリンクします。 IPv6は.106.3に802.16への設立をリンクします。 マキシマム・トランスミッション・ユニットコネ802.16.117。 IPv6は課題. . . . . . . . . . . . . . . . . . . . 12 8を前に置きます。 ルータ発見. . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 ルータ懇願. . . . . . . . . . . . . . . . . . . 12 8.2。 ルータ通知. . . . . . . . . . . . . . . . . . . 12 8.3。 ルータ生涯と周期的なルータ通知. . . . 13 9。 ホスト. . . . . . . . . . . . . . . . . . 13 9.1のためのIPv6アドレシング。 識別子. . . . . . . . . . . . . . . . . . . 13 9.2を連結してください。 アドレス検出. . . . . . . . . . . . . . . 13 9.3をコピーしてください。 状態がないアドレス自動構成. . . . . . . . . . . 14 9.4。 Statefulは自動構成. . . . . . . . . . . . 14 10を扱います。 マルチキャストリスナー発見. . . . . . . . . . . . . . . . . 14 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 14 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 16付録A.WiMAXネットワークアーキテクチャとIPv6サポート. . . . . 17付録B.IPv6はWiMAX. . . . . . . . . 20でWiMAXへのWiMAX. . . . . . . . . . . . . . . . . 19付録C.IPv6リンク設立で.19付録D.マキシマム・トランスミッション・ユニットリンクします。
Patil, et al. Standards Track [Page 2] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[2ページ]RFC5121IPv6
1. Introduction
1. 序論
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は修理されてモバイルの広帯域のワイヤレス・アクセスシステムのための空気インタフェースです。IEEE802.16[802.16]規格は空気インタフェースを指定します、Medium Access Control(MAC)層と複数の物理的な層(PHY)の仕様を含んでいて。 認可されて無免許のスペクトルでそれを配布することができます。 PHYとMACはIEEE802.16で指定されますが、空気インタフェースの上のIPv4とIPv6操作の詳細は含まれていません。 このドキュメントはIEEE802.16空気インタフェースの上でIPv6の操作を指定します。
IPv6 packets can be carried over the IEEE Std 802.16 specified air interface via:
以下を通ってIEEE Std802.16の指定された空気インタフェースの上までIPv6パケットを運ぶことができます。
1. the IP-specific part of the Packet CS or
または1. Packet CSのIP特有の部分。
2. the 802.3[802.3]-specific part of the Packet CS
2. Packet CSの802.3[802.3]特有の部分
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.
IEEE802.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 Std802.16空気インタフェースを通して接されます。 BSを超えてMSからのIPv6リンクはBSの一部であるかもしれないアクセスルータか実体で終わります。 基地局は、層2の実体(MSとアクセスルータ(AR)とのIPv6リンクの見解からの)であり、空気インタフェースの上の二地点間接続でARとホストの間のIPv6パケットをリレーします。
2. Terminology
2. 用語
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [PS-GOALS].
用語は本書では「IPより多くの802.16問題声明と目標」[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--Packet集合副層の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)、モバイルNode(ミネソタ)--用語加入者設備、移動局、およびモバイルノードは、互換性を持って本書では使用されて、同じであることを意味します、すなわち、IPホスト。
Patil, et al. Standards Track [Page 3] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[3ページ]RFC5121IPv6
3. Conventions Used in This Document
3. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
4. IEEE 802.16 Convergence Sublayer Support for IPv6
4. IPv6のIEEE802.16集合副層サポート
The IEEE 802.16 MAC specifies two main service-specific convergence sublayers:
IEEE802.16MACは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:
Packet CSはパケットベースのプロトコルの輸送に使用されます。(それは、以下の通りです)。
1. IEEE Std 802.3(Ethernet)
1. IEEE Std802.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 上側の層からパケット(プロトコルData Units、PDUs)を受け入れます。
o performing classification of the packet/PDU based on a set of
defined classifiers that are service specific,
o 1セットのサービス特有の定義されたクラシファイアに基づくパケット/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 同輩実体からPDUsを受けます。
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の概念を示しています:
Patil, et al. Standards Track [Page 4] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[4ページ]RFC5121IPv6
------------------------------\
| ATM CS | Packet CS | \
------------------------------ \
| MAC Common Part Sublayer | \
| (Ranging, scheduling, etc.)| 802.16 MAC
------------------------------ /
| Security | /
|(Auth, encryption, key mgmt)| /
------------------------------/
| PHY |
------------------------------
------------------------------\ | 気圧Cs| パケットCs| \ ------------------------------ \ | MACの一般的な部分副層| \ | (及ぶこと計画をするのなどて、| 802.16 Mac------------------------------ / | セキュリティ| / |(Auth、暗号化、主要な管理)| / ------------------------------/ | PHY| ------------------------------
Figure 1: IEEE 802.16 MAC
図1: IEEE802.16Mac
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)は、IEEE802.16仕様に基づき定義されます(上側の層からのパケットがPacket CSの適切なサービス特有の部分によって処理されるのを可能にします)。 IPv6をPacket CS(IP CS)のIP特有の部分の直接上輸送できます。 IPv4パケットもPacket CSのIP特有の部分の上輸送されます。 IP CSによって使用されたクラシファイアは、IPv4とIPv6パケットの分化と空気インタフェースの上の接続を特定の輸送に写像するのを可能にします。
The figure below shows the options for IPv6 transport over the packet CS of IEEE 802.16:
IPv6のためのオプションがIEEE802.16のパケットCSの上で輸送するショーの下における図:
+-------------------+
| IPv6 |
+-------------------+ +-------------------+
| IPv6 | | Ethernet |
+-------------------+ +-------------------+
| IP-specific | | 802.3-specific |
| part of Packet CS | | part of Packet CS |
|...................| |...................|
| MAC | | MAC |
+-------------------+ +-------------------+
| PHY | | PHY |
+-------------------+ +-------------------+
+-------------------+ | IPv6| +-------------------+ +-------------------+ | IPv6| | イーサネット| +-------------------+ +-------------------+ | IP特有です。| | 802.3特有です。| | Packet CSの一部| | 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
(1) (2) Packet CSのPacket CSの特定の部分のIP特有の一部分802.3/イーサネットの上IPv6の上のIPv6
Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CS
図2: Packet CSのIPと802.3特有の部分の上のIPv6
Patil, et al. Standards Track [Page 5] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[5ページ]RFC5121IPv6
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].
そこである間802.16空気インタフェースの上にIPv6を伝えることができる複数のメソッドであるショーを超えた図、このドキュメントの範囲はIP CSだけの上のIPv6操作に制限されます。 イーサネットの上のIPのトランスミッションは[IPoE-over-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.
SBC-REQ/RSPメッセージ(802.16詳細)の及ぶこと(802.16空気インタフェース手順)と交換直後MSとBSが802.16のREG-REQ(登録Request)とREG-RSP(登録Response)MACメッセージで彼らの能力を交換することに注意されるべきです。 これらの管理フレームはMSとBSによってサポートされたConvergence Sublayerなどのパラメタを交渉します。 デフォルトで、Packet、IPv4、および802.3/イーサネットはサポートされます。 IP CSを通したIPv6はそのようなサポートを含意する能力交渉メッセージ(REG-REQとREG-RSP)のIPv6サポートビットが「分類/PHSオプションとSDU(サービスData Unit)カプセル化サポート」というパラメタで示されるMSとBSだけによってサポートされます。([802.16])を参照してください。 さらに、IPv6パケットを輸送するための輸送接続の設立の間、BSとMSの間のDSA-REQ(ダイナミックなService Addition)と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. Packet CSのイーサネットの(802.3)特有の部分の上にIPv6パケットを送って、MSとBSがイーサネットCSの上のIPv6プロトコルサポートを示すときには受けることができなければならなくなってください。 しかしながら、MSとBSがIP CSとイーサネットCSの両方の上のIPv6プロトコルサポートを示すとき、MSとBS MUSTは送受信IPv6パケットにIP CSを使用します。
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
MSとBSがIP CSの上でIPv6をサポートするとき、このドキュメントにおける続かれているIEEE802.16と推薦の上でIPv6パケットを輸送するのにデフォルトモードとしてそれを使用しなければなりません。 IPv6輸送のための一般的な集合副層を交渉する無能
Patil, et al. Standards Track [Page 6] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[6ページ]RFC5121IPv6
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は輸送接続をセットアップして、その結果ホストをIPv6パケットを送って、受けることができないようにしないことをもたらすでしょう。 IPv6パケットを輸送する1つ以上のメソッドを実装するホストの場合では、また、BSがそのような能力をサポートするとき、(すなわち、IP CSかIPv6より多くの802.3の上の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 MUSTは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実装が802.16のためにIETFによって定義されたすべての標準化過程カプセル化をサポートするのは、REQUIREDです。 この仕様を書く時点で、これは唯一のカプセル化ですが、追加仕様に働いています。 しかしながら、BS実装がそれらがサポートするすべてのカプセル化を使用するのが必要ではありません。 いくつかの運転モードが構成でオフであるかもしれません。
4.1. IPv6 Encapsulation over the IP CS of the MAC
4.1. MACのIP Csの上のIPv6カプセル化
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.
Packet CSのIP特有の部分の上運ばれると、IPv6ペイロードは6バイトのIEEE802.16ジェネリックMACヘッダーによってカプセル化されます。 ジェネリックMACヘッダーによってカプセルに入れられたIPv6パケットの書式は以下の図に示されます。 6バイトのMACヘッダーの形式は[802.16]仕様で説明されます。 CRC(周期冗長検査)は任意です。 実際のMACアドレスがMACヘッダーに含まれていないことに注意されるべきです。
---------/ /-----------
| MAC SDU |
--------/ /------------
||
||
MSB \/ LSB
---------------------------------------------------------
| Generic MAC header| IPv6 Payload | CRC |
---------------------------------------------------------
---------/ /----------- | Mac SDU| --------/ /------------ || || MSB\/LSB--------------------------------------------------------- | ジェネリックMACヘッダー| IPv6有効搭載量| 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,
IEEE802.16の上のIP CSを通したIPv6パケットのトランスミッションのために、IPv6層は直接802.16MACに連結します。 IPv6層はIEEE802.16MACのPacket CSにIPv6パケットを提供します。 Packet CSはパケットを扱う方法を決定するのに使用される1セットのクラシファイアを定義します。 MACで使用されるIPクラシファイアはIPヘッダーの分野とトランスポート・プロトコルを作動させます、そして、これらはIP Trafficのクラスを含んでいます、Nextヘッダーフィールド
Patil, et al. Standards Track [Page 7] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[7ページ]RFC5121IPv6
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
----------- ---------- | IPv6 Pkt| |IPv6 Pkt| ----------- ---------- | | /|\ | | | --[SAP]--------------------- ---------[SAP]-------- ||-| |----------| | | /|\ | || \ / 0---->[CID1]| | --- |-------- | || ダウンリンク0円/-->[CID2]| | |再建します。| | || classifiers0/\--、>、[] | | | (アンドゥPHS)| | || 0---->[CIDn]| | --- ------- | ||--------------| | | /|\ | | | | | | | SDU、Cid。 | | SDU、Cid。 | | | | | /|\ | | v| | | | ------[SAP]----------------- |-------[SAP]--------- | 802.16 Mac CPS|、-、-、-、-、--、>| 802.16 Mac CPS| ---------------------------- ---------------------- BSさん
Figure 4: IPv6 packet transmission: Downlink
図4: IPv6パケット伝送: ダウンリンク
5. Generic Network Architecture Using the 802.16 Air Interface
5. 802.16空気インタフェースを使用するジェネリックネットワークアーキテクチャ
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パケットはユニークなConnection Identifier(CID)によって特定される二地点間輸送接続の上まで運ばれます。 輸送接続はMSとBSとのMAC層のリンクです。 以下の数字は、可能なネットワークアーキテクチャについて説明して、現実にジェネリックです。 より難解なアーキテクチャは、可能ですが、このドキュメントの範囲で考えられません。
Patil, et al. Standards Track [Page 8] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[8ページ]RFC5121IPv6
Option A:
オプションA:
+-----+ CID1 +--------------+
| MS1 |------------/| BS/AR |-----[Internet]
+-----+ / +--------------+
. /---/
. CIDn
+-----+ /
| MSn |---/
+-----+
+-----+ CID1+--------------+ | MS1|------------/| BS/アルゴン|-----[インターネット] +-----+ / +--------------+ . /---/CIDn+-----+ / | MSn|---/ +-----+
Figure 5: IPv6 AR as an integral part of the BS
図5: BSの不可欠の部分としてのIPv6 AR
Option B:
オプションB:
+-----+ CID1 +-----+ +-----------+
| MS1 |----------/| BS1 |----------| AR |-----[Internet]
+-----+ / +-----+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
+-----+ CID1+-----+ +-----------+ | MS1|----------/| BS1|----------| アルゴン|-----[インターネット] +-----+ / +-----+ +-----------+ . / ____________ . CIDn/()__________() +-----+/L2トンネル| 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とのポイントツーポイント接続を例証するために見せられます。
6. IPv6 Link
6. IPv6リンク
"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ヘッダーのHop限界分野を減少させるルータで境界があります。 MSがリンクの中に移行すると、それはIPアドレスを使用し続けることができます。 これは、層の3定義と、定義はIEEE802規格が'(L2)はリンクする'用語の定義と同じでないというメモです。
6.1. IPv6 Link in 802.16
6.1. IPv6は802.16でリンクします。
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の間に存在できます。
Patil, et al. Standards Track [Page 9] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[9ページ]RFC5121IPv6
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がcolocatedされるとき、MSへの輸送の接続の収集は単一のリンクと定義されます。 ARとBSが切り離されるとき、トンネルが粒状が、より'MS'か'サービス流動'であるARとBSの間で確立されるのは、お勧めです(MSはサービス流れ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]のための隣人発見でポイントツーポイント接続の定義に従います。 したがって、Packet CSのIP特有の部分の上IPv6操作のために802.16SHOULDでポイントツーポイント接続をたどります。使用されます。 リンク(MS/ホスト)あたり1つのユニークなIPv6接頭語(es)を割り当てなければなりません。
6.2. IPv6 Link Establishment in 802.16
6.2. 802.16へのIPv6リンク設立
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 Std802.16仕様に基づき定義されるようにPrivacy Key Managementバージョン2(PKMv2)に基づいています。
4. On successful completion of authentication, the MS performs
802.16 registration with the network.
4. 認証の無事終了に、MSはネットワークと共に802.16登録を実行します。
Patil, et al. Standards Track [Page 10] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[10ページ]RFC5121IPv6
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カプセル化をサポートするかを示します。 デフォルトで、Packet、IPv4、および802.3/イーサネットはサポートされるものとします。 したがって、REG-REQ(802.16メッセージ)でのこのパラメタの欠如は、命名されたオプションがMS/SSによってサポートされることを意味します。 Packet CSのIP特有の部分の上IPv6のサポートは2つのCS能力Bit#パラメタによって示されます。([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をサポートするために能力を確認したなら、さんは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 SHOULDは隣人発見[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]にあります。
6.3. Maximum Transmission Unit in 802.16
6.3. 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値は構成可能です。 デフォルトMTU、802.16リンクSHOULDの上のIPv6パケットのために、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.16MAC PDUは任意のペイロードが支えた6バイトのヘッダーとヘッダーとペイロードを含んでいる任意のCRCで構成されます。 PDUの長さはGeneric MACヘッダーでレンパラメタによって示されます。 レンパラメタには、11ビットのサイズがあります。 したがって、総MAC PDUサイズは2048バイトです。 IPv6ペイロードサイズは異なることができます。 ある展開シナリオでは、MTU値はデフォルトより大きい場合があります。 IPv6[RFC4861]のための隣人発見はアルゴンが広告を出さなければならないMTUオプションを定義します、ルータ通知(RA)で、1500年と異なった値が使用されているなら。 ミネソタは[RFC4861]で定義されるようにこのオプションを処理します。 Path MTUがディスカバリー[RFC1981]であると実装するノードは、IPv6パケットのためにMTUを決定するのにメカニズムを使用するかもしれません。
Patil, et al. Standards Track [Page 11] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[11ページ]RFC5121IPv6
7. IPv6 Prefix Assignment
7. IPv6接頭語課題
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(顧客Premise Equipment)タイプは接続のエンドポイントであるかもしれません。 したがって、1以上/64はSHOULDを前に置きます。リンクに割り当てられます。 リンクの上に(Lで噛み付かれる)の旗のセットがある状態で、[RFC4861]で指定されるように接頭語の広告を出します。 接頭語のサイズと数は構成問題です。 また、Dynamic Host Configuration Protocol(DHCP)かAuthenticationと、Authorizationと、Accountingの(AAA)ベースの接頭語委譲が1つを提供するのに使用されたかもしれませんか、またはARのためのMSへの、より多くの接頭語が802.16以上を接続しました。 また、構成で接頭語の他の特性は対処されています。
8. Router Discovery
8. ルータ発見
8.1. Router Solicitation
8.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個のリンクを通して接続されたMNsのために推薦されません。
8.2. Router Advertisement
8.2. ルータ通知
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.
IPv6リンクが設立されるとすぐに、AR SHOULDはルータ通知の数(構成可能な値)をMSに送ります。 ARは[RFC4861]に従って定期的に求められていないルータ通知を送ります。 周期的なルータ通知の間隔について、隣人発見における仕様よりどんなにさらに大きいならIPv6をである以下のセクションで議論するか。
Patil, et al. Standards Track [Page 12] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[12ページ]RFC5121IPv6
8.3. Router Lifetime and Periodic Router Advertisements
8.3. ルータ生涯と周期的なルータ通知
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.
ルータ生涯SHOULD、望ましくは何時間も大きい値に設定されてください。 このドキュメントは「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に提供する必要があるといけないので、ページングが必要です。周期的なルータ通知SHOULDの間で放送されたインタフェース、無駄なモードとリソースを消費することにおいて間隔であるモバイルを起こすのを避けるには、全く高く設定されてください。 本書では指定されたMaxRtrAdvInterval値は「IPバージョン6(IPv6)のための隣人発見」[RFC4861]における推薦をくつがえします。 MaxRtrAdvIntervalは4秒未満と21600秒以下ノーであるに違いありません。 MaxRtrAdvIntervalのためのデフォルト値は10800秒です。
9. IPv6 Addressing for Hosts
9. ホストのためのIPv6アドレシング
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]はアドレシングに、適切なRFCsの1セットを指定します、そして、IPv6パケットを輸送するのにリンクレイヤとして802.16を使用するホストにとって、同じくらいは適切です。
9.1. Interface Identifier
9.1. インタフェース識別子
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アドレスがあります。 「IPバージョン6アドレッシング体系」[RFC4291]の指定されるとしての変更されたEUI-64形式ベースのインタフェース識別子を生成するのにこのMACアドレスを使用しなければなりません。 変更されたEUI-64インタフェース識別子は状態がないアドレス自動構成に使用されます。 IPv6をサポートする他のリンクのように、EUI-64ベースのインタフェース識別子は義務的で他のメカニズムではありません、無作為のインタフェース識別子、「IPv6"[RFC4941]での状態がないアドレス自動構成のためのプライバシー拡大、また、使用されるかもしれないことなど」ように。
9.2. Duplicate Address Detection
9.2. アドレス検出をコピーしてください。
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
DAD SHOULD、「IPバージョン6(IPv6)のための隣人発見」、[RFC4861]、および「IPv6の状態がないアドレス自動構成」[RFC4862]に従って、実行されてください。 IPv6リンクより多くの802.16は本書ではポイントツーポイント接続として指定されます。 この評価基準に基づいて、それはそうです。
Patil, et al. Standards Track [Page 13] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[13ページ]RFC5121IPv6
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:
以下の2つの条件が満たされる限り、IPv6 Stateless Address Autoconfigurationプロトコル[RFC4862]の一部としてインタフェースにEUI-64を使用することで構成されるか、またはRFC4941[RFC4941]に従って作られるグローバルなユニキャストアドレスにDADを実行するために余分:
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.16IPv6リンクを終えながらルータ通知メッセージのを通してアクセスルータによって広告に掲載された接頭語はそのリンクにユニークです。
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.16IPv6リンクを終えるアクセスルータはそれが広告を出す接頭語からの少しのIPv6のグローバルなユニキャストアドレスも自動構成しません。
9.3. Stateless Address Autoconfiguration
9.3. 状態がないアドレス自動構成
When stateless address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC4862].
状態がないアドレス自動構成が実行されるとき、それとして、[RFC4861]と[RFC4862]で指定されていた状態で実行しなければなりません。
9.4. Stateful Address Autoconfiguration
9.4. Statefulアドレス自動構成
When stateful address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC3315].
statefulアドレス自動構成が実行されるとき、それとして、[RFC4861]と[RFC3315]で指定されていた状態で実行しなければなりません。
10. Multicast Listener Discovery
10. マルチキャストリスナー発見
"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.
「マルチキャストListenerディスカバリーバージョン2(MLDv2)、IPv6"[RFC3810]SHOULDに関しては、802.16リンクを通して互いに愛着しているホストとルータによって指定されるようにサポートされてください、」 802.16SHOULD NOTの上のポイントツーポイント接続を通してそれに付けられたホストがホストであるならそれで周期的な質問を送るアクセスルータが活動していないか眠っているモードであります。 ARはページングコントローラからネットワークでホストの状態の情報を得ることができます。
11. Security Considerations
11. セキュリティ問題
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の基地局を超えてわたるネットワークアーキテクチャの安全保障問題はそのようなアーキテクチャを定義するドキュメントの対象です、Stage2のセクション7.2と7.3におけるWiMAX Network Architecture[WiMAXArch]などのように、Part2。
Patil, et al. Standards Track [Page 14] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[14ページ]RFC5121IPv6
12. Acknowledgments
12. 承認
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ワーキンググループいすのヤリArkkoと同様にSoohongダニエルParkとガブリエル・モンテネグロ、Jonne Soininen、マックス・リーゲル、プラカシュ・アイヤル、DJのジョンストン、デーヴThaler、ブルーノ・スーザ、Alexandruペトレスク、マーガレット・ワッサーマン、およびペッカSavolaの貢献を承諾したがっています。 また、フィル・バーバーによるレビューとコメントは、ドキュメント品質を改良するのを手伝いました。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[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:」 「Licensed BandsのLocalとメトロポリタンエリアネットワークのためのIEEE Standard、PhysicalのためのAmendment、およびCombined FixedとモバイルOperationのためのMedium Access Control Layers」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.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC4291] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 4291,
February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、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)」、RFC4861(2007年9月)。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。
Patil, et al. Standards Track [Page 15] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[15ページ]RFC5121IPv6
13.2. Informative References
13.2. 有益な参照
[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 Std802.3-2005:」 情報技術テレコミュニケーションのためのIEEE Standardとシステム地方とメトロポリタンエリアネットワークの間の情報交換--決められた一定の要求Part3: 「衝突検出型搬送波検知多重アクセス(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.
H.、リーゲル、M.、およびS.Jeong、「IEEE802.16ネットワークの上のイーサネットの上のIPのトランスミッション」という[IPoE-over-802.16]Jeonは進行中(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.、Park、S.、およびS.Chakrabarti、「IEEE802.16のIP Convergence Sublayerの上のIPv4パケットのトランスミッション」、Progress(2007年11月)のWork。
[PS-GOALS] Jee, J., Madanapalli, S., and J. Mandin, "IP over
802.16 Problem Statement and Goals", Work
in Progress, December 2007.
[PS-目標] J.、Madanapalli、S.、J.Mandin、および「IPより多くの802.16問題声明と目標」というJeeは進歩、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4294] Loughney、J.、「IPv6ノード要件」、RFC4294、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"、RFC4941、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.
2007年9月の[WiMAXArch]「WiMAX終わりから終わりへのネットワーク・システムアーキテクチャ。」
Patil, et al. Standards Track [Page 16] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[16ページ]RFC5121IPv6
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]は空気インタフェースがIEEE802.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などの他の機能に加えてBSとARを含んでいるアクセスネットワークです、モバイルIP外国人のエージェント、コントローラ、位置のレジスタなどを呼び出して 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 | ( )
--------- (----------)
------------------- | ---- ASN| |----| ---- | |BS|\R6-------| |---------| | CSN| |さん|-----R1----| ---- \---|ASN-GW| R3| CSN| R5| | ---- | |R8/--|------|----| |-----|ホーム| | ---- / | | 訪問されます。| | NSP| | |BS|/ | | NSP| | | | ---- | |---------| | | | 仮眠| \ |----| ------------------- \---| / | | / | (--|------/----) |R4( )| (ASPネットワーク) --------- (または、インターネット) | ASN| ( ) --------- (----------)
Figure 7: WiMAX network reference model
図7: WiMAXネットワーク規範モデル
Patil, et al. Standards Track [Page 17] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[17ページ]RFC5121IPv6
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のASNsはBSとASN-ゲートウェイ(ASN-GW)を含んでいます。(それは、R6インタフェースを通して互いに接続されます)。 プロフィールタイプBのASNはBSと他のASN機能の機能性がどれであるかで結合するものです。 ASN-GWは全くプロフィールB ASNで明確に定義されません。 また、R6インタフェースの不在はプロフィールのB特定の特性です。 IPv6層のMSはASNのARに関連しています。 ARはプロフィールAとCの場合における、ASN-GWの機能であるかもしれなく、プロフィールB.When BSの場合でASNでの機能です、そして、ARは別々の実体です、そして、R6インタフェースを通して繋がって、BSとARの間のIPv6パケットはGenericルート設定Encapsulation(GRE)トンネルの上まで運ばれます。 1MSあたり1個のベースの上、または、サービス単位で流れるベースの上にGREトンネルの粒状があるべきです(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 |
-------- --------------- ----------------- -------
|-------| | 装置|- - - - - - - - - - - - - - - - - - - - - - - -(装置同輩への) | | |-------| /------ ------- | | /IPv6| | | | IPv6|- - - - - - - - - - - - - - - - / | | | -->、|、| --------------- -------/ | | IPv6| |-------| | \リレー/| | | |- - - | | | | | \ / | | 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 AR/ASN-GW CSN Rtr
Figure 8: WiMAX protocol stack
エイト環: 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リンクに供給します。
Patil, et al. Standards Track [Page 18] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[18ページ]RFC5121IPv6
Appendix B. IPv6 Link in WiMAX
付録B.IPv6はWiMAXでリンクします。
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 Std802.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. そしてすなわち、空気インタフェース、MS、およびBSの上でa Connection Identifier(CID)によって特定される輸送接続。
2. A GRE tunnel between the BS and AR that transports the IPv6
packets
2. BSとARの間のIPv6パケットを輸送する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は異なったリンクに属します。 いいえtwo、MSsは同じリンクに属します。 異なった接頭語はそれぞれのユニークなリンクに割り当てられるべきです。 このリンクは、例外なしで標準の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はIPv6のための初期のサービス流動(ISF)の設立のMSに向かって引き金となります。ISFはASN-GW/ARとBSの間のGREトンネルです。 BSは、空気インタフェースの上の輸送接続を確立するよう順番にMSに要求します。 結末は、IPv6パケットを運ぶための空気インタフェースの上の輸送接続とIPv6パケットをリレーするためのBSとARの間のGREトンネルです。 ISFの設立の無事終了のときに、MSとARの間にIPv6パケットを送って、受け取ることができます。 ISFは、MSがホスト構成手順のためにARとコミュニケートするのを可能にします。 ISFの設立の後に、ARはルータ通知をMSに送ることができます。MSは異なったサービスの質(QoS)の特性に従った複数のサービス流れを確立できます。 一次業務流動であるとISFをみなすことができます。 ASN-GW/ARは各ISFを扱います、同じMSへの他のサービス流れと共に、(仮想)のインタフェースとして管理されるユニークなリンクとして。
Patil, et al. Standards Track [Page 19] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[19ページ]RFC5121IPv6
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の八重奏であるかもしれません。 しかしながら、空気インタフェースの上でBSとARの間のIPv6パケットと6バイトのMACヘッダーを輸送するのに使用されるGREトンネルのオーバーヘッドのために、1500年の値を使用すると、パケットの断片化はもたらされるでしょう。 IPv6のためのMTUがWiMAXネットワーク、およびこの値(デフォルトと異なった)における1400の八重奏に用意ができているのは、お勧めです。MSとコミュニケートしてください。1522八重奏の仕様がサイズではなく、802.16以上に伝えることができるSDUのWiMAXフォーラム仕様であることに注意してください。(それは、より高い限界を持っています)。
Patil, et al. Standards Track [Page 20] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[20ページ]RFC5121IPv6
Authors' Addresses
作者のアドレス
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキアジーメンスネットワーク6000接続Driveテキサス75039アービング(米国)
EMail: basavaraj.patil@nsn.com
メール: basavaraj.patil@nsn.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
フランクシャーHuawei米国1700アルマ博士Suite500テキサス75075プラノ(米国)
EMail: xiayangsong@huawei.com
メール: xiayangsong@huawei.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
Behcet Sarikaya Huawei米国1700アルマ博士Suite500テキサス75075プラノ(米国)
EMail: sarikaya@ieee.org
メール: sarikaya@ieee.org
JinHyeock Choi Samsung AIT Networking Technology Lab P.O.Box 111 Suwon, Korea 440-600
水原、JinHyeockチェ三星オート麦ネットワーク・テクノロジー研究室P.O.Box111韓国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
Patil, et al. Standards Track [Page 21] RFC 5121 IPv6 via IPv6 CS over IEEE 802.16 February 2008
パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[21ページ]RFC5121IPv6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Patil, et al. Standards Track [Page 22]
パティル、他 標準化過程[22ページ]
一覧
スポンサーリンク
