RFC2492 日本語訳

Network Working Group                                       G. Armitage
Request for Comments: 2492                          Lucent Technologies
Category: Standards Track                                   P. Schulter
                                               BrightTiger Technologies
                                                                M. Jork
                                                 Digital Equipment GmbH
                                                           January 1999

コメントを求めるワーキンググループG.アーミテージ要求をネットワークでつないでください: 2492年のルーセントテクノロジーズカテゴリ: 標準化過程P.Schulter BrightTiger技術M.Jorkデジタル機器GmbH1999年1月

                         IPv6 over ATM Networks

気圧ネットワークの上のIPv6

Status of this Memo

この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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   This document is a companion to the ION working group's architecture
   document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".
   It provides specific details on how to apply the IPv6 over NBMA
   architecture to ATM networks. This architecture allows conventional
   host-side operation of the IPv6 Neighbor Discovery protocol, while
   also supporting the establishment of 'shortcut' ATM forwarding paths
   (when using SVCs).  Operation over administratively configured Point
   to Point PVCs is also supported.

このドキュメントはIONワーキンググループのアーキテクチャドキュメント、「Non Broadcast Multiple Access(NBMA)ネットワークの上のIPv6」の仲間です。 それはどうNBMAアーキテクチャの上にIPv6を適用するかに関する特定の詳細をATMネットワークに明らかにします。 このアーキテクチャはまた、'近道'ATM推進経路の設立をサポートしている間(SVCsを使用するとき)、IPv6 Neighborディスカバリープロトコルの従来のホストサイド手術を許します。 また、Point PVCsへの行政上構成されたPointの上の操作はサポートされます。

1. Introduction.

1. 序論。

   This document is an ATM-specific companion document to the ION
   working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
   networks" specification [1].  Terminology and architectural
   descriptions will not be repeated here.

このドキュメントはワーキンググループのIONもの(「Non Broadcast Multiple Access(NBMA)ネットワークの上のIPv6」仕様[1])へのATM特有の仲間ドキュメントです。 用語と建築記述はここで繰り返されないでしょう。

   The use of ATM to provide point to point PVC service, or flexible
   point to point and point to multipoint SVC service, is covered by
   this document.

多点SVCサービスへのPVCサービスをポイント・ツー・ポイントに提供するATMの使用か、フレキシブルなポイント・ツー・ポイントとポイントがこのドキュメントで含まれています。

   A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
   operation. An IPv6/ATM driver that supports the full SVC mode SHALL
   also support PVC mode of operation.

SHALLがPVC運転モードをサポートする最少量で従っているIPv6/ATMドライバー。 また、完全なSVCモードSHALLがサポートPVC運転モードであるとサポートするIPv6/ATMドライバー。

G. Armitage, et. al.        Standards Track                     [Page 1]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[1ページ]。

2. Specification Terminology

2. 仕様用語

   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 [16].

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

3. PVC Environments

3. PVC環境

   When the ATM network is used in PVC mode, each PVC will connect
   exactly two nodes and the use of Neighbor Discovery and other IPv6
   features is limited.  IPv6/ATM interfaces have only one neighbor on
   each Link. The MARS and NHRP protocols are NOT necessary, since
   multicast and broadcast operations collapse down to an ATM level
   unicast operation. Dynamically discovered shortcuts are not
   supported.

ATMネットワークがPVCモードで使用されるとき、各PVCはまさに2つのノードを接続するでしょう、そして、Neighborディスカバリーと他のIPv6の特徴の使用は限られています。 IPv6/ATMインタフェースには、1人の隣人しか各Linkにいません。 火星とNHRPプロトコルは必要ではありません、マルチキャストと放送操作がATMの平らなユニキャスト操作まで崩れるので。 ダイナミックに発見された近道はサポートされません。

   The actual details of encapsulations, MTU, and link token generation
   are provided in the following sections.

カプセル化、MTU、およびリンクトークン世代の実際の詳細は以下のセクションに明らかにされます。

   This use of PVC links does not mandate, nor does it prohibit the use
   of extensions to the Neighbor Discovery protocol which may be
   developed for either general use of for use in PVC connections (for
   example, Inverse Neighbor Discovery).

PVCリンクのこの使用は、または、ディスカバリーがPVC接続(例えば、Inverse Neighborディスカバリー)における使用のために一般的使用のために開発されるかもしれないものについて議定書の中で述べるNeighborに拡張子の使用を禁止しないのを強制しません。

   Since ATM PVC links do not use link-layer addresses, the link-layer
   address options SHOULD not be included in any ND message [11].  If a
   link-layer address option is present in an ND message, then the
   option SHOULD be ignored.

ATM PVCがリンクするので、リンクレイヤが扱う使用、アドレスオプションSHOULDリンクレイヤは何かノースダコタメッセージ[11]に含まれていませんか? リンクレイヤアドレスオプションがそうなら次に、ノースダコタメッセージ、オプションでSHOULDを寄贈してください。無視されます。

   A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
   operation.  PVC only implementations are not required to support any
   SVC mode of operation.

SHALLがPVC運転モードをサポートする最少量で従っているIPv6/ATMドライバー。 どんなSVCモードもサポートする実装だけは必要でない操作のPVC。

3.1 Default Packet Encapsulation

3.1 デフォルトパケットカプセル化

   Following the model in RFC 1483 [2], AAL5 SHALL be the default
   Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be
   default encapsulation used by unicast and multicast packets across
   pt-pt PVC links. As defined in [1], the default IPv6 packet
   encapsulation SHALL be:

デフォルトがAdaptation Layerサービスと、(LLC/SNAP)カプセル化SHALLであったならPt Ptの向こう側のユニキャストによって使用されるデフォルトカプセル化とマルチキャストパケットがPVCリンクであったならRFC1483[2]のモデル、AAL5 SHALLに続きます。 [1]、デフォルトIPv6パケットカプセル化SHALLで定義される、あります:

         [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
             (LLC)       (OUI)     (PID)

[0xAA-AA-03][0×00 00-00][0×86DD][IPv6パケット](LLC)(OUI)(PID)

G. Armitage, et. al.        Standards Track                     [Page 2]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[2ページ]。

3.2 Optional null encapsulation

3.2 任意のヌルカプセル化

   IPv6/ATM drivers MAY also support null encapsulation as a
   configurable option. When null encapsulation is enabled, the IPv6
   packet is passed directly to the AAL5 layer. Both ends of the PVC
   MUST be configured to use null encapsulation. The PVC will not be
   available for use by protocols other than IPv6.

また、IPv6/ATMドライバーは構成可能なオプションとしてヌルカプセル化をサポートするかもしれません。 ヌルカプセル化が可能にされるとき、IPv6パケットは直接AAL5層に通過されます。 両端、PVC MUSTでは、構成されて、ヌルカプセル化を使用してください。 PVCはIPv6以外のプロトコルで使用に利用可能にならないでしょう。

3.3 PPP encapsulation

3.3 PPPカプセル化

   The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not
   covered by this specification.

AAL5 PVCsの上にPPPがあるPPPの上のIPv6のconcatentationはこの仕様でカバーされていません。

3.4 MTU For PVC Environments

3.4 PVC環境のためのMTU

   The default IP MTU size for PVC links is 9180 bytes as specified in
   [7].  Other IP MTU values MAY be used.

PVCリンクへのデフォルトIP MTUサイズは指定されるとして[7]の9180バイトです。 他のIP MTU値は使用されるかもしれません。

3.5 Interface Token Formats in PVC Environments

3.5 PVC環境におけるインタフェーストークン形式

   When the ATM network is used in PVC mode interface tokens SHALL be
   generated using one of the methods described in section 5. Interface
   tokens need only be unique between the two nodes on the PVC link.

ATMネットワークがPVCモードインタフェーストークンSHALLで使用されたら、セクション5で説明されたメソッドの1つを使用することで生成されてください。 インタフェーストークンはPVCリンクの上の2つのノードの間でユニークであるだけでよいです。

4 SVC environments

4 SVC環境

4.1 SVC Specific Code Points

4.1 SVC特定のコード・ポイント

4.1.1 ATM Adaptation Layer encapsulation for SVC environments

4.1.1 SVC環境のためのATM Adaptation Layerカプセル化

   Following the model in RFC 1483 [2], AAL5 SHALL be the default
   Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the
   default encapsulation used by unicast and multicast packets across
   SVC links.

デフォルトがAdaptation Layerサービスと、(LLC/SNAP)カプセル化SHALLであったならデフォルトがSVCリンクの向こう側にユニキャストとマルチキャストパケットによって使用されるカプセル化であったならRFC1483[2]のモデル、AAL5 SHALLに続きます。

4.1.2 Unicast Packet Encapsulation

4.1.2 ユニキャストパケットカプセル化

   As defined in [1], the default IPv6 unicast packet encapsulation
   SHALL be:

[1]、デフォルトIPv6ユニキャストパケットカプセル化SHALLで定義される、あります:

         [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
             (LLC)       (OUI)     (PID)

[0xAA-AA-03][0×00 00-00][0×86DD][IPv6パケット](LLC)(OUI)(PID)

G. Armitage, et. al.        Standards Track                     [Page 3]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[3ページ]。

4.1.3 Multicast packet encapsulation

4.1.3 マルチキャストパケットカプセル化

   As defined in [1], the default IPv6 multicast packet encapsulation
   SHALL be:

[1]、デフォルトIPv6マルチキャストパケットカプセル化SHALLで定義される、あります:

         [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
         packet]
             (LLC)       (OUI)     (PID)    (mars encaps)

[0xAA-AA-03][0×00 00-5E][0×00-01][pkt$cmi][0x86DD][IPv6パケット](LLC)(OUI)(PID)(encapsを損ないます)

         The IPv6/ATM driver's Cluster Member ID SHALL be copied into
         the 2 octet pkt$cmi field prior to transmission.

IPv6/ATMドライバーのClusterメンバーID SHALL、トランスミッションの前に2八重奏pktドルのcmi分野にコピーされてください。

4.1.4 Optional null encapsulation

4.1.4 任意のヌルカプセル化

   IPv6/ATM drivers MAY also support null encapsulation as a
   configurable option. Null encapsulation SHALL only be used for
   passing IPv6 packets from one IPv6/ATM driver to another. Null
   encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM
   driver and its local MARS.

また、IPv6/ATMドライバーは構成可能なオプションとしてヌルカプセル化をサポートするかもしれません。 ヌルカプセル化SHALL、1人のIPv6/ATMドライバーから別のドライバーまでパケットをIPv6に通過するのに単に使用されてください。 ヌルカプセル化SHALL NOT、IPv6/ATMドライバーとその地方の火星の間のPt Pt SVCで使用されてください。

   If null encapsulation is enabled, the IPv6 packet is passed directly
   to the AAL5 layer. Both ends of the SVC MUST agree to use null
   encapsulation during the call SETUP phase.  The SVC will not be
   available for use by protocols other than IPv6.

ヌルカプセル化が可能にされるなら、IPv6パケットは直接AAL5層に通過されます。 SVC MUSTの両端は、呼び出しSETUP段階の間、ヌルカプセル化を使用するのに同意します。 SVCはIPv6以外のプロトコルで使用に利用可能にならないでしょう。

   If null encapsulation is enabled on data SVCs between routers,
   inter-router NHRP traffic SHALL utilize a separate, parallel SVC.

ヌルカプセル化がルータの間のデータSVCsで可能にされるなら、相互ルータNHRPトラフィックSHALLは別々の、そして、平行なSVCを利用します。

   Use of null encapsulation is not encouraged when IPv6/ATM is used
   with MARS/NHRP/ND as described in [1].

IPv6/ATMが火星/NHRP/ノースダコタと共に[1]で説明されるように使用されるとき、ヌルカプセル化の使用は奨励されません。

4.1.5 MARS control messages

4.1.5 火星コントロールメッセージ

   The encapsulation of MARS control messages (between MARS and MARS
   Clients) remains the same as shown in RFC 2022 [3]:

火星コントロールメッセージ(火星と火星Clientsの間の)のカプセル化はRFC2022[3]に示されるように同じままで残っています:

      [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
         (LLC)       (OUI)     (PID)

[0xAA-AA-03][0×00 00-5E][0×00-03][火星コントロールメッセージ](LLC)(OUI)(PID)

   The key control field values are:

主要な制御フィールド値は以下の通りです。

      The mar$afn field remains 0x0F (ATM addresses)

$afn分野残り0x0Fを損なってください。(ATMアドレス)

      The mar$pro field SHALL be 0x86DD (IPv6)

$プロ分野SHALLを損なってください、0x86DDになってください。(IPv6)

      The mar$op.version field remains 0x00 (MARS)

損なう、$op.version分野は0×00のままで残っています。(火星)

G. Armitage, et. al.        Standards Track                     [Page 4]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[4ページ]。

   The mar$spln and mar$tpln fields (where relevant) are either 0 (for
   null or non-existent information) or 16 (for the full IPv6 protocol
   address)

損なう、$がsplnして、損なう、$のtpln分野(関連しているところ)は、どちらかの0(ヌルの、または、実在しない情報のための)か16です。(完全なIPv6プロトコルアドレスのための)

   The way in which ATM addresses are stored remains the same as shown
   in RFC 2022 [3]

ATMアドレスが保存される方法はRFC2022に示されるように同じままで残っています。[3]

4.1.6 NHRP control messages

4.1.6 NHRPコントロールメッセージ

   The encapsulation of NHRP control messages remains the same as shown
   in RFC 2332 [4]:

NHRPコントロールメッセージのカプセル化はRFC2332[4]に示されるように同じままで残っています:

      [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message]
         (LLC)       (OUI)     (PID)

[0xAA-AA-03][0×00 00-5E][0×00-03][NHRPコントロールメッセージ](LLC)(OUI)(PID)

   The key control field values are:

主要な制御フィールド値は以下の通りです。

      The ar$afn field remains 0x0F (ATM addresses)

ar$afn分野残り0x0F(ATMアドレス)

      The ar$pro field SHALL be 0x86DD (IPv6)

ar$プロ分野SHALL、0x86DDになってください。(IPv6)

      The ar$op.version field remains 0x01 (NHRP)

ar$op.version分野は0×01のままで残っています。(NHRP)

   The ar$spln and ar$tpln fields (where relevant) are either 0 (for
   null or non-existent information) or 16 (for the full IPv6 protocol
   address)

ar$splnとtplnがさばく(関連しているところ)ar$は、どちらかの0(ヌルの、または、実在しない情報のための)か16です。(完全なIPv6プロトコルアドレスのための)

   The way in which ATM addresses are stored remains the same as shown
   in RFC 2022 [3]

ATMアドレスが保存される方法はRFC2022に示されるように同じままで残っています。[3]

4.1.7 Neigbor Discovery control messages

4.1.7 Neigborディスカバリーコントロールメッセージ

   Section 5.2 of [1] describes the ND Link-layer address option.  For
   IPv6/ATM drivers, the subfields SHALL be encoded in the following
   manner:

[1]のセクション5.2はノースダコタのLink-層のアドレスオプションについて説明します。 IPv6/ATMドライバー、部分体SHALL、以下の方法でコード化されてください:

      [NTL] defines the type and length of the ATM number immediately
      following the [STL] field. The format is as follows:

すぐに[STL]野原に続いて、[NTL]はATM番号のタイプと長さを定義します。 形式は以下の通りです:

            7 6 5 4 3 2 1 0
            +-+-+-+-+-+-+-+-+
            |0|x|  length   |
            +-+-+-+-+-+-+-+-+

7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |0|x| 長さ| +-+-+-+-+-+-+-+-+

G. Armitage, et. al.        Standards Track                     [Page 5]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[5ページ]。

      The most significant bit is reserved and MUST be set to zero.  The
      second most significant bit (x) is a flag indicating whether the
      ATM number is in:

最も重要なビットを予約されていて、ゼロに設定しなければなりません。 2番目の最上位ビット(x)はATM番号が以下にあるかを示す旗です。

          ATM Forum AESA format (x = 0).
          Native E.164 format (x = 1).

ATM Forum AESAは(x=0)をフォーマットします。 ネイティブのE.164は(x=1)をフォーマットします。

      The bottom 6 bits represent an unsigned integer value indicating
      the length of the associated ATM address field in octets.

下部6ビットは八重奏における、関連ATMアドレス・フィールドの長さを示す符号のない整数値を表します。

   The [STL] format is the same as the [NTL] field. Defines the length
   of the subaddress field, if it exists. If it does not exist this
   entire octet field MUST be zero. If the subaddress exists it will be
   in AESA format, so flag x SHALL be zero.

[STL]形式は[NTL]分野と同じです。 存在しているなら、「副-アドレス」分野の長さを定義します。 存在していないなら、この全体の八重奏分野はゼロであるに違いありません。 「副-アドレス」が存在しているとAESA形式にはそれがあるので、x SHALLに旗を揚げさせてください。ゼロになってください。

   [NBMA Number] is a variable length field containing the ATM address
   of the Link layer target. It is always present.

[NBMA Number]はLink層の目標のATMアドレスを含む可変長フィールドです。 それはいつも存在しています。

   [NBMA Subaddress] is a variable length field containing the ATM
   subaddress of the Link layer target. It may or may not be present.
   When it is not, the option ends after the [NBMA Number] (or any
   additional padding for 8 byte alignment).

[NBMA Subaddress]はLink層の目標のATM subaddressを含む可変長フィールドです。 それは存在しているかもしれません。 それがそうでないときに、オプションは[NBMA Number](または、8バイトの整列のためのどんな追加詰め物も)の後に終わります。

   The octet ordering of the [NBMA Number] and [NBMA Subaddress] fields
   SHALL be the same as that used in MARS and NHRP control messages.

[NBMA Number]と[NBMA Subaddress]の八重奏注文は火星の中で使用されたそれと同じくらいとNHRPがコントロールメッセージであったならSHALLをさばきます。

4.2 UNI 3.0/3.1 signaling issues (SVC mode).

4.2 UNI3.0/3.1シグナリングは(SVCモード)を発行します。

   When an IPv6 node places a call to another IPv6 node, it SHOULD
   follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs
   [9] and negotiating MTU.  The default IP MTU size on a LL is 9180
   bytes as specified in [7].

IPv6ノードがaを置いたら別のIPv6ノードに呼びかけてください、それ。SHOULDはUNI3.0/3.1SVCs[9]に合図して、MTUを交渉するための[6]と[7]で手順に従います。 LLのデフォルトIP MTUサイズは指定されるとして[7]の9180バイトです。

   Note that while the procedures in [7] still apply to IPv6 over ATM,
   IPv6 Path MTU Discovery [8] is used by nodes and routers rather than
   IPv4 MTU discovery. Additionally, while IPv6 nodes are not required
   to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it.
   Also, since IPv6 nodes will negotiate an appropriate MTU for each VC,
   Path MTU should never be triggered since neither node should ever
   receive a Packet Too Big message to trigger Path MTU Discovery.  When
   nodes are communicating via one or more routers Path MTU Discovery
   will be used just as it is for legacy networks.

[7]の手順がATMの上でまだIPv6に適用されている間IPv6 Path MTUディスカバリー[8]がIPv4 MTU発見よりむしろノードとルータによって使用されることに注意してください。 さらに、IPv6ノードが、Path MTUがディスカバリーであると実装する必要はない間、IPv6/ATMノードSHOULDはそれを実装します。 また、IPv6ノードが各VCのために適切なMTUを交渉するとき、どちらのノードもPath MTUディスカバリーの引き金となるPacket Too Bigメッセージを受け取るはずがないので、Path MTUは決して引き起こされるべきではありません。 ちょうどそれがレガシーネットワークのためのものであって、ノードがいつ、1を通って交信しているか、そして、より多くのルータPath MTUディスカバリーが使用されるでしょう。

5 Interface Tokens

5 インタフェーストークン

   For both PVC and SVC modes of operation, one of the following methods
   SHALL be used to generate Interface Tokens as required by section 5.1
   of [1].

PVCとSVC運転モード、以下のメソッドSHALLの1つの両方に関しては、使用されて、必要に応じて[1]のセクション5.1のそばでInterface Tokensを生成してください。

G. Armitage, et. al.        Standards Track                     [Page 6]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[6ページ]。

5.1 Interface Tokens Based on ESI values

5.1 ESI値のインタフェースTokens Based

   When the underlying ATM interface is identified by an ATM End System
   Address (AESA, formerly known as an NSAPA), the interface token MAY
   be formed from the ESI and SEL values in the AESA as follows:

基本的なATMインタフェースがATM End System Address(以前NSAPAとして知られていたAESA)によって特定されるとき、インタフェーストークンは以下のAESAでESIとSEL値から形成されるかもしれません:

          [0x00][ESI][SEL]

[0×00][ESI][SEL]

   [0x00] is a one octet field which is always set to 0.
          Note that the bit corresponding to the EUI-64 Global/Local bit
          [5] is always reset indicating that this address is not a
          globally unique IPv6 interface token.

[0×00]はいつも0に設定される1つの八重奏分野です。 EUI-64 Global/地方のビット[5]に対応するビットがいつもこのアドレスがグローバルにユニークなIPv6インタフェーストークンでないことを示すリセットであることに注意してください。

   [ESI] is a six octet field.
          This field always contains the six octet ESI value for the
          AESA used to address the specific instance of the IPv6/ATM
          interface.

[ESI]は6八重奏分野です。 この分野はいつもIPv6/ATMインタフェースの特定のインスタンスを扱うのに使用されるAESAのための6八重奏ESI価値を含んでいます。

   [SEL] is a one octet field.
          This field always contains the SEL value from the AESA used to
          address the specific instance of the IPv6/ATM interface.

[SEL]は1つの八重奏分野です。 この分野はいつもIPv6/ATMインタフェースの特定のインスタンスを扱うのに使用されるAESAからのSEL値を含んでいます。

5.2 Interface Tokens Based on 48 Bit MAC Values

5.2 48ビットのMAC値に基づくインタフェーストークン

   Where the underlying ATM NIC driver has access to a set of one or
   more 48 bit MAC values unique to the ATM NIC (e.g. MAC addresses
   configured into the NIC's ROM), the IPv6/ATM interface MAY use one of
   these values to create a unique interface token as described in [10].

基本的なATM NICドライバーがATM NIC(例えばNICのROMに構成されたMACアドレス)にユニークな48ビットの1つ以上のMAC値のセットに近づく手段を持っているところでは、IPv6/ATMインタフェースは、[10]で説明されるようにユニークなインタフェーストークンを作成するのにこれらの値の1つを使用するかもしれません。

5.3 Interface Tokens Based on EUI-64 Values

5.3 EUI-64値に基づくインタフェーストークン

   Where the underlying ATM NIC driver has access to a set of one or
   more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
   addresses configured into the NIC's ROM), the IPv6/ATM interface
   SHOULD use one of these values to create a unique interface token.
   after inverting the Global/Local identifier bit [10].  (Any
   relationship between these values and the ESI(s) registered with the
   local ATM switch by the ATM driver are outside the scope of this
   document.)

Global/地方の識別子ビット[10]を逆にした後に、基本的なATM NICドライバーが1セットの1つにどこに近づく手段を持っているか、そして、より多くの64がEUI-64値に噛み付いて、ATM NIC(例えばNICのROMに構成されたEUI-64アドレス)(ユニークなインタフェーストークンを作成するこれらの値のIPv6/ATMインタフェースSHOULD使用1)にユニークにしました。 (このドキュメントの範囲の外にATMドライバーによって地方のATMスイッチに示されたこれらの値とESI(s)とのどんな関係もあります。)

   When EUI-64 values are used for IPv6 interface tokens the only
   modification allowed to the octet string read from the NIC is
   inversion of the Global/Local identifier bit.

EUI-64値が唯一の変更が八重奏ストリングに許容したIPv6インタフェーストークンに使用されるとき、NICから読まれているのは、Global/地方の識別子ビットの逆です。

G. Armitage, et. al.        Standards Track                     [Page 7]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[7ページ]。

5.4 Interface Tokens Based on Native E.164 Addresses

5.4 固有のE.164アドレスに基づくインタフェーストークン

   When an interface uses Native E.164 addresses then the E.164 values
   MAY be used to generate an interface token as follows:

インタフェースがその時ネイティブのE.164アドレスを使用すると、E.164値は以下のインタフェーストークンを生成するのに使用されるかもしれません:

          [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

   [D14] A single octet containing the semi-octet representing the most
   significant E.164 digit shifted left four bits to the most
   significant four bits of the octet.  The lower four bits MUST be set
   to 0.  Note that the EUI-64 Global/Local indicator is set to 0
   indicating that this is not a globally unique IPv6 interface token.

[D14] 最も重要なE.164ケタを表しながら準八重奏を含むただ一つの八重奏は左で八重奏の最も重要な4ビットに4ビットを移動させました。 低級4ビットを0に設定しなければなりません。 EUI-64 Global/ローカルのインディケータがこれがグローバルにユニークなIPv6インタフェーストークンでないことを示す0に設定されることに注意してください。

   [D13D12] A single octet containing the semi-octet representing the
   second most significant E.164 digit [D13] shifted left four places to
   the most significant bits of the octet, and the third most
   significant semi-octet in the four least significant bits of the
   octet.

[D13D12] 2番目に重要なE.164ケタ[D13]を表しながら準八重奏を含むただ一つの八重奏は左で八重奏の最も重要なビット、および八重奏の4つの最下位ビットにおける3番目に重要な準八重奏に4つの場所を移行させました。

   [D11D10] - [D1D0] Octets each containing two E.164 digits, one in the
   most significant four bits, and one in the least significant four
   bits as indicated.

[D11D10]--示されるようにそれぞれ2E.164ケタ、最も重要な4ビットの1、および最も重要でない4ビットの1つを含む[D1D0]八重奏。

5.5 Nodes Without Unique Identifiers

5.5 ユニークな識別子のないノード

   If no MAC, EUI-64, AESA, or E.164 value is available for generating
   an interface token, then the interface token SHALL be generated as
   described in Appendix A of [10].

EUI-64、AESA、またはE.164値がMacでないなら、インタフェーストークン、次に、インタフェーストークンSHALLを生成するのに利用可能です。[10]のAppendix Aで説明されるように、生成されてください。

5.6 Multiple Logical Links on a Single Interface

5.6 単一のインタフェースの複数の論理的なリンク

   A logical ATM interface might be associated with a different SEL
   field of a common AESA prefix, or a set of entirely separate ESIs
   might have been registered with the local ATM switch to create a
   range of unique AESAs.

論理的なATMインタフェースが一般的なAESA接頭語の異なったSEL分野に関連しているかもしれませんか、またはさまざまなユニークなAESAsを作成するために完全に別々のESIsの1セットを地方のATMスイッチに登録してあるかもしれません。

   The minimum information required to uniquely identify each logical
   ATM interface is (within the context of the local switch port) their
   ESI+SEL combination.

唯一それぞれの論理的なATMインタフェースを特定するのに必要である最小の情報は彼らの(地方のスイッチポートの文脈の中の)ESI+SEL組み合わせです。

   For the vhost case described in section 5.1.2 of [1], vhost SHALL
   select a different interface token from the range of 64 bit values
   available to the ATM NIC (as described in 4.1). Each vhost SHALL
   implement IPv6/ATM interfaces in such a way that no two or more
   vhosts end up advertising the same interface token onto the same LL.
   (Conformance with this requirement may be achieved by choosing
   different SEL values, ESI values, or both.)

[1]についてセクション5.1.2で説明されたvhostケースのために、vhost SHALLはATM NICに利用可能な64ビットの値の範囲と異なったインタフェーストークンを選択します(4.1で説明されるように)。 各vhost SHALLは、そのような方法でIPv6/ATMインタフェースがそのいいえtwoか、より多くのvhostsエンドであると同じインタフェーストークンの同じLLに広告を出すのに実装します。 (この要件がある順応は異なったSEL値、ESI値、または両方を選ぶことによって、達成されるかもしれません。)

G. Armitage, et. al.        Standards Track                     [Page 8]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[8ページ]。

6. Conclusion and Open Issues.

6. 結論と未解決の問題。

   This document is an ATM-specific companion document to the ION
   working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
   networks" specification [1]. It specifies codepoints for the
   administratively configured PVC, and dynamically established SVC,
   modes of operation.

このドキュメントはワーキンググループのIONもの(「Non Broadcast Multiple Access(NBMA)ネットワークの上のIPv6」仕様[1])へのATM特有の仲間ドキュメントです。 それは行政上構成されたPVC、およびダイナミックに設立されたSVC、運転モードにcodepointsを指定します。

   There are no major open issues. Comments to the ION mailing list are
   solicited (ion@nexen.com).

どんな主要な未解決の問題もありません。 IONメーリングリストへのコメントは請求されます( ion@nexen.com )。

7. Security Considerations

7. セキュリティ問題

   While this proposal does not introduce any new security mechanisms
   all current IPv6 security mechanisms will work without modification
   for ATM.  This includes both authentication and encryption for both
   Neighbor Discovery protocols as well as the exchange of IPv6 data
   packets.

この提案は少しの新しいセキュリティー対策も紹介しませんが、すべての現在のIPv6セキュリティー対策がATMのために変更なしで動作するでしょう。 これはNeighborディスカバリープロトコルとIPv6データ・パケットの交換の両方のための認証と暗号化の両方を含んでいます。

Acknowledgments

承認

   The original IPv6/ATM work by G. Armitage occurred while employed at
   Bellcore. Elements of section 4 were borrowed from Matt Crawford's
   memo on IPv6 over Ethernet.

G.アーミテージによるオリジナルのIPv6/ATM仕事はBellcoreで使われている間、起こりました。 イーサネットの上のIPv6の上のマット・クロフォードのメモからセクション4のElementsを借りました。

   The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho,
   Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi
   Hagiwara for their contributions based on actual PVC implementations.

作者は実際のPVC実装に基づく彼らの貢献についてKazuhiko山本、Kenjiro Cho、井上由伸、Hiroshi江崎、Yoshifumi Atarashi、および萩原篤に感謝したがっています。

G. Armitage, et. al.        Standards Track                     [Page 9]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[9ページ]。

Authors' Addresses

作者のアドレス

   Grenville Armitage
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   USA

グレンビルアーミテージベル研究所、ルーセントテクノロジーズ101Crawfordsコーナー道路Holmdel、ニュージャージー07733米国

   EMail: gja@lucent.com

メール: gja@lucent.com

   Peter Schulter
   BrightTiger Technologies
   125 Nagog Park
   Acton, MA 01720

ピーターSchulter BrightTiger Technologies125Nagog Parkアクトン、MA 01720

   EMail: paschulter@acm.org

メール: paschulter@acm.org

   Markus Jork
   European Applied Research Center
   Digital Equipment GmbH
   CEC Karlsruhe
   Vincenz-Priessnitz-Str. 1
   D-76131 Karlsruhe
   Germany

マーカスJork European応用研究センターデジタル機器GmbH CECカールスルーエVincenzプリースニッツStr。 1 D-76131カールスルーエドイツ

   EMail: jork@kar.dec.com

メール: jork@kar.dec.com

G. Armitage, et. al.        Standards Track                    [Page 10]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[10ページ]。

References

参照

   [1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over
       Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January
       1999.

[1] アーミテージとG.とSchulterとP.とJorkとM.とG.Harter、「Non-放送Multiple Access(NBMA)ネットワークの上のIPv6」、RFC2491、1999年1月。

   [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
       Layer 5", RFC 1483, July 1993.

[2] Heinanen、J.、「気圧適応の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。

   [3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
       Networks", RFC 2022, November 1996.

[3] アーミテージ、G.、「UNI3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。

   [4] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[4] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。

   [5] "64-Bit Global Identifier Format Tutorial",
       http://standards.ieee.org/db/oui/tutorials/EUI64.html.

[5] 「64ビットのグローバルな識別子形式チュートリアル」、 http://standards.ieee.org/db/oui/tutorials/EUI64.html 。

   [6] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A.
       Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
       February 1995.

[6] ペレスとM.とLiawとF.とマンキンとA.とホフマンとE.とグロースマン、D.とA.Malis、「気圧でのIPの気圧合図サポート」RFC1755(1995年2月)。

   [7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626,
       May 1994.

[7] アトキンソン、R.、「ATM AAL5"、RFC1626、1994年5月の間の使用のためのデフォルトIP MTU。」

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

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

   [9] ATM Forum, "ATM User Network Interface (UNI) Specification
       Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
       Cliffs, NJ, June 1995.

[9] 気圧フォーラム、「気圧ユーザネットワーク・インターフェース(UNI)仕様バージョン3.1インチ、ISBN0-13-393828X、新米のホール、イングルウッドがけ、ニュージャージー、1995年6月。」

   [10] Hinden, B. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

[10]HindenとB.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。

   [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

[11]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。

G. Armitage, et. al.        Standards Track                    [Page 11]

RFC 2492                 IPv6 over ATM Networks             January 1999

G。 etアーミテージ、アル。 規格は1999年1月に気圧ネットワークの上でRFC2492IPv6を追跡します[11ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

G. Armitage, et. al.        Standards Track                    [Page 12]

G。 etアーミテージ、アル。 標準化過程[12ページ]