RFC 6172

RFC 6172: Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode 🦋

okay bestie, this one is RFC 6172 and it's a Standards Track doc from March 2011 💅 It's written by D. Black from EMC and D. Peterson from Brocade, and it updates RFC 4172. It's a 2070-1721 ISSN doc (the ISSN is 2070-1721) 🎀

Abstract ✨

okay so Fibre Channel changed a bunch, and that made the iFCP address translation mode spec wrong 😭 nobody actually uses that mode, so this doc deprecates it. The iFCP address transparent mode is still specified correctly and is in real use, so this doc doesn't touch it 🫶

this doc also records the state of Protocol Number 133, which was given out for a pre-standard version of the Fibre Channel Internet Protocol (FCIP) 🌸

Status of This Memo 🧚

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6172.

Copyright Notice 💜

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🍓

1. Introduction...................................................3
2. Conventions Used in This Document..............................3
3. iFCP Address Translation Mode..................................3
   3.1. Problem Discussion........................................4
   3.2. iFCP Address Translation Mode Deprecation.................4
4. FCIP and Protocol Number 133...................................5
5. Security Considerations........................................5
6. IANA Considerations............................................5
7. Conclusions....................................................5
8. References.....................................................5
   8.1. Normative References......................................5
   8.2. Informative References....................................6
9. Acknowledgments ...............................................6

1. Introduction 🌈

okay so go read Section 3 of [RFC4172] first if you need the Fibre Channel basics 🧚

the Internet Fibre Channel Protocol (iFCP) [RFC4172] has two modes for Fibre Channel N_PORT fabric addresses (the 24-bit N_PORT_IDs) 👑 both are specified in [RFC4172]:

• Address transparent mode is a pass-through mode that keeps the Fibre Channel N_PORT fabric addresses exactly as they are.
• Address translation mode is basically the Fibre Channel version of Network Address Translation (NAT). The iFCP gateways change the Fibre Channel N_PORT fabric addresses at the edge between Fibre Channel and the Internet. Both the source (S_ID) and destination (D_ID) N_PORT fabric addresses can be changed by the iFCP gateways.

this doc deprecates iFCP address translation mode 💅 because the spec never kept up with Fibre Channel changes and because there are no known implementations.

Protocol Number 133 was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP) that wrapped FC frames directly in IP packets. The standard FCIP protocol [RFC3821] [FC-BB-3] doesn't use that protocol number, but implementations of the pre-standard protocol did get deployed. So this doc makes no change to the current allocation of Protocol Number 133 🦋

2. Conventions Used in This Document 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. iFCP Address Translation Mode 🌸

iFCP address translation mode has to translate addresses that are embedded in the transmitted data. This is kinda like NAT translating IP addresses that are embedded in IP packets 🫶 Fibre Channel only allows embedded fabric addresses in control messages (frames). N_PORTs send and receive two kinds of control frames that can contain embedded fabric addresses:

• Extended Link Services (ELSs); and
• FC-4 Link Services (FC-4 LSs) for the Small Computer System Interface (SCSI) over Fibre Channel Protocol (FCP).

the embedded fabric address translations for N_PORT control frames are specified in Section 7.3 of [RFC4172]. Those translations were correct for Fibre Channel at about 2003, based on the [FC-FS] standard for ELSs and the [FCP] standard for FCP FC-4 LSs 💖

3.1. Problem Discussion 😭

so a lot has changed in FC control frames since [RFC4172] came out 💀 the current FC standards are [FC-LS] and [FCP-3], and more changes are coming in the [FC-LS-2] and [FCP-4] standards projects, which are almost done. Those changes made Section 7.3 of [RFC4172] wrong.

actual iFCP deployment also went a totally different way than what was expected when [RFC4172] was being developed. Every iFCP deployment the authors know of uses iFCP address transparent mode, and it's only used for FC inter-switch links 🙈 iFCP address translation mode as specified in [RFC4172] can't be used for FC inter-switch links, because the embedded fabric address translations for FC inter-switch control messages (Switch Fabric Internal Link Services (ILSs)) were never specified 💅

3.2. iFCP Address Translation Mode Deprecation 👑

for all the reasons above, it makes sense to deprecate iFCP address translation mode instead of updating it to match current Fibre Channel standards 🧚 updating it would mean constantly updating a mode nobody uses, to keep up with future changes to FC control frames. no thank you 😭

so this doc deprecates iFCP address translation mode:

• iFCP address translation mode [RFC4172] SHOULD NOT be implemented and SHOULD NOT be used.
• The status of [RFC4172] stays Proposed Standard RFC so the spec for iFCP address transparent mode is kept.
• The [RFC4172] specification of iFCP address translation mode should be treated as Historic [RFC2026].

4. FCIP and Protocol Number 133 🌈

Protocol Number 133 was allocated for Fibre Channel (FC) [IANA-IP] and was used by a pre-standard version of the FCIP protocol that wraps FC frames directly in IP packets. The standard FCIP protocol [RFC3821] [FC-BB-3] wraps FC frames in TCP, so it doesn't use Protocol Number 133. But implementations of the pre-standard version of FCIP were deployed [MR]. Because of that deployment, the protocol number needs to stay allocated 🎀

5. Security Considerations 🔥

the security considerations for iFCP still apply, so go check Section 10 of [RFC4172] 💀

6. IANA Considerations 🫶

IANA has added this document as a supplemental reference for the allocation of Protocol Number 133, but IANA hasn't changed that allocation 🌸

7. Conclusions 👑

for all the reasons in this doc, iFCP Address Translation mode is deprecated, and the allocation of Protocol Number 133 stays unchanged for now 💅✨

8. References 🧚

8.1. Normative References 💜

• [FC-FS] Fibre Channel Framing and Signaling Interface (FC-FS), ANSI INCITS 373-2003, October 2003.
• [FC-LS] Fibre Channel - Link Services (FC-LS), ANSI INCITS 433-2007, July 2007.
• [FCP] Fibre Channel Protocol (FCP), ANSI INCITS 269-1996, April 1996.
• [FCP-3] Fibre Channel Protocol - 3 (FCP-3), ISO/IEC 14776-223:2008, June 2008.
• [IANA-IP] Assigned Internet Protocol Numbers, IANA Registry, http://www.iana.org, visited October 2010.
• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.

8.2. Informative References 🌸

• [FC-BB-3] Fibre Channel Backbone - 3 (FC-BB-3), ANSI INCITS 414-2006, July 2006.
• [FC-LS-2] Fibre Channel - Link Services - 2 (FC-LS-2), INCITS Project 2103-D, Technical Committee T11 (www.t11.org).
• [FCP-4] Fibre Channel Protocol - 4 (FCP-4), INCITS Project 1828-D, Technical Committee T10 (www.t10.org).
• [MR] Rajagopal, M., Private email communication, June 2009.
• [RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3821, July 2004.

9. Acknowledgments 💖

the authors want to thank Tom Talpey, David Harrington, Joe Touch, Paul Hoffman, and Pekka Savola for their helpful comments on this document 🫶🎀

Authors' Addresses 🦋

David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748

Phone: +1 (508) 293-7953 EMail: david.black@emc.com

David Peterson Brocade Communications 6000 Nathan Lane North Plymouth, MN 55442

Phone: +1 (612) 802-3299 EMail: david.peterson@brocade.com