RFC 4338
Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
RFC 4338 🎀 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
okay bestie, this is part 1 of 7 of RFC 4338, so grab a drink 🧋 and get comfy. Here's the title block so you know who's behind it:
- Series: Network Working Group, Request for Comments: 4338
- Authors: C. DeSanti (Cisco Systems), C. Carlson (QLogic Corporation), R. Nixon (Emulex)
- Category: Standards Track
- Date: January 2006
- Obsoletes: 3831, 2625 (that's RFC 3831 and RFC 2625 💅)
Status of This Memo
okay so the Status section is basically the "read this first" bit 📜 This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the official standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed with no limits, which is iconic of it 🌈
Copyright Notice
Copyright (C) The Internet Society (2006). ✨
Abstract
the abstract is the main character summary 💜 This document explains how to wrap up IPv6, IPv4, and Address Resolution Protocol (ARP) packets so they can travel over Fibre Channel 🦋 It also covers how to form IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, plus a way to do IPv4 address resolution over Fibre Channel networks 🔥
This document obsoletes RFC 2625 and RFC 3831, so those two are officially retired 💀
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 ..........................................311. 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, but only for a subset of Fibre Channel devices 😬 This spec gives IPv4 support to a much broader category of Fibre Channel devices. It also glow-ups [RFC-2625] by removing unused options and clarifying what current implementations actually do 💅 This document obsoletes [RFC-2625].
Here are the specific [RFC-2625] limitations this document is trying to fix:
- N_Port_Name format restriction. [RFC-2625] only lets IPv4 run on Fibre Channel devices with the format
0x1 N_Port_Name, but lots of current implementations use other N_Port_Name formats 🙄 - Use of Fibre Channel Address Resolution Protocol (FARP). [RFC-2625] requires support for 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] doesn't specify how to transmit IPv4 packets with a multicast destination address over Fibre Channel 💀
[RFC-3831] defines how to encapsulate IPv6 over Fibre Channel, plus a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured IPv6 addresses on Fibre Channel networks 🦋 It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when those messages are transmitted on a Fibre Channel network. This document obsoletes [RFC-3831].
⚠️ Warning to readers who already know 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]. these are the rule words, so pay attention 🌈
2. Summary of Fibre Channel 🌸
2.1. Overview
Fibre Channel (FC) is a gigabit-speed network technology that's mainly used for storage networking 💾 It's standardized by the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), which is an American National Standard Institute (ANSI) accredited standards committee. Very official, very serious, very iconic 👑
Fibre Channel devices are called Nodes. Each Node has one or more Ports that connect to Ports on other devices. Fibre Channel can be implemented using any combination of these 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 mean a Node Port that can operate 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 mean a Fabric Port that can operate in either mode 💜
A Fibre Channel network, built with any combination of the FC topologies 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 ✨
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 tells you the format of a Name_Identifier 🔍 These Name_Identifiers get shortened to the following names:
- 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 gets an N_Port_ID from the Fabric by performing a process called Fabric Login, or FLOGI. FLOGI is also used to negotiate several communication parameters between the Nx_Port and the Fabric, such as the receive data field size. That setting decides the maximum size of the Fibre Channel frames that may be transferred between the Nx_Port and the Fabric 🧚
Before effective communication can happen between two Nx_Ports, they must complete a process called Port Login, or PLOGI. PLOGI gives each Nx_Port the other Nx_Port's N_Port_Name, and it negotiates several communication parameters, such as the receive data field size. That one decides 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 (meaning they're done with specific FC control messages called Extended Link Services, or ELSes) or implicit (meaning the parameters are specified by configuration or other methods). Literally two ways to get the job done, and both are valid 💅✨
2.3. FC Levels and Frame Format 🎀
okay so [FC-FS] breaks the Fibre Channel protocol into 5 levels 🧚. Only FC-2 and FC-4 matter for this spec. FC-2 is where the frame format, transport services, and control functions for moving information live 💅. FC-4 supports Upper Level Protocols like IPv6, IPv4, and SCSI. Here's what the frame format looks like:
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+Figure 1: Fibre Channel Frame Format
SOF and EOF are special FC transmission words that act as frame delimiters 🫶. The CRC is 4 octets long and is used to check that a frame arrived intact 🔥.
The FC Header is 24 octets long and holds fields for identifying and controlling the Data Field 💖.
The Data Field can be anywhere from 0 to 2112 octets, and it holds the user data in the Frame Payload field plus any Optional Headers. These are the Optional Headers defined right now:
- ESP_Header;
- Network_Header;
- Association_Header;
- Device_Header.
The SOF value tells you which FC Class of service the frame belongs to. [FC-FS] specifies five Classes. They mostly differ in how flow control works between the communicating Nx_Ports, and in how much data integrity they give you 👑. A given Fabric or Nx_Port may support one or more of these Classes:
- 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 the ones you'll usually see in storage networking 💾. Classes 1 and 6 are typically used for specialized avionics stuff ✈️. Class 3 is recommended for IPv6, IPv4, and ARP (see section 4.3) 🌸.
2.4. Sequences and Exchanges 🦋
An application-level payload like an IPv6 or IPv4 packet is called an Information Unit at the FC-4 level. FC-2 maps each FC-4 Information Unit to an FC Sequence. An FC Sequence is one or more FC frames that share the same value in the Sequence_ID (SEQ_ID) field of the FC Header 🧠.
The architectural maximum data an FC frame can carry is 2112 octets. The actual maximum usable frame size depends on the Fabric and Nx_Port implementations, and it gets negotiated during the Login process 🤝. Whenever an Information Unit is bigger than that, FC-2 chops it into multiple FC frames, all sent as one Sequence ✂️. The receiving Nx_Port puts the Sequence back together and hands the reassembled Information Unit up to FC-4. The Sequence Count (SEQ_CNT) field of the FC Header may be used to keep frames in order 📋.
Multiple Sequences can be grouped together as part of the same FC Exchange. The Exchange is how two Nx_Ports keep track of an operation between them 🫧. It opens when the operation starts between the two Nx_Ports and closes when the operation ends. FC frames in the same Exchange share the same value in the Exchange_ID fields of the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) together uniquely identify the Exchange between a pair of Nx_Ports 💜.
3. IP-capable Nx_Ports ⭐
This specification says an IP-capable Nx_Port has to have these 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 gets mapped to an Information Unit at FC-4, and FC-2 then maps that to an FC Sequence [FC-FS]. An FC Information Unit carrying an IP packet MUST include the FC Network_Header [FC-FS] and the Logical Link Control/SubNetwork Access Protocol (LLC/SNAP) header [IEEE-LLC]. The result looks like figure 2 👀.
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 or IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+Figure 2: FC Information Unit Mapping an IP Packet
Here's the bit about the minimum IPv6 MTU, which is 1280 octets. To support it, an Nx_Port that supports IP MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long. That's 1280 + 8 + 16 🧮.
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames that make up an IP FC Sequence 🔐. Other FC Optional Headers MUST NOT be used in an IP FC Sequence.
An IP FC Sequence often has more than one frame, and all of them have 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 figure 3 shows 🎀.
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
4.2. FC Sequence Format for ARP Packets 🦋
An ARP packet gets mapped to an Information Unit at FC-4, and FC-2 maps that to an FC Sequence. An FC Information Unit carrying an ARP packet MUST include the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC]. Here's figure 4 📦.
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+Figure 4: FC Information Unit Mapping an ARP Packet
ARP packets are small (see section 7), so an FC Sequence carrying one MUST map to a single FC frame. That frame 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 🙈.
4.3. FC Classes of Service 👑
This spec uses FC Class 3. These 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, meaning unicast IP packets carrying data traffic, SHOULD be mapped in Class 3 FC frames as well 🚀. Supporting 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 🎀
okay so the Fibre Channel Header has a bunch of fields, and figure 5 lines them all up 💅 The D_ID and S_ID fields hold the destination N_Port_ID and the source N_Port_ID, in that order 🦋
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 Formatso to encapsulate IPv6 and IPv4 over Fibre Channel, these code points apply 🌈 When a single value is listed with no extra 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:0x00is the default, see [FC-FS] for other values;DF_CTL:0x20(Network_Header) for the first FC frame of an IPv6 or IPv4 Sequence,0x00for the following FC frames. If the FC ESP_Header is used, then0x60for the first FC frame of an IPv6 or IPv4 Sequence,0x40for 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].
now for ARP over Fibre Channel 🧚 The same idea applies here, and when a single value is listed with no extra 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:0x00is the default, see [FC-FS] for other values;DF_CTL:0x20(Network_Header). If the FC ESP_Header is used, then0x60;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 FC Network_Header is 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 Format4.6. LLC/SNAP Header 💅
the LLC/SNAP header [IEEE-LLC] is 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 Formatto encapsulate IPv6, IPv4, and ARP over Fibre Channel, these code points MUST be used 🫶
DSAP:0xAA;SSAP:0xAA;CTRL:0x03;OUI:0x000000;PID:0x86DDfor IPv6,0x0800for IPv4,0x0806for ARP.
4.7. Bit and Byte Ordering 🍓
IPv6, IPv4, and ARP packets are mapped to the FC-4 level using big-endian byte ordering, which is the standard network byte order, also called canonical form 🧚
4.8. Maximum Transfer Unit 👑
okay the default MTU size for IPv6 packets over Fibre Channel is 65280 octets 💖 Large IPv6 packets get mapped to a Sequence of FC frames (see section 2.4). This size can be reduced by a Router Advertisement [DISC] that has an MTU option specifying a smaller MTU, or by manual configuration of each Nx_Port. Bestie, but 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 💀
the default MTU size is way bigger than the message sizes the Internet usually uses, so an IPv6 over FC implementation SHOULD implement Path MTU Discovery [PMTUD6], or at least keep different MTU values for on-link and off-link destinations 🌈
for correct operation of IPv6 in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements. no cap, this one matters a lot 😭
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 also 65280 octets ✨ Large IPv4 packets get mapped to a Sequence of FC frames (see section 2.4). This size can 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] that gets derived from the Nx_Port's N_Port_Name ✨ The IPv6 Interface Identifier is made by complementing the Universal/Local (U/L) bit of the OUI field in the derived EUI-64 address. The U/L bit does nothing in Fibre Channel, but it has to be handled properly when a Name_Identifier is converted to an EUI-64 address 🧚
[FC-FS] has a method to map format 0x1 (IEEE 48-bit address), 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers into EUI-64 addresses. That means you can use these Name_Identifiers to support IPv6 🫶 [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF) that come from an EUI-64 address. It's possible to reverse this mapping and get the original EUI-64 address back, so IPv6 still works 🔥
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 👑
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_Identifierthe 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_Identifierthe IPv6 Interface Identifier comes 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 the same 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_Identifieras an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000 🎀💖
5.3. Generating an Interface ID from a Format 2 N_Port_Name ✨
Okay bestie, format 0x2 Name_Identifiers get their own glow-up 💅 Here's the layout 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 you get from this Name_Identifier looks like 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
Now the IPv6 Interface Identifier comes from that EUI-64 address by flipping the U/L bit in the OUI field. The OUI in the IPv6 Interface ID is exactly the same as in the FC Name_Identifier, which is so satisfying 🦋 The result has local scope [AARCH] and looks like 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
Here's an example: the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789 ✨
5.4. Generating an Interface ID from a Format 5 N_Port_Name
Format 0x5 is up next 🌸 Here's the Name_Identifier 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 it has the format 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 by complementing the U/L bit in the OUI field. Once again the OUI stays exactly as it is in the FC Name_Identifier. It has local scope [AARCH] and the format 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 💖
5.5. Generating an Interface ID from an EUI-64 Mapped N_Port_Name
The EUI-64 mapped Name_Identifier formats (formats 0xC through 0xF) come from an EUI-64 address that has its OUI field compressed 🙈 To compress it, you remove the Universal/Local and Individual/Group bits from the OUI. Then bits 0 to 5 of the OUI go in the first octet of the Name_Identifier, and bits 8 to 23 of the OUI go in the second and third octets. Figure 17 shows how it all fits together:
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 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 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
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 made by appending the Interface Identifier (as defined in section 5) to the prefix FE80::/64 🦋 The result looks like 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] was designed to be a general purpose protocol, so it can work with lots of network technologies and lots of Upper Layer Protocols 🫶
[RFC-2625] chose to use the same ARP packet format for Fibre Channel that Ethernet networks use. To make that work, [RFC-2625] limited IPv4 to Nx_Ports with N_Port_Name format 0x1. That was probably a reasonable call back then, but today there are Nx_Ports with an N_Port_Name format other than 0x1 in widespread use, and that's a lot of Nx_Ports 💀
This specification welcomes Nx_Ports with N_Port_Names in a format other than 0x1 by defining a Fibre Channel specific version of the ARP protocol (FC ARP). It carries both the N_Port_Name and the N_Port_ID as the Hardware (HW) Address 🌸
IANA has registered the number 18 (decimal) to identify Fibre Channel as an ARP HW type. The FC ARP packet format is shown in figure 21, and the FC ARP packet is 40 octets long 🎀
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:0x0001for ARP Request,0x0002for 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.
8. Link-layer Address/Hardware Address ✨
okay so the Link-layer Address in the Source/Target Link-layer Address option (see section 9.2) and the Hardware Address in FC ARP (see section 7) have the exact same format 💅 check it out:
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 what uniquely identifies the Nx_Port, and the N_Port_ID is what gets frames routed to it 🚚 both FC addresses are required to resolve an IPv6 or IPv4 unicast address. since the N_Port_ID is volatile, an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events happen (see Appendix B). this one is important, bestie 😭
9.2. IPv6 Address Mapping
so mapping IPv6 unicast addresses to Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC] 🧚 the Source/Target Link-layer Address option looks like figure 23 when the link layer is Fibre Channel:
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
here's the breakdown 🎀
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, and MUST be ignored when receiving.Link-layer Address: the Nx_Port's Link-layer Address (see section 8).
9.3. IPv4 Address Mapping
for IPv4 unicast, the mapping goes through FC ARP, which is specified in section 7 and [ARP] 🌸 a source Nx_Port that needs to send IPv4 packets to a destination Nx_Port (known by its IPv4 address) MUST do the following steps:
- the source Nx_Port first checks its local mapping tables for a mapping
<destination IPv4 address, N_Port_Name, N_Port_ID>. - if that mapping is found AND a valid Port Login is already in place with the destination Nx_Port, the source sends the IPv4 packets to the destination using the retrieved
N_Port_IDas the D_ID 🔥 - if the mapping isn't found, OR there's no valid Port Login with the destination Nx_Port, the source sends a broadcast FC ARP Request (see section 10) out to its connected FC network 📡
- when a broadcast FC ARP Request shows up at an Nx_Port with the matching IPv4 address, that Nx_Port caches the info from the request in its local mapping tables and generates a unicast FC ARP Reply. if there's no valid Port Login to the Nx_Port that sent the broadcast request, the Nx_Port MUST perform one, and then use it for the unicast reply. the
N_Port_IDthe Port Login is directed to comes from theN_Port_IDfield of the Sender HW Address field in the received FC ARP packet 🫶 - if no Nx_Port has the matching IPv4 address, no unicast FC ARP Reply gets sent back 🙈
10. Address Mapping for Multicast 🍓
okay so 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. they get sent in FC Class 3 inside a unidirectional Exchange (see section 12) 💜 Appendix A explains how to transmit a Class 3 broadcast FC Sequence over the different Fibre Channel topologies. the Destination N_Port_Name field of the FC Network_Header MUST be set to this 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, whereXX-YY-ZZ-QQare 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 ofXX-YY-ZZare the 23 least significant bits of the multicast destination IPv4 address, and the most significant bit ofXX-YY-ZZis 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. that's how it handles 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 🚨 to cut down on 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 that carries an IPv6 multicast packet, an IPv4 multicast/broadcast packet, or an FC ARP broadcast packet kicks off some extra processing at the Nx_Port, but only when that IPv6, IPv4, or FC ARP packet needs a unicast reply 💅 in that case, if there's no valid Port Login to the Nx_Port that sent the multicast or broadcast packet, the Nx_Port MUST perform one and then use it for the unicast reply. for Neighbor Discovery messages [DISC], the N_Port_ID the Port Login is directed to comes from the N_Port_ID field of the Source Link-layer Address in the received Neighbor Discovery message. for FC ARP messages, it comes from the N_Port_ID field of the Sender HW Address field in the received FC ARP packet.
for example 🧚 if a received broadcast FC Sequence carries an IPv6 multicast unsolicited Router Advertisement [DISC], the receiving Nx_Port just processes it by passing the carried IPv6 packet up to the IPv6 layer. but if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] that needs a unicast reply, and there's no valid Port Login with the Nx_Port sender, then a Port Login MUST be performed so the unicast reply message can go out. and if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] that needs a multicast reply, the reply goes 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]. to avoid missing FC frame aliasing caused 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, and every frame sent 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 send IPv6, IPv4, or ARP packets to another Nx_Port or to a multicast/broadcast address, an Nx_Port MUST use dedicated unidirectional Exchanges. those are Exchanges that are dedicated to IPv6, IPv4, or ARP packet transmission and that don't transfer Sequence Initiative 💖 so 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 (like ARP packets, IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages, and IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD be sent in short-lived unidirectional Exchanges. those are Exchanges with only one Sequence, where both the First_Sequence and Last_Sequence bits in the F_CTL field of the FC Header are set to one [FC-FS] ⚡ unicast FC Sequences carrying other IPv6 and IPv4 packets (unicast IP packets carrying data traffic) MUST be sent in a long-lived unidirectional Exchange, which is 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 (like ARP packets, IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages, and 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 (multicast IP packets carrying data traffic) MAY be sent in long-lived unidirectional Exchanges, which makes multicast distribution more efficient 🌈
reasons to end 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 through the ABTS (Abort Sequence) protocol [FC-FS]. a long-lived Exchange SHOULD NOT be terminated by sending the LOGO ELS, since that may end active Exchanges on other FC-4s [FC-FS] 👑
⚠️ bestie, the LOGO ELS can take down active Exchanges on other FC-4s too, so don't reach for it to close a long-lived Exchange 💀
13. Interoperability with RFC 2625 🎀
okay so the IPv4 encapsulation in this doc, plus Exchange and Sequence management, are all defined the same way as in [RFC-2625] 🌸 that's the vibe we're going for. implementations following this spec are expected to interoperate with [RFC-2625] implementations for IPv4 packet transmission and reception 🫶
the big difference is address resolution 💅 [RFC-2625] uses the Ethernet format of ARP and requires every Nx_Port to have a format 0x1 N_Port_Name. this spec defines a Fibre Channel format for ARP that works with all the commonly used N_Port_Names ✨ and on top of that, this spec does not use FARP [RFC-2625] 🙈
if an Nx_Port follows this spec but doesn't have a format 0x1 N_Port_Name, it can still talk to an [RFC-2625] implementation by manually configuring the mapping <destination IPv4 address, N_Port_Name, N_Port_ID> on the Nx_Ports involved 🦋 with that manual setup, ARP doesn't need to run at all. BUT 💀 IPv4 communication is not possible if the [RFC-2625] implementation strictly enforces the requirement for Nx_Ports to use format 0x1 N_Port_Names. rip
if an Nx_Port follows this spec AND has a format 0x1 N_Port_Name, it can interoperate with an [RFC-2625] implementation in one of two ways: manually configuring the same <destination IPv4 address, N_Port_Name, N_Port_ID> mapping on the Nx_Ports, or doing IPv4 address resolution in compatibility mode, which goes like this 👑
- when IPv4 address resolution is attempted, the Nx_Port MUST send two ARP Requests. the first is in the FC ARP format and the second is in the Ethernet ARP format. if only an Ethernet ARP Reply comes back, it tells you the N_Port_Name of the Nx_Port that has the destination IPv4 address. the N_Port_ID tied to that N_Port_Name can be pulled from the S_ID field of the Ethernet 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] ✨
getting one format of ARP message does NOT mean the sender will keep using that same format later, so don't lock in on it 🌈
support for compatibility mode is REQUIRED for every implementation 🔥 and the use of compatibility mode MUST be administratively configurable. so admins get the final say 😭🫶
14. Security Considerations 🔐
okay this one is serious bestie, so let's be real 🥺 IPv6, IPv4, and ARP don't add any new security concerns beyond the ones that already exist in the Fibre Channel protocols 💀 zoning based on FC Name Server masking (aka soft zoning) does NOT work with IPv6 and IPv4, because IPv6 and IPv4 over Fibre Channel don't use the FC Name Server at all 🙅♀️ if you're counting on that for protection, it won't cover this traffic 😭
to secure the FC frames that make up the FC Sequences carrying IPv6, IPv4, and ARP packets, you can use the FC ESP_Header [FC-FS] 🔒 and any of the techniques made to secure IP traffic at the IP layer can be used in a Fibre Channel environment too 💜
15. IANA Considerations 🌷
the directory of ARP parameters has been updated to reference this document for hardware type 18 ✨
16. Acknowledgements 🫶
the authors want to give a shoutout to the ANSI INCITS T11.3 Task Group members who reviewed this doc, plus the authors of [RFC-2625] and [RFC-3831] 👑 they also thank the IMSS WG and Brian Haberman for their review and comments 💖
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.
[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.htmlA. Transmission of a Broadcast FC Sequence over FC Topologies (Informative) 📡
A.1. Point-to-Point Topology 🔌
no special mechanisms are required in this case 💅 the Nx_Port on the other end of the cable receives the broadcast FC Sequence with 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] 🫶
- the source NL_Port first sends an Open Broadcast Replicate (OPN(fr)) primitive signal. this makes every NL_Port in the loop (except itself) replicate the frames it receives, by checking the D_ID field in the FC Header 🔥
- the source NL_Port then removes the OPN(fr) signal when it gets back to itself 🧚
- the source NL_Port then sends the Class 3 broadcast FC Sequence with D_ID 0xFFFFFF 💖
A.3. Public Loop Topology 🌈
an NL_Port attached to a public loop must not use the OPN(fr) primitive signal 🙅♀️ instead, it must send the Class 3 broadcast FC Sequence with D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 [FC-AL-2] 👑
the Fabric passes the broadcast along to all the other FC_Ports [FC-FS], including the FL_Port the broadcast came in on. that covers all F_Ports and other FL_Ports 🦋
each FL_Port passes the broadcast along using the OPN(fr) primitive signal, so the loop is ready to receive the broadcast Sequence 💜
A.4. Fabric Topology 🌸
an N_Port connected to an F_Port must send the Class 3 broadcast FC Sequence with D_ID 0xFFFFFF to that F_Port 💅 the Fabric then passes the broadcast along to all the other FC_Ports [FC-FS] ✨
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 it's used 💖
after an FC link interruption, the N_Port_ID of an Nx_Port can change, and so can the N_Port_IDs of every other Nx_Port that did Port Login with it before 😭 that's why address validation is required after a Loop Initialization Primitive Sequence (LIP) in a loop topology [FC-AL-2], or after a Not_Operational Primitive Sequence / Offline Primitive Sequence (NOS/OLS) in a point-to-point topology [FC-FS] 🫶
N_Port_IDs do NOT change because of a Link Reset (LR) [FC-FS], so address validation is not required in that 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 an implicit Logout of each N_Port, and after an NOS/OLS each N_Port must perform a Port Login again [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 that port's address has been validated 🙈 the validation means finishing 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-in remote NL_Port exactly match what they were before the LIP, then any active Exchange with that NL_Port can continue ✨
if any of the three FC addresses has changed, 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 😭
B.4. FC Layer Address Validation in a Public Loop Topology 🎡
the Fabric may send a Fabric Address Notification (FAN) ELS to all the previously logged-in NL_Ports after an initialization event 📣 so after a LIP [FC-AL-2], NL_Ports can wait for that notification to show up, or they can do an FLOGI instead 🦋
if the F_Port_Name and Fabric_Name in the FAN ELS or FLOGI response exactly match what they were before the LIP, AND the AL_PA [FC-AL-2] the NL_Port got is the same as before the LIP, then the port can resume all Exchanges 🎉 if not, FLOGI must be performed with the Fabric and all logged-in Nx_Ports must be logged out 🥺
a public loop NL_Port must do the private loop validation from section B.3 with any NL_Port on the local loop that has an N_Port_ID of the form 0x00-00-XX (i.e., 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 all match what they were before the NOS/OLS, then the N_Port can resume all Exchanges 🙌 if not, all logged-in Nx_Ports must be logged out [FC-FS] 💅
C. Fibre Channel Bit and Byte Numbering Guidance (Informative) 🧮
both Fibre Channel and IETF standards send bytes in the same transmission order 🫶 but the bit numbering is different, so keep that in mind 🤓
you can see the Fibre Channel bit numbering if you cut and paste the data structure heading shown in figure 24 to the top of the figures 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 NumberingD. Changes from RFC 2625 ✨
Okay bestie, here's the glow-up list from RFC 2625 🦋
- Nx_Ports with N_Port_Name format
0x2,0x5,0xC,0xD,0xE, and0xFare supported, in addition to format0x1💖 - 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
Next up, the changes from RFC 3831, and yes, it's another round of tidying 💜
- Clarified the usage of the CS_CTL and Parameter fields of the FC Header 🍓
- Clarified the usage of FC Classes of service 🌸
- Clarified and updated the mapping of IPv6 multicast on Fibre Channel 🦋
- Clarified the usage of FC Sequences and Exchanges 🌈
- Clarified and updated the format of the Neighbor Discovery Link-layer option for Fibre Channel ⭐
Authors' Addresses 🎀
Here's who wrote this, with contact info, so you can slide into their inboxes 💌
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.comFull Copyright Statement 🔒
Legal stuff, but it matters, so here it is in full 💜 Copyright first:
Copyright (C) The Internet Society (2006).Then the rights bit, word for word:
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.And the warranty disclaimer, verbatim, because this part is serious 😭
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 🦋
Here's the IP section, complete and unchanged where it counts 🫶 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 🌟
Last but not least, the thank-you note 🎀 Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
📦 where this page comes from
- ietf: rfc4338 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms