RFC5121 日本語訳

5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S.Madanapalli. February 2008. (Format: TXT=50092 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           B. Patil
Request for Comments: 5121                        Nokia Siemens Networks
Category: Standards Track                                         F. Xia
                                                             B. Sarikaya
                                                              Huawei USA
                                                                JH. Choi
                                                             Samsung AIT
                                                          S. Madanapalli
                                                      Ordyn Technologies
                                                           February 2008

コメントを求めるワーキンググループB.パティルの要求をネットワークでつないでください: 5121 ノキアシーメンスはカテゴリをネットワークでつなぎます: 規格はF.シャーB.Sarikaya Huawei米国JHを追跡します。 チェ三星オート麦S.Madanapalli Ordyn技術2008年2月

         Transmission of IPv6 via the IPv6 Convergence Sublayer
                       over IEEE 802.16 Networks

IEEE802.16Networksの上のIPv6 Convergence Sublayerを通したIPv6のトランスミッション

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   IEEE Std 802.16 is an air interface specification for fixed and
   mobile Broadband Wireless Access Systems.  Service-specific
   convergence sublayers to which upper-layer protocols interface are a
   part of the IEEE 802.16 MAC (Medium Access Control).  The Packet
   convergence sublayer (CS) is used for the transport of all packet-
   based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN
   CSMA/CD Access Method (Ethernet).  IPv6 packets can be sent and
   received via the IP-specific part of the Packet CS.  This document
   specifies the addressing and operation of IPv6 over the IP-specific
   part of the Packet CS for hosts served by a network that utilizes the
   IEEE Std 802.16 air interface.  It recommends the assignment of a
   unique prefix (or prefixes) to each host and allows the host to use
   multiple identifiers within that prefix, including support for
   randomly generated interface identifiers.

IEEE Std802.16は修理されてモバイルのBroadband Wireless Access Systemsのための空気インターフェース仕様です。上側の層のプロトコルが連結するサービス特有の集合副層はIEEE802.16MAC(中型のAccess Control)の一部です。 Packet集合副層(CS)はパケットインターネットプロトコル(IP)やIEEE802.3LAN/MAN CSMA/CD Access Method(イーサネット)などのベースのプロトコルの輸送に使用されます。 Packet CSのIP特有の部分でIPv6パケットを送って、受け取ることができます。 このドキュメントはIEEE Std802.16空気インタフェースを利用するネットワークによって役立たれたホストにIPv6のアドレシングと操作をPacket CSのIP特有の部分の上指定します。 それは、ユニークな接頭語(または、接頭語)の課題を各ホストに推薦して、ホストがその接頭語の中で複数の識別子を使用するのを許容します、手当たりしだいに発生しているインタフェース識別子のサポートを含んでいて。

Patil, et al.               Standards Track                     [Page 1]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[1ページ]RFC5121IPv6

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   4.  IEEE 802.16 Convergence Sublayer Support for IPv6  . . . . . .  4
     4.1.  IPv6 Encapsulation over the IP CS of the MAC . . . . . . .  7
   5.  Generic Network Architecture Using the 802.16 Air Interface  .  8
   6.  IPv6 Link  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  IPv6 Link in 802.16  . . . . . . . . . . . . . . . . . . .  9
     6.2.  IPv6 Link Establishment in 802.16  . . . . . . . . . . . . 10
     6.3.  Maximum Transmission Unit in 802.16  . . . . . . . . . . . 11
   7.  IPv6 Prefix Assignment . . . . . . . . . . . . . . . . . . . . 12
   8.  Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Router Solicitation  . . . . . . . . . . . . . . . . . . . 12
     8.2.  Router Advertisement . . . . . . . . . . . . . . . . . . . 12
     8.3.  Router Lifetime and Periodic Router Advertisements . . . . 13
   9.  IPv6 Addressing for Hosts  . . . . . . . . . . . . . . . . . . 13
     9.1.  Interface Identifier . . . . . . . . . . . . . . . . . . . 13
     9.2.  Duplicate Address Detection  . . . . . . . . . . . . . . . 13
     9.3.  Stateless Address Autoconfiguration  . . . . . . . . . . . 14
     9.4.  Stateful Address Autoconfiguration . . . . . . . . . . . . 14
   10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     13.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  WiMAX Network Architecture and IPv6 Support . . . . . 17
   Appendix B.  IPv6 Link in WiMAX  . . . . . . . . . . . . . . . . . 19
   Appendix C.  IPv6 Link Establishment in WiMAX  . . . . . . . . . . 19
   Appendix D.  Maximum Transmission Unit in WiMAX  . . . . . . . . . 20

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 コンベンションは本書では.4 4を使用しました。 IPv6. . . . . . 4 4.1のIEEE802.16集合副層サポート。 MAC. . . . . . . 7 5のIP Csの上のIPv6カプセル化。 802.16空気インタフェース. 8 6を使用するジェネリックネットワークアーキテクチャ。 IPv6は.96.1をリンクします。 IPv6は802.16で.96.2にリンクします。 IPv6は.106.3に802.16への設立をリンクします。 マキシマム・トランスミッション・ユニットコネ802.16.117。 IPv6は課題. . . . . . . . . . . . . . . . . . . . 12 8を前に置きます。 ルータ発見. . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 ルータ懇願. . . . . . . . . . . . . . . . . . . 12 8.2。 ルータ通知. . . . . . . . . . . . . . . . . . . 12 8.3。 ルータ生涯と周期的なルータ通知. . . . 13 9。 ホスト. . . . . . . . . . . . . . . . . . 13 9.1のためのIPv6アドレシング。 識別子. . . . . . . . . . . . . . . . . . . 13 9.2を連結してください。 アドレス検出. . . . . . . . . . . . . . . 13 9.3をコピーしてください。 状態がないアドレス自動構成. . . . . . . . . . . 14 9.4。 Statefulは自動構成. . . . . . . . . . . . 14 10を扱います。 マルチキャストリスナー発見. . . . . . . . . . . . . . . . . 14 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 14 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 16付録A.WiMAXネットワークアーキテクチャとIPv6サポート. . . . . 17付録B.IPv6はWiMAX. . . . . . . . . 20でWiMAXへのWiMAX. . . . . . . . . . . . . . . . . 19付録C.IPv6リンク設立で.19付録D.マキシマム・トランスミッション・ユニットリンクします。

Patil, et al.               Standards Track                     [Page 2]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[2ページ]RFC5121IPv6

1.  Introduction

1. 序論

   IEEE 802.16e is an air interface for fixed and mobile broadband
   wireless access systems.  The IEEE 802.16 [802.16] standard specifies
   the air interface, including the Medium Access Control (MAC) layer
   and multiple physical layer (PHY) specifications.  It can be deployed
   in licensed as well as unlicensed spectrum.  While the PHY and MAC
   are specified in IEEE 802.16, the details of IPv4 and IPv6 operation
   over the air interface are not included.  This document specifies the
   operation of IPv6 over the IEEE 802.16 air interface.

IEEE 802.16eは修理されてモバイルの広帯域のワイヤレス・アクセスシステムのための空気インタフェースです。IEEE802.16[802.16]規格は空気インタフェースを指定します、Medium Access Control(MAC)層と複数の物理的な層(PHY)の仕様を含んでいて。 認可されて無免許のスペクトルでそれを配布することができます。 PHYとMACはIEEE802.16で指定されますが、空気インタフェースの上のIPv4とIPv6操作の詳細は含まれていません。 このドキュメントはIEEE802.16空気インタフェースの上でIPv6の操作を指定します。

   IPv6 packets can be carried over the IEEE Std 802.16 specified air
   interface via:

以下を通ってIEEE Std802.16の指定された空気インタフェースの上までIPv6パケットを運ぶことができます。

   1.  the IP-specific part of the Packet CS or

または1. Packet CSのIP特有の部分。

   2.  the 802.3[802.3]-specific part of the Packet CS

2. Packet CSの802.3[802.3]特有の部分

   The scope of this specification is limited to the operation of IPv6
   over IP CS only.

この仕様の範囲はIP CSだけの上でIPv6の操作に制限されます。

   The IEEE 802.16 specification includes the PHY and MAC details.  The
   convergence sublayers are a part of the MAC.  The packet convergence
   sublayer includes the IP-specific part that is used by the IPv6
   layer.

IEEE802.16仕様はPHYとMACの詳細を含んでいます。 集合副層はMACの一部です。 パケット集合副層はIPv6層によって使用されるIP特有の部分を含んでいます。

   The mobile station (MS)/host is attached to an access router via a
   base station (BS).  The host and the BS are connected via the IEEE
   Std 802.16 air interface at the link and physical layers.  The IPv6
   link from the MS terminates at an access router that may be a part of
   the BS or an entity beyond the BS.  The base station is a layer 2
   entity (from the perspective of the IPv6 link between the MS and
   access router (AR)) and relays the IPv6 packets between the AR and
   the host via a point-to-point connection over the air interface.

移動局の(MS)/ホストは基地局(BS)を通ってアクセスルータに付けられています。 ホストとBSはリンクと物理的な層のIEEE Std802.16空気インタフェースを通して接されます。 BSを超えてMSからのIPv6リンクはBSの一部であるかもしれないアクセスルータか実体で終わります。 基地局は、層2の実体(MSとアクセスルータ(AR)とのIPv6リンクの見解からの)であり、空気インタフェースの上の二地点間接続でARとホストの間のIPv6パケットをリレーします。

2.  Terminology

2. 用語

   The terminology in this document is based on the definitions in "IP
   over 802.16 Problem Statement and Goals" [PS-GOALS].

用語は本書では「IPより多くの802.16問題声明と目標」[PS-GOALS]との定義に基づいています。

   o  IP CS - The IP-specific part of the Packet convergence sublayer is
      referred to as IP CS.  IPv6 CS and IP CS are used interchangeably.

o IP CS--Packet集合副層のIP特有の部分はIP CSと呼ばれます。 IPv6 CSとIP CSは互換性を持って使用されます。

   o  Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) -
      The terms subscriber station, mobile station, and mobile node are
      used interchangeably in this document and mean the same, i.e., an
      IP host.

