[要約] RFC 4968は、802.16ベースのネットワークにおけるIPv6リンクモデルの分析に関するものです。このRFCの目的は、IPv6を使用した802.16ネットワークのリンクモデルを評価し、その効果を理解することです。
Network Working Group S. Madanapalli, Ed.
Request for Comments: 4968 Ordyn Technologies
Category: Informational August 2007
Analysis of IPv6 Link Models for IEEE 802.16 Based Networks
IEEE 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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.
このドキュメントは、IEEE 802.16ベースのネットワークに適したさまざまなIPv6リンクモデルを提供し、各リンクモデルのさまざまな考慮事項と、異なる展開シナリオでの各リンクモデルの適用性の分析を提供します。このドキュメントは、IEEE 802.16ベースのネットワークのIPv6リンクモデルを分析するために形成された設計チーム（DT）の結果です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Link Models for IEEE 802.16 Based Networks . . . . . . . 3
3.1. Shared IPv6 Prefix Link Model . . . . . . . . . . . . . . 3
3.1.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 5
3.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 5
3.1.3. Duplicate Address Detection . . . . . . . . . . . . . 5
3.1.4. Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Applicability . . . . . . . . . . . . . . . . . . . . 7
3.2. Point-to-Point Link Model . . . . . . . . . . . . . . . . 7
3.2.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 8
3.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 8
3.2.3. Considerations . . . . . . . . . . . . . . . . . . . . 8
3.2.4. Applicability . . . . . . . . . . . . . . . . . . . . 9
3.3. Ethernet-Like Link Model . . . . . . . . . . . . . . . . . 10
3.3.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 10
3.3.2. Address Autoconfiguration . . . . . . . . . . . . . . 10
3.3.3. Duplicate Address Detection . . . . . . . . . . . . . 10
3.3.4. Considerations . . . . . . . . . . . . . . . . . . . . 11
3.3.5. Applicability . . . . . . . . . . . . . . . . . . . . 11
4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Effect on Dormant Mode . . . . . . . . . . . . . . . . . . . . 12
6. Effect on Routing . . . . . . . . . . . . . . . . . . . . . . 12
7. Conclusions and Relevant Link Models . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
IEEE 802.16 [4] [5] is a point-to-multipoint, connection-oriented access technology for the last mile without bi-directional native multicast support. IEEE 802.16 has defined only downlink multicast support. This leads to two methods for running IP protocols that traditionally assume the availability of multicast at the link layer. One method is to use bridging, e.g., IEEE 802.1D [6], to support bi-directional multicast. Another method is to treat the IEEE 802.16 MAC (Message Authentication Code) transport connections between an MS (Mobile Station) and BS (Base Station) as point-to-point IP links so that the IP protocols (e.g., ARP (Address Resolution Protocol), IPv6 Neighbor Discovery) can be run without any problems.
IEEE 802.16 [4] [5]は、双方向のネイティブマルチキャストサポートなしの最後のマイルのポイントツーマルチポイント、接続指向アクセステクノロジーです。IEEE 802.16は、ダウンリンクマルチキャストサポートのみを定義しています。これにより、リンクレイヤーでのマルチキャストの可用性を伝統的に想定しているIPプロトコルを実行する2つの方法につながります。1つの方法は、Bridging、たとえばIEEE 802.1d [6]を使用して、双方向マルチキャストをサポートすることです。別の方法は、IEEE 802.16 MAC（メッセージ認証コード）をMS（モバイルステーション）とBS（ベースステーション）間の接続をポイントツーポイントIPリンクとして扱うことで、IPプロトコル（例：ARP（アドレス解像度プロトコル））、IPv6 Neighbor Discovery）問題なく実行できます。
This is further complicated by the definition of commercial network models like WiMAX, which defines the WiMAX transport connection that extends the IEEE 802.16 MAC transport connection all the way to an access router by using a tunnel between the base station and the access router [14]. This leads to multiple ways of deploying IP over IEEE 802.16 based networks.
これは、ベースステーションとアクセスルーターの間のトンネルを使用してIEEE 802.16 Mac Transport Connectionをアクセスルーターまで拡張するWimax Transport Connectionを定義するWimaxのような商用ネットワークモデルの定義によってさらに複雑になります[14]。これにより、IEEE 802.16ベースのネットワークを介してIPを展開する複数の方法につながります。
This document looks at various considerations in selecting a link model for IEEE 802.16 based networks and provides an analysis of the various possible link models. And finally, this document provides a recommendation for choosing one link model that is best suitable for the deployment.
このドキュメントは、IEEE 802.16ベースのネットワークのリンクモデルを選択する際のさまざまな考慮事項を調べ、さまざまな可能なリンクモデルの分析を提供します。そして最後に、このドキュメントは、展開に最適な1つのリンクモデルを選択するための推奨事項を提供します。
The terminology in this document is based on the definitions in [6], in addition to the ones specified in this section.
このドキュメントの用語は、このセクションで指定されたものに加えて、[6]の定義に基づいています。
Access Router (AR): An entity that performs an IP routing function to provide IP connectivity for Mobile Stations. In WiMAX Networks, the AR is an Access Service Network Gateway.
アクセスルーター（AR）：IPルーティング関数を実行してモバイルステーションにIP接続を提供するエンティティ。WIMAXネットワークでは、ARはアクセスサービスネットワークゲートウェイです。
Access Service Network (ASN) - The ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX subscriber. The ASN is the access network to which the MS attaches. The IPv6 access router is an entity within the ASN. The term ASN is specific to the WiMAX network architecture.
Access Service Network（ASN）-ASNは、WIMAXサブスクライバーへの無線アクセスを提供するために必要なネットワーク関数の完全なセットとして定義されます。ASNは、MSが付着するアクセスネットワークです。IPv6アクセスルーターは、ASN内のエンティティです。ASNという用語は、WIMAXネットワークアーキテクチャに固有です。
Dormant Mode: A state in which a mobile station restricts its ability to receive normal IP traffic by reducing monitoring of radio channels. This allows the mobile station to save power and reduces signaling load on the network. In the dormant mode, the MS is only listening at scheduled intervals to the paging channel. The network (e.g., the AR) maintains state about an MS that has transitioned to dormant mode and can page it when needed.
休眠モード：モバイルステーションが無線チャネルの監視を減らすことにより、通常のIPトラフィックを受ける能力を制限する状態。これにより、モバイルステーションは電源を節約し、ネットワーク上のシグナル伝達負荷を減らすことができます。休眠モードでは、MSはスケジュールされた間隔でページングチャネルへのみリスニングしています。ネットワーク（たとえば、AR）は、休眠モードに遷移したMSに関する状態を維持し、必要に応じてページできます。
This section discusses various IPv6 link models for IEEE 802.16 based networks and provides their operational considerations in practical deployment scenarios.
このセクションでは、IEEE 802.16ベースのネットワークのさまざまなIPv6リンクモデルについて説明し、実際の展開シナリオで運用上の考慮事項を提供します。
In this model, all MSs attached to an AR share one or more prefixes for constructing their global IPv6 addresses, however this model does not provide any multicast capability. The following figures illustrates a high-level view of this link model wherein one or more prefixes advertised on the link would be used by all the MSs attached to the IPv6 link.
このモデルでは、ARに接続されているすべてのMSSは、グローバルIPv6アドレスを構築するために1つ以上のプレフィックスを共有していますが、このモデルはマルチキャスト機能を提供しません。次の図は、このリンクモデルの高レベルビューを示しています。このリンクモデルでは、リンクに宣伝されている1つ以上の接頭辞が、IPv6リンクに添付されているすべてのMSSによって使用されます。
+-----+
| MS1 |-----+
+-----+ |
|
|
+-----+ | +-----+ +--------+
| MS2 |-----+-----| BS1 |----------| AR |-------Internet
+-----+ | +-----+ +--------+
. | ____________
. | ()__________()
+-----+ | L2 Tunnel
| MSn |-----+
+-----+
Figure 1. Shared IPv6 Prefix Link Model
図1.共有IPv6プレフィックスリンクモデル
The above figure shows the case where the BS and AR exist as separate entities. In this case, a tunnel exists between the BS and AR per MS basis.
上記の図は、BSとARが別々のエンティティとして存在する場合を示しています。この場合、MSベースごとにBSとARの間にトンネルが存在します。
In this link model, the link between the MS and the AR at the IPv6 layer is viewed as a shared link, and the lower layer link between the MS and BS is a point-to-point link. This point-to-point link between the MS and BS is extended all the way to the AR when the granularity of the tunnel between the BS and AR is on a per MS basis. This is illustrated in the following figure below.
このリンクモデルでは、IPv6レイヤーのMSとARの間のリンクは共有リンクと見なされ、MSとBSの間の下層リンクはポイントツーポイントリンクです。MSとBSの間のこのポイントツーポイントリンクは、BSとARの間のトンネルの粒度がMSごとに拡張されている場合、ARまでずっと拡張されます。これを次の図に示します。
MS
+----+ +----+
| | IPv6 (Shared link) | |
| L3 |=====================================| |
| | | |
|----| PTP conn. +----+ L2 Tunnel | AR |---Internet
| L2 |-------------| BS |==================| |
| | | | | |
+----+ +----+ | |
| |
+----+ L2 Tunnel | |
| BS |==================| |
| | | |
+----+ +----+
Figure 2. Shared IPv6 Prefix Link Model - Layered View
図2.共有IPv6プレフィックスリンクモデル - レイヤードビュー
In this link model, an AR can serve one or more BSs. All MSs connected to BSs that are served by an AR are on the same IPv6 link. This model is different from an Ethernet Like Link model wherein the later model provides an Ethernet link abstraction and multicast capability to the IPv6 layer, whereas the Shared IPv6 Prefix Link Model defined here does not provide native link-layer multicast and broadcast capabilities.
このリンクモデルでは、ARは1つ以上のBSSを提供できます。ARが提供するBSSに接続されたすべてのMSSは、同じIPv6リンク上にあります。このモデルは、イーサネットのようなリンクモデルとは異なり、後のモデルはイーサネットリンクの抽象化とIPv6層にマルチキャスト機能を提供しますが、ここで定義されている共有IPv6プレフィックスリンクモデルはネイティブリンク層マルチキャストとブロードキャスト機能を提供しません。
One or more IPv6 prefixes are assigned to the link and hence shared by all the nodes that are attached to the link. The prefixes are advertised with the autonomous flag (A-Flag) set and the On-link flag (L-flag) reset for address autoconfiguration so that the nodes may not make an on-link assumption for the addresses in those prefixes.
1つ以上のIPv6プレフィックスがリンクに割り当てられているため、リンクに接続されているすべてのノードによって共有されます。接頭辞は、自動フラグ（A-Flag）セットとオンリンクフラグ（L-Flag）リセットでアドレスの自動構成に宣伝されているため、ノードはそれらのプレフィックスのアドレスのオンリンクの仮定を作成しないようにします。
The standard IPv6 address autoconfiguration mechanisms, which are specified in [2] [3], are used.
[2] [3]で指定されている標準のIPv6アドレスAutoconfigurationメカニズムが使用されます。
The DAD procedure, as specified in [2], does not adapt well to the IEEE 802.16 air interface as there is no native multicast support. The DAD can be performed with MLD (Multicast Listener Discovery) snooping [7] and the AR relaying the DAD probe to the address owners in case the address is a duplicate, called Relay DAD. In this method, the MS behavior is the same as specified in [2] and the optimization is achieved with the support of AR, which maintains the MLD table for a list of multicast addresses and the nodes that joined the multicast address. The relay DAD works as below:
[2]で指定されているお父さんの手順は、ネイティブのマルチキャストサポートがないため、IEEE 802.16エアインターフェイスに適していません。お父さんは、MLD（マルチキャストリスナーディスカバリー）スヌーピング[7]で実行できます。この方法では、MSの動作は[2]で指定されたものと同じであり、最適化はARのサポートで達成されます。ARは、マルチキャストアドレスのリストとマルチキャストアドレスに結合したノードのMLDテーブルを維持します。リレーパパは以下のように機能します：
1. An MS constructs a Link Local Address as specified in [2].
1. MSは、[2]で指定されているようにリンクローカルアドレスを構築します。
2. The MS constructs a solicited node multicast address for the corresponding Link Local Address and sends an MLD Join request for the solicited node multicast address.
2. MSは、対応するリンクローカルアドレスの勧誘されたノードマルチキャストアドレスを構築し、勧誘されたノードマルチキャストアドレスのMLD参加要求を送信します。
3. The MS starts verifying address uniqueness by sending a DAD NS on the initial MAC transport connection.
3. MSは、最初のMac Transport ConnectionでDAD NSを送信することにより、アドレスの一意性の確認を開始します。
4. The AR consults the MLD table for who joined the multicast address. If the AR does not find any entry in the MLD table, the AR silently discards the DAD NS. If the AR finds a match, the AR relays the DAD NS to the address owner.
4. ARは、マルチキャストアドレスに参加した人のためにMLDテーブルに相談します。ARがMLDテーブルにエントリが見つからない場合、ARは静かにDAD NSを破棄します。ARが一致を見つけた場合、ARはDAD NSを住所所有者にリリーします。
5. The address owner defends the address by sending DAD NA, which is relayed to the DAD originating MS via the AR.
5. アドレス所有者は、ARを介してMSから生まれたMSに中継されるDAD NAを送信することにより、住所を守ります。
6. If the DAD originating MS does not receive any response (DAD NA) to its DAD NS, the MS assigns the address to its interface. If the MS receives the DAD NA, the MS discards the tentative address and behaves as specified in [2].
6. MSの出身のお父さんがDAD NSに応答（DAD NA）を受け取らない場合、MSはアドレスをインターフェイスに割り当てます。MSがDAD NAを受信した場合、MSは暫定的な住所を破棄し、[2]で指定されたとおりに動作します。
The shared IPv6 prefix model uses the existing specification and does not require any protocol changes or any new protocols. However, this model requires implementation changes for DAD optimization on the AR.
共有IPv6プレフィックスモデルは既存の仕様を使用しており、プロトコルの変更または新しいプロトコルは必要ありません。ただし、このモデルでは、ARでのDAD最適化のための実装の変更が必要です。
No native on-link multicast is possible with this method. However, the multicast can be supported with using a backend process in AR that maintains the multicast members list and forwards the multicast packets to the MSs belonging to a particular multicast group in a unicast manner. MLD snooping [7] should be used for maintaining the multicast members list.
この方法では、ネイティブオンリンクマルチキャストは不可能です。ただし、マルチキャストメンバーのリストを維持し、マルチキャストパケットを特定のマルチキャストグループに属するマルチキャストパケットをユニキャスト方法で転送することで、マルチキャストをサポートできます。MLD Snooping [7]は、マルチキャストメンバーリストを維持するために使用する必要があります。
The definition of an IPv6 link is consistent for all procedures and functionalities except for the support of native on-link multicast support.
IPv6リンクの定義は、ネイティブオンリンクマルチキャストサポートのサポートを除き、すべての手順と機能について一貫しています。
All the packets travel to the AR before being delivered to the final destination as the layer 2 transport connection exists between the MS and AR. The AR normally handles the packets with external IPv6 addresses. However, the packets with link local destination addresses are relayed by the AR to the destination without decrementing the hop-limit.
すべてのパケットは、MSとARの間にレイヤー2トランスポート接続が存在するため、最終目的地に配信される前にARに移動します。ARは通常、外部IPv6アドレスでパケットを処理します。ただし、リンクローカル宛先アドレスを備えたパケットは、ホップリミットを減らすことなくARによって宛先に中継されます。
This link model does not require any implementation changes for the host implementation.
このリンクモデルでは、ホストの実装に実装の変更は必要ありません。
This link model requires MLD snooping in the AR for supporting Relay DAD.
このリンクモデルでは、リレーパパをサポートするためにARでMLDスヌーピングが必要です。
This model is good for providing shared on-link services in conjunction with the IP convergence sublayer with IPv6 classifiers. However, in public access networks like cellular networks, this model cannot be used for the end users to share any of their personal devices/services with the public.
このモデルは、IPv6分類子を持つIP Convergence Sublayerと組み合わせて、共有オンリンクサービスを提供するのに適しています。ただし、セルラーネットワークなどのパブリックアクセスネットワークでは、このモデルをエンドユーザーが個人のデバイス/サービスを一般と共有するために使用することはできません。
This link model was also under consideration of the WiMAX Forum Network Working Group for use with IPv6 CS (Convergence Sublayer) access.
このリンクモデルは、IPv6 CS（Convergence Sublayer）アクセスで使用するためのWimax Forum Network Working Groupも検討中でした。
In this model, a set of MAC transport connections between an MS and an AR are treated as a single link. The point-to-point link model follows the recommendations of [8]. In this model, each link between an MS and an AR is allocated a separate, unique prefix or a set of unique prefixes by the AR. No other node under the AR has the same prefixes on the link between it and the AR. The following diagram illustrates this model.
このモデルでは、MSとARの間のMAC輸送接続のセットが単一のリンクとして扱われます。ポイントツーポイントリンクモデルは、[8]の推奨事項に従います。このモデルでは、MSとARの間の各リンクには、ARによる個別の一意のプレフィックスまたは一意のプレフィックスのセットが割り当てられます。ARの下にある他のノードには、リンクとARの間のリンクに同じ接頭辞がありません。次の図は、このモデルを示しています。
+----+ +----+
+-----+ | | Tunnel | |
| MS1 |-------------|....|===================| |
+-----+ | | | |
| | | |
+-----+ | | Tunnel | |
| MS2 |-------------|....|===================| |---Internet
+-----+ | | | AR |
| BS | | |
+-----+ | | Tunnel | |
| MS3 |-------------|....|===================| |
+-----+ | | | |
+----+ +----+
Figure 3. Point-to-Point Link Model
図3.ポイントツーポイントリンクモデル
There are multiple possible ways that the point-to-point link between the AR and the MS can be implemented.
ARとMSの間のポイントツーポイントリンクを実装できる複数の方法があります。
1. One way to accomplish this is to run PPP on the link [8]. Running PPP requires that the IEEE 802.16 link use the Ethernet CS and PPP over Ethernet [9]. Since the IPv6 CS does not support PPP, whether PPP can be run depends on the network architecture.
1.
2. If the actual physical medium is shared, like Ethernet, but PPP is not run, the link can be made point to point between the MS and AR by having each MS on a separate VLAN [11].
2. イーサネットのように実際の物理媒体が共有されているが、PPPが実行されない場合、リンクは、個別のVLAN [11]に各MSを配置することにより、MSとARの間をポイントすることができます。
3. If neither PPP nor VLAN is used, the set of IEEE 802.16 connections can be viewed as a virtual point-to-point link.
3. PPPもVLANも使用されていない場合、IEEE 802.16接続のセットは仮想ポイントツーポイントリンクと見なすことができます。
Prefixes are assigned to the link using the standard [1] Router Advertisement mechanism. The AR assigns a unique prefix or a set of unique prefixes for each MS. In the prefix information options, both the A-flag and L-flag are set to 1, as they can be used for address autoconfiguration and the prefixes are on the link.
プレフィックスは、標準[1]ルーター広告メカニズムを使用してリンクに割り当てられます。ARは、各MSに一意のプレフィックスまたは一意のプレフィックスのセットを割り当てます。接頭辞情報オプションでは、A-FlagとL-Flagの両方が1に設定されています。これは、Autoconfigurationにアドレス指定するために使用でき、プレフィックスはリンク上にあります。
MSs perform link local as well as global address autoconfiguration exactly as specified in [2], including duplicate address detection. Because there is only one other node on the link, the AR, there is only a possibility of an address conflict with the AR, so collisions are statistically very unlikely, and easy to fix if they should occur.
MSSは、[2]で指定されているとおりに、[2]で指定されたとおりにローカルアドレスおよびグローバルアドレスの自動構成を実行します。リンクには他のノードが1つしかないため、ARでは、ARとのアドレス競合の可能性しかないため、衝突は統計的に非常にありそうになく、それらが発生するかどうかを簡単に修正できます。
If DHCP is used for address configuration ('M=1' in the Router Advertisement), the DHCP server must provide addresses with a separate prefix per MS. The prefix must of course match a prefix that the ASN Gateway has advertised to the MS (if any).
DHCPがアドレス構成（ルーター広告の「M = 1」）に使用される場合、DHCPサーバーはMSごとに個別のプレフィックスを付けるアドレスを提供する必要があります。もちろん、ASNゲートウェイがMSに宣伝しているプレフィックスと一致する必要があります（ある場合）。
This solution reuses RFC 2461, 2462, and, if PPP is used, RFC 2472 and RFC 2516. No changes in these protocols are required; the protocols must only be configured properly.
このソリューションは、RFC 2461、2462、およびPPPを使用する場合、RFC 2472およびRFC 2516を再利用します。これらのプロトコルに変更は不要です。プロトコルは適切にのみ構成する必要があります。
If PPP is not used, any VLAN solution, such as IEEE 802.1Q [9] or any L2 tunnel, can be used.
PPPが使用されない場合、IEEE 802.1Q [9]またはL2トンネルなどのVLANソリューションを使用できます。
Since the link between the MS and the AR is point to point, any multicast can only be sent by one or the other node. Link local multicast between other nodes and the AR will not be seen.
MSとARの間のリンクはポイントツーポイントであるため、マルチキャストはどちらか他のノードでのみ送信できます。他のノードとARの間にローカルマルチキャストをリンクしません。
The IP link is fully consistent with a standard IP point-to-point link, without exception.
IPリンクは、例外なく、標準のIPポイントツーポイントリンクと完全に一致しています。
The MS always sends all packets to the AR because it is the only other node on the link. Link local unicast and multicast packets are also forwarded only between the two.
MSは、リンク上の他の唯一のノードであるため、常にすべてのパケットをARに送信します。リンクローカルユニキャストとマルチキャストパケットは、2つの間にのみ転送されます。
Host implementations follow standard IPv6 stack procedures. No changes are needed.
ホストの実装は、標準のIPv6スタック手順に従います。変更は必要ありません。
If PPP is used, no changes in router implementations are needed. If PPP is not used, the AR must be capable of doing the following:
PPPを使用する場合、ルーターの実装に変更は必要ありません。PPPが使用されない場合、ARは次のことを行うことができなければなりません。
1. Each MS is assigned a separate VLAN when IEEE 802.1X [12] or each MS must have an L2 tunnel to the AR to aggregate all the connections to the MS and present these set of connections as an interface to the IPv6 layer.
1. IEEE 802.1x [12]または各MSがARにL2トンネルを持ち、MSへのすべての接続を集約し、IPv6レイヤーへのインターフェイスとしてこれらの接続セットを提示する場合、各MSには個別のVLANが割り当てられます。
2. The AR must be configured to include a unique prefix or a set of prefixes for each MS. This unique prefix or set of prefixes must be included in Router Advertisements every time they are sent, and if DHCP is used, the addresses leased to the MS must include only the uniquely advertised prefixes.
2. ARは、各MSの一意のプレフィックスまたはプレフィックスのセットを含めるように構成する必要があります。この一意のプレフィックスまたはプレフィックスのセットは、送信されるたびにルーター広告に含める必要があり、DHCPを使用する場合、MSにリードされたアドレスには、ユニークな宣伝されたプレフィックスのみを含める必要があります。
Note that, depending on the router implementation, these functions may or may not be possible with simple configuration. No protocol changes are required, however.
ルーターの実装に応じて、これらの機能は単純な構成で可能である場合とできない場合があることに注意してください。ただし、プロトコルの変更は必要ありません。
In enterprise networks, shared services including printers, fax machines, and other such online services are often available on the local link. These services are typically discovered using some kind of link local service discovery protocol. The unique prefix per MS model is not appropriate for these kinds of deployments, since it is not possible to have shared link services in the ASN.
エンタープライズネットワークでは、プリンター、ファックスマシン、その他のオンラインサービスなどの共有サービスがローカルリンクで利用できることがよくあります。これらのサービスは通常、何らかのリンクローカルサービスディスカバリープロトコルを使用して発見されます。MSモデルごとの一意のプレフィックスは、ASNでリンクサービスを共有することはできないため、これらの種類の展開には適していません。
The p2p link model is applicable to deployments where there are no shared services in the ASN. Such deployments are typical of service provider networks like cellular networks, which provide public access to wireless networks.
P2Pリンクモデルは、ASNに共有サービスがない展開に適用できます。このような展開は、ワイヤレスネットワークへのパブリックアクセスを提供するセルラーネットワークのようなサービスプロバイダーネットワークの典型です。
This model describes a scheme for configuration and provisioning of an IEEE 802.16 network so that it emulates a broadcast link in a manner similar to Ethernet. Figure 4 illustrates an example of the Ethernet model. This model essentially functions like an Ethernet link, which means the model works as described in [1], [2].
このモデルは、IEEE 802.16ネットワークの構成とプロビジョニングのスキームを説明し、イーサネットと同様の方法でブロードキャストリンクをエミュレートするようにします。図4は、イーサネットモデルの例を示しています。このモデルは、本質的にイーサネットリンクのように機能します。つまり、[1]、[2]で説明されているようにモデルが機能します。
One way to construct an Ethernet-like link is to implement bridging [13] between BSs and an AR, like a switched Ethernet. In Figure 4, bridging performs link aggregation between BSs and an AR. Bridging also supports multicast packet filtering.
イーサネットのようなリンクを構築する1つの方法は、スイッチ付きイーサネットのように、BSSとAR間のブリッジング[13]を実装することです。図4では、ブリッジングはBSSとAR間のリンク集約を実行します。ブリッジングは、マルチキャストパケットフィルタリングもサポートしています。
+-----+ +---+ +----+
| MS1 |---+ | | +---|AR1 |---Internet
+-----+ | | S| | +----+
+-----+ | +-----+ |E w| |
| MS2 |---+---| BS1 |---|t i| |
+-----+ +-----+ |h t|---+
| c| | +----+
+-----+ +-----+ +-----+ | h| +---|AR2 |---Internet
|Hosts|--|MS/GW|-------| BS2 |---| | +----+
+-----+ +-----+ +-----+ +---+
A network
may exist behind
MS/GW
Figure 4: Ethernet Like Link Model
図4：イーサネットのようなリンクモデル
Prefixes are assigned as specified in [1], [2].
プレフィックスは、[1]、[2]で指定されているように割り当てられます。
It is the same as described in [2].
[2]に記載されているものと同じです。
It is the same as described in [2].
[2]に記載されているものと同じです。
All the IPv6 standards can be preserved or reused in this model.
このモデルでは、すべてのIPv6標準を保存または再利用できます。
On-link multicast can be emulated in a unicast manner by efficiently bridging between all BSs with IEEE 802.16 providing the links between the MSs and the bridge on top of the BS. MLD snooping should be used for efficient forwarding of multicast packets as specified in [7]. Nevertheless, in case of bridging, direct inter-MSs communication may not be not allowed due to restrictions from the service providers.
オンリンクマルチキャストは、IEEE 802.16を使用してすべてのBSSを効率的に橋渡しすることにより、MSSとBSの上のブリッジの間のリンクを提供することにより、ユニキャスト方法でエミュレートできます。MLDスヌーピングは、[7]で指定されているように、マルチキャストパケットの効率的な転送に使用する必要があります。それにもかかわらず、ブリッジングの場合、サービスプロバイダーからの制限により、直接MSS間の通信は許可されない場合があります。
This model is consistent with the IP link definition.
このモデルは、IPリンク定義と一致しています。
When properly configured and assisted by simple bridging, IEEE 802.16 can emulate a simple broadcast network like Ethernet.
単純なブリッジングによって適切に構成および支援された場合、IEEE 802.16はイーサネットのような単純なブロードキャストネットワークをエミュレートできます。
No special impact on host implementation.
ホストの実装に特別な影響はありません。
No special impact on router implementation under a separated AR-BS model, if the bridging is implemented in BS. Some networks, e.g., WiMAX networks, may require bridging to be implemented in the AR (ASN Gateway).
BSでブリッジングが実装されている場合、分離されたAR-BSモデルの下でのルーターの実装に特別な影響はありません。一部のネットワーク、たとえば、Wimaxネットワークでは、AR（ASNゲートウェイ）にブリッジングを実装する必要がある場合があります。
This model works with the Ethernet CS and is chosen for fixed/nomadic WiMAX networks by the WiMAX Forum Network Working Group.
このモデルは、イーサネットCSで動作し、WIMAXフォーラムネットワークワーキンググループによって固定/遊牧民のWimaxネットワークに選択されています。
If the downstream prefixes managed by the AR are involved in renumbering, it may be necessary to renumber each link under the AR. [10] discusses recommended procedures for renumbering.
ARによって管理されている下流のプレフィックスが変更に関与している場合、ARの下の各リンクを変更する必要がある場合があります。[10]は、推奨される手順について議論します。
If the prefixes are advertised in RAs, the AR must withdraw the existing prefixes and advertise the new ones. Since each MS, irrespective of the link model, is on a separate point-to-point link at the MAC level because of the IEEE 802.16 connection oriented architecture, the AR must send an RA withdrawing the old prefix and advertising the new one to each link. In a point-to-point link model, the number of RAs sent is equal to the number of nodes the AR serves, whereas in the other two models, the AR sends a single RA to BS that is sent to all the MSs as separate RAs.
プレフィックスがRASで宣伝されている場合、ARは既存のプレフィックスを撤回し、新しいプレフィックスを宣伝する必要があります。リンクモデルに関係なく、各MSはIEEE 802.16接続指向アーキテクチャのためにMacレベルで別のポイントツーポイントリンクにあるため、ARは古いプレフィックスを引き出して新しいものをそれぞれに宣伝するRAを送信する必要がありますリンク。ポイントツーポイントリンクモデルでは、送信されるRAの数はARが提供するノードの数に等しくなりますが、他の2つのモデルでは、ARはすべてのMSSに送信される単一のRAを個別に送信します。ras。
If DHCP is used to assign addresses, either the DHCP address lease lifetime may be reduced prior to the renumbering event to encourage MSs to renew their addresses quickly, or a DHCP Reconfigure message may be sent to each of the MSs by the server to cause them to renew their addresses.
DHCPがアドレスを割り当てるために使用される場合、DHCPアドレスリースライフタイムのいずれかが、MSSがアドレスを迅速に更新することを奨励するために、変更イベントの前に削減される可能性があります。アドレスを更新する。
In conclusion, the amount of traffic on the air-interface is the same for all link models. However, the number of RAs sent by the AR to BS can be better compared to the other two models.
結論として、エアインターフェイス上のトラフィックの量は、すべてのリンクモデルで同じです。ただし、ARからBSに送信されるRAの数は、他の2つのモデルと比較して優れています。
If the network needs to deliver packets to an MS, which is in dormant mode, the AR pages the MS. The MS that is monitoring the paging channel receives the page and transitions out of the dormant mode to active mode. It establishes connectivity with the network by requesting and obtaining the radio resources. The network is then able to deliver the packets to the MS. In many networks, packets destined to an MS in dormant mode are buffered at the AR in the network until connectivity is established.
ネットワークが休眠モードのMSにパケットを配信する必要がある場合、ARはMSをページします。ページングチャネルを監視しているMSは、ページを受信し、休眠モードからアクティブモードに移行します。無線リソースを要求して取得することにより、ネットワークとの接続を確立します。ネットワークは、パケットをMSに配信できます。多くのネットワークでは、休眠モードでMSに運命づけられているパケットは、接続が確立されるまでネットワーク内のARでバッファリングされます。
Support for dormant MSs is critical in mobile networks, hence it is a necessary feature. Paging capability and optimizations possible for paging an MS are neither enhanced nor handicapped by the link model itself. However, the multicast capability within a link may cause for an MS to wake up for an unwanted packet. This can be avoided by filtering the multicast packets and delivering the packets to only for MSs that are listening for particular multicast packets. As the Shared IPv6 Prefix model does not have the multicast capability and the point-to-point link model has only one node on the link, neither has any effect on the dormant mode. The Ethernet-like link model may have the multicast capability, which requires filtering at the BS to support the dormant mode for the MSs.
休眠状態のMSSのサポートはモバイルネットワークで重要であるため、必要な機能です。MSのページングに可能なページング機能と最適化は、リンクモデル自体によって強化されたり、障害を引き起こしたりすることはできません。ただし、リンク内のマルチキャスト機能により、MSが不要なパケットを目覚めさせる可能性があります。これは、マルチキャストパケットをフィルタリングし、特定のマルチキャストパケットをリスニングしているMSSのみにパケットを配信することで回避できます。共有されたIPv6プレフィックスモデルにはマルチキャスト機能がなく、ポイントツーポイントリンクモデルにはリンク上の1つのノードのみがあり、休眠モードにも影響を与えません。イーサネット様リンクモデルにはマルチキャスト機能があり、MSSの休眠モードをサポートするためにBSでフィルタリングする必要があります。
The model used in an IEEE 802.16 network may have a significant impact on how routing protocols are run over such a network. The deployment model presented in this document discusses the least impacting model on routing as connectivity on the provider edge is intentionally limited to point-to-point connectivity from one BS to any one of multiple MSs. Any other deployment model may cause a significant impact on routing protocols, however, they are outside the scope of this document.
IEEE 802.16ネットワークで使用されるモデルは、そのようなネットワーク上でルーティングプロトコルの実行方法に大きな影響を与える可能性があります。このドキュメントに示されている展開モデルは、プロバイダーエッジの接続性が1つのBSから複数のMSSのいずれかへのポイントツーポイント接続に意図的に制限されるため、ルーティングに最も影響を与えないモデルについて説明しています。他の展開モデルは、ルーティングプロトコルに大きな影響を与える可能性がありますが、これらはこのドキュメントの範囲外です。
Ethernet-Like Link models would be used when the deployment requires the use of Ethernet CS, as this is the only model being proposed for the Ethernet CS and running IPv6 over Ethernet is well understood.
イーサネット様リンクモデルは、展開にイーサネットCSの使用が必要な場合に使用されます。これは、イーサネットCSとイーサネット上のIPv6を実行するために提案されている唯一のモデルであるため、よく理解されています。
For IP CS with IPv6 classifiers, a point-to-point link model appears to be the choice because of its simplicity for performing the DAD and because it does not break any existing applications nor requires defining any new protocol. However, the IPv6 shared prefix model would be defined if there is any interest from the service provider community.
IPv6分類器を使用したIP CSの場合、Point-to-Pointリンクモデルは、DADを実行するためのシンプルさと、既存のアプリケーションを壊さず、新しいプロトコルを定義する必要があるため、選択のように見えます。ただし、IPv6共有プレフィックスモデルは、サービスプロバイダーコミュニティから興味がある場合に定義されます。
This document provides the analysis of various IPv6 link models for IEEE 802.16 based networks, and as such does not introduce any new security threats. No matter what the link model is, the networks employ the same link-layer security mechanisms defined in [5]. However, the chosen link model affects the scope of link local communication, and this may have security implications for protocols that are designed to work within the link scope. This is the concern for a shared link model compared with other models wherein private resources e.g., personal printer, cannot be put onto a public WiMAX network. This may restrict the usage of a shared prefix model to enterprise environments. The Neighbor Discovery related security issues are document in [1] [2] and these are applicable for all the models described in this document. The model specific security considerations are documented in their respective protocol specifications.
このドキュメントは、IEEE 802.16ベースのネットワークのさまざまなIPv6リンクモデルの分析を提供するため、新しいセキュリティの脅威は導入されません。リンクモデルが何であれ、ネットワークは[5]で定義されている同じリンク層セキュリティメカニズムを採用しています。ただし、選択されたリンクモデルは、リンクローカル通信の範囲に影響し、これはリンクスコープ内で動作するように設計されたプロトコルにセキュリティに影響を与える可能性があります。これは、個人のプリンターなどのプライベートリソースがパブリックWimaxネットワークに載せることができない他のモデルと比較して、共有リンクモデルの懸念です。これにより、共有プレフィックスモデルの使用がエンタープライズ環境に使用される場合があります。近隣発見関連のセキュリティの問題は[1] [2]の文書であり、これらはこのドキュメントで説明されているすべてのモデルに適用されます。モデル固有のセキュリティに関する考慮事項は、それぞれのプロトコル仕様に文書化されています。
This document is a result of discussions in the v6subnet design team for IPv6 Prefix Model Analysis. The members of this design team are (in alphabetical order): Dave Thaler, David Johnston, Junghoon Jee, Max Riegel, Myungki Shin and Syam Madanapalli. The discussion in the DT was benefited from the active participation of James Kempf, Behcet Sarikaya, Basavaraj Patil and JinHyeock Choi in the DT mailing list. The DT thanks the chairs (Gabriel Montenegro and Soohong Daniel Park) and Shepherding AD (Jari Arkko) for their active participation and motivation.
このドキュメントは、IPv6プレフィックスモデル分析のためのV6Subnet設計チームでの議論の結果です。この設計チームのメンバーは（アルファベット順に）：Dave Thaler、David Johnston、Junghoon Jee、Max Riegel、Myungki Shin、Syam Madanapalliです。DTでの議論は、DTメーリングリストにJames Kempf、Behcet Sarikaya、Basavaraj Patil、Jinhyeock Choiの積極的な参加から恩恵を受けました。DTは、椅子（Gabriel MontenegroとSoohong Daniel Park）と、積極的な参加とモチベーションに感謝してくれたAD（Jari Arkko）に感謝します。
The members who provided the text based on the DT discussion are:
DTディスカッションに基づいてテキストを提供したメンバーは次のとおりです。
Myung-Ki Shin ETRI EMail: myungki.shin@gmail.com
myung-ki shin etriメール：myungki.shin@gmail.com
James Kempf DoCoMo Communications Labs USA EMail: kempf@docomolabs-usa.com
James Kempf Docomo Communications Labs USAメール：kempf@docomolabs-usa.com
Soohong Daniel Park Samsung Electronics EMail: soohong.park@samsung.com
Soohong Daniel Park Samsung Electronicsメール：Soohong.park@samsung.com
Dave Thaler Microsoft EMail: dthaler@microsoft.com
Dave Thaler Microsoftメール：dthaler@microsoft.com
JinHyeock Choi Samsung Advanced Institute of Technology EMail: jinchoe@samsung.com
Jinhyeock Choi Samsung Advanced Institute of Technology Email：jinchoe@samsung.com
Behcet Sarikaya Huawei USA EMail: sarikaya@ieee.org
Behcet Sarikaya Huawei USAメール：Sarikaya@ieee.org
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[3] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[4] "IEEE 802.16-2004, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed broadband wireless access systems", October 2004.
[4] 「IEEE 802.16-2004、ローカルおよびメトロポリタンエリアネットワークのIEEE標準、パート16：固定ブロードバンドワイヤレスアクセスシステムのエアインターフェイス」、2004年10月。
[5] "IEEE 802.16e, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems", October 2005.
[5] 「IEEE 802.16E、ローカルおよびメトロポリタンエリアネットワークのIEEE標準、パート16：固定およびモバイルブロードバンドワイヤレスアクセスシステム用エアインターフェイス」、2005年10月。
[6] Jee, J., "IP over IEEE 802.16 Problem Statement and Goals", Work in Progress, October 2006.
[6] Jee、J。、「IPオーバーIEEE 802.16問題声明と目標」、2006年10月、進行中の作業。
[7] 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.
[7] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[8] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[8] Wasserman、M。、「第3世代パートナーシッププロジェクト（3GPP）規格におけるIPv6の推奨」、RFC 3314、2002年9月。
[9] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[9] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPを超える（PPPOE）を送信する方法」、RFC 2516、1999年2月。
[10] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[10] Baker、F.、Lear、E。、およびR. Droms、「フラグの日なしでIPv6ネットワークを変更する手順」、RFC 4192、2005年9月。
[11] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q", May 2003.
[11] 2003年5月、「IEEE、仮想ブリッジ型ローカルエリアネットワーク、IEEE 802.1Q」。
[12] "IEEE, Port-based Network Access Control, IEEE 802.1X", December 2004.
[12] 「IEEE、ポートベースのネットワークアクセス制御、IEEE 802.1x」、2004年12月。
[13] "IEEE Std 802.1D-2004, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges"", June 2004.
[13] 「IEEE STD 802.1D-2004」、地元および大都市圏ネットワークのIEEE標準、メディアアクセス制御（MAC）ブリッジ」、2004年6月。
[14] "WiMAX End-to-End Network Systems Architecture", March 2007, <http://www.wimaxforum.org/technology/documents>.
[14] 「Wimaxのエンドツーエンドネットワークシステムアーキテクチャ」、2007年3月、<http://www.wimaxforum.org/technology/documents>。
Author's Address
著者の連絡先
Syam Madanapalli (editor) Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
Syam Madanapalli（編集者）Ordyn Technologies 1st Floor、クリエイタービルディング、ITPLバンガロール-560066インド
EMail: smadanapalli@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。