diff options
Diffstat (limited to 'doc/rfc/rfc4338.txt')
| -rw-r--r-- | doc/rfc/rfc4338.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc4338.txt b/doc/rfc/rfc4338.txt new file mode 100644 index 0000000..51a5e3d --- /dev/null +++ b/doc/rfc/rfc4338.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group C. DeSanti +Request for Comments: 4338 Cisco Systems +Obsoletes: 3831, 2625 C. Carlson +Category: Standards Track QLogic Corporation + R. Nixon + Emulex + January 2006 + + + Transmission of IPv6, IPv4, and + Address Resolution Protocol (ARP) Packets over Fibre Channel + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies the way of encapsulating IPv6, IPv4, and + Address Resolution Protocol (ARP) packets over Fibre Channel. This + document also specifies the method of forming IPv6 link-local + addresses and statelessly autoconfigured IPv6 addresses on Fibre + Channel networks, and a mechanism to perform IPv4 address resolution + over Fibre Channel networks. + + This document obsoletes RFC 2625 and RFC 3831. + + + + + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 1] + +RFC 4338 IP over Fibre Channel January 2006 + + +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 + + + +DeSanti, et al. Standards Track [Page 2] + +RFC 4338 IP over Fibre Channel January 2006 + + +1. Introduction + + 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]. + + [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]. + + Specific [RFC-2625] limitations that this document aims to resolve + are the following: + + - 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. + + - 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. + + - Missing support for IPv4 multicast. [RFC-2625] does not specify + how to transmit IPv4 packets with a multicast destination address + over Fibre Channel. + + [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]. + + 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. + + 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]. + + + + + + +DeSanti, et al. Standards Track [Page 3] + +RFC 4338 IP over Fibre Channel January 2006 + + +2. Summary of Fibre Channel + +2.1. Overview + + 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. + + 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]. + + 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. + + 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. + + A Fibre Channel network, built with any combination of the FC + topologies described above, is a multiaccess network with broadcast + capabilities. + + From an IPv6 point of view, a Fibre Channel network is an IPv6 Link + [IPv6]. IP-capable Nx_Ports are what [IPv6] calls Interfaces. + + 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. + + + + + + + + + +DeSanti, et al. Standards Track [Page 4] + +RFC 4338 IP over Fibre Channel January 2006 + + +2.2. Identifiers and Login + + 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: + + - an Nx_Port's Name_Identifier is called N_Port_Name; + - an Fx_Port's Name_Identifier is called F_Port_Name; + - a Node's Name_Identifier is called Node_Name; + - a Fabric's Name_Identifier is called Fabric_Name. + + An Nx_Port connected to a Fibre Channel network is associated with + two identifiers, its non-volatile N_Port_Name and a volatile 24-bit + address called N_Port_ID. The N_Port_Name is used to identify the + Nx_Port, and the N_Port_ID is used for communications among Nx_Ports. + + 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. + + 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. + + 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). + +2.3. FC Levels and Frame Format + + [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. + + + + + +DeSanti, et al. Standards Track [Page 5] + +RFC 4338 IP over Fibre Channel January 2006 + + + +-----+-----------+-----------+--------//-------+-----+-----+ + | | | Data Field | | | + | SOF | FC Header |<--------------------------->| CRC | EOF | + | | | Optional | Frame | | | + | | | Header(s) | Payload | | | + +-----+-----------+-----------+--------//-------+-----+-----+ + + Figure 1: Fibre Channel Frame Format + + 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. + + The FC Header is 24 octets long and contains several fields + associated with the identification and control of the Data Field. + + 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: + + - ESP_Header; + - Network_Header; + - Association_Header; + - Device_Header. + + The value of the SOF field determines the FC Class of service + associated with the frame. Five Classes of service are specified in + [FC-FS]. They are distinguished primarily by the method of flow + control between the communicating Nx_Ports and by the level of data + integrity provided. A given Fabric or Nx_Port may support one or + more of the following Classes of service: + + - Class 1: Dedicated physical connection with delivery confirmation; + - Class 2: Frame multiplexed service with delivery confirmation; + - Class 3: Datagram service; + - Class 4: Fractional bandwidth; + - Class 6: Reliable multicast via dedicated connections. + + Classes 3 and 2 are commonly used for storage networking + applications; Classes 1 and 6 are typically used for specialized + applications in avionics. Class 3 is recommended for IPv6, IPv4, and + ARP (see section 4.3). + +2.4. Sequences and Exchanges + + 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 + + + +DeSanti, et al. Standards Track [Page 6] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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. + + 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. + + 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. + +3. IP-capable Nx_Ports + + This specification requires an IP-capable Nx_Port to have the + following properties: + + - 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). + +4. IPv6, IPv4, and ARP Encapsulation + +4.1. FC Sequence Format for IPv6 and IPv4 Packets + + 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. + + + +DeSanti, et al. Standards Track [Page 7] + +RFC 4338 IP over Fibre Channel January 2006 + + + +---------------+---------------+---------------+---------------+ + | | + +- -+ + | Network_Header | + +- (16 octets) -+ + | | + +- -+ + | | + +---------------+---------------+---------------+---------------+ + | LLC/SNAP header | + +- (8 octets) -+ + | | + +---------------+---------------+---------------+---------------+ + | | + +- -+ + / IPv6 or IPv4 Packet / + / / + +- -+ + | | + +---------------+---------------+---------------+---------------+ + + Figure 2: FC Information Unit Mapping an IP Packet + + 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). + + 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. + + 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. + + First Frame of an IP FC Sequence + +-----------+-------------------+-----------------+-------//--------+ + | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | + | | | | the IP Packet | + +-----------+-------------------+-----------------+-------//--------+ + + Subsequent Frames of an IP FC Sequence + +-----------+-----------------//--------------------+ + | FC Header | Additional chunk of the IP Packet | + +-----------+----------------//---------------------+ + + Figure 3: Optional Headers in an IP FC Sequence + + + +DeSanti, et al. Standards Track [Page 8] + +RFC 4338 IP over Fibre Channel January 2006 + + +4.2. FC Sequence Format for ARP Packets + + 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. + + +---------------+---------------+---------------+---------------+ + | | + +- -+ + | Network_Header | + +- (16 octets) -+ + | | + +- -+ + | | + +---------------+---------------+---------------+---------------+ + | LLC/SNAP header | + +- (8 octets) -+ + | | + +---------------+---------------+---------------+---------------+ + | | + +- -+ + / ARP Packet / + / / + +- -+ + | | + +---------------+---------------+---------------+---------------+ + + Figure 4: FC Information Unit Mapping an ARP Packet + + 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. + + 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. + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 9] + +RFC 4338 IP over Fibre Channel January 2006 + + +4.3. FC Classes of Service + + This specification uses FC Class 3. The following types of packets + MUST be mapped in Class 3 FC frames: + + - multicast IPv6 packets; + - multicast/broadcast IPv4 packets; + - Control Protocol packets (e.g., ARP packets; IPv6 packets carrying + ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener + Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or + IGMP [IGMPv3] messages; IPv6 and IPv4 Routing Protocols packets). + + Other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data + traffic) SHOULD be mapped in Class 3 FC frames as well. Support for + reception of IPv4 or IPv6 packets mapped in FC frames of any Class + other than Class 3 is OPTIONAL; receivers MAY ignore them. + +4.4. FC Header Code Points + + 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. + + 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 + + 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: + + - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information + Category [FC-FS]); + - TYPE: 0x05 (IP over Fibre Channel); + + + +DeSanti, et al. Standards Track [Page 10] + +RFC 4338 IP over Fibre Channel January 2006 + + + - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; + - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or + IPv4 Sequence, 0x00 for the following FC frames. If the FC + ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or + IPv4 Sequence, 0x40 for the following FC frames; + - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12, + and [FC-FS] for additional requirements; + - Parameter: if Relative Offset [FC-FS] is not used, the content of + this field MUST be ignored by the receiver, and SHOULD be set to + zero by the sender. If Relative Offset is used, see [FC-FS]. + + To encapsulate ARP over Fibre Channel, the following code points + apply. When a single value is listed without further qualification, + that value MUST be used: + + - 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. + +4.5. FC Network_Header + + 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]. + + 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 + + + + + + + +DeSanti, et al. Standards Track [Page 11] + +RFC 4338 IP over Fibre Channel January 2006 + + +4.6. LLC/SNAP Header + + The fields of the LLC/SNAP header [IEEE-LLC] are shown in figure 7. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DSAP | SSAP | CTRL | OUI | + +---------------+---------------+---------------+---------------+ + | OUI | PID | + +---------------+---------------+---------------+---------------+ + + Figure 7: LLC/SNAP Header Format + + To encapsulate IPv6, IPv4, and ARP over Fibre Channel, the following + code points MUST be used: + + - DSAP: 0xAA; + - SSAP: 0xAA; + - CTRL: 0x03; + - OUI: 0x000000; + - PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP. + +4.7. Bit and Byte Ordering + + 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. + +4.8. Maximum Transfer Unit + + 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. + + 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. + + + + + +DeSanti, et al. Standards Track [Page 12] + +RFC 4338 IP over Fibre Channel January 2006 + + + For correct operation of IPv6 in a routed environment, it is + critically important to configure an appropriate MTU option in Router + Advertisements. + + 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. + + 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]. + +5. IPv6 Stateless Address Autoconfiguration + +5.1. IPv6 Interface Identifier and Address Prefix + + 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. + + [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. + + 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. + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 13] + +RFC 4338 IP over Fibre Channel January 2006 + + +5.2. Generating an Interface ID from a Format 1 N_Port_Name + + The Name_Identifier format 0x1 is shown in figure 8. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1| 0x000 | OUI | + +-------+-------+---------------+---------------+---------------+ + | OUI | VSID | + +---------------+---------------+---------------+---------------+ + + Figure 8: Format 0x1 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + shown in figure 9 [FC-FS]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 0 0 1| VSID | + +---------------+---------------+-------+-------+-------+-------+ + | VSID | 0x000 | + +---------------+---------------+-------+-------+---------------+ + + Figure 9: EUI-64 Address from a Format 0x1 Name_Identifier + + 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. + + 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 + + As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF + generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. + + + + + + +DeSanti, et al. Standards Track [Page 14] + +RFC 4338 IP over Fibre Channel January 2006 + + +5.3. Generating an Interface ID from a Format 2 N_Port_Name + + The Name_Identifier format 0x2 is shown in figure 11. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 0| Vendor Specific | OUI | + +-------+-------+---------------+---------------+---------------+ + | OUI | VSID | + +---------------+---------------+---------------+---------------+ + + Figure 11: Format 0x2 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + shown in figure 12 [FC-FS]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 0 1 0| VSID | + +---------------+-----------------------+-------+-------+-------+ + | VSID | Vendor Specific | + +---------------+-----------------------+-------+---------------+ + + Figure 12: EUI-64 Address from a Format 0x2 Name_Identifier + + 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. + + 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 + + As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF + generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. + + + + + + +DeSanti, et al. Standards Track [Page 15] + +RFC 4338 IP over Fibre Channel January 2006 + + +5.4. Generating an Interface ID from a Format 5 N_Port_Name + + The Name_Identifier format 0x5 is shown in figure 14. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 0 1| OUI | VSID | + +-------+-------+---------------+---------------+-------+-------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Figure 14: Format 0x5 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + shown in figure 15 [FC-FS]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 1 0 1| VSID | + +---------------+---------------+---------------+-------+-------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Figure 15: EUI-64 Address from a Format 0x5 Name_Identifier + + 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. + + 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 + + As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 + generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. + + + + + + +DeSanti, et al. Standards Track [Page 16] + +RFC 4338 IP over Fibre Channel January 2006 + + +5.5. Generating an Interface ID from an EUI-64 Mapped N_Port_Name + + 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. + + 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 + + The EUI-64 address used to generate the Name_Identifier shown in + figure 17 has the format shown in figure 18. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI[0..5] |0 0| OUI[8..23] | VSID | + +-----------+---+---------------+---------------+---------------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Figure 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier + + 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. + + 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 + + + + +DeSanti, et al. Standards Track [Page 17] + +RFC 4338 IP over Fibre Channel January 2006 + + + As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A + generates the IPv6 Interface Identifier 3663:46AB:0125:789A. + +6. Link-local Addresses + + 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. + + 10 bits 54 bits 64 bits + +----------+-----------------------+----------------------------+ + |1111111010| (zeros) | Interface Identifier | + +----------+-----------------------+----------------------------+ + + Figure 20: IPv6 Link-local Address Format + +7. ARP Packet Format + + 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. + + [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. + + 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. + + 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. + + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 18] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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 + + The following code points MUST be used with 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. + + + + + + + + + +DeSanti, et al. Standards Track [Page 19] + +RFC 4338 IP over Fibre Channel January 2006 + + +8. Link-layer Address/Hardware Address + + 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. + + 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 + + Reserved fields MUST be set to zero when transmitting, and MUST be + ignored when receiving. + +9. Address Mapping for Unicast + +9.1. Overview + + An Nx_Port has two kinds of Fibre Channel addresses: + + - a non-volatile 64-bit address, called N_Port_Name; + - a volatile 24-bit address, called 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). + +9.2. IPv6 Address Mapping + + 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. + + + + + + + + +DeSanti, et al. Standards Track [Page 20] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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 + + Type: 1 for Source Link-layer address. + 2 for Target Link-layer address. + + Length: 2 (in units of 8 octets). + + 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). + +9.3. IPv4 Address Mapping + + 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: + + 1) The source Nx_Port first consults its local mapping tables for a + mapping <destination IPv4 address, N_Port_Name, N_Port_ID>. + + 2) If such a mapping is found, and a valid Port Login is in place + with the destination Nx_Port, then the source Nx_Port sends the + IPv4 packets to the destination Nx_Port using the retrieved + N_Port_ID as D_ID. + + 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. + + + + + + +DeSanti, et al. Standards Track [Page 21] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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. + + 5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP + Reply is returned. + +10. Address Mapping for Multicast + + 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: + + - for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF; + - for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, where + XX-YY-ZZ-QQ are the 4 least significant octets of the multicast + destination IPv6 address; + - for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, where the + 23 least significant bits of XX-YY-ZZ are the 23 least significant + bits of the multicast destination IPv4 address and the most + significant bit of XX-YY-ZZ is set to zero. + + An Nx_Port supporting IPv6 or IPv4 MUST be able to map a received + broadcast Class 3 Device_Data FC frame to an implicit Port Login + context in order to handle IPv6 multicast packets, IPv4 multicast or + broadcast packets, and ARP broadcast packets. The receive data field + size of this implicit Port Login MUST be the same across all the + Nx_Ports connected to the same Fabric, otherwise FC broadcast + transmission does not work. In order to reduce the need for FC + Sequence segmentation, the receive data field size of this implicit + Port Login SHOULD be 1024 octets. This receive data field size + requirement applies to broadcast Device_Data FC frames, not to ELSes. + + 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 + + + +DeSanti, et al. Standards Track [Page 22] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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. + + 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. + +11. Sequence Management + + 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]. + +12. Exchange Management + + 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. + + 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 + + + +DeSanti, et al. Standards Track [Page 23] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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). + + 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]. + +13. Interoperability with RFC 2625 + + 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. + + 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]. + + 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. + + + +DeSanti, et al. Standards Track [Page 24] + +RFC 4338 IP over Fibre Channel January 2006 + + + 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: + + - When IPv4 address resolution is attempted, the Nx_Port MUST send + two ARP Requests, the first one according to the FC ARP format and + the second one according to the Ethernet ARP format. If only an + Ethernet ARP Reply is received, it provides the N_Port_Name of the + Nx_Port having the destination IPv4 address. The N_Port_ID + associated with the N_Port_Name received in an Ethernet ARP Reply + may be retrieved from the S_ID field of the received ARP Reply, or + by querying the Fibre Channel Name Server; + - The Nx_Port MUST respond to a received Ethernet ARP Request with + an Ethernet ARP Reply; + - The Nx_Port MAY respond to FARP Requests [RFC-2625]. + + The reception of a particular format of ARP message does not imply + that the sending Nx_Port will continue to use the same format later. + + Support of compatibility mode is REQUIRED by each implementation. + The use of compatibility mode MUST be administratively configurable. + +14. Security Considerations + + 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. + +15. IANA Considerations + + The directory of ARP parameters has been updated to reference this + document for hardware type 18. + +16. Acknowledgements + + 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. + + + + +DeSanti, et al. Standards Track [Page 25] + +RFC 4338 IP over Fibre Channel January 2006 + + +17. Normative References + + [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and + Signaling (FC-FS)". + + [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 + (FC-AL-2)". + + [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [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. + + [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and + Metropolitan Area Networks: Overview and Architecture". + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +18. Informative References + + [RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre + Channel", RFC 3831, July 2004. + + [RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP + over Fibre Channel", RFC 2625, June 1999. + + [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + + +DeSanti, et al. Standards Track [Page 26] + +RFC 4338 IP over Fibre Channel January 2006 + + + [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [PMTUD4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [ICMPv6] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. + + [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64) + Registration Authority", + http://standards.ieee.org/regauth/oui/tutorials/ + EUI64.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 27] + +RFC 4338 IP over Fibre Channel January 2006 + + +A. Transmission of a Broadcast FC Sequence over FC Topologies + (Informative) + +A.1. Point-to-Point Topology + + 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. + +A.2. Private Loop Topology + + 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]. + + 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. + + 2) The source NL_Port then removes the OPN(fr) signal when it returns + to it. + + 3) The source NL_Port then sends the Class 3 broadcast FC Sequence + having D_ID 0xFFFFFF. + +A.3. Public Loop Topology + + 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]. + + 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. + + Each FL_Port propagates the broadcast by using the primitive signal + OPN(fr), in order to prepare the loop to receive the broadcast + sequence. + +A.4. Fabric Topology + + 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]. + + + + + +DeSanti, et al. Standards Track [Page 28] + +RFC 4338 IP over Fibre Channel January 2006 + + +B. Validation of the <N_Port_Name, N_Port_ID> Mapping + (Informative) + +B.1. Overview + + At all times, the <N_Port_Name, N_Port_ID> mapping must be valid + before use. + + 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]. + + N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS]; + thus, address validation is not required in this case. + +B.2. FC Layer Address Validation in a Point-to-Point Topology + + 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]. + +B.3. FC Layer Address Validation in a Private Loop Topology + + 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]. + + 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. + + If any of the three FC addresses has changed, then the remote NL_Port + must be logged out. + + If an NL_Port's N_Port_ID changes after a LIP, then all active + logged-in NL_Ports must be logged out. + + + + + + + + + + +DeSanti, et al. Standards Track [Page 29] + +RFC 4338 IP over Fibre Channel January 2006 + + +B.4. FC Layer Address Validation in a Public Loop Topology + + 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. + + 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. + + 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). + +B.5. FC Layer Address Validation in a Fabric Topology + + No validation is required after 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]. + +C. Fibre Channel Bit and Byte Numbering Guidance + + Both Fibre Channel and IETF standards use the same byte transmission + order. However, the bit numbering is different. + + 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. + + 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 + + + + + + + + + + +DeSanti, et al. Standards Track [Page 30] + +RFC 4338 IP over Fibre Channel January 2006 + + +D. Changes from 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. + +E. Changes from 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. + + + + + + + + + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 31] + +RFC 4338 IP over Fibre Channel January 2006 + + +Authors' Addresses + + Claudio DeSanti + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA + + Phone: +1 408 853-9172 + EMail: cds@cisco.com + + + Craig W. Carlson + QLogic Corporation + 6321 Bury Drive + Eden Prairie, MN 55346 + USA + + Phone: +1 952 932-4064 + EMail: craig.carlson@qlogic.com + + + Robert Nixon + Emulex + 3333 Susan Street + Costa Mesa, CA 92626 + USA + + Phone: +1 714 885-3525 + EMail: bob.nixon@emulex.com + + + + + + + + + + + + + + + + + + + + + +DeSanti, et al. Standards Track [Page 32] + +RFC 4338 IP over Fibre Channel January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +DeSanti, et al. Standards Track [Page 33] + |