o 加入者設備(SS)、モバイル駅(MS)、モバイルNode(ミネソタ)--用語加入者設備、移動局、およびモバイルノードは、互換性を持って本書では使用されて、同じであることを意味します、すなわち、IPホスト。

Patil, et al.               Standards Track                     [Page 3]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[3ページ]RFC5121IPv6

3.  Conventions Used in This Document

3. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

4.  IEEE 802.16 Convergence Sublayer Support for IPv6

4. IPv6のIEEE802.16集合副層サポート

   The IEEE 802.16 MAC specifies two main service-specific convergence
   sublayers:

IEEE802.16MACは2つの主なサービス特有の集合副層を指定します:

   1.  ATM convergence sublayer

1. ATM集合副層

   2.  Packet convergence sublayer

2. パケット集合副層

   The Packet CS is used for the transport of packet-based protocols,
   which include:

Packet CSはパケットベースのプロトコルの輸送に使用されます。(それは、以下の通りです)。

   1.  IEEE Std 802.3(Ethernet)

1. IEEE Std802.3(イーサネット)

   2.  Internet Protocol (IPv4 and IPv6)

2. インターネットプロトコル(IPv4とIPv6)

   The service-specific CS resides on top of the MAC Common Part
   Sublayer (CPS) as shown in Figure 1.  The service-specific CS is
   responsible for:

サービス特有のCSは図1に示されるようにMAC Common Part Sublayer(CPS)の上に住んでいます。 サービス特有のCSは以下に責任があります。

   o  accepting packets (Protocol Data Units, PDUs) from the upper
      layer,

o 上側の層からパケット(プロトコルData Units、PDUs)を受け入れます。

   o  performing classification of the packet/PDU based on a set of
      defined classifiers that are service specific,

o 1セットのサービス特有の定義されたクラシファイアに基づくパケット/PDUの分類を実行します。

   o  delivering the CS PDU to the appropriate service flow and
      transport connection, and

o そして適切なサービス流動と輸送接続にCS PDUを提供する。

   o  receiving PDUs from the peer entity.

o 同輩実体からPDUsを受けます。

   Payload header suppression (PHS) is also a function of the CS but is
   optional.

有効搭載量ヘッダー抑圧(PHS)は、また、CSの機能ですが、任意です。

   The figure below shows the concept of the service-specific CS in
   relation to the MAC:

以下の図はMACと関連してサービス特有のCSの概念を示しています:

Patil, et al.               Standards Track                     [Page 4]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[4ページ]RFC5121IPv6

     ------------------------------\
     |  ATM CS     | Packet CS    | \
     ------------------------------  \
     |  MAC Common Part Sublayer  |   \
     | (Ranging, scheduling, etc.)|    802.16 MAC
     ------------------------------   /
     |        Security            |  /
     |(Auth, encryption, key mgmt)| /
     ------------------------------/
     |            PHY             |
     ------------------------------

------------------------------\ | 気圧Cs| パケットCs| \ ------------------------------ \ | MACの一般的な部分副層| \ | (及ぶこと計画をするのなどて、| 802.16 Mac------------------------------ / | セキュリティ| / |(Auth、暗号化、主要な管理)| / ------------------------------/ | PHY| ------------------------------

                         Figure 1: IEEE 802.16 MAC

図1: IEEE802.16Mac

   Classifiers for each of the specific upper-layer protocols, i.e.,
   Ethernet and IP, are defined in the IEEE 802.16 specification, which
   enable the packets from the upper layer to be processed by the
   appropriate service-specific part of the Packet CS.  IPv6 can be
   transported directly over the IP-specific part of the Packet CS (IP
   CS).  IPv4 packets also are transported over the IP-specific part of
   the Packet CS.  The classifiers used by IP CS enable the
   differentiation of IPv4 and IPv6 packets and their mapping to
   specific transport connections over the air interface.

それぞれの特定の上側の層のプロトコルのためのクラシファイア(すなわち、イーサネットとIP)は、IEEE802.16仕様に基づき定義されます(上側の層からのパケットがPacket CSの適切なサービス特有の部分によって処理されるのを可能にします)。 IPv6をPacket CS(IP CS)のIP特有の部分の直接上輸送できます。 IPv4パケットもPacket CSのIP特有の部分の上輸送されます。 IP CSによって使用されたクラシファイアは、IPv4とIPv6パケットの分化と空気インタフェースの上の接続を特定の輸送に写像するのを可能にします。

   The figure below shows the options for IPv6 transport over the packet
   CS of IEEE 802.16:

IPv6のためのオプションがIEEE802.16のパケットCSの上で輸送するショーの下における図:

                                      +-------------------+
                                      |    IPv6           |
         +-------------------+        +-------------------+
         |    IPv6           |        |    Ethernet       |
         +-------------------+        +-------------------+
         |  IP-specific      |        |  802.3-specific   |
         | part of Packet CS |        | part of Packet CS |
         |...................|        |...................|
         |    MAC            |        |    MAC            |
         +-------------------+        +-------------------+
         |    PHY            |        |    PHY            |
         +-------------------+        +-------------------+

+-------------------+ | IPv6| +-------------------+ +-------------------+ | IPv6| | イーサネット| +-------------------+ +-------------------+ | IP特有です。| | 802.3特有です。| | Packet CSの一部| | Packet CSの一部| |...................| |...................| | Mac| | Mac| +-------------------+ +-------------------+ | PHY| | PHY| +-------------------+ +-------------------+

         (1) IPv6 over                (2) IPv6 over
             IP-specific part             802.3/Ethernet-
             of Packet CS                 specific part
                                          of Packet CS

(1) (2) Packet CSのPacket CSの特定の部分のIP特有の一部分802.3/イーサネットの上IPv6の上のIPv6

     Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CS

図2: Packet CSのIPと802.3特有の部分の上のIPv6

Patil, et al.               Standards Track                     [Page 5]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[5ページ]RFC5121IPv6

   The figure above shows that while there are multiple methods by which
   IPv6 can be transmitted over an 802.16 air interface, the scope of
   this document is limited to IPv6 operation over IP CS only.
   Transmission of IP over Ethernet is specified in [IPoE-over-802.16].
   Transmission of IPv4 over IP CS is specified in [IPv4-over-IPCS].

そこである間802.16空気インタフェースの上にIPv6を伝えることができる複数のメソッドであるショーを超えた図、このドキュメントの範囲はIP CSだけの上のIPv6操作に制限されます。 イーサネットの上のIPのトランスミッションは[IPoE-over-802.16]で指定されます。 IP CSの上のIPv4のトランスミッションは[IPv4過剰IPCS]で指定されます。

   It should be noted that immediately after ranging (802.16 air
   interface procedure) and exchange of SBC-REQ/RSP messages (802.16
   specific), the MS and BS exchange their capabilities via REG-REQ
   (Registration Request) and REG-RSP (Registration Response) 802.16 MAC
   messages.  These management frames negotiate parameters such as the
   Convergence Sublayer supported by the MS and BS.  By default, Packet,
   IPv4, and 802.3/Ethernet are supported.  IPv6 via the IP CS is
   supported by the MS and the BS only when the IPv6 support bit in the
   capability negotiation messages (REG-REQ and REG-RSP) implying such
   support is indicated in the parameter "Classification/PHS options and
   SDU (Service Data Unit) encapsulation support" (refer to [802.16]).
   Additionally, during the establishment of the transport connection
   for transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition)
   and DSA-RSP messages between the BS and MS indicate via the CS-
   Specification TLV the CS that the connection being set up shall use.
   When the IPv6 packet is preceded by the IEEE 802.16 6-byte MAC
   header, there is no specific indication in the MAC header itself
   about the payload type.  The processing of the packet is based
   entirely on the classifiers.  Based on the classification rules, the
   MAC layer selects an appropriate transport connection for the
   transmission of the packet.  An IPv6 packet is transported over a
   transport connection that is specifically established for carrying
   such packets.

SBC-REQ/RSPメッセージ(802.16詳細)の及ぶこと(802.16空気インタフェース手順)と交換直後MSとBSが802.16のREG-REQ(登録Request)とREG-RSP(登録Response)MACメッセージで彼らの能力を交換することに注意されるべきです。 これらの管理フレームはMSとBSによってサポートされたConvergence Sublayerなどのパラメタを交渉します。 デフォルトで、Packet、IPv4、および802.3/イーサネットはサポートされます。 IP CSを通したIPv6はそのようなサポートを含意する能力交渉メッセージ(REG-REQとREG-RSP)のIPv6サポートビットが「分類/PHSオプションとSDU(サービスData Unit)カプセル化サポート」というパラメタで示されるMSとBSだけによってサポートされます。([802.16])を参照してください。 さらに、IPv6パケットを輸送するための輸送接続の設立の間、BSとMSの間のDSA-REQ(ダイナミックなService Addition)とDSA-RSPメッセージは、CS仕様TLV CSを通してセットアップされている接続が使用するだろうというのを示します。 IPv6パケットがIEEEの802.16の6バイトのMACヘッダーによって先行されているとき、ペイロードタイプに関して特異的な適応が全くMACヘッダー自体にありません。 パケットの処理はクラシファイアに完全に基づいています。 分類規則に基づいて、MAC層はパケットのトランスミッションのための適切な輸送接続を選びます。 IPv6パケットはそのようなパケットを運ぶために明確に確立される輸送接続の上で輸送されます。

   Transmission of IPv6 as explained above is possible via multiple
   methods, i.e., via IP CS or via Ethernet interfaces.  Every Internet
   host connected via an 802.16 link:

上で説明されるとしてのIPv6のトランスミッションはすなわち、複数のメソッドかIP CSを通して、または、イーサネットインタフェースを通して可能です。 すべてのインターネット・ホストが802.16リンクを通して接続しました:

   1.  MUST be able to send and receive IPv6 packets via IP CS when the
       MS and BS indicate IPv6 protocol support over IP CS

1. MSとBSがIP CSの上のIPv6プロトコルサポートを示すとき、IP CSを通してIPv6パケットを送って、受けることができなければなりません。

   2.  MUST be able to send and receive IPv6 packets over the Ethernet
       (802.3)-specific part of the Packet CS when the MS and BS
       indicate IPv6 protocol support over Ethernet CS.  However, when
       the MS and BS indicate IPv6 protocol support over both IP CS and
       Ethernet CS, the MS and BS MUST use IP CS for sending and
       receiving IPv6 packets.

2. Packet CSのイーサネットの(802.3)特有の部分の上にIPv6パケットを送って、MSとBSがイーサネットCSの上のIPv6プロトコルサポートを示すときには受けることができなければならなくなってください。 しかしながら、MSとBSがIP CSとイーサネットCSの両方の上のIPv6プロトコルサポートを示すとき、MSとBS MUSTは送受信IPv6パケットにIP CSを使用します。

   When the MS and BS support IPv6 over IP CS, it MUST be used as the
   default mode for transporting IPv6 packets over IEEE 802.16 and the
   recommendations in this document that are followed.  Inability to
   negotiate a common convergence sublayer for IPv6 transport between

MSとBSがIP CSの上でIPv6をサポートするとき、このドキュメントにおける続かれているIEEE802.16と推薦の上でIPv6パケットを輸送するのにデフォルトモードとしてそれを使用しなければなりません。 IPv6輸送のための一般的な集合副層を交渉する無能

Patil, et al.               Standards Track                     [Page 6]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[6ページ]RFC5121IPv6

   the MS and BS will result in failure to set up the transport
   connection and thereby render the host unable to send and receive
   IPv6 packets.  In the case of a host that implements more than one
   method of transporting IPv6 packets, the default choice of which
   method to use (i.e., IPv6 over the IP CS or IPv6 over 802.3) is IPv6
   over IP CS when the BS also supports such capability.

MSとBSは輸送接続をセットアップして、その結果ホストをIPv6パケットを送って、受けることができないようにしないことをもたらすでしょう。 IPv6パケットを輸送する1つ以上のメソッドを実装するホストの場合では、また、BSがそのような能力をサポートするとき、(すなわち、IP CSかIPv6より多くの802.3の上のIPv6)を使用するどのメソッドのデフォルト選択はIP CSの上のIPv6であるか。

   In any case, the MS and BS MUST negotiate at most one convergence
   sublayer for IPv6 transport on a given link.

どのような場合でも、MSとBS MUSTはIPv6輸送のために与えられたリンクに関して1つの集合副層を高々交渉します。

   In addition, to ensure interoperability between devices that support
   different encapsulations, it is REQUIRED that BS implementations
   support all standards-track encapsulations defined for 802.16 by the
   IETF.  At the time of writing this specification, this is the only
   encapsulation, but additional specifications are being worked on.  It
   is, however, not required that the BS implementations use all the
   encapsulations they support; some modes of operation may be off by
   configuration.

さらに、異なったカプセル化をサポートするデバイスの間の相互運用性を確実にするために、BS実装が802.16のためにIETFによって定義されたすべての標準化過程カプセル化をサポートするのは、REQUIREDです。 この仕様を書く時点で、これは唯一のカプセル化ですが、追加仕様に働いています。 しかしながら、BS実装がそれらがサポートするすべてのカプセル化を使用するのが必要ではありません。 いくつかの運転モードが構成でオフであるかもしれません。

4.1.  IPv6 Encapsulation over the IP CS of the MAC

4.1. MACのIP Csの上のIPv6カプセル化

   The IPv6 payload when carried over the IP-specific part of the Packet
   CS is encapsulated by the 6-byte IEEE 802.16 generic MAC header.  The
   format of the IPv6 packet encapsulated by the generic MAC header is
   shown in the figure below.  The format of the 6-byte MAC header is
   described in the [802.16] specification.  The CRC (cyclic redundancy
   check) is optional.  It should be noted that the actual MAC address
   is not included in the MAC header.

Packet CSのIP特有の部分の上運ばれると、IPv6ペイロードは6バイトのIEEE802.16ジェネリックMACヘッダーによってカプセル化されます。 ジェネリックMACヘッダーによってカプセルに入れられたIPv6パケットの書式は以下の図に示されます。 6バイトのMACヘッダーの形式は[802.16]仕様で説明されます。 CRC(周期冗長検査)は任意です。 実際のMACアドレスがMACヘッダーに含まれていないことに注意されるべきです。

             ---------/ /-----------
             |    MAC SDU          |
             --------/ /------------
                     ||
                     ||
      MSB            \/                                    LSB
      ---------------------------------------------------------
      | Generic MAC header|  IPv6 Payload              | CRC  |
      ---------------------------------------------------------

---------/ /----------- | Mac SDU| --------/ /------------ || || MSB\/LSB--------------------------------------------------------- | ジェネリックMACヘッダー| IPv6有効搭載量| CRC| ---------------------------------------------------------

                       Figure 3: IPv6 encapsulation

図3: IPv6カプセル化

   For transmission of IPv6 packets via the IP CS over IEEE 802.16, the
   IPv6 layer interfaces with the 802.16 MAC directly.  The IPv6 layer
   delivers the IPv6 packet to the Packet CS of the IEEE 802.16 MAC.
   The Packet CS defines a set of classifiers that are used to determine
   how to handle the packet.  The IP classifiers that are used at the
   MAC operate on the fields of the IP header and the transport
   protocol, and these include the IP Traffic class, Next header field,

IEEE802.16の上のIP CSを通したIPv6パケットのトランスミッションのために、IPv6層は直接802.16MACに連結します。 IPv6層はIEEE802.16MACのPacket CSにIPv6パケットを提供します。 Packet CSはパケットを扱う方法を決定するのに使用される1セットのクラシファイアを定義します。 MACで使用されるIPクラシファイアはIPヘッダーの分野とトランスポート・プロトコルを作動させます、そして、これらはIP Trafficのクラスを含んでいます、Nextヘッダーフィールド

Patil, et al.               Standards Track                     [Page 7]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[7ページ]RFC5121IPv6

   Masked IP source and destination addresses, and Protocol source and
   destination port ranges.  Next header in this case refers to the last
   header of the IP header chain.  Parsing these classifiers, the MAC
   maps an upper-layer packet to a specific service flow and transport
   connection to be used.  The MAC encapsulates the IPv6 packet in the
   6-byte MAC header (MAC SDU) and transmits it.  The figure below shows
   the operation on the downlink, i.e., the transmission from the BS to
   the host.  The reverse is applicable for the uplink transmission.

仮面のIPソース、送付先アドレス、プロトコルソース、および仕向港の範囲。 次のヘッダーはこの場合IPヘッダーチェーンの最後のヘッダーについて言及します。 これらのクラシファイアを分析して、MACは、使用されるために特定のサービス流動と輸送接続に上側の層のパケットを写像します。 MACは6バイトのMACヘッダー(MAC SDU)でIPv6パケットをカプセルに入れって、それを伝えます。 以下の図はすなわち、ダウンリンク、BSからホストまでのトランスミッションに操作を示しています。 アップリンク送信に、逆は適切です。

     -----------                               ----------
     | IPv6 Pkt|                               |IPv6 Pkt|
     -----------                               ----------
        | |                                      /|\
        | |                                       |
     --[SAP]---------------------       ---------[SAP]--------
     ||-| |----------|          |       |        /|\         |
     || \ /        0---->[CID1] |       |     --- |--------  |
     || Downlink   0\/-->[CID2] |       |     |Reconstruct|  |
     || classifiers0/\-->[....] |       |     | (undo PHS)|  |
     ||            0---->[CIDn] |       |     ---   -------  |
     ||--------------|          |       |        /|\         |
     |                          |       |         |          |
     |  {SDU, CID,..}           |       |    {SDU, CID,..}   |
     |       |                  |       |        /|\         |
     |       v                  |       |         |          |
     ------[SAP]-----------------       |-------[SAP]---------
     |     802.16 MAC CPS       |------>|   802.16 MAC CPS   |
     ----------------------------       ----------------------
              BS                                  MS

----------- ---------- | IPv6 Pkt| |IPv6 Pkt| ----------- ---------- | | /|\ | | | --[SAP]--------------------- ---------[SAP]-------- ||-| |----------| | | /|\ | || \ / 0---->[CID1]| | --- |-------- | || ダウンリンク0円/-->[CID2]| | |再建します。| | || classifiers0/\--、>、[] | | | (アンドゥPHS)| | || 0---->[CIDn]| | --- ------- | ||--------------| | | /|\ | | | | | | | SDU、Cid。 | | SDU、Cid。 | | | | | /|\ | | v| | | | ------[SAP]----------------- |-------[SAP]--------- | 802.16 Mac CPS|、-、-、-、-、--、>| 802.16 Mac CPS| ---------------------------- ---------------------- BSさん

               Figure 4: IPv6 packet transmission: Downlink

図4: IPv6パケット伝送: ダウンリンク

5.  Generic Network Architecture Using the 802.16 Air Interface

5. 802.16空気インタフェースを使用するジェネリックネットワークアーキテクチャ

   In a network that utilizes the 802.16 air interface, the host/MS is
   attached to an IPv6 access router (AR) in the network.  The BS is a
   layer 2 entity only.  The AR can be an integral part of the BS or the
   AR could be an entity beyond the BS within the access network.  An AR
   may be attached to multiple BSs in a network.  IPv6 packets between
   the MS and BS are carried over a point-to-point transport connection
   which is identified by a unique Connection Identifier (CID).  The
   transport connection is a MAC layer link between the MS and the BS.
   The figures below describe the possible network architectures and are
   generic in nature.  More esoteric architectures are possible but not
   considered in the scope of this document.

