prefix FE80::/64. The resulting address is shown in figure 20.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 20: IPv6 Link-local Address Format
7. ARP Packet Format
The Address Resolution Protocol defined in [ARP] is designed to be a
general purpose protocol, to accommodate many network technologies
and many Upper Layer Protocols.
[RFC-2625] chose to use for Fibre Channel the same ARP packet format
used for Ethernet networks. In order to do that, [RFC-2625]
restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1.
Although this may have been a reasonable choice at that time, today
there are Nx_Ports with an N_Port_Name format other than 0x1 in
widespread use.
This specification accommodates Nx_Ports with N_Port_Names of a
format different from 0x1 by defining a Fibre Channel specific
version of the ARP protocol (FC ARP), carrying both N_Port_Name and
N_Port_ID as Hardware (HW) Address.
IANA has registered the number 18 (decimal) to identify Fibre Channel
as ARP HW type. The FC ARP packet format is shown in figure 21. The
length of the FC ARP packet is 40 octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Type = 0x0012 | Protocol = 0x0800 |
+---------------+---------------+---------------+---------------+
| HW Len = 12 | Proto Len = 4 | Opcode |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Sender |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Sender |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Target |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Target |
+---------------+---------------+---------------+---------------+
Figure 21: FC ARP Packet Format
The following code points MUST be used with FC ARP:
- HW Type: 0x0012 (Fibre Channel);
- Protocol: 0x0800 (IPv4);
- HW Len: 12 (Length in octets of the HW Address);
- Proto Len: 4 (Length in octets of the Protocol Address);
- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply [ARP];
- HW Address of Sender: the HW Address (see section 8) of the
Requester in an ARP Request, or the HW Address of the Responder in
an ARP Reply;
- Protocol Address of Sender: the IPv4 address of the Requester in
an ARP Request, or that of the Responder in an ARP Reply;
- HW Address of Target: set to zero in an ARP Request, and to the HW
Address (see section 8) of the Requester in an ARP Reply;
- Protocol Address of Target: the IPv4 address of the Responder in
an ARP Request, or that of the Requester in an ARP Reply.
8. Link-layer Address/Hardware Address
The Link-layer Address used in the Source/Target Link-layer Address
option (see section 9.2) and the Hardware Address used in FC ARP (see
section 7) have the same format, shown in figure 22.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Figure 22: Link-layer Address/HW Address Format
Reserved fields MUST be set to zero when transmitting, and MUST be
ignored when receiving.
9. Address Mapping for Unicast
9.1. Overview
An Nx_Port has two kinds of Fibre Channel addresses:
- a non-volatile 64-bit address, called N_Port_Name;
- a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, and the
N_Port_ID is used to route frames to the Nx_Port. Both FC addresses
are required to resolve an IPv6 or IPv4 unicast address. The fact
that the N_Port_ID is volatile implies that an Nx_Port MUST validate
the mapping between its N_Port_Name and N_Port_ID when certain Fibre
Channel events occur (see Appendix B).
9.2. IPv6 Address Mapping
The procedure for mapping IPv6 unicast addresses into Fibre Channel
link-layer addresses uses the Neighbor Discovery Protocol [DISC].
The Source/Target Link-layer Address option has the format shown in
figure 23 when the link layer is Fibre Channel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | |
+---------------+---------------+ -+
| |
+- Link-layer Address -+
| |
+- +---------------+---------------+
| | Padding |
+---------------+---------------+---------------+---------------+
Figure 23: Source/Target Link-layer Address Option for Fibre Channel
Type: 1 for Source Link-layer address.
2 for Target Link-layer address.
Length: 2 (in units of 8 octets).
Padding: MUST be set to zero when transmitting,
MUST be ignored when receiving.
Link-layer Address: the Nx_Port’s Link-layer Address (see section
8).
9.3. IPv4 Address Mapping
The procedure for mapping IPv4 unicast addresses into Fibre Channel
link-layer addresses uses the FC ARP protocol, as specified in
section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets
to a destination Nx_Port, known by its IPv4 address, MUST perform the
following steps:
1) The source Nx_Port first consults its local mapping tables for a
mapping <destination IPv4 address, N_Port_Name, N_Port_ID>.
2) If such a mapping is found, and a valid Port Login is in place
with the destination Nx_Port, then the source Nx_Port sends the
IPv4 packets to the destination Nx_Port using the retrieved
N_Port_ID as D_ID.
3) If such a mapping is not found, or a valid Port Login is not in
place with the destination Nx_Port, then the source Nx_Port sends
a broadcast FC ARP Request (see section 10) to its connected FC
network.
4) When a broadcast FC ARP Request is received by the Nx_Port with
the matching IPv4 address, that Nx_Port caches the information
carried in the FC ARP Request in its local mapping tables and
generates a unicast FC ARP Reply. If a valid Port Login to the
Nx_Port that sent the broadcast FC ARP Request does not exist, the
Nx_Port MUST perform such a Port Login, and then use it for the
unicast reply. The N_Port_ID to which the Port Login is directed
is taken from the N_Port_ID field of the Sender HW Address field
in the received FC ARP packet.
5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP
Reply is returned.
10. Address Mapping for Multicast
IPv6 multicast packets, IPv4 multicast/broadcast packets, and ARP
broadcast packets MUST be mapped to FC Sequences addressed to the
broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional
Exchange (see section 12). Appendix A specifies how to transmit a
Class 3 broadcast FC Sequence over various Fibre Channel topologies.
The Destination N_Port_Name field of the FC Network_Header MUST be
set to the value:
- for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF;
- for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, where
XX-YY-ZZ-QQ are the 4 least significant octets of the multicast
destination IPv6 address;
- for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, where the
23 least significant bits of XX-YY-ZZ are the 23 least significant
bits of the multicast destination IPv4 address and the most
significant bit of XX-YY-ZZ is set to zero.
An Nx_Port supporting IPv6 or IPv4 MUST be able to map a received
broadcast Class 3 Device_Data FC frame to an implicit Port Login
context in order to handle IPv6 multicast packets, IPv4 multicast or
broadcast packets, and ARP broadcast packets. The receive data field
size of this implicit Port Login MUST be the same across all the
Nx_Ports connected to the same Fabric, otherwise FC broadcast
transmission does not work. In order to reduce the need for FC
Sequence segmentation, the receive data field size of this implicit
Port Login SHOULD be 1024 octets. This receive data field size
requirement applies to broadcast Device_Data FC frames, not to ELSes.
Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4
multicast/broadcast packet, or an FC ARP broadcast packet triggers
some additional processing by the Nx_Port when that IPv6, IPv4, or
FC ARP packet requires a unicast reply. In this case, if a valid
Port Login to the Nx_Port that sent the multicast or broadcast packet
does not exist, the Nx_Port MUST perform such a Port Login, and then
use it for the unicast reply. In the case of Neighbor Discovery
messages [DISC], the N_Port_ID to which the Port Login is directed is
taken from the N_Port_ID field of the Source Link-layer Address in
the received Neighbor Discovery message. In the case of FC ARP
messages, the N_Port_ID to which the Port Login is directed is taken
from the N_Port_ID field of the Sender HW Address field in the
received FC ARP packet.
As an example, if a received broadcast FC Sequence carries an IPv6
multicast unsolicited Router Advertisement [DISC], the receiving
Nx_Port processes it simply by passing the carried IPv6 packet to the
IPv6 layer. Instead, if a received broadcast FC Sequence carries an
IPv6 multicast solicitation message [DISC] requiring a unicast reply,
and no valid Port Login exists with the Nx_Port sender of the
multicast packet, then a Port Login MUST be performed in order to
send the unicast reply message. If a received broadcast FC Sequence
carries an IPv6 multicast solicitation message [DISC] requiring a
multicast reply, the reply is sent to the broadcast N_Port_ID
0xFFFFFF.
11. Sequence Management
FC Sequences carrying IPv6, IPv4, or ARP packets are REQUIRED to be
non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by
Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to
use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST
start by setting SEQ_CNT to zero in the first frame; every frame
transmitted after that MUST increment the previous SEQ_CNT by one.
The Continue Sequence Condition field in the F_CTL field of the FC
Header MUST be set to zero [FC-FS].
12. Exchange Management
To transmit IPv6, IPv4, or ARP packets to another Nx_Port or to a
multicast/broadcast address, an Nx_Port MUST use dedicated
unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4, or
ARP packet transmission and that do not transfer Sequence
Initiative). As such, the Sequence Initiative bit in the F_CTL field
of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the
FC Header MUST be set to 0xFFFF.
Unicast FC Sequences carrying unicast Control Protocol packets (e.g.,
ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor
Discovery [DISC], or Multicast Listener Discovery [MLDv2] messages;
IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD
be sent in short-lived unidirectional Exchanges (i.e., Exchanges
containing only one Sequence, in which both the First_Sequence and
Last_Sequence bits in the F_CTL field of the FC Header are set to one
[FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets
(i.e., unicast IP packets carrying data traffic) MUST be sent in a
long-lived unidirectional Exchange (i.e., an Exchange containing one
or more Sequences). IP multicast packets MUST NOT be carried in
unicast FC Sequences (see section 10).
Broadcast FC Sequences carrying multicast or broadcast Control
Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6
[ICMPv6], Neighbor Discovery [DISC], or Multicast Listener Discovery
[MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP
[IGMPv3] messages) MUST be sent in short-lived unidirectional
Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4
multicast traffic (i.e., multicast IP packets carrying data traffic)
MAY be sent in long-lived unidirectional Exchanges to enable a more
efficient multicast distribution.
Reasons to terminate a long-lived Exchange include the termination of
Port Login and the completion of the IP communication. A long-lived
Exchange MAY be terminated by setting the Last_Sequence bit in the
F_CTL field of the FC Header to one, or via the ABTS (Abort Sequence)
protocol [FC-FS]. A long-lived Exchange SHOULD NOT be terminated by
transmitting the LOGO ELS, since this may terminate active Exchanges
on other FC-4s [FC-FS].
13. Interoperability with RFC 2625
The IPv4 encapsulation defined in this document, along with Exchange
and Sequence management, are as defined in [RFC-2625].
Implementations following this specification are expected to
interoperate with implementations compliant to [RFC-2625] for IPv4
packet transmission and reception.
The main difference between this document and [RFC-2625] is in the
address resolution procedure. [RFC-2625] uses the Ethernet format of
the ARP protocol and requires all Nx_Ports to have a format 0x1
N_Port_Name. This specification defines a Fibre Channel format for
the ARP protocol that supports all commonly used N_Port_Names. In
addition, this specification does not use FARP [RFC-2625].
An Nx_Port following this specification, and not having a format 0x1
N_Port_Name, is able to interoperate with an [RFC-2625]
implementation by manually configuring the mapping <destination IPv4
address, N_Port_Name, N_Port_ID> on the involved Nx_Ports. Through
this manual configuration, the ARP protocol does not need to be
performed. However, IPv4 communication is not possible if the
[RFC-2625] implementation strictly enforces the requirement for
Nx_Ports to use N_Port_Names of format 0x1.
An Nx_Port following this specification, and having a format 0x1
N_Port_Name, is able to interoperate with an [RFC-2625]
implementation by manually configuring the mapping <destination IPv4
address, N_Port_Name, N_Port_ID> on the involved Nx_Ports, or by
performing the IPv4 address resolution in compatibility mode, as
described below:
- When IPv4 address resolution is attempted, the Nx_Port MUST send
two ARP Requests, the first one according to the FC ARP format and
the second one according to the Ethernet ARP format. If only an
Ethernet ARP Reply is received, it provides the N_Port_Name of the
Nx_Port having the destination IPv4 address. The N_Port_ID
associated with the N_Port_Name received in an Ethernet ARP Reply
may be retrieved from the S_ID field of the received ARP Reply, or
by querying the Fibre Channel Name Server;
- The Nx_Port MUST respond to a received Ethernet ARP Request with
an Ethernet ARP Reply;
- The Nx_Port MAY respond to FARP Requests [RFC-2625].
The reception of a particular format of ARP message does not imply
that the sending Nx_Port will continue to use the same format later.
Support of compatibility mode is REQUIRED by each implementation.
The use of compatibility mode MUST be administratively configurable.
14. Security Considerations
IPv6, IPv4, and ARP do not introduce any additional security concerns
beyond those that already exist within the Fibre Channel protocols.
Zoning techniques based on FC Name Server masking (soft zoning) do
not work with IPv6 and IPv4, because IPv6 and IPv4 over Fibre Channel
do not use the FC Name Server. The FC ESP_Header [FC-FS] may be used
to secure the FC frames composing FC Sequences carrying IPv6, IPv4,
and ARP packets. All the techniques defined to secure IP traffic at
the IP layer may be used in a Fibre Channel environment.
15. IANA Considerations
The directory of ARP parameters has been updated to reference this
document for hardware type 18.
16. Acknowledgements
The authors would like to acknowledge the ANSI INCITS T11.3 Task
Group members who reviewed this document as well as the authors of
[RFC-2625] and [RFC-3831]. The authors also thank the IMSS WG and
Brian Haberman for their review and comments.
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.