Sequence carrying an ARP packet MUST be mapped to a single FC frame
that MUST include the FC Network_Header and the LLC/SNAP header.
The FC ESP_Header [FC-FS] MAY be used to secure an FC frame carrying
an ARP packet. Other FC Optional Headers MUST NOT be used in an FC
frame carrying an ARP packet.
4.3. FC Classes of Service
This specification uses FC Class 3. The following types of packets
MUST be mapped in Class 3 FC frames:
- multicast IPv6 packets;
- multicast/broadcast IPv4 packets;
- Control Protocol packets (e.g., ARP packets; IPv6 packets carrying
ICMPv6 [ICMPv6], Neighbor Discovery [DISC], or Multicast Listener
Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or
IGMP [IGMPv3] messages; IPv6 and IPv4 Routing Protocols packets).
Other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data
traffic) SHOULD be mapped in Class 3 FC frames as well. Support for
reception of IPv4 or IPv6 packets mapped in FC frames of any Class
other than Class 3 is OPTIONAL; receivers MAY ignore them.
4.4. FC Header Code Points
The fields of the Fibre Channel Header are shown in figure 5. The
D_ID and S_ID fields contain, respectively, the destination N_Port_ID
and the source N_Port_ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Figure 5: FC Header Format
To encapsulate IPv6 and IPv4 over Fibre Channel, the following code
points apply. When a single value is listed without further
qualification, that value MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or
IPv4 Sequence, 0x00 for the following FC frames. If the FC
ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or
IPv4 Sequence, 0x40 for the following FC frames;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: if Relative Offset [FC-FS] is not used, the content of
this field MUST be ignored by the receiver, and SHOULD be set to
zero by the sender. If Relative Offset is used, see [FC-FS].
To encapsulate ARP over Fibre Channel, the following code points
apply. When a single value is listed without further qualification,
that value MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then
0x60;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12,
and [FC-FS] for additional requirements;
- Parameter: SHOULD be set to zero.
4.5. FC Network_Header
The fields of the FC Network_Header are shown in figure 6. For use
with IPv6, IPv4, and ARP, the N_Port_Names formats MUST be one of
0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [FC-FS].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Figure 6: FC Network_Header Format
4.6. LLC/SNAP Header
The fields of the LLC/SNAP header [IEEE-LLC] are shown in figure 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Figure 7: LLC/SNAP Header Format
To encapsulate IPv6, IPv4, and ARP over Fibre Channel, the following
code points MUST be used:
- DSAP: 0xAA;
- SSAP: 0xAA;
- CTRL: 0x03;
- OUI: 0x000000;
- PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP.
4.7. Bit and Byte Ordering
IPv6, IPv4, and ARP packets are mapped to the FC-4 level using the
big-endian byte ordering that corresponds to the standard network
byte order or canonical form.
4.8. Maximum Transfer Unit
The default MTU size for IPv6 packets over Fibre Channel is 65280
octets. Large IPv6 packets are mapped to a Sequence of FC frames
(see section 2.4). This size may be reduced by a Router
Advertisement [DISC] containing an MTU option that specifies a
smaller MTU, or by manual configuration of each Nx_Port. However, as
required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a
Router Advertisement received on an Nx_Port has an MTU option
specifying an MTU larger than 65280, or larger than a manually
configured value, that MTU option MAY be logged to system management
but MUST be otherwise ignored.
As the default MTU size far exceeds the message sizes typically used
in the Internet, an IPv6 over FC implementation SHOULD implement Path
MTU Discovery [PMTUD6], or at least maintain different MTU values for
on-link and off-link destinations.
For correct operation of IPv6 in a routed environment, it is
critically important to configure an appropriate MTU option in Router
Advertisements.
For correct operation of IPv6 when mixed media (e.g., Ethernet and
Fibre Channel) are bridged together, the smallest MTU of all the
media must be advertised by routers in an MTU option. If there are
no routers present, this MTU must be manually configured in each node
that is connected to a medium with a default MTU larger than the
smallest MTU.
The default MTU size for IPv4 packets over Fibre Channel is 65280
octets. Large IPv4 packets are mapped to a Sequence of FC frames
(see section 2.4). This size may be reduced by manual configuration
of each Nx_Port or by the Path MTU Discovery technique [PMTUD4].
5. IPv6 Stateless Address Autoconfiguration
5.1. IPv6 Interface Identifier and Address Prefix
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64
address [EUI64] derived from the Nx_Port’s N_Port_Name. The IPv6
Interface Identifier is obtained by complementing the Universal/Local
(U/L) bit of the OUI field of the derived EUI-64 address. The U/L
bit has no function in Fibre Channel; however, it has to be properly
handled when a Name_Identifier is converted to an EUI-64 address.
[FC-FS] specifies a method to map format 0x1 (IEEE 48-bit address),
0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in
EUI-64 addresses. This allows the usage of these Name_Identifiers to
support IPv6. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers
(formats 0xC, 0xD, 0xE, and 0xF) that are derived from an EUI-64
address. It is possible to reverse this address mapping to obtain
the original EUI-64 address in order to support IPv6.
IPv6 stateless address autoconfiguration MUST be performed as
specified in [ACONF]. An IPv6 Address Prefix used for stateless
address autoconfiguration of an Nx_Port MUST have a length of 64
bits.
5.2. Generating an Interface ID from a Format 1 N_Port_Name
The Name_Identifier format 0x1 is shown in figure 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Figure 8: Format 0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
shown in figure 9 [FC-FS].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Figure 9: EUI-64 Address from a Format 0x1 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. Therefore, the OUI in
the IPv6 Interface ID is exactly as in the FC Name_Identifier. The
resulting IPv6 Interface Identifier has local scope [AARCH] and the
format shown in figure 10.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Figure 10: IPv6 Interface ID from a Format 0x1 Name_Identifier
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
5.3. Generating an Interface ID from a Format 2 N_Port_Name
The Name_Identifier format 0x2 is shown in figure 11.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Figure 11: Format 0x2 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
shown in figure 12 [FC-FS].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Figure 12: EUI-64 Address from a Format 0x2 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. Therefore, the OUI in
the IPv6 Interface ID is exactly as in the FC Name_Identifier. The
resulting IPv6 Interface Identifier has local scope [AARCH] and the
format shown in figure 13.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Figure 13: IPv6 Interface ID from a Format 0x2 Name_Identifier
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
5.4. Generating an Interface ID from a Format 5 N_Port_Name
The Name_Identifier format 0x5 is shown in figure 14.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 14: Format 0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
shown in figure 15 [FC-FS].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 15: EUI-64 Address from a Format 0x5 Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address
complementing the U/L bit in the OUI field. Therefore, the OUI in
the IPv6 Interface ID is exactly as in the FC Name_Identifier. The
resulting IPv6 Interface Identifier has local scope [AARCH] and the
format shown in figure 16.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 16: IPv6 Interface ID from a Format 0x5 Name_Identifier
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89
generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
5.5. Generating an Interface ID from an EUI-64 Mapped N_Port_Name
The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF)
are derived from an EUI-64 address by compressing the OUI field of
such addresses. The compression is performed by removing the
Universal/Local and Individual/Group bits from the OUI, and by
putting bits 0 to 5 of the OUI in the first octet of the
Name_Identifier, and bits 8 to 23 of the OUI in the second and third
octet of the Name_Identifier, as shown in figure 17.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 17: EUI-64 Mapped Name_Identifiers Format
The EUI-64 address used to generate the Name_Identifier shown in
figure 17 has the format shown in figure 18.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. The resulting IPv6
Interface Identifier has global scope [AARCH] and the format shown in
figure 19.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Figure 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A
generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
6. Link-local Addresses
The IPv6 link-local address [AARCH] for an Nx_Port is formed by
appending the Interface Identifier (as defined in section 5) to the