802.16空気インタフェースを利用するネットワークでは、ホスト/MSはネットワークでIPv6アクセスルータ(AR)に付けられています。 BSは層2の実体専用です。 ARはBSの不可欠の部分であるかもしれませんかARがアクセスネットワークの中のBSを超えた実体であるかもしれません。 ARはネットワークにおける複数のBSsに取り付けられるかもしれません。 MSとBSの間のIPv6パケットはユニークなConnection Identifier(CID)によって特定される二地点間輸送接続の上まで運ばれます。 輸送接続はMSとBSとのMAC層のリンクです。 以下の数字は、可能なネットワークアーキテクチャについて説明して、現実にジェネリックです。 より難解なアーキテクチャは、可能ですが、このドキュメントの範囲で考えられません。

Patil, et al.               Standards Track                     [Page 8]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[8ページ]RFC5121IPv6

   Option A:

オプションA:

           +-----+    CID1     +--------------+
           | MS1 |------------/|     BS/AR    |-----[Internet]
           +-----+           / +--------------+
              .         /---/
              .     CIDn
           +-----+    /
           | MSn |---/
           +-----+

+-----+ CID1+--------------+ | MS1|------------/| BS/アルゴン|-----[インターネット] +-----+ / +--------------+ . /---/CIDn+-----+ / | MSn|---/ +-----+

              Figure 5: IPv6 AR as an integral part of the BS

図5: BSの不可欠の部分としてのIPv6 AR

   Option B:

オプションB:

         +-----+   CID1    +-----+          +-----------+
         | MS1 |----------/| BS1 |----------|     AR    |-----[Internet]
         +-----+         / +-----+          +-----------+
            .           /        ____________
            .     CIDn /        ()__________()
         +-----+      /            L2 Tunnel
         | MSn |-----/
         +-----+

+-----+ CID1+-----+ +-----------+ | MS1|----------/| BS1|----------| アルゴン|-----[インターネット] +-----+ / +-----+ +-----------+ . / ____________ . CIDn/()__________() +-----+/L2トンネル| MSn|-----/ +-----+

                 Figure 6: IPv6 AR is separate from the BS

図6: IPv6 ARはBSから別々です。

   The above network models serve as examples and are shown to
   illustrate the point-to-point link between the MS and the AR.

上のネットワークモデルは、例として機能して、MSとARとのポイントツーポイント接続を例証するために見せられます。

6.  IPv6 Link

6. IPv6リンク

   "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] defines link
   as a communication facility or medium over which nodes can
   communicate at the link layer, i.e., the layer immediately below IP.
   A link is bounded by routers that decrement the Hop limit field in
   the IPv6 header.  When an MS moves within a link, it can keep using
   its IP addresses.  This is a layer 3 definition, and note that the
   definition is not identical with the definition of the term '(L2)
   link' in IEEE 802 standards.

「IPバージョン6(IPv6)のための隣人ディスカバリー」[RFC4861]はノードがリンクレイヤで交信できる通信機器か媒体とリンクを定義します、すなわち、IPのすぐ下の層。 リンクはIPv6ヘッダーのHop限界分野を減少させるルータで境界があります。 MSがリンクの中に移行すると、それはIPアドレスを使用し続けることができます。 これは、層の3定義と、定義はIEEE802規格が'(L2)はリンクする'用語の定義と同じでないというメモです。

6.1.  IPv6 Link in 802.16

6.1. IPv6は802.16でリンクします。

   In 802.16, the transport connection between an MS and a BS is used to
   transport user data, i.e., IPv6 packets in this case.  A transport
   connection is represented by a CID, and multiple transport
   connections can exist between an MS and a BS.

802.16では、MSとBSとの輸送接続は、利用者データ(すなわち、この場合、IPv6パケット)を輸送するのに使用されます。 輸送接続はCIDによって代理をされます、そして、複数の輸送の接続がMSとBSの間に存在できます。

Patil, et al.               Standards Track                     [Page 9]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[9ページ]RFC5121IPv6

   When an AR and a BS are colocated, the collection of transport
   connections to an MS is defined as a single link.  When an AR and a
   BS are separated, it is recommended that a tunnel be established
   between the AR and a BS whose granularity is no greater than 'per MS'
   or 'per service flow' (An MS can have multiple service flows which
   are identified by a service flow ID).  Then the tunnel(s) for an MS,
   in combination with the MS's transport connections, forms a single
   point-to-point link.

ARとBSがcolocatedされるとき、MSへの輸送の接続の収集は単一のリンクと定義されます。 ARとBSが切り離されるとき、トンネルが粒状が、より'MS'か'サービス流動'であるARとBSの間で確立されるのは、お勧めです(MSはサービス流れIDによって特定される複数のサービス流れを持つことができます)。 そして、MSの輸送の接続と組み合わせて、MSへのトンネルは単一のポイントツーポイント接続を形成します。

   The collection of service flows (tunnels) to an MS is defined as a
   single link.  Each link that uses the same higher-layer protocol has
   only an MS and an AR.  Each MS belongs to a different link.  A
   different prefix should be assigned to each unique link.  This link
   is fully consistent with a standard IP link, without exception, and
   conforms with the definition of a point-to-point link in neighbor
   discovery for IPv6 [RFC4861].  Hence, the point-to-point link model
   for IPv6 operation over the IP-specific part of the Packet CS in
   802.16 SHOULD be used.  A unique IPv6 prefix(es) per link (MS/host)
   MUST be assigned.

MSへのサービス流れ(トンネル)の収集は単一のリンクと定義されます。 同じ上位層プロトコルを使用する各リンクがMSとARしか持っていません。 各MSは異なったリンクに属します。 異なった接頭語はそれぞれのユニークなリンクに割り当てられるべきです。 このリンクは、例外なしで標準のIPリンクと完全に一致していて、IPv6[RFC4861]のための隣人発見でポイントツーポイント接続の定義に従います。 したがって、Packet CSのIP特有の部分の上IPv6操作のために802.16SHOULDでポイントツーポイント接続をたどります。使用されます。 リンク(MS/ホスト)あたり1つのユニークなIPv6接頭語(es)を割り当てなければなりません。

6.2.  IPv6 Link Establishment in 802.16

6.2. 802.16へのIPv6リンク設立

   In order to enable the sending and receiving of IPv6 packets between
   the MS and the AR, the link between the MS and the AR via the BS
   needs to be established.  This section illustrates the link
   establishment procedure.

MSとARの間のIPv6パケットの送受信を可能にするために、BSを通したMSとARとのリンクは、設立される必要があります。 このセクションはリンク設立手順を例証します。

   The MS goes through the network entry procedure as specified by
   802.16.  A high-level description of the network entry procedure is
   as follows:

MSは指定されるとしての802.16のネットワークエントリー手順を執り行います。 ネットワークエントリー手順のハイレベルの記述は以下の通りです:

   1.  The MS performs initial ranging with the BS.  Ranging is a
       process by which an MS becomes time aligned with the BS.  The MS
       is synchronized with the BS at the successful completion of
       ranging and is ready to set up a connection.

1. MSは、BSと共に及びながら、初期で働きます。 及ぶのはMSが時間になるプロセスがBSに並んだということです。 MSは及ぶ無事終了におけるBSに連動して、接続をセットアップする準備ができています。

   2.  The MS and BS exchange basic capabilities that are necessary for
       effective communication during the initialization using SBC-REQ/
       RSP (802.16 specific) messages.

2. MSとBSは初期化の間SBC-REQ/ RSP(802.16詳細)メッセージを使用することで有効なコミュニケーションに必要な基本的な能力を交換します。

   3.  The MS progresses to an authentication phase.  Authentication is
       based on Privacy Key Management version 2 (PKMv2) as defined in
       the IEEE Std 802.16 specification.

3. MSは認証フェーズに進んでいます。 認証はIEEE Std802.16仕様に基づき定義されるようにPrivacy Key Managementバージョン2(PKMv2)に基づいています。

   4.  On successful completion of authentication, the MS performs
       802.16 registration with the network.

4. 認証の無事終了に、MSはネットワークと共に802.16登録を実行します。

Patil, et al.               Standards Track                    [Page 10]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[10ページ]RFC5121IPv6

   5.  The MS and BS perform capability exchange as per 802.16
       procedures.  Protocol support is indicated in this exchange.  The
       CS capability parameter indicates which classification/PHS
       options and SDU encapsulation the MS supports.  By default,
       Packet, IPv4, and 802.3/Ethernet shall be supported; thus,
       absence of this parameter in REG-REQ (802.16 message) means that
       named options are supported by the MS/SS.  Support for IPv6 over
       the IP-specific part of the Packet CS is indicated by Bit #2 of
       the CS capability parameter (refer to [802.16]).

5. MSとBSは802.16の手順に従って能力交換を実行します。 プロトコルサポートはこの交換で示されます。 CS能力パラメタは、MSがどの分類/PHSオプションとSDUカプセル化をサポートするかを示します。 デフォルトで、Packet、IPv4、および802.3/イーサネットはサポートされるものとします。 したがって、REG-REQ(802.16メッセージ)でのこのパラメタの欠如は、命名されたオプションがMS/SSによってサポートされることを意味します。 Packet CSのIP特有の部分の上IPv6のサポートは2つのCS能力Bit#パラメタによって示されます。([802.16])を参照してください。

   6.  The MS MUST request the establishment of a service flow for IPv6
       packets over IP CS if the MS and BS have confirmed capability for
       supporting IPv6 over IP CS.  The service flow MAY also be
       triggered by the network as a result of pre-provisioning.  The
       service flow establishes a link between the MS and the AR over
       which IPv6 packets can be sent and received.

