Network Working Group C. DeSanti
Request for Comments: 4338 Cisco Systems
Obsoletes: 3831, 2625 C. Carlson
Category: Standards Track QLogic Corporation
R. Nixon
Emulex
January 2006
Transmission of IPv6, IPv4, and
Address Resolution Protocol (ARP) 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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.
この文書は、IPv6、IPv4のをカプセル化する方法を指定し、ファイバチャネル上で解決プロトコル（ARP）パケットをアドレス。この文書はまた、IPv6リンクローカルアドレスを形成する方法を指定し、ステートレスファイバチャネルネットワーク上のIPv6アドレスを自動設定、およびメカニズムは、ファイバチャネルネットワーク上でIPv4アドレス解決を実行します。
This document obsoletes RFC 2625 and RFC 3831.
この文書は、RFC 2625およびRFC 3831を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. Summary of Fibre Channel ........................................4
2.1. Overview ...................................................4
2.2. Identifiers and Login ......................................5
2.3. FC Levels and Frame Format .................................5
2.4. Sequences and Exchanges ....................................6
3. IP-capable Nx_Ports .............................................7
4. IPv6, IPv4, and ARP Encapsulation ...............................7
4.1. FC Sequence Format for IPv6 and IPv4 Packets ...............7
4.2. FC Sequence Format for ARP Packets .........................9
4.3. FC Classes of Service .....................................10
4.4. FC Header Code Points .....................................10
4.5. FC Network_Header .........................................11
4.6. LLC/SNAP Header ...........................................12
4.7. Bit and Byte Ordering .....................................12
4.8. Maximum Transfer Unit .....................................12
5. IPv6 Stateless Address Autoconfiguration .......................13
5.1. IPv6 Interface Identifier and Address Prefix ..............13
5.2. Generating an Interface ID from a Format 1 N_Port_Name ....14
5.3. Generating an Interface ID from a Format 2 N_Port_Name ....15
5.4. Generating an Interface ID from a Format 5 N_Port_Name ....16
5.5. Generating an Interface ID from an EUI-64 Mapped
N_Port_Name ...............................................17
6. Link-local Addresses ...........................................18
7. ARP Packet Format ..............................................18
8. Link-layer Address/Hardware Address ............................20
9. Address Mapping for Unicast ....................................20
9.1. Overview ..................................................20
9.2. IPv6 Address Mapping ......................................20
9.3. IPv4 Address Mapping ......................................21
10. Address Mapping for Multicast .................................22
11. Sequence Management ...........................................23
12. Exchange Management ...........................................23
13. Interoperability with RFC 2625 ................................24
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
16. Acknowledgements ..............................................25
17. Normative References ..........................................26
18. Informative References ........................................26
A. Transmission of a Broadcast FC Sequence over FC Topologies
(Informative) ..................................................28
B. Validation of the <N_Port_Name, N_Port_ID> Mapping
(Informative) ..................................................29
C. Fibre Channel Bit and Byte Numbering Guidance ..................30
D. Changes from RFC 2625 ..........................................31
E. Changes from RFC 3831 ..........................................31
Fibre Channel (FC) is a high-speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI), IPv6 [IPv6], and IPv4 [IPv4].
ファイバチャネル（FC）は、小型コンピュータシステムインタフェース（SCSI）、IPv6の[IPv6の]、およびIPv4の[IPv4の]を含むいくつかの上位層プロトコルをサポートする高速シリアルインターフェース技術です。
[RFC-2625] defined how to encapsulate IPv4 and Address Resolution Protocol (ARP) packets over Fibre Channel for a subset of Fibre Channel devices. This specification enables the support of IPv4 for a broader category of Fibre Channel devices. In addition, this specification simplifies [RFC-2625] by removing unused options and clarifying current implementations. This document obsoletes [RFC-2625].
[RFC-2625]はIPv4のをカプセル化し、ファイバ・チャネル・デバイスのサブセットのために、ファイバチャネルを介して解決プロトコル（ARP）パケットに対処するためにどのように定義されました。この仕様は、ファイバ・チャネル・デバイスの広範なカテゴリのIPv4のサポートを可能にします。また、本明細書では使用されないオプションを除去し、現在の実装を明確にすることにより、[RFC-2625]を簡素化します。この文書では、[RFC-2625]を廃止します。
Specific [RFC-2625] limitations that this document aims to resolve are the following:
この文書は以下の通り解決することを目指していることを具体的な[RFC-2625]の制限：
- N_Port_Name format restriction. [RFC-2625] restricts the use of IPv4 to Fibre Channel devices having the format 0x1 N_Port_Name, but many current implementations use other N_Port_Name formats.
- のN_Port_Name形式制限。 [RFC-2625]は、フォーマットは0x1とのN_Port_Nameを有するファイバチャネルデバイスへのIPv4の使用を制限するが、多くの現在の実装では、他のN_Port_Nameフォーマットを使用します。
- Use of Fibre Channel Address Resolution Protocol (FARP). [RFC-2625] requires the support of FARP to map N_Port_Names to N_Port_IDs, but many current implementations use other methods, such as the Fibre Channel Name Server.
- ファイバチャネルの使用は解決プロトコル（FARP）のアドレス。 [RFC-2625]はのN_Port_IDにN_Port_NamesをマッピングするためにFARPのサポートが必要ですが、多くの現在の実装では、ファイバチャネルネームサーバのような他の方法を使用します。
- Missing support for IPv4 multicast. [RFC-2625] does not specify how to transmit IPv4 packets with a multicast destination address over Fibre Channel.
- IPv4のマルチキャストのサポートがありません。 [RFC-2625]は、ファイバチャネル経由のマルチキャスト宛先アドレスをIPv4パケットを送信する方法を指定しません。
[RFC-3831] defines how to encapsulate IPv6 over Fibre Channel and a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured IPv6 addresses on Fibre Channel networks. [RFC-3831] 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. This document obsoletes [RFC-3831].
[RFC-3831]は、ファイバチャネル上でIPv6をカプセル化する方法を定義し、IPv6リンクローカルアドレスを形成する方法[AARCH]とステートレスIPv6は、ファイバチャネルネットワーク上のアドレス自動設定しました。 [RFC-3831]はまた、メッセージは、ファイバチャネルネットワーク上で伝送されている近隣探索[DISC]で使用するソース/ターゲットリンク層アドレスオプションの内容を説明しています。この文書では、[RFC-3831]を廃止します。
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 that does not operate in a loop topology is called an N_Port. A Node Port that operates in a loop topology using the loop-specific protocols is designated as an NL_Port. The term Nx_Port is used to indicate a Node Port that is capable of operating in either mode.
ループトポロジで動作していないノード・ポートはNポートと呼ばれています。ループ固有のプロトコルを使用して、ループトポロジで動作するノードポートは、NLポートとして指定されます。長期たNx_Portはどちらのモードで動作することが可能であるノード・ポートを示すために使用されます。
A Fabric Port that does not operate in a loop topology is called an F_Port. A Fabric Port that operates in a loop topology using the loop-specific protocols is designated as an FL_Port. The term Fx_Port is used to indicate a Fabric Port that is capable of operating in either mode.
ループトポロジで動作しないファブリックポートがFポートと呼ばれています。ループ固有のプロトコルを使用して、ループトポロジで動作するファブリックポートはFLポートとして指定されます。用語Fx_Portは、いずれかのモードで動作することが可能であるファブリックポートを示すために使用されます。
A Fibre Channel network, built with any combination of the FC topologies described above, is a multiaccess network with broadcast capabilities.
前述したFCトポロジの任意の組み合わせで構築されたファイバチャネルネットワークは、ブロードキャスト機能を持つマルチアクセスネットワークです。
From an IPv6 point of view, a Fibre Channel network is an IPv6 Link [IPv6]. IP-capable Nx_Ports are what [IPv6] calls Interfaces.
ビューのIPv6の点からは、ファイバチャネルネットワークは、IPv6リンク[IPv6の]です。 IP対応のNx_Portsは、[IPv6が]インタフェースを呼んでいるものです。
From an IPv4 point of view, a Fibre Channel network is an IPv4 Local Network [IPv4]. IP-capable Nx_Ports are what [IPv4] calls Local Network Interfaces.
ビューのIPv4の点からは、ファイバチャネルネットワークはIPv4のローカルネットワーク[IPv4の]です。 IP対応のNx_Portsは、[IPv4の]はローカルネットワークインターフェイスを呼んでいるものです。
Fibre Channel entities are identified by non-volatile 64-bit Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the most significant 4 bits defines the format of a Name_Identifier. These Name_Identifiers are referred to in a more concise manner as follows:
ファイバチャネルエンティティは、不揮発性64ビットName_Identifiersによって識別されます。 [FC-FS]はName_Identifiersのいくつかの形式を定義します。上位4ビットの値はName_Identifierのフォーマットを定義します。次のようにこれらのName_Identifiersは、より簡潔な方法で言及されています。
- 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 non-volatile N_Port_Name and a volatile 24-bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, and the N_Port_ID is used for communications among Nx_Ports.
ファイバチャネルネットワークに接続されたNx_Portは、二つの識別子、その非揮発性のN_Port_NameとのN_Port_IDと呼ばれる揮発性の24ビットのアドレスに関連付けられています。 N_Port_NameはたNx_Portを識別するために使用され、及びN_ポート_IDはNx_Ports間の通信のために使用されます。
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 ELSes) or implicit (i.e., in which the parameters are specified by configuration or other methods).
ファブリックログインおよびポートログインの両方が（すなわち、ここでパラメータを設定または他の方法で指定される）、明示的な（すなわち、拡張リンク・サービス、またはよそと呼ばれる特定の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 the control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv6, IPv4, and SCSI. The Fibre Channel frame format is shown in figure 1.
[FC-FS]は、5つの異なるレベルを使用して、ファイバチャネルプロトコルが記載されています。 FC-2、FC-4のレベルは、本明細書に関連します。 FC-2レベルは、FCフレームフォーマット、トランスポート・サービス、及び情報転送に必要な制御機能を定義します。 FC-4レベルは、IPv6の、IPv4の、及びSCSI等の上位プロトコルをサポートします。ファイバチャネルフレームフォーマットは、図1に示されています。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Figure 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 Cyclic Redundancy Check (CRC) is 4 octets long and is used to verify the integrity of a frame.
フレームの開始（SOF）およびフレームの終わり（EOF）は、フレームの区切り文字として機能し、特殊なFC伝送言葉です。巡回冗長検査（CRC）は4つのオクテットの長さであり、フレームの整合性を検証するために使用されます。
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 the following:
データフィールドは、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.
Classes 3 and 2 are commonly used for storage networking applications; Classes 1 and 6 are typically used for specialized applications in avionics. Class 3 is recommended for IPv6, IPv4, and ARP (see section 4.3).
クラス3と2は、一般的にストレージ・ネットワーキング・アプリケーションに使用されています。クラス1および6は、一般的に、アビオニクスで特殊な用途のために使用されています。クラス3は、IPv6、IPv4の、およびARPのために推奨されます（4.3節を参照してください）。
An application-level payload such as an IPv6 or IPv4 packet is called an Information Unit at the FC-4 level of Fibre Channel. Each FC-4
そのようなIPv6のまたはIPv4パケットとしてアプリケーションレベルのペイロードは、ファイバチャネルのFC-4レベルの情報単位と呼ばれます。各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.
情報単位は、FC-2レベルによりFc配列にマッピングされます。 Fc配列は、FCヘッダのSEQUENCE_ID（SEQ_ID）フィールドの値によって関連する1つ以上のFCフレームで構成されています。
The architectural 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 grouped 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 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 between a pair of Nx_Ports.
複数の配列は同じFC取引所に属するとしてグループ化することができます。 Exchangeは、それらの間の操作を識別し、管理するために2つのNx_Portsによって使用されるメカニズムです。取引所は、操作が2 Nx_Portsの間で開始されたときに開かれ、動作が終了すると閉じられています。同じExchangeに所属するFCフレームは、FCヘッダのExchange_IDフィールドの値によって関連しています。発信Exchange_ID（OX_ID）とレスポンダExchange_ID（RX_ID）が一意Nx_Portsの対の間の交換を識別する。
This specification requires an IP-capable Nx_Port to have the following properties:
この仕様は、次の特性を有するようにIP対応のたNx_Portが必要です。
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF (see section 5.1);
- 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 (see section 4.1);
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets (see section 10).
An IPv6 or IPv4 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 [FC-FS]. An FC Information Unit containing an IP packet MUST carry the FC Network_Header [FC-FS] and the Logical Link Control/SubNetwork Access Protocol (LLC/SNAP) header [IEEE-LLC], resulting in the FC Information Unit format shown in figure 2.
IPv6またはIPv4パケットが順番にFC-2レベル[FC-FS]によってFc配列にマッピングされ、ファイバチャネルのFC-4レベルの情報単位にマッピングされます。 FC Network_Header [FC-FS]及びFC情報ユニットの形式で得られる論理リンク制御/サブネットワークアクセスプロトコル（LLC / SNAP）ヘッダ[IEEE-LLC]を、搬送しなければならないIPパケットを含むFC情報ユニットは、図2に示され。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 or IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Figure 2: FC Information Unit Mapping an IP Packet
図2：FC情報ユニットのマッピングIPパケット
In order to support the minimum IPv6 MTU (i.e., 1280 octets), an Nx_Port supporting IP MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long (i.e., 1280 + 8 + 16).
最小のIPv6 MTU（すなわち1280オクテット）をサポートするために、支持たNx_Port IPは、少なくとも1304オクテット長FC-4情報単位を送信および受信することができなければなりません（即ち、1280 + 8 + 16）。
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing an IP FC Sequence. Other FC Optional Headers MUST NOT be used in an IP FC Sequence.
FC ESP_Header [FC-FS]は、IP FCシーケンスを構成するフレームFCを固定するために使用され得ます。その他のFCオプションヘッダは、IP FCシーケンスに使用してはいけません。
An IP FC Sequence often consists of more than one frame, all frames having the same TYPE (see section 4.4). 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 shown in figure 3.
IP Fc配列は、しばしば、複数のフレームで構成され、同一の型を有する全てのフレームは（セクション4.4を参照します）。シーケンスの最初のフレームは、FC Network_HeaderおよびLLC / SNAPヘッダを含まなければなりません。図3に示すように、他のフレームには、それらを含んではいけません。
First Frame of an IP FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IP Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IP FC Sequence
+-----------+-----------------//--------------------+
| FC Header | Additional chunk of the IP Packet |
+-----------+----------------//---------------------+
Figure 3: Optional Headers in an IP FC Sequence
図3：IP FCシーケンスのオプションのヘッダ
An ARP 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 ARP packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format shown in figure 4.
ARPパケットは順番にFC-2レベルによりFc配列にマッピングされ、ファイバチャネルのFC-4レベルの情報単位にマッピングされます。 ARPパケットを含むFC情報ユニットは、図4に示すFC情報ユニットの形式で、その結果、FC Network_Header [FC-FS]、およびLLC / SNAPヘッダ[IEEE-LLC]を運ばなければなりません。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Figure 4: FC Information Unit Mapping an ARP Packet
図4：FC情報ユニットのマッピングARPパケット
Given the limited size of an ARP packet (see section 7), an FC Sequence carrying an ARP packet MUST be mapped to a single FC frame that MUST include the FC Network_Header and the LLC/SNAP header.
ARPパケットの制限されたサイズ（セクション7参照）を考慮すると、ARPパケットを運ぶFc配列は、FC Network_HeaderおよびLLC / SNAPヘッダを含まなければならない単一のFCフレームにマッピングされなければなりません。
The FC ESP_Header [FC-FS] MAY be used to secure an FC frame carrying an ARP packet. Other FC Optional Headers MUST NOT be used in an FC frame carrying an ARP packet.
FC ESP_Header [FC-FS]はARPパケットを搬送するFCフレームを固定するために使用され得ます。その他のFCオプションヘッダは、ARPパケットを運ぶFCフレームに使用してはいけません。
This specification uses FC Class 3. The following types of packets MUST be mapped in Class 3 FC frames:
この仕様は、パケットの次のタイプは、クラス3のFCフレームにマッピングする必要がありFCクラス3を使用します。
- multicast IPv6 packets;
- multicast/broadcast IPv4 packets;
- Control Protocol packets (e.g., ARP packets; IPv6 packets carrying
ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener
Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or
IGMP [IGMPv3] messages; IPv6 and IPv4 Routing Protocols packets).
Other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data traffic) SHOULD be mapped in Class 3 FC frames as well. Support for reception of IPv4 or IPv6 packets mapped in FC frames of any Class other than Class 3 is OPTIONAL; receivers MAY ignore them.
他のIPv6とIPv4パケット（データ・トラフィックを搬送する、すなわち、ユニキャストIPパケット）がFCは同様フレームクラス3にマッピングされてください。クラス3は任意であり以外の任意のクラスのFCフレームにマッピングされたIPv4またはIPv6パケットの受信のためのサポート。受信機は、それらを無視するかもしれません。
The fields of the Fibre Channel Header are shown in figure 5. The D_ID and S_ID fields contain, respectively, the destination N_Port_ID and the source N_Port_ID.
ファイバ・チャネル・ヘッダのフィールドは、D_IDとS_IDフィールドは、それぞれ、先のN_Port_IDとソースのN_Port_IDを含む図5に示されています。
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 |
+---------------+---------------+---------------+---------------+
Figure 5: FC Header Format
図5：FCヘッダー形式
To encapsulate IPv6 and IPv4 over Fibre Channel, the following code points apply. When a single value is listed without further qualification, that value MUST be used:
ファイバチャネル上でIPv6とIPv4をカプセル化するには、次のコード・ポイントが適用されます。単一の値をさらに資格なしに列挙されている場合、その値を使用する必要があります。
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or
IPv4 Sequence, 0x00 for the following FC frames. If the FC
ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or
IPv4 Sequence, 0x40 for the following FC frames;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: if Relative Offset [FC-FS] is not used, the content of
this field MUST be ignored by the receiver, and SHOULD be set to
zero by the sender. If Relative Offset is used, see [FC-FS].
To encapsulate ARP over Fibre Channel, the following code points apply. When a single value is listed without further qualification, that value MUST be used:
ファイバチャネル上でARPをカプセル化するには、次のコード・ポイントが適用されます。単一の値をさらに資格なしに列挙されている場合、その値を使用する必要があります。
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then
0x60;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: SHOULD be set to zero.
The fields of the FC Network_Header are shown in figure 6. For use with IPv6, IPv4, and ARP, the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [FC-FS].
FC Network_Headerのフィールドは、IPv6、IPv4の、およびARPとの使用については、図6に示され、N_Port_Namesフォーマットは0x1の、0x2の、0x5のいずれか、から0xC、0xDの、から0xE、0xFの[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Figure 6: FC Network_Header Format
図6：FC Network_Headerフォーマット
The fields of the LLC/SNAP header [IEEE-LLC] are shown in figure 7.
LLC / SNAPヘッダ[IEEE-LLC]のフィールドは、図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Figure 7: LLC/SNAP Header Format
図7：LLC / SNAPヘッダー形式
To encapsulate IPv6, IPv4, and ARP over Fibre Channel, the following code points MUST be used:
ファイバチャネル上でのIPv6、IPv4の、およびARPをカプセル化するには、次のコード・ポイントを使用しなければなりません。
- DSAP: 0xAA;
- SSAP: 0xAA;
- CTRL: 0x03;
- OUI: 0x000000;
- PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP.
IPv6, IPv4, and ARP 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、IPv4の、およびARPパケットは、標準のネットワークバイト順または標準形式に対応するビッグエンディアンバイト順を使用して、FC-4レベルにマッピングされます。
The default MTU size for IPv6 packets over Fibre Channel is 65280 octets. Large IPv6 packets are mapped to a Sequence of FC frames (see section 2.4). 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パケットのデフォルトのMTUサイズは65280オクテットです。大IPv6パケットは、FCフレームのシーケンスにマッピングされる（セクション2.4参照）。このサイズは、ルータ広告[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 [PMTUD6], or at least maintain different MTU values for on-link and off-link destinations.
デフォルトMTUサイズははるかメッセージは、典型的にはインターネットで使用されるサイズ超えると、IPv6のFC上の実装は、パスMTU探索[PMTUD6]を実装する、または少なくともリンク・オン及びオフリンク宛先の異なるMTU値を維持しなければなりません。
For correct operation of IPv6 in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
ルーティングされた環境でのIPv6の正しい操作のために、ルータ広告で適切なMTUオプションを設定することが非常に重要です。
For correct operation of IPv6 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 that is connected to a medium with a default MTU larger than the smallest MTU.
IPv6の混合媒体（例えば、イーサネット（登録商標）およびファイバーチャネル）の正しい動作のために一緒にブリッジされ、すべてのメディアの最小のMTUはMTUオプションでルータによって通知されなければなりません。存在しないルータが存在しない場合、このMTUを手動で最小のMTUよりも大きいデフォルトMTUを有する媒体に接続されている各ノードで構成されなければなりません。
The default MTU size for IPv4 packets over Fibre Channel is 65280 octets. Large IPv4 packets are mapped to a Sequence of FC frames (see section 2.4). This size may be reduced by manual configuration of each Nx_Port or by the Path MTU Discovery technique [PMTUD4].
ファイバチャネルを介したIPv4パケットのデフォルトのMTUサイズは65280オクテットです。大IPv4パケットは、FCフレームのシーケンスにマッピングされる（セクション2.4参照）。このサイズは、各たNx_Portの手動設定によって、またはパスMTU探索手法[PMTUD4]によって減少させることができます。
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 (U/L) bit of the OUI field of the derived EUI-64 address. The U/L bit has no function in Fibre Channel; however, it has to be properly handled when a Name_Identifier is converted to an EUI-64 address.
たNx_PortのIPv6インターフェースID [AARCH]は、者たNx_PortのN_Port_Nameに由来EUI64アドレス[EUI64]に基づくものです。 IPv6インタフェース識別子は、ユニバーサル/ローカル（U / L）由来のEUI-64アドレスのOUIフィールドのビットを補完することによって得られます。 U / Lビットは、ファイバチャネルでの機能を有していません。しかし、Name_IdentifierがEUI-64アドレスに変換されたときに適切に処理しなければなりません。
[FC-FS] specifies a method to map format 0x1 (IEEE 48-bit address), 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アドレスを取得するために、このアドレスマッピングを反転することが可能です。
IPv6 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]で指定されたIPv6ステートレスアドレス自動設定が行われなければなりません。たNx_Portのステートレスアドレス自動設定に使用されるIPv6アドレスプレフィックスは、64ビットの長さでなければなりません。
The Name_Identifier format 0x1 is shown in figure 8.
Name_Identifierフォーマット0x1のは、図8に示されています。
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 |
+---------------+---------------+---------------+---------------+
Figure 8: Format 0x1 Name_Identifier
図8：フォーマットは0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 9 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図9に示すフォーマット[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 |
+---------------+---------------+-------+-------+---------------+
Figure 9: EUI-64 Address from a Format 0x1 Name_Identifier
図9：フォーマットは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. Therefore, 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 shown in figure 10.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。したがって、IPv6インタフェースIDにOUIは、正確FC Name_Identifierと同様です。得られたIPv6インタフェース識別子はローカルスコープ[AARCH]図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Figure 10: IPv6 Interface ID from a Format 0x1 Name_Identifier
図10：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 shown in figure 11.
Name_Identifierフォーマットを0x2は、図11に示されています。
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 |
+---------------+---------------+---------------+---------------+
Figure 11: Format 0x2 Name_Identifier
図11：フォーマットの0x2のName_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 12 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図12に示すフォーマット[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 |
+---------------+-----------------------+-------+---------------+
Figure 12: EUI-64 Address from a Format 0x2 Name_Identifier
図12：フォーマットを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. Therefore, 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 shown in figure 13.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。したがって、IPv6インタフェースIDにOUIは、正確FC Name_Identifierと同様です。得られたIPv6インタフェース識別子はローカルスコープ[AARCH]図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Figure 13: IPv6 Interface ID from a Format 0x2 Name_Identifier
図13：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 shown in figure 14.
Name_Identifierフォーマット0x5は、図14に示されています。
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 |
+---------------+---------------+---------------+---------------+
Figure 14: Format 0x5 Name_Identifier
図14：フォーマットの0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format shown in figure 15 [FC-FS].
このName_Identifier由来するEUI-64アドレスは、図15に示すフォーマット[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 |
+---------------+---------------+---------------+---------------+
Figure 15: EUI-64 Address from a Format 0x5 Name_Identifier
図15：フォーマットの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. Therefore, 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 shown in figure 16.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完このEUI-64アドレスから得られます。したがって、IPv6インタフェースIDにOUIは、正確FC Name_Identifierと同様です。得られたIPv6インタフェース識別子はローカルスコープ[AARCH]図16に示すフォーマットを有しています。
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 |
+---------------+---------------+---------------+---------------+
Figure 16: IPv6 Interface ID from a Format 0x5 Name_Identifier
図16：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 the Universal/Local and Individual/Group bits from the OUI, 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 17.
EUI-64は、アドレスのOUIフィールドを圧縮することによりEUI-64アドレスから導出さName_Identifiers形式（フォーマット0xFのスルーから0xC）にマッピングされました。圧縮は、第二及び第三にOUIの23 8 OUIからユニバーサル/ローカルおよび個人/グループビットを除去することにより、及びName_Identifierの最初のオクテットでOUIの5ビット0を置くことによって行われ、そしてビットであります図17に示すように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 |
+---------------+---------------+---------------+---------------+
Figure 17: EUI-64 Mapped Name_Identifiers Format
図17：EUI-64マップされたName_Identifiersフォーマット
The EUI-64 address used to generate the Name_Identifier shown in figure 17 has the format shown in figure 18.
図17に示さName_Identifierを生成するために使用されるEUI-64アドレスは、図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] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier
図18：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 shown in figure 19.
IPv6インタフェース識別子は、OUIフィールドにU / Lビットを補完することにより、このEUI-64アドレスから得られます。得られたIPv6インタフェース識別子は、グローバルスコープ[AARCH]図19に示すフォーマットを有しています。
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 |
+---------------+---------------+---------------+---------------+
Figure 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
図19：IPv6インタフェースID EUI-64マップされName_Identifierから
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 5) to the prefix FE80::/64. The resulting address is shown in figure 20.
【AARCH】たNx_PortのIPv6リンクローカルアドレス（セクション5で定義されるように）プレフィクスFE80 :: / 64とインタフェース識別子を付加することにより形成されています。得られたアドレスは、図20に示されています。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 20: IPv6 Link-local Address Format
図20：IPv6のリンクローカルアドレスのフォーマット
The Address Resolution Protocol defined in [ARP] is designed to be a general purpose protocol, to accommodate many network technologies and many Upper Layer Protocols.
[ARP]で定義されたアドレス解決プロトコルは、多くのネットワーク技術と多くの上位層プロトコルに対応するために、汎用的なプロトコルとして設計されています。
[RFC-2625] chose to use for Fibre Channel the same ARP packet format used for Ethernet networks. In order to do that, [RFC-2625] restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1. Although this may have been a reasonable choice at that time, today there are Nx_Ports with an N_Port_Name format other than 0x1 in widespread use.
[RFC-2625]は、ファイバチャネル用のイーサネットネットワークのために使用したのと同じARPパケットフォーマットを使用することにしました。これを行うためには、[RFC-2625]はのN_Port_Nameフォーマットは0x1を有するNx_PortsへのIPv4の使用を制限しました。これはその時点で合理的な選択だったかもしれないが、今日広く使用されている0x1の以外のN_Port_Name形式のNx_Portsがあります。
This specification accommodates Nx_Ports with N_Port_Names of a format different from 0x1 by defining a Fibre Channel specific version of the ARP protocol (FC ARP), carrying both N_Port_Name and N_Port_ID as Hardware (HW) Address.
この仕様は、ハードウェア（HW）アドレスなどのN_Port_NameとのN_Port_IDの両方を担持する、ARPプロトコル（FC ARP）のファイバチャネル特定のバージョンを定義することによって、0x1の異なる形式のN_Port_NamesとNx_Portsを収容します。
IANA has registered the number 18 (decimal) to identify Fibre Channel as ARP HW type. The FC ARP packet format is shown in figure 21. The length of the FC ARP packet is 40 octets.
IANAは、ARP HWタイプとしてファイバチャネルを識別するための番号18（10進数）を登録しています。 FC ARPパケットフォーマットは、FC ARPパケットの長さは40オクテットである図21に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Type = 0x0012 | Protocol = 0x0800 |
+---------------+---------------+---------------+---------------+
| HW Len = 12 | Proto Len = 4 | Opcode |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Sender |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Sender |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Target |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Target |
+---------------+---------------+---------------+---------------+
Figure 21: FC ARP Packet Format
図21：FC ARPパケットフォーマット
The following code points MUST be used with FC ARP:
次のコード・ポイントは、FC ARPと共に使用する必要があります。
- HW Type: 0x0012 (Fibre Channel);
- Protocol: 0x0800 (IPv4);
- HW Len: 12 (Length in octets of the HW Address);
- Proto Len: 4 (Length in octets of the Protocol Address);
- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply [ARP];
- HW Address of Sender: the HW Address (see section 8) of the
Requester in an ARP Request, or the HW Address of the Responder in
an ARP Reply;
- Protocol Address of Sender: the IPv4 address of the Requester in
an ARP Request, or that of the Responder in an ARP Reply;
- HW Address of Target: set to zero in an ARP Request, and to the HW
Address (see section 8) of the Requester in an ARP Reply;
- Protocol Address of Target: the IPv4 address of the Responder in
an ARP Request, or that of the Requester in an ARP Reply.
The Link-layer Address used in the Source/Target Link-layer Address option (see section 9.2) and the Hardware Address used in FC ARP (see section 7) have the same format, shown in figure 22.
ソース/ターゲット・リンク層アドレス・オプションで使用されるリンク層アドレスは、同一のフォーマットが、図22に示されているとFC ARP（セクション7参照）に使用されるハードウェアアドレス（セクション9.2を参照します）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Figure 22: Link-layer Address/HW Address Format
図22：リンク層アドレス/ HWアドレスのフォーマット
Reserved fields MUST be set to zero when transmitting, and MUST be ignored when receiving.
予約フィールドは、送信するときにゼロに設定しなければなりません、そして受信した場合、無視されなければなりません。
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, and the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 or IPv4 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_Nameを一意たNx_Portを識別するために使用され、及びN_ポート_IDがたNx_Portにルーティングフレームに使用されます。両方のFCアドレスは、IPv6またはIPv4ユニキャストアドレスを解決するために必要とされています。 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 shown in figure 23 when the link layer is Fibre Channel.
ファイバチャネルリンク層アドレスにマッピングするIPv6ユニキャストアドレスのための手順は、近隣探索プロトコル[DISC]を使用しています。ソース/ターゲットリンク層アドレスオプションは、リンク層は、ファイバチャネルであるとき、図23に示すフォーマットを有します。
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 | |
+---------------+---------------+ -+
| |
+- Link-layer Address -+
| |
+- +---------------+---------------+
| | Padding |
+---------------+---------------+---------------+---------------+
Figure 23: Source/Target Link-layer Address Option for Fibre Channel
図23：ファイバチャネルのソース/ターゲットリンク層アドレスオプション
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
タイプ：1ソースリンク層アドレスのために。ターゲットリンク層アドレスのため2。
Length: 2 (in units of 8 octets).
長さ：2（8つのオクテットの単位で）。
Padding: MUST be set to zero when transmitting, MUST be ignored when receiving.
パディング：送信時にゼロに設定しなければならなくて、受信時に無視しなければなりません。
Link-layer Address: the Nx_Port's Link-layer Address (see section 8).
リンク層アドレス：たNx_Portのリンク層アドレス（セクション8を参照）。
The procedure for mapping IPv4 unicast addresses into Fibre Channel link-layer addresses uses the FC ARP protocol, as specified in section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets to a destination Nx_Port, known by its IPv4 address, MUST perform the following steps:
セクション7と[ARP]で指定されるように、ファイバチャネルリンク層アドレスにマッピングIPv4ユニキャストアドレスのための手順は、FC ARPプロトコルを使用します。先のIPv4アドレスによって知られたNx_PortにIPv4パケットを送信しなければならないソースたNx_Portは、以下のステップを実行する必要があります。
1) The source Nx_Port first consults its local mapping tables for a mapping <destination IPv4 address, N_Port_Name, N_Port_ID>.
1）ソースたNx_Portは、最初のマッピング<宛先IPv4アドレス、のN_Port_Name、N_ポート_ID>のためにそのローカルマッピングテーブルを参照します。
2) If such a mapping is found, and a valid Port Login is in place with the destination Nx_Port, then the source Nx_Port sends the IPv4 packets to the destination Nx_Port using the retrieved N_Port_ID as D_ID.
2）このようなマッピングが見つから、および有効なポートは、ログインしたNx_Portは、ソース・たNx_Portは、D_IDとしてN_ポート_ID検索を使用して宛先たNx_PortにIPv4パケットを送信先との代わりになっている場合。
3) If such a mapping is not found, or a valid Port Login is not in place with the destination Nx_Port, then the source Nx_Port sends a broadcast FC ARP Request (see section 10) to its connected FC network.
3）このようなマッピングが見つからない、または有効なポートログインが先たNx_Portのある場所ではありませんされている場合は、ソースたNx_Portはそれに接続されたFCネットワークに放送FC ARPリクエストを（セクション10を参照）を送信します。
4) When a broadcast FC ARP Request is received by the Nx_Port with the matching IPv4 address, that Nx_Port caches the information carried in the FC ARP Request in its local mapping tables and generates a unicast FC ARP Reply. If a valid Port Login to the Nx_Port that sent the broadcast FC ARP Request does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast reply. The N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
4）放送FC ARP要求がたNx_PortがローカルマッピングテーブルにおけるFC ARPリクエストで搬送される情報をキャッシュし、ユニキャストFC ARP応答を生成し、マッチングIPv4アドレスとともにたNx_Portによって受信されます。ブロードキャストを送信したNx_Portに有効なポートのログインがFC ARP要求が存在しない場合は、たNx_Portは、このようなポートのログインを行い、その後、ユニキャスト応答のためにそれを使用しなければなりません。ポートログインが向けられるのN_Port_IDを受信FC ARPパケット内の送信者HWアドレスフィールドのN_Port_IDをフィールドから取得されます。
5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP Reply is returned.
何たNx_Port一致するIPv4アドレスを持っていない場合は5）、何ユニキャストFC ARP応答が返されません。
IPv6 multicast packets, IPv4 multicast/broadcast packets, and ARP broadcast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional Exchange (see section 12). Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies. The Destination N_Port_Name field of the FC Network_Header MUST be set to the value:
FC配列は一方向性交換にFCクラス3で送信された放送のN_Port_ID 0xFFFFFFの、宛てにIPv6マルチキャストパケットのIPv4マルチキャスト/ブロードキャストパケット、およびARPブロードキャストパケットがマッピングされなければならない（セクション12を参照）。付録Aは、様々なファイバーチャネルトポロジを超えるクラス3の放送FCシーケンスを送信する方法を指定します。 FC Network_Headerの先のN_Port_Nameフィールドが値に設定する必要があります。
- for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF;
- for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, where
XX-YY-ZZ-QQ are the 4 least significant octets of the multicast
destination IPv6 address;
- for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, where the
23 least significant bits of XX-YY-ZZ are the 23 least significant
bits of the multicast destination IPv4 address and the most
significant bit of XX-YY-ZZ is set to zero.
An Nx_Port supporting IPv6 or IPv4 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, IPv4 multicast or broadcast packets, and ARP broadcast 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 ELSes.
IPv6またはIPv4をサポートたNx_Portは、IPv6マルチキャストパケットのIPv4マルチキャストまたはブロードキャストパケット、およびARPブロードキャストパケットを処理するために暗黙ポートログインコンテキストに受信された放送クラス3 Device_Data FCフレームをマッピングすることができなければなりません。この暗黙のポートログインの受信データフィールドサイズは、そうでない場合はFCの同報送信が動作しません、同じファブリックに接続されているすべてのNx_Portsで同じでなければなりません。 FCシーケンスセグメンテーションの必要性を低減させるために、この暗黙のポートログインの受信データフィールドサイズは、1024オクテットであるべきです。これは、フィールドのサイズ要件はないよそに、Device_Data FCフレームをブロードキャストするために適用されたデータを受け取ります。
Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4 multicast/broadcast packet, or an FC ARP broadcast packet triggers some additional processing by the Nx_Port when that IPv6, IPv4, or FC ARP packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the multicast or broadcast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast 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 Link-layer Address in the received Neighbor Discovery message. In the case of FC ARP messages, the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
それのIPv6、IPv4の、またはFC ARPパケットがユニキャスト応答を必要とする場合、IPv6マルチキャストパケットのIPv4マルチキャスト/ブロードキャストパケット、またはFC ARPブロードキャストパケットを運ぶFCシーケンスを受信したNx_Portによって、いくつかの追加処理をトリガします。マルチキャストまたはブロードキャストパケットを送信したNx_Portに有効なポートのログインが存在しない場合この場合、たNx_Portは、このようなポートのログインを実行しなければなりませんし、その後ユニキャスト応答のためにそれを使用します。近隣探索メッセージ[DISC]の場合には、ポートログインを対象とするのN_Port_IDを受信した近隣探索メッセージ内のソースリンク層アドレスのN_ポート_IDフィールドから取られます。 FC ARPメッセージの場合は、ポートログインが向けられるのN_Port_IDを受信FC ARPパケット内の送信者HWアドレスフィールドのN_Port_IDをフィールドから取得されます。
As an example, if a received broadcast FC Sequence carries an IPv6 multicast unsolicited Router Advertisement [DISC], the receiving Nx_Port processes it 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 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 0xFFFFFF.
受信した放送FCシーケンスはIPv6マルチキャスト迷惑ルータ広告[DISC]を担持した場合、一例として、受信したNx_Portは、IPv6層に運ばIPv6パケットを通過させることにより、単にそれを処理します。受信した放送Fc配列は、ユニキャスト応答を必要とするIPv6マルチキャスト要請メッセージ[DISC]を運び、そして有効なポートログインマルチキャストパケットのたNx_Port送信者と存在しない場合、代わりに、ポートログインは、ユニキャストを送信するために実行しなければなりませんメッセージを返信します。受信した放送Fc配列はマルチキャスト応答を必要とするIPv6マルチキャスト要請メッセージ[DISC]を担持した場合、応答はブロードキャストのN_Port_ID 0xFFFFFFのに送られます。
FC Sequences carrying IPv6, IPv4, or ARP packets are REQUIRED to be non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start by setting SEQ_CNT to zero in the first frame; every frame transmitted after that MUST increment the previous SEQ_CNT by one. The Continue Sequence Condition field in the F_CTL field of the FC Header MUST be set to zero [FC-FS].
IPv6、IPv4の、またはARPパケットを搬送FC配列は、非ストリーミング[FC-FS]であることが要求されています。 SEQUENCE_ID再利用によって欠落FCフレームのエイリアシングを回避するために、支持たNx_PortのIPv6またはIPv4を増加SEQ_CNT [FC-FS]連続的に使用する必要があります。各取引所は、第1のフレームにゼロにSEQ_CNTを設定することにより開始しなければなりません。その後に送信すべてのフレームを一つ前のSEQ_CNTを増加しなければなりません。 FCヘッダのF_CTLフィールドのシーケンス条件フィールドを続けゼロ[FC-FS]に設定しなければなりません。
To transmit IPv6, IPv4, or ARP packets to another Nx_Port or to a multicast/broadcast address, an Nx_Port MUST use dedicated unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4, or ARP packet transmission and that do not transfer Sequence Initiative). As such, the Sequence Initiative bit in the F_CTL field of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the FC Header MUST be set to 0xFFFF.
別たNx_Portまたはマルチキャスト/ブロードキャストアドレスへのIPv6、IPv4の、またはARPパケットを送信するために、たNx_Portは、専用の一方向交換（即ち、IPv6の、IPv4のに専用の交換、またはARPパケットの送信とそのシーケンス・イニシアチブを転送していない）を使用する必要があります。このように、FCヘッダのF_CTLフィールドのシーケンス・イニシアティブのビットはゼロ[FC-FS]に設定しなければなりません。 FCヘッダのRX_IDフィールドが0xFFFFのに設定しなければなりません。
Unicast FC Sequences carrying unicast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD be sent in short-lived unidirectional Exchanges (i.e., Exchanges containing only one Sequence, in which both the First_Sequence and
ICMP [ICMPv4の]、またはIGMP [IGMPv3の]メッセージを運ぶIPv4パケット、ICMPv6の[ICMPv6の]、近隣探索[DISC]、またはマルチキャストリスナーディスカバリー【のMLDv2]メッセージを運ぶIPv6パケット、ユニキャスト制御プロトコル・パケット（例えば、ARPパケットを搬送するユニキャストFC配列）短命の一方向の交換だけで1シーケンス、中にFirst_Sequenceの両方を含む（すなわち、取引所に送ってくださいと
Last_Sequence bits in the F_CTL field of the FC Header are set to one [FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data traffic) MUST be sent in a long-lived unidirectional Exchange (i.e., an Exchange containing one or more Sequences). IP multicast packets MUST NOT be carried in unicast FC Sequences (see section 10).
FCヘッダのF_CTLフィールドのLast_Sequenceビットが1 [FC-FS]）に設定されています。他のIPv6とIPv4パケットを運ぶユニキャストFC配列（すなわち、データ・トラフィックを搬送するユニキャストIPパケット）が長寿命一方向性交換で送信されなければならない（すなわち、1つまたは複数のシーケンスを含む交換）。 IPマルチキャストパケットをユニキャストFCシーケンス（セクション10を参照）で搬送してはいけません。
Broadcast FC Sequences carrying multicast or broadcast Control Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) MUST be sent in short-lived unidirectional Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4 multicast traffic (i.e., multicast IP packets carrying data traffic) MAY be sent in long-lived unidirectional Exchanges to enable a more efficient multicast distribution.
マルチキャストまたはブロードキャスト制御プロトコル・パケット（例えば、ARPパケットを搬送する放送FC配列; ICMPv6の[ICMPv6の]、近隣探索[DISC]、またはマルチキャストリスナーディスカバリー【のMLDv2]メッセージを運ぶIPv6パケット、ICMP [ICMPv4の]、またはIGMPを運ぶIPv4パケット[IGMPv3の]のメッセージ）短命一方向の交流に送らなければなりません。他のIPv6又はIPv4マルチキャストトラフィック（データトラフィックを搬送する、すなわち、マルチキャストIPパケット）を搬送する放送FC配列は、より効率的なマルチキャスト配信を可能にするために、長寿命の一方向交換で送信することができます。
Reasons to terminate a long-lived Exchange include the termination of Port Login and the completion of the IP communication. A long-lived Exchange MAY be terminated by setting the Last_Sequence bit in the F_CTL field of the FC Header to one, or via the ABTS (Abort Sequence) protocol [FC-FS]. A long-lived Exchange SHOULD NOT be terminated by transmitting the LOGO ELS, since this may terminate active Exchanges on other FC-4s [FC-FS].
長寿命の取引を終了する理由は、ポートのログインの終了およびIP通信の完了が含まれています。長寿命Exchangeは一つにFCヘッダのF_CTLフィールドにLast_Sequenceビットを設定することによって終了、またはABTS（アボートシーケンス）プロトコル[FC-FS]を介してもよいです。これは、他のFC-4S [FC-FS]の活発な交流を終了させることができるので、長寿命の交換は、LOGO ELSを送信することにより終了されるべきではありません。
The IPv4 encapsulation defined in this document, along with Exchange and Sequence management, are as defined in [RFC-2625]. Implementations following this specification are expected to interoperate with implementations compliant to [RFC-2625] for IPv4 packet transmission and reception.
[RFC-2625]で定義されるように、この文書で定義されたIPv4カプセル化は、Exchangeおよびシーケンス管理と一緒に、です。本明細書以下の実装は、IPv4パケットの送受信のために[RFC-2625]に準拠した実装と相互運用することが期待されます。
The main difference between this document and [RFC-2625] is in the address resolution procedure. [RFC-2625] uses the Ethernet format of the ARP protocol and requires all Nx_Ports to have a format 0x1 N_Port_Name. This specification defines a Fibre Channel format for the ARP protocol that supports all commonly used N_Port_Names. In addition, this specification does not use FARP [RFC-2625].
この文書と[RFC-2625]との間の主な違いは、アドレス解決の手順です。 [RFC-2625]はARPプロトコルのイーサネット・フォーマットを使用し、フォーマットは0x1用のN_Port_Nameを持つように、すべてのNx_Portsを必要とします。この仕様は、すべての一般的に使用されるN_Port_NamesをサポートしているARPプロトコルのファイバチャネルフォーマットを定義します。また、本明細書はFARP [RFC-2625]を使用していません。
An Nx_Port following this specification, and not having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports. Through this manual configuration, the ARP protocol does not need to be performed. However, IPv4 communication is not possible if the [RFC-2625] implementation strictly enforces the requirement for Nx_Ports to use N_Port_Names of format 0x1.
たNx_Portこの仕様を以下、フォーマットは0x1とのN_Port_Nameを有していない、手動でマッピングを構成することにより、[RFC-2625]の実装と相互運用することができる<宛先IPv4アドレス、のN_Port_Name、N_ポート_ID>関与Nx_Portsオン。このマニュアル構成により、ARPプロトコルを実行する必要はありません。 [RFC-2625]実装は厳密フォーマットは0x1のN_Port_Namesを使用するNx_Portsの要件を強制する場合は、IPv4の通信は不可能です。
An Nx_Port following this specification, and having a format 0x1 N_Port_Name, is able to interoperate with an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports, or by performing the IPv4 address resolution in compatibility mode, as described below:
たNx_Portこの仕様を以下、フォーマットは0x1とのN_Port_Nameを有するが、手動でマッピングを構成することにより、[RFC-2625]の実装と相互運用することができる<宛先IPv4アドレス、のN_Port_Name、N_ポート_ID>関与Nx_Portsに、またはIPv4アドレスを行うことにより互換モードの解像度は、後述するように：
- When IPv4 address resolution is attempted, the Nx_Port MUST send
two ARP Requests, the first one according to the FC ARP format and
the second one according to the Ethernet ARP format. If only an
Ethernet ARP Reply is received, it provides the N_Port_Name of the
Nx_Port having the destination IPv4 address. The N_Port_ID
associated with the N_Port_Name received in an Ethernet ARP Reply
may be retrieved from the S_ID field of the received ARP Reply, or
by querying the Fibre Channel Name Server;
- The Nx_Port MUST respond to a received Ethernet ARP Request with
an Ethernet ARP Reply;
- The Nx_Port MAY respond to FARP Requests [RFC-2625].
The reception of a particular format of ARP message does not imply that the sending Nx_Port will continue to use the same format later.
ARPメッセージの特定のフォーマットの受信は送信たNx_Portが後で同じ形式を使用し続けることを意味するものではありません。
Support of compatibility mode is REQUIRED by each implementation. The use of compatibility mode MUST be administratively configurable.
互換性モードのサポートは、それぞれの実装によって必要とされます。互換モードを使用すると、管理上構成可能でなければなりません。
IPv6, IPv4, and ARP do 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 and IPv4, because IPv6 and IPv4 over Fibre Channel do 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, IPv4, and ARP packets. All the techniques defined to secure IP traffic at the IP layer may be used in a Fibre Channel environment.
IPv6の、IPv4の、そしてARPは、すでにファイバ・チャネル・プロトコル内に存在しているものを超えて追加のセキュリティ上の懸念を導入しません。ファイバチャネルを介したIPv6とIPv4は、FCネームサーバを使用していないので（ソフトゾーニング）をマスキングFCネームサーバに基づくゾーニング手法は、IPv6とIPv4では動作しません。 FC ESP_Header [FC-FSは]のIPv6、IPv4の、およびARPパケットを運ぶFCシーケンスを構成するFCフレームを固定するために使用されてもよいです。 IP層でのIPトラフィックを保護するために定義されたすべての技術は、ファイバチャネル環境で使用することができます。
The directory of ARP parameters has been updated to reference this document for hardware type 18.
ARPパラメータのディレクトリには、ハードウェアタイプ18は、このドキュメントを参照するように更新されました。
The authors would like to acknowledge the ANSI INCITS T11.3 Task Group members who reviewed this document as well as the authors of [RFC-2625] and [RFC-3831]. The authors also thank the IMSS WG and Brian Haberman for their review and comments.
作者はこのドキュメントだけでなく、[RFC-2625]と[RFC-3831]の著者を見直しANSI INCITS T11.3タスクグループのメンバーを確認したいと思います。著者はまた、彼らのレビューとコメントをIMSS WGとブライアンハーバーマンに感謝します。
[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月。
[PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD6]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
【のIPv4]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[ARP]プラマー、D.、 "イーサネットアドレス解決プロトコル：またはEthernetハードウェア上での伝送のためのイーサネットアドレスを48ビットするネットワーク・プロトコル・アドレスを変換"、STD 37、RFC 826、1982年11月には。
[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月。
[RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre Channel", RFC 3831, July 2004.
[RFC-3831] DeSanti、C.、 "ファイバチャネルの上のIPv6パケットのトランスミッション"、RFC 3831、2004年7月。
[RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[RFC-2625] Rajagopal、M.、Bhagwat、R.、およびW.リカード、 "ファイバチャネルを介したIPとARP"、RFC 2625、1999年6月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[のMLDv2]ヴィーダ、R.とL.コスタ、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[IGMPv3の]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[PMTUD4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PMTUD4]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
【のICMPv6]コンタ、A.、およびS.デアリング、 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 2463、1998年12月。
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv4の]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html
[EUI64] "64ビットのグローバル識別子（EUI64）登録機関のためのガイドライン"、http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html
A. Transmission of a Broadcast FC Sequence over FC Topologies (Informative)
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シーケンスを送信しなければなりません。
1) 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.
1）ソースは、NLポートは、第FCヘッダのD_IDフィールドを検査しながら、彼らが受け取ることフレームを複製するために、それ自体を除くループ（）内のすべてのNL_Portsを強制的に開くブロードキャスト複製（OPN（FR））プリミティブ信号を送信します。
2) The source NL_Port then removes the OPN(fr) signal when it returns to it.
それに戻ると2）ソースNLポートは、次に、OPN（FR）信号を除去します。
3) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
3）ソース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 that 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 (Informative)
<の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 Loop Initialization Primitive Sequence (LIP) in a loop topology [FC-AL-2] or after Not_Operational Primitive Sequence / Offline Primitive Sequence (NOS/OLS) in a point-to-point topology [FC-FS].
FCリンクの中断が発生した後、たNx_PortのN_Port_IDを変更するには、だけでなく、以前にこのたNx_Portでポートログインを行っている他のすべてのNx_PortsののN_Port_IDがあります。このため、アドレス検証は、ループ・トポロジ内のループ初期化プリミティブシーケンス（LIP）後に必要とされる[FC-AL-2]又はポイントツーポイントトポロジでNot_Operationalプリミティブシーケンス/オフラインプリミティブシーケンス（NOS / OLS）後[FC-FS]。
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 Link Reset (LR). In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after an 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 the Address Discovery procedure with the ADISC ELS [FC-FS].
他のポートのアドレスが検証されるまでLIP [FC-AL-2]の後、NLポートは、別のNLポートにデータを送信してはなりません。検証はADISC ELS [FC-FS]でアドレス発見手順を完了から構成されています。
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 Fabric Address Notification (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 (i.e., to any private loop NL_Port).
フォーム0x00-00-XX（すなわち、任意のプライベートループNLポートまで）のN_ポート_IDを有するローカルループ上のNLポートにセクションB.3で指定されている公衆ループNLポートプライベートループ検証を実行しなければなりません。
B.5. FC Layer Address Validation in a Fabric Topology
B.5。ファブリックトポロジでのFC層アドレス検証
No validation is required after Link Reset (LR).
何の検証は、リンクリセット（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 24 is cut and pasted at the top of the figures present in this document.
図24に示すデータ構造の見出しは、本文書中に存在する図の上部で切断し、貼り付けられている場合、ファイバチャネルビットの番号を観察することができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Fibre Channel Bit Numbering
図24：ファイバチャネルビット番号
D. Changes from
D.変更から
- Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF
are supported, in addition to format 0x1;
- An IP-capable Nx_Port MUST support Class 3;
- An IP-capable Nx_Port MUST support continuously increasing
SEQ_CNT;
- An IP-capable Nx_Port SHOULD support a receive data field size for
Device_Data FC frames of at least 1024 octets;
- The FC ESP_Header MAY be used;
- FC Classes of services other than 3 are not recommended;
- Defined a new FC ARP format;
- Removed support for FARP because some FC implementations do not
tolerate receiving broadcast ELSes;
- Added support for IPv4 multicast;
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified the usage of FC Sequences and Exchanges.
E. Changes from
E.変更から
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified and updated the mapping of IPv6 multicast on Fibre
Channel;
- Clarified the usage of FC Sequences and Exchanges;
- Clarified and updated the format of the Neighbor Discovery
Link-layer option for Fibre Channel.
Authors' Addresses
著者のアドレス
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
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
クレイグW.カールソンのQLogic社6321ドライブイーデンプレーリー、MN 55346 USAベリー
Phone: +1 952 932-4064 EMail: craig.carlson@qlogic.com
電話：+1 952 932-4064 Eメール：craig.carlson@qlogic.com
Robert Nixon Emulex 3333 Susan Street Costa Mesa, CA 92626 USA
ロバート・ニクソンのEmulex 3333スーザン・ストリートコスタメサ、CA 92626 USA
Phone: +1 714 885-3525 EMail: bob.nixon@emulex.com
電話：+1 714 885-3525 Eメール：bob.nixon@emulex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。