Network Working Group C. DeSanti
Request for Comments: 3831 Cisco Systems
Category: Standards Track July 2004
Transmission of IPv6 Packets over Fibre Channel
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.
この文書では、ファイバチャネル経由でIPv6パケットをカプセル化する方法、およびファイバチャネルネットワーク上でIPv6リンクローカルアドレスおよびステートレス自動設定アドレスを形成する方法を指定します。
Table Of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IPv4 as specified in [IPFC].
ファイバチャネル（FC）は、小型コンピュータシステムインタフェース（SCSI）と[IPFC]で指定されたIPv4を含むいくつかの上位層プロトコルをサポートし、高速シリアルインターフェース技術です。
The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network.
この文書の目的は、ファイバーチャネルオーバーIPバージョン6 [IPv6を】カプセル化方法を指定すると、ファイバチャネルネットワーク上でIPv6リンクローカルアドレス[AARCH]とステートレス自動設定アドレスを形成する方法を記載することです。また、このドキュメントでは、メッセージは、ファイバチャネルネットワーク上で伝送されている近隣探索[DISC]で使用するソース/ターゲットリンク層アドレスオプションの内容を説明しています。
Warning to readers familiar with Fibre Channel: both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different. See Appendix C for guidance.
ファイバチャネルに精通読者に警告：ファイバチャネルとIETF標準の両方が同じバイト送信順序を使用します。しかし、ビット番号は異なっています。指導については、付録Cを参照してください。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Fibre Channel (FC) is a gigabit speed network technology primarily used for Storage Networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standard Institute (ANSI) accredited standards committee.
ファイバチャネル（FC）は、主にストレージネットワーキングに使用する、ギガビット高速ネットワーク技術です。ファイバチャネルは、情報技術規格国際委員会のT11技術委員会（INCITS）、米国国家規格協会（ANSI）公認の規格委員会で標準化されています。
Fibre Channel devices are called Nodes. Each Node has one or more Ports that connect to Ports of other devices. Fibre Channel may be implemented using any combination of the following three topologies:
ファイバチャネルデバイスは、ノードと呼ばれます。各ノードは、他のデバイスのポートに接続する1つのまたは複数のポートを持っています。ファイバチャネルは、次の3つのトポロジのいずれかの組み合わせを用いて実現することができます。
- a point-to-point link between two Ports;
- a set of Ports interconnected by a switching network called a
Fabric, as defined in [FC-FS];
- a set of Ports interconnected with a loop topology, as defined in
[FC-AL-2].
A Node Port is more precisely called an N_Port. A Node Port that is capable of operating in a loop topology using the loop specific protocols is designated as an NL_Port. The term Nx_Port is used to generically indicate these two kinds of Node Port.
ノードのポートは、より正確にNポートと呼ばれています。ループ特定のプロトコルを使用して、ループトポロジで動作可能なノードポートは、NLポートとして指定されます。用語を総称したNx_Portノードのポートのこの2種類を示すのに使用されています。
A Fabric Port is more precisely called an F_Port. A Fabric Port that is capable of operating in a loop topology using the loop specific protocols is designated as an FL_Port. The term Fx_Port is used to generically indicate these two kinds of Fabric Port.
ファブリックポートは、より正確にFポートと呼ばれています。ループ特定のプロトコルを使用して、ループトポロジで動作することが可能であるファブリックポートは、FLポートとして指定されます。長期Fx_Portを総称するために使用されるファブリックポートのこの2種類を示しています。
From an IPv6 point of view, a Fibre Channel network, built with any combination of the FC topologies described above, is an IPv6 Link [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces.
ビューのIPv6の点からは、上述したFCトポロジの任意の組み合わせで構築されたファイバ・チャネル・ネットワークは、IPv6のリンク[IPv6の]です。 IPv6対応Nx_Portsは、[IPv6が]インタフェースを呼んでいるものです。
Fibre Channel entities are identified by permanent 64 bit long Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the first four bits defines the format of a Name_Identifier. These names are referred to in a more precise manner as follows:
ファイバチャネルエンティティは、永久的な64ビット長Name_Identifiersによって識別されます。 [FC-FS]はName_Identifiersのいくつかの形式を定義します。最初の4ビットの値はName_Identifierのフォーマットを定義します。次のようにこれらの名前は、より正確な方法で言及されています。
- an Nx_Port's Name_Identifier is called N_Port_Name;
- an Fx_Port's Name_Identifier is called F_Port_Name;
- a Node's Name_Identifier is called Node_Name;
- a Fabric's Name_Identifier is called Fabric_Name.
An Nx_Port connected to a Fibre Channel network is associated with two identifiers, its permanent N_Port_Name and a volatile 24 bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, while the N_Port_ID is used for communications among Nx_Ports.
ファイバチャネルネットワークに接続されたNx_Portは、二つの識別子、そのパーマネントのN_Port_NameとのN_Port_IDと呼ばれる揮発性の24ビットアドレスに関連付けられています。 N_Port_IDがNx_Ports間の通信のために使用されている間のN_Port_Nameは、たNx_Portを識別するために使用されます。
Each Nx_Port acquires an N_Port_ID from the Fabric by performing a process called Fabric Login or FLOGI. The FLOGI process is used also to negotiate several communications parameters between the Nx_Port and the Fabric, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the Nx_Port and the Fabric.
各たNx_Portは、ファブリックログインまたはFLOGIと呼ばれる処理を行うことにより、ファブリックからのN_Port_IDを取得します。 FLOGIプロセスは、たNx_Portとファブリックとの間で転送することができるファイバチャネルフレームの最大サイズを決定する受信データフィールドサイズ、などたNx_Portとファブリックとの間のいくつかの通信パラメータをネゴシエートするためにも使用されます。
Before effective communication may take place between two Nx_Ports, they must complete a process called Port Login or PLOGI. The PLOGI process provides each Nx_Port with the other Nx_Port's N_Port_Name, and negotiates several communication parameters, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the two Nx_Ports.
効果的なコミュニケーションが2 Nx_Portsの間で起こり得る前に、彼らはポートログインまたはPLOGIと呼ばれるプロセスを完了する必要があります。 PLOGIプロセスは、他たNx_Port者のN_Port_Nameと各たNx_Portを提供し、このような二Nx_Ports間で転送することができるファイバチャネルフレームの最大サイズを決定する受信データフィールドサイズ、などのいくつかの通信パラメータをネゴシエート。
Both Fabric Login and Port Login may be explicit, i.e., performed using specific FC control messages (called Extended Link Services or ELS), or implicit, in which the parameters are specified by configuration or other methods.
ファブリックログインとポートログインの両方が明示的であってもよい、すなわち、パラメータが設定または他の方法で指定されている、（拡張リンク・サービスまたはELSと呼ばれる）は、特定のFC制御メッセージを使用して、または暗黙的に行わ。
[FC-FS] describes the Fibre Channel protocol using 5 different levels. The FC-2 and FC-4 levels are relevant for this specification. The FC-2 level defines the FC frame format, the transport services, and control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in figure 1.
[FC-FS]は、5つの異なるレベルを使用して、ファイバチャネルプロトコルが記載されています。 FC-2、FC-4のレベルは、本明細書に関連します。 FC-2レベルは、FCフレームフォーマット、トランスポート・サービス、及び情報転送に必要な制御機能を定義します。 FC-4レベルは、のIPv4、IPv6の又はSCSIなどの上位レベルのプロトコルをサポートします。ファイバチャネルフレームフォーマットは、図1に示されています。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
図1：ファイバチャネルフレーム形式
The Start of Frame (SOF) and End of Frame (EOF) are special FC transmission words that act as frame delimiters. The CRC is 4 octets long and uses the same 32-bit polynomial used in FDDI.
フレームの開始（SOF）およびフレームの終わり（EOF）は、フレームの区切り文字として機能し、特殊なFC伝送言葉です。 CRCは、4つのオクテットの長さであり、FDDIで使用したのと同じ32ビットの多項式を使用します。
The FC Header is 24 octets long and contains several fields associated with the identification and control of the Data Field.
FCヘッダは24オクテットの長さであり、データ・フィールドの識別および制御に関連するいくつかのフィールドが含ま。
The Data Field is of variable size, ranging from 0 to 2112 octets, and includes the user data in the Frame Payload field, and Optional Headers. The currently defined Optional Headers are:
データフィールドは、0から2112オクテットまでの、可変サイズのものであり、ユーザフレームのペイロードフィールド内のデータ、およびオプションのヘッダーが含まれています。現在定義されている任意のヘッダは以下のとおりです。
- ESP_Header;
- Network_Header;
- Association_Header;
- Device_Header.
The value of the SOF field determines the FC Class of service associated with the frame. Five Classes of service are specified in [FC-FS]. They are distinguished primarily by the method of flow control between the communicating Nx_Ports and by the level of data integrity provided. A given Fabric or Nx_Port may support one or more of the following Classes of service:
SOFフィールドの値は、フレームに関連するサービスのFCクラスを決定します。サービスの5つのクラスは、[FC-FS]で指定されています。これらは、主に通信Nx_Ports間のフロー制御の方法によって、および提供されたデータの整合性のレベルにより区別されます。与えられたファブリックやたNx_Portは、サービスの次のクラスの一つ以上をサポートすることがあります。
- Class 1: Dedicated physical connection with delivery confirmation;
- Class 2: Frame multiplexed service with delivery confirmation;
- Class 3: Datagram service;
- Class 4: Fractional bandwidth;
- Class 6: Reliable multicast via dedicated connections.
An application level payload such as IPv6 is called Information Unit at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is mapped to an FC Sequence by the FC-2 level. An FC Sequence consists of one or more FC frames related by the value of the Sequence_ID (SEQ_ID) field of the FC Header.
IPv6などのアプリケーションレベルのペイロードは、ファイバチャネルのFC-4レベルの情報単位と呼ばれています。各FC-4の情報ユニットは、FC-2レベルによりFc配列にマッピングされます。 Fc配列は、FCヘッダのSEQUENCE_ID（SEQ_ID）フィールドの値によって関連する1つ以上のFCフレームで構成されています。
The maximum data that may be carried by an FC frame is 2112 octets. The maximum usable frame size depends on the Fabric and Nx_Port implementations and is negotiated during the Login process. Whenever an Information Unit to be transmitted exceeds this value, the FC-2 level segments it into multiple FC frames, sent as a single Sequence. The receiving Nx_Port reassembles the Sequence of frames and delivers a reassembled Information Unit to the FC-4 level. The Sequence Count (SEQ_CNT) field of the FC Header may be used to ensure frame ordering.
FCフレームによって実施することができる最大データ2112オクテットです。使用可能な最大フレームサイズはファブリックたNx_Portの実装に依存し、ログインプロセス中にネゴシエートされます。送信すべき情報ユニットがこの値を超えるたびに、複数のFCフレームへのFC-2レベルのセグメントは、単一のシーケンスとして送信します。受信したNx_Portは、フレームのシーケンスを再構成し、FC-4レベル再組立情報ユニットを配信します。 FCヘッダのシーケンスカウント（SEQ_CNT）フィールドは、フレーム順序を保証するために使用されてもよいです。
Multiple Sequences may be related together as belonging to the same FC Exchange. The Exchange is a mechanism used by two Nx_Ports to identify and manage an operation between them. The Exchange is opened when the operation is started between the two Nx_Ports, and closed when the operation ends. FC frames belonging to the same
複数の配列は同じFC取引所に属していると一緒に関連することができます。 Exchangeは、それらの間の操作を識別し、管理するために2つのNx_Portsによって使用されるメカニズムです。取引所は、操作が2 Nx_Portsの間で開始されたときに開かれ、動作が終了すると閉じられています。同じに所属するFCフレーム
Exchange are related by the value of the Exchange_ID fields in the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) uniquely identify the Exchange.
取引所は、FCヘッダのExchange_IDフィールドの値によって関連しています。発信Exchange_ID（OX_ID）とレスポンダExchange_ID（RX_ID）が一意交換を識別する。
This specification requires an IPv6 capable Nx_Port to have the following properties:
この仕様は、次の特性を持っているのIPv6対応を必要としたNx_Port：
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF (see section 6.1). IPv6 support for other
Name_Identifier formats is outside the scope of this
specification;
- It MUST support Class 3;
- It MUST support continuously increasing SEQ_CNT [FC-FS];
- It MUST be able to transmit and receive an FC-4 Information Unit
at least 1304 octets long;
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets.
An IPv6 packet is mapped to an Information Unit at the FC-4 level of Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 level. An FC Information Unit containing an IPv6 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format depicted in figure 2.
IPv6パケットは、順番に、FC-2レベルによりFc配列にマッピングされ、ファイバチャネルのFC-4レベルの情報単位にマッピングされます。 IPv6パケットを含むFC情報ユニットは、図2に示すFC情報ユニットの形式で、その結果、FC Network_Header [FC-FS]、およびLLC / SNAPヘッダ[IEEE-LLC]を運ばなければなりません。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 Packet
図2：FC情報ユニットマッピングのIPv6パケット
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing the FC Sequence. [AH] or [ESP] may be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence.
FC ESP_Header [FC-FS]はFC FCシーケンスを構成するフレームを固定するために使用され得ます。 [AH]または[ESP]のIPv6層にセキュリティを提供するために使用され得ます。 FCオプションヘッダーの他のタイプは、IPv6 FCシーケンスに使用してはいけません。
Typically, a Sequence consists of more than one frame. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/SNAP header. The other frames MUST NOT include them, as depicted in figure 3.
典型的には、配列は、複数のフレームから構成されています。シーケンスの最初のフレームは、FC Network_HeaderおよびLLC / SNAPヘッダを含まなければなりません。図3に示すように、他のフレームには、それらを含んではいけません。
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence
図3：IPv6のFc配列にオプションヘッダ
This specification uses FC Class 3. IPv6 packets carrying Neighbor Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. Other IPv6 packets SHOULD use Class 3 as well. The use of other Classes of service is outside the scope of this specification.
この仕様は、クラス3のFCフレーム内にカプセル化されなければならない近隣探索[DISC]メッセージを運ぶFCクラス3 IPv6パケットを使用します。他のIPv6パケットは、同様に、クラス3を使用すべきです。サービスの他のクラスの使用は、この仕様書の範囲外です。
The fields of the Fibre Channel Header are depicted in figure 4. The D_ID and S_ID fields contain respectively the destination N_Port_ID and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
ファイバチャネルヘッダーのフィールドは、D_IDとS_IDフィールドは、それぞれ先のN_Port_IDとソースのN_Port_IDが含まれている図4に描かれています。ファイバチャネル上でIPv6をカプセル化するために、次のコード・ポイントを使用しなければなりません。
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information Category [FC-FS]) - TYPE: 0x05 (IP over Fibre Channel) - CS_CTL/Prio: 0x0 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 Sequence, 0x00 for the following FC frames. If the FC ESP_Header is used, then 0x60 for the first FC frame of an IPv6 Sequence, 0x40 for the following FC frames. - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10, section 11, and [FC-FS] for additional requirements.
- R_CTL：0x04を（未承諾データ情報分類[FC-FS]でDevice_Dataフレーム） - TYPE：0x05を（ファイバーチャネルオーバーIP） - CS_CTL /プリオ：0x0の - DF_CTL：0x20の（Network_Header）IPv6のシーケンスの最初のFCフレーム用、以下のFCフレームのは0x00。 FC ESP_Headerが使用される場合、IPv6のシーケンスは、次のFCフレームの0x40の最初のFCフレームの0x60。 - F_CTL、SEQ_ID、SEQ_CNT、OX_ID、RX_ID、パラメータ：追加要件のためのセクション10、セクション11、及び[FC-FS]を参照。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format
図4：FCヘッダフォーマット
The fields of the FC Network_Header are depicted in figure 5. For use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification.
FC Network_Headerのフィールドが0x1の、0x2の、0x5のいずれか、から0xC、0xDの、から0xE、0xFのでなければなりませんのIPv6 N_Port_Namesフォーマットと共に使用するために、図5に示されています。他のName_IdentifierフォーマットのIPv6のサポートは、本明細書の範囲外です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 5: FC Network_Header Format
図5：FC Network_Headerフォーマット
The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 6. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
LLC / SNAPヘッダ[IEEE-LLC]のフィールドは、次のコード・ポイントを使用する必要があり、ファイバチャネル上のIPv6をカプセル化するために、図6に示されています。
- DSAP: 0xAA - SSAP: 0xAA - CTRL: 0x03 - OUI: 0x00-00-00 - PID: 0x86-DD
- DSAP：0xAAを - SSAP：0xAAを - CTRL：0×03 - YES：0x00-00-00 - PID：0x86で-DD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
図6：LLC / SNAPヘッダー形式
IPv6 packets are mapped to the FC-4 level using the big-endian byte ordering that corresponds to the standard network byte order or canonical form.
IPv6パケットは、標準ネットワークバイト順または標準形式に対応するビッグエンディアンバイト順を使用して、FC-4レベルにマッピングされます。
The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 65280 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option that specifies a smaller MTU, or by manual configuration of each Nx_Port. However, as required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement received on an Nx_Port has an MTU option specifying an MTU larger than 65280, or larger than a manually configured value, that MTU option MAY be logged to system management but MUST be otherwise ignored.
ファイバチャネルを介したIPv6の[IPv6の]パケットのデフォルトMTUサイズは65280オクテットです。このサイズは、ルータ広告[DISC]小さいMTUを指定するMTUオプションを含むことにより、又は各たNx_Portの手動設定によって減少させることができます。しかし、[IPv6の]によって要求されるように、MTUは1280オクテットよりも下げてはなりません。ルータ広告が受信されたNx_Portに場合MTUオプションは、システム管理に記録されてもよいが、そうでなければ無視されなければならないことは、65280より大きい、または手動で設定された値よりも大きいMTUを指定するMTUオプションを有しています。
As the default MTU size far exceeds the message sizes typically used in the Internet, an IPv6 over FC implementation SHOULD implement Path MTU Discovery [PMTUD], or at least maintain different MTU values for on-link and off-link destinations.
デフォルトMTUサイズははるかメッセージは、典型的にはインターネットで使用されるサイズ超えると、IPv6のFC上の実装は、パスMTU探索[PMTUD]を実装する、または少なくともリンク・オン及びオフリンク宛先の異なるMTU値を維持しなければなりません。
For correct operation in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
ルーティングされた環境で正しく動作させるには、ルータ広告で適切なMTUオプションを設定することが非常に重要です。
For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU.
混合メディア（例えば、イーサネットおよびファイバチャネル）が一緒にブリッジされ、正しい動作のために、すべてのメディアの最小のMTUはMTUオプションのルータによって通知されなければなりません。存在しないルータが存在しない場合、このMTUを手動で最小のMTUよりも大きいデフォルトMTUを有する媒体に接続されている各ノードで構成されなければなりません。
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 Interface Identifier is obtained by complementing the Universal/Local bit of the OUI field of the derived EUI-64 address.
たNx_PortのIPv6インターフェースID [AARCH]は、者たNx_PortのN_Port_Nameに由来EUI64アドレス[EUI64]に基づくものです。 IPv6インタフェース識別子を導出EUI-64アドレスのOUIフィールドのユニバーサル/ローカルビットを補完することによって得られます。
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in EUI-64 addresses. This allows the usage of these Name_Identifiers to support IPv6. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived from an EUI-64 address. It is possible to reverse this address mapping to obtain the original EUI-64 address in order to support IPv6.
[FC-FS]は、EUI-64アドレスにフォーマットは0x1（IEEE 48ビット・アドレス）、または0x2の（IEEE拡張）、または0x5（IEEE登録済み）のFC Name_Identifiersをマップする方法を指定します。これは、これらのName_Identifiersの使用量がIPv6をサポートすることができます。 [FC-FS]また、EUI-64は、FC Name_Identifiersにマッピング定義（フォーマットから0xC、0xDの、から0xE、及び0xFの）EUI-64アドレスから導出されます。 IPv6をサポートするために、元のEUI-64アドレスを取得するために、このアドレスマッピングを反転することが可能です。
Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits.
【ACONF]で指定されるようにステートレスアドレス自動設定が行われなければなりません。たNx_Portのステートレスアドレス自動設定に使用されるIPv6アドレスプレフィックスは、64ビットの長さでなければなりません。
The Name_Identifier format 0x1 is depicted in figure 7.
Name_Identifierフォーマット0x1のは、図7に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
図7：フォーマットは0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 8 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図8 [FC-FS]に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier
図8：フォーマットは0x1からEUI-64アドレスName_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 9.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。だから、IPv6インタフェースIDでOUIは正確FC Name_Identifierのようです。得られたIPv6インタフェース識別子はローカルスコープ[AARCH】図9に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
図9：IPv6インタフェースIDフォーマットは0x1からName_Identifier
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
461A：BCDE：F000例として、FC Name_Identifier 0x10-00-34-63-46-AB-CD-EFは、IPv6インタフェース識別子3463を生成します。
The Name_Identifier format 0x2 is depicted in figure 10.
Name_Identifierフォーマットを0x2は、図10に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
図10：フォーマットの0x2のName_Identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 11 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図11 [FC-FS]に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier
図11：フォーマットを0x2からEUI-64アドレスName_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 12.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。だから、IPv6インタフェースIDでOUIは正確FC Name_Identifierのようです。得られたIPv6インタフェース識別子はローカルスコープ[AARCH]図12に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
図12：IPv6インタフェースID形式を0x2からName_Identifier
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
462A：BCDE：F789例として、FC Name_Identifier 0x27-89-34-63-46-AB-CD-EFは、IPv6インタフェース識別子3463を生成します。
The Name_Identifier format 0x5 is depicted in figure 13.
Name_Identifierフォーマット0x5は、図13に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
図13：フォーマットの0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 14 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図14 [FC-FS]に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier
図14：フォーマットの0x5からEUI-64アドレスName_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 15.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完このEUI-64アドレスから得られます。だから、IPv6インタフェースIDでOUIは正確FC Name_Identifierのようです。得られたIPv6インタフェース識別子はローカルスコープ[AARCH]図15に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
図15：IPv6インタフェースIDフォーマット0x5からName_Identifier
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
465A：BCDE：F789例として、FC Name_Identifier 0x53-46-34-6A-BCDE-F7-89は、IPv6インタフェース識別子3463を生成します。
The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) are derived from an EUI-64 address by compressing the OUI field of such addresses. The compression is performed by removing from the OUI the Universal/Local and Individual/Group bits, and by putting bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 to 23 of the OUI in the second and third octet of the Name_Identifier, as shown in figure 16.
EUI-64は、アドレスのOUIフィールドを圧縮することによりEUI-64アドレスから導出さName_Identifiers形式（フォーマット0xFのスルーから0xC）にマッピングされました。圧縮は、第二及び第三にOUIの23 8ユニバーサル/ローカルおよび個人/グループビットOUIから除去することにより、及びName_Identifierの最初のオクテットでOUIの5ビット0を置くことによって行われ、そしてビットであります図16に示すようにName_Identifierのオクテット。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
図16：EUI-64マップされたName_Identifiersフォーマット
The EUI-64 address used to generate the Name_Identifier shown in figure 16 has the format depicted in figure 17.
図16に示さName_Identifierを生成するために使用されるEUI-64アドレスは、図17に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier
図17：EUI-64マップされName_IdentifierからEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. The resulting IPv6 Interface Identifier has global scope [AARCH] and the format depicted in figure 18.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。得られたIPv6インタフェース識別子は、グローバルスコープ[AARCH]図18に示されるフォーマットを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
図18：EUI-64マップされName_IdentifierからIPv6インタフェースID
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
0125：46AB：789A例として、FC Name_Identifier 0xCD-63から46-AB-01-25-78-9Aは、IPv6インタフェース識別子3663を生成します。
The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier, as defined in section 6, to the prefix FE80::/64. The resulting address is depicted in figure 19.
プレフィックスFE80 :: / 64に、セクション6で定義されたNx_PortのIPv6リンクローカルアドレス[AARCH]は、インターフェース識別子を付加することによって形成されます。得られたアドレスは、図19に示されています。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
図19：IPv6リンクローカルアドレスのフォーマット
An Nx_Port has two kinds of Fibre Channel addresses:
たNx_Portは、ファイバー・チャネル・アドレスの2種類があります。
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
- のN_Port_Nameと呼ばれる不揮発性の64ビットのアドレス; - のN_Port_IDと呼ばれる揮発性の24ビットアドレス、。
The N_Port_Name is used to uniquely identify the Nx_Port, while the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events occur (see Appendix B).
N_Port_IDがたNx_Portにルーティングフレームに使用されている間のN_Port_Nameは、一意たNx_Portを識別するために使用されます。両方のFCアドレスは、IPv6ユニキャストアドレスを解決するために必要とされています。 N_Port_IDが揮発性であるという事実がたNx_PortはそののN_Port_NameとのN_Port_ID特定のファイバ・チャネル・イベントが発生するとの間のマッピングを検証しなければならないことを意味します（付録Bを参照してください）。
The procedure for mapping IPv6 unicast addresses into Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The Source/Target Link-layer Address option has the format depicted in figure 20 when the link layer is Fibre Channel.
ファイバチャネルリンク層アドレスにマッピングするIPv6ユニキャストアドレスのための手順は、近隣探索プロトコル[DISC]を使用しています。ソース/ターゲットリンク層アドレスオプションは、リンク層は、ファイバチャネルであるとき、図20に示したフォーマットを持ちます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Fig. 20: Source/Target Link-layer Address option for Fibre Channel
図20：ファイバチャネルのソース/ターゲットリンク層アドレスオプション
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
タイプ：1ソースリンク層アドレスのために。ターゲットリンク層アドレスのため2。
Length: 2 (in units of 8 octets).
長さ：2（8つのオクテットの単位で）。
N_Port_Name: This field contains the Nx_Port's N_Port_Name. N_Port_ID: This field contains the Nx_Port's N_Port_ID.
N_Port_Name：このフィールドは、たNx_PortののN_Port_Nameが含まれています。 N_Port_ID：このフィールドは、たNx_PortののN_Port_IDが含まれています。
Reserved fields MUST be zero when transmitting, and MUST be ignored when receiving.
送信し、受信時に無視されなければならないとき、予約済みのフィールドはゼロでなければなりません。
By default, all best-effort IPv6 multicast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In particular, datagrams addressed to all-nodes multicast address, all-routers multicast address, and solicited-node multicast addresses [AARCH] MUST be sent as Class 3 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination N_Port_Name field of the FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies.
デフォルトでは、すべてのベストエフォート型のIPv6マルチキャストパケットは、FCシーケンスにマップする必要があり、放送のN_Port_IDは0xFF-FF-FF宛。特に、データグラムは、全ノードマルチキャストアドレスへの全ルーターマルチキャストアドレスをアドレス指定し、要請ノードマルチキャストアドレスは、[AARCH]クラス3のFCシーケンスは、ブロードキャストのN_Port_ID 0xFFで-FF-FF宛てとして送らなければなりません。この場合には、FC Network_Headerの先のN_Port_Nameフィールドは0x10-00-FF-FF-FF-FF-FF-FFの値に設定しなければなりません。付録Aは、様々なファイバーチャネルトポロジを超えるクラス3の放送FCシーケンスを送信する方法を指定します。
An Nx_Port supporting IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context in order to handle IPv6 multicast packets. The receive data field size of this implicit Port Login MUST be the same across all the Nx_Ports connected to the same Fabric, otherwise FC broadcast transmission does not work. In order to reduce the need for FC Sequence segmentation, the receive data field size of this implicit Port Login SHOULD be 1024 octets. This receive data field size requirement applies to broadcast Device_Data FC frames, not to ELSs.
たNx_Port支持IPv6は、IPv6マルチキャストパケットを処理するために暗黙ポートログインコンテキストに受信された放送クラス3 Device_Data FCフレームをマッピングすることができなければなりません。この暗黙のポートログインの受信データフィールドサイズは、そうでない場合はFCの同報送信が動作しません、同じファブリックに接続されているすべてのNx_Portsで同じでなければなりません。 FCシーケンスセグメンテーションの必要性を低減させるために、この暗黙のポートログインの受信データフィールドサイズは、1024オクテットであるべきです。これは、フィールドのサイズ要件はないELSSに、Device_Data FCフレームをブロードキャストするために適用されたデータを受け取ります。
Receiving an FC Sequence carrying an IPv6 multicast packet MAY trigger some additional processing by the Nx_Port if that IPv6 packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the IPv6 multicast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast IPv6 reply. In the case of Neighbor Discovery messages [DISC], the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Source/Target Link-layer Address option.
そのIPv6パケットがユニキャスト応答を必要とする場合、IPv6マルチキャストパケットを運ぶFCシーケンスを受信したNx_Portによっていくつかの追加処理をトリガすることができます。この場合、存在しないIPv6マルチキャストパケットを送信したNx_Portに有効なポートログインすれば、たNx_Portは、このようなポートのログインを実行しなければなりませんし、その後ユニキャストIPv6応答のためにそれを使用します。近隣探索メッセージ[DISC]の場合は、ポートログインが向けられるのN_Port_IDは、ソース/ターゲットリンク層アドレスオプションのN_Port_IDをフィールドから取得されます。
As an example, an Nx_Port processes a received broadcast FC Sequence carrying an IPv6 multicast unsolicited router advertisement [DISC] simply by passing the carried IPv6 packet to the IPv6 layer. Instead, if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a unicast reply, and
一例として、たNx_Portは単にのIPv6層に運ばIPv6パケットを通過させることによって、IPv6マルチキャスト迷惑ルータ通知[DISC]を担持し、受信した放送Fc配列を処理します。その代わりに、受信した放送Fc配列は、ユニキャスト応答を必要とするIPv6マルチキャスト要請メッセージ[DISC]を運び、そして場合
no valid Port Login exists with the Nx_Port sender of the multicast packet, then a Port Login MUST be performed in order to send the unicast reply message. If a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a multicast reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
有効なポートログインはその後、ポートログインがユニキャスト応答メッセージを送信するために実行しなければなりません、マルチキャストパケットの送信者たNx_Portに存在しません。受信した放送Fc配列はマルチキャスト応答を必要とするIPv6マルチキャスト要請メッセージ[DISC]を担持した場合、応答はブロードキャストのN_Port_IDは0xFF-FF-FFに送信されます。
Best-effort IPv6 multicast for other multicast group addresses MAY use Fibre Channel Multicast Groups [FC-FS], if supported by the particular FC topology and implementation.
特定のFCトポロジと実装によってサポートされている場合、他のマルチキャストグループアドレスのためのベストエフォート型のIPv6マルチキャストは、[FC-FS]ファイバチャネルのマルチキャストグループを使用するかもしれません。
FC Sequences are REQUIRED to be non-streamed. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that MUST increment the previous SEQ_CNT by one. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
FCシーケンスは、非ストリーミングすることが要求されます。 SEQUENCE_ID再利用によって欠落FCフレームのエイリアシングを回避するために、支持たNx_Port IPv6が増加SEQ_CNT [FC-FS]連続的に使用する必要があります。各取引所は、第1のフレームにおけるSEQ_CNT = 0で始まる必要があり、その後送信されるすべてのフレームを一つ前SEQ_CNTを増加しなければなりません。 Exchangeで他のNポートから受信したフレームが送信さSEQ_CNTに影響を及ぼさないものとします。
To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange for sending data to each Nx_Port in the network and a dedicated Exchange for receiving data from each Nx_Port.
IPv6パケットを転送するには、各たNx_Portは、ネットワーク内の各たNx_Portにデータを送信するための専用のExchangeおよび各たNx_Portからのデータを受信するための専用の交換を持たなければなりません。
An Exchange Responder is not required to assign RX_IDs. If an RX_ID of 0xFFFF is assigned, the Exchange Responder is identifying Exchanges based on S_ID / D_ID / OX_ID only.
取引ResponderはRX_IDsを割り当てるために必要とされていません。 0xFFFFでのRX_IDが割り当てられている場合、Exchange Responderは唯一S_ID / D_ID / OX_IDに基づいて交流を識別しています。
When an Exchange is created between two Nx_Ports for unicast IPv6 packets, it remains active while the Nx_Ports are logged in with each other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short lived Exchange.
ExchangeがユニキャストIPv6パケットのための2つのNx_Ports間に作成されたときNx_Portsが互いにログインしているが、それはアクティブのままです。各FC放送とELS [FC-FS]は別々の短命交換を使用すべきです。
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because they are used in a unidirectional mode. The Sequence Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
彼らは単方向モードで使用されているので、IPv6の場合、取引所は、シーケンス・イニシアチブを転送してはなりません。 FCヘッダ[FC-FS]のF_CTLフィールドのシーケンス・イニシアティブビットが0に設定しなければなりません。
The mechanism for aging or expiring exchanges based on activity, timeout, or other methods is outside the scope of this document.
老化または活性、タイムアウト、または他の方法に基づいて交換を期限切れにするための機構は、この文書の範囲外です。
The Exchange Originator MAY terminate Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator or Exchange Responder by using the ABTS (Abort Sequence) protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since this may terminate active Exchanges on other FC-4s [FC-FS].
交換オリジネーターは、[FC-FS] F_CTL LSビットを設定することにより、交換を終了することができます。交換はABTS（アボートシーケンス）プロトコル[FC-FS]を使用してExchange発信またはExchangeレスポンダによって取り壊されるかもしれません。これは他のFC-4S [FC-FS]にアクティブ交換を終了することができるので、IPv6の交換は、ログアウトによって終わるべきではありません。
IPv6 does not introduce any additional security concerns beyond those that already exist within the Fibre Channel protocols. Zoning techniques based on FC Name Server masking (soft zoning) do not work with IPv6, because IPv6 over Fibre Channel does not use the FC Name Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment.
IPv6は、すでにファイバ・チャネル・プロトコル内に存在しているものを超えて追加のセキュリティ上の懸念を導入しません。ファイバチャネルを介したIPv6がFCネームサーバを使用しないため（ソフトゾーニング）をマスキングFCネームサーバに基づくゾーニング手法は、IPv6で動作しません。 FC ESP_Header [FC-FS]はフレームのIPv6パケットを運ぶFCシーケンスを構成するFCを確保するために使用することができます。 IPv6のレイヤでのIPv6トラフィックを保護するために定義されたすべての技術は、ファイバチャネル環境で使用することができます。
The author would like to acknowledge the authors of [IPFC], [ETHER], and [IPv6-1394], since some part of this document has been derived from them, as well as the ANSI INCITS T11.3 Task Group members who reviewed this document.
このドキュメントの一部は、それらに由来しているので、著者は、審査だけでなく、ANSI INCITS T11.3タスクグループのメンバーを[IPFC]、[ETHER]の著者に感謝し、[IPv6-1394]でしょうこのドキュメント。
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)".
[FC-FS] ANSI INCITS 373-2003、 "ファイバチャネル - フレーミングおよびシグナリング（FC-FS）"。
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 (FC-AL-2)".
[FC-AL-2] ANSI INCITS 332から1999、 "ファイバチャネル - アービトレート型ループ2（FC-AL-2）"。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[AARCH] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture".
[IEEE-LLC] IEEE標準802-2001、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[IPFC] Rajagopal、M.、Bhagwat、R.、およびW.リカード、 "ファイバチャネルを介したIPとARP"、RFC 2625、1999年6月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html
[EUI64] "64ビットのグローバル識別子（EUI64）のためのガイドライン"、http://standards.ieee.org/db/oui/tutorials/EUI64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHER]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
[IPv6-1394]藤沢、K.とA.尾上、RFC 3146、2001年10月 "1394ネットワークの上のIPv6パケットのトランスミッション"。
A. Transmission of a Broadcast FC Sequence over FC Topologies
FCトポロジ上ブロードキャストFc配列のA.伝送
A.1. Point-to-Point Topology
A.1。ポイントツーポイントトポロジ
No particular mechanisms are required for this case. The Nx_Port connected at the other side of the cable receives the broadcast FC Sequence having D_ID 0xFFFFFF.
何ら特定のメカニズムはこの場合のために必要とされません。ケーブルのもう一方の側に接続されたNx_PortはD_ID 0xFFFFFFのを有する放送FCシーケンスを受信します。
A.2. Private Loop Topology
A.2。プライベートループトポロジ
An NL_Port attached to a private loop MUST transmit a Class 3 broadcast FC Sequence by using the OPN(fr) primitive signal [FC-AL-2].
プライベートループに取り付けられたNLポートは、OPN（FR）プリミティブ信号[FC-AL-2]を用いて、クラス3放送FCシーケンスを送信しなければなりません。
a) The source NL_Port first sends an Open Broadcast Replicate (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop (except itself) to replicate the frames that they receive while examining the FC Header's D_ID field. b) The source NL_Port then removes the OPN(fr) signal when it returns to it. c) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
A）NLポートは最初のオープンブロードキャスト複製（OPN（FR）を送信元）プリミティブ信号を、FCヘッダのD_IDフィールドを検査しながら、彼らが受け取ることフレームを複製するために、それ自体を除くループ（）内のすべてのNL_Portsを強制。それに戻ったときB）ソースNLポートは、次に、OPN（FR）信号を除去します。 C）ソースNLポートは、次いで、D_ID 0xFFFFFFのを有するクラス3放送FCシーケンスを送信します。
A.3. Public Loop Topology
A.3。パブリックループトポロジ
An NL_Port attached to a public loop MUST NOT use the OPN(fr) primitive signal. Rather, it MUST send the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 [FC-AL-2].
公衆ループに取り付けられたNLポートは、OPN（FR）プリミティブ信号を使用してはいけません。むしろ、AL_PA = 0x00の[FCは-AL-2]でFLポートにD_ID 0xFFFFFFのを有するクラス3放送FCシーケンスを送信しなければなりません。
The Fabric propagates the broadcast to all other FC_Ports [FC-FS], including the FL_Port which the broadcast arrives on. This includes all F_Ports, and other FL_Ports.
ファブリックは、放送に到着FLポートを含むすべての他のFC_Ports [FC-FS]に放送を伝播します。これは、すべてのF_Ports、およびその他のFL_Portを含んでいます。
Each FL_Port propagates the broadcast by using the primitive signal OPN(fr), in order to prepare the loop to receive the broadcast sequence.
各FLポートは、ブロードキャスト・シーケンスを受信するためにループを調製するために、プリミティブ信号OPN（FR）を使用してブロードキャストを伝播します。
A.4. Fabric Topology
A.4。ファブリックトポロジ
An N_Port connected to an F_Port MUST transmit the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates the broadcast to all other FC_Ports [FC-FS].
Fポートに接続されたNポートは、FポートにD_ID 0xFFFFFFのを有するクラス3放送FCシーケンスを送信しなければなりません。ファブリックは、他のすべてのFC_Ports [FC-FS]にブロードキャストを伝搬します。
B. Validation of the <N_Port_Name, N_Port_ID> mapping
<のN_Port_Name、N_ポート_ID>マッピングの検証B.
B.1. Overview
B.1。概要
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid before use.
すべての回で、<のN_Port_Name、N_Port_IDを>マッピングは、使用前に有効でなければなりません。
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may change, as well as the N_Port_IDs of all other Nx_Ports that have previously performed Port Login with this Nx_Port. Because of this, address validation is required after a LIP in a loop topology [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS].
FCリンクの中断が発生した後、たNx_PortのN_Port_IDを変更するには、だけでなく、以前にこのたNx_Portでポートログインを行っている他のすべてのNx_PortsののN_Port_IDがあります。このため、アドレス検証は、ポイントツーポイントトポロジ[FC-FS]のループトポロジー[FC-AL-2]またはNOS / OLS後LIP後に必要とされます。
N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus address validation is not required in this case.
N_Port_IDが、この場合に必要とされていないリンクリセット（LR）[FC-FS]、従ってアドレス検証の結果として変化しません。
B.2. FC Layer Address Validation in a Point-to-Point Topology
B.2。ポイントツーポイントトポロジでのFC層アドレス検証
No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS each N_Port must again perform a Port Login [FC-FS].
いいえ検証はLRの後に必要とされません。ポイントツーポイントトポロジでは、NOS / OLSは、各N_ポートの暗黙のログアウトを引き起こし、NOS / OLS後に各N_ポートは再びポートログイン[FC-FS]を実行しなければなりません。
B.3. FC Layer Address Validation in a Private Loop Topology
B.3。プライベートループトポロジでのFC層アドレス検証
After a LIP [FC-AL-2], an NL_Port must not transmit any data to another NL_Port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC [FC-FS].
他のポートのアドレスが検証されるまでLIP [FC-AL-2]の後、NLポートは、別のNLポートにデータを送信してはなりません。検証は、[FC-FS] ADISCまたはPDISCのいずれかを完了から構成されています。
For a requester, this specification prohibits PDISC and requires ADISC. As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
依頼者のために、この仕様はPDISCを禁止しADISCが必要です。応答として、実装は、他のFC仕様との互換性のためにADISCとPDISCの両方に応答する必要があるかもしれません。
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a logged remote NL_Port exactly match the values prior to the LIP, then any active Exchange with that NL_Port may continue.
ログイン遠隔NLポートの三のFCアドレス（N_ポート_ID、のN_Port_Name、node_nameは）正確前LIPに値が一致する場合、そのNLポートを有する任意のアクティブExchangeが継続することができます。
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
3つのFCアドレスのいずれかが変更された場合、リモートNLポートは、ログアウトする必要があります。
If an NL_Port's N_Port_ID changes after a LIP, then all active logged in NL_Ports must be logged out.
NLポートののN_Port_IDがLIP後に変更された場合、その後、NL_Portsに記録されたすべてのアクティブは、ログアウトする必要があります。
B.4. FC Layer Address Validation in a Public Loop Topology
B.4。パブリックループトポロジでのFC層アドレス検証
A FAN ELS may be sent by the Fabric to all known previously logged in NL_Ports following an initialization event. Therefore, after a LIP [FC-AL-2], NL_Ports may wait for this notification to arrive, or they may perform an FLOGI.
FAN ELSは、すべての既知の以前に初期化イベントを以下NL_Portsログインにファブリックによって送信されてもよいです。したがって、LIP [FC-AL-2]の後に、この通知が到着するNL_Portsは待つことができる、またはそれらはFLOGIを実行してもよいです。
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI response exactly match the values before the LIP and if the AL_PA [FC-AL-2] obtained by the NL_Port is the same as the one before the LIP, then the port may resume all Exchanges. If not, then FLOGI must be performed with the Fabric and all logged in Nx_Ports must be logged out.
F_Port_NameとFabric_NameファンELSまたはFLOGI応答に含まれる正確LIP前の値と一致するとNLポートによって得られるAL_PA [FC-AL-2] LIP前と同じである場合、ポートは再開することができる場合すべて交換。そうでない場合には、FLOGIはファブリックで実行されなければならないとNx_Portsに記録されたすべてがログアウトする必要があります。
A public loop NL_Port must perform the private loop validation as specified in section B.3 to any NL_Port on the local loop that has an N_Port_ID of the form 0x00-00-XX.
フォーム0x00-00-XXのN_ポート_IDを有するローカルループ上のNLポートにセクションB.3で指定されている公衆ループNLポートプライベートループ検証を実行しなければなりません。
B.5. FC Layer Address Validation in a Fabric Topology
B.5。ファブリックトポロジでのFC層アドレス検証
No validation is required after LR (link reset).
いいえ検証はLR（リンクリセット）の後に必要とされません。
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same as before the NOS/OLS, then the N_Port may resume all Exchanges. If not, all logged in Nx_Ports must be logged out [FC-FS].
NOS / OLS後、NポートがFLOGIを実行する必要があります。 FLOGIの後、NポートのN_Port_IDを、F_Port_Name、およびFabric_NameはNOS / OLS前と同じであり、場合には、Nポートは、すべての交流を再開してもよいです。ない場合は、Nx_Portsに記録されたすべてのは、[FC-FS]ログアウトする必要があります。
C. Fibre Channel Bit and Byte Numbering Guidance
C.ファイバチャネルビットおよびバイト番号順ガイダンス
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different.
ファイバチャネルおよびIETF標準の両方が同じバイト送信順序を使用します。しかし、ビット番号は異なっています。
Fibre Channel bit numbering can be observed if the data structure heading shown in figure 21 is cut and pasted at the top of the figures present in this document.
図21に示すデータ構造の見出しは、本文書中に存在する図の上部で切断し、貼り付けられている場合、ファイバチャネルビットの番号を観察することができます。
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
図21：ファイバチャネルビット番号
Author's Address
著者のアドレス
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
クラウディオDeSantiシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134 USA
Phone: +1 408 853-9172 EMail: cds@cisco.com
電話：+1 408 853-9172 Eメール：cds@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。