6. MSとBSがIP CSの上でIPv6をサポートするために能力を確認したなら、さんはIP CSの上のIPv6パケットのためにサービス流動の設立を要求しなければなりません。 また、サービス流動はプレの食糧を供給することの結果、ネットワークによって引き起こされるかもしれません。 サービス流動はIPv6パケットを送って、受け取ることができるMSとARの間とのリンクを設立します。

   7.  The AR and MS SHOULD send router advertisements and solicitations
       as specified in neighbor discovery [RFC4861].

7. ARとMS SHOULDは隣人発見[RFC4861]における指定されるとしてのルータ通知と懇願を送ります。

   The above flow does not show the actual 802.16 messages that are used
   for ranging, capability exchange, or service flow establishment.
   Details of these are in [802.16].

上の流れは及ぶのに使用される、実際の802.16のメッセージ、能力交換、またはサービス流れ設立を見せません。 これらの詳細が[802.16]にあります。

6.3.  Maximum Transmission Unit in 802.16

6.3. 802.16におけるマキシマム・トランスミッション・ユニット

   The MTU value for IPv6 packets on an 802.16 link is configurable.
   The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500
   octets.

802.16リンクの上のIPv6パケットのためのMTU値は構成可能です。 デフォルトMTU、802.16リンクSHOULDの上のIPv6パケットのために、1500の八重奏がそうです。

   The 802.16 MAC PDU is composed of a 6-byte header followed by an
   optional payload and an optional CRC covering the header and the
   payload.  The length of the PDU is indicated by the Len parameter in
   the Generic MAC header.  The Len parameter has a size of 11 bits.
   Hence, the total MAC PDU size is 2048 bytes.  The IPv6 payload size
   can vary.  In certain deployment scenarios, the MTU value can be
   greater than the default.  Neighbor discovery for IPv6 [RFC4861]
   defines an MTU option that an AR MUST advertise, via router
   advertisement (RA), if a value different from 1500 is used.  The MN
   processes this option as defined in [RFC4861].  Nodes that implement
   Path MTU Discovery [RFC1981] MAY use the mechanism to determine the
   MTU for the IPv6 packets.

802.16MAC PDUは任意のペイロードが支えた6バイトのヘッダーとヘッダーとペイロードを含んでいる任意のCRCで構成されます。 PDUの長さはGeneric MACヘッダーでレンパラメタによって示されます。 レンパラメタには、11ビットのサイズがあります。 したがって、総MAC PDUサイズは2048バイトです。 IPv6ペイロードサイズは異なることができます。 ある展開シナリオでは、MTU値はデフォルトより大きい場合があります。 IPv6[RFC4861]のための隣人発見はアルゴンが広告を出さなければならないMTUオプションを定義します、ルータ通知(RA)で、1500年と異なった値が使用されているなら。 ミネソタは[RFC4861]で定義されるようにこのオプションを処理します。 Path MTUがディスカバリー[RFC1981]であると実装するノードは、IPv6パケットのためにMTUを決定するのにメカニズムを使用するかもしれません。

Patil, et al.               Standards Track                    [Page 11]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[11ページ]RFC5121IPv6

7.  IPv6 Prefix Assignment

7. IPv6接頭語課題

   The MS and the AR are connected via a point-to-point connection at
   the IPv6 layer.  Hence, each MS can be considered to be on a separate
   subnet.  A CPE (Customer Premise Equipment) type of device that
   serves multiple IPv6 hosts may be the end point of the connection.
   Hence, one or more /64 prefixes SHOULD be assigned to a link.  The
   prefixes are advertised with the on-link (L-bit) flag set as
   specified in [RFC4861].  The size and number of the prefixes are a
   configuration issue.  Also, Dynamic Host Configuration Protocol
   (DHCP) or Authentication, Authorization, and Accounting (AAA)-based
   prefix delegation MAY be used to provide one or more prefixes to MS
   for an AR connected over 802.16.  The other properties of the
   prefixes are also dealt with via configuration.

MSとARはIPv6層の二地点間接続でつなげられます。 したがって、各MSが別々のサブネットにいると考えることができます。 複数のIPv6ホストに役立つデバイスのCPE(顧客Premise Equipment)タイプは接続のエンドポイントであるかもしれません。 したがって、1以上/64はSHOULDを前に置きます。リンクに割り当てられます。 リンクの上に(Lで噛み付かれる)の旗のセットがある状態で、[RFC4861]で指定されるように接頭語の広告を出します。 接頭語のサイズと数は構成問題です。 また、Dynamic Host Configuration Protocol(DHCP)かAuthenticationと、Authorizationと、Accountingの(AAA)ベースの接頭語委譲が1つを提供するのに使用されたかもしれませんか、またはARのためのMSへの、より多くの接頭語が802.16以上を接続しました。 また、構成で接頭語の他の特性は対処されています。

8.  Router Discovery

8. ルータ発見

8.1.  Router Solicitation

8.1. ルータ懇願

   On completion of the establishment of the IPv6 link, the MS may send
   a router solicitation message to solicit a router advertisement
   message from the AR to acquire necessary information as per the
   neighbor discovery for IPv6 specification [RFC4861].  An MS that is
   network attached may also send router solicitations at any time.
   Movement detection at the IP layer of an MS in many cases is based on
   receiving periodic router advertisements.  An MS may also detect
   changes in its attachment via link triggers or other means.  The MS
   can act on such triggers by sending router solicitations.  The router
   solicitation is sent over the IPv6 link that has been previously
   established.  The MS sends router solicitations to the all-routers
   multicast address.  It is carried over the point-to-point link to the
   AR via the BS.  The MS does not need to be aware of the link-local
   address of the AR in order to send a router solicitation at any time.
   The use of router advertisements as a means for movement detection is
   not recommended for MNs connected via 802.16 links as the frequency
   of periodic router advertisements would have to be high.

IPv6リンクの設立の完成のときに、MSは、IPv6仕様[RFC4861]のための隣人発見に従って必要事項を取得するためにARからルータ通知メッセージに請求するルータ懇願メッセージを送るかもしれません。 また、添付のネットワークであるMSはいつでも、ルータ懇願を送るかもしれません。 多くの場合、MSのIP層での動き検出は周期的なルータ通知を受け取るのに基づいています。 また、MSはリンク引き金か他の手段で付属における変化を検出するかもしれません。 ルータ懇願を送ることによって、MSはそのような引き金に影響できます。 以前に設立されたIPv6リンクの上にルータ懇願を送ります。 MSはオールルータマルチキャストアドレスにルータ懇願を送ります。 持ち越されて、ポイントツーポイントがBSを通してARにリンクされるということです。 MSは、いつでもルータ懇願を送るためにARのリンクローカルアドレスを意識している必要はありません。 手段としてのルータ通知の動き検出の使用は周期的なルータ通知の頻度が高くなければならないでしょう、したがって、802.16個のリンクを通して接続されたMNsのために推薦されません。

8.2.  Router Advertisement

8.2. ルータ通知

   The AR SHOULD send a number (configurable value) of router
   advertisements to the MS as soon as the IPv6 link is established.
   The AR sends unsolicited router advertisements periodically as per
   [RFC4861].  The interval between periodic router advertisements is
   however greater than the specification in neighbor discovery for
   IPv6, and is discussed in the following section.

IPv6リンクが設立されるとすぐに、AR SHOULDはルータ通知の数(構成可能な値)をMSに送ります。 ARは[RFC4861]に従って定期的に求められていないルータ通知を送ります。 周期的なルータ通知の間隔について、隣人発見における仕様よりどんなにさらに大きいならIPv6をである以下のセクションで議論するか。

Patil, et al.               Standards Track                    [Page 12]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[12ページ]RFC5121IPv6

8.3.  Router Lifetime and Periodic Router Advertisements

8.3. ルータ生涯と周期的なルータ通知

   The router lifetime SHOULD be set to a large value, preferably in
   hours.  This document overrides the specification for the value of
   the router lifetime in "Neighbor Discovery for IP Version 6 (IPv6)"
   [RFC4861].  The AdvDefaultLifetime in the router advertisement MUST
   be either zero or between MaxRtrAdvInterval and 43200 seconds.  The
   default value is 2 * MaxRtrAdvInterval.

ルータ生涯SHOULD、望ましくは何時間も大きい値に設定されてください。 このドキュメントは「IPバージョン6(IPv6)のための隣人発見」[RFC4861]における、ルータ生涯の値のための仕様に優越します。 ルータ通知におけるAdvDefaultLifetimeはゼロであるかMaxRtrAdvIntervalと43200秒の間でそうでなければなりません。 デフォルト値は2*MaxRtrAdvIntervalです。

   802.16 hosts have the capability to transition to an idle mode, in
   which case, the radio link between the BS and MS is torn down.
   Paging is required in case the network needs to deliver packets to
   the MS.  In order to avoid waking a mobile that is in idle mode and
   consuming resources on the air interface, the interval between
   periodic router advertisements SHOULD be set quite high.  The
   MaxRtrAdvInterval value specified in this document overrides the
   recommendation in "Neighbor Discovery for IP Version 6
   (IPv6)"[RFC4861].  The MaxRtrAdvInterval MUST be no less than 4
   seconds and no greater than 21600 seconds.  The default value for
   MaxRtrAdvInterval is 10800 seconds.

802.16人のホストが無駄なモードへの変遷に能力を持っています、その場合、BSとMSとのラジオリンクを取りこわします。 ネットワークが、パケットをMSに提供する必要があるといけないので、ページングが必要です。周期的なルータ通知SHOULDの間で放送されたインタフェース、無駄なモードとリソースを消費することにおいて間隔であるモバイルを起こすのを避けるには、全く高く設定されてください。 本書では指定されたMaxRtrAdvInterval値は「IPバージョン6(IPv6)のための隣人発見」[RFC4861]における推薦をくつがえします。 MaxRtrAdvIntervalは4秒未満と21600秒以下ノーであるに違いありません。 MaxRtrAdvIntervalのためのデフォルト値は10800秒です。

9.  IPv6 Addressing for Hosts

9. ホストのためのIPv6アドレシング

   The addressing scheme for IPv6 hosts in 802.16 networks follows the
   IETF's recommendation for hosts specified in "IPv6 Node Requirements"
   [RFC4294].  The IPv6 node requirements [RFC4294] specify a set of
   RFCs that are applicable for addressing, and the same is applicable
   for hosts that use 802.16 as the link layer for transporting IPv6
   packets.

802.16のネットワークのIPv6ホストのアドレシング体系は「IPv6ノード要件」[RFC4294]で指定されたホストのためのIETFの推薦に続きます。 IPv6ノード要件[RFC4294]はアドレシングに、適切なRFCsの1セットを指定します、そして、IPv6パケットを輸送するのにリンクレイヤとして802.16を使用するホストにとって、同じくらいは適切です。

9.1.  Interface Identifier

9.1. インタフェース識別子

   The MS has a 48-bit globally unique MAC address as specified in
   802.16 [802.16].  This MAC address MUST be used to generate the
   modified EUI-64 format-based interface identifier as specified in "IP
   Version 6 Addressing Architecture" [RFC4291].  The modified EUI-64
   interface identifier is used in stateless address autoconfiguration.
   As in other links that support IPv6, EUI-64-based interface
   identifiers are not mandatory and other mechanisms, such as random
   interface identifiers, "Privacy Extensions for Stateless Address
   Autoconfiguration in IPv6" [RFC4941], MAY also be used.

MSには、802.16[802.16]の指定されるとしての48ビットのグローバルにユニークなMACアドレスがあります。 「IPバージョン6アドレッシング体系」[RFC4291]の指定されるとしての変更されたEUI-64形式ベースのインタフェース識別子を生成するのにこのMACアドレスを使用しなければなりません。 変更されたEUI-64インタフェース識別子は状態がないアドレス自動構成に使用されます。 IPv6をサポートする他のリンクのように、EUI-64ベースのインタフェース識別子は義務的で他のメカニズムではありません、無作為のインタフェース識別子、「IPv6"[RFC4941]での状態がないアドレス自動構成のためのプライバシー拡大、また、使用されるかもしれないことなど」ように。

9.2.  Duplicate Address Detection

9.2. アドレス検出をコピーしてください。

   DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6
   (IPv6)", [RFC4861] and "IPv6 Stateless Address Autoconfiguration"
   [RFC4862].  The IPv6 link over 802.16 is specified in this document
   as a point-to-point link.  Based on this criteria, it may be

DAD SHOULD、「IPバージョン6(IPv6)のための隣人発見」、[RFC4861]、および「IPv6の状態がないアドレス自動構成」[RFC4862]に従って、実行されてください。 IPv6リンクより多くの802.16は本書ではポイントツーポイント接続として指定されます。 この評価基準に基づいて、それはそうです。

Patil, et al.               Standards Track                    [Page 13]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[13ページ]RFC5121IPv6

   redundant to perform DAD on a global unicast address that is
   configured using the EUI-64 or generated as per RFC 4941 [RFC4941]
   for the interface as part of the IPv6 Stateless Address
   Autoconfiguration Protocol [RFC4862] as long as the following two
   conditions are met:

以下の2つの条件が満たされる限り、IPv6 Stateless Address Autoconfigurationプロトコル[RFC4862]の一部としてインタフェースにEUI-64を使用することで構成されるか、またはRFC4941[RFC4941]に従って作られるグローバルなユニキャストアドレスにDADを実行するために余分:

   1.  The prefixes advertised through the router advertisement messages
       by the access router terminating the 802.16 IPv6 link are unique
       to that link.

1. 802.16IPv6リンクを終えながらルータ通知メッセージのを通してアクセスルータによって広告に掲載された接頭語はそのリンクにユニークです。

   2.  The access router terminating the 802.16 IPv6 link does not
       autoconfigure any IPv6 global unicast addresses from the prefix
       that it advertises.

2. 802.16IPv6リンクを終えるアクセスルータはそれが広告を出す接頭語からの少しのIPv6のグローバルなユニキャストアドレスも自動構成しません。

9.3.  Stateless Address Autoconfiguration

9.3. 状態がないアドレス自動構成

   When stateless address autoconfiguration is performed, it MUST be
   performed as specified in [RFC4861] and [RFC4862].

状態がないアドレス自動構成が実行されるとき、それとして、[RFC4861]と[RFC4862]で指定されていた状態で実行しなければなりません。

9.4.  Stateful Address Autoconfiguration

9.4. Statefulアドレス自動構成

   When stateful address autoconfiguration is performed, it MUST be
   performed as specified in [RFC4861] and [RFC3315].

statefulアドレス自動構成が実行されるとき、それとして、[RFC4861]と[RFC3315]で指定されていた状態で実行しなければなりません。

10.  Multicast Listener Discovery

10. マルチキャストリスナー発見

   "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
   SHOULD be supported as specified by the hosts and routers attached to
   each other via an 802.16 link.  The access router that has hosts
   attached to it via a point-to-point link over an 802.16 SHOULD NOT
   send periodic queries if the host is in idle/dormant mode.  The AR
   can obtain information about the state of a host from the paging
   controller in the network.

「マルチキャストListenerディスカバリーバージョン2(MLDv2)、IPv6"[RFC3810]SHOULDに関しては、802.16リンクを通して互いに愛着しているホストとルータによって指定されるようにサポートされてください、」 802.16SHOULD NOTの上のポイントツーポイント接続を通してそれに付けられたホストがホストであるならそれで周期的な質問を送るアクセスルータが活動していないか眠っているモードであります。 ARはページングコントローラからネットワークでホストの状態の情報を得ることができます。

11.  Security Considerations

11. セキュリティ問題

   This document does not introduce any new vulnerabilities to IPv6
   specifications or operation.  The security of the 802.16 air
   interface is the subject of [802.16].  It should be noted that 802.16
   provides capability to cipher the traffic carried over the transport
   connections.  A traffic encryption key (TEK) is generated by the MS
   and BS on completion of successful authentication and is used to
   secure the traffic over the air interface.  An MS may still use IPv6
   security mechanisms even in the presence of security over the 802.16
   link.  In addition, the security issues of the network architecture
   spanning beyond the 802.16 base stations are the subject of the
   documents defining such architectures, such as WiMAX Network
   Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2, Part 2.

このドキュメントはIPv6仕様か操作にどんな新しい脆弱性も紹介しません。 802.16空気インタフェースのセキュリティは[802.16]の対象です。 802.16が輸送の接続の上まで運ばれたトラフィックを解く能力を提供することに注意されるべきです。 トラフィック暗号化キー(TEK)は、うまくいっている認証の完成のときにMSとBSによって生成されて、空気インタフェースの上でトラフィックを保証するのに使用されます。 MSは802.16リンクの上のセキュリティがあるときさえまだIPv6セキュリティー対策を使用しているかもしれません。 さらに、802.16の基地局を超えてわたるネットワークアーキテクチャの安全保障問題はそのようなアーキテクチャを定義するドキュメントの対象です、Stage2のセクション7.2と7.3におけるWiMAX Network Architecture[WiMAXArch]などのように、Part2。

Patil, et al.               Standards Track                    [Page 14]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[14ページ]RFC5121IPv6

12.  Acknowledgments

12. 承認

   The authors would like to acknowledge the contributions of the 16NG
   working group chairs Soohong Daniel Park and Gabriel Montenegro as
   well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ
   Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret
   Wasserman, and Pekka Savola for their review and comments.  Review
   and comments by Phil Barber have also helped in improving the
   document quality.

作者は彼らのレビューとコメントのために16NGワーキンググループいすのヤリArkkoと同様にSoohongダニエルParkとガブリエル・モンテネグロ、Jonne Soininen、マックス・リーゲル、プラカシュ・アイヤル、DJのジョンストン、デーヴThaler、ブルーノ・スーザ、Alexandruペトレスク、マーガレット・ワッサーマン、およびペッカSavolaの貢献を承諾したがっています。 また、フィル・バーバーによるレビューとコメントは、ドキュメント品質を改良するのを手伝いました。

13.  References

13. 参照

13.1.  Normative References

13.1. 引用規格

   [802.16]            "IEEE Std 802.16e: IEEE Standard for Local and
                       metropolitan area networks, Amendment for
                       Physical and Medium Access Control Layers for
                       Combined Fixed and Mobile Operation in Licensed
                       Bands", October 2005, <http://standards.ieee.org/
                       getieee802/download/802.16e-2005.pdf>.

[802.16]、「IEEE Std 802.16e:」 「Licensed BandsのLocalとメトロポリタンエリアネットワークのためのIEEE Standard、PhysicalのためのAmendment、およびCombined FixedとモバイルOperationのためのMedium Access Control Layers」2005年10月<httpな://standards.ieee.org/getieee802/ダウンロード/802.16e-2005.pdf>。

   [RFC1981]           McCann, J., Deering, S., and J. Mogul, "Path MTU
                       Discovery for IP version 6", RFC 1981,
                       August 1996.

[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。

   [RFC2119]           Bradner, S., "Key words for use in RFCs to
                       Indicate Requirement Levels", BCP 14, RFC 2119,
                       March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3810]           Vida, R. and L. Costa, "Multicast Listener
                       Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
                       June 2004.

そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」

   [RFC4291]           Hinden, R. and S. Deering, "IP Version 6
                       Addressing Architecture", RFC 4291,
                       February 2006.

