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
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）IETFトラスト（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つの方法につながります。一つの方法は、例えば、IEEE 802.1D [6]、双方向マルチキャストをサポートするようにブリッジを使用することです。もう一つの方法は、例えば、ARP（アドレス解決プロトコル（IPプロトコルように、ポイントツーポイントのIPリンクとしてMS（移動局）とBS（基地局）との間にIEEE 802.16 MAC（メッセージ認証コード）交通機関の接続を処理することです）、IPv6近隣探索）が問題なく実行することができます。
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トランスポート接続のすべての方法を拡張WiMAXのトランスポート接続を定義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.
アクセスサービスネットワーク（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.
このモデルでは、すべてのMSは、しかし、このモデルは任意のマルチキャスト機能を提供していない、彼らのグローバルIPv6アドレスを構築するためのARシェア1以上のプレフィックスに取り付けられています。以下の図は、リンク上でアドバタイズ一つ以上のプレフィックスがIPv6リンクに接続されているすべてのMSによって使用される前記リンクモデルの高レベル図を示します。
+-----+
| 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は、一の以上のBSを提供することができます。 ARによって提供されている基地局に接続されているすべてのMSが同じ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.
一の以上のIPv6プレフィックスがリンクに割り当てられ、したがって、リンクに接続されているすべてのノードによって共有されます。プレフィックスが設定自律フラグ（フラッグ）とオンリンクフラグ（L-フラグ）ノードは、それらのプレフィックスでアドレスのオンリンク仮定をすることができないように、アドレス自動設定にリセットしてアドバタイズされます。
The standard IPv6 address autoconfiguration mechanisms, which are specified in [2] [3], are used.
[2]で指定されている標準のIPv6アドレス自動設定機構、[3]は、使用されています。
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:
ネイティブマルチキャストサポートがないようにDAD手順は、で指定されている[2]、IEEE 802.16エアインタフェースにうまく適合しません。 DADは、MLD（マルチキャストリスナ発見）は、[7]スヌーピング及びアドレスリレーDADと呼ばれる、重複している場合には、ARは、アドレスの所有者にDADプローブの中継を行うことができます。この方法では、MSの動作は、[2]で指定され、最適化がマルチキャストアドレスとマルチキャストアドレスに参加したノードのリストについては、MLDテーブルを維持ARのサポート、で達成される。同じですリレーDADは、以下のように動作します：
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トランスポート接続に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発信DADに中継される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が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.
ネイティブオンリンクマルチキャストは、この方法では不可能ではありません。しかし、マルチキャストは、マルチキャスト・メンバーリストを維持し、ユニキャストのようにして、特定のマルチキャストグループに属するMSへマルチキャストパケットを転送ARにおけるバックエンドプロセスを使用してサポートすることができます。 MLDスヌーピング[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.
すべてのパケットは、レイヤ2トランスポート接続がMSとARとの間に存在するように最終的な宛先に配信される前に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.
このリンクモデルは、リレー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コンバージェンスサブレイヤと一緒に共有オンリンクのサービスを提供するために良いです。しかし、携帯電話ネットワークのような公衆アクセスネットワークでは、このモデルでは、公開して自分の個人的なデバイス/サービスのいずれかを共有するために、エンドユーザーのために使用することはできません。
This link model was also under consideration of the WiMAX Forum Network Working Group for use with IPv6 CS (Convergence Sublayer) access.
このリンクモデルは、IPv6 CS（コンバージェンス副層）のアクセスで使用するためにWiMAXフォーラムネットワークワーキンググループの検討中でもありました。
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つの方法は、[8]のリンク上でPPPを実行することです。 PPPを実行すると、IEEE 802.16リンクはイーサネット上でイーサネットCSとPPPを使用する必要があります[9]。 IPv6のCSはPPPをサポートしていないので、PPPを実行できるかどうかをネットワークアーキテクチャに依存します。
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.
PPPやVLANのどちらも使用されている場合は3、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フラグおよびLフラグの両方が、1に設定され、プレフィックスがリンク上にあります。
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.
MSは、[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 VLANのような任意の溶液、[9]または任意のL2トンネルを使用することができます。
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との間のリンクがポイントしているので、任意のマルチキャストは、1つまたは他のノードによって送信することができます。他のノードと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.各MSは、IEEE 802.1X [12]又は各MSは、MSへのすべての接続を集約およびIPv6層へのインタフェースとしての接続のこれらのセットを提示するARへのL2トンネルを有していなければならない別個の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.
企業ネットワークでは、プリンタ、ファックス、および他のそのようなオンラインサービスを含む共有サービスは、多くの場合、ローカルリンク上で利用可能です。これらのサービスは、通常、リンクローカルサービス発見プロトコルのいくつかの種類を使用して発見されます。 ASNにリンクサービスを共有していることはできないので、MSモデルごとに固有の接頭辞は、展開のこれらの種類には適していません。
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.
イーサネットのようなリンクを構築する一つの方法は、スイッチ、イーサネットのような、基地局とAR間のブリッジ[13]を実現することです。図4に、架橋を行うには、基地局と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.
オンリンクマルチキャストを効率よくのMSとBSの上にブリッジ間のリンクを提供するIEEE 802.16で全てのBS間のブリッジによってユニキャスト方法でエミュレートすることができます。 MLDスヌーピング[7]で指定されたマルチキャストパケットの効率的な転送のために使用されるべきです。それにもかかわらず、ブリッジングの場合には、直接の間のMSの通信が原因のサービスプロバイダからの制約のために許可されていないことはできません。
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).
分離されたAR-BSモデルの下でルータの実装に特別な影響は、ブリッジは、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.
プレフィックスはRAの中で宣伝されている場合は、ARは、既存のプレフィックスを撤回し、新しいものをアドバタイズする必要があります。各MS以来、関係なく、リンクモデルの、理由はIEEE 802.16接続指向アーキテクチャーのMACレベルでの個別のポイントツーポイントリンク上で、ARは、RA古いプレフィックスを引き抜くと、それぞれに新しいものを宣伝を送信する必要がありますリンク。他の二つのモデルにおいて、ARは別として全てのMSに送信されるBSに単一RAを送信する一方、ポイントツーポイントリンクモデルでは、送信されたRasの数は、ARが機能するノードの数に等しいです。 RA。
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アドレスのリース寿命がすぐに自分のアドレスを更新するためのMSを奨励するためにリナンバリングイベントに先立って減少させることができる、またはDHCP再設定メッセージは、サーバによってMSのそれぞれに送信することができる場合は、それらを引き起こしますそれらのアドレスを更新します。
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.
結論として、エア・インターフェイス上のトラフィックの量は、すべてのリンクモデルでも同じです。しかし、BSにARによって送信されたRasの数は、他の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.
休止状態のMSのサポートは、したがって、それは必要な機能であり、モバイルネットワーク上で重要です。ページング機能とMSをページングするための可能な最適化はどちらも強化されていないにもリンクモデル自体によって不利されています。ただし、リンク内のマルチキャスト機能は、不要なパケットのために目を覚ますためにMSのために発生することがあります。これは、マルチキャストパケットをフィルタリングし、特定のマルチキャストパケットを受信しているのMSのためだけにパケットを提供することで回避できます。共有のIPv6接頭語モデルは、マルチキャスト機能およびポイントツーポイントリンクモデルを持っていないため、リンク上のノードを1つだけ持っていない、どちらも休止モードに影響を持っています。イーサネットのようなリンクモデルは、MSのために休止モードをサポートする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ネットワークで使用されるモデルは、ネットワーク上で実行される方法ルーティングプロトコルに重大な影響を有していてもよいです。この文書の展開モデルは、意図的に複数のMSのいずれか1つの基地局からのポイントツーポイント接続に限定されるプロバイダエッジに接続としてルーティングに最も影響を与えるモデルを議論します。その他の展開モデルは、ルーティングプロトコルに重大な影響を引き起こす可能性があり、しかし、彼らはこの文書の範囲外です。
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のために提案されていると、イーサネット上でIPv6を実行しているが、よく理解されているよう展開が、イーサネットCSの使用を必要とする場合にイーサネットのようなリンクモデルが使用されます。
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の場合は、ポイントツーポイントリンクモデルは、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ネットワーク上に置くことはできませんここで他のモデルと比較して共有リンクモデルの関心事です。これは、エンタープライズ環境への共有プレフィックスモデルの使用を制限することができます。近隣探索関連のセキュリティ問題は、[2] [1]に文書であり、これらは、本文書に記載されているすべてのモデルに適用されます。モデル固有のセキュリティ上の考慮事項は、それぞれのプロトコル仕様に記載されています。
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デザインチームでの議論の結果です。この設計チームのメンバーは、（アルファベット順）です：デーブターラー、デビッド・ジョンストン、Junghoonジヨン、マックスリーゲル、Myungki新とSyam Madanapalli。 DTでの議論は、DTメーリングリストでジェームズ・ケンプ、ベーチェットSarikaya、BasavarajパティルとJinHyeockチェの積極的な参加の恩恵を受けました。 DTのおかげ椅子（ガブリエル・モンテネグロとSoohongダニエル・パーク）とその積極的な参加とモチベーションのための牧AD（ヤリArkko）。
The members who provided the text based on the DT discussion are:
DTの議論に基づいてテキストを提供するメンバーは以下のとおりです。
Myung-Ki Shin ETRI EMail: myungki.shin@gmail.com
明博新Etryメール：म्यूंगकी.शिन@जीमेल.कॉम
James Kempf DoCoMo Communications Labs USA EMail: kempf@docomolabs-usa.com
ジェームズ・ケンプドコモコミュニケーション研究所USA Eメール：kempf@docomolabs-usa.com
Soohong Daniel Park Samsung Electronics EMail: soohong.park@samsung.com
Soohongダニエル・パークサムスン電子メールアドレス：soohong.park@samsung.com
Dave Thaler Microsoft EMail: dthaler@microsoft.com
デーブターラーマイクロソフトの電子メール：dthaler@microsoft.com
JinHyeock Choi Samsung Advanced Institute of Technology EMail: jinchoe@samsung.com
テクノロジーのJinHyeockチェ・サムスン高度な研究所Eメール：jinchoe@samsung.com
Behcet Sarikaya Huawei USA EMail: sarikaya@ieee.org
ベーチェットSarikaya Huawei社USA Eメール：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.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "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]ジヨン、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]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[8] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[8]、RFC 3314、2002年9月ワッサーマン、M.、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための推奨事項"。
[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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[10] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[10]ベーカー、F.、リア、E.、およびR. Droms、 "フラグ日なしIPv6ネットワークをリナンバリングするための手順"、RFC 4192、2005年9月。
[11] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q", May 2003.
[11] "IEEE、仮想ブリッジローカルエリアネットワーク、IEEE 802.1Q"、2003年5月。
[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 802.1D STD-2004、 "地方とメトロポリタンエリアネットワークのためのIEEE規格、メディアアクセス制御（MAC）は2004年6月、"" BRIDGES。
[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
シャムmadanapalli（編集）ordhyamテクノロジーズ1つの側面バンガロールaitipil階、クリエータービル - 560066、インド
EMail: smadanapalli@gmail.com
メールアドレス：smadanapalli@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎と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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。