| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
4.6. Bit and Byte Ordering
IPv6 packets are mapped to the FC-4 level using the big-endian byte
ordering that corresponds to the standard network byte order or
canonical form.
5. Maximum Transfer Unit
The default MTU size for IPv6 [IPv6] packets over Fibre Channel is
65280 octets. This size may be reduced by a Router Advertisement
[DISC] containing an MTU option that specifies a smaller MTU, or by
manual configuration of each Nx_Port. However, as required by
[IPv6], the MTU MUST NOT be lower than 1280 octets. If a Router
Advertisement received on an Nx_Port has an MTU option specifying an
MTU larger than 65280, or larger than a manually configured value,
that MTU option MAY be logged to system management but MUST be
otherwise ignored.
As the default MTU size far exceeds the message sizes typically used
in the Internet, an IPv6 over FC implementation SHOULD implement Path
MTU Discovery [PMTUD], or at least maintain different MTU values for
on-link and off-link destinations.
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 which 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 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.
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
The Name_Identifier format 0x1 is depicted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted 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_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [AARCH] and the format
depicted in figure 9.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
6.3. Generating an Interface ID from a Format 2 N_Port_Name
The Name_Identifier format 0x2 is depicted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted 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_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address by
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [AARCH] and the format
depicted in figure 12.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF
generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
6.4. Generating an Interface ID from a Format 5 N_Port_Name
The Name_Identifier format 0x5 is depicted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
The EUI-64 address derived from this Name_Identifier has the format
depicted in 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_Identifier
The IPv6 Interface Identifier is obtained from this EUI-64 address
complementing the U/L bit in the OUI field. So the OUI in the IPv6
Interface ID is exactly as in the FC Name_Identifier. The resulting
IPv6 Interface Identifier has local scope [AARCH] and the format
depicted in figure 15.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89
generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
6.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 from the
OUI the Universal/Local and Individual/Group bits, and by putting
bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and
bits 8 to 23 of the OUI in the second and third octet of the
Name_Identifier, as shown in figure 16.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
The EUI-64 address used to generate the Name_Identifier shown in
figure 16 has the format depicted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: 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 depicted
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] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: 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.
7. Link-Local Addresses
The IPv6 link-local address [AARCH] for an Nx_Port is formed by
appending the Interface Identifier, as defined in section 6, to the
prefix FE80::/64. The resulting address is depicted in figure 19.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
8. Address Mapping for Unicast
An Nx_Port has two kinds of Fibre Channel addresses:
- a non-volatile 64-bit address, called N_Port_Name;
- a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, while the
N_Port_ID is used to route frames to the Nx_Port. Both FC addresses
are required to resolve an IPv6 unicast address. The fact that the
N_Port_ID is volatile implies that an Nx_Port MUST validate the
mapping between its N_Port_Name and N_Port_ID when certain Fibre
Channel events occur (see Appendix B).
The procedure for mapping IPv6 unicast addresses into Fibre Channel
link-layer addresses uses the Neighbor Discovery Protocol [DISC].
The Source/Target Link-layer Address option has the format depicted
in figure 20 when the link layer is Fibre Channel.
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
Type: 1 for Source Link-layer address.
2 for Target Link-layer address.
Length: 2 (in units of 8 octets).
N_Port_Name: This field contains the Nx_Port’s N_Port_Name.
N_Port_ID: This field contains the Nx_Port’s N_Port_ID.
Reserved fields MUST be zero when transmitting, and MUST be ignored
when receiving.
9. Address Mapping for Multicast
By default, all best-effort IPv6 multicast packets MUST be mapped to
FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In
particular, datagrams addressed to all-nodes multicast address,
all-routers multicast address, and solicited-node multicast addresses
[AARCH] MUST be sent as Class 3 FC Sequences addressed to the
broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination
N_Port_Name field of the FC Network_Header MUST be set to the value
0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a
Class 3 broadcast FC Sequence over various Fibre Channel topologies.
An Nx_Port supporting IPv6 MUST be able to map a received broadcast
Class 3 Device_Data FC frame to an implicit Port Login context in
order to handle IPv6 multicast packets. The receive data field size
of this implicit Port Login MUST be the same across all the Nx_Ports
connected to the same Fabric, otherwise FC broadcast transmission
does not work. In order to reduce the need for FC Sequence
segmentation, the receive data field size of this implicit Port Login
SHOULD be 1024 octets. This receive data field size requirement
applies to broadcast Device_Data FC frames, not to ELSs.
Receiving an FC Sequence carrying an IPv6 multicast packet MAY
trigger some additional processing by the Nx_Port if that IPv6 packet
requires a unicast reply. In this case, if a valid Port Login to the
Nx_Port that sent the IPv6 multicast packet does not exist, the
Nx_Port MUST perform such a Port Login, and then use it for the
unicast IPv6 reply. In the case of Neighbor Discovery messages
[DISC], the N_Port_ID to which the Port Login is directed is taken
from the N_Port_ID field of the Source/Target Link-layer Address
option.
As an example, an Nx_Port processes a received broadcast FC Sequence
carrying an IPv6 multicast unsolicited router advertisement [DISC]
simply by passing the carried IPv6 packet to the IPv6 layer.
Instead, if a received broadcast FC Sequence carries an IPv6
multicast solicitation message [DISC] requiring a unicast reply, and
no valid Port Login exists with the Nx_Port sender of the multicast
packet, then a Port Login MUST be performed in order to send the
unicast reply message. If a received broadcast FC Sequence carries
an IPv6 multicast solicitation message [DISC] requiring a multicast
reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
Best-effort IPv6 multicast for other multicast group addresses MAY
use Fibre Channel Multicast Groups [FC-FS], if supported by the
particular FC topology and implementation.
10. Sequence Management
FC Sequences are REQUIRED to be non-streamed. In order to avoid
missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting
IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS].
Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and
every frame transmitted after that MUST increment the previous
SEQ_CNT by one. Any frames received from the other N_Port in the
Exchange shall have no effect on the transmitted SEQ_CNT.
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 and 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 is assigned, the Exchange Responder is identifying
Exchanges based on S_ID / D_ID / OX_ID only.
When an Exchange is created between two Nx_Ports for unicast IPv6
packets, it remains active while the Nx_Ports are logged in with each
other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short
lived Exchange.
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because
they are used in a unidirectional mode. The Sequence Initiative bit
in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
The mechanism for aging or expiring exchanges based on activity,
timeout, or other methods is outside the scope of this document.
The Exchange Originator MAY terminate Exchanges by setting the F_CTL
LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange
Originator or Exchange Responder by using the ABTS (Abort Sequence)
protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout,
since this may terminate active Exchanges on other FC-4s [FC-FS].
12. Security Considerations
IPv6 does not introduce any additional security concerns beyond those
that already exist within the Fibre Channel protocols. Zoning
techniques based on FC Name Server masking (soft zoning) do not work
with IPv6, because IPv6 over Fibre Channel does not use the FC Name
Server. The FC ESP_Header [FC-FS] may be used to secure the FC
frames composing FC Sequences carrying IPv6 packets. All the
techniques defined to secure IPv6 traffic at the IPv6 layer may be
used in a Fibre Channel environment.
13. Acknowledgments
The author would like to acknowledge the authors of [IPFC], [ETHER],
and [IPv6-1394], since some part of this document has been derived
from them, as well as the ANSI INCITS T11.3 Task Group members who
reviewed this document.
14. References
14.1. 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