[要約] RFC 5181は、802.16ネットワークでのIPv6展開シナリオに関するガイドラインです。その目的は、IPv6を使用したネットワーク展開に関する情報を提供し、802.16ネットワークのIPv6対応を促進することです。
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
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 IEEE 802.16アクセスネットワークの主要なコンポーネントと、IPv4 IEEE 802.16ネットワークとの違いと、IEEE 802.16テクノロジーのそれぞれにIPv6が展開および統合される方法について説明します。
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ネットワークとの違いと、IEEE 802.16テクノロジーのそれぞれにIPv6が展開および統合される方法について説明します。
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は[IEEE802.16E]で導入されたモバイルサブスクライバーステーション（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）：IPルーティング関数を実行してサブスクライバーステーション（SSまたはMS）に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（Convergence Sublayer）：802.3/Ethernet CS固有のパケット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 IPv6 CS（Convergence Sublayer）：802.16 STDで定義されたPacket 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]は、収束サブレイヤーとAIPインターフェイス上でIPを輸送する機能を指定します。IEEE 802.16を超えるIPv6（およびIPv4）操作の詳細は、16ng Wgで定義されています。IPv6 over 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.
[IEEE802.16]は、ワイヤレスメディアを共有するための2つのモード（Point-to-MultiPoint（PMP）とMesh（オプション）を指定します。このドキュメントは、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.
2つの異なる展開シナリオがあります：固定とモバイルアクセスの展開シナリオ。固定アクセスシナリオは、デジタルサブスクライバーライン（XDSL）やケーブルネットワークなどの既存の有線ベースのアクセステクノロジーを置き換えます。この固定アクセスシナリオは、Hot Zoneモデルと呼ばれるラジオカバレッジ内で遊牧民のアクセスを提供できます。モバイルネットワークを介した音声、データ、ビデオの送信の新しいパラダイムには、モバイルアクセスシナリオが存在します。このシナリオは、ワイヤーベースのインターネットに相当する高速データレートと、セルラーシステムに相当するモビリティ関数を提供できます。固定およびモバイルアクセスの展開シナリオの間で、Convergenceサブレイヤータイプ、リンクモデル、アドレス指定、モビリティなどに異なるIPv6の影響があります。詳細については、以下で説明します。モバイルアクセスシナリオは、共有IPv6プレフィックスリンクモデルとポイントツーポイントリンクモデルの2つの異なる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リンクモデルが2つあります。シナリオには常にデフォルトのアクセスルーターがあります。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のみで構成されているIEEE 802.16モバイルアクセスネットワーク展開を表します。したがって、すべてのMSSおよび対応するARインターフェイスは、図2に示すように同じIPv6プレフィックスを共有します。IPv6プレフィックスは、ARのインターフェイスとは異なります。
+-----+
| 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].
IPv6は、次のデバイスをデュアルスタックにアップグレードすることにより、このシナリオに展開されます：MS、AR、およびER。このシナリオでは、IEEE 802.16 BSSには、ルーター機能のないMacとPhy（物理層）層のみがあり、ブリッジとして動作します。BSは、[IEEE802.16]で指定されている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は、Stateless Auto Configurationを使用してアクセスルーターから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は、IPv6（DHCPV6）の動的ホスト構成プロトコルを使用して、DHCPV6サーバーからIPv6アドレスを取得できます。この場合、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に単一のプレフィックスが割り当てられます。同じARに接続されているすべてのMSSは、同じ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プレフィックスリンクモデルの場合、1つ以上の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.
IPv6サブネットでは、常に2つの根底にあるリンクがあります。1つはMSとBSの間のIEEE 802.16ワイヤレスリンク、もう1つは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].
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をサポートしていない場合、サービスプロバイダーはIPv6-in-IPV4トンネルメカニズムを展開して、ARとERの間で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）。
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は、複数のリンクでERに接続した場合、IPv6の中間システム（IS-IS）にOSPFV3 [RFC2740]や中間システム（IS-IS）への中間システム（IS-IS）などの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は、サービスプロバイダーネットワークのIPv6のIS-ISなどのインテリアゲートウェイプロトコル（IGP）を実行します。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.
IEEE 802.16Eネットワークには、リンクレイヤーハンドオーバーとIPレイヤーのハンドオーバーには、2種類のハンドオーバーがあります。リンクレイヤーのハンドオーバーでは、ハンドオーバーに関与するBSSは同じIPサブネットに存在します。MSは、IPアドレス、デフォルトのルーター、オンリンクプレフィックスなど、IP構成を変更せずに新しいBSとのリンクレイヤー接続を再確立する必要があります。MSは、ハンドオーバープロセスの開始時に現在のBSとの接続を遮断する必要があり、ハンドオーバーが完了するまで新しいBSとの通信を再開できないためです[IEEE802.16E]。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は、ムーブメント検出が近隣の非到達性検出を使用して、デフォルトのルーターが双方向に到達できなくなったときに検出することを定義しています。その場合、モバイルノードは新しいデフォルトルーターを発見する必要があります。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から別のCS（例えば、IPv6 CSからイーサネット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.
このシナリオは、サブネットが複数のBSSの複数のMSSと複数のインターフェイスで構成されている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はイーサネットブリッジに接続されています。イーサネットブリッジは、BRA（ブロードバンドリモートアクセスサーバー）に分離したり、BRA（ブロードバンドリモートアクセスサーバー）に統合できます。
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、およびEthernet Bridge。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のブラジャーは、ARの機能を提供しています。802.16リンク層の特性からブラジャーを保護するためには、イーサネットブリッジが必要です。イーサネットブリッジは、BSを介して受信したすべてのトラフィックをブラジャーに接続したネットワークサイドポートにリレーします。ブラジャーから受け取ったトラフィックは、適切なBSに中継されます。802.16 Macレイヤーはアップリンク方向にマルチキャスト（およびブロードキャスト）をネイティブサポートしていないため、イーサネットブリッジは、MSからすべてのポートに受信したマルチキャストフレームを中継することにより、マルチキャスト（およびブロードキャスト）を実装します。イーサネットブリッジは、802.16無線リンクのリンク効率を高めるために、いくつかのIPv6固有の機能を提供する場合があります（セクション2.2.2.3を参照）。
One or more IPv6 prefixes can be shared to all the attached MSs. Prefix delegation can be required if networks exist behind the SS.
1つ以上のIPv6プレフィックスを、添付のすべてのMSSと共有できます。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マルチホーミングの考慮事項が存在します。たとえば、MSSをサポートする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.
Edgeルーターは、OSPFV3 [RFC2740]やIS-ISなどのSPネットワークで使用されるIGPを実行します。接続されたプレフィックスを再配布する必要があります。プレフィックスの要約は、エッジルーターで行う必要があります。
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テクノロジーと同様に、モビリティプロトコルなしでは、ラジオカバレッジで遊牧民がサポートできます。そのため、ユーザーはカバレッジで遊牧的にインターネットにアクセスできます。
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セッションの継続性またはホームアドレスの再利用性を要求する場合があります。その場合、レイヤー2のモビリティサポートがない場合でも、このシナリオでは、モバイルIPv6 [RFC3775]を使用できます。
[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]インターネットグループ管理プロトコル/マルチキャストリスナーディスカバリー（IGMP/MLD）のプロキシ[RFC4605]およびIGMP/MLDスヌーピング[RFC4541]による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関連のパラメーターは、[IEEE802.16]で指定された動的サービス追加（DSA）および動的サービス変更（DSC）MAC管理メッセージを使用して管理されます。[IEEE802.16]は、5つのスケジューリングサービスによって、さまざまなタイプのアプリケーションにQoS区別を提供します。4つのスケジューリングサービスは、802.16で定義されています：未承諾の助成金サービス（UGS）、リアルタイムポーリングサービス（RTPS）、非リアルタイムポーリングサービス（NRTPS）、および最良の努力（BE）。5番目のスケジューリングサービスは、[IEEE802.16E]で定義されているリアルタイムポーリングサービス（ERTPS）を拡張します。IPレイヤーのサービス品質マッピングをMacレイヤーQoSタイプ[IEEE802.16]、[IEEE802.16E]を定義する必要があります。
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サーバーで認証されると、Stateless Auto ConfigurationまたはDHCPV6を介してBSにうまく関連付けられ、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ネットワーク管理の場合、必要な計装（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 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展開シナリオとリンクモデルの詳細な説明を提供するため、新しいセキュリティの脅威は導入されません。適用されたシナリオが何であれ、ネットワークは[IEEE802.16E]で定義されている同じリンクレイヤーセキュリティメカニズムと[RFC4942]で定義された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.
この作業は、[RFC4779]のV6OPS作業を拡張します。ドキュメントのすべての著者に感謝します。マクシミリアン・リーゲル、ジョンネ・ソイニネン、ブライアン・E・カーペンター、ジム・バウンド、デビッド・ジョンストン、バサヴァラジ・パティル、バイオン・ジョージ・キム、エリック・クライン、ブルーノ・スーサ、ジョン・モーン、サングジン・ジョン、ジンヒョック・チョイが広範囲にわたるレビューを求めていることに感謝しますこのドキュメントの。ドキュメントを校正してくれたDominik Kasparに感謝します。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[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標準、パート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：ライセンスバンドとCorrigendum 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] Jeon、H.、Riegel、M。、およびS. Jeong、「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] Jang、H.、Jee、J.、Han、Y.、Park、S。、およびJ. Cha、「モバイルIPv6高速手向きのIEEE 802.16Eネットワーク」、2008年3月の進行中。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「第三世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、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] Fenner、B.、He、H.、Haberman、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.、Ahmed、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.、Davies、E。、およびD. Thaler、「有害と見なされる複数のカプセル化方法」、RFC 4840、2007年4月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6 Transition/Co-Existence Security Scomationations」、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] Patil、B.、Xia、F.、Sarikaya、B.、Choi、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] Jee、J.、Madanapalli、S。、およびJ. Mandin、「IP Over IEEE 802.16問題声明と目標」、RFC 5154、2008年4月。
Authors' Addresses
著者のアドレス
Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea
myung-ki shin etri 161 gajeong-dong yuseng-gu daejeon、305-350 Korea
Phone: +82 42 860 4847
EMail: myungki.shin@gmail.com
Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea
youn-hee han kut gajeon-ri 307 byeongcheon-myon chunan-si chungnam省、330-708韓国
EMail: yhhan@kut.ac.kr
Sang-Eon Kim KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-791 Korea
Sang-eon Kim Kt 17 Woomyeon-Dong、Seocho-gu Seoul、137-791 Korea
EMail: sekim@kt.com
Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia
Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia
EMail: domagoj.premec@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。