idnits 2.17.1 draft-ietf-storm-ifcp-ipn133-updates-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4172, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4172, updated by this document, for RFC5378 checks: 2001-02-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2010) is 4940 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-LS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'FCP-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IP' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Storage Maintenance (storm) WG David L. Black 2 Internet Draft EMC 3 Intended status: Proposed Standard David Peterson 4 Expires: April 2011 Brocade 5 Updates: 4172 October 14, 2010 7 Deprecation of iFCP Address Translation Mode 8 draft-ietf-storm-ifcp-ipn133-updates-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on April 14, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 Changes to Fibre Channel have caused the specification of iFCP 51 address translation mode to become incorrect. Due to the absence of 52 usage of iFCP address translation mode, it is deprecated by this 53 document. iFCP address transparent mode remains correctly specified. 55 iFCP address transparent mode has been implemented and is in current 56 use, therefore, it is not affected by this document. 58 This document also records the state of Protocol Number 133, which 59 was allocated for a pre-standard version of FCIP. 61 Table of Contents 63 1. Introduction...................................................2 64 2. Conventions used in this document..............................3 65 3. iFCP Address Translation Mode..................................3 66 3.1. Problem Discussion........................................3 67 3.2. iFCP Address Translation Mode Deprecation.................4 68 4. FCIP and Protocol Number 133...................................4 69 5. Security Considerations........................................4 70 6. IANA Considerations............................................5 71 7. Conclusions....................................................5 72 8. References.....................................................5 73 8.1. Normative References......................................5 74 8.2. Informative References....................................5 76 1. Introduction 78 See Section 3 of [RFC4172] for introductory material on Fibre Channel 79 concepts. 81 iFCP (Internet Fibre Channel Protocol) [RFC4172] operates in two 82 modes with respect to Fibre Channel N_Port fabric addresses (24-bit 83 N_Port_IDs), address transparent mode and address translation mode 84 (both modes are specified in [RFC4172]): 86 o Address Transparent mode is a pass-through mode that preserves 87 Fibre Channel N_Port fabric addresses. 89 o Address Translation mode is a Fibre Channel analog to Network 90 Address Translation (NAT) in which iFCP gateways change Fibre 91 Channel N_Port fabric addresses at the boundary between Fibre 92 Channel and the Internet. Both the source (S_ID) and destination 93 (D_ID) N_Port fabric addresses may be changed by the iFCP 94 gateways. 96 This document deprecates iFCP address translation mode because the 97 specification has not tracked changes in Fibre Channel and because 98 there are no known implementations. 100 Protocol Number 133 was allocated for a pre-standard version of FCIP 101 (Fibre Channel Internet Protocol) that encapsulated FC frames 102 directly in IP packets. That protocol number is not used by the 103 standard FCIP protocol [RFC3821][FC-BB-3], but implementations of the 104 pre-standard protocol were deployed. Therefore, this document makes 105 no change to the current allocation of Protocol Number 133. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. iFCP Address Translation Mode 115 iFCP address translation mode has to translate addresses embedded in 116 transmitted data. This is analogous to NAT translation of IP 117 addresses embedded in IP packets. Fibre Channel restricts the 118 occurrence of embedded fabric addresses to control messages (frames); 119 N_Ports send and receive two types of control frames that may contain 120 embedded fabric addresses: 122 o Extended Link Services (ELSs); and 124 o FC-4 Link Services (FC-4 LSs) for the SCSI over Fibre Channel 125 Protocol (FCP). 127 The embedded fabric address translations for N_Port control frames 128 are specified in Section 7.3 of [RFC4172]. These translations were 129 correct as specified for Fibre Channel as of approximately 2003, 130 based on the [FC-FS] standard for ELSs and the [FCP] standard for FCP 131 FC-4 LSs. 133 3.1. Problem Discussion 135 Significant changes have been made to FC control frames since the 136 iFCP specification [RFC4172] was published; the currently applicable 137 FC standards are [FC-LS] and [FCP-3], and additional changes are 138 forthcoming in the [FC-LS-2] and [FCP-4] standards projects which are 139 nearing completion. These changes have caused Section 7.3 of [RFC 140 4172] to become incorrect. 142 Actual iFCP deployment has diverged significantly from that 143 anticipated during the development of [RFC4172]. All deployments of 144 iFCP known to the authors of this document use iFCP address 145 transparent mode and are used only for FC inter-switch links. iFCP 146 address translation mode as specified in [RFC4172] cannot be used for 147 FC inter-switch links because the necessary embedded fabric address 148 translations for FC inter-switch control messages (Switch Fabric 149 Internal Link Services, ILSs) have not been specified. 151 3.2. iFCP Address Translation Mode Deprecation 153 For the reasons described above, it is prudent to deprecate iFCP 154 address translation mode in preference to updating it to the current 155 state of Fibre Channel standards. Updating iFCP address translation 156 mode would create a continuing requirement to update an unused 157 protocol mode to match future changes to FC control frames. 159 Therefore, this document deprecates iFCP address translation mode: 161 o iFCP address translation mode [RFC4172] SHOULD NOT be implemented 162 and SHOULD NOT be used. 164 o The status of [RFC4172] remains Proposed Standard RFC in order to 165 retain the specification of iFCP address transparent mode. 167 o The [RFC4172] specification of iFCP address translation mode 168 should be treated as Historic [RFC2026]. 170 4. FCIP and Protocol Number 133 172 Protocol Number 133 was allocated for Fibre Channel (FC) [IANA-IP] 173 and used by a pre-standard version of the FCIP protocol that 174 encapsulates FC frames directly in IP packets. The standard FCIP 175 protocol [RFC3821][FC-BB-3] encapsulates FC frames in TCP and hence 176 does not use Protocol Number 133, but implementations of the pre- 177 standard version of the FCIP protocol were deployed [MR]. Based on 178 this deployment, the protocol number needs to remain allocated. 180 5. Security Considerations 182 The security considerations for iFCP continue to apply; see Section 183 10 of [RFC4172]. 185 6. IANA Considerations 187 IANA should add this document as a supplemental reference for the 188 allocation of Protocol Number 133, but should not change that 189 allocation. 191 7. Conclusions 193 For the reasons described in this document, iFCP Address Translation 194 mode is deprecated, and the allocation of Protocol Number 133 remains 195 unchanged at this time. 197 8. References 199 8.1. Normative References 201 [FC-FS] Fibre Channel Framing and Signaling Interface (FC-FS), 202 ANSI INCITS 373-2003, October 2003. 204 [FC-LS] Fibre Channel - Link Services (FC-LS), ANSI INCITS 433-2007, 205 July 2007. 207 [FCP] Fibre Channel Protocol (FCP), ANSI INCITS 269-1996, April 208 1996. 210 [FCP-3] Fibre Channel Protocol - 3 (FCP-3), ISO/IEC 14776-223:2008, 211 June 2008. 213 [IANA-IP] Assigned Internet Protocol Numbers, IANA Registry, 214 http://www.iana.org/assignments/protocol-numbers/protocol- 215 numbers.xhtml, visited October 2010. 217 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 218 3", BCP 9, RFC 2026, October 1996. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC4172] Monia, C., et al, "iFCP - A Protocol for Internet Fibre 224 Channel Storage Networking", RFC 4172, September 2005. 226 8.2. Informative References 228 [FC-BB-3] Fibre Channel Backbone - 3 (FC-BB-3), ANSI INCITS 414-2006, 229 July 2006. 231 [FC-LS-2] Fibre Channel - Link Services - 2 (FC-LS-2), INCITS Project 232 2103-D, Technical Committee T11 (www.t11.org). 234 [FCP-4] Fibre Channel Protocol - 4 (FCP-4), INCITS Project 1828-D, 235 Technical Committee T10 (www.t10.org). 237 [MR] Rajagopal, M., Private email communication, June 2009. 239 [RFC3821] Rajagopal, M., E. Rodriguez and R. Weber, "Fibre Channel 240 Over TCP/IP (FCIP)", RFC 3821, July 2004. 242 Acknowledgments 244 The authors would like to thank Tom Talpey, David Harrington, Joe 245 Touch, Paul Hoffman and Pekka Savola for helpful comments on this 246 document. 248 This document was prepared using 2-Word-v2.0.template.dot. 250 Authors' Addresses 252 David L. Black 253 EMC Corporation 254 176 South Street 255 Hopkinton, MA 01748 257 Phone: +1 (508) 293-7953 258 Email: david.black@emc.com 260 David Peterson 261 Brocade Communications 262 6000 Nathan Lane North 263 Plymouth, MN 55442 265 Phone: +1 (612) 802-3299 266 Email: david.peterson@brocade.com