[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。

   [RFC4861]           Narten, T., Nordmark, E., Simpson, W., and H.
                       Soliman, "Neighbor Discovery for IP version 6
                       (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。

   [RFC4862]           Thomson, S., Narten, T., and T. Jinmei, "IPv6
                       Stateless Address Autoconfiguration", RFC 4862,
                       September 2007.

[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。

Patil, et al.               Standards Track                    [Page 15]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[15ページ]RFC5121IPv6

13.2.  Informative References

13.2. 有益な参照

   [802.3]             "IEEE Std 802.3-2005: IEEE Standard for
                       Information technology-Telecommunications and
                       information exchange between systems-Local and
                       metropolitan area networks--Specific requirements
                       Part 3: Carrier Sense Multiple Access with
                       Collision Detection (CSMA/CD) Access Method and
                       Physical Layer Specifications", December 2005,
                       <http://standards.ieee.org/getieee802/
                       802.3.html>.

[802.3]、「IEEE Std802.3-2005:」 情報技術テレコミュニケーションのためのIEEE Standardとシステム地方とメトロポリタンエリアネットワークの間の情報交換--決められた一定の要求Part3: 「衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスする」2005年12月、<http://standards.ieee.org/getieee802/ 802.3.html>。

   [IPoE-over-802.16]  Jeon, H., Riegel, M., and S. Jeong, "Transmission
                       of IP over Ethernet over IEEE 802.16 Networks",
                       Work in Progress, January 2008.

H.、リーゲル、M.、およびS.Jeong、「IEEE802.16ネットワークの上のイーサネットの上のIPのトランスミッション」という[IPoE-over-802.16]Jeonは進行中(2008年1月)で働いています。

   [IPv4-over-IPCS]    Madanapalli, S., Park, S., and S. Chakrabarti,
                       "Transmission of IPv4 packets over IEEE 802.16's
                       IP Convergence Sublayer", Work in Progress,
                       November 2007.

[IPv4過剰IPCS] Madanapalli、S.、Park、S.、およびS.Chakrabarti、「IEEE802.16のIP Convergence Sublayerの上のIPv4パケットのトランスミッション」、Progress(2007年11月)のWork。

   [PS-GOALS]          Jee, J., Madanapalli, S., and J. Mandin, "IP over
                       802.16 Problem Statement and Goals", Work
                       in Progress, December 2007.

[PS-目標] J.、Madanapalli、S.、J.Mandin、および「IPより多くの802.16問題声明と目標」というJeeは進歩、2007年12月に働いています。

   [RFC3315]           Droms, R., Bound, J., Volz, B., Lemon, T.,
                       Perkins, C., and M. Carney, "Dynamic Host
                       Configuration Protocol for IPv6 (DHCPv6)",
                       RFC 3315, July 2003.

[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。

   [RFC4294]           Loughney, J., "IPv6 Node Requirements", RFC 4294,
                       April 2006.

[RFC4294] Loughney、J.、「IPv6ノード要件」、RFC4294、2006年4月。

   [RFC4941]           Narten, T., Draves, R., and S. Krishnan, "Privacy
                       Extensions for Stateless Address
                       Autoconfiguration in IPv6", RFC 4941,
                       September 2007.

[RFC4941] Narten、T.、Draves、R.、およびS.クリシュナン、「IPv6"、RFC4941、2007年9月の状態がないアドレス自動構成のためのプライバシー拡大。」

   [WMF]               "WiMAX Forum", <http://www.wimaxforum.org>.

[WMF]「WiMAXフォーラム」、<http://www.wimaxforum.org>。

   [WiMAXArch]         "WiMAX End-to-End Network Systems Architecture",
                       September 2007.

2007年9月の[WiMAXArch]「WiMAX終わりから終わりへのネットワーク・システムアーキテクチャ。」

Patil, et al.               Standards Track                    [Page 16]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[16ページ]RFC5121IPv6

Appendix A.  WiMAX Network Architecture and IPv6 Support

付録A.WiMAXネットワークアーキテクチャとIPv6サポート

   The WiMAX (Worldwide Interoperability for Microwave Access) forum
   [WMF] has defined a network architecture in which the air interface
   is based on the IEEE 802.16 standard.  The addressing and operation
   of IPv6 described in this document are applicable to the WiMAX
   network as well.

WiMAX(ワイマックス)フォーラム[WMF]は空気インタフェースがIEEE802.16規格に基づいているネットワークアーキテクチャを定義しました。 本書では説明されたIPv6のアドレシングと操作はまた、WiMAXネットワークに適切です。

   WiMAX is an example architecture of a network that uses the 802.16
   specification for the air interface.  WiMAX networks are also in the
   process of being deployed in various parts of the world, and the
   operation of IPv6 within a WiMAX network is explained in this
   appendix.

WiMAXは空気インタフェースに802.16仕様を使用するネットワークの例のアーキテクチャです。 世界各地で配布されることの途中にもWiMAXネットワークがあります、そして、WiMAXネットワークの中のIPv6の操作はこの付録で説明されます。

   The WiMAX network architecture consists of the Access Service Network
   (ASN) and the Connectivity Service Network (CSN).  The ASN is the
   access network that includes the BS and the AR in addition to other
   functions such as AAA, mobile IP foreign agent, paging controller,
   location register, etc.  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.  The CSN is the entity
   that provides connectivity to the Internet and includes functions
   such as mobile IP home agent and AAA.  The figure below shows the
   WiMAX reference model:

WiMAXネットワークアーキテクチャはAccess Service Network(ASN)とConnectivity Service Network(CSN)から成ります。 ASNはAAAなどの他の機能に加えてBSとARを含んでいるアクセスネットワークです、モバイルIP外国人のエージェント、コントローラ、位置のレジスタなどを呼び出して ASNはWiMAX加入者へのラジオアクセスを提供するのに必要である完全なネットワーク機能と定義されます。 ASNはMSが付くアクセスネットワークです。 IPv6アクセスルータはASNの中の実体です。 ASNという用語はWiMAXネットワークアーキテクチャに特定です。 CSNは接続性をインターネットに提供して、モバイルIPホームのエージェントやAAAなどの機能を含んでいる実体です。 以下の図はWiMAX規範モデルを示しています:

                        -------------------
                        | ----      ASN   |                    |----|
         ----           | |BS|\ R6 -------|    |---------|     | CSN|
         |MS|-----R1----| ---- \---|ASN-GW| R3 |  CSN    | R5  |    |
         ----           |  |R8  /--|------|----|         |-----|Home|
                        | ---- /          |    |  visited|     | NSP|
                        | |BS|/           |    |   NSP   |     |    |
                        | ----            |    |---------|     |    |
                        |       NAP       |         \          |----|
                        -------------------          \---|        /
                                |                        |       /
                                |                     (--|------/----)
                                |R4                  (                )
                                |                   (      ASP network )
                            ---------                ( or Internet    )
                            |  ASN  |                 (              )
                            ---------                   (----------)

------------------- | ---- ASN| |----| ---- | |BS|\R6-------| |---------| | CSN| |さん|-----R1----| ---- \---|ASN-GW| R3| CSN| R5| | ---- | |R8/--|------|----| |-----|ホーム| | ---- / | | 訪問されます。| | NSP| | |BS|/ | | NSP| | | | ---- | |---------| | | | 仮眠| \ |----| ------------------- \---| / | | / | (--|------/----) |R4( )| (ASPネットワーク) --------- (または、インターネット) | ASN| ( ) --------- (----------)

                  Figure 7: WiMAX network reference model

図7: WiMAXネットワーク規範モデル

Patil, et al.               Standards Track                    [Page 17]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[17ページ]RFC5121IPv6

   Three different types of ASN realizations called profiles are defined
   by the architecture.  ASNs of profile types A and C include BS' and
   ASN-gateway(s) (ASN-GW), which are connected to each other via an R6
   interface.  An ASN of profile type B is one in which the
   functionality of the BS and other ASN functions are merged together.
   No ASN-GW is specifically defined in a profile B ASN.  The absence of
   the R6 interface is also a profile B specific characteristic.  The MS
   at the IPv6 layer is associated with the AR in the ASN.  The AR may
   be a function of the ASN-GW in the case of profiles A and C and is a
   function in the ASN in the case of profile B.  When the BS and the AR
   are separate entities and linked via the R6 interface, IPv6 packets
   between the BS and the AR are carried over a Generic Routing
   Encapsulation (GRE) tunnel.  The granularity of the GRE tunnel should
   be on a per-MS basis or on a per-service-flow basis (an MS can have
   multiple service flows, each of which is identified uniquely by a
   service flow ID).  The protocol stack in WiMAX for IPv6 is shown
   below:

プロフィールと呼ばれる3つの異なったタイプのASN実現はアーキテクチャによって定義されます。 プロフィールタイプAとCのASNsはBSとASN-ゲートウェイ(ASN-GW)を含んでいます。(それは、R6インタフェースを通して互いに接続されます)。 プロフィールタイプBのASNはBSと他のASN機能の機能性がどれであるかで結合するものです。 ASN-GWは全くプロフィールB ASNで明確に定義されません。 また、R6インタフェースの不在はプロフィールのB特定の特性です。 IPv6層のMSはASNのARに関連しています。 ARはプロフィールAとCの場合における、ASN-GWの機能であるかもしれなく、プロフィールB.When BSの場合でASNでの機能です、そして、ARは別々の実体です、そして、R6インタフェースを通して繋がって、BSとARの間のIPv6パケットはGenericルート設定Encapsulation(GRE)トンネルの上まで運ばれます。 1MSあたり1個のベースの上、または、サービス単位で流れるベースの上にGREトンネルの粒状があるべきです(MSはそれのそれぞれがサービス流れIDによって唯一特定される複数のサービス流れを持つことができます)。 IPv6のためのWiMAXのプロトコル・スタックは以下で見せられます:

   |-------|
   | App   |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
   |       |
   |-------|                                   /------      -------
   |       |                                  / IPv6 |      |     |
   | IPv6  |- - - - - - - - - - - - - - - -  /       |      |     |-->
   |       |      ---------------    -------/        |      | IPv6|
   |-------|      |    \Relay/  |    |      |        |- - - |     |
   |       |      |     \   /   |    | GRE  |        |      |     |
   |       |      |      \ /GRE | -  |      |        |      |     |
   |       |- - - |       |-----|    |------|        |      |     |
   | IPv6CS|      |IPv6CS | IP  | -  | IP   |        |      |     |
   | ..... |      |...... |-----|    |------|--------|      |-----|
   |  MAC  |      | MAC   | L2  | -  | L2   |  L2    |- - - | L2  |
   |-------|      |------ |-----|    |----- |--------|      |-----|
   |  PHY  |- - - | PHY   | L1  | -  | L1   |  L1    |- - - | L1  |
    --------      ---------------    -----------------      -------

|-------| | 装置|- - - - - - - - - - - - - - - - - - - - - - - -(装置同輩への) | | |-------| /------ ------- | | /IPv6| | | | IPv6|- - - - - - - - - - - - - - - - / | | | -->、|、| --------------- -------/ | | IPv6| |-------| | \リレー/| | | |- - - | | | | | \ / | | GRE| | | | | | | \/GRE| - | | | | | | |- - - | |-----| |------| | | | | IPv6CS| |IPv6CS| IP| - | IP| | | | | ..... | |...... |-----| |------|--------| |-----| | Mac| | Mac| L2| - | L2| L2|- - - | L2| |-------| |------ |-----| |----- |--------| |-----| | PHY|- - - | PHY| L1| - | L1| L1|- - - | L1| -------- --------------- ----------------- -------

      MS             BS                   AR/ASN-GW          CSN Rtr

MS BS AR/ASN-GW CSN Rtr

                      Figure 8: WiMAX protocol stack

エイト環: WiMAXプロトコル・スタック

   As can be seen from the protocol stack description, the IPv6 end-
   points are constituted in the MS and the AR.  The BS provides lower-
   layer connectivity for the IPv6 link.

プロトコル・スタック記述から見ることができるように、終わりが指すIPv6はMSとARで構成されます。 BSは低い層の接続性をIPv6リンクに供給します。

Patil, et al.               Standards Track                    [Page 18]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[18ページ]RFC5121IPv6

Appendix B.  IPv6 Link in WiMAX

付録B.IPv6はWiMAXでリンクします。

   WiMAX is an example of a network based on the IEEE Std 802.16 air
   interface.  This section describes the IPv6 link in the context of a
   WiMAX network.  The MS and the AR are connected via a combination of:

WiMAXはIEEE Std802.16空気インタフェースに基づくネットワークに関する例です。 このセクションはWiMAXネットワークの文脈でIPv6リンクについて説明します。 MSとARは以下の組み合わせでつなげられます。

   1.  The transport connection that is identified by a Connection
       Identifier (CID) over the air interface, i.e., the MS and BS, and

1. そしてすなわち、空気インタフェース、MS、およびBSの上でa Connection Identifier(CID)によって特定される輸送接続。

   2.  A GRE tunnel between the BS and AR that transports the IPv6
       packets

2. BSとARの間のIPv6パケットを輸送するGREトンネル

   From an IPv6 perspective, the MS and the AR are connected by a point-
   to-point link.  The combination of transport connection over the air
   interface and the GRE tunnel between the BS and AR creates a (point-
   to-point) tunnel at the layer below IPv6.

IPv6見解から、MSとARはポイントへのポイントリンクによってつなげられます。 BSとARの間の空気インタフェースとGREトンネルの上の輸送接続の組み合わせは(ポイントで、指します)トンネルをIPv6の下の層に作成します。

   The collection of service flows (tunnels) to an MS is defined as a
   single link.  Each link has only an MS and an AR.  Each MS belongs to
   a different link.  No two MSs belong to the same link.  A different
   prefix should be assigned to each unique link.  This link is fully
   consistent with a standard IP link, without exception, and conforms
   with the definition of a point-to-point link in [RFC4861].

MSへのサービス流れ(トンネル)の収集は単一のリンクと定義されます。 各リンクには、MSとARしかありません。 各MSは異なったリンクに属します。 いいえtwo、MSsは同じリンクに属します。 異なった接頭語はそれぞれのユニークなリンクに割り当てられるべきです。 このリンクは、例外なしで標準のIPリンクと完全に一致していて、[RFC4861]でポイントツーポイント接続の定義に従います。

Appendix C.  IPv6 Link Establishment in WiMAX

WiMAXへの付録C.IPv6リンク設立

   The mobile station performs initial network entry as specified in
   802.16.  On successful completion of the network entry procedure, the
   ASN gateway/AR triggers the establishment of the initial service flow
   (ISF) for IPv6 towards the MS.  The ISF is a GRE tunnel between the
   ASN-GW/AR and the BS.  The BS in turn requests the MS to establish a
   transport connection over the air interface.  The end result is a
   transport connection over the air interface for carrying IPv6 packets
   and a GRE tunnel between the BS and AR for relaying the IPv6 packets.
   On successful completion of the establishment of the ISF, IPv6
   packets can be sent and received between the MS and AR.  The ISF
   enables the MS to communicate with the AR for host configuration
   procedures.  After the establishment of the ISF, the AR can send a
   router advertisement to the MS.  An MS can establish multiple service
   flows with different quality of service (QoS) characteristics.  The
   ISF can be considered as the primary service flow.  The ASN-GW/AR
   treats each ISF, along with the other service flows to the same MS,
   as a unique link that is managed as a (virtual) interface.

移動局は802.16における指定されるとしての初期のネットワークエントリーを実行します。 ネットワークエントリー手順の無事終了のときに、ASNゲートウェイ/ARはIPv6のための初期のサービス流動(ISF)の設立のMSに向かって引き金となります。ISFはASN-GW/ARとBSの間のGREトンネルです。 BSは、空気インタフェースの上の輸送接続を確立するよう順番にMSに要求します。 結末は、IPv6パケットを運ぶための空気インタフェースの上の輸送接続とIPv6パケットをリレーするためのBSとARの間のGREトンネルです。 ISFの設立の無事終了のときに、MSとARの間にIPv6パケットを送って、受け取ることができます。 ISFは、MSがホスト構成手順のためにARとコミュニケートするのを可能にします。 ISFの設立の後に、ARはルータ通知をMSに送ることができます。MSは異なったサービスの質(QoS)の特性に従った複数のサービス流れを確立できます。 一次業務流動であるとISFをみなすことができます。 ASN-GW/ARは各ISFを扱います、同じMSへの他のサービス流れと共に、(仮想)のインタフェースとして管理されるユニークなリンクとして。

Patil, et al.               Standards Track                    [Page 19]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[19ページ]RFC5121IPv6

Appendix D.  Maximum Transmission Unit in WiMAX

WiMAXの付録D.マキシマム・トランスミッション・ユニット

   The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
   Hence, the IPv6 path MTU can be 1500 octets.  However, because of the
   overhead of the GRE tunnel used to transport IPv6 packets between the
   BS and AR and the 6-byte MAC header over the air interface, using a
   value of 1500 would result in fragmentation of packets.  It is
   recommended that the MTU for IPv6 be set to 1400 octets in WiMAX
   networks, and this value (different from the default) be communicated
   to the MS.  Note that the 1522-octet specification is a WiMAX forum
   specification and not the size of the SDU that can be transmitted
   over 802.16, which has a higher limit.

WiMAXフォーラム[WMF]は1522の八重奏としてマックスSDUサイズを指定しました。 したがって、IPv6経路MTUは1500の八重奏であるかもしれません。 しかしながら、空気インタフェースの上でBSとARの間のIPv6パケットと6バイトのMACヘッダーを輸送するのに使用されるGREトンネルのオーバーヘッドのために、1500年の値を使用すると、パケットの断片化はもたらされるでしょう。 IPv6のためのMTUがWiMAXネットワーク、およびこの値(デフォルトと異なった)における1400の八重奏に用意ができているのは、お勧めです。MSとコミュニケートしてください。1522八重奏の仕様がサイズではなく、802.16以上に伝えることができるSDUのWiMAXフォーラム仕様であることに注意してください。(それは、より高い限界を持っています)。

Patil, et al.               Standards Track                    [Page 20]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[20ページ]RFC5121IPv6

Authors' Addresses

作者のアドレス

   Basavaraj Patil
   Nokia Siemens Networks
   6000 Connection Drive
   Irving, TX  75039
   USA

Basavarajパティルノキアジーメンスネットワーク6000接続Driveテキサス75039アービング(米国)

   EMail: basavaraj.patil@nsn.com

メール: basavaraj.patil@nsn.com

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   USA

フランクシャーHuawei米国1700アルマ博士Suite500テキサス75075プラノ(米国)

   EMail: xiayangsong@huawei.com

メール: xiayangsong@huawei.com

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   USA

Behcet Sarikaya Huawei米国1700アルマ博士Suite500テキサス75075プラノ(米国)

   EMail: sarikaya@ieee.org

メール: sarikaya@ieee.org

   JinHyeock Choi
   Samsung AIT
   Networking Technology Lab
   P.O.Box 111
   Suwon, Korea  440-600

水原、JinHyeockチェ三星オート麦ネットワーク・テクノロジー研究室P.O.Box111韓国440-600

   EMail: jinchoe@samsung.com

メール: jinchoe@samsung.com

   Syam Madanapalli
   Ordyn Technologies
   1st Floor, Creator Building, ITPL.
   Off Airport Road
   Bangalore, India  560066

Syam Madanapalli Ordyn技術第1床、創造者ビル、ITPL。 バンガロール、空港道インド560066沖で

   EMail: smadanapalli@gmail.com

メール: smadanapalli@gmail.com

Patil, et al.               Standards Track                    [Page 21]

RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008

パティル、他 IEEE802.16 2月2008の間のIPv6 CSを通した規格Track[21ページ]RFC5121IPv6

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントは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に情報を記述してください。

Patil, et al.               Standards Track                    [Page 22]

パティル、他 標準化過程[22ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

PI関数 円周率を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る