RFC5181 日本語訳
5181 IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed.,Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT=36671 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M-K. Shin, Ed.
Request for Comments: 5181 ETRI
Category: Informational Y-H. Han
KUT
S-E. Kim
KT
D. Premec
Siemens Mobile
May 2008
ワーキンググループM Kをネットワークでつないでください。 エド、よじ登ってください。コメントのために以下を要求してください。 5181年のETRIカテゴリ: 情報のY-H。 ハンKUT S-E。 2008年5月のモバイルのキムKT D.Premecシーメンス
IPv6 Deployment Scenarios in 802.16 Networks
802.16のネットワークにおけるIPv6展開シナリオ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies.
このドキュメントは配布しているIPv4サービスとの共存でIPv6展開、統合メソッド、およびシナリオの詳述をワイヤレスの広帯域アクセスネットワークに提供します。 本書では、私たちはIPv6がどうIPv4 IEEE802.16からのネットワークとそれらの違いがネットワークでつなぐIPv6 IEEE802.16アクセスと配布されて、それぞれのIEEEで802.16の技術を統合したかに関する主なコンポーネントについて議論するつもりです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3
2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3
2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 3
2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 4
2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 8
2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 10
2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 11
2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 2 2。 IEEE802.16のIPv6にネットワーク. . . . . . . . . . . . 3 2.1を配布します。 IEEE802.16のElementsは.32.2をネットワークでつなぎます。 シナリオとIPv6展開. . . . . . . . . . . . . . 3 2.2.1。 モバイルアクセス展開シナリオ. . . . . . . . . . 4 2.2.2。 修理されたか遊牧民的な展開シナリオ. . . . . . . . . . 8 2.3。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . 10 2.4。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5。 IPv6セキュリティ. . . . . . . . . . . . . . . . . . . . . . 11 2.6。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . . . 11 3。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 5.2。 有益な参照. . . . . . . . . . . . . . . . . . 13
Shin, Ed., et al. Informational [Page 1] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[1ページ]のRFC5181IPv6
1. Introduction
1. 序論
As the deployment of IEEE 802.16 access networks progresses, users will be connected to IPv6 networks. While the IEEE 802.16 standard defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 Media Access Control (MAC) payload, a complete description of IPv4/ IPv6 operation and deployment is not present. The IEEE 802.16 standards are limited to L1 and L2, so they may be used within any number of IP network architectures and scenarios. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies.
IEEE802.16アクセスの展開が発展をネットワークでつなぐとき、ユーザはIPv6ネットワークに接続されるでしょう。 IEEE802.16規格はIEEE802.16メディアAccess Control(MAC)ペイロードでIPv4/IPv6データグラムのカプセル化を定義しますが、IPv4/ IPv6操作と展開の完全な記述は存在していません。 IEEE、802.16の規格がL1とL2に制限されるので、それらはいろいろなIPネットワークアーキテクチャとシナリオの中で使用されるかもしれません。 本書では、私たちはIPv6がどうIPv4 IEEE802.16からのネットワークとそれらの違いがネットワークでつなぐIPv6 IEEE802.16アクセスと配布されて、それぞれのIEEEで802.16の技術を統合したかに関する主なコンポーネントについて議論するつもりです。
This document extends the work of [RFC4779] and follows the structure and common terminology of that document.
このドキュメントは、[RFC4779]の仕事を広げていて、そのドキュメントの構造と一般的な用語に従います。
1.1. Terminology
1.1. 用語
The IEEE 802.16-related terminologies in this document are to be interpreted as described in [RFC5154].
このドキュメントのIEEEの802.16関連の用語は[RFC5154]で説明されるように解釈されることです。
o Subscriber Station (SS): An end-user equipment that provides
connectivity to the 802.16 networks. It can be either fixed/
nomadic or mobile equipment. In a mobile environment, SS
represents the Mobile Subscriber Station (MS) introduced in
[IEEE802.16e].
o 加入者設備(ss): 802.16のネットワークに接続性を提供するエンドユーザ設備。 それは修理されるか遊牧民的であるかモバイルの設備であるかもしれません。 モバイル環境で、SSは[IEEE802.16e]で導入されたモバイルSubscriber駅(MS)を代表します。
o Base Station (BS): A generalized equipment set providing
connectivity, management, and control between the subscriber
station and the 802.16 networks.
o 駅(BS)を基礎づけてください: 一般化された設備は、加入者設備と802.16のネットワークの間に接続性、管理、およびコントロールを提供しながら、セットしました。
o Access Router (AR): An entity that performs an IP routing function
to provide IP connectivity for a subscriber station (SS or MS).
o ルータ(AR)にアクセスしてください: 加入者設備(SSかMS)にIPの接続性を提供するためにIP経路選択機能を実行する実体。
o Connection Identifier (CID): A 16-bit value that identifies a
connection to equivalent peers in the 802.16 MAC of the SS(MS) and
BS.
o 接続識別子(Cid): 同等物に接続を特定する16ビットの値はSS(MS)とBSの802.16MACをじっと見ます。
o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS-specific
part of the Packet CS defined in 802.16 STD.
o イーサネットCs(集合副層): Packet CSの802.3/イーサネットのCS特有の部分は802.16でSTDを定義しました。
o IPv6 CS (Convergence Sublayer): IPv6-specific subpart of the
Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.
o IPv6Cs(集合副層): Packet CS、802.16STDで定義されたClassifier2(パケット、IPv6)のIPv6特有の下位区分。
Shin, Ed., et al. Informational [Page 2] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[2ページ]のRFC5181IPv6
2. Deploying IPv6 in IEEE 802.16 Networks
2. IEEE802.16のIPv6にネットワークを配布します。
2.1. Elements of IEEE 802.16 Networks
2.1. IEEE802.16ネットワークのElements
[IEEE802.16e] is an air interface for fixed and mobile broadband wireless access systems. [IEEE802.16] only specifies the convergence sublayers and the ability to transport IP over the air interface. The details of IPv6 (and IPv4) operations over IEEE 802.16 are defined in the 16ng WG. The IPv6 over IPv6 CS definition is already an approved specification [RFC5121]. IP over Ethernet CS in IEEE 802.16 is defined in [IP-ETHERNET].
[IEEE802.16e]は修理されてモバイルの広帯域のワイヤレス・アクセスシステムのための空気インタフェースです。[IEEE802.16]は空気インタフェースの上で集合副層とIPを輸送する能力を指定するだけです。 IEEE802.16の上のIPv6(そして、IPv4)操作の詳細は16ng WGで定義されます。 IPv6 CS定義の上のIPv6は既に承認された仕様[RFC5121]です。 IEEE802.16のイーサネットCSの上のIPは[IP-イーサネット]で定義されます。
Figure 1 illustrates the key elements of typical mobile 802.16 deployments.
図1は典型的なモバイル802.16の展開の主要な要素を例証します。
Customer | Access Provider | Service Provider
Premise | | (Backend Network)
顧客| アクセスプロバイダ| サービスプロバイダー前提| | (バックエンドネットワーク)
+-----+ +----+ +----+ +--------+
| SSs |--(802.16)--| BS |-----| | | Edge | ISP
+-----+ +----+ | AR |---| Router |==>Network
+--| | | (ER) |
| +----+ +--------+
+-----+ +----+ | | +------+
| SSs |--(802.16)--| BS |--+ +--|AAA |
+-----+ +----+ |Server|
+------+
+-----+ +----+ +----+ +--------+ | SSs|--(802.16)--| BS|-----| | | 縁| ISP+-----+ +----+ | アルゴン|---| ルータ|==>ネットワーク+--| | | (えー) | | +----+ +--------+ +-----+ +----+ | | +------+ | SSs|--(802.16)--| BS|--+ +--|AAA| +-----+ +----+ |サーバ| +------+
Figure 1: Key Elements of IEEE 802.16(e) Networks
図1: IEEE 802.16(e)ネットワークの主要なElements
2.2. Scenarios and IPv6 Deployment
2.2. シナリオとIPv6展開
[IEEE802.16] specifies two modes for sharing the wireless medium: point-to-multipoint (PMP) and mesh (optional). This document only focuses on the PMP mode.
[IEEE802.16]はワイヤレスの媒体を共有するための2つのモードを指定します: ポイントツーマルチポイント(PMP)とメッシュ(任意の)。 このドキュメントはPMPモードに焦点を合わせるだけです。
Some of the factors that hinder deployment of native IPv6 core protocols are already introduced by [RFC5154].
固有のIPv6コアプロトコルの展開を妨げる要素のいくつかが[RFC5154]によって既に紹介されます。
There are two different deployment scenarios: fixed and mobile access deployment scenarios. A fixed access scenario substitutes for existing wired-based access technologies such as digital subscriber lines (xDSL) and cable networks. This fixed access scenario can provide nomadic access within the radio coverages, which is called the Hot-zone model. A mobile access scenario exists for the new paradigm of transmitting voice, data, and video over mobile networks. This scenario can provide high-speed data rates equivalent to the wire-based Internet as well as mobility functions equivalent to
2つの異なった展開シナリオがあります: 修理されてモバイルのアクセス展開シナリオ。 固定アクセスシナリオはデジタル加入者線(xDSL)やケーブルネットワークなどの既存の配線ベースのアクセス技術のために代理をします。 この固定アクセスシナリオはラジオ適用範囲の中の遊牧民的なアクセスを提供できます。(それは、Hot-ゾーンモデルと呼ばれます)。 モバイルアクセスシナリオは声、データ、およびビデオをモバイルネットワークの上に送る新しい発想のために存在しています。 このシナリオは相当していた状態で移動性機能と同様にワイヤベースのインターネットに同等な高速データレートを提供できます。
Shin, Ed., et al. Informational [Page 3] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[3ページ]のRFC5181IPv6
cellular systems. There are the different IPv6 impacts on convergence sublayer type, link model, addressing, mobility, etc. between fixed and mobile access deployment scenarios. The details will be discussed below. The mobile access scenario can be classified into two different IPv6 link models: shared IPv6 prefix link model and point-to-point link model.
セルラ方式修理されてモバイルのアクセス展開シナリオの間には、異なったIPv6影響が集合副層タイプ、リンクモデル、アドレシング、移動性などにあります。 以下で詳細について議論するでしょう。 モバイルアクセスシナリオを2つの異なったIPv6リンクモデルに分類できます: 共有されたIPv6接頭語リンクモデルとポイントツーポイント接続はモデル化されます。
2.2.1. Mobile Access Deployment Scenarios
2.2.1. モバイルアクセス展開シナリオ
Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions and fixed communications. [IEEE802.16e] has been standardized to provide mobility features on IEEE 802.16 environments. IEEE 802.16 BS might be deployed with a proprietary backend managed by an operator.
IEEE802.11と異なって、IEEE802.16に、BSは移動性機能と固定コミュニケーションを提供できます。 [IEEE802.16e]は、IEEE802.16環境に関する移動性機能を提供するために標準化されました。 802.16BSが独占バックエンドで配布されるかもしれないIEEEはオペレータで管理しました。
There are two possible IPv6 link models for mobile access deployment scenarios: shared IPv6 prefix link model and point-to-point link model [RFC4968]. There is always a default access router in the scenarios. There can exist multiple hosts behind an MS (networks behind an MS may exist). The mobile access deployment models, Mobile WiMax and WiBro, fall within this deployment model.
モバイルアクセス展開シナリオのための2つの可能なIPv6リンクモデルがあります: 共有されたIPv6はリンクモデルとポイントツーポイント接続モデル[RFC4968]を前に置きます。 シナリオにはデフォルトアクセスルータがいつもあります。 複数のホストがMSの後ろに存在できます(MSの後ろのネットワークは存在するかもしれません)。 モバイルアクセス展開モデル(モバイルWiMaxとWiBro)は、この展開モデルの中に落ちます。
(1) Shared IPv6 Prefix Link Model
(1)の共有されたIPv6接頭語リンクモデル
This link model represents the IEEE 802.16 mobile access network deployment where a subnet consists of only single AR interfaces and multiple MSs. Therefore, all MSs and corresponding AR interfaces share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix will be different from the interface of the AR.
サブネットが単一のARインタフェースと複数のMSsだけから成るところにこのリンクモデルはIEEE802.16モバイルアクセスネットワーク展開を表します。 したがって、すべてのMSsと対応するARインタフェースは図2に示されるのと同じIPv6接頭語を共有します。 IPv6接頭語はARのインタフェースと異なるでしょう。
+-----+
| MS1 |<-(16)-+
+-----+ | +-----+
+-----+ +----| BS1 |--+
| MS2 |<-(16)-+ +-----+ |
+-----+ | +-----+ +--------+
+->| AR |----| Edge | ISP
+-----+ | +-----+ | Router +==>Network
| MS3 |<-(16)-+ +-----+ | +--------+
+-----+ +----| BS2 |--+
+-----+ | +-----+
| MS4 |<-(16)-+
+-----+
+-----+ | MS1| <、-(16)-+ +-----+ | +-----+ +-----+ +----| BS1|--+ | MS2| <、-(16)-+ +-----+ | +-----+ | +-----+ +--------+ +->| アルゴン|----| 縁| ISP+-----+ | +-----+ | ルータ+=>ネットワーク| MS3| <、-(16)-+ +-----+ | +--------+ +-----+ +----| BS2|--+ +-----+ | +-----+ | MS4| <、-(16)-+ +-----+
Figure 2: Shared IPv6 Prefix Link Model
図2: 共有されたIPv6接頭語リンクモデル
Shin, Ed., et al. Informational [Page 4] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[4ページ]のRFC5181IPv6
(2) Point-to-Point Link Model
(2)ポイントツーポイント接続モデル
This link model represents IEEE 802.16 mobile access network deployments where a subnet consists of only a single AR, BS, and MS. That is, each connection to a mobile node is treated as a single link. Each link between the MS and the AR is allocated a separate, unique prefix or a set of unique prefixes by the AR. The point-to- point link model follows the recommendations of [RFC3314].
サブネットが独身のAR、BS、およびMSだけから成るところにこのリンクモデルはIEEE802.16モバイルのアクセスネットワーク展開を表します。すなわち、モバイルノードとの各接続は単一のリンクとして扱われます。 MSとARとの各リンクはARによって別々の、そして、ユニークな接頭語かユニークな接頭語のセットに割り当てられます。 ポイントからポイントへのリンクモデルは[RFC3314]の推薦の後をつけます。
+-----+ +-----+ +-----+
| MS1 |<-(16)------| |---->| |
+-----+ | BS1 | | |
+-----+ | | | | +--------+
| MS2 |<-(16)------| |---->| |----| Edge | ISP
+-----+ +-----+ | | | Router +==>Network
| AR | +--------+
+-----+ +-----+ | |
| MS3 |<-(16)------| |---->| |
+-----+ | BS2 | | |
+-----+ | | | |
| MS4 |<-(16)------| |---->| |
+-----+ +-----+ +-----+
+-----+ +-----+ +-----+ | MS1| <、-(16)------| |、-、-、--、>|、| +-----+ | BS1| | | +-----+ | | | | +--------+ | MS2| <、-(16)------| |、-、-、--、>| |----| 縁| ISP+-----+ +-----+ | | | ルータ+=>ネットワーク| アルゴン| +--------+ +-----+ +-----+ | | | MS3| <、-(16)------| |、-、-、--、>|、| +-----+ | BS2| | | +-----+ | | | | | MS4| <、-(16)------| |、-、-、--、>|、| +-----+ +-----+ +-----+
Figure 3: Point-to-Point Link Model
図3: ポイントツーポイント接続モデル
2.2.1.1. IPv6-Related Infrastructure Changes
2.2.1.1. IPv6関連のインフラストラクチャ変化
IPv6 will be deployed in this scenario by upgrading the following devices to dual stack: MS, AR, and ER. In this scenario, IEEE 802.16 BSs have only MAC and PHY (Physical Layer) layers without router functionality and operate as a bridge. The BS should support IPv6 classifiers as specified in [IEEE802.16].
IPv6はこのシナリオで以下のデバイスをデュアルスタックにアップグレードさせることによって、配布されるでしょう: そして、MS、AR、えー。 このシナリオ、IEEE、802.16BSsがルータの機能性なしでMACとPHY(物理的なLayer)層しか持たないで、ブリッジとして作動します。 BSは指定されるとしての[IEEE802.16]のIPv6クラシファイアをサポートするはずです。
2.2.1.2. Addressing
2.2.1.2. アドレシング
An IPv6 MS has two possible options to get an IPv6 address. These options will be equally applied to the other scenario below (Section 2.2.2).
IPv6MSには、IPv6アドレスを得るために、2つの可能なオプションがあります。 これらのオプションは(セクション2.2.2)より下で等しくもう片方のシナリオに適用されるでしょう。
(1) An IPv6 MS can get the IPv6 address from an access router using stateless auto-configuration. In this case, router discovery and Duplicate Address Detection (DAD) operation should be properly operated over an IEEE 802.16 link.
(1) IPv6MSは、アクセスルータから状態がない自動構成を使用することでIPv6アドレスを得ることができます。 この場合、ルータ発見とDuplicate Address Detection(DAD)操作はIEEE802.16リンクの上に適切に操作されるべきです。
Shin, Ed., et al. Informational [Page 5] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[5ページ]のRFC5181IPv6
(2) An IPv6 MS can use Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to get an IPv6 address from the DHCPv6 server. In this case, the DHCPv6 server would be located in the service provider core network, and the AR should provide a DHCPv6 relay agent. This option is similar to what we do today in case of DHCPv4.
(2) IPv6(DHCPv6)がDHCPv6サーバからIPv6アドレスを得るのにIPv6MSはDynamic Host Configuration Protocolを使用できます。この場合DHCPv6サーバはサービスプロバイダーコアネットワークで位置しているでしょう、そして、ARはDHCPv6中継エージェントを提供するはずです。 このオプションは私たちが今日DHCPv4の場合にすることと同様です。
In this scenario, a router and multiple BSs form an IPv6 subnet, and a single prefix is allocated to all the attached MSs. All MSs attached to the same AR can be on the same IPv6 link.
このシナリオでは、ルータと複数のBSsがIPv6サブネットを形成します、そして、すべての付属MSsにただ一つの接頭語を割り当てます。 同じIPv6リンクの上に同じARに取り付けられたすべてのMSsがあることができます。
As for the prefix assignment, in the case of the shared IPv6 prefix link model, one or more IPv6 prefixes are assigned to the link and are hence shared by all the nodes that are attached to the link. In the point-to-point link model, the AR assigns a unique prefix or a set of unique prefixes for each MS. Prefix delegation can be required if networks exist behind an MS.
接頭語課題に関して、共有されたIPv6接頭語リンクモデルの場合では、1つ以上のIPv6接頭語が、リンクに割り当てられて、したがって、リンクに添付されるすべてのノードによって共有されます。 ポイントツーポイント接続モデルでは、ARはユニークな接頭語かユニークな接頭語のセットを各MSに割り当てます。ネットワークがMSの後ろに存在しているなら、接頭語委譲は必要とすることができます。
2.2.1.3. IPv6 Transport
2.2.1.3. IPv6輸送
In an IPv6 subnet, there are always two underlying links: one is the IEEE 802.16 wireless link between the MS and BS, and the other is a wired link between the BS and AR.
IPv6サブネットには、2個の基本的なリンクがいつもあります: 1つはMSとBSとのIEEE802.16のワイヤレスのリンクです、そして、もう片方がBSとARとのワイヤードなリンクです。
IPv6 packets can be sent and received via the IP-specific part of the packet convergence sublayer. The Packet CS is used for the transport of packet-based protocols, which include Ethernet and Internet Protocol (IPv4 and IPv6). Note that in this scenario, IPv6 CS may be more appropriate than Ethernet CS to transport IPv6 packets, since there is some overhead of Ethernet CS (e.g., Ethernet header) under mobile access environments. However, when PHS (Payload Header Suppression) is deployed, it mitigates this overhead through the compression of packet headers. The details of IPv6 operations over the IP-specific part of the packet CS are defined in [RFC5121].
パケット集合副層のIP特有の部分でIPv6パケットを送って、受け取ることができます。 Packet CSはパケットベースのプロトコルの輸送に使用されます。(プロトコルはイーサネットとインターネットプロトコル(IPv4とIPv6)を含んでいます)。 モバイルアクセス環境でIPv6 CSがそこ以来IPv6パケットを輸送するイーサネットCSがイーサネットCS(例えば、イーサネットヘッダー)の何らかのオーバーヘッドであるよりこのシナリオでは、適切であるかもしれないことに注意してください。 しかしながら、PHS(有効搭載量Header Suppression)が配布されるとき、それはパケットのヘッダーの圧縮でこのオーバーヘッドを緩和します。 パケットCSのIP特有の部分の上IPv6操作の詳細は[RFC5121]で定義されます。
Simple or complex network equipment may constitute the underlying wired network between the AR and the ER. If the IP-aware equipment between the AR and the ER does not support IPv6, the service providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 packets between the AR and the ER.
簡単であるか複雑なネットワーク装置はARとERの間の基本的な有線ネットワークを構成するかもしれません。 ARとERの間のIP意識している設備がIPv6をサポートしないなら、サービスプロバイダーは、ARとERの間のIPv6パケットを輸送するためにメカニズムにトンネルを堀りながら、IPv4のIPv6を配布することができます。
The service providers are deploying tunneling mechanisms to transport IPv6 over their existing IPv4 networks as well as deploying native IPv6 where possible. Native IPv6 should be preferred over tunneling mechanisms as native IPv6 deployment options might be more scalable and provide the required service performance. Tunneling mechanisms should only be used when native IPv6 deployment is not an option. This can be equally applied to other scenarios below (Section 2.2.2).
サービスプロバイダーは、それらの既存のIPv4ネットワークの上でIPv6を輸送するためにメカニズムにトンネルを堀って、可能であるところでネイティブのIPv6を配布しながら、展開しています。 固有のIPv6展開オプションが、よりスケーラブルであり、必要なサービス性能を提供するかもしれないとき、ネイティブのIPv6はトンネリングメカニズムより好まれるべきです。 ネイティブのIPv6展開がオプションでないときにだけ、トンネリングメカニズムは使用されるべきです。 (セクション2.2.2)より下で等しく他のシナリオにこれを適用できます。
Shin, Ed., et al. Informational [Page 6] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[6ページ]のRFC5181IPv6
2.2.1.4. Routing
2.2.1.4. ルート設定
In general, the MS is configured with a default route that points to the AR. Therefore, no routing protocols are needed on the MS. The MS just sends to the AR using the default route.
一般に、MSはARを示すデフォルトルートによって構成されます。 したがって、ルーティング・プロトコルは全くMSで必要ではありません。MSは、デフォルトルートを使用することでARにただ発信します。
The AR can configure multiple links to the ER for network reliability. The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740] or Intermediate System to Intermediate System (IS-IS) for IPv6 when connected to the ER with multiple links.
ARはネットワークの信頼性のためにERへの複数のリンクを構成できます。 ARが、IPv6ルーティングがOSPFv3[RFC2740]かIntermediate SystemなどのプロトコルであるとIntermediate Systemにサポートするはずである、(-、)、倍数でERに接続されるとIPv6がリンクするので。
The ER runs the Interior Gateway Protocol (IGP) such as OSPFv3 or IS-IS for IPv6 in the service provider network. The routing information of the ER can be redistributed to the AR. Prefix summarization should be done at the ER.
または、ERがOSPFv3などのInteriorゲートウェイプロトコル(IGP)を実行する、-、サービスプロバイダーネットワークにおけるIPv6のために。 ERのルーティング情報をARに再配付できます。 接頭語総括をERにするべきです。
2.2.1.5. Mobility
2.2.1.5. 移動性
There are two types of handovers for the IEEE 802.16e networks: link layer handover and IP layer handover. In a link layer handover, BSs involved in the handover reside in the same IP subnet. An MS only needs to reestablish a link layer connection with a new BS without changing its IP configuration, such as its IP address, default router, on-link prefix, etc. The link layer handover in IEEE 802.16e is by nature a hard handover since the MS has to cut off the connection with the current BS at the beginning of the handover process and cannot resume communication with the new BS until the handover completes [IEEE802.16e]. In an IP layer handover, the BSs involved reside in different IP subnets, or in different networks. Thus, in an IP layer handover, an MS needs to establish both a new link layer connection, as in a link layer handover, and a new IP configuration to maintain connectivity.
IEEE 802.16eネットワークのための2つのタイプの身柄の引き渡しがあります: リンクレイヤ引き渡しとIP層の引き渡しリンクレイヤ引き渡しでは、引き渡しにかかわるBSsは同じIPサブネットで住んでいます。 MSは、IP構成を変えないで新しいBSとのリンクレイヤ接続を回復させる必要があるだけです、IPアドレス、デフォルトルータ、リンクの上の接頭語などのように IEEE 802.16eのリンクレイヤ引き渡しは、業務引き継ぎ作業の始めに、MS以来の困難な引き渡しが現在のBSとの接続を解雇するために持っている自然であって、引き渡しが[IEEE802.16e]を完成するまで、新しいBSと共にコミュニケーションを再開できません。 IP層の引き渡しでは、かかわったBSsは異なったIPサブネット、または異なったネットワークで住んでいます。 したがって、IP層の引き渡し、両方を設立するMSの必要性では、新しいリンクは接続を層にします、リンクレイヤ引き渡し、および接続性を維持する新しいIP構成のように。
IP layer handover for MSs is handled by Mobile IPv6 [RFC3775]. Mobile IPv6 defines that movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bidirectionally reachable, in which case the mobile node must discover a new default router. Periodic Router Advertisements for reachability and movement detection may be unnecessary because the IEEE 802.16 MAC provides the reachability by its ranging procedure and the movement detection by the Handoff procedure.
MSsのためのIP層の引き渡しはモバイルIPv6[RFC3775]によって扱われます。 モバイルIPv6は検出がデフォルトルータがもう双方向に届いていないとき、検出するのにNeighbor Unreachability Detectionを使用するその動きを定義します、その場合、モバイルノードが新しいデフォルトルータを発見しなければなりません。 IEEE802.16MACがHandoff手順で及んでいる手順と動き検出で可到達性を提供するので、可到達性のための周期的なRouter Advertisementsと動き検出は不要であるかもしれません。
Mobile IPv6 alone will not solve the handover latency problem for the IEEE 802.16e networks. To reduce or eliminate packet loss and to reduce the handover delay in Mobile IPv6, therefore, Fast Handover for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with MIPv6. To perform predictive packet forwarding, the FMIPv6's IP layer assumes the presence of handover-related triggers delivered by
モバイルIPv6だけがIEEE 802.16eネットワークのための引き渡し潜在問題を解決しないでしょう。 パケット損失を抑えるか、または排除して、したがって、モバイルIPv6の引き渡し遅れを減少させるために、MIPv6と共にモバイルIPv6(FMIPv6)[RFC4068]のためのFast Handoverを配布することができます。 予言のパケット推進を実行するために、FMIPv6のIP層は、引き渡し関連の引き金の存在が配送したと仮定します。
Shin, Ed., et al. Informational [Page 7] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[7ページ]のRFC5181IPv6
the IEEE 802.16 MAC layers. Thus, there is a need for cross-layering design to support proper behavior of the FMIPv6 solution. This issue is also discussed in [MIPSHOP-FH80216E].
IEEE802.16MACは層にします。 したがって、十字を層にするデザインがFMIPv6ソリューションの適切な振舞いをサポートする必要があります。 また、[MIPSHOP-FH80216E]でこの問題について議論します。
Also, [IEEE802.16g] defines L2 triggers for link status such as link-up, link-down, and handoff-start. These L2 triggers may make the Mobile IPv6 or FMIPv6 procedure more efficient and faster.
また、[IEEE802.16g]は上にリンクするのや、下にリンクして、移管始めなどのリンク状態とL2引き金を定義します。 これらのL2引き金で、モバイルIPv6かFMIPv6手順が、より効率的でより速くなるかもしれません。
In addition, due to the problems caused by the existence of multiple convergence sublayers [RFC4840], the mobile access scenarios need solutions about how roaming will work when forced to move from one CS to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase, this issue is the out of scope of this document.
さらに、複数の集合副層[RFC4840]の存在によって引き起こされた問題のため、1CSから別のもの(例えば、イーサネットCSへのIPv6 CS)まで移行させられるとき、ローミングがどう働くかに関してモバイルアクセスシナリオはソリューションを必要とします。 この問題がこのフェーズにおいてそうであることに注意してください、このドキュメントの範囲から。
2.2.2. Fixed/Nomadic Deployment Scenarios
2.2.2. 修理されたか遊牧民的な展開シナリオ
The IEEE 802.16 access networks can provide plain Ethernet end-to-end connectivity. This scenario represents a deployment model using Ethernet CS. A wireless DSL deployment model is an example of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet service providers (wireless ISPs) have planned to use IEEE 802.16 for the purpose of high-quality broadband wireless services. A company can use IEEE 802.16 to build up a mobile office. Wireless Internet spreading through a campus or a cafe can also be implemented with it.
アクセスがネットワークでつなぐIEEE802.16はイーサネット終わりから終わりへの明瞭な接続性を提供できます。 このシナリオは、イーサネットCSを使用することで展開モデルの代理をします。 ワイヤレスのDSL展開モデルはIEEE802.16の修理されたか遊牧民的なIPv6展開に関する例です。 多くのワイヤレスのインターネット接続サービス業者(ワイヤレスのISP)が、高品質な広帯域の無線電信便の目的にIEEE802.16を使用するのを計画していました。 会社は、モバイルオフィスを確立するのにIEEE802.16を使用できます。 また、それでキャンパスかカフェを通って広まるワイヤレスのインターネットは実装することができます。
+-----+ +-----+ +-----+ ISP 1
| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network
+-----+ | | +-----+ +-----+
+-----+ | +-----+ |
| SS2 |<-(16)+-----| BS1 |--|
+-----+ +-----+ | +-----+ +-----+ ISP 2
+->| AR2 |----| ER2 |===>Network
+-----+ +-----+ +-----+ | +-----+ +-----+
|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
+-----+ +-----+ +-----+
This network
behind SS may exist
+-----+ +-----+ +-----+ ISP1| SS1| <、-(16)+ +->| AR1|----| ER1|===>ネットワーク+-----+ | | +-----+ +-----+ +-----+ | +-----+ | | SS2| <、-(16)+-----| BS1|--| +-----+ +-----+ | +-----+ +-----+ ISP2+>| AR2|----| ER2|===>ネットワーク+-----+ +-----+ +-----+ | +-----+ +-----+ |ホスト| <-->、|SS/GW| <、-(16)------| BS2|--+ +-----+ +-----+ +-----+ SSの後ろのこのネットワークは存在するかもしれません。
Figure 4: Fixed/Nomadic Deployment Scenario
図4: 修理されたか遊牧民的な展開シナリオ
This scenario also represents IEEE 802.16 network deployment where a subnet consists of multiple MSs and multiple interfaces of the multiple BSs. Multiple access routers can exist. There exist multiple hosts behind an SS (networks behind an SS may exist). When 802.16 access networks are widely deployed as in a Wireless Local Area Network (WLAN), this case should also be considered. The Hot- zone deployment model falls within this case.
また、サブネットが複数のBSsの複数のMSsと複数のインタフェースから成るところにこのシナリオはIEEE802.16ネットワーク展開を表します。 複数のアクセスルータが存在できます。 複数で、ホストはSSの後ろに存在します(SSの後ろのネットワークは存在するかもしれません)。 また、802.16のアクセスネットワークがWirelessローカル・エリア・ネットワーク(WLAN)のように広く配布されるとき、本件は考えられるべきです。 Hotゾーン展開モデルは本件の中に落ちます。
Shin, Ed., et al. Informational [Page 8] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[8ページ]のRFC5181IPv6
While Figure 4 illustrates a generic deployment scenario, the following, Figure 5, shows in more detail how an existing DSL ISP would integrate the 802.16 access network into its existing infrastructure.
図4はジェネリック展開シナリオを例証しますが、以下(図5)は既存のDSL ISPがさらに詳細にどう802.16アクセスネットワークを既存のインフラストラクチャと統合するだろうかを示しています。
+-----+ +---+ +-----+ +-----+ ISP 1
| SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network
+-----+ | | b| | +-----+ +-----+
+-----+ | +-----+ |E r| |
| SS2 |<-(16)+-----| BS1 |-----|t i| |
+-----+ +-----+ |h d|--+
| g| | +-----+ +-----+ ISP 2
+-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network
| SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+
+-----+ +-----+ +---+ |
|
+-----+ +-----+ |
| TE |<-(DSL)-----|DSLAM|------------+
+-----+ +-----+
+-----+ +---+ +-----+ +-----+ ISP1| SS1| <、-(16)+ | | +-->|ブラ|----| ER1|===>ネットワーク+-----+ | | b| | +-----+ +-----+ +-----+ | +-----+ |E r| | | SS2| <、-(16)+-----| BS1|-----|t i| | +-----+ +-----+ |h d|--+ | g| | +-----+ +-----+ ISP2+-----+ +-----+ | e| +-->|ブラ|----| ER2|===>ネットワーク| SS3| <、-(16)------| BS2|-----| | | +-----+ +-----+ +-----+ +-----+ +---+ | | +-----+ +-----+ | | Te| <、-(DSL)-----|DSLAM|------------+ +-----+ +-----+
Figure 5: Integration of 802.16 Access into the DSL Infrastructure
図5: DSLインフラストラクチャへの802.16アクセスの統合
In this approach, the 802.16 BS is acting as a DSLAM (Digital Subscriber Line Access Multiplexer). On the network side, the BS is connected to an Ethernet bridge, which can be separate equipment or integrated into the BRAS (Broadband Remote Access Server).
このアプローチでは、802.16BSがDSLAM(デジタルSubscriber線Access Multiplexer)として機能しています。 ネットワーク側では、BSはイーサネットブリッジに接続されるか、またはBRAS(ブロードバンドRemote Access Server)と統合されます。(ブリッジは別々の設備であるかもしれません)。
2.2.2.1. IPv6-Related Infrastructure Changes
2.2.2.1. IPv6関連のインフラストラクチャ変化
IPv6 will be deployed in this scenario by upgrading the following devices to dual stack: MS, AR, ER, and the Ethernet bridge. The BS should support IPv6 classifiers as specified in [IEEE802.16].
IPv6はこのシナリオで以下のデバイスをデュアルスタックにアップグレードさせることによって、配布されるでしょう: MS、AR、ER、およびイーサネットはブリッジします。 BSは指定されるとしての[IEEE802.16]のIPv6クラシファイアをサポートするはずです。
The BRAS in Figure 5 is providing the functionality of the AR. An Ethernet bridge is necessary for protecting the BRAS from 802.16 link layer peculiarities. The Ethernet bridge relays all traffic received through the BS to its network side port(s) connected to the BRAS. Any traffic received from the BRAS is relayed to the appropriate BS. Since the 802.16 MAC layer has no native support for multicast (and broadcast) in the uplink direction, the Ethernet bridge will implement multicast (and broadcast) by relaying the multicast frame received from the MS to all of its ports. The Ethernet bridge may also provide some IPv6-specific functions to increase link efficiency of the 802.16 radio link (see Section 2.2.2.3).
図5のBRASはARの機能性を提供しています。 イーサネットブリッジが802.16のリンクレイヤのユニークさからBRASを保護するのに必要です。 すべてのトラフィックがBSを通してネットワークサイドポートに受けたイーサネットブリッジリレーはBRASに接続しました。 BRASから受け取られたどんなトラフィックも適切なBSにリレーされます。 802.16MAC層がマルチキャスト(放送する)のどんなネイティブのサポートもアップリンク方向に持っていないので、イーサネットブリッジはMSからポートのすべてまで受け取られたマルチキャストフレームをリレーすることによって、マルチキャスト(放送する)を実装するでしょう。 セクション2.2を見てください。また、イーサネットブリッジが802.16ラジオリンクのリンク効率を増強するためにいくつかのIPv6-具体的な機能を提供するかもしれない、(.2 .3)。
Shin, Ed., et al. Informational [Page 9] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[9ページ]のRFC5181IPv6
2.2.2.2. Addressing
2.2.2.2. アドレシング
One or more IPv6 prefixes can be shared to all the attached MSs. Prefix delegation can be required if networks exist behind the SS.
すべての付属MSsと1つ以上のIPv6接頭語を共有できます。 ネットワークがSSの後ろに存在しているなら、接頭語委譲を必要とすることができます。
2.2.2.3. IPv6 Transport
2.2.2.3. IPv6輸送
Transmission of IPv6 over Ethernet CS follows [RFC2464] and does not introduce any changes to [RFC4861] and [RFC4862]. However, there are a few considerations in the viewpoint of operation, such as preventing periodic router advertisement messages from an access router and broadcast transmission, deciding path MTU size, and so on. The details about the considerations are described in [IP-ETHERNET].
イーサネットCSの上のIPv6のトランスミッションは、[RFC2464]に続いて、[RFC4861]と[RFC4862]に少しの変化も紹介しません。 しかしながら、操作の観点にはいくつかの問題があります、アクセスルータと放送送信から周期的なルータ通知メッセージを防ぐのなどように、経路MTUサイズなどについて決めて。 問題に関する詳細は[IP-イーサネット]で説明されます。
2.2.2.4. Routing
2.2.2.4. ルート設定
In this scenario, IPv6 multi-homing considerations exist. For example, if there exist two routers to support MSs, a default router must be selected.
このシナリオでは、IPv6マルチホーミング問題は存在しています。 例えば、2つのルータがMSsをサポートするために存在しているなら、デフォルトルータを選択しなければなりません。
The Edge Router runs the IGP used in the SP network such as OSPFv3 [RFC2740] or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router.
または、Edge RouterがOSPFv3[RFC2740]などのSPネットワークに使用されるIGPを実行する、-、IPv6のために。 接続接頭語を再配付しなければなりません。 接頭語総括をEdge Routerにするべきです。
2.2.2.5. Mobility
2.2.2.5. 移動性
No mobility functions of Layer 2 and Layer 3 are supported in the fixed access scenario. Like WLAN technology, however, nomadicity can be supported in the radio coverage without any mobility protocol. So, a user can access Internet nomadically in the coverage.
Layer2とLayer3の移動性機能は全く固定アクセスシナリオでサポートされません。 しかしながら、WLAN技術のように、ラジオ適用範囲で少しも移動性プロトコルなしでnomadicityをサポートすることができます。 それで、ユーザは適用範囲でインターネットに遊動民族的にアクセスできます。
Sometimes, service users can demand IP session continuity or home address reusability even in the nomadic environment. In that case, Mobile IPv6 [RFC3775] may be used in this scenario even in the absence of Layer 2's mobility support.
時々、サービス利用者は遊牧民的な環境さえにおけるIPセッションの連続かホームアドレスリユーザビリティを要求できます。 その場合、モバイルIPv6[RFC3775]はLayer2の移動性サポートがないときでさえこのシナリオで使用されるかもしれません。
2.3. IPv6 Multicast
2.3. IPv6マルチキャスト
[IP-ETHERNET] realizes IPv6 multicast support by Internet Group Management Protocol/Multicast Listener Discovery (IGMP/MLD) proxying [RFC4605] and IGMP/MLD snooping [RFC4541]. Additionally, it may be possible to efficiently implement multicast packet transmission among the multicast subscribers by means of IEEE 802.16 Multicast CIDs. However, such a protocol is not yet available and under development in WiMAX Forum.
[IP-イーサネット]は、[RFC4605]とIGMP/MLD詮索[RFC4541]をproxyingしながら、インターネットGroup Managementプロトコル/マルチキャストListenerディスカバリー(IGMP/MLD)によるIPv6マルチキャストサポートがわかります。 さらに、IEEE802.16によってマルチキャスト加入者の中で効率的にマルチキャストパケット伝送を実装するのは可能であるかもしれません。Multicast CIDs。 しかしながら、そのようなプロトコルは、WiMAX Forumでまだ利用可能であって、開発中ではありません。
Shin, Ed., et al. Informational [Page 10] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[10ページ]のRFC5181IPv6
2.4. IPv6 QoS
2.4. IPv6 QoS
In IEEE 802.16 networks, a connection is unidirectional and has a Quality of Service (QoS) specification. Each connection is associated with a single data service flow, and each service flow is associated with a set of QoS parameters in [IEEE802.16]. The QoS- related parameters are managed using the Dynamic Service Addition (DSA) and Dynamic Service Change (DSC) MAC management messages specified in [IEEE802.16]. The [IEEE802.16] provides QoS differentiation for the different types of applications by five scheduling services. Four scheduling services are defined in 802.16: Unsolicited Grant Service (UGS), real-time Polling Service (rtPS), non-real-time Polling Service (nrtPS), and Best Effort (BE). A fifth scheduling service is Extended Real-time Polling Service (ertPS), defined in [IEEE802.16e]. It is required to define IP layer quality of service mapping to MAC layer QoS types [IEEE802.16], [IEEE802.16e].
IEEE802.16では、ネットワークであり、接続は、単方向であり、Service(QoS)仕様のQualityを持っています。 それぞれの接続はただ一つのデータサービス流動に関連しています、そして、それぞれのサービス流動は[IEEE802.16]の1セットのQoSパラメタに関連しています。 QoS関係パラメータは、[IEEE802.16]で指定されたDynamic Service Addition(DSA)とDynamic Service Change(DSC)MAC管理メッセージを使用することで管理されます。 [IEEE802.16]は5つのスケジューリングサービスで異なったタイプのアプリケーションのための分化をQoSに供給します。 4つのスケジューリングサービスが802.16で定義されます: 求められていないグラントService(UGS)、リアルタイムのPolling Service(rtPS)、非リアルタイムのPolling Service(nrtPS)、およびBest Effort(あります)。 5番目のスケジューリングサービスは[IEEE802.16e]で定義されたExtendedレアル-時間Polling Service(ertPS)です。 [IEEE802.16e]、それが、層のQoSタイプ[IEEE802.16]をMACに写像するIP層のサービスの質を定義するのに必要です。
2.5. IPv6 Security
2.5. IPv6セキュリティ
When initiating the connection, an MS is authenticated by the Authentication, Authorization, and Accounting (AAA) server located at its service provider network. To achieve that, the MS and the BS use Privacy Key Management [IEEE802.16],[IEEE802.16e], while the BS communicates with the AAA server using a AAA protocol. Once the MS is authenticated with the AAA server, it can associate successfully with the BS and acquire an IPv6 address through stateless auto- configuration or DHCPv6. Note that the initiation and authentication process is the same as the one used in IPv4.
接続を開始するとき、MSはAuthentication、Authorization、およびサービスプロバイダーネットワークに位置するAccounting(AAA)サーバによって認証されます。 それ、MS、およびBSを達成するのに、Privacy Key Management[IEEE802.16]を使用してください、[IEEE802.16e]、BSはAAAプロトコルを使用することでAAAサーバとコミュニケートしますが。 MSがAAAサーバでいったん認証されると、それは、状態がない自動構成かDHCPv6を通して首尾よくBSと交際して、IPv6アドレスを習得できます。 開始と認証が処理されるというメモはIPv4で使用されるものと同じです。
2.6. IPv6 Network Management
2.6. IPv6ネットワークマネージメント
[IEEE802.16f] includes the management information base for IEEE 802.16 networks. For IPv6 network management, the necessary instrumentation (such as MIBs, NetFlow Records, etc.) should be available.
[IEEE802.16f]はIEEE802.16ネットワークのための管理情報ベースを含んでいます。 IPv6ネットワークマネージメントに、必要な計装(MIBs、NetFlow Recordsなどの)は利用可能であるべきです。
Upon entering the network, an MS is assigned three management connections in each direction. These three connections reflect the three different QoS requirements used by different management levels. The first of these is the basic connection, which is used for the transfer of short, time-critical MAC management messages and radio link control (RLC) messages. The primary management connection is used to transfer longer, more delay-tolerant messages such as those used for authentication and connection setup. The secondary management connection is used for the transfer of standards-based
ネットワークに入ると、MSは各方向との3つの管理接続に割り当てられます。 これらの3つの接続が異なった管理者の各レベルによって使用される3つの異なったQoS要件を反映します。 これらの1番目は基本接続です。(その基本接続は短くて、時間重要なMAC管理メッセージとラジオリンクコントロール(RLC)メッセージの転送に使用されます)。 プライマリ管理接続は、より長い間移すのに使用されます、認証と接続設定に使用されるものなどの、より遅れ許容性があるメッセージ。 セカンダリ管理接続は規格ベースの転送に使用されます。
Shin, Ed., et al. Informational [Page 11] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[11ページ]のRFC5181IPv6
management messages such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network Management Protocol (SNMP).
Dynamic Host Configuration Protocol(DHCP)や、トリビアル・ファイル転送プロトコル(TFTP)や、Simple Network Managementプロトコル(SNMP)などの管理メッセージ。
IPv6-based IEEE 802.16 networks can be managed by IPv4 or IPv6 when network elements are implemented dual stack. SNMP messages can be carried by either IPv4 or IPv6.
IPv6ベースのIEEE、ネットワーク要素がデュアルスタックであると実装されるとき、IPv4かIPv6が802.16のネットワークを経営できます。 IPv4かIPv6のどちらかによってSNMPメッセージを伝えられることができます。
3. Security Considerations
3. セキュリティ問題
This document provides a detailed description of various IPv6 deployment scenarios and link models for IEEE 802.16-based networks, and as such does not introduce any new security threats. No matter what the scenario applied is, the networks should employ the same link layer security mechanisms defined in [IEEE802.16e] and IPv6 transition security considerations defined in [RFC4942]. However, as already described in [RFC4968], a shared prefix model-based mobile access deployment scenario may have security implications for protocols that are designed to work within the scope. This is the concern for a shared prefix link model wherein private resources cannot be put onto a public 802.16-based network. This may restrict the usage of a shared prefix model to enterprise environments.
このドキュメントは、様々なIPv6展開シナリオとリンクモデルの詳述をIEEEの802.16を拠点とするネットワークに提供して、そういうものとして少しの新しい軍事的脅威も紹介しません。 適用されたシナリオが何であっても、ネットワークは[IEEE802.16e]で定義された同じリンクレイヤセキュリティー対策と[RFC4942]で定義されたIPv6変遷セキュリティ問題を使うべきです。 しかしながら、既に説明されるように、[RFC4968]、モデルベースのモバイルアクセス展開シナリオがそうする共有された接頭語では、範囲の中で働くように設計されているプロトコルのためのセキュリティ意味を持ってください。 これは公立の802.16を拠点とするネットワークに個人的なリソースを置くことができない共有された接頭語リンクモデルに関する心配です。 これは共有された接頭語モデルの使用法を企業環境に制限するかもしれません。
4. Acknowledgements
4. 承認
This work extends v6ops work on [RFC4779]. We thank all the authors of the document. Special thanks are due to Maximilian Riegel, Jonne Soininen, Brian E. Carpenter, Jim Bound, David Johnston, Basavaraj Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin Jeong, and Jinhyeock Choi for extensive review of this document. We acknowledge Dominik Kaspar for proofreading the document.
この仕事は[RFC4779]に対するv6ops仕事を広げています。 私たちはドキュメントのすべての作者に感謝します。 特別な感謝はこのドキュメントの大量のレビューのためのマクシミリアン・リーゲル、Jonne Soininen、ブライアンE.Carpenter、ジムBound、デヴィッド・ジョンストン、Basavarajパティル、Byoung-ジョウ・キム、エリッククライン、ブルーノ・スーザ、ユング-Mo月、Sangjin Jeong、およびJinhyeockチェのためです。 私たちは、ドキュメントを校正するためにドミニク・カスパーを承認します。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[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月。
Shin, Ed., et al. Informational [Page 12] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[12ページ]のRFC5181IPv6
5.2. Informative References
5.2. 有益な参照
[IEEE802.16] "IEEE 802.16-2004, IEEE Standard for Local and
Metropolitan Area Networks, Part 16: Air
Interface for Fixed Broadband Wireless Access
Systems", October 2004.
[IEEE802.16] 「IEEE802.16-2004(地方とメトロポリタンエリアネットワークのIEEE規格)は16を分けます」。 2004年10月の「固定広帯域のワイヤレス・アクセスシステムのための空気インタフェース。」
[IEEE802.16e] "IEEE Standard for Local and Metropolitan Area
Networks Part 16: Air Interface for Fixed and
Mobile Broadband Wireless Access Systems
Amendment 2: Physical and Medium Access Control
Layers for Combined Fixed and Mobile Operation in
Licensed Bands and Corrigendum 1", February 2006.
[IEEE802.16e] 「地方とメトロポリタンエリアネットワークにおける、標準のIEEEは16を分けます」。 空気は修理されてモバイルの広帯域のワイヤレス・アクセスシステムのために修正2を連結します: 物理的で中型のアクセスコントロールは1インチと、2006年2月に認可されたバンドと間違いにおける結合した修理されてモバイルの操作のために層にされます。
[IEEE802.16f] "Amendment to IEEE Standard for Local and
Metropolitan Area Networks, Part 16: Air
Interface for Fixed Broadband Wireless Access
Systems - Management Information Base",
December 2005.
[IEEE802.16f]、「地方とメトロポリタンエリアネットワークのIEEE規格の修正、パート16:」 2005年12月に「固定広帯域のワイヤレスのための空気インタフェースはシステム--管理情報ベースにアクセスします」。
[IEEE802.16g] "Draft Amendment to IEEE Standard for Local and
Metropolitan Area Networks, Part 16: Air
Interface for Fixed Broadband Wireless Access
Systems - Management Plane Procedures and
Services", January 2007.
[IEEE802.16g]、「地方とメトロポリタンエリアネットワークのIEEE規格への修正案、パート16:」 「固定広帯域のワイヤレス・アクセスシステムのためにインタフェースを放送してください--経営者側は手順とサービスを平らにする」2007年1月。
[IP-ETHERNET] Jeon, H., Riegel, M., and S. Jeong, "Transmission
of IP over Ethernet over IEEE 802.16 Networks",
Work in Progress, April 2008.
H.、リーゲル、M.、およびS.Jeong、「IEEE802.16ネットワークの上のイーサネットの上のIPのトランスミッション」という[IP-イーサネット]Jeonは進行中(2008年4月)で働いています。
[MIPSHOP-FH80216E] Jang, H., Jee, J., Han, Y., Park, S., and J. Cha,
"Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", Work in Progress, March 2008.
[MIPSHOP-FH80216E]Jang、H.、Jee、J.、ハン、Y.は駐車します、S.、「IEEE 802.16eネットワークの上のモバイルIPv6速い身柄の引き渡し」というJ.Chaは進行中(2008年3月)で働いています。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
IPv6", RFC 2740, December 1999.
[RFC2740] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、2002年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
Shin, Ed., et al. Informational [Page 13] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[13ページ]のRFC5181IPv6
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6",
RFC 4068, July 2005.
[RFC4068]Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery
(MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541] クリステンセン、M.、キンボール、K.、およびF.Solensky、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、2006年5月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) /
Multicast Listener Discovery (MLD)-Based
Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006.
[RFC4605] フェナー、B.、彼、H.、ハーバーマン、B.、およびH.Sandick、「インターネット集団経営は(IGMP)/マルチキャストのリスナーの発見の(MLD)ベースのマルチキャスト推進("IGMP/MLD Proxying")について議定書の中で述べます」、RFC4605、2006年8月。
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola,
P., and J. Palet, "ISP IPv6 Deployment Scenarios
in Broadband Access Networks", RFC 4779,
January 2007.
[RFC4779] Asadullah、S.、アフマド、A.、Popoviciu、C.、Savola、P.、およびJ.殻、「広帯域アクセスネットワークにおけるISP IPv6展開シナリオ」、RFC4779(2007年1月)。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
Encapsulation Methods Considered Harmful",
RFC 4840, April 2007.
2007年4月の[RFC4840]AbobaとB.とデイヴィース、E.とD.ターレル、「有害であると考えられた複数のカプセル化メソッド」RFC4840。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
Transition/Co-existence Security Considerations",
RFC 4942, September 2007.
[RFC4942] デイヴィースとE.とクリシュナン、S.とP.Savola、「IPv6変遷/共存セキュリティ問題」、RFC4942、2007年9月。
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models
for 802.16 Based Networks", RFC 4968,
August 2007.
[RFC4968]Madanapalli、S.、「802.16のためのIPv6リンクモデルの分析はネットワークを基礎づけた」RFC4968、2007年8月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and
S. Madanapalli, "Transmission of IPv6 via the
IPv6 Convergence Sublayer over IEEE 802.16
Networks", RFC 5121, February 2008.
[RFC5121]パティルとB.とシャーとF.とSarikayaとB.、チェ(JH)とS.Madanapalli、「IEEE802.16Networksの上のIPv6 Convergence Sublayerを通したIPv6のトランスミッション」RFC5121(2008年2月)。
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over
IEEE 802.16 Problem Statement and Goals",
RFC 5154, April 2008.
[RFC5154] Jee、J.、Madanapalli、S.、およびJ.Mandin、「IEEE802.16問題声明と目標の上のIP」、RFC5154、2008年4月。
Shin, Ed., et al. Informational [Page 14] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[14ページ]のRFC5181IPv6
Authors' Addresses
作者のアドレス
Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea
ミュング-気向こうずねのETRI161Gajeong-ドングYuseng-gu305-350大田(韓国)
Phone: +82 42 860 4847 EMail: myungki.shin@gmail.com
以下に電話をしてください。 +82 42 860 4847はメールされます: myungki.shin@gmail.com
Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea
Youn-ヒーハンKUT Gajeon-Ri307Byeongcheon-Myeonチョナン-Si Chungnam330-708州(韓国)
EMail: yhhan@kut.ac.kr
メール: yhhan@kut.ac.kr
Sang-Eon Kim KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-791 Korea
累代を歌っているキムKT17Woomyeon-ドング、Seocho-gu137-791ソウル(韓国)
EMail: sekim@kt.com
メール: sekim@kt.com
Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia
Domagoj PremecのジーメンスのモバイルHeinzelova 70a10010ザグレブクロアチア
EMail: domagoj.premec@siemens.com
メール: domagoj.premec@siemens.com
Shin, Ed., et al. Informational [Page 15] RFC 5181 IPv6 over IEEE 802.16 Scenarios May 2008
エド、よじ登ってください、他 IEEE802.16シナリオ2008年5月の上の情報[15ページ]のRFC5181IPv6
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に情報を扱ってください。
Shin, Ed., et al. Informational [Page 16]
エド、よじ登ってください、他 情報[16ページ]
一覧
スポンサーリンク
