ietf-corpus

rfc-4338

Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel

C. DeSanti, C. Carlson, R. Nixon
date2006-01 streamIETF areaops wgimss statusPROPOSED STANDARD pages33 canonicalhttps://www.rfc-editor.org/rfc/rfc4338 doi10.17487/RFC4338
This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (24)

design-rationale §4.3

Class 3 (datagram service) is specified as the recommended FC class for IP traffic because Classes 1 and 6 are specialized for avionics and dedicated connections, while Class 3 is commonly used for storage networking and supports the broadcast required for multicast/ARP.

ip, qos

design-rationale §D

FARP support was removed from RFC 4338 (compared to RFC 2625) because some FC implementations do not tolerate receiving broadcast ELSes. The FC Name Server and manual configuration of <IPv4 address, N_Port_Name, N_Port_ID> mappings serve as alternatives.

ip

design-rationale §7

RFC 2625 restricted ARP to Nx_Ports with format 0x1 N_Port_Names by reusing the Ethernet ARP format. RFC 4338 defines a Fibre Channel-specific ARP format carrying both N_Port_Name and N_Port_ID as the hardware address, enabling support for all commonly used N_Port_Name formats (0x1, 0x2, 0x5, 0xC–0xF) in widespread use.

ip

interoperability-note §13 REQUIRED

Implementations following RFC 4338 are expected to interoperate with RFC 2625 for IPv4 packet transmission and reception. For compatibility with RFC 2625 implementations, an Nx_Port with format 0x1 N_Port_Name MUST send both FC ARP and Ethernet ARP Requests, and MUST respond to Ethernet ARP Requests. Support of compatibility mode is REQUIRED and MUST be administratively configurable.

ip, interoperability-note

normative-requirement §4.1 MUST

An FC Information Unit containing an IPv6 or IPv4 packet MUST carry the FC Network_Header (16 octets) and the LLC/SNAP header (8 octets). To support the minimum IPv6 MTU of 1280 octets, an Nx_Port MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long.

ip

normative-requirement §4.2 MUST

An FC 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. Other FC Optional Headers (besides ESP_Header) MUST NOT be used in an FC frame carrying an ARP packet.

ip

normative-requirement §3 MUST

An IP-capable Nx_Port MUST support N_Port_Name formats 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, or 0xF; MUST support Class 3; MUST support continuously increasing SEQ_CNT; and MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long.

ip, registry

normative-requirement §10 MUST

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. The receive data field size of this implicit Port Login MUST be the same across all Nx_Ports connected to the same Fabric.

ip, multicast

normative-requirement §11 REQUIRED

FC Sequences carrying IPv6, IPv4, or ARP packets are REQUIRED to be non-streamed. An Nx_Port is REQUIRED to use continuously increasing SEQ_CNT to avoid FC frame aliasing by Sequence_ID reuse. Each Exchange MUST start SEQ_CNT at zero and increment by one per frame.

ip

normative-requirement §9.3 MUST

For IPv4 address mapping, a source Nx_Port MUST consult its local mapping tables; if no mapping or valid Port Login exists, it MUST send a broadcast FC ARP Request. Upon receiving a broadcast FC ARP Request, the matching Nx_Port MUST perform a Port Login (if none exists) before sending the unicast ARP Reply.

ip

normative-requirement §10 MUST

IPv6 multicast, IPv4 multicast/broadcast, and ARP broadcast packets MUST be addressed to the broadcast N_Port_ID 0xFFFFFF in FC Class 3. The Destination N_Port_Name in the FC Network_Header MUST be set to specific values: 0x10-00-FF-FF-FF-FF-FF-FF for broadcast, or multicast-derived values for IPv6/IPv4 multicast.

ip, multicast

normative-requirement §5.1 MUST

IPv6 stateless address autoconfiguration MUST be performed as specified in RFC 2462. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits.

ip, v6ops

normative-requirement §4.3 MUST

Multicast IPv6 packets, multicast/broadcast IPv4 packets, and Control Protocol packets (ARP, ICMPv6, Neighbor Discovery, MLDv2, ICMP, IGMP, Routing Protocols) MUST be mapped in Class 3 FC frames.

ip, multicast

normative-requirement §4.8 MUST NOT

The default MTU for IPv6 and IPv4 packets over Fibre Channel is 65280 octets. The MTU MUST NOT be lower than 1280 octets. Router Advertisement MTU options specifying values larger than 65280 or a manually configured value MUST be ignored.

ip

normative-requirement §12 MUST

To transmit IPv6, IPv4, or ARP packets, an Nx_Port MUST use dedicated unidirectional Exchanges (Sequence Initiative bit MUST be zero, RX_ID MUST be 0xFFFF). Unicast data traffic MUST be sent in long-lived Exchanges; control protocol packets SHOULD use short-lived Exchanges.

ip

protocol-element §5.1

The IPv6 Interface Identifier for an Nx_Port is derived from an EUI-64 address obtained from the N_Port_Name, with the Universal/Local (U/L) bit of the OUI field complemented. Different derivation procedures apply for N_Port_Name formats 0x1, 0x2, 0x5, and EUI-64 mapped formats (0xC–0xF).

ip, v6ops

registry §15

The IANA directory of ARP parameters has been updated to reference RFC 4338 for ARP hardware type 18 (decimal), identifying Fibre Channel as an ARP hardware type.

registry, ip

security-consideration §14

Soft zoning techniques based on FC Name Server masking do not work with IPv6 and IPv4 over Fibre Channel because IP over FC does not use the FC Name Server. The FC ESP_Header may be used to secure FC frames carrying IPv6, IPv4, and ARP packets; all IP-layer security techniques remain applicable.

security, ip

wire-format §4.4

FC Header code points for IPv6/IPv4 encapsulation: R_CTL MUST be 0x04 (Unsolicited Data), TYPE MUST be 0x05 (IP over Fibre Channel), DF_CTL MUST be 0x20 for the first frame (0x60 with ESP_Header), and 0x00 for subsequent frames (0x40 with ESP_Header).

ip

wire-format §7

The FC ARP packet is 40 octets with HW Type=0x0012 (Fibre Channel), Protocol=0x0800 (IPv4), HW Len=12 (octets), Proto Len=4. The HW Address field carries both N_Port_Name (8 octets) and N_Port_ID (3 octets, with 1 reserved octet prefix), totalling 12 octets.

ip

wire-format §4.1

The FC Information Unit for an IP packet consists of: FC Network_Header (16 octets), LLC/SNAP header (8 octets), followed by the IPv6 or IPv4 packet. The FC Network_Header and LLC/SNAP header appear only in the first frame of a multi-frame Sequence.

ip

wire-format §4.5

The FC Network_Header is 16 octets and contains two 8-octet fields: Destination N_Port_Name and Source N_Port_Name. N_Port_Name formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, or 0xF.

ip

wire-format §8

The Link-layer Address / Hardware Address used in FC Neighbor Discovery and FC ARP is 12 octets: an 8-octet N_Port_Name followed by 1 reserved octet and a 3-octet N_Port_ID. Reserved fields MUST be set to zero on transmit and MUST be ignored on receive.

ip

wire-format §4.6

The LLC/SNAP header is 8 octets with fixed code points: DSAP=0xAA, SSAP=0xAA, CTRL=0x03, OUI=0x000000, and PID=0x86DD (IPv6), 0x0800 (IPv4), or 0x0806 (ARP).

ip