RFC 6172 PROPOSED STANDARD STORAGE · DEPRECATION
iFCP Deprecation: Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode
Retiring an unused, outdated mode of iFCP and recording why Protocol Number 133 stays allocated.
RFC EDITOR
Black, D. and D. Peterson, "Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode", RFC 6172, DOI 10.17487/RFC6172, March 2011, <https://www.rfc-editor.org/info/rfc6172>.
BIBTEX
@misc{rfc6172,
series = {Request for Comments},
number = 6172,
howpublished = {RFC 6172},
publisher = {RFC Editor},
doi = {10.17487/RFC6172},
url = {https://www.rfc-editor.org/info/rfc6172},
author = {D. Black and D. Peterson},
title = {{Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode}},
pagetotal = 6,
year = 2011,
month = mar,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 6172 EMC
Updates: 4172 D. Peterson
Category: Standards Track Brocade
ISSN: 2070-1721 March 2011
Deprecation of the Internet Fibre Channel Protocol (iFCP)
Address Translation Mode
Abstract
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).
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
See Section 3 of [RFC4172] for introductory material on Fibre Channel
concepts.
The Internet Fibre Channel Protocol (iFCP) [RFC4172] operates in two
modes with respect to Fibre Channel N_PORT fabric addresses (24-bit
N_PORT_IDs): address transparent mode and address translation mode
(both modes are specified in [RFC4172]):
o Address transparent mode is a pass-through mode that preserves
Fibre Channel N_PORT fabric addresses.
o Address translation mode is a Fibre Channel analog to Network
Address Translation (NAT) in which iFCP gateways change Fibre
Channel N_PORT fabric addresses at the boundary between Fibre
Channel and the Internet. Both the source (S_ID) and destination
(D_ID) N_PORT fabric addresses may be changed by the iFCP
gateways.
This document deprecates iFCP address translation mode because the
specification has not tracked changes in Fibre Channel 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 encapsulated FC frames
directly in IP packets. That protocol number is not used by the
standard FCIP protocol [RFC3821] [FC-BB-3], but implementations of
the pre-standard protocol were deployed. Therefore, this document
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 embedded in
transmitted data. This is analogous to NAT translation of IP
addresses embedded in IP packets. Fibre Channel restricts the
occurrence of embedded fabric addresses to control messages (frames);
N_PORTs send and receive two types of control frames that may contain
embedded fabric addresses:
o Extended Link Services (ELSs); and
o 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]. These translations were
correct as specified for Fibre Channel as of approximately 2003,
based on the [FC-FS] standard for ELSs and the [FCP] standard for FCP
FC-4 LSs.
3.1. Problem Discussion
Significant changes have been made to FC control frames since the
iFCP specification [RFC4172] was published; the currently applicable
FC standards are [FC-LS] and [FCP-3], and additional changes are
forthcoming in the [FC-LS-2] and [FCP-4] standards projects, which
are nearing completion. These changes have caused Section 7.3 of
[RFC4172] to become incorrect.
Actual iFCP deployment has diverged significantly from that
anticipated during the development of [RFC4172]. All deployments of
iFCP known to the authors of this document use iFCP address
transparent mode and are used only for FC inter-switch links. iFCP
address translation mode as specified in [RFC4172] cannot be used for
FC inter-switch links because the necessary embedded fabric address
translations for FC inter-switch control messages (Switch Fabric
Internal Link Services (ILSs)) have not been specified.
3.2. iFCP Address Translation Mode Deprecation
For the reasons described above, it is prudent to deprecate iFCP
address translation mode in preference to updating it to the current
state of Fibre Channel standards. Updating iFCP address translation
mode would create a continuing requirement to update an unused
protocol mode to match future changes to FC control frames.
Therefore, this document deprecates iFCP address translation mode:
o iFCP address translation mode [RFC4172] SHOULD NOT be implemented
and SHOULD NOT be used.
o The status of [RFC4172] remains Proposed Standard RFC in order to
retain the specification of iFCP address transparent mode.
o 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 used by a pre-standard version of the FCIP protocol that
encapsulates FC frames directly in IP packets. The standard FCIP
protocol [RFC3821] [FC-BB-3] encapsulates FC frames in TCP and hence
does not use Protocol Number 133, but implementations of the pre-
standard version of the FCIP protocol were deployed [MR]. Based on
this deployment, the protocol number needs to remain allocated.
5. Security Considerations
The security considerations for iFCP continue to apply; see Section
10 of [RFC4172].
6. IANA Considerations
IANA has added this document as a supplemental reference for the
allocation of Protocol Number 133 but hasn't changed that allocation.
7. Conclusions
For the reasons described in this document, iFCP Address Translation
mode is deprecated, and the allocation of Protocol Number 133 remains
unchanged at this time.
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 would like to thank Tom Talpey, David Harrington, Joe
Touch, Paul Hoffman, and Pekka Savola for 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
AI ELI5
On this page
PROBLEMChanges to Fibre Channel made the iFCP address translation mode specification incorrect, and no known implementation used it.
MECHANISMThe RFC says address translation mode SHOULD NOT be implemented and SHOULD NOT be used, and that its text in RFC 4172 should be treated as Historic. Address transparent mode is left alone.
STATUS TODAYRFC 4172 stays a Proposed Standard to keep address transparent mode, and Protocol Number 133 remains allocated because pre-standard FCIP was deployed.
§1Two Modes of iFCP
The Internet Fibre Channel Protocol (iFCP), specified in RFC 4172, has two modes for handling Fibre Channel N_PORT fabric addresses, which are 24-bit N_PORT_IDs.
- Address transparent mode is a pass-through mode that preserves the addresses.
- Address translation mode is a Fibre Channel analog to Network Address Translation (NAT). iFCP gateways change the addresses at the boundary between Fibre Channel and the Internet, and both the source (
S_ID) and destination (D_ID) addresses may be changed.
This document deprecates address translation mode because its specification has not tracked changes in Fibre Channel and because there are no known implementations.
One mode passes the address labels along untouched. The other swaps the labels at the border. The swapping kind is the one being retired.
| Mode | Fabric addresses | Status |
|---|---|---|
| Address transparent | Preserved | In use; unaffected |
| Address translation THIS RFC | Changed by gateways (like NAT) | Deprecated |
§2Why Translation Mode Broke
Address translation mode has to translate addresses embedded in transmitted data, much as NAT translates IP addresses embedded in IP packets. Fibre Channel limits embedded fabric addresses to control frames: Extended Link Services (ELSs) and FC-4 Link Services for SCSI over Fibre Channel (FCP). The translations are given in Section 7.3 of RFC 4172 and were correct for Fibre Channel as of approximately 2003.
Since then, significant changes were made to FC control frames, and these changes made Section 7.3 of RFC 4172 incorrect. Deployment also diverged from expectations: all iFCP deployments known to the authors use address transparent mode, and only for FC inter-switch links. Translation mode cannot be used for those links, because the needed translations for Switch Fabric Internal Link Services have not been specified.
The rules for swapping labels went out of date when the things being labeled changed. Meanwhile, everyone who actually used the system picked the other mode.
§3What the Deprecation Says
The authors judged it prudent to deprecate the mode rather than update it, since updating would create a continuing requirement to track future changes to FC control frames for an unused protocol mode.
The rule book now says: do not build or use the old swapping mode. Keep the rest of the book, because the other mode is still good.
§4FCIP and Protocol Number 133
Protocol Number 133 was allocated for Fibre Channel and used by a pre-standard version of the Fibre Channel over IP (FCIP) protocol that put FC frames directly into IP packets. The standard FCIP protocol, RFC 3821, encapsulates FC frames in TCP and so does not use that number.
Implementations of the pre-standard version were deployed, so the number needs to remain allocated. IANA has added this document as a supplemental reference for the allocation but has not changed it.
An old version of a system used a special locker number. Even though the new version does not need it, some old users still do, so nobody takes the locker away.
§5Security Considerations
This document adds nothing new here. The security considerations for iFCP continue to apply, as described in Section 10 of RFC 4172.
The safety rules for the system stay as they were.
§6References
[RFC2026]RFC 2026Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.October 1996[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997[RFC4172]RFC 4172Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.September 2005[RFC3821]RFC 3821Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3821, July 2004.July 2004