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
IPv6 Deployment Scenarios in 802.16 Networks
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のIEEE 802.16アクセスネットワークとIPv4 IEEEから、その違い802.16ネットワークの主要コンポーネントについて説明し、どのようにIPv6が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
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.
IEEE 802.16アクセスネットワークの展開が進むにつれて、ユーザーがIPv6ネットワークに接続されます。 IEEE 802.16規格は、IEEE 802.16メディアアクセス制御（MAC）ペイロード内のIPv4 / IPv6データグラムのカプセル化を定義しながら、のIPv4 / IPv6の動作および展開の完全な記述は存在しません。 IEEE 802.16規格は、L1とL2に限定されるので、それらはIPネットワークアーキテクチャとシナリオの任意の数内で使用することができます。この文書では、我々はIPv6のIEEE 802.16アクセスネットワークとIPv4 IEEEから、その違い802.16ネットワークの主要コンポーネントについて説明し、どのようにIPv6がIEEE 802.16技術のそれぞれに展開し、統合されています。
This document extends the work of [RFC4779] and follows the structure and common terminology of that document.
このドキュメントは[RFC4779]の作業を拡張し、構造とその文書の共通の用語に従います。
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は、移動加入者局（MS）は[IEEE802.16e規格]に導入表します。
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）：SS（MS）とBSの802.16 MACにおける等価なピアへの接続を特定する16ビット値。
o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS-specific part of the Packet CS defined in 802.16 STD.
OイーサネットCS（収束サブレイヤ）：802.16 STDで定義されたパケットCSの802.3 /イーサネットCS特異的部分。
o IPv6 CS (Convergence Sublayer): IPv6-specific subpart of the Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.
O IPv6のCS（収束サブレイヤ）：802.16 STDで定義されたパケットCS、分類2（パケットはIPv6）のIPv6固有サブパート。
[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を輸送する能力を指定します。 IEEE 802.16上のIPv6（とIPv4）の詳細動作を、16ngのWGで定義されています。 IPv6のIPv6を介しCSの定義は、すでに承認された仕様[RFC5121]です。 IEEE 802.16でイーサネットCSオーバーIPは、[IP-ETHERNET]で定義されています。
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|
+------+
Figure 1: Key Elements of IEEE 802.16(e) Networks
図1：IEEE 802.16（e）のネットワークの重要な要素
[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.
ポイント・ツー・マルチポイント（PMP）とメッシュ（オプション）：IEEE802.16無線媒体を共有するための2つのモードを指定します。この文書では、唯一の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 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.
固定とモバイルアクセスの展開シナリオ：二つの異なる展開シナリオがあります。固定アクセスシナリオは、デジタル加入者線（xDSL）、ケーブルネットワークなどの既存の有線ベースのアクセス技術に代わります。この固定アクセスシナリオは、ホットゾーンモデルと呼ばれているラジオカバレッジ内の遊牧民のアクセスを提供することができます。モバイルアクセスシナリオは、モバイルネットワーク上で音声、データ、およびビデオを伝送する新しいパラダイムのために存在します。このシナリオでは、セルラーシステムと同等のワイヤベースのインターネットと同等の高速データ速度ならびにモビリティ機能を提供することができます。固定とモバイルアクセスの展開シナリオの間などの収束サブレイヤタイプ、リンクモデル、アドレッシング、モビリティ、上の異なるIPv6の影響があります。詳細は後述します。モバイルアクセスのシナリオは、二つの異なるIPv6リンクモデルに分類することができます：IPv6のプレフィックスリンクモデルとポイントツーポイントリンクモデルを共有しました。
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.
IEEE 802.11は異なり、IEEE 802.16 BSは、モビリティ機能と固定通信を提供することができます。 [IEEE802.16e規格] IEEE 802.16環境でモビリティ機能を提供するために、標準化されています。 IEEE 802.16 BSは、オペレータによって管理される独自のバックエンドで展開される可能性があります。
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.
共有IPv6プレフィックスのリンクモデルとポイントツーポイントリンクモデル[RFC4968]：モバイルアクセス展開シナリオのための2つの可能なIPv6のリンクモデルがあります。シナリオのデフォルトのアクセスルータは常にあります。 MS（MS背後にあるネットワークが存在していてもよい）の背後にある複数のホストが存在することができます。モバイルアクセス展開モデル、モバイルWiMAXとワイブロは、この展開モデルに収まります。
(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インタフェースと複数のMSから構成IEEE 802.16モバイルアクセスネットワークの展開を表します。 IPv6プレフィックスは、ARのインタフェースとは異なるであろう。図2に示すように、したがって、すべてのMSと対応ARインタフェースは、同一のIPv6プレフィックスを共有します。
+-----+
| MS1 |<-(16)-+
+-----+ | +-----+
+-----+ +----| BS1 |--+
| MS2 |<-(16)-+ +-----+ |
+-----+ | +-----+ +--------+
+->| AR |----| Edge | ISP
+-----+ | +-----+ | Router +==>Network
| MS3 |<-(16)-+ +-----+ | +--------+
+-----+ +----| BS2 |--+
+-----+ | +-----+
| MS4 |<-(16)-+
+-----+
Figure 2: Shared IPv6 Prefix Link Model
図2：共有のIPv6プレフィックスリンクモデル
(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から構成IEEE 802.16モバイルアクセスネットワークの展開を表します。つまり、モバイルノードへの各接続は、単一のリンクとして扱われます。 MSとARとの間の各リンクは、別個の、固有のプレフィックスまたはARによって一意プレフィックスの集合を割り当てられます。ポイントツーポイントリンクモデルは、[RFC3314]の推奨に従います。
+-----+ +-----+ +-----+
| MS1 |<-(16)------| |---->| |
+-----+ | BS1 | | |
+-----+ | | | | +--------+
| MS2 |<-(16)------| |---->| |----| Edge | ISP
+-----+ +-----+ | | | Router +==>Network
| AR | +--------+
+-----+ +-----+ | |
| MS3 |<-(16)------| |---->| |
+-----+ | BS2 | | |
+-----+ | | | |
| MS4 |<-(16)------| |---->| |
+-----+ +-----+ +-----+
Figure 3: Point-to-Point Link Model
図3：ポイントツーポイントリンクモデル
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].
MS、AR、およびER：IPv6のデュアルスタックに次のデバイスをアップグレードすることによって、このシナリオで展開されます。このシナリオでは、IEEE 802.16のBSは、ルータ機能なしのみMACおよびPHY（物理層）の層を有し、ブリッジとして動作します。 [IEEE802.16]で指定されるように、BSは、IPv6分類をサポートしなければなりません。
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).
IPv6のMSは、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）アンIPv6のMSは、ステートレス自動構成を使用して、アクセスルータからIPv6アドレスを取得することができます。この場合、ルータの発見と重複アドレス検出（DAD）操作が正常にIEEE 802.16リンク上で動作させる必要があります。
(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のMSは、DHCPv6サーバからIPv6アドレスを取得するために、IPv6の動的ホスト構成プロトコル（DHCPv6の）を使用することができます。この場合、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.
このシナリオでは、ルータと複数のBSは、IPv6サブネットを形成し、単一のプレフィックスが接続されているすべてのMSに割り当てられます。同じARに接続されているすべてのMSが同じIPv6リンク上に存在することができます。
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プレフィックスリンクモデルの場合には、一の以上のIPv6プレフィックスがリンクに割り当てられ、したがって、リンクに接続されているすべてのノードによって共有されます。ポイントツーポイントリンクモデルでは、ARは、一意のプレフィックスまたは各MSのためのユニークなプレフィクスのセットを割り当てます。ネットワークはMSの後ろに存在する場合はプレフィックス委任が必要になることができます。
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.
一方はMSとBSとの間のIEEE 802.16無線リンクであり、他方はBSとARとの間の有線リンクである：IPv6サブネットでは、常に2つの根本的なリンクがあります。
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].
IPv6パケットは、パケット収束サブレイヤのIP固有部分を介して送受信することができます。パケットCSは、イーサネット、インターネットプロトコル（IPv4とIPv6）を含むパケットベースのプロトコルを搬送するために使用されます。イーサネットCS（例えば、イーサネットヘッダ）のいくつかのオーバーヘッドがあるので、このシナリオでは、IPv6のCSは、モバイルアクセス環境の下で、IPv6パケットを転送するためにイーサネット（登録商標）CSより適切であるかもしれないことに留意されたいです。 PHS（ペイロードヘッダー抑制）が配備されている場合しかし、それは、パケットヘッダの圧縮により、このオーバーヘッドを軽減します。パケット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パケットを転送するためのIPv6インのIPv4トンネリングメカニズムを展開することができます。
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）以下の他のシナリオにも同様に適用することができます。
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への複数のリンクを設定することができます。複数のリンクを持つERに接続されたときにARは、IPv6のための中間システム（IS-IS）へのOSPFv3 [RFC2740]、または中間システムとして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のようインテリアゲートウェイプロトコル（IGP）などを実行したり、サービスプロバイダーネットワークでIPv6のIS-IS。 ERのルーティング情報は、ARに再配布することができます。プレフィックス集約はERで行うべきです。
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.
リンク層ハンドオーバとIP層ハンドオーバ：IEEE 802.16eのネットワークのためのハンドオーバの2種類があります。リンク層ハンドオーバでは、ハンドオーバに関与する基地局は、同じIPサブネットに存在します。 MSは唯一のIEEE 802.16eの中に、リンク層ハンドオーバが自然にハードハンドオーバであるなど、そのIPアドレス、デフォルトルータ、オンリンク接頭辞として、そのIPの設定を変更することなく、新しいBSとのリンク層接続を再確立する必要がありますMSは、ハンドオーバプロセスの開始時に現在のBSとの接続を切断しなければならないとハンドオーバ[IEEE802.16e規格】完了するまで新しいBSとの通信を再開することができないからです。 IP層ハンドオーバでは、関与するBSが異なる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.
MSに対してIP層ハンドオーバはモバイルIPv6 [RFC3775]によって処理されます。モバイルIPv6は、移動検出がデフォルトルータは、モバイルノードが新しいデフォルトルータを検出する必要があり、その場合、もはや双方向到達可能であるときを検出しないように近隣非検出を使用することを規定しています。 IEEE 802.16 MACは、そのレンジング手順およびハンドオフ手順によって動き検出によって到達可能性を提供するので、到達可能性および移動検出のための周期的ルータ広告は不要であってもよいです。
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 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].
モバイルIPv6だけではIEEE 802.16eのネットワークのためのハンドオーバ待ち時間の問題を解決することはできません。低減またはパケット損失を排除し、モバイルIPv6におけるハンドオーバ遅延を低減するために、したがって、モバイルIPv6（FMIPv6と）[RFC4068]のための高速ハンドオーバのMIPv6と一緒に展開することができます。予測パケット転送を実行するために、FMIPv6とのIP層は、IEEE 802.16のMAC層によって送達ハンドオーバ関連トリガーの存在を前提としています。このように、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]の存在によって引き起こされる問題に、モバイル・アクセス・シナリオは、別の（例えば、イーサネット（登録商標）CSへのIPv6 CS）1つのCSから移動させたときにローミングが機能する方法についてのソリューションを必要とします。この段階では、この問題は、この文書の範囲外である、ということに注意してください。
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.
IEEE 802.16アクセスネットワークは、プレーン、イーサネット、エンドツーエンドの接続性を提供することができます。このシナリオでは、イーサネットCSを使用して展開モデルを表しています。無線DSL配置モデルは、IEEE 802.16の固定/ノマディックIPv6展開の一例です。多くの無線インターネット・サービス・プロバイダ（ワイヤレスISP）は、高品質なブロードバンド・ワイヤレス・サービスの目的のためにIEEE 802.16を使用することを計画しています。同社は、モバイルオフィスを構築するためにIEEE 802.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
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.
このシナリオはまた、サブネットが複数のMSと複数のBSの複数のインターフェースで構成されIEEE 802.16ネットワークの展開を表します。複数のアクセスルータが存在することができます。 SSの後ろの複数のホストが存在する（SSの後ろのネットワークが存在していてもよいです）。 802.16アクセスネットワークが広くワイヤレスローカルエリアネットワーク（WLAN）のように展開されている場合は、この場合も考慮すべきです。ホットゾーンの展開モデルは、このケースに収まります。
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|------------+
+-----+ +-----+
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.16 BSは、DSLAM（デジタル加入者線アクセスマルチプレクサ）として機能しています。ネットワーク側では、BSは、別個の装置又はBRAS（ブロードバンドリモートアクセスサーバ）に統合することができるイーサネット・ブリッジに接続されています。
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].
MS、AR、ER、およびイーサネットブリッジ：IPv6のデュアルスタックに次のデバイスをアップグレードすることによって、このシナリオで展開されます。 [IEEE802.16]で指定されるように、BSは、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を保護するために必要です。イーサネットブリッジリレーのすべてのトラフィックは、BRASに接続されたネットワーク側のポート（複数可）にBSを介して受信しました。 BRASから受信したトラフィックは、適切なBSに中継されます。 802.16 MAC層は、アップリンク方向におけるマルチキャスト（ブロードキャスト）のためのネイティブサポートしていないので、イーサネット・ブリッジは、そのポートのすべてにMSから受信したマルチキャストフレームを中継することにより、マルチキャスト（ブロードキャスト）を実施します。イーサネットブリッジはまた、802.16無線リンク（セクション2.2.2.3参照）のリンク効率を高めるためにいくつかのIPv6固有の機能を提供することができます。
One or more IPv6 prefixes can be shared to all the attached MSs. Prefix delegation can be required if networks exist behind the SS.
一つまたは複数のIPv6プレフィックスが取り付けられているすべてのMSに共有することができます。ネットワークがSSの後ろに存在する場合はプレフィックス委任が必要になることができます。
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-ETHERNET]で説明されています。
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のマルチホーミングの考慮事項が存在します。 MSをサポートするために、2つのルータが存在する場合、例えば、デフォルトルータを選択する必要があります。
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.
エッジルータは、OSPFv3の[RFC2740]としてSPのネットワークで使用されるIGPを実行するか、IPv6のIS-IS。接続されているプレフィックスは再配布する必要があります。プレフィックス要約は、エッジルータで実行する必要があります。
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.
レイヤ2およびレイヤ3のないモビリティ機能は、固定アクセスのシナリオではサポートされていません。 WLAN技術と同様に、しかし、nomadicityはどのモビリティプロトコルなしで無線カバレッジでサポートすることができます。だから、ユーザーは、カバレッジにnomadicallyインターネットにアクセスすることができます。
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]はあっても、レイヤ2のモビリティサポートの非存在下で、このシナリオで使用することができます。
[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-ETHERNET]は[RFC4605]をプロキシし、IGMP / MLDは[RFC4541]をスヌーピングインターネットグループ管理プロトコル/マルチキャストリスナ発見（IGMP / MLD）によってIPv6マルチキャストサポートを実現しています。また、効率的にIEEE 802.16マルチキャストCIDの手段によって、マルチキャスト加入者の間でマルチキャストパケットの送信を実現することが可能です。しかし、そのようなプロトコルはまだ利用し、WiMAXフォーラムで開発中ではありません。
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].
IEEE 802.16ネットワークでは、接続は単方向で、サービス品質（QoS）の仕様を持っています。各接続は、単一のデータ・サービス・フローに関連付けられており、各サービスフローは[IEEE802.16]におけるQoSパラメータのセットに関連付けられています。 QoS関連のパラメータは、動的サービス追加（DSA）と[IEEE802.16]で指定された動的サービス変更（DSC）MAC管理メッセージを使用して管理されています。 [IEEE802.16]は5つのスケジューリングサービスによって、異なるタイプのアプリケーションのためのQoS差別化を提供します。送信権割当サービス（UGS）、リアルタイムポーリング・サービス（rtPS）、非リアルタイムポーリングサービス（上記nrtPS）、およびベストエフォート（BE）：四つのスケジューリングサービスは、802.16で定義されています。第五のスケジューリングサービスは[IEEE802.16e規格]で定義され、リアルタイムポーリングサービス（ertPSを）に拡張されます。 MAC層のQoSタイプ[IEEE802.16]、[IEEE802.16e規格]にサービスマッピングのIPレイヤの品質を定義するために必要とされます。
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は、そのサービスプロバイダネットワークに位置する認証、許可、アカウンティング（AAA）サーバによって認証されています。それを達成するために、MSとBSの使用プライバシーキー管理[IEEE802.16]、[IEEE802.16e規格]、BSは、AAAプロトコルを使用してAAAサーバと通信しながら。 MSは、AAAサーバと認証されると、それがBSで正常に関連付け、ステートレス自動設定またはDHCPv6のを通してIPv6アドレスを取得することができます。開始および認証プロセスがIPv4で使用されるものと同じであることに留意されたいです。
[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】IEEE 802.16ネットワークのための管理情報ベースを含みます。 IPv6ネットワーク管理のために、（などのMIB、NetFlowのレコードなど）が必要計器が利用可能であるべきです。
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 management messages such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network Management Protocol (SNMP).
ネットワークに入ると、MSは、各方向に3つの管理接続が割り当てられます。これらの3つの接続は、異なる管理レベルで使用された3つの異なるQoS要件を反映しています。これらの最初は、短い、タイムクリティカルなMAC管理メッセージと無線リンク制御（RLC）メッセージの転送のために使用される基本的な接続、です。プライマリ管理接続は、長い認証や接続設定のために使用されるものなど、より遅延トレラントメッセージを転送するために使用されます。セカンダリ管理接続は、動的ホスト構成プロトコル（DHCP）、簡易ファイル転送プロトコル（TFTP）、および簡易ネットワーク管理プロトコル（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 802.16ネットワークはIPv4またはIPv6によって管理することができます。 SNMPメッセージは、IPv4またはIPv6のいずれかによって実施することができます。
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.
このドキュメントでは、IEEE 802.16ベースのネットワークのためのさまざまなIPv6の展開シナリオとリンクモデルの詳細な説明を提供し、そのように任意の新しいセキュリティ脅威を導入しません。どんなにネットワークは[RFC4942]で定義される[IEEE802.16e規格]とIPv6移行セキュリティ問題で定義された同一のリンク・レイヤ・セキュリティ・メカニズムを採用すべきかのシナリオが適用されます。すでに[RFC4968]に記載されているようしかし、共有プレフィックスモデルベースのモバイルアクセスの展開シナリオは、範囲内で動作するように設計されているプロトコルのセキュリティ上の影響を有していてもよいです。これは、民間の資源が公共の802.16ベースのネットワーク上に置くことができない前記共有プレフィックスリンクモデルの関心事です。これは、エンタープライズ環境への共有プレフィックスモデルの使用を制限することができます。
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.
この作品はv6opsは、[RFC4779]で動作する拡張します。私たちは、ドキュメントのすべての著者に感謝します。特別な感謝は、大規模なレビューのためにマクシミリアンリーゲル、Jonne Soininen、ブライアンE.カーペンター、ジムバウンド、デビッド・ジョンストン、Basavarajパティル、Byoung-ジョー・キム、エリック・クライン、ブルーノ・スーザ、ジョン・モリブデン・ムーン、Sangjinチョン、とJinhyeock崔によるものですこのドキュメントの。私たちは、文書の校正のためのドミニクカスパーを認めます。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[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]「IEEE 802.16-2004、地方のIEEE Standardとメトロポリタンエリアネットワーク、パート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規格]「ローカルおよびメトロポリタンエリアネットワークパート16のためのIEEE規格：固定およびモバイルブロードバンドワイヤレスアクセスシステムの修正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.
[IP-ETHERNET]チョン、H.、リーゲル、M.、およびS.チョン、 "IEEE 802.16ネットワーク経由イーサネット上のIPの送信"、進歩、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]チャン、H.、ジヨン、J.、漢、Y.、公園、S.、およびJ.チャ、 "IEEE 802.16eのネットワーク上のモバイルIPv6高速ハンドオーバ"、進歩、2008年3月での作業。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、RFC 3314、2002年9月、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[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、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[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プロキシ」） 」、RFC 4605、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. Palet、 "ブロードバンドアクセスネットワークにおけるISPのIPv6展開シナリオ"、RFC 4779、2007年1月。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation Methods Considered Harmful", RFC 4840, April 2007.
[RFC4840] Aboba、B.、デイヴィス、E.、およびD.ターラー、 "有害と考えられ、複数のカプセル化メソッド"、RFC 4840、2007年4月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]デイヴィス、E.、クリシュナン、S.、およびP. Savola、 "IPv6移行/共存のセキュリティの考慮事項"、RFC 4942、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リンクモデルの分析"、RFC 4968、2007年8月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121]パティル、B.、夏、F.、Sarikaya、B.、チェ、JH。、およびS. Madanapalli、 "IEEE 802.16ネットワークの上のIPv6コンバージェンスサブレイヤを介したIPv6の送信"、RFC 5121、2008年2月。
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 802.16 Problem Statement and Goals", RFC 5154, April 2008.
[RFC5154]ジヨン、J.、Madanapalli、S.、およびJ. Mandin、RFC 5154、2008年4月 "IP IEEE 802.16問題文と目標を超えます"。
Authors' Addresses
著者のアドレス
Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea
明博新Etry 161 Gajeong洞Useng-TH Dayxav、305から350韓国
Phone: +82 42 860 4847 EMail: myungki.shin@gmail.com
電話：+82 42 860 4847 Eメール：myungki.shin@gmail.com
Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea
ユン・ヒチョルハンKUT Gajeon-Riを307 Byeongcheon-北面天安のa-Si忠清南道（チュンチョンナムド）、330から708韓国
EMail: yhhan@kut.ac.kr
メールアドレス：yhhan@kut.ac.kr
Sang-Eon Kim KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-791 Korea
サンウ - キム・永劫KT 17 Woomyeon洞、瑞草区、ソウル、137から791韓国
EMail: sekim@kt.com
メールアドレス：sekim@kt.com
Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia
Domagoj 10010ザグレブクロアチア70AシーメンスモバイルHeinzelova弓
EMail: domagoj.premec@siemens.com
メールアドレス：domagoj.premec@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。