[要約] RFC 4338は、Fibre Channel上でIPv6、IPv4、およびAddress Resolution Protocol（ARP）パケットを転送するための仕様です。このRFCの目的は、Fibre Channelネットワーク上でこれらのパケットを効果的に転送するためのガイドラインを提供することです。
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
ファイバーチャネル上のIPv6、IPv4、およびアドレス解像度プロトコル（ARP）パケットの送信
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).
Copyright（c）The Internet Society（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）パケットをカプセル化する方法を指定します。このドキュメントは、Fiberチャネルネットワーク上のIPv6 Link-LocalアドレスとStatelestely Autoconfigured 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].
Fiber Channel（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]は、Format 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_NAMESをN_PORT_IDSにマッピングするためにFARPのサポートを必要としますが、多くの現在の実装はFiber Channel Name Serverなどの他の方法を使用しています。
- 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]を形成し、ファイバーチャネルネットワークでステートレレスAutoconfigured IPv6アドレスを形成する方法を定義します。[RFC-3831]は、ファイバーチャネルネットワークでメッセージが送信されたときに、Neighbor Discovery [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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
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.
Fiber Channel（FC）は、主にストレージネットワーキングに使用されるギガビットスピードネットワークテクノロジーです。Fiber Channelは、American National Standard Institute（ANSI）認定基準委員会であるInternational Information Technology Standards（Incits）のT11技術委員会に標準化されています。
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].
- 2つのポート間のポイントツーポイントリンク。 - [FC-FS]で定義されているように、ファブリックと呼ばれるスイッチングネットワークによって相互接続されたポートのセット。 - [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_PORTと呼ばれます。ループ固有のプロトコルを使用してループトポロジで動作するノードポートは、NL_PORTとして指定されます。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_portと呼ばれます。ループ固有のプロトコルを使用してループトポロジで動作するファブリックポートは、FL_PORTとして指定されています。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の観点から、Fiberチャネルネットワークは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.
- nx_portのname_identifierはn_port_nameと呼ばれます。-fx_portのname_identifierはf_port_nameと呼ばれます。-Nodeのname_identifierはnode_nameと呼ばれます。 - ファブリックのname_identifierは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は、2つの識別子、その非揮発性N_PORT_NAMEとN_PORT_IDと呼ばれる揮発性24ビットアドレスに関連付けられています。N_PORT_NAMEはNX_PORTを識別するために使用され、N_PORT_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に他のNX_PORTのN_PORT_NAMEを提供し、受信データフィールドサイズなどのいくつかの通信パラメーターを交渉し、2つの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).
ファブリックログインとポートログインの両方が、明示的なもの（つまり、拡張リンクサービス、またはELSEと呼ばれる特定の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.
- 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は、次のクラスの1つ以上のサービスをサポートできます。
- 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.
- クラス1：配信確認との専用の物理的接続。 - クラス2：配信確認を備えたフレーム多重化サービス。 - クラス3：データグラムサービス。 - クラス4：分数帯域幅。 - クラス6：専用の接続を介した信頼性の高いマルチキャスト。
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 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やIPv4パケットなどのアプリケーションレベルのペイロードは、FC-4レベルのファイバーチャネルの情報ユニットと呼ばれます。各FC-4情報ユニットは、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-2レベルはそれを複数のFCフレームにセグメントし、単一のシーケンスとして送信します。受信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交換に属するものとしてグループ化できます。交換は、2つのNX_PORTSが使用するメカニズムであり、それらの間の操作を識別および管理します。2つのNX_PORTSの間で操作が開始されると交換が開かれ、操作が終了すると閉じられます。同じ交換に属するFCフレームは、FCヘッダーのExchange_IDフィールドの値に関連しています。Originator 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).
- そのn_port_nameの形式は、0x1、0x2、0x5、0xc、0xd、0xe、0xfのいずれかでなければなりません（セクション5.1を参照）。 - クラス3をサポートする必要があります。-SEQ_CNT [FC-FS]を継続的に増加させることをサポートする必要があります。 - 少なくとも1304オクテットのFC-4情報ユニットを送信および受信できる必要があります（セクション4.1を参照）。-1024オクテットのDevice_Data FCフレームの受信データフィールドサイズをサポートする必要があります（セクション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-4レベルのファイバーチャネルの情報ユニットにマッピングされ、FC-2レベル[FC-FS]によってFCシーケンスにマッピングされます。IPパケットを含むFC情報ユニットは、FC Network_Header [FC-FS]と論理リンクコントロール/サブネットワークアクセスプロトコル（LLC/SNAP）ヘッダー[IEEE-LLC]を搭載する必要があります。。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 or IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Figure 2: FC Information Unit Mapping an IP Packet
図2：IPパケットをマッピングするFC情報ユニット
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-4レベルのファイバーチャネルの情報ユニットにマッピングされ、FC-2レベルによってFCシーケンスにマッピングされます。ARPパケットを含むFC情報ユニットは、FC Network_Header [FC-FS]とLLC/SNAPヘッダー[IEEE-LLC]を搭載する必要があり、図4に示すFC情報ユニット形式が表示されます。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Figure 4: FC Information Unit Mapping an ARP Packet
図4：ARPパケットのマッピングFC情報ユニット
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:
この仕様では、FCクラス3を使用しています。次の種類のパケットをクラス3 FCフレームにマッピングする必要があります。
- 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).
- マルチキャストIPv6パケット。-MultiCast/Broadcast IPv4パケット。 - コントロールプロトコルパケット（例：ARPパケット、ICMPV6 [ICMPV6]、隣接リスナーディスカバリー[MLDV2]メッセージ、ICMP [ICMPv4]またはIGMP [IGMPv3]メッセージを運ぶIPv4パケットを運ぶIPv6パケット。ルーティングプロトコルパケット）。
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パケット）もクラス3 FCフレームにマッピングする必要があります。クラス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.
ファイバーチャネルヘッダーのフィールドを図5に示します。D_IDおよびS_IDフィールドには、それぞれ宛先N_PORT_IDとソースN_PORT_IDが含まれています。
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);
- r_ctl：0x04（未承諾のデータ情報カテゴリ[FC-FS]を備えたDevice_Dataフレーム）; - タイプ：0x05（ファイバーチャネル上のIP）;
- 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].
- CS_CTL/PRIO：0x00はデフォルトです。他の値については[FC-FS]を参照してください。-DF_CTL：IPv6またはIPv4シーケンスの最初のFCフレームの0x20（network_header）、次のFCフレームの0x00。FC ESP_Headerを使用する場合は、IPv6またはIPv4シーケンスの最初のFCフレームで0x60、次のFCフレームで0x40。-f_ctl、seq_id、seq_cnt、ox_id、rx_id：追加要件については、セクション11、セクション12、および[fc-fs]を参照してください。 - パラメーター：相対オフセット[FC-FS]が使用されない場合、このフィールドのコンテンツは受信機によって無視され、送信者がゼロに設定する必要があります。相対オフセットを使用する場合は、[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.
- r_ctl：0x04（未承諾のデータ情報カテゴリ[FC-FS]を備えたDevice_Dataフレーム）; - タイプ：0x05（ファイバーチャネル上のIP）;-CS_CTL/PRIO：0x00はデフォルトです。他の値については[FC-FS]を参照してください。-df_ctl：0x20（network_header）。FC esp_headerを使用する場合は、0x60;-f_ctl、seq_id、seq_cnt、ox_id、rx_id：追加要件については、セクション11、セクション12、および[fc-fs]を参照してください。 - パラメーター：ゼロに設定する必要があります。
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のフィールドを図6に示します。IPv6、IPv4、およびARPで使用するには、N_PORT_NAMESフォーマットは0x1、0x2、0x5、0xc、0xd、0xe、0xf [fc-fs]の1つでなければなりません。
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.
- DSAP：0xaa;-SSAP：0xaa;-Ctrl：0x03;-OUI：0x000000;-PID：IPv6の場合は0x86DD、IPv4の場合は0x0800、ARPの0x0806。
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パケットは、標準のネットワークバイト順序または標準形式に対応するBig-Endian BYTE順序を使用して、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を参照）。このサイズは、小さいMTUを指定するMTUオプションを含むルーター広告[disc]、または各NX_PORTの手動構成によって縮小できます。ただし、[IPv6]で要求されているように、MTUは1280オクテットよりも低くてはなりません。NX_PORTで受信したルーター広告には、65280を超えるMTUを指定するMTUオプションがある場合、または手動で構成された値よりも大きい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サイズがインターネットで通常使用されるメッセージサイズをはるかに超えるため、FCの実装を介してIPv6の実装はPATH 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の手動構成またはPATH 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に由来するEUI-64アドレス[EUI64]に基づいています。IPv6インターフェイス識別子は、派生EUI-64アドレスのOUIフィールドのユニバーサル/ローカル（U/L）ビットを補完することにより取得されます。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アドレスから派生したEUI-64マッピングFC name_identifiers（フォーマット0xc、0xd、0xe、および0xf）も定義します。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.
IPv6ステートレスアドレスAutoconfigurationは、[ACONF]で指定されているように実行する必要があります。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 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. 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：フォーマット0x1 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
例として、FC name_identifier 0x10-00-34-63-46-AB-CD-EFは、IPv6インターフェイス識別子3463：461a：BCDE：F000を生成します。
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 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. 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：フォーマット0x2 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
例として、FC name_identifier 0x27-89-34-63-46-ab-cd-efは、IPv6インターフェイス識別子3463：462A：BCDE：F789を生成します。
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：FORMAT 0x5 name_identifierのEUI-64アドレス
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：フォーマット0x5 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
例として、FC name_identifier 0x53-46-34-6a-bc-de-f7-89は、IPv6インターフェイス識別子3463：465a：BCDE：F789を生成します。
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マッピングされたNAME_IDENTIFIERSフォーマット（フォーマット0XCから0xF）は、そのようなアドレスのOUIフィールドを圧縮することにより、EUI-64アドレスから派生します。圧縮は、OUIからユニバーサル/ローカルおよび個人/グループのビットを除去し、name_identifierの最初のオクテットにOUIの0〜5を除去し、2番目と3番目のOUIの8〜23を除去することによって実行されます。図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：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.
例として、FC name_identifier 0xcd-63-46-AB-01-25-78-9aは、IPv6インターフェイス識別子3663：46AB：0125：789aを生成します。
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.
NX_PORTのIPv6リンクローカルアドレス[AARCH]は、インターフェイス識別子（セクション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を持つIPv4の使用をNX_PORTSに制限しました。これは当時の合理的な選択だったかもしれませんが、今日では、広範囲にわたる使用されている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.
この仕様は、ARPプロトコル（FC ARP）のファイバーチャネル固有のバージョンを定義することにより、0x1とは異なる形式のN_PORT_NAMESを使用してNX_PORTSに対応し、N_PORT_NAMEとN_PORT_IDの両方をハードウェア（HW）アドレスとして運びます。
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番（小数）を登録しています。FC ARPパケット形式を図21に示します。FCARPパケットの長さは40オクテットです。
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.
- HWタイプ：0x0012（ファイバーチャネル）; - プロトコル：0x0800（IPv4）;-HWレン：12（HWアドレスのオクテットの長さ）; - プロトレン：4（プロトコルアドレスのオクテットの長さ）;-OPCODE：ARPリクエストの0x0001、ARP応答の0x0002 [arp]; - 送信者のHWアドレス：ARPリクエストの要求者のHWアドレス（セクション8を参照）、またはARP応答のResponderのHWアドレス。 - 送信者のプロトコルアドレス：ARPリクエストのリクエスターのIPv4アドレス、またはARP応答の応答者のアドレス。-HWターゲットのアドレス：ARPリクエストでゼロに設定し、ARP応答の要求者のHWアドレス（セクション8を参照）に設定します。 - ターゲットのプロトコルアドレス：ARPリクエストでのレスポンダーのIPv4アドレス、またはARP応答のリクエスターのアドレス。
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.
ソース/ターゲットリンク層アドレスオプション（セクション9.2を参照）で使用されるリンク層アドレスとFC ARPで使用されるハードウェアアドレス（セクション7を参照）には、図22に示す同じ形式があります。
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_PORT_IDはフレームをNX_PORTにルーティングするために使用されます。IPv6またはIPv4ユニキャストアドレスを解決するには、両方のFCアドレスが必要です。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.
タイプ：ソースリンク層アドレスの場合。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:
IPv4ユニキャストアドレスをファイバーチャネルリンク層アドレスにマッピングする手順は、セクション7および[ARP]で指定されているように、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) Source NX_PORTは、最初にローカルマッピングテーブルをマッピング<宛先IPv4アドレス、n_port_name、n_port_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は、取得したN_PORT_IDをD_IDとして使用してIPv4パケットを宛先NX_PORTに送信します。
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 ARP要求（セクション10を参照）を接続されたFCネットワークに送信します。
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) NX_PORTが一致するIPv4アドレスを使用して、NX_PORTによってブロードキャストFC ARP要求が受信されると、NX_PORTがローカルマッピングテーブルのFC ARP要求に掲載された情報をキャッシュし、Unicast FC ARP応答を生成します。ブロードキャストFC ARPリクエストを送信したNX_PORTへの有効なポートログインが存在しない場合、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.
5) NX_PORTに一致するIPv4アドレスがない場合、Unicast 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:
IPv6マルチキャストパケット、IPv4マルチキャスト/ブロードキャストパケット、およびARPブロードキャストパケットは、単方向の交換でFCクラス3に送信されるブロードキャストN_PORT_ID 0xFFFFFFにアドレス指定されたFCシーケンスにマッピングする必要があります（セクション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.
- ブロードキャストARPおよびIPv4パケットの場合：0x10-00-ff-ff-ff-ff-ff; - マルチキャストのIPv6パケットの場合：0x10-00-33-33-xx-yy-zz-qq。 - マルチキャストのIPv4パケットの場合：0x10-00-01-00-5E-xx-yy-zz。xx-yy-zzのビットはゼロに設定されています。
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フレームを暗黙のポートログインコンテキストにマッピングできる必要があります。この暗黙のポートログインの受信データフィールドサイズは、同じファブリックに接続されたすべてのNX_PORTSで同じでなければなりません。そうしないと、FCブロードキャスト伝送は機能しません。FCシーケンスセグメンテーションの必要性を減らすために、この暗黙のポートログインの受信データフィールドサイズは1024オクテットでなければなりません。この受信データフィールドサイズの要件は、ELSEではなく、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ブロードキャストパケットを運ぶFCシーケンスを受信すると、IPv6、IPv4、またはFC ARPパケットがユニキャスト応答が必要な場合、NX_PORTによる追加の処理をトリガーします。この場合、マルチキャストまたはブロードキャストパケットを送信したNX_PORTへの有効なポートログインが存在しない場合、NX_PORTはそのようなポートログインを実行し、ユニキャスト応答に使用する必要があります。Neighbor Discoveryメッセージ[disc]の場合、ポートログインが誘導されるN_PORT_IDは、受信したNeighbor DiscoveryメッセージのソースリンクレイヤーアドレスのN_PORT_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フレームエイリアシングの欠落を避けるために、継続的に増加するSEQ_CNT [FC-FS]を使用するには、IPv6またはIPv4をサポートするNX_PORTが必要です。各交換は、最初のフレームでSEQ_CNTをゼロに設定することから開始する必要があります。その後送信されたすべてのフレームは、以前のSEQ_CNTを1つずつ増分する必要があります。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.
IPv6、IPv4、またはARPパケットを別のNX_PORTまたはマルチキャスト/ブロードキャストアドレスに送信するには、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 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シーケンスを運ぶユニキャスト制御プロトコルパケット（例：ARPパケット、ICMPV6 [ICMPV6]、隣接リスナーディスカバリー[MLDV2]メッセージを運ぶIPv6パケット;）短命の単方向交換（つまり、FCヘッダーのF_CTLフィールドのFIRST seasecenceとlast_sequenceビットの両方が1つの[FC-FS]に設定されている1つのシーケンスのみを含む交換）で送信する必要があります。他の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.
マルチキャストまたはブロードキャスト制御プロトコルパケットを運ぶFCシーケンスをブロードキャストします（例：ARPパケット、ICMPV6 [ICMPV6]、隣接リスナー[DISC]、またはマルチキャストリスナーディスカバリー[MLDV2]メッセージを運ぶIPv6パケット;]メッセージ）は、短命の単方向交換で送信する必要があります。他の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通信の完了が含まれます。長寿命の交換は、FCヘッダーのF_CTLフィールドに1つまたはABTS（ABORTシーケンス）プロトコル[FC-FS]を介してLAST_CTLフィールドを設定することにより終了する場合があります。これは、他のFC-4 [FC-FS]のアクティブな交換を終了する可能性があるため、ロゴELを送信することにより、長寿命の交換を終了しないでください。
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.
このドキュメントで定義されているIPv4カプセル化は、交換およびシーケンス管理とともに、[RFC-2625]で定義されています。この仕様に続く実装は、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プロトコルのイーサネット形式を使用しており、すべてのNX_PORTSがフォーマット0x1 N_PORT_NAMEを持たせる必要があります。この仕様は、一般的に使用されるすべての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]の実装と相互運用することができます。この手動構成を通じて、ARPプロトコルを実行する必要はありません。ただし、[RFC-2625]の実装がNX_PORTSがフォーマット0x1のN_PORT_NAMESを使用する要件を厳密に強制的に強制する場合、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]の実装と相互運用することができます。以下で説明するように、互換性モードの解像度：
- 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].
- IPv4アドレス解像度が試行される場合、NX_PORTは2つのARPリクエストを送信する必要があります。これは、FC ARP形式に従って最初のリクエストと2番目のARP形式に応じて、2番目のARP形式に応じて送信する必要があります。Ethernet ARP返信のみを受信した場合、宛先IPv4アドレスを持つNX_PORTのN_PORT_NAMEを提供します。イーサネットARP応答で受信したN_PORT_NAMEに関連付けられたN_PORT_IDは、受信したARP応答のS_IDフィールドから、またはFiber Channel Name Serverを照会することにより取得できます。-NX_PORTは、イーサネットARP応答で受信したイーサネットARP要求に応答する必要があります。-NX_PORTは、FARPリクエスト[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は、ファイバーチャネルプロトコル内に既に存在するものを超えて追加のセキュリティ上の懸念を導入しません。FC Name Serverマスキング（ソフトゾーニング）に基づくゾーニング技術は、IPv6およびIPv4で動作しません。これは、ファイバーチャネル上のIPv6およびIPv4がFC名サーバーを使用しないためです。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.
著者は、このドキュメントをレビューしたANSIインセットT11.3タスクグループメンバーと[RFC-2625]および[RFC-3831]の著者を認めたいと考えています。著者はまた、IMSS WGとブライアンハーバーマンのレビューとコメントに感謝します。
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)".
[FC-FS] ANSIは373-2003、「ファイバーチャネル - フレーミングとシグナリング（FC-FS）」を挿入します。
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 (FC-AL-2)".
[FC-AL-2] ANSIは332-1999、「ファイバーチャネル - 任意ループ2（FC-AL-2）」を挿入します。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and 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。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アーキテクチャのアドレス指定」、RFC 3513、2003年4月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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. Simpson、「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] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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 STD 802-2001、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Rickard、「IP and ARP Over Fiber Channel」、RFC 2625、1999年6月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDV2] Vida、R。およびL. Costa、「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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[PMTUD4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PMTUD4] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPV4] Postel、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ビットグローバル識別子（EUI-64）登録局のガイドライン」、http：//standards.ieee.org/regauth/oui/tutorials/ eui64.html
A. Transmission of a Broadcast FC Sequence over FC Topologies (Informative)
A. FCトポロジを介したブロードキャストFCシーケンスの送信（有益）
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シーケンスを受信します。
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_PORTは、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) Source NL_PORTは、最初にオープンブロードキャストReplicate（OPN（FR））プリミティブ信号を送信し、ループ内のすべてのNL_PORTSを強制して、FCヘッダーのD_IDフィールドを調べながら受け取ったフレームを複製します。
2) The source NL_Port then removes the OPN(fr) signal when it returns to it.
2) ソースNL_PORTは、OPN（FR）信号を返すと削除します。
3) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
3) ソースNL_PORTは、D_ID 0xffffffを備えたクラス3ブロードキャストFCシーケンスを送信します。
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_PORTは、OPN（FR）プリミティブ信号を使用してはなりません。むしろ、d_id 0xffffffを使用したクラス3ブロードキャストFCシーケンスをal_pa = 0x00 [fc-al-2]のfl_portに送信する必要があります。
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_PORTを含む、他のすべてのFC_PORTS [FC-FS]にブロードキャストを伝播します。これには、すべてのf_ports、およびその他のfl_portsが含まれます。
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_PORTは、ブロードキャストシーケンスを受信するためにループを準備するために、プリミティブ信号OPN（FR）を使用してブロードキャストを伝播します。
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_portに接続されたN_portは、d_id 0xffffffをf_portにd_id 0xffffffを持つクラス3ブロードキャストFCシーケンスを送信する必要があります。生地は、他のすべてのFC_PORTS [FC-FS]にブロードキャストを伝播します。
B. Validation of the <N_Port_Name, N_Port_ID> Mapping (Informative)
B. <n_port_name、n_port_id>マッピングの検証（情報）
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が変更される場合があります。このため、ループトポロジ[FC-AL-2]のループ初期化プリミティブシーケンス（LIP）の後、またはポイントツーポイントトポロジのNot_operational Primitive Sequence / Offline Primitive Sequence（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_idsリンクリセット（lr）[fc-fs]の結果として変更されません。したがって、この場合、アドレス検証は必要ありません。
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_PORTの暗黙的なログアウトを引き起こし、NOS/OLSの後に各N_PORTが再びポートログイン[FC-FS]を実行する必要があります。
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].
リップ[FC-AL-2]の後、NL_PORTは、他のポートのアドレスが検証されるまで、データを別のNL_PORTに送信してはなりません。検証は、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_PORTの3つのFCアドレス（n_port_id、n_port_name、node_name）が、唇の前に値と正確に一致する場合、そのnl_portとのアクティブな交換は続く場合があります。
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
3つのFCアドレスのいずれかが変更された場合、リモートNL_PORTをログアウトする必要があります。
If an NL_Port's N_Port_ID changes after a LIP, then all active logged-in NL_Ports must be logged out.
nl_portのn_port_idがリップの後に変更された場合、すべてのアクティブログインnl_portsをログアウトする必要があります。
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に送信できます。したがって、唇[FC-AL-2]の後、NL_PORTSはこの通知が到着するのを待つか、フロギを実行する可能性があります。
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.
ファンELSまたはFLOGI応答に含まれるF_PORT_NAMEおよびFABRIC_NAMEが唇の前の値と正確に一致し、NL_PORTによって取得されたAL_PA [FC-AL-2]が唇の前のものと同じ場合、ポートは再開できますすべての交換。そうでない場合は、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).
パブリックループNL_PORTは、セクションB.3で指定されたプライベートループ検証を、フォーム0x00-00-XX（つまり、任意のプライベートループNL_PORT）のN_PORT_IDを持つローカルループ上の任意のNL_PORTに実行する必要があります。
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_PORTはFLOGIを実行する必要があります。Flogiの後、N_PORTのN_PORT_ID、F_PORT_NAME、およびFABRIC_NAMEがNOS/OLSの前と同じ場合、N_PORTはすべての交換を再開する場合があります。そうでない場合、すべてのログイン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 RFC 2625
D. RFC 2625からの変更
- 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.
- nx_ports with n_port_name format 0x2、0x5、0xc、0xd、0xe、および0xfは、形式0x1に加えてサポートされています。-IP対応NX_PORTはクラス3をサポートする必要があります。-IP対応NX_PORTは、継続的に増加するSEQ_CNTをサポートする必要があります。-IP対応NX_PORTは、少なくとも1024オクテットのDevice_Data FCフレームの受信データフィールドサイズをサポートする必要があります。-FC esp_headerを使用できます。-FC 3以外のサービスのクラスは推奨されません。 - 新しいFC ARP形式を定義しました。 - 一部のFC実装では、放送エルゼの受信を許容しないため、FARPのサポートを削除しました。-IPv4マルチキャストのサポートを追加しました。-FCヘッダーのCS_CTLおよびパラメーターフィールドの使用法を明確にしました。-FCクラスのサービスの使用を明確にしました。-FCシーケンスと交換の使用を明確にしました。
E. Changes from RFC 3831
E. RFC 3831からの変更
- 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.
- FCヘッダーのCS_CTLおよびパラメーターフィールドの使用法を明確にしました。-FCクラスのサービスの使用を明確にしました。 - ファイバーチャネル上のIPv6マルチキャストのマッピングを明確にして更新しました。-FCシーケンスと交換の使用を明確にしました。 - ファイバーチャネル用のNeighbor Discovery Link-Layerオプションの形式を明確にして更新しました。
Authors' Addresses
著者のアドレス
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Claudio Desanti Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134 USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
Craig W. Carlson Qlogic Corporation 6321 Bury Drive Eden Prairie、MN 55346 USA
Phone: +1 952 932-4064
EMail: craig.carlson@qlogic.com
Robert Nixon Emulex 3333 Susan Street Costa Mesa, CA 92626 USA
ロバート・ニクソン・エミューレックス3333スーザン・ストリート・コスタ・メサ、カリフォルニア92626 USA
Phone: +1 714 885-3525
EMail: bob.nixon@emulex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。