RFC 3831
Transmission of IPv6 Packets over Fibre Channel
RFC 3831: Transmission of IPv6 Packets over Fibre Channel 🎀✨
okay bestie, let's get into this one 💅 It's RFC 3831, written by C. DeSanti at Cisco Systems, and it's a Standards Track document from July 2004. Standards Track means it's a real protocol spec the internet community is supposed to implement 🔥. Nothing in the header says it obsoletes or updates any other RFC, so it's a fresh start 🌸.
Status of this Memo 📝
okay so this part is the legal-ish stuff, but the vibe is: this is an Internet standards track protocol 💜 that the internet community is invited to discuss and suggest improvements for. If you want the official standardization state, you check the current edition of "Internet Official Protocol Standards" (STD 1) 🧚. Distribution is unlimited, so share it with everyone 🦋.
Copyright Notice 🌈
Copyright (C) The Internet Society (2004). That's the whole thing, no drama ✨.
Abstract 🫶
so the big idea is that this doc specifies how to wrap IPv6 packets up inside Fibre Channel frames 📦, and also how to build IPv6 link-local addresses and statelessly autoconfigured addresses on FC networks 🌸. It's literally the blueprint for running IPv6 over FC, periodt 💅.
Table Of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 241. Introduction 🦋
okay so Fibre Channel (FC) is a high speed serial interface tech that runs several Upper Layer Protocols, including SCSI and IPv4 🔥 (see [IPFC]).
this doc is all about encapsulating IP version 6 [IPv6] over Fibre Channel 📦, and describing how to form IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on FC networks 💖. It also describes what goes in the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when those messages travel over FC 🫶.
⚠️ bestie, warning for anyone who already knows Fibre Channel: both FC and IETF standards send bytes in the same order, but the bit numbering is different 💀. Check Appendix C for the details 🙈.
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] 🎀.
2. Summary of Fibre Channel 📚
2.1. Overview 🌸
okay so Fibre Channel (FC) is a gigabit speed network tech 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 🫶.
Fibre Channel devices are called Nodes, and each Node has one or more Ports that connect to Ports on other devices 🧚. FC can use 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 is more precisely called an N_Port 💖. A Node Port that can run in a loop topology using the loop specific protocols is designated as an NL_Port 🦋. The term Nx_Port is the generic way to refer to either of these kinds of Node Port 💅.
A Fabric Port is more precisely called an F_Port 🌈. A Fabric Port that can run in a loop topology using the loop specific protocols is designated as an FL_Port 💜. The term Fx_Port generically covers both of these kinds of Fabric Port ✨.
From an IPv6 point of view, an FC network built from any combination of the topologies above is an IPv6 Link [IPv6] 🔥. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces 👑.
2.2. Identifiers and Login 🪪
okay so Fibre Channel entities are identified by permanent 64 bit long Name_Identifiers 💖. [FC-FS] defines several formats of Name_Identifiers, and the value of the first four bits tells you which format a given one uses 🎀. Here's the more precise naming:
- 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 an FC network has two identifiers: its permanent N_Port_Name and a volatile 24 bit address called N_Port_ID 🌸. The N_Port_Name identifies the Nx_Port, and the N_Port_ID is used for communication among Nx_Ports 🧚.
Each Nx_Port gets an N_Port_ID from the Fabric by doing a process called Fabric Login or FLOGI 🦋. FLOGI also negotiates communication parameters between the Nx_Port and the Fabric, like the receive data field size, which sets the maximum size of FC frames that can be transferred between them 📦.
Before any 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 one's N_Port_Name, and negotiates communication parameters such as the receive data field size, which sets the maximum size of FC frames that can be transferred between the two Nx_Ports 💅.
Both Fabric Login and Port Login can be explicit, meaning they use specific FC control messages (called Extended Link Services or ELS), or implicit, where the parameters are set 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 the ones that matter for this spec ✨. FC-2 defines the FC frame format, the transport services, and the control functions needed for information transfer 🫶. FC-4 supports Upper Level Protocols like IPv4, IPv6 or SCSI 🔥. The frame format is shown in figure 1 👑.
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame FormatThe Start of Frame (SOF) and End of Frame (EOF) are special FC transmission words that work as frame delimiters 🧚. The CRC is 4 octets long and uses the same 32-bit polynomial as FDDI 🌸.
The FC Header is 24 octets long and holds several fields for identifying and controlling the Data Field 💖.
The Data Field is variable in size, from 0 to 2112 octets, and includes the user data in the Frame Payload field plus any Optional Headers 🦋. The currently defined Optional Headers are:
- ESP_Header;
- Network_Header;
- Association_Header;
- Device_Header.
The value of the SOF field determines the FC Class of service for the frame 🎀. Five Classes of service are specified in [FC-FS] 💅. They're mainly told apart by how flow control works between the communicating Nx_Ports and by how much data integrity they provide. A given Fabric or Nx_Port may support one or more of these 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.
okay that's part 1 done, bestie 🎀💜 Part 2 is coming next, so stay tuned 🫶✨
2.4. Sequences and Exchanges 💌
okay so bestie, an application-level payload like IPv6 is called an Information Unit at the FC-4 level of Fibre Channel 🎀. Then the FC-2 level maps each FC-4 Information Unit to an FC Sequence 💅. A Sequence is made of one or more FC frames that share the same value in the SEQ_ID field of the FC Header 🦋.
The max data an FC frame can carry is 2112 octets 🌸. The max 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 frames, all sent as one Sequence ✂️. The receiving Nx_Port stitches the frames back together and hands the full Information Unit up to FC-4 🧩. The 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 identify and manage an operation between them. It opens when the operation starts between the two Nx_Ports and closes when the operation ends 🚪. Frames in the same Exchange are linked by the Exchange_ID fields in the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) together uniquely identify the Exchange 🔑.
3. IPv6 Capable Nx_Ports ✨
this spec says an IPv6 capable Nx_Port has to have these properties, no exceptions 🙈
- The format of its
N_Port_NameMUST be one of0x1,0x2,0x5,0xC,0xD,0xE,0xF(see section 6.1). IPv6 support for other Name_Identifier formats is outside the scope of this specification. - It MUST support Class 3.
- It MUST support continuously increasing
SEQ_CNT[FC-FS]. - It MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long.
- It SHOULD support a receive data field size for Device_Data FC frames of at least 1024 octets.
4. IPv6 Encapsulation 🧚
4.1. FC Sequence Format 🌈
an IPv6 packet gets mapped to an Information Unit at the FC-4 level, and then FC-2 maps that to an FC Sequence 🦋. An FC Information Unit carrying an IPv6 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC]. That gives you the FC Information Unit format shown in figure 2 💖.
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 PacketThe FC ESP_Header [FC-FS] MAY be used to secure the FC frames that make up the FC Sequence. [AH] or [ESP] may be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence 🔐.
Typically, a Sequence has more than one frame 🎀. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/SNAP header. The other frames MUST NOT include them, as shown in figure 3 ✨.
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence4.2. FC Classes of Service 🌸
this spec uses FC Class 3 🫶. IPv6 packets carrying Neighbor Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. Other IPv6 packets SHOULD use Class 3 as well. Using any other Classes of service is outside the scope of this specification 🙅♀️.
4.3. FC Header Code Points 💜
the fields of the Fibre Channel Header are shown in figure 4 👑. The D_ID and S_ID fields hold the destination N_Port_ID and the source N_Port_ID, respectively. To encapsulate IPv6 over Fibre Channel, the following code points 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:0x0DF_CTL:0x20(Network_Header) for the first FC frame of an IPv6 Sequence,0x00for the following FC frames. If the FCESP_Headeris used, then0x60for the first FC frame of an IPv6 Sequence,0x40for the following FC frames.F_CTL,SEQ_ID,SEQ_CNT,OX_ID,RX_ID, Parameter: see section 10, section 11, and [FC-FS] for additional requirements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format4.4. FC Network_Header 🦋
the fields of the FC Network_Header are shown in figure 5 🧩. For use with IPv6, the N_Port_Name formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 5: FC Network_Header Format4.5. LLC/SNAP Header 🌷
the fields of the LLC/SNAP Header [IEEE-LLC] are shown in figure 6 💅. To encapsulate IPv6 over Fibre Channel, the following code points MUST be used:
- DSAP:
0xAA - SSAP:
0xAA - CTRL:
0x03 - OUI:
0x00-00-00 - PID:
0x86-DD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format4.6. Bit and Byte Ordering 🎀
IPv6 packets are mapped to the FC-4 level using the big-endian byte ordering that matches the standard network byte order, or canonical form 🫶.
5. Maximum Transfer Unit 📏
the default MTU size for IPv6 [IPv6] packets over Fibre Channel is 65280 octets 💖. 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. 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 is way bigger than the message sizes most of the Internet uses, so an IPv6 over FC implementation SHOULD implement Path MTU Discovery [PMTUD], or at least maintain different MTU values for on-link and off-link destinations 🌈.
For correct operation in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements. ⚠️
For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node that is connected to a medium with a default MTU larger than the smallest MTU 🍓.
6. Stateless Address Autoconfiguration 🧚♀️
6.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 bit of the OUI field of the derived EUI-64 address 🦋.
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in EUI-64 addresses. This lets you use these Name_Identifiers to support IPv6 🌸. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), which are derived from an EUI-64 address. It's possible to reverse this address mapping to get the original EUI-64 address in order to support 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 ✨.
6.2. Generating an Interface ID from a Format 1 N_Port_Name 🎀
okay bestie, so the Name_Identifier format 0x1 looks like this 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifierthe EUI-64 address you get from it has the layout in figure 8 [FC-FS] 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifierthen the IPv6 Interface Identifier is made from that EUI-64 by flipping the U/L bit in the OUI field ✨ the OUI stays the same as in the FC Name_Identifier, just with that one bit toggled. the result has local scope [AARCH] and looks like figure 9 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifierexample time 🧚 the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF gives you the IPv6 Interface Identifier 3463:461A:BCDE:F000 😭🫶
6.3. Generating an Interface ID from a Format 2 N_Port_Name 🌸
next up is format 0x2, which is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifierits EUI-64 address is in figure 11 [FC-FS] 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifiersame move as before: complement the U/L bit in the OUI field, and the OUI in the IPv6 Interface ID is exactly what it was in the FC Name_Identifier 🔥 the result has local scope [AARCH] and the shape in figure 12 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifierexample 🎀 0x27-89-34-63-46-AB-CD-EF turns into 3463:462A:BCDE:F789 ⭐
6.4. Generating an Interface ID from a Format 5 N_Port_Name 🦋
format 0x5 is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifierthe EUI-64 address derived from it is figure 14 [FC-FS] 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifieronce more, the IPv6 Interface Identifier comes from complementing the U/L bit in the OUI field, so the OUI matches the FC Name_Identifier 🌸 the local-scope result is figure 15 [AARCH] 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifierexample: 0x53-46-34-6A-BC-DE-F7-89 generates 3463:465A:BCDE:F789 👑
6.5. Generating an Interface ID from an EUI-64 mapped N_Port_Name 🌈
the EUI-64 mapped Name_Identifier formats (that's 0xC through 0xF) come from an EUI-64 address with its OUI squished down 🧚 to do that, you drop the Universal/Local and Individual/Group bits from the OUI, put bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and put bits 8 to 23 of the OUI in the second and third octets, as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Formatthe EUI-64 address that makes that Name_Identifier looks like 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifierthe IPv6 Interface Identifier comes from that EUI-64 by complementing the U/L bit in the OUI field 💜 this one has global scope [AARCH] (not local, bestie, that's different!!) and looks like 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] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifierexample 🌸 0xCD-63-46-AB-01-25-78-9A gives you 3663:46AB:0125:789A 🎀
7. Link-Local Addresses ✨
the IPv6 link-local address [AARCH] for an Nx_Port is made by tacking the Interface Identifier from section 6 onto the prefix FE80::/64 🧚 the layout is figure 19, and it's giving very neat 10-bit, 54-bit, 64-bit vibes 🍓
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format8. Address Mapping for Unicast ✨
okay so an Nx_Port has two Fibre Channel addresses and they do totally different jobs 🫶
- a non-volatile 64-bit address called
N_Port_Name; - a volatile 24-bit address called
N_Port_ID.
the N_Port_Name is how we uniquely identify the Nx_Port, and the N_Port_ID is how frames actually get routed to it 🦋 both FC addresses are required to resolve an IPv6 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 whenever certain Fibre Channel events happen (see Appendix B). no skipping this bestie 💅
the procedure for mapping IPv6 unicast addresses into Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC]. when the link layer is Fibre Channel, the Source/Target Link-layer Address option looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+Fig. 20: Source/Target Link-layer Address option for Fibre Channel
here's the breakdown 🎀
Type:1for Source Link-layer address,2for Target Link-layer address.Length:2(in units of 8 octets).N_Port_Name: this field holds the Nx_Port's N_Port_Name.N_Port_ID: this field holds the Nx_Port's N_Port_ID.
the reserved fields are a strict rule: they MUST be zero when you transmit, and they MUST be ignored when you receive 🙈
9. Address Mapping for Multicast 🌈
by default, every best-effort IPv6 multicast packet MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF 📣 that includes datagrams going to the all-nodes multicast address, the all-routers multicast address, and the solicited-node multicast addresses [AARCH]. those MUST be sent as Class 3 FC Sequences addressed to 0xFF-FF-FF, and the Destination N_Port_Name field of the FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A explains how to send a Class 3 broadcast FC Sequence over the different Fibre Channel topologies 🧚
an Nx_Port that supports IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context so it can handle IPv6 multicast packets 💜 the receive data field size of that implicit Port Login MUST be the same across all the Nx_Ports connected to the same Fabric, otherwise FC broadcast transmission does not work. so important! to cut down on FC Sequence segmentation, that receive data field size SHOULD be 1024 octets. and this size requirement only covers broadcast Device_Data FC frames, not ELSs.
receiving an FC Sequence that carries an IPv6 multicast packet MAY trigger some extra processing by the Nx_Port, but only if that packet needs a unicast reply 👀 in that case, if there's no valid Port Login to the Nx_Port that sent the multicast packet, the Nx_Port MUST perform one and then use it for the unicast IPv6 reply. for Neighbor Discovery messages [DISC], the N_Port_ID that the Port Login is directed to comes from the N_Port_ID field of the Source/Target Link-layer Address option.
for example, an Nx_Port handling a received broadcast FC Sequence that carries an IPv6 multicast unsolicited router advertisement [DISC] just passes the IPv6 packet up to the IPv6 layer. easy. but if the 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 can be sent 💅 and if that solicitation needs a multicast reply instead, the reply goes to the broadcast N_Port_ID 0xFF-FF-FF.
best-effort IPv6 multicast for other multicast group addresses MAY use Fibre Channel Multicast Groups [FC-FS], as long as the FC topology and implementation support it 🌸
10. Sequence Management 🎀
FC Sequences are REQUIRED to be non-streamed 🙅♀️ and to avoid missing FC frames because of Sequence_ID reuse (aliasing), an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. each Exchange MUST start with SEQ_CNT = 0 in its first frame, and every frame sent after that MUST increment the previous SEQ_CNT by one. any frames that come in from the other N_Port in the Exchange shall have no effect on the SEQ_CNT you transmit. they can't mess with your count 😤✨
11. Exchange Management 🦋
to transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange for sending data to each Nx_Port in the network, plus a dedicated Exchange for receiving data from each Nx_Port 💖
an Exchange Responder is not required to assign RX_IDs. if an RX_ID of 0xFFFF does get assigned, then the Exchange Responder is identifying Exchanges based only on S_ID / D_ID / OX_ID 🧠
when an Exchange is created between two Nx_Ports for unicast IPv6 packets, it stays active for as long as those Nx_Ports are logged in with each other. each FC broadcast and ELS [FC-FS] SHOULD use its own short-lived Exchange, though 🫶
for IPv6, Exchanges MUST NOT transfer Sequence Initiative, because they only run in one direction 🙅♀️ the Sequence Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
how Exchanges get aged out or expired (based on activity, timeout, or other methods) is outside the scope of this document. not our problem here, bestie 💁♀️
the Exchange Originator MAY end Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY also be torn down by either the Exchange Originator or the Exchange Responder using the ABTS (Abort Sequence) protocol [FC-FS]. and IPv6 Exchanges SHOULD NOT be terminated by Logout, since that might kill active Exchanges belonging to other FC-4s [FC-FS] 🚫
12. Security Considerations 💀
okay this section is SERIOUS, read it twice 🚨 IPv6 doesn't add any new security concerns beyond the ones that already exist in the Fibre Channel protocols. zoning based on FC Name Server masking (that's soft zoning) does NOT work with IPv6, because IPv6 over Fibre Channel doesn't use the FC Name Server at all 😭 the FC ESP_Header [FC-FS] can be used to secure the FC frames that carry IPv6 packets inside FC Sequences. and any technique you'd use to secure IPv6 traffic at the IPv6 layer can be used in a Fibre Channel environment too. stay safe out there 🔐
13. Acknowledgments 🫶
the author wants to give a huge shoutout to the authors of [IPFC], [ETHER], and [IPv6-1394], since parts of this document were derived from their work 🙌 they also thank the ANSI INCITS T11.3 Task Group members who reviewed this document. the real MVPs 👑
14. References 📚
14.1. Normative References
here are the normative refs, copied exactly so nothing gets lost 💅
[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.
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[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.14.2. Informative References
and the informative ones, which are good to read but not required 🌷
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001.A. Transmission of a Broadcast FC Sequence over FC Topologies 🗺️
A.1. Point-to-Point Topology
in point-to-point, no special mechanisms are needed 🙌 the Nx_Port on the other end of the cable just receives the broadcast FC Sequence with D_ID 0xFFFFFF.
A.2. Private Loop Topology
an NL_Port on a private loop MUST transmit a Class 3 broadcast FC Sequence using the OPN(fr) primitive signal [FC-AL-2]. here's how it goes 🔁
- a) the source NL_Port first sends an Open Broadcast Replicate (OPN(fr)) primitive signal. this forces every NL_Port on the loop (except itself) to replicate the frames it receives, by checking the FC Header's
D_IDfield. - b) then the source NL_Port removes the OPN(fr) signal once it comes back around to it.
- c) finally, the source NL_Port sends the Class 3 broadcast FC Sequence with
D_ID0xFFFFFF.
A.3. Public Loop Topology
an NL_Port on 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 it arrived on. that covers all F_Ports and all other FL_Ports.
each FL_Port then passes the broadcast on by 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 transmit the Class 3 broadcast FC Sequence with D_ID 0xFFFFFF to that F_Port. the Fabric then propagates the broadcast to all other FC_Ports [FC-FS] 🌐
B. Validation of the <N_Port_Name, N_Port_ID> mapping 🔍
B.1. Overview
at all times, the <N_Port_Name, N_Port_ID> mapping must be valid before you use it, no exceptions 🙅♀️
after an FC link interruption, the N_Port_ID of an Nx_Port might change, and so might the N_Port_IDs of every other Nx_Port that has done Port Login with it. because of that, address validation is required after a LIP in a loop topology [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS] 🔄
N_Port_IDs do NOT change because of Link Reset (LR) [FC-FS], so in that case address validation is not required 🎉
B.2. FC Layer Address Validation in a Point-to-Point Topology
no validation is required after LR 💖 in a point-to-point topology, NOS/OLS causes an implicit Logout of each N_Port, and after a NOS/OLS each N_Port must again perform a Port Login [FC-FS].
B.3. FC Layer Address Validation in a Private Loop Topology 🔐
okay so after a LIP [FC-AL-2], an NL_Port must not send any data to another NL_Port until it has validated that port's address. 🙅♀️ Validation means finishing either ADISC or PDISC [FC-FS].
as a requester, you're not allowed to use PDISC, you have to use ADISC 💅. as a responder, an implementation may need to answer both ADISC and PDISC so it plays nicely with other FC specs 🫶.
here's how the checks go:
- if all 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, any active Exchange with that NL_Port can keep going ✨.
- if any of the three FC addresses changed, the remote NL_Port must be logged out 💀.
- if an NL_Port's N_Port_ID changes after a LIP, then every active logged in NL_Port must be logged out 😭.
B.4. FC Layer Address Validation in a Public Loop Topology 🌈
so the Fabric may send a FAN ELS to all the NL_Ports that were logged in before, right after an initialization event 📬. that means after a LIP [FC-AL-2], NL_Ports can either wait for that notification to show up, or just do an FLOGI 🦋.
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 port can resume all Exchanges 🎉. if not, then FLOGI has to be done with the Fabric and all logged in Nx_Ports have to be logged out 🙈.
also, a public loop NL_Port must do the private loop validation from section B.3 to any NL_Port on the local loop that has an N_Port_ID of the form 0x00-00-XX 🧚.
B.5. FC Layer Address Validation in a Fabric Topology 🛸
no validation is needed after LR (link reset) 🙌.
after NOS/OLS, an N_Port must do FLOGI 💖. if, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are all the same as before the NOS/OLS, then the N_Port can resume all Exchanges 🍓. if not, every logged in Nx_Port has to be logged out [FC-FS] 💀.
C. Fibre Channel Bit and Byte Numbering Guidance 🎀
okay this one's a little different, bestie 👀. both Fibre Channel and IETF standards send bytes in the same order 🫶, but the bit numbering is different 🙃.
you can see the Fibre Channel bit numbering if you copy and paste the data structure heading from figure 21 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Fig. 21: Fibre Channel Bit Numbering 📊
Author's Address 📮
Claudio DeSanti
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853-9172
EMail: cds@cisco.comFull Copyright Statement ©
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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 currently provided by the Internet Society. 🌸
📦 where this page comes from
- ietf: rfc3831 2004-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms