rfc-6172

Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode

D. Black, D. Peterson
date2011-03 streamIETF areatsv wgstorm statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6172 doi10.17487/RFC6172
Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document. This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]

updates

Extracted elements (10)

design-rationale §3.1

All known deployments of iFCP use address transparent mode exclusively for FC inter-switch links. Address translation mode cannot be used for FC inter-switch links because the necessary embedded fabric address translations for Switch Fabric Internal Link Services (ILSs) were never specified.

design-rationale §3.1

iFCP address translation mode is deprecated rather than updated because the FC control frame standards (FC-LS, FCP-3, and forthcoming FC-LS-2 and FCP-4) have changed significantly since RFC 4172 was published, rendering Section 7.3 of RFC 4172 incorrect. Updating it would create a continuing requirement to track future FC changes for an unused protocol mode.

design-rationale §4

Protocol Number 133 is retained as allocated (not reclaimed) because pre-standard FCIP implementations that use it were actually deployed. Removing the allocation would be incorrect given known deployment history.

registry

interoperability-note §3.2

The status of RFC 4172 remains Proposed Standard in order to retain the specification of iFCP address transparent mode, which has been implemented and is in current use. Only the address translation mode portion of RFC 4172 is treated as Historic per RFC 2026.

normative-requirement §3.2 SHOULD NOT

iFCP address translation mode SHOULD NOT be implemented and SHOULD NOT be used. The specification has not tracked changes in Fibre Channel standards and there are no known implementations.

protocol-element §3

iFCP address translation mode must translate fabric addresses embedded in two types of N_PORT control frames: Extended Link Services (ELSs) and FC-4 Link Services (FC-4 LSs) for SCSI over Fibre Channel Protocol (FCP). The embedded fabric address translations were specified in Section 7.3 of RFC 4172.

protocol-element §1

iFCP operates in two modes with respect to Fibre Channel N_PORT fabric addresses (24-bit N_PORT_IDs): address transparent mode, which preserves fabric addresses as a pass-through, and address translation mode, which changes source (S_ID) and destination (D_ID) N_PORT fabric addresses at the FC/Internet boundary, analogous to NAT.

nat

protocol-element §4

Protocol Number 133 was allocated for Fibre Channel (FC) and used by a pre-standard version of FCIP that encapsulated FC frames directly in IP packets. The standard FCIP protocol (RFC 3821) encapsulates FC frames in TCP and does not use Protocol Number 133.

ip

registry §6

IANA added RFC 6172 as a supplemental reference for the allocation of Protocol Number 133 (assigned for Fibre Channel / pre-standard FCIP) but made no change to that allocation.

registry

security-consideration §5

The security considerations for iFCP continue to apply as specified in Section 10 of RFC 4172. This document introduces no new security considerations.

security