[要約] RFC 2492は、IPv6をATMネットワーク上で利用するためのガイドラインを提供するものであり、IPv6パケットのATMネットワークへのトンネリング方法やアドレス割り当ての手法などが含まれています。目的は、IPv6をATMネットワーク上で効果的に利用するための標準化と実装の支援です。
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
IPv6 over ATM Networks
ATMネットワーク上の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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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ワーキンググループのアーキテクチャドキュメントである「IPv6 over Non Broadcast Multiple Access（NBMA）ネットワーク」に付属しています。 IPv6 over NBMAアーキテクチャをATMネットワークに適用する方法の具体的な詳細を提供します。このアーキテクチャは、IPv6近隣探索プロトコルの従来のホスト側操作を可能にすると同時に、「SVCを使用する場合」の「ショートカット」ATM転送パスの確立をサポートします。管理上構成されたポイントツーポイントPVCでの操作もサポートされています。
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ワーキンググループの「IPv6 over Non Broadcast Multiple Access（NBMA）ネットワーク」仕様[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.
ポイントツーポイントPVCサービス、または柔軟なポイントツーポイントおよびポイントツーマルチポイントSVCサービスを提供するための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.
最低限適合したIPv6 / ATMドライバーは、PVCモードの操作をサポートするものとします（SHALL）。完全なSVCモードをサポートするIPv6 / ATMドライバーは、PVCモードの操作もサポートする必要があります。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [16]で説明されているように解釈されます。
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つのノードを接続し、近隣探索およびその他のIPv6機能の使用が制限されます。 IPv6 / ATMインターフェイスは、各リンクに1つだけのネイバーを持っています。マルチキャストおよびブロードキャスト操作は、ATMレベルのユニキャスト操作に集約されるため、MARSおよびNHRPプロトコルは必要ありません。動的に検出されたショートカットはサポートされていません。
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接続で使用するために一般的に使用するために開発されたネイバーディスカバリプロトコルの拡張機能の使用を禁止するものでもありません（たとえば、逆ネイバーディスカバリー）。
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リンクはリンク層アドレスを使用しないため、リンク層アドレスオプションはNDメッセージに含めないでください[11]。リンク層アドレスオプションがNDメッセージに存在する場合、オプションは無視されるべきです（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.
最低限適合したIPv6 / ATMドライバーは、PVCモードの操作をサポートするものとします（SHALL）。 PVCのみの実装は、SVC動作モードをサポートする必要はありません。
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:
RFC 1483 [2]のモデルに従って、AAL5はデフォルトのアダプテーション層サービスである必要があり（SHALL）、（LLC / SNAP）カプセル化は、pt-pt PVCリンク上のユニキャストおよびマルチキャストパケットで使用されるデフォルトのカプセル化である必要があります。 [1]で定義されているように、デフォルトのIPv6パケットカプセル化は次のとおりです。
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] (LLC) (OUI) (PID)
[0xAA-AA-03] [0x00-00-00] [0x86-DD] [IPv6パケット]（LLC）（OUI）（PID）
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ドライバーは、構成可能なオプションとしてnullカプセル化もサポートする場合があります。 nullカプセル化が有効な場合、IPv6パケットは直接AAL5レイヤーに渡されます。 PVCの両端は、nullカプセル化を使用するように構成する必要があります。 PVCは、IPv6以外のプロトコルでは使用できません。
The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not covered by this specification.
IPv6 over PPPとPPP over AAL5 PVCの連結は、この仕様ではカバーされていません。
The default IP MTU size for PVC links is 9180 bytes as specified in [7]. Other IP MTU values MAY be used.
[7]で指定されているように、PVCリンクのデフォルトのIP MTUサイズは9180バイトです。他のIP MTU値が使用される場合があります。
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モードで使用される場合、セクション5で説明されている方法のいずれかを使用してインターフェーストークンを生成する必要があります（SHALL）。インターフェーストークンは、PVCリンク上の2つのノード間でのみ一意である必要があります。
4 SVC environments
4 SVC環境
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.
RFC 1483 [2]のモデルに従って、AAL5はデフォルトのアダプテーションレイヤーサービスである必要があり（SHALL）、（LLC / SNAP）カプセル化はSVCリンク上のユニキャストおよびマルチキャストパケットで使用されるデフォルトのカプセル化である必要があります。
As defined in [1], the default IPv6 unicast packet encapsulation SHALL be:
[1]で定義されているように、デフォルトのIPv6ユニキャストパケットカプセル化は次のとおりです。
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] (LLC) (OUI) (PID)
[0xAA-AA-03] [0x00-00-00] [0x86-DD] [IPv6パケット]（LLC）（OUI）（PID）
As defined in [1], the default IPv6 multicast packet encapsulation SHALL be:
[1]で定義されているように、デフォルトのIPv6マルチキャストパケットカプセル化は、
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] (LLC) (OUI) (PID) (mars encaps)
[0xAA-AA-03] [0x00-00-5E] [0x00-01] [pkt $ cmi] [0x86DD] [IPv6パケット]（LLC）（OUI）（PID）（mars encaps）
The IPv6/ATM driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field prior to transmission.
IPv6 / ATMドライバーのクラスターメンバーIDは、送信前に2オクテットのpkt $ cmiフィールドにコピーする必要があります。
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ドライバーは、構成可能なオプションとしてnullカプセル化もサポートする場合があります。 nullカプセル化は、あるIPv6 / ATMドライバから別のIPv6 / ATMドライバにIPv6パケットを渡す場合にのみ使用する必要があります（SHALL）。ヌルカプセル化は、IPv6 / ATMドライバーとそのローカルMARS間のpt-pt SVCで使用してはなりません（SHALL NOT）。
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.
nullカプセル化が有効な場合、IPv6パケットは直接AAL5層に渡されます。 SVCの両端は、コールセットアップフェーズ中にnullカプセル化を使用することに同意する必要があります。 SVCは、IPv6以外のプロトコルでは使用できません。
If null encapsulation is enabled on data SVCs between routers, inter-router NHRP traffic SHALL utilize a separate, parallel SVC.
ルーター間のデータSVCでnullカプセル化が有効になっている場合、ルーター間のNHRPトラフィックは、別個の並列SVCを利用する必要があります（SHALL）。
Use of null encapsulation is not encouraged when IPv6/ATM is used with MARS/NHRP/ND as described in [1].
[1]で説明されているように、MARS / NHRP / NDでIPv6 / ATMを使用する場合は、nullカプセル化の使用は推奨されません。
The encapsulation of MARS control messages (between MARS and MARS Clients) remains the same as shown in RFC 2022 [3]:
MARS制御メッセージのカプセル化（MARSとMARSクライアントの間）は、RFC 2022 [3]に示されているものと同じです。
[0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message] (LLC) (OUI) (PID)
[0xAA-AA-03] [0x00-00-5E] [0x00-03] [MARS制御メッセージ]（LLC）（OUI）（PID）
The key control field values are:
主要な制御フィールド値は次のとおりです。
The mar$afn field remains 0x0F (ATM addresses)
mar $ afnフィールドは0x0F（ATMアドレス）のままです。
The mar$pro field SHALL be 0x86DD (IPv6)
mar $ proフィールドは0x86DD（IPv6）である必要があります
The mar$op.version field remains 0x00 (MARS)
mar $ op.versionフィールドは0x00のままです（MARS）
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)
mar $ splnおよびmar $ tplnフィールド（該当する場合）は、0（nullまたは存在しない情報の場合）または16（完全なIPv6プロトコルアドレスの場合）のいずれかです。
The way in which ATM addresses are stored remains the same as shown in RFC 2022 [3]
ATMアドレスが格納される方法は、RFC 2022 [3]に示されているものと同じです。
The encapsulation of NHRP control messages remains the same as shown in RFC 2332 [4]:
NHRP制御メッセージのカプセル化は、RFC 2332 [4]に示されているものと同じです。
[0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message] (LLC) (OUI) (PID)
[0xAA-AA-03] [0x00-00-5E] [0x00-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 $ proフィールドは0x86DD（IPv6）
The ar$op.version field remains 0x01 (NHRP)
ar $ op.versionフィールドは0x01（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およびar $ tplnフィールド（該当する場合）は、0（nullまたは存在しない情報の場合）または16（完全なIPv6プロトコルアドレスの場合）のいずれかです。
The way in which ATM addresses are stored remains the same as shown in RFC 2022 [3]
ATMアドレスが格納される方法は、RFC 2022 [3]に示されているものと同じです。
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では、NDリンク層アドレスオプションについて説明しています。 IPv6 / ATMドライバーの場合、サブフィールドは次の方法でエンコードする必要があります。
[NTL] defines the type and length of the ATM number immediately following the [STL] field. The format is as follows:
[NTL]は、[STL]フィールドの直後のATM番号のタイプと長さを定義します。形式は次のとおりです。
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
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フォーラム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はゼロでなければなりません。
[NBMA Number] is a variable length field containing the ATM address of the Link layer target. It is always present.
[NBMA番号]は、リンク層ターゲットの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]は、リンク層ターゲットのATMサブアドレスを含む可変長フィールドです。存在する場合と存在しない場合があります。そうでない場合、このオプションは[NBMA番号]（または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番号]および[NBMAサブアドレス]フィールドのオクテット順序は、MARSおよびNHRP制御メッセージで使用されるものと同じである必要があります。
4.2 UNI 3.0/3.1 signaling issues (SVC mode).
4.2 UNI 3.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ノードが別のIPv6ノードに通話を発信する場合、UNI 3.0 / 3.1 SVC [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]の手順は引き続きIPv6 over ATMに適用されますが、ノードとルーターはIPv4 MTU検出ではなくIPv6パスMTU検出[8]を使用することに注意してください。さらに、IPv6ノードはPath MTU Discoveryを実装する必要はありませんが、IPv6 / ATMノードはそれを実装する必要があります（SHOULD）。また、IPv6ノードは各VCに適切なMTUをネゴシエートするため、どちらのノードもPath MTU DiscoveryをトリガーするためのPacket Too Bigメッセージを受信することはないため、Path MTUはトリガーされません。ノードが1つ以上のルーターを介して通信している場合、レガシーネットワークの場合と同様に、パス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].
[1]のセクション5.1で要求されているように、PVCモードとSVCモードの両方の操作で、次のいずれかの方法を使用してインターフェイストークンを生成する必要があります（SHALL）。
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エンドシステムアドレス（AESA、以前はNSAPAと呼ばれていた）で識別される場合、インターフェイストークンは、次のようにAESAのESI値とSEL値から形成される場合があります。
[0x00][ESI][SEL]
[0x00] [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.
[0x00]は常に0に設定される1オクテットフィールドです。EUI-64グローバル/ローカルビット[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値が常に含まれています。
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に固有の1つ以上の48ビットMAC値のセット（NICのROMに構成されたMACアドレスなど）にアクセスできる場合、IPv6 / ATMインターフェースはこれらの値の1つを使用して一意の[10]で説明されているインターフェイストークン。
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.)
基盤となるATM NICドライバーがATM NICに固有の1つ以上の64ビットEUI-64値のセット（例：NICのROMに構成されたEUI-64アドレス）にアクセスできる場合、IPv6 / ATMインターフェイスはこれらの値の1つを使用する必要があります（SHOULD）一意のインターフェイストークンを作成します。グローバル/ローカル識別子ビット[10]を反転させた後。 （これらの値と、ATMドライバによってローカルATMスイッチに登録されたESIとの関係は、このドキュメントの範囲外です。）
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から読み取られるオクテット文字列に許可される唯一の変更は、グローバル/ローカル識別子ビットの反転です。
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グローバル/ローカルインジケーターが0に設定されていることを示します。これは、これがグローバルに一意なIPv6インターフェイストークンではないことを示します。
[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桁左にシフトし、4つの最下位ビットの3番目に上位のセミオクテットオクテットの。
[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]-[D1D0]示されているように、それぞれが最上位4ビットに1つ、最下位4ビットに1つ、2つのE.164桁を含むオクテット。
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].
MAC、EUI-64、AESA、またはE.164の値がインターフェイストークンの生成に使用できない場合、[10]の付録Aで説明されているように、インターフェイストークンを生成する必要があります。
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フィールドに関連付けられているか、完全に別個のESIのセットがローカルATMスイッチに登録されて、一連の一意のAESAを作成している可能性があります。
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は（4.1で説明されているように）ATM NICで使用可能な64ビット値の範囲から別のインターフェーストークンを選択する必要があります（SHALL）。各vhostは、2つ以上のvhostが同じLLに同じインターフェイストークンをアドバタイズしないように、IPv6 / ATMインターフェイスを実装する必要があります（SHALL）。 （この要件への適合は、異なるSEL値、ESI値、またはその両方を選択することによって達成できます。）
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ワーキンググループの「IPv6 over Non Broadcast Multiple Access（NBMA）ネットワーク」仕様[1]のATM固有の付属文書です。これは、管理上構成されたPVC、および動的に確立されたSVCの動作モードのコードポイントを指定します。
There are no major open issues. Comments to the ION mailing list are solicited (ion@nexen.com).
大きな未解決の問題はありません。 IONメーリングリストへのコメントは募集されています（ion@nexen.com）。
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を変更しなくても機能します。これには、両方の近隣探索プロトコルの認証と暗号化、および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の仕事は、ベルコアでの雇用中に発生しました。セクション4の要素は、Matt CrawfordのIPv6 over Ethernetに関するメモから借用したものです。
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.
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.
Authors' Addresses
著者のアドレス
Grenville Armitage Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA
Grenville Armitage Bell Laboratories、Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733 USA
EMail: gja@lucent.com
Peter Schulter BrightTiger Technologies 125 Nagog Park Acton, MA 01720
Technologies 125 Nagga Park Octen by Peter Schulter Brighatting、Ma 017
EMail: paschulter@acm.org
Markus Jork European Applied Research Center Digital Equipment GmbH CEC Karlsruhe Vincenz-Priessnitz-Str. 1 D-76131 Karlsruhe Germany
Markus Jork欧州応用研究センターDigital Equipment GmbH CECカールスルーエヴィンセンツプリエスニッツStr。 1 D-76131カールスルーエドイツ
EMail: jork@kar.dec.com
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。、シュルター、P。、ジョーク、M.、G。ハーター、「IPv6 over Non-Broadcast Multiple Access（NBMA）ネットワーク」、RFC 2491、1999年1月。
[2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, July 1993.
[2] Heinanen、J。、「ATM Adaption Layer 5上のマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.
[3] アーミテージ、G。、「UNI 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、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.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、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] Perez、M.、Liaw、F.、Mankin、A.、Hoffman、E.、Grossman、D。およびA. Malis、「ATM Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, May 1994.
[7] Atkinson、R。、「ATM AAL5で使用するためのデフォルトIP MTU」、RFC 1626、1994年5月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8] マッキャンJ.、ディアリングS.、J。モーグル、「IPバージョン6のパスMTUディスカバリー」、RFC 1981、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] ATMフォーラム、「ATM User Network Interface（UNI）Specification Version 3.1」、ISBN 0-13-393828-X、Prentice Hall、Englewood Cliffs、NJ、1995年6月。
[10] Hinden, B. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[10] Hinden、B. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、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. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.アーミテージ他al。規格トラック[ページ12]