RFC4968 日本語訳
4968 Analysis of IPv6 Link Models for 802.16 Based Networks. S.Madanapalli, Ed.. August 2007. (Format: TXT=34536 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Madanapalli, Ed. Request for Comments: 4968 Ordyn Technologies Category: Informational August 2007
ワーキンググループS.Madanapalli、エドをネットワークでつないでください。コメントのために以下を要求してください。 4968年のOrdyn技術カテゴリ: 情報の2007年8月
Analysis of IPv6 Link Models for IEEE 802.16 Based Networks
IEEE802.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).
IETFが信じる著作権(C)(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.
このドキュメントは、IEEE802.16に適当な異なったIPv6リンクモデルにベースのネットワークを供給して、異なった展開シナリオの下でそれぞれのリンクモデルとそれぞれのリンクモデルの適用性に様々な問題の分析を供給します。 このドキュメントはIPv6リンクを分析するために形成されたデザインチーム(DT)の結果がIEEEのために802.16のベースのネットワークをモデル化するということです。
Madanapalli Informational [Page 1] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[1ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 IEEE802.16のIPv6リンクモデルはネットワーク. . . . . . . 3 3.1を基礎づけました。 共有されたIPv6はリンクモデル. . . . . . . . . . . . . . 3 3.1.1を前に置きます。 課題. . . . . . . . . . . . . . . . . . 5 3.1.2を前に置いてください。 自動構成. . . . . . . . . . . . . . 5 3.1.3を記述してください。 アドレス検出. . . . . . . . . . . . . 5 3.1.4をコピーしてください。 問題. . . . . . . . . . . . . . . . . . . . 6 3.1.5。 適用性. . . . . . . . . . . . . . . . . . . . 7 3.2。 ポイントツーポイント接続モデル. . . . . . . . . . . . . . . . 7 3.2.1。 課題. . . . . . . . . . . . . . . . . . 8 3.2.2を前に置いてください。 自動構成. . . . . . . . . . . . . . 8 3.2.3を記述してください。 問題. . . . . . . . . . . . . . . . . . . . 8 3.2.4。 適用性. . . . . . . . . . . . . . . . . . . . 9 3.3。 イーサネットのようなリンクモデル. . . . . . . . . . . . . . . . . 10 3.3.1。 課題. . . . . . . . . . . . . . . . . . 10 3.3.2を前に置いてください。 自動構成. . . . . . . . . . . . . . 10 3.3.3を記述してください。 アドレス検出. . . . . . . . . . . . . 10 3.3.4をコピーしてください。 問題. . . . . . . . . . . . . . . . . . . . 11 3.3.5。 適用性. . . . . . . . . . . . . . . . . . . . 11 4。 .115に番号を付け替えさせます。 眠っているモード. . . . . . . . . . . . . . . . . . . . 12 6への効果。 ルート設定. . . . . . . . . . . . . . . . . . . . . . 12 7への効果。 結論と関連リンクモデル. . . . . . . . . . . . . 13 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 10。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 14 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 14 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 14
1. Introduction
1. 序論
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.
IEEE802.16[4][5]はポイントツーマルチポイント、双方向のネイティブのマルチキャストサポートのない最後のマイル単位で接続指向のアクセス技術です。 IEEE802.16はダウンリンクマルチキャストサポートだけを定義しました。 これはリンクレイヤでマルチキャストの有用性を伝統的に仮定する走行IPプロトコルのための2つの方法に通じます。 1つの方法は両性愛者の方向のマルチキャストを支持するのに橋を架ける例えばIEEE 802.1D[6]を使用することです。 別の方法は二地点間IPがIPプロトコル(例えば、ARP(アドレスResolutionプロトコル)、IPv6 Neighborディスカバリー)が少しも問題なしで走ることができるようにリンクされるときMS(モバイル駅)とBS(基地の駅)とのIEEE802.16MAC(メッセージ立証コード)輸送の接続を扱うことです。
Madanapalli Informational [Page 2] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[2ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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.
これは基地局とアクセスルータ[14]の間のトンネルを使用することによってIEEE802.16MAC輸送接続をアクセスルータまでのいっぱいに広げるWiMAX輸送接続を定義するWiMAXのような商業ネットワークモデルの定義でさらに複雑にされます。 これはベースのネットワークをIEEE802.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.
IEEE802.16のためにリンクモデルを選ぶことにおける様々な問題における面相が基礎づけたこのドキュメントは、様々な可能なリンクモデルの分析をネットワークでつないで、提供します。 そして、最終的に、このドキュメントは1つの展開に最も十分適したリンクモデルを選ぶための推薦を提供します。
2. Terminology
2. 用語
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 Networksでは、ARはAccess Service Networkゲートウェイです。
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.
アクセス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に関して状態を維持します。
3. IPv6 Link Models for IEEE 802.16 Based Networks
3. IEEE802.16のIPv6リンクモデルはネットワークを基礎づけました。
This section discusses various IPv6 link models for IEEE 802.16 based networks and provides their operational considerations in practical deployment scenarios.
このセクションは、IEEE802.16に基づいているネットワークのために様々なIPv6リンクモデルについて論じて、それらの操作上の問題を実用的な展開シナリオに提供します。
3.1. Shared IPv6 Prefix Link Model
3.1. 共有された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
このモデルでは、ARに取り付けられたすべてのMSsがそれらのグローバルなIPv6アドレスを構成するために1つ以上の接頭語を共有して、しかしながら、このモデルは少しのマルチキャスト能力も提供しません。 以下の数字はどの点で1つか、より多くであるこのリンクモデルのハイレベルの眺めを例証します。
Madanapalli Informational [Page 3] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[3ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
prefixes advertised on the link would be used by all the MSs attached to the IPv6 link.
リンクの上に広告に掲載された接頭語はIPv6リンクに取り付けられたすべてのMSsによって使用されるでしょう。
+-----+
| MS1 |-----+
+-----+ |
|
|
+-----+ | +-----+ +--------+
| MS2 |-----+-----| BS1 |----------| AR |-------Internet
+-----+ | +-----+ +--------+
. | ____________
. | ()__________()
+-----+ | L2 Tunnel
| MSn |-----+
+-----+
+-----+ | MS1|-----+ +-----+ | | | +-----+ | +-----+ +--------+ | MS2|-----+-----| BS1|----------| アルゴン|-------インターネット+-----+ | +-----+ +--------+ . | ____________ . | ()__________() +-----+ | L2トンネル| 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との下層リンクはポイントツーポイント接続です。 BSとARの間のトンネルの粒状がMS基礎あたりのaにあるとき、MSとBSとのこのポイントツーポイント接続はARまでのいっぱいに広げられます。 これは以下の以下の図で例証されます。
MS
+----+ +----+
| | IPv6 (Shared link) | |
| L3 |=====================================| |
| | | |
|----| PTP conn. +----+ L2 Tunnel | AR |---Internet
| L2 |-------------| BS |==================| |
| | | | | |
+----+ +----+ | |
| |
+----+ L2 Tunnel | |
| BS |==================| |
| | | |
+----+ +----+
MS+----+ +----+ | | IPv6(共有されたリンク)| | | L3|=====================================| | | | | | |----| PTPコン。 +----+ L2トンネル| アルゴン|---インターネット| L2|-------------| BS|==================| | | | | | | | +----+ +----+ | | | | +----+ L2トンネル| | | BS|==================| | | | | | +----+ +----+
Figure 2. Shared IPv6 Prefix Link Model - Layered View
図2。 共有されたIPv6はリンクモデルを前に置きます--視点を層にします。
Madanapalli Informational [Page 4] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[4ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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は1BSsに役立つことができます。 同じIPv6リンクの上にARによって役立たれているBSsに接続されたすべてのMSsがあります。 このモデルは後のモデルがイーサネットリンク抽象化とマルチキャスト能力を供給するイーサネットLike LinkモデルからIPv6層まで異なっていますが、ここで定義されたShared IPv6 Prefix Link Modelはネイティブのリンクレイヤマルチキャストと放送能力を提供しません。
3.1.1. Prefix Assignment
3.1.1. 接頭語課題
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-旗)のセットとOn-リンク旗(L-旗)で接頭語の広告を出します。
3.1.2. Address Autoconfiguration
3.1.2. アドレス自動構成
The standard IPv6 address autoconfiguration mechanisms, which are specified in [2] [3], are used.
標準のIPv6アドレス自動構成メカニズム([2][3]で指定される)は使用されています。
3.1.3. Duplicate Address Detection
3.1.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:
どんなネイティブのマルチキャストサポートもないとき、[2]で指定されるDAD手順はIEEE802.16空気インタフェースによく順応しません。 Relay DADは、MLD(マルチキャストListenerディスカバリー)が[7]について詮索している状態でDADを実行できて、DADをリレーするARがアドレスが写しであるといけないのでアドレス所有者に調べると呼びました。 この方法で、MSの振舞いは[2]で指定されるのと同じです、そして、最適化はARのサポートによって達成されます。(ARはマルチキャストアドレスを接合したマルチキャストアドレスとノードのリストのためにMLDテーブルを維持します)。 リレーDADは以下で働いています:
1. An MS constructs a Link Local Address as specified in [2].
1. MSは[2]の指定されるとしてのLink Local Addressを組み立てます。
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は対応するLink Local Addressのために請求されたノードマルチキャストアドレスを構成して、請求されたノードマルチキャストアドレスのためにMLD Join要求を送ります。
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をリレーします。
Madanapalli Informational [Page 5] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[5ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
5. The address owner defends the address by sending DAD NA, which is
relayed to the DAD originating MS via the AR.
5. アドレス所有者は、DAD NAを送ることによって、アドレスを防御します。(DAD NAはARを通してDADの由来しているMSにリレーされます)。
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. DADの由来しているMSがDAD NSへの少しの応答(DAD NA)も受けないなら、MSはアドレスをインタフェースに割り当てます。 MSがDAD NAを受けるなら、MSは一時的なアドレスを捨てて、[2]で指定されるように振る舞います。
3.1.4. Considerations
3.1.4. 問題
3.1.4.1. Reuse of Existing Specifications
3.1.4.1. 既存の仕様の再利用
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接頭語モデルは、既存の仕様を使用して、どんなプロトコル変化かどんな新しいプロトコルも必要としません。 しかしながら、このモデルはDAD最適化のためにARで実現変化を求めます。
3.1.4.2. On-link Multicast Support
3.1.4.2. リンクにおけるマルチキャストサポート
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.
リンクの上のどんなネイティブのマルチキャストもこの方法で可能ではありません。 しかしながら、マルチキャストメンバーリストとフォワードがマルチキャストパケットであることをユニキャスト方法で特定のマルチキャストグループのものMSsに支持するARのバックエンドの過程を使用するのはマルチキャストを支持できます。 [7]について詮索するMLDは、マルチキャストメンバーリストを維持するのに使用されるべきです。
3.1.4.3. Consistency in IP Link Definition
3.1.4.3. IPリンク定義における一貫性
The definition of an IPv6 link is consistent for all procedures and functionalities except for the support of native on-link multicast support.
すべての手順とリンクにおけるネイティブのマルチキャストサポートのサポート以外の機能性において、IPv6リンクの定義は一貫しています。
3.1.4.4. Packet Forwarding
3.1.4.4. パケット推進
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によって目的地にリレーされます。
3.1.4.5. Changes to Host Implementation
3.1.4.5. ホスト導入への変化
This link model does not require any implementation changes for the host implementation.
このリンクモデルはホスト導入のためにどんな実現変化も求めません。
Madanapalli Informational [Page 6] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[6ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
3.1.4.6. Changes to Router Implementation
3.1.4.6. ルータ実現への変化
This link model requires MLD snooping in the AR for supporting Relay DAD.
このリンクモデルはRelay DADを支持するためにARで詮索するMLDを必要とします。
3.1.5. Applicability
3.1.5. 適用性
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(集合Sublayer)アクセサリーをもって使用のためのWiMAX Forum Network作業部会の考慮でもありました。
3.2. Point-to-Point Link Model
3.2. ポイントツーポイント接続モデル
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との1セットのMAC輸送の接続は単一のリンクとして扱われます。 ポイントツーポイント接続モデルは[8]の推薦の後をつけます。 このモデルでは、MSとARとの各リンクはARによって別々の、そして、ユニークな接頭語かユニークな接頭語のセットに割り当てられます。 ARの下の他のどんなノードもそれとARとのリンクの上に同じ接頭語を持っていません。 以下のダイヤグラムはこのモデルを例証します。
+----+ +----+
+-----+ | | Tunnel | |
| MS1 |-------------|....|===================| |
+-----+ | | | |
| | | |
+-----+ | | Tunnel | |
| MS2 |-------------|....|===================| |---Internet
+-----+ | | | AR |
| BS | | |
+-----+ | | Tunnel | |
| MS3 |-------------|....|===================| |
+-----+ | | | |
+----+ +----+
+----+ +----+ +-----+ | | トンネル| | | MS1|-------------|....|===================| | +-----+ | | | | | | | | +-----+ | | トンネル| | | MS2|-------------|....|===================| |---インターネット+-----+ | | | アルゴン| | BS| | | +-----+ | | トンネル| | | 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の間でリンクする道を実行できるのが可能な状態で、あります。
Madanapalli Informational [Page 7] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[7ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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. これを達成する1つの方法はリンク[8]でPPPを走らせることです。 走行PPPは、IEEE802.16リンクがイーサネット[9]の上でイーサネットCSとPPPを使用するのを必要とします。 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.
3. PPPもVLANも使用されていません、IEEEのセット。仮想のポイントツーポイント接続として802.16の接続は見なすことができます。
3.2.1. Prefix Assignment
3.2.1. 接頭語課題
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]ルータAdvertisementメカニズムを使用することでリンクに割り当てられます。 ARはユニークな接頭語かユニークな接頭語のセットを各MSに割り当てます。接頭語情報オプションでは、A-旗とL-旗の両方は1に設定されます、アドレス自動構成にそれらを使用できて、リンクの上に接頭語があるとき。
3.2.2. Address Autoconfiguration
3.2.2. アドレス自動構成
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]のちょうど指定されるとしてのグローバルアドレス自動構成と同様に地方のリンクを実行します。 他の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がアドレス構成(Router Advertisementの'M=1')に使用されるなら、DHCPサーバは1MSあたり1つの別々の接頭語をアドレスに提供しなければなりません。接頭語はもちろん、ASNゲートウェイがMS(もしあれば)に広告を出した接頭語に合わなければなりません。
3.2.3. Considerations
3.2.3. 問題
3.2.3.1. Reuse of Existing Specifications
3.2.3.1. 既存の仕様の再利用
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.
この解決策はPPPが使用されているときのRFC2461、2462、RFC2472、およびRFC2516を再利用します。 これらのプロトコルにおける変化は全く必要ではありません。 適切にプロトコルを構成するだけでよいです。
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解決策も使用できます。
Madanapalli Informational [Page 8] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[8ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
3.2.3.2. On-link Multicast Support
3.2.3.2. リンクにおけるマルチキャストサポート
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は見られないでしょう。
3.2.3.3. Consistency in IP Link Definition
3.2.3.3. IPリンク定義における一貫性
The IP link is fully consistent with a standard IP point-to-point link, without exception.
IPリンクは例外なしで標準のIPポイントツーポイント接続と完全に一致しています。
3.2.3.4. Packet Forwarding
3.2.3.4. パケット推進
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つだけの間に送ります。
3.2.3.5. Changes to Host Implementation
3.2.3.5. ホスト導入への変化
Host implementations follow standard IPv6 stack procedures. No changes are needed.
ホスト導入は標準のIPv6スタック手順に従います。 変化は全く必要ではありません。
3.2.3.6. Changes to Router Implementation
3.2.3.6. ルータ実現への変化
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がIPv6層へのインタフェースとしてこれらが設定する接続のMSと現在とのすべての接続に集めるためにL2トンネルをARに持たなければならないと、別々のVLANは各MSに割り当てられます。
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. 各MSへの接頭語のユニークな接頭語かセットを含むようにARを構成しなければなりません。彼らを送るときはいつも、Router Advertisementsにこのユニークな接頭語かセットの接頭語を含まなければなりません、そして、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.
ルータ実現によって、これらの機能が簡単な構成で可能であるかもしれないことに注意してください。 しかしながら、プロトコル変化は全く必要ではありません。
3.2.4. Applicability
3.2.4. 適用性
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
企業網では、プリンタ、ファックス装置、および他のそのようなオンラインサービスを含む共有されたサービスは地方のリンクでしばしば利用可能です。 これらのサービスはある種のリンクローカル・サービス発見プロトコルを使用していると通常発見されます。 1MSあたりのユニークな接頭語
Madanapalli Informational [Page 9] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[9ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
model is not appropriate for these kinds of deployments, since it is not possible to have shared link services in the ASN.
これらの種類の展開には、モデルは適切ではありません、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.
共有されたサービスが全くASNにないところでp2pリンクモデルは展開に適切です。 そのような展開はセルラー・ネットワークのようなサービスプロバイダーネットワークの典型です。(セルラー・ネットワークはパブリックアクセスをワイヤレス・ネットワークに提供します)。
3.3. Ethernet-Like Link Model
3.3. イーサネットのようなリンクモデル
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].
このモデルがIEEE802.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
+-----+ +---+ +----+ | MS1|---+ | | +---|AR1|---インターネット+-----+ | | S| | +----+ +-----+ | +-----+ |E w| | | MS2|---+---| BS1|---|t i| | +-----+ +-----+ |h t|---+ | c| | +----+ +-----+ +-----+ +-----+ | h| +---|AR2|---インターネット|ホスト|--|さん/GW|-------| BS2|---| | +----+ +-----+ +-----+ +-----+ +---+ ネットワークはMS/GWの後ろに存在するかもしれません。
Figure 4: Ethernet Like Link Model
図4: リンクモデルのようなイーサネット
3.3.1. Prefix Assignment
3.3.1. 接頭語課題
Prefixes are assigned as specified in [1], [2].
接頭語は[1]、[2]で指定されるように割り当てられます。
3.3.2. Address Autoconfiguration
3.3.2. アドレス自動構成
It is the same as described in [2].
それは[2]で説明されるのと同じです。
3.3.3. Duplicate Address Detection
3.3.3. アドレス検出をコピーしてください。
It is the same as described in [2].
それは[2]で説明されるのと同じです。
Madanapalli Informational [Page 10] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[10ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
3.3.4. Considerations
3.3.4. 問題
3.3.4.1. Reuse of Existing Specifications
3.3.4.1. 既存の仕様の再利用
All the IPv6 standards can be preserved or reused in this model.
このモデルですべてのIPv6規格を保存するか、または再利用できます。
3.3.4.2. On-link Multicast Support
3.3.4.2. リンクにおけるマルチキャストサポート
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.
BSの上にすべての間に効率的にIEEE802.16がMSsの間のリンクを提供しているBSsと橋に橋を架けることによって、ユニキャスト方法でリンクの上のマルチキャストを見習うことができます。 MLD詮索は[7]の指定されるとしてのマルチキャストパケットの効率的な推進に使用されるべきです。 それにもかかわらず、橋を架けることの場合に、ダイレクト相互MSsコミュニケーションは制限のためサービスプロバイダーから許容されるかもしれません。
3.3.4.3. Consistency in IP Link Definition
3.3.4.3. IPリンク定義における一貫性
This model is consistent with the IP link definition.
このモデルはIPリンク定義と一致しています。
3.3.4.4. Packet Forwarding
3.3.4.4. パケット推進
When properly configured and assisted by simple bridging, IEEE 802.16 can emulate a simple broadcast network like Ethernet.
簡単な橋を架けることで適切に構成されて、補助されると、IEEE802.16はイーサネットのような簡単な放送網を見習うことができます。
3.3.4.5. Changes to Host Implementation
3.3.4.5. ホスト導入への変化
No special impact on host implementation.
ホスト導入への特別な影響がありません。
3.3.4.6. Changes to Router Implementation
3.3.4.6. ルータ実現への変化
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ゲートウェイ)で実行されるのを必要とするものもあるかもしれません。
3.3.5. Applicability
3.3.5. 適用性
This model works with the Ethernet CS and is chosen for fixed/nomadic WiMAX networks by the WiMAX Forum Network Working Group.
このモデルは、イーサネットCSと共に取り組んで、WiMAX Forum Network作業部会によって修理されたか遊牧民的なWiMAXネットワークに選ばれています。
4. Renumbering
4. 番号を付け替えること
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,
接頭語がRAsの広告に掲載されるなら、ARは既存の接頭語を引き下がらせて、新しい方の広告を出さなければなりません。 各MS以来
Madanapalli Informational [Page 11] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[11ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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.
リンクモデルにおいて関係なくて、MACの別々のポイントツーポイント接続の上にレベルが古い接頭語を引き下がらせるRAが指向の構造、ARが送られなければならなくて、新しい方のそれぞれに広告を出すとリンクされるIEEE802.16接続のためにありますか? ポイントツーポイント接続モデルでは、ARは他の2つのモデルで別々のRAsとしてすべてのMSsに送られるBSに独身のRAを送りますが、送られたRAsの数はARが役立つノードの数と等しいです。
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がすぐに彼らのアドレスを更新するよう奨励する番号を付け替える出来事の前に生涯を変えるかもしれませんか、またはサーバでDHCP Reconfigureメッセージをそれぞれの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に送られたRAsの数を他の2つのモデルにたとえることができるほうがよいです。
5. Effect on Dormant Mode
5. 眠っているモードへの効果
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のための唯一へのパケットを提供することによって、これを避けることができます。 Shared IPv6 Prefixモデルにはマルチキャスト能力がなくて、またポイントツーポイント接続モデルがリンクの上の1つのノードしか持っていないとき、眠っているモードへのどんな効果もそうしません。 イーサネットのようなリンクモデルには、マルチキャスト能力があるかもしれません。(それは、MSsのために眠っているモードをサポートするためにBSでフィルターにかけるのを必要とします)。
6. Effect on Routing
6. ルート設定への効果
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
IEEE802.16ネットワークに使用されるモデルはルーティング・プロトコルがどうそのようなネットワークの上に実行されるかの重要な影響を与えるかもしれません。 プロバイダー縁の接続性が議論するように本書では提示された展開モデルはルーティングで最も影響を与えていないモデルについて議論します。
Madanapalli Informational [Page 12] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[12ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
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.
故意に1BSから複数のMSsのいずれまでも二地点間接続性に制限されています。 いかなる他の展開モデルもルーティング・プロトコルで重要な影響を引き起こすかもしれなくて、このドキュメントの範囲の外にしかしながら、それらはあります。
7. Conclusions and Relevant Link Models
7. 結論と関連リンクモデル
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の使用を必要とするとき、イーサネットで好きなLinkモデルは使用されるでしょう、これがイーサネット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に関しては、ポイントツーポイント接続モデルは、DADを実行するための簡単さのためそれが、少しの既存のアプリケーションも破らないで、どんな新しいプロトコルも定義するのを必要とするので選択であるように見えます。 しかしながら、何かサービスプロバイダー共同体からの関心があれば、IPv6の共有された接頭語モデルは定義されるでしょう。
8. Security Considerations
8. セキュリティ問題
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の様々なIPv6リンクモデルの分析に802.16のベースのネットワークを提供して、そういうものとして少しの新しい軍事的脅威も導入しません。 リンクモデルが者であっても、ネットワークは[5]で定義された同じリンクレイヤセキュリティー対策を使います。 しかしながら、選ばれたリンクモデルはリンクのローカルのコミュニケーションの範囲に影響します、そして、これには、リンク範囲の中で働くように設計されているプロトコルのためのセキュリティ意味があるかもしれません。 他と比べたモデルがどの点でをモデル化するという共有されたリンクに関する心配は個人的なリソースです。これ、例えば、個人的なプリンタ、公立のWiMAXネットワークに置くことができません。 これは共有された接頭語モデルの使用法を企業環境に制限するかもしれません。 Neighborのディスカバリーの関連する安全保障問題は[1][2]のドキュメントです、そして、本書では説明されたすべてのモデルに、これらは適切です。 モデルの特定のセキュリティ問題はそれらのそれぞれのプロトコル仕様に記録されます。
9. Acknowledgements
9. 承認
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 Prefix Model Analysisのためのv6subnetデザインチームで、議論の結果です。 このデザインチームのメンバーは(アルファベット順に)以下の通りです。 デーヴThaler、デヴィッド・ジョンストン、Junghoon Jee、マックス・リーゲル、Myungki向こうずね、およびSyam Madanapalli。 DTでの議論がジェームス・ケンフ、Behcet Sarikayaの積極的な参加からためになられて、BasavarajはDTメーリングリストのパティルとJinHyeockチェです。 DT感謝いす(ガブリエル・モンテネグロとSoohongダニエルPark)と彼らの積極的な参加と動機のためのShepherding西暦(ヤリArkko)。
Madanapalli Informational [Page 13] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[13ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
10. Contributors
10. 貢献者
The members who provided the text based on the DT discussion are:
DT議論に基づくテキストを提供したメンバーは以下の通りです。
Myung-Ki Shin ETRI EMail: myungki.shin@gmail.com
ミュング-気向こうずねのETRIはメールします: myungki.shin@gmail.com
James Kempf DoCoMo Communications Labs USA EMail: kempf@docomolabs-usa.com
ジェームスケンフDoCoMoコミュニケーション研究室米国はメールされます: 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チェ三星高度先端技術研究所EMail: jinchoe@samsung.com
Behcet Sarikaya Huawei USA EMail: sarikaya@ieee.org
Behcet Sarikaya Huawei米国メール: sarikaya@ieee.org
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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)のための隣人発見」、RFC2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[2] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
11.2. Informative References
11.2. 有益な参照
[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] 「IEEE802.16-2004、LocalとメトロポリタンエリアネットワークのIEEE規格、Part16: 固定広帯域のワイヤレス・アクセスシステムのためにInterfaceを放送してください」、2004年10月。
Madanapalli Informational [Page 14] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[14ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
[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、LocalとメトロポリタンエリアネットワークのIEEE規格、Part16: 修理されてモバイルの広帯域のワイヤレス・アクセスシステムのためにInterfaceを放送してください」、2005年10月。
[6] Jee, J., "IP over IEEE 802.16 Problem Statement and Goals",
Work in Progress, October 2006.
[6] J.、「IEEE802.16問題声明と目標の上のIP」というJeeは進歩、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、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、2006年5月。
[8] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314,
September 2002.
[8] ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、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.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるためのメソッド(PPPoE)」、RFC2516(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] ベイカー、F.、リア、E.、およびR.Droms、「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
[11] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q",
May 2003.
[11] 「IEEE、仮想のブリッジしているローカル・エリア・ネットワーク、IEEE 802.1Q」は2003がそうするかもしれません。
[12] "IEEE, Port-based Network Access Control, IEEE 802.1X",
December 2004.
[12]、2004年12月に「IEEEの、そして、ポートを拠点とするネットワークはコントロール、IEEE 802.1Xにアクセスします」。
[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、「LocalのためのIEEE Standardとメトロポリタンエリアネットワーク、メディアAccess Control(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/技術/ドキュメント>。
Author's Address
作者のアドレス
Syam Madanapalli (editor) Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
Syam Madanapalliの(エディタ)Ordyn技術1階、創造者ビル、ITPLバンガロール--560066インド
EMail: smadanapalli@gmail.com
メール: smadanapalli@gmail.com
Madanapalli Informational [Page 15] RFC 4968 IPv6 Link Models for IEEE 802.16 August 2007
Madanapalliの情報[15ページ]のRFC4968IPv6は2007年8月にIEEE802.16のためにモデルをリンクします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Madanapalli Informational [Page 16]
Madanapalli情報です。[16ページ]
一覧
スポンサーリンク
