Network Working Group C. DeSanti
Request for Comments: 3831 Cisco Systems
Category: Standards Track July 2004
Network Working Group C. DeSanti
Request for Comments: 3831 Cisco Systems
Category: Standards Track July 2004
Transmission of IPv6 Packets over Fibre Channel
通过光纤通道传输IPv6数据包
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.
本文档指定了通过光纤通道封装IPv6数据包的方法，以及在光纤通道网络上形成IPv6链路本地地址和无状态自动配置地址的方法。
Table Of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IPv4 as specified in [IPFC].
光纤通道（FC）是一种高速串行接口技术，支持多种上层协议，包括[IPFC]中规定的小型计算机系统接口（SCSI）和IPv4。
The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network.
本文档旨在指定通过光纤通道封装IP版本6[IPv6]的方法，并描述在光纤通道网络上形成IPv6链路本地地址[AARCH]和无状态自动配置地址的方法。本文档还描述了在光纤通道网络上传输消息时，邻居发现[DISC]中使用的源/目标链路层地址选项的内容。
Warning to readers familiar with Fibre Channel: both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different. See Appendix C for guidance.
向熟悉光纤通道的读者发出警告：光纤通道和IETF标准都使用相同的字节传输顺序。但是，位编号不同。有关指南，请参见附录C。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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 is more precisely called an N_Port. A Node Port that is capable of operating in a loop topology using the loop specific protocols is designated as an NL_Port. The term Nx_Port is used to generically indicate these two kinds of Node Port.
节点端口更准确地称为N_端口。能够使用特定于环路的协议在环路拓扑中操作的节点端口被指定为NL_端口。术语Nx_Port一般用于表示这两种节点端口。
A Fabric Port is more precisely called an F_Port. A Fabric Port that is capable of operating in a loop topology using the loop specific protocols is designated as an FL_Port. The term Fx_Port is used to generically indicate these two kinds of Fabric Port.
结构端口更准确地称为F_端口。能够使用环路特定协议在环路拓扑中运行的结构端口被指定为FL_端口。术语Fx_Port通常用于表示这两种结构端口。
From an IPv6 point of view, a Fibre Channel network, built with any combination of the FC topologies described above, is an IPv6 Link [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces.
从IPv6的角度来看，使用上述FC拓扑的任意组合构建的光纤通道网络是IPv6链路[IPv6]。支持IPv6的Nx_端口是[IPv6]所称的接口。
Fibre Channel entities are identified by permanent 64 bit long Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the first four bits defines the format of a Name_Identifier. These names are referred to in a more precise manner as follows:
光纤通道实体由永久的64位长名称\u标识符标识。[FC-FS]定义了名称标识符的几种格式。前四位的值定义名称标识符的格式。这些名称以更精确的方式引用如下：
- 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 permanent N_Port_Name and a volatile 24 bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, while the N_Port_ID is used for communications among Nx_Ports.
连接到光纤通道网络的Nx_端口与两个标识符关联，其永久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 ELS), or implicit, in which the parameters are specified by configuration or other methods.
结构登录和端口登录可以是显式的，即使用特定的FC控制消息（称为扩展链路服务或ELS）执行，也可以是隐式的，其中参数由配置或其他方法指定。
[FC-FS] describes the Fibre Channel protocol using 5 different levels. The FC-2 and FC-4 levels are relevant for this specification. The FC-2 level defines the FC frame format, the transport services, and control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in figure 1.
[FC-FS]介绍了使用5种不同级别的光纤通道协议。FC-2和FC-4级别与本规范相关。FC-2级别定义了信息传输所需的FC帧格式、传输服务和控制功能。FC-4级别支持更高级别的协议，如IPv4、IPv6或SCSI。光纤通道帧格式如图1所示。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
图1：光纤通道帧格式
The Start of Frame (SOF) and End of Frame (EOF) are special FC transmission words that act as frame delimiters. The CRC is 4 octets long and uses the same 32-bit polynomial used in FDDI.
帧开始（SOF）和帧结束（EOF）是用作帧分隔符的特殊FC传输字。CRC的长度为4个八位字节，使用与FDDI相同的32位多项式。
The FC Header is 24 octets long and contains several fields associated with the identification and control of the Data Field.
FC报头长度为24个八位字节，包含多个与数据字段的标识和控制相关的字段。
The Data Field is of variable size, ranging from 0 to 2112 octets, and includes the user data in the Frame Payload field, and Optional Headers. The currently defined Optional Headers are:
数据字段大小可变，范围从0到2112个八位字节，包括帧有效负载字段中的用户数据和可选的标头。当前定义的可选标题包括：
- ESP_Header; - Network_Header; - Association_Header; - Device_Header.
- 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类：通过专用连接的可靠多播。
An application level payload such as IPv6 is called Information Unit at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is mapped to an FC Sequence by the FC-2 level. An FC Sequence consists of one or more FC frames related by the value of the Sequence_ID (SEQ_ID) field of the FC Header.
应用程序级有效负载（如IPv6）在光纤通道的FC-4级别称为信息单元。每个FC-4信息单元由FC-2级映射到一个FC序列。FC序列由一个或多个FC帧组成，这些帧与FC报头的Sequence_ID（SEQ_ID）字段的值相关。
The maximum data that may be carried by an FC frame is 2112 octets. The maximum usable frame size depends on the Fabric and Nx_Port implementations and is negotiated during the Login process. Whenever an Information Unit to be transmitted exceeds this value, the FC-2 level segments it into multiple FC frames, sent as a single Sequence. The receiving Nx_Port reassembles the Sequence of frames and delivers a reassembled Information Unit to the FC-4 level. The Sequence Count (SEQ_CNT) field of the FC Header may be used to ensure frame ordering.
FC帧可携带的最大数据量为2112个八位字节。最大可用帧大小取决于结构和Nx_端口实现，并在登录过程中协商。当要传输的信息单元超过该值时，FC-2级将其分割为多个FC帧，作为单个序列发送。接收Nx_端口重新组装帧序列，并将重新组装的信息单元传送至FC-4级。FC报头的序列计数（SEQ_CNT）字段可用于确保帧顺序。
Multiple Sequences may be related together as belonging to the same FC Exchange. The Exchange is a mechanism used by two Nx_Ports to identify and manage an operation between them. The Exchange is opened when the operation is started between the two Nx_Ports, and closed when the operation ends. FC frames belonging to the same
多个序列可以被关联在一起，作为属于同一FC交换。交换是两个Nx_端口用来识别和管理它们之间的操作的机制。当两个Nx_端口之间的操作开始时，交换机打开，当操作结束时，交换机关闭。属于同一帧的FC帧
Exchange are related by the value of the Exchange_ID fields in the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) uniquely identify the Exchange.
交换通过FC标头中交换ID字段的值进行关联。发起者交换ID（OX_ID）和响应者交换ID（RX_ID）唯一标识交换。
This specification requires an IPv6 capable Nx_Port to have the following properties:
本规范要求支持IPv6的Nx_端口具有以下属性：
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other Name_Identifier formats is outside the scope of this specification; - It MUST support Class 3; - It MUST support continuously increasing SEQ_CNT [FC-FS]; - It MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long; - It SHOULD support a receive data field size for Device_Data FC frames of at least 1024 octets.
- 其N_端口_名称的格式必须为0x1、0x2、0x5、0xC、0xD、0xE、0xF中的一种（参见第6.1节）。对其他名称\标识符格式的IPv6支持不在本规范的范围之内；-它必须支持类别3；-它必须支持不断增加的序列[FC-FS]；-它必须能够发送和接收至少1304个八位字节长的FC-4信息单元；-它应支持至少1024个八位字节的设备_数据FC帧的接收数据字段大小。
An IPv6 packet is mapped to an Information Unit at the FC-4 level of Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 level. An FC Information Unit containing an IPv6 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format depicted in figure 2.
IPv6数据包被映射到光纤通道FC-4级别的信息单元，而FC-4级别的信息单元又被FC-2级别映射到FC序列。包含IPv6数据包的FC信息单元必须携带FC网络_头[FC-FS]和LLC/SNAP头[IEEE-LLC]，从而形成图2中所示的FC信息单元格式。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 Packet
图2：映射IPv6数据包的FC信息单元
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing the FC Sequence. [AH] or [ESP] may be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence.
FC ESP_报头[FC-FS]可用于保护构成FC序列的FC帧。[AH]或[ESP]可用于在IPv6层提供安全性。IPv6 FC序列中不得使用其他类型的FC可选标头。
Typically, a Sequence consists of more than one frame. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/SNAP header. The other frames MUST NOT include them, as depicted in figure 3.
通常，一个序列由多个帧组成。只有序列的第一帧必须包括FC网络_头和LLC/SNAP头。其他框架不得包括它们，如图3所示。
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence
图3:IPv6 FC序列中的可选报头
This specification uses FC Class 3. IPv6 packets carrying Neighbor Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. Other IPv6 packets SHOULD use Class 3 as well. The use of other Classes of service is outside the scope of this specification.
本规范使用FC类别3。承载邻居发现[DISC]消息的IPv6数据包必须封装在第3类FC帧中。其他IPv6数据包也应使用类别3。其他服务类别的使用不在本规范的范围内。
The fields of the Fibre Channel Header are depicted in figure 4. The D_ID and S_ID fields contain respectively the destination N_Port_ID and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
Fibre Channel标头的字段如图4所示。D_ID和S_ID字段分别包含目标N_Port_ID和源N_Port_ID。要通过光纤通道封装IPv6，必须使用以下代码点：
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information Category [FC-FS]) - TYPE: 0x05 (IP over Fibre Channel) - CS_CTL/Prio: 0x0 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 Sequence, 0x00 for the following FC frames. If the FC ESP_Header is used, then 0x60 for the first FC frame of an IPv6 Sequence, 0x40 for the following FC frames. - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10, section 11, and [FC-FS] for additional requirements.
- R_CTL:0x04（具有未经请求的数据信息类别[FC-FS]的设备_数据帧）-类型：0x05（光纤通道上的IP）-CS_CTL/Prio:0x0-对于IPv6序列的第一个FC帧，DF_CTL:0x20（网络_头），对于以下FC帧，0x00。如果使用FC ESP_头，则0x60表示IPv6序列的第一个FC帧，0x40表示以下FC帧。-F_CTL、SEQ_ID、SEQ_CNT、OX_ID、RX_ID、参数：其他要求见第10节、第11节和[FC-FS]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format
图4:FC报头格式
The fields of the FC Network_Header are depicted in figure 5. For use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification.
FC网络_头的字段如图5所示。要与IPv6一起使用，N_端口名称格式必须是0x1、0x2、0x5、0xC、0xD、0xE、0xF中的一种。对其他名称标识符格式的IPv6支持不在本规范的范围内。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 5: FC Network_Header Format
图5:FC网络头格式
The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 6. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
LLC/SNAP头[IEEE-LLC]的字段如图6所示。要通过光纤通道封装IPv6，必须使用以下代码点：
- DSAP: 0xAA - SSAP: 0xAA - CTRL: 0x03 - OUI: 0x00-00-00 - PID: 0x86-DD
- DSAP:0xAA-SSAP:0xAA-CTRL:0x03-OUI:0x00-00-00-PID:0x86 DD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
图6:LLC/SNAP标头格式
IPv6 packets are mapped to the FC-4 level using the big-endian byte ordering that corresponds to the standard network byte order or canonical form.
IPv6数据包使用对应于标准网络字节顺序或规范形式的大端字节顺序映射到FC-4级别。
The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 65280 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option that specifies a smaller MTU, or by manual configuration of each Nx_Port. However, as required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement received on an Nx_Port has an MTU option specifying an MTU larger than 65280, or larger than a manually configured value, that MTU option MAY be logged to system management but MUST be otherwise ignored.
光纤通道上IPv6[IPv6]数据包的默认MTU大小为65280个八位字节。可通过包含指定较小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 [PMTUD], or at least maintain different MTU values for on-link and off-link destinations.
由于默认MTU大小远远超过Internet中通常使用的消息大小，IPv6 over FC实现应实现路径MTU发现[PMTUD]，或至少为链路上和链路外的目的地保持不同的MTU值。
For correct operation in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
为了在路由环境中正确运行，在路由器广告中配置适当的MTU选项至关重要。
For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU.
为了在混合介质（如以太网和光纤通道）桥接在一起时正确运行，所有介质中最小的MTU必须由路由器在MTU选项中公布。如果没有路由器，则必须在连接到默认MTU大于最小MTU的介质的每个节点中手动配置此MTU。
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 Interface Identifier is obtained by complementing the Universal/Local bit of the OUI field of the derived EUI-64 address.
Nx_端口的IPv6接口ID[AARCH]基于从Nx_端口的N_端口名称派生的EUI-64地址[EUI64]。IPv6接口标识符是通过对派生EUI-64地址的OUI字段的通用/本地位进行补码获得的。
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in EUI-64 addresses. This allows the usage of these Name_Identifiers to support IPv6. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived from an EUI-64 address. It is possible to reverse this address mapping to obtain the original EUI-64 address in order to support IPv6.
[FC-FS]指定在EUI-64地址中映射格式0x1（IEEE 48位地址）、0x2（IEEE扩展）或0x5（IEEE注册）FC名称_标识符的方法。这允许使用这些名称标识符来支持IPv6。[FC-FS]还定义从EUI-64地址派生的EUI-64映射FC名称\ U标识符（格式0xC、0xD、0xE和0xF）。可以反转此地址映射以获得原始EUI-64地址，以支持IPv6。
Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits.
必须按照[ACONF]中的规定执行无状态地址自动配置。用于Nx_端口无状态地址自动配置的IPv6地址前缀的长度必须为64位。
The Name_Identifier format 0x1 is depicted in figure 7.
图7描述了名称\u标识符格式0x1。
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 |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
图7：格式0x1名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 8 [FC-FS].
从该名称_标识符派生的EUI-64地址的格式如图8[FC-FS]所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier
图8:0x1格式名称\u标识符的EUI-64地址
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 9.
IPv6接口标识符是通过对OUI字段中的U/L位进行补码从该EUI-64地址获得的。因此，IPv6接口ID中的OUI与FC名称_标识符中的OUI完全相同。生成的IPv6接口标识符具有本地作用域[AARCH]和图9所示的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
图9: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 depicted in figure 10.
图10描述了名称\u标识符格式0x2。
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 |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
图10：格式0x2名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 11 [FC-FS].
从该名称_标识符派生的EUI-64地址的格式如图11所示[FC-FS]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier
图11:0x2格式名称\u标识符的EUI-64地址
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 12.
IPv6接口标识符是通过对OUI字段中的U/L位进行补码从该EUI-64地址获得的。因此，IPv6接口ID中的OUI与FC名称_标识符中的OUI完全相同。生成的IPv6接口标识符具有本地作用域[AARCH]和图12中所示的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
图12: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 depicted in figure 13.
图13描述了名称_标识符格式0x5。
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 |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
图13：格式0x5名称\u标识符
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 14 [FC-FS].
从该名称_标识符派生的EUI-64地址的格式如图14[FC-FS]所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier
图14:0x5格式名称\u标识符的EUI-64地址
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 15.
IPv6接口标识符从该EUI-64地址获得，该地址补充OUI字段中的U/L位。因此，IPv6接口ID中的OUI与FC名称_标识符中的OUI完全相同。生成的IPv6接口标识符具有本地作用域[AARCH]和图15所示的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
图15: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 from the OUI the Universal/Local and Individual/Group bits, and by putting bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 to 23 of the OUI in the second and third octet of the Name_Identifier, as shown in figure 16.
EUI-64映射名称\ U标识符格式（格式0xC到0xF）通过压缩EUI-64地址的OUI字段从该地址派生而来。压缩是通过从OUI中删除通用/本地和单个/组位，并将OUI的位0到5放入名称_标识符的第一个八位字节，将OUI的位8到23放入名称_标识符的第二和第三个八位字节来执行的，如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
图16:EUI-64映射名称\u标识符格式
The EUI-64 address used to generate the Name_Identifier shown in figure 16 has the format depicted in figure 17.
图16所示的用于生成名称_标识符的EUI-64地址具有图17所示的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier
图17：来自EUI-64映射名称\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 depicted in figure 18.
IPv6接口标识符是通过对OUI字段中的U/L位进行补码从该EUI-64地址获得的。生成的IPv6接口标识符具有全局作用域[AARCH]和图18所示的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
图18：来自EUI-64映射名称\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 6, to the prefix FE80::/64. The resulting address is depicted in figure 19.
Nx_端口的IPv6链路本地地址[AARCH]是通过将第6节中定义的接口标识符附加到前缀FE80:：/64来形成的。结果地址如图19所示。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
图19:IPv6链路本地地址格式
An Nx_Port has two kinds of Fibre Channel addresses:
Nx_端口有两种光纤通道地址：
- 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, while the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events occur (see Appendix B).
N_Port_名称用于唯一标识Nx_端口，而N_Port_ID用于将帧路由到Nx_端口。解析IPv6单播地址需要两个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 depicted in figure 20 when the link layer is Fibre Channel.
将IPv6单播地址映射到光纤通道链路层地址的过程使用邻居发现协议[DISC]。当链路层为光纤通道时，源/目标链路层地址选项的格式如图20所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Fig. 20: Source/Target Link-layer Address option for Fibre Channel
图20：光纤通道的源/目标链路层地址选项
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
类型：1表示源链接层地址。2表示目标链路层地址。
Length: 2 (in units of 8 octets).
长度：2（以8个八位字节为单位）。
N_Port_Name: This field contains the Nx_Port's N_Port_Name. N_Port_ID: This field contains the Nx_Port's N_Port_ID.
N_Port_Name：此字段包含Nx_端口的N_Port_名称。N_Port_ID：此字段包含Nx_端口的N_Port_ID。
Reserved fields MUST be zero when transmitting, and MUST be ignored when receiving.
传输时保留字段必须为零，接收时必须忽略。
By default, all best-effort IPv6 multicast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In particular, datagrams addressed to all-nodes multicast address, all-routers multicast address, and solicited-node multicast addresses [AARCH] MUST be sent as Class 3 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination N_Port_Name field of the FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies.
默认情况下，所有尽力而为的IPv6多播数据包必须映射到寻址到广播N_Port_ID 0xFF的FC序列。特别是，寻址到所有节点多播地址、所有路由器多播地址和请求的节点多播地址[AARCH]的数据报必须作为第3类FC序列发送到广播N_Port_ID 0xFF。在这种情况下，FC Network_标头的Destination N_Port_Name字段必须设置为值0x10-00-FF-FF-FF-FF-FF-FF。附录A规定了如何通过各种光纤通道拓扑传输3级广播FC序列。
An Nx_Port supporting IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context in order to handle IPv6 multicast packets. The receive data field size of this implicit Port Login MUST be the same across all the Nx_Ports connected to the same Fabric, otherwise FC broadcast transmission does not work. In order to reduce the need for FC Sequence segmentation, the receive data field size of this implicit Port Login SHOULD be 1024 octets. This receive data field size requirement applies to broadcast Device_Data FC frames, not to ELSs.
支持IPv6的Nx_端口必须能够将接收到的广播类3设备_数据FC帧映射到隐式端口登录上下文，以便处理IPv6多播数据包。在连接到同一结构的所有Nx_端口上，此隐式端口登录的接收数据字段大小必须相同，否则FC广播传输无法工作。为了减少FC序列分段的需要，此隐式端口登录的接收数据字段大小应为1024个八位字节。此接收数据字段大小要求适用于广播设备_数据FC帧，而不适用于ELS。
Receiving an FC Sequence carrying an IPv6 multicast packet MAY trigger some additional processing by the Nx_Port if that IPv6 packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the IPv6 multicast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast IPv6 reply. In the case of Neighbor Discovery messages [DISC], the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Source/Target Link-layer Address option.
如果接收到承载IPv6多播分组的FC序列需要单播应答，则Nx_端口可能会触发一些额外的处理。在这种情况下，如果发送IPv6多播数据包的Nx_端口的有效端口登录不存在，则Nx_端口必须执行此类端口登录，然后将其用于单播IPv6应答。对于邻居发现消息[DISC]，端口登录所指向的N_Port_ID取自源/目标链路层地址选项的N_Port_ID字段。
As an example, an Nx_Port processes a received broadcast FC Sequence carrying an IPv6 multicast unsolicited router advertisement [DISC] simply by passing the carried IPv6 packet to the IPv6 layer. Instead, if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a unicast reply, and
例如，Nx_端口仅通过将携带的IPv6分组传递到IPv6层来处理携带IPv6多播非请求路由器广告[DISC]的接收广播FC序列。相反，如果接收到的广播FC序列携带需要单播回复的IPv6多播请求消息[DISC]，以及
no valid Port Login exists with the Nx_Port sender of the multicast packet, then a Port Login MUST be performed in order to send the unicast reply message. If a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a multicast reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
多播数据包的Nx_端口发送方不存在有效的端口登录，则必须执行端口登录才能发送单播回复消息。如果接收到的广播FC序列携带需要多播回复的IPv6多播请求消息[DISC]，则该回复将发送到广播N_端口_ID 0xFF。
Best-effort IPv6 multicast for other multicast group addresses MAY use Fibre Channel Multicast Groups [FC-FS], if supported by the particular FC topology and implementation.
如果特定FC拓扑和实现支持，其他多播组地址的尽力而为IPv6多播可以使用光纤通道多播组[FC-FS]。
FC Sequences are REQUIRED to be non-streamed. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that MUST increment the previous SEQ_CNT by one. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
FC序列要求为非流式。为了避免因序列ID重用而丢失FC帧别名，需要支持IPv6的Nx_端口使用不断增加的序列CNT[FC-FS]。每个交换必须在第一帧中以SEQ_CNT=0开始，并且在该帧之后传输的每个帧必须将前一个SEQ_CNT增加1。从交换机中的另一个N_端口接收的任何帧对传输的序列没有影响。
To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange for sending data to each Nx_Port in the network and a dedicated Exchange for receiving data from each Nx_Port.
要传输IPv6数据包，每个Nx_端口必须有一个专用交换机，用于向网络中的每个Nx_端口发送数据，以及一个专用交换机，用于从每个Nx_端口接收数据。
An Exchange Responder is not required to assign RX_IDs. If an RX_ID of 0xFFFF is assigned, the Exchange Responder is identifying Exchanges based on S_ID / D_ID / OX_ID only.
交换应答器不需要分配RX_ID。如果分配了0xFFFF的RX_ID，则交换响应程序仅基于S_ID/D_ID/OX_ID识别交换。
When an Exchange is created between two Nx_Ports for unicast IPv6 packets, it remains active while the Nx_Ports are logged in with each other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short lived Exchange.
当在两个Nx_端口之间为单播IPv6数据包创建交换时，它将在Nx_端口彼此登录时保持活动状态。每个FC广播和ELS[FC-FS]应使用单独的短寿命交换。
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because they are used in a unidirectional mode. The Sequence Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
对于IPv6，交换机不得传输序列主动权，因为它们是以单向模式使用的。FC头[FC-FS]的F_CTL字段中的序列起始位必须设置为0。
The mechanism for aging or expiring exchanges based on activity, timeout, or other methods is outside the scope of this document.
基于活动、超时或其他方法使Exchange老化或过期的机制不在本文档的范围内。
The Exchange Originator MAY terminate Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator or Exchange Responder by using the ABTS (Abort Sequence) protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since this may terminate active Exchanges on other FC-4s [FC-FS].
交换发起人可以通过设置F_CTL LS位[FC-FS]来终止交换。交换发起者或交换响应者可以使用ABTS（中止序列）协议[FC-FS]中断交换。不应通过注销来终止IPv6交换，因为这可能会终止其他FC-4[FC-FS]上的活动交换。
IPv6 does not introduce any additional security concerns beyond those that already exist within the Fibre Channel protocols. Zoning techniques based on FC Name Server masking (soft zoning) do not work with IPv6, because IPv6 over Fibre Channel does not use the FC Name Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment.
除了光纤通道协议中已经存在的安全问题外，IPv6不会引入任何其他安全问题。基于FC名称服务器屏蔽的分区技术（软分区）不适用于IPv6，因为光纤通道上的IPv6不使用FC名称服务器。FC ESP_报头[FC-FS]可用于保护构成承载IPv6分组的FC序列的FC帧。定义用于在IPv6层保护IPv6流量的所有技术都可以在光纤通道环境中使用。
The author would like to acknowledge the authors of [IPFC], [ETHER], and [IPv6-1394], since some part of this document has been derived from them, as well as the ANSI INCITS T11.3 Task Group members who reviewed this document.
作者要感谢[IPFC]、[ETHER]和[IPv6-1394]的作者，因为本文件的某些部分源自他们，以及审查本文件的ANSI INCITS T11.3工作组成员。
[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月。
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture".
[IEEE-LLC]IEEE标准802-2001，“局域网和城域网的IEEE标准：概述和体系结构”。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[IPFC]Rajagopal，M.，Bhagwat，R.，和W.Rickard，“光纤通道上的IP和ARP”，RFC 26251999年6月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ethernet]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
[IPv6-1394]Fujisawa，K.和A.Onoe，“通过IEEE 1394网络传输IPv6数据包”，RFC 3146，2001年10月。
A. Transmission of a Broadcast FC Sequence over FC Topologies
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序列。
a) The source NL_Port first sends an Open Broadcast Replicate (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop (except itself) to replicate the frames that they receive while examining the FC Header's D_ID field. b) The source NL_Port then removes the OPN(fr) signal when it returns to it. c) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
a) 源NL_端口首先发送开放广播复制（OPN（fr））原语信号，强制循环中的所有NL_端口（自身除外）复制它们在检查FC报头的D_ID字段时接收的帧。b） 然后，源NL_端口在返回时删除OPN（fr）信号。c） 然后，源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 which 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
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 LIP in a loop topology [FC-AL-2] or after 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 LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS each N_Port must again perform a Port Login [FC-FS].
LR后无需验证。在点到点拓扑中，NOS/OLS导致每个N_端口隐式注销，在NOS/OLS之后，每个N_端口必须再次执行端口登录[FC-FS]。
After a LIP [FC-AL-2], an NL_Port must not transmit any data to another NL_Port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC [FC-FS].
在LIP[FC-AL-2]之后，NL_端口不得将任何数据传输到另一个NL_端口，直到验证另一个端口的地址。验证包括完成ADISC或PDISC[FC-FS]。
For a requester, this specification prohibits PDISC and requires ADISC. As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
对于请求者，本规范禁止PDISC，并要求ADISC。作为响应者，实现可能需要同时响应ADISC和PDISC，以便与其他FC规范兼容。
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 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.
公共环路NL_端口必须按照第B.3节的规定，对本地环路上具有0x00-00-XX形式的N_端口ID的任何NL_端口执行专用环路验证。
No validation is required after LR (link reset).
LR（链路重置）后无需验证。
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same as before the NOS/OLS, then the N_Port may resume all Exchanges. If not, all logged in Nx_Ports must be logged out [FC-FS].
NOS/OLS之后，N_端口必须执行FLOGI。如果在FLOGI之后，N_端口的N_端口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 21 is cut and pasted at the top of the figures present in this document.
如果图21中所示的数据结构标题被剪切并粘贴在本文档中所示图的顶部，则可以观察到光纤通道位编号。
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
图21：光纤通道位编号
Author's Address
作者地址
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。