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
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).
版权所有（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
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\u端口名称格式限制。[RFC-2625]将IPv4的使用限制在具有0x1 N_Port_Name格式的光纤通道设备上，但许多当前的实现使用其他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]需要FARP的支持才能将N_端口名称映射到N_端口ID，但当前的许多实现都使用其他方法，如光纤通道名称服务器。
- 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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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）是一种主要用于存储网络的千兆速度网络技术。光纤通道由国际信息技术标准委员会（INCITS）的T11技术委员会标准化，该委员会是美国国家标准协会（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:
光纤通道设备称为节点。每个节点都有一个或多个连接到其他设备端口的端口。光纤通道可以使用以下三种拓扑的任意组合来实现：
- 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].
- 两个端口之间的点对点链路；-由称为结构的交换网络互连的一组端口，如[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_端口。使用特定于环路的协议在环路拓扑中运行的节点端口被指定为NL_端口。术语Nx_端口用于表示能够在任一模式下运行的节点端口。
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_端口用于表示能够在任一模式下运行的结构端口。
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_端口是[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_端口是[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位名称\ U标识符标识。[FC-FS]定义了名称标识符的几种格式。最高有效4位的值定义名称标识符的格式。以下以更简洁的方式引用这些名称标识符：
- 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_端口的名称_标识符称为N_端口_名称；-Fx\u端口的名称\u标识符称为F\u端口\u名称；-节点的名称\标识符称为节点\名称；-结构的名称\标识符称为结构\名称。
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_端口与两个标识符关联，其非易失性N_端口名称和称为N_端口ID的易失性24位地址。N_端口名称用于标识Nx_端口，N_端口ID用于Nx_端口之间的通信。
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_端口通过执行一个名为Fabric Login（结构登录）或FLOGI的过程从结构获取一个N_端口ID。FLOGI过程还用于协商Nx_端口和结构之间的多个通信参数，例如接收数据字段大小，它确定了可在Nx_端口和结构之间传输的光纤通道帧的最大大小。
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.
在两个Nx_端口之间进行有效通信之前，它们必须完成一个称为端口登录或PLOGI的过程。PLOGI进程为每个Nx_端口提供另一个Nx_端口的N_Port_名称，并协商若干通信参数，如接收数据字段大小，该参数确定可在两个Nx_端口之间传输的光纤通道帧的最大大小。
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 | | |
+-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+
| | | 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_头；-网络_头；-关联_头；-设备标题。
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服务类别。[FC-FS]中规定了五类服务。它们的主要区别在于通信Nx_端口之间的流量控制方法和提供的数据完整性级别。给定结构或Nx_端口可支持以下一种或多种服务类别：
- 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级通常用于航空电子设备中的特殊应用。对于IPv6、IPv4和ARP，建议使用类别3（参见第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帧组成，这些帧与FC报头的Sequence_ID（SEQ_ID）字段的值相关。
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_端口实现，并在登录过程中协商。当要传输的信息单元超过该值时，FC-2级将其分割为多个FC帧，作为单个序列发送。接收Nx_端口重新组装帧序列，并将重新组装的信息单元传送至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交换。交换是两个Nx_端口用来识别和管理它们之间的操作的机制。当两个Nx_端口之间的操作开始时，交换机打开，当操作结束时，交换机关闭。属于同一交换的FC帧通过FC头中交换ID字段的值进行关联。发起者交换ID（OX_ID）和响应者交换ID（RX_ID）唯一标识一对Nx_端口之间的交换。
This specification requires an IP-capable Nx_Port to have the following properties:
本规范要求具有IP功能的Nx_端口具有以下属性：
- 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_端口_名称的格式必须为0x1、0x2、0x5、0xC、0xD、0xE、0xF中的一种（见第5.1节）；-它必须支持类别3；-它必须支持不断增加的序列[FC-FS]；-它必须能够发送和接收至少1304个八位字节长的FC-4信息单元（见第4.1节）；-它应支持至少1024个八位字节的设备_数据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-4级别的信息单元又被FC-2级别[FC-FS]映射到FC序列。包含IP数据包的FC信息单元必须携带FC网络_头[FC-FS]和逻辑链路控制/子网访问协议（LLC/SNAP）头[IEEE-LLC]，从而形成图2中所示的FC信息单元格式。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 or IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| |
+- -+
| 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个八位字节），支持IP的Nx_端口必须能够发送和接收至少1304个八位字节长（即1280+8+16）的FC-4信息单元。
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_报头[FC-FS]可用于保护构成IP FC序列的FC帧。IP FC序列中不得使用其他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网络_头和LLC/SNAP头。其他框架不能包括它们，如图3所示。
First Frame of an IP FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IP Packet |
+-----------+-------------------+-----------------+-------//--------+
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 |
+-----------+----------------//---------------------+
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-4级别的信息单元又被FC-2级别映射到FC序列。包含ARP数据包的FC信息单元必须携带FC网络_头[FC-FS]和LLC/SNAP头[IEEE-LLC]，从而形成图4所示的FC信息单元格式。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| |
+- -+
| 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帧，该FC帧必须包括FC网络_报头和LLC/SNAP报头。
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_报头[FC-FS]可用于保护承载ARP分组的FC帧。在承载ARP数据包的FC帧中不得使用其他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数据包；-多播/广播IPv4数据包；-控制协议数据包（例如，ARP数据包；承载ICMPv6[ICMPv6]、邻居发现[DISC]或多播侦听器发现[MLDv2]消息的IPv6数据包；承载ICMP[ICMPv4]或IGMP[IGMPv3]消息的IPv4数据包；IPv6和IPv4路由协议数据包）。
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.
Fibre Channel标头的字段如图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 |
+---------------+---------------+---------------+---------------+
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]的设备_数据帧）；-类型：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:0x20（网络_头）用于IPv6或IPv4序列的第一个FC帧，0x00用于以下FC帧。如果使用FC ESP_头，则0x60表示IPv6或IPv4序列的第一个FC帧，0x40表示以下FC帧；-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]的设备_数据帧）；-类型：0x05（光纤通道上的IP）；-CS_CTL/Prio:0x00是默认值，请参阅[FC-FS]了解其他值；-DF_CTL:0x20（网络_头）。如果使用FC ESP_头，则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网络_头的字段如图6所示。对于IPv6、IPv4和ARP，N_端口名称格式必须是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 -+
| |
+---------------------------------------------------------------+
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网络头格式
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 |
+---------------+---------------+---------------+---------------+
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:0x86DD表示IPv6，0x0800表示IPv4，0x0806表示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节）。可通过包含指定较小MTU的MTU选项的路由器广告[光盘]或通过手动配置每个Nx_端口来减小该尺寸。但是，根据[IPv6]的要求，MTU不得低于1280个八位字节。如果在Nx_端口上接收的路由器播发具有MTU选项，该MTU选项指定的MTU大于65280或大于手动配置的值，则该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大小远远超过Internet中通常使用的消息大小，IPv6 over 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_端口或通过路径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_端口的IPv6接口ID[AARCH]基于从Nx_端口的N_端口名称派生的EUI-64地址[EUI64]。IPv6接口标识符是通过对派生EUI-64地址的OUI字段的通用/本地（U/L）位进行补码获得的。U/L位在光纤通道中不起作用；但是，当名称标识符转换为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名称\u标识符的方法。这允许使用这些名称标识符来支持IPv6。[FC-FS]还定义从EUI-64地址派生的EUI-64映射FC名称\ U标识符（格式0xC、0xD、0xE和0xF）。可以反转此地址映射以获得原始EUI-64地址，以支持IPv6。
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无状态地址自动配置必须按照[ACONF]中的规定执行。用于Nx_端口无状态地址自动配置的IPv6地址前缀的长度必须为64位。
The Name_Identifier format 0x1 is shown in figure 8.
名称\u标识符格式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 |
+---------------+---------------+---------------+---------------+
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名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format shown in figure 9 [FC-FS].
从该名称\u标识符派生的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 |
+---------------+---------------+-------+-------+---------------+
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格式名称\u标识符的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名称_标识符中的OUI完全相同。生成的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 |
+---------------+---------------+-------+-------+---------------+
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名称\标识符格式的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名称_标识符0x10-00-34-63-46-AB-CD-EF生成IPv6接口标识符3463:461A:BCDE:F000。
The Name_Identifier format 0x2 is shown in figure 11.
名称\u标识符格式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 |
+---------------+---------------+---------------+---------------+
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名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format shown in figure 12 [FC-FS].
从该名称\u标识符派生的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 |
+---------------+-----------------------+-------+---------------+
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格式名称\u标识符的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名称_标识符中的OUI完全相同。生成的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 |
+---------------+-----------------------+-------+---------------+
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名称\标识符格式的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名称_标识符0x27-89-34-63-46-AB-CD-EF生成IPv6接口标识符3463:462A:BCDE:F789。
The Name_Identifier format 0x5 is shown in figure 14.
名称_标识符格式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 |
+---------------+---------------+---------------+---------------+
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名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format shown in figure 15 [FC-FS].
从该名称_标识符派生的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 |
+---------------+---------------+---------------+---------------+
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格式名称\u标识符的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接口标识符从该EUI-64地址获得，该地址补充OUI字段中的U/L位。因此，IPv6接口ID中的OUI与FC名称_标识符中的OUI完全相同。生成的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 |
+---------------+---------------+---------------+---------------+
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名称\标识符格式的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名称_标识符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映射名称\ U标识符格式（格式0xC到0xF）通过压缩EUI-64地址的OUI字段从该地址派生而来。压缩是通过从OUI中删除通用/本地和单个/组位，并将OUI的位0到5放入名称_标识符的第一个八位字节，将OUI的位8到23放入名称_标识符的第二和第三个八位字节来执行的，如图17所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
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映射名称\u标识符格式
The EUI-64 address used to generate the Name_Identifier shown in figure 17 has the format shown in figure 18.
用于生成图17所示的名称_标识符的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 |
+---------------+---------------+---------------+---------------+
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映射名称\u标识符中的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 |
+---------------+---------------+---------------+---------------+
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映射名称\u标识符的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名称_标识符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_端口的IPv6链路本地地址[AARCH]是通过将接口标识符（如第5节所定义）附加到前缀FE80:：/64来形成的。结果地址如图20所示。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
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]将IPv4的使用限制为N_端口名称格式为0x1的Nx_端口。尽管这在当时可能是一个合理的选择，但如今，广泛使用的是N_端口名称格式（而非0x1）的Nx_端口。
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）的光纤通道特定版本，将N_端口名称和N_端口ID作为硬件（HW）地址，来容纳具有不同于0x1格式的N_端口名称的Nx_端口。
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已注册数字18（十进制），以将光纤通道标识为ARP HW类型。FC ARP数据包格式如图21所示。FC ARP数据包的长度为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 |
+---------------+---------------+---------------+---------------+
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.
- 硬件类型：0x0012（光纤通道）；-协议：0x0800（IPv4）；-硬件长度：12（硬件地址的八位字节长度）；-协议长度：4（协议地址的八位字节长度）；-操作码：0x0001表示ARP请求，0x0002表示ARP回复[ARP]；-发送方的硬件地址：ARP请求中请求方的硬件地址（见第8节），或ARP回复中响应方的硬件地址；-发送方的协议地址：ARP请求中请求方的IPv4地址，或ARP应答中响应方的IPv4地址；-目标的硬件地址：在ARP请求中设置为零，在ARP应答中设置为请求者的硬件地址（见第8节）；-目标的协议地址：ARP请求中响应者的IPv4地址，或ARP应答中请求者的IPv4地址。
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 |
+---------------+---------------+---------------+---------------+
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_端口有两种光纤通道地址：
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
- 非易失性64位地址，称为N_Port_Name；-一个不稳定的24位地址，称为N_Port_ID。
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_名称用于唯一标识Nx_端口，N_Port_ID用于将帧路由到Nx_端口。解析IPv6或IPv4单播地址需要两个FC地址。N_Port_ID是易变的这一事实意味着，当发生某些光纤通道事件时，Nx_端口必须验证其N_Port_名称和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 |
+---------------+---------------+---------------+---------------+
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_端口的链路层地址（参见第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单播地址映射到光纤通道链路层地址的过程使用FC ARP协议，如第7节和[ARP]中所述。必须将IPv4数据包发送到目标Nx_端口（通过其IPv4地址知道）的源Nx_端口必须执行以下步骤：
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\U端口首先查阅其本地映射表，查找映射<目标IPv4地址，N\U端口名称，N\U端口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_端口具有有效的端口登录，则源Nx_端口使用检索到的N_端口ID作为D_ID将IPv4数据包发送到目标Nx_端口。
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_端口的有效端口登录不到位，则源Nx_端口向其连接的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) 当Nx_端口接收到具有匹配IPv4地址的广播FC ARP请求时，该Nx_端口将FC ARP请求中携带的信息缓存在其本地映射表中，并生成单播FC ARP应答。如果发送广播FC ARP请求的Nx_端口的有效端口登录不存在，则Nx_端口必须执行此类端口登录，然后将其用于单播回复。端口登录所指向的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_端口具有匹配的IPv4地址，则不会返回单播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序列，地址为广播N_Port_ID 0xFFFFFF，以FC类3在单向交换中发送（参见第12节）。附录A规定了如何通过各种光纤通道拓扑传输3级广播FC序列。FC网络_头的Destination 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-FF；-对于多播IPv6数据包：0x10-00-33-33-XX-YY-ZZ-QQ，其中XX-YY-ZZ-QQ是多播目标IPv6地址的4个最低有效八位字节；-对于多播IPv4数据包：0x10-00-01-00-5E-XX-YY-ZZ，其中XX-YY-ZZ的23个最低有效位是多播目标IPv4地址的23个最低有效位，并且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_端口必须能够将接收到的广播类3设备_数据FC帧映射到隐式端口登录上下文，以便处理IPv6多播数据包、IPv4多播或广播数据包以及ARP广播数据包。在连接到同一结构的所有Nx_端口上，此隐式端口登录的接收数据字段大小必须相同，否则FC广播传输无法工作。为了减少FC序列分段的需要，此隐式端口登录的接收数据字段大小应为1024个八位字节。此接收数据字段大小要求适用于广播设备_数据FC帧，而不适用于ELSE。
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
接收承载IPv6多播数据包、IPv4多播/广播数据包或FC ARP广播数据包的FC序列时，当该IPv6、IPv4或FC ARP数据包需要单播应答时，Nx_端口会触发一些附加处理。在这种情况下，如果有效端口登录到发送多播或广播数据包的Nx_端口
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.
不存在，Nx_端口必须执行此类端口登录，然后将其用于单播回复。对于邻居发现消息[DISC]，端口登录所指向的N_Port_ID取自所接收邻居发现消息中源链路层地址的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_端口仅通过将携带的IPv6分组传递到IPv6层来处理它。相反，如果接收到的广播FC序列携带需要单播回复的IPv6多播请求消息[DISC]，并且多播数据包的Nx_端口发送方不存在有效的端口登录，则必须执行端口登录以发送单播回复消息。如果接收到的广播FC序列携带需要多播回复的IPv6多播请求消息[DISC]，则该回复将发送到广播N_端口_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]。为了避免因序列ID重用而丢失FC帧别名，需要支持IPv6或IPv4的Nx_端口使用不断增加的序列CNT[FC-FS]。每个交换必须在第一帧中将SEQ_CNT设置为零；在此之后传输的每一帧必须将之前的序列增加一。FC头的F_CTL字段中的Continue Sequence Condition字段必须设置为零[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_端口或多播/广播地址，Nx_端口必须使用专用单向交换机（即，专用于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
承载单播控制协议数据包（例如，ARP数据包；承载ICMPv6[ICMPv6]、邻居发现[DISC]或多播侦听器发现[MLDv2]消息的IPv6数据包；承载ICMP[ICMPv4]或IGMP[IGMPv3]消息的IPv4数据包）的单播FC序列应在短寿命单向交换中发送（即，仅包含一个序列的交换，其中第一个_序列和
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字段中的最后一个_序列位设置为1[FC-FS]）。承载其他IPv6和IPv4数据包（即承载数据流量的单播IP数据包）的单播FC序列必须在长期单向交换（即包含一个或多个序列的交换）中发送。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.
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.
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（中止序列）协议[FC-FS]终止长时间的交换。不应通过传输徽标ELS来终止长期的交换，因为这可能会终止其他FC-4[FC-FS]上的活动交换。
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_端口具有格式0x1 N_端口名称。本规范定义了ARP协议的光纤通道格式，该协议支持所有常用的N_端口名称。此外，本规范未使用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.
遵循此规范且不具有0x1 N_Port_Name格式的Nx_端口能够通过在相关Nx_端口上手动配置映射<目标IPv4地址，N_Port_Name，N_Port_ID>，与[RFC-2625]实现互操作。通过这种手动配置，不需要执行ARP协议。但是，如果[RFC-2625]实现严格执行Nx_端口使用格式为0x1的N_端口名称的要求，则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:
遵循此规范且格式为0x1 N_Port_Name的Nx_端口能够通过在相关Nx_端口上手动配置映射<目标IPv4地址，N_Port_Name，N_Port_ID>，或通过在兼容模式下执行IPv4地址解析，与[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_端口必须发送两个ARP请求，第一个根据FC ARP格式，第二个根据以太网ARP格式。如果只接收到以太网ARP应答，它将提供具有目标IPv4地址的Nx_端口的N_端口名称。与以太网ARP应答中接收到的N_Port_名称相关联的N_Port_ID可以从接收到的ARP应答的S_ID字段中检索，或者通过查询光纤通道名称服务器来检索；-Nx_端口必须使用以太网ARP应答响应接收到的以太网ARP请求；-Nx_端口可响应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_端口以后将继续使用相同格式。
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名称服务器屏蔽的分区技术（软分区）不适用于IPv6和IPv4，因为光纤通道上的IPv6和IPv4不使用FC名称服务器。FC ESP_报头[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 INCITS T11.3工作组成员以及[RFC-2625]和[RFC-3831]的作者。作者还感谢IMSS工作组和Brian Haberman的审查和评论。
[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]Deering，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.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无状态地址自动配置”，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 246112998年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的路径MTU发现”，RFC 1981，1996年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4]Postel，J.，“互联网协议”，STD 5，RFC 7911981年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.，“以太网地址解析协议：或将网络协议地址转换为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.
[关键词]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 38312004年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和ARP”，RFC 26251999年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，“MTU发现路径”，RFC191990年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] "Guidelines For 64-bit Global Identifier (EUI-64)
Registration Authority",
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_端口接收具有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_端口必须通过使用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_端口首先发送开放广播复制（OPN（fr））原语信号，强制循环中的所有NL_端口（自身除外）复制它们在检查FC报头的D_ID字段时接收的帧。
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的Class 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_端口不得使用OPN（fr）原语信号。相反，它必须将具有D_ID 0xFFFFFF的Class 3广播FC序列发送到AL_PA=0x00[FC-AL-2]处的FL_端口。
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.
结构将广播传播到所有其他FC_端口[FC-FS]，包括广播到达的FL_端口。这包括所有F_端口和其他F_端口。
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）传播广播，以便准备环路以接收广播序列。
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_端口必须将D_ID为0xFFFFFF的Class 3广播FC序列传输到F_端口。结构将广播传播到所有其他FC_端口[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\u Port\u Name，N\u Port\u 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_端口的N_Port_ID可能会更改，之前使用此Nx_端口进行端口登录的所有其他Nx_端口的N_Port_ID也可能会更改。因此，在循环拓扑[FC-AL-2]中的循环初始化原语序列（LIP）或点对点拓扑[FC-FS]中的非操作原语序列/脱机原语序列（NOS/OLS）之后，需要进行地址验证。
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_端口_ID不会因链路重置（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_端口隐式注销，在NOS/OLS之后，每个N_端口必须再次执行端口登录[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].
在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_Port_ID、N_Port_名称、节点_名称）与LIP之前的值完全匹配，则可以继续与该NL_端口进行任何活动交换。
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
如果三个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_端口ID在LIP后发生更改，则必须注销所有活动的已登录NL_端口。
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_端口。因此，在LIP[FC-AL-2]之后，NL_端口可以等待该通知到达，或者它们可以执行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.
如果FAN ELS或FLOGI响应中包含的F_端口名称和结构名称与LIP之前的值完全匹配，并且如果NL_端口获得的AL_PA[FC-AL-2]与LIP之前的相同，则端口可以恢复所有交换。如果没有，则必须使用结构执行FLOGI，并且必须注销所有登录的Nx_端口。
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_端口必须按照第B.3节的规定，对本地环路上具有0x00-00-XX形式的N_端口ID的任何NL_端口（即，对任何专用环路NL_端口）执行专用环路验证。
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_端口ID、F_端口名称和结构名称与NOS/OLS之前相同，则N_端口可以恢复所有交换。否则，必须注销所有登录的Nx_端口[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
- 除格式0x1外，还支持N_端口名称格式为0x2、0x5、0xC、0xD、0xE和0xF的Nx_端口；-支持IP的Nx_端口必须支持Class 3；-支持IP的Nx_端口必须支持不断增加的序列号；-支持IP的Nx_端口应支持至少1024个八位字节的设备_数据FC帧的接收数据字段大小；-可以使用FC ESP_头；-不建议使用除3类以外的FC类服务；-定义了新的FC ARP格式；-删除对FARP的支持，因为某些FC实现不允许接收广播ELSE；-增加了对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序列和交换的使用；-阐明并更新了光纤通道的邻居发现链路层选项的格式。
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.圣何塞，加利福尼亚州，美国95134
Phone: +1 408 853-9172
EMail: cds@cisco.com
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美国明尼苏达州伊甸草原伯里大道55346号
Phone: +1 952 932-4064
EMail: craig.carlson@qlogic.com
Phone: +1 952 932-4064
EMail: craig.carlson@qlogic.com
Robert Nixon Emulex 3333 Susan Street Costa Mesa, CA 92626 USA
美国加利福尼亚州科斯塔梅萨市苏珊街3333号，邮编92626
Phone: +1 714 885-3525
EMail: bob.nixon@emulex.com
Phone: +1 714 885-3525
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。