idnits 2.17.1 draft-desanti-imss-ip-over-fibre-channel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1410. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2004) is 7065 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-AL-2' ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (ref. 'AARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2462 (ref. 'ACONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1981 (ref. 'PMTUD6') (Obsoleted by RFC 8201) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-LLC' -- Obsolete informational reference (is this intentional?): RFC 3831 (Obsoleted by RFC 4338) -- Obsolete informational reference (is this intentional?): RFC 2625 (Obsoleted by RFC 4338) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMSS Working Group C. DeSanti 2 INTERNET DRAFT Cisco Systems 3 draft-desanti-imss-ip-over-fibre-channel-00.txt C. Carlson 4 Category: Standards Track QLogic Corporation 5 Replaces: RFC 2625, RFC 3831 R. Nixon 6 Expires: June 2005 Emulex 7 December 2004 9 Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the way of encapsulating IPv6, IPv4 and ARP 39 packets over Fibre Channel. This document specifies also the method 40 of forming IPv6 link-local addresses and statelessly autoconfigured 41 IPv6 addresses on Fibre Channel networks, and a mechanism to perform 42 IPv4 address resolution over Fibre Channel networks. 44 Table Of Contents 46 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Summary of Fibre Channel. . . . . . . . . . . . . . . . . . . 3 48 2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.2 Identifiers and Login . . . . . . . . . . . . . . . . . . . . 4 50 2.3 FC Levels and Frame Format. . . . . . . . . . . . . . . . . . 5 51 2.4 Sequences and Exchanges . . . . . . . . . . . . . . . . . . . 6 52 3. IP Capable Nx_Ports . . . . . . . . . . . . . . . . . . . . . 7 53 4. IPv6, IPv4 and ARP Encapsulation. . . . . . . . . . . . . . . 7 54 4.1 FC Sequence Format for IPv6 and IPv4 Packets. . . . . . . . . 7 55 4.2 FC Sequence Format for ARP Packets. . . . . . . . . . . . . . 9 56 4.3 FC Classes of Service . . . . . . . . . . . . . . . . . . . . 9 57 4.4 FC Header Code Points . . . . . . . . . . . . . . . . . . . . 10 58 4.5 FC Network_Header . . . . . . . . . . . . . . . . . . . . . . 11 59 4.6 LLC/SNAP Header . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.7 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 12 61 4.8 Maximum Transfer Unit . . . . . . . . . . . . . . . . . . . . 12 62 5. IPv6 Stateless Address Autoconfiguration. . . . . . . . . . . 13 63 5.1 IPv6 Interface Identifier and Address Prefix. . . . . . . . . 13 64 5.2 Generating an Interface ID from a Format 1 N_Port_Name. . . . 14 65 5.3 Generating an Interface ID from a Format 2 N_Port_Name. . . . 15 66 5.4 Generating an Interface ID from a Format 5 N_Port_Name. . . . 16 67 5.5 Generating an Interface ID from an EUI-64 mapped N_Port_Name. 17 68 6. Link-Local Addresses. . . . . . . . . . . . . . . . . . . . . 18 69 7. ARP Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 70 8. Address Mapping for Unicast . . . . . . . . . . . . . . . . . 20 71 8.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 8.2 IPv6 Address Mapping. . . . . . . . . . . . . . . . . . . . . 20 73 8.3 IPv4 Address Mapping. . . . . . . . . . . . . . . . . . . . . 21 74 9. Address Mapping for Multicast . . . . . . . . . . . . . . . . 22 75 10. Sequence Management . . . . . . . . . . . . . . . . . . . . . 23 76 11. Exchange Management . . . . . . . . . . . . . . . . . . . . . 23 77 12. Interoperability with [RFC-2625]. . . . . . . . . . . . . . . 24 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 16. Normative References. . . . . . . . . . . . . . . . . . . . . 25 82 17. Informative References. . . . . . . . . . . . . . . . . . . . 26 83 18. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 27 85 A. Transmission of a Broadcast FC Sequence over FC Topologies. . 28 86 B. Validation of the mapping. . . . . . 29 87 C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 30 88 D. Changes from [RFC-2625] . . . . . . . . . . . . . . . . . . . 31 89 E. Changes from [RFC-3831] . . . . . . . . . . . . . . . . . . . 31 91 1. Introduction 93 Fibre Channel (FC) is a high speed serial interface technology that 94 supports several Upper Layer Protocols including Small Computer 95 System Interface (SCSI), IPv6 [IPv6] and IPv4 [IPv4]. 97 [RFC-2625] defined how to encapsulate IPv4 and ARP packets over Fibre 98 Channel for a subset of Fibre Channel devices. This specification 99 enables the support of IPv4 for a broader category of Fibre Channel 100 devices. In addition, this specification simplifies [RFC-2625] by 101 removing unused options and clarifying what is currently implemented. 102 This document updates [RFC-2625] and, hence, replaces it. 104 Specific [RFC-2625] limitations that this document aims to resolve 105 are: 107 - N_Port_Name format restriction. [RFC-2625] restricts the use of 108 IPv4 to Fibre Channel devices having format 0x1 N_Port_Name, but 109 many current implementations use other N_Port_Name formats; 110 - Use of FARP. [RFC-2625] requires the support of FARP to map 111 N_Port_Names to N_Port_IDs, but many current implementations use 112 other methods, such as the Fibre Channel Name Server; 113 - Missing support for IPv4 multicast. [RFC-2625] does not specify 114 how to transmit IPv4 packets with a multicast destination address 115 over Fibre Channel. 117 [RFC-3831] defines how to encapsulate IPv6 over Fibre Channel and a 118 method of forming IPv6 link-local addresses [AARCH] and statelessly 119 autoconfigured IPv6 addresses on Fibre Channel networks. [RFC-3831] 120 describes also the content of the Source/Target Link-layer Address 121 option used in Neighbor Discovery [DISC] when the messages are 122 transmitted on a Fibre Channel network. This document incorporates 123 and clarifies [RFC-3831] and, hence, replaces it. 125 Warning to readers familiar with Fibre Channel: both Fibre Channel 126 and IETF standards use the same byte transmission order. However, 127 the bit numbering is different. See Appendix C for guidance. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [KEYWORDS]. 133 2. Summary of Fibre Channel 135 2.1. Overview 137 Fibre Channel (FC) is a gigabit speed network technology primarily 138 used for Storage Networking. Fibre Channel is standardized in the 139 T11 Technical Committee of the InterNational Committee for 140 Information Technology Standards (INCITS), an American National 141 Standard Institute (ANSI) accredited standards committee. 143 Fibre Channel devices are called Nodes. Each Node has one or more 144 Ports that connect to Ports of other devices. Fibre Channel may be 145 implemented using any combination of the following three topologies: 147 - a point-to-point link between two Ports; 148 - a set of Ports interconnected by a switching network called a 149 Fabric, as defined in [FC-FS]; 150 - a set of Ports interconnected with a loop topology, as defined in 151 [FC-AL-2]. 153 A Node Port is more precisely called an N_Port. A Node Port that is 154 capable of operating in a loop topology using the loop specific 155 protocols is designated as an NL_Port. The term Nx_Port is used to 156 generically indicate these two kinds of Node Port. 158 A Fabric Port is more precisely called an F_Port. A Fabric Port that 159 is capable of operating in a loop topology using the loop specific 160 protocols is designated as an FL_Port. The term Fx_Port is used to 161 generically indicate these two kinds of Fabric Port. 163 A Fibre Channel network, built with any combination of the FC 164 topologies described above, is a multiaccess network with broadcast 165 capabilities. 167 From an IPv6 point of view, a Fibre Channel network is an IPv6 Link 168 [IPv6]. IP-capable Nx_Ports are what [IPv6] calls Interfaces. 170 From an IPv4 point of view, a Fibre Channel network is an IPv4 Local 171 Network [IPv4]. IP-capable Nx_Ports are what [IPv4] calls Local 172 Network Interfaces. 174 2.2. Identifiers and Login 176 Fibre Channel entities are identified by permanent 64 bit long 177 Name_Identifiers. [FC-FS] defines several formats of 178 Name_Identifiers. The value of the most significant four bits 179 defines the format of a Name_Identifier. These names are referred to 180 in a more precise manner as follows: 182 - an Nx_Port's Name_Identifier is called N_Port_Name; 183 - an Fx_Port's Name_Identifier is called F_Port_Name; 184 - a Node's Name_Identifier is called Node_Name; 185 - a Fabric's Name_Identifier is called Fabric_Name. 187 An Nx_Port connected to a Fibre Channel network is associated with 188 two identifiers, its permanent N_Port_Name and a volatile 24 bit 189 address called N_Port_ID. The N_Port_Name is used to identify the 190 Nx_Port, while the N_Port_ID is used for communications among 191 Nx_Ports. 193 Each Nx_Port acquires an N_Port_ID from the Fabric by performing a 194 process called Fabric Login or FLOGI. The FLOGI process is used also 195 to negotiate several communications parameters between the Nx_Port 196 and the Fabric, such as the receive data field size, which determines 197 the maximum size of the Fibre Channel frames that may be transferred 198 between the Nx_Port and the Fabric. 200 Before effective communication may take place between two Nx_Ports, 201 they must complete a process called Port Login or PLOGI. The PLOGI 202 process provides each Nx_Port with the other Nx_Port's N_Port_Name, 203 and negotiates several communication parameters, such as the receive 204 data field size, which determines the maximum size of the Fibre 205 Channel frames that may be transferred between the two Nx_Ports. 207 Both Fabric Login and Port Login may be explicit (i.e., performed 208 using specific FC control messages called Extended Link Services or 209 ELS), or implicit (i.e., in which the parameters are specified by 210 configuration or other methods). 212 2.3. FC Levels and Frame Format 214 [FC-FS] describes the Fibre Channel protocol using 5 different 215 levels. The FC-2 and FC-4 levels are relevant for this 216 specification. The FC-2 level defines the FC frame format, the 217 transport services, and the control functions necessary for 218 information transfer. The FC-4 level supports Upper Level Protocols, 219 such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is shown 220 in figure 1. 222 +-----+-----------+-----------+--------//-------+-----+-----+ 223 | | | Data Field | | | 224 | SOF | FC Header |<--------------------------->| CRC | EOF | 225 | | | Optional | Frame | | | 226 | | | Header(s) | Payload | | | 227 +-----+-----------+-----------+--------//-------+-----+-----+ 229 Fig. 1: Fibre Channel Frame Format 231 The Start of Frame (SOF) and End of Frame (EOF) are special FC 232 transmission words that act as frame delimiters. The CRC is 4 octets 233 long and uses the same 32-bit polynomial used in Ethernet. 235 The FC Header is 24 octets long and contains several fields 236 associated with the identification and control of the Data Field. 238 The Data Field is of variable size, ranging from 0 to 2112 octets, 239 and includes the user data in the Frame Payload field, and Optional 240 Headers. The currently defined Optional Headers are: 242 - ESP_Header; 243 - Network_Header; 244 - Association_Header; 245 - Device_Header. 247 The value of the SOF field determines the FC Class of service 248 associated with the frame. Five Classes of service are specified in 249 [FC-FS]. They are distinguished primarily by the method of flow 250 control between the communicating Nx_Ports and by the level of data 251 integrity provided. A given Fabric or Nx_Port may support one or 252 more of the following Classes of service: 254 - Class 1: Dedicated physical connection with delivery confirmation; 255 - Class 2: Frame multiplexed service with delivery confirmation; 256 - Class 3: Datagram service; 257 - Class 4: Fractional bandwidth; 258 - Class 6: Reliable multicast via dedicated connections. 260 Class 3 and 2 are commonly used for storage networking applications; 261 Class 1 and 6 are typically used for specialized applications in 262 avionics. Class 3 is recommended for IPv6, IPv4 and ARP (see section 263 4.3). 265 2.4. Sequences and Exchanges 267 An application level payload such as an IPv6 or IPv4 packet is called 268 an Information Unit at the FC-4 level of Fibre Channel. Each FC-4 269 Information Unit is mapped to an FC Sequence by the FC-2 level. An 270 FC Sequence consists of one or more FC frames related by the value of 271 the Sequence_ID (SEQ_ID) field of the FC Header. 273 The maximum data that may be carried by an FC frame is 2112 octets. 274 The maximum usable frame size depends on the Fabric and Nx_Port 275 implementations and is negotiated during the Login process. Whenever 276 an Information Unit to be transmitted exceeds this value, the FC-2 277 level segments it into multiple FC frames, sent as a single Sequence. 278 The receiving Nx_Port reassembles the Sequence of frames and delivers 279 a reassembled Information Unit to the FC-4 level. The Sequence Count 280 (SEQ_CNT) field of the FC Header may be used to ensure frame 281 ordering. 283 Multiple Sequences may be related together as belonging to the same 284 FC Exchange. The Exchange is a mechanism used by two Nx_Ports to 285 identify and manage an operation between them. The Exchange is 286 opened when the operation is started between the two Nx_Ports, and 287 closed when the operation ends. FC frames belonging to the same 288 Exchange are related by the value of the Exchange_ID fields in the FC 289 Header. An Originator Exchange_ID (OX_ID) and a Responder 290 Exchange_ID (RX_ID) uniquely identify the Exchange between a pair of 291 Nx_Port. 293 3. IP Capable Nx_Ports 295 This specification requires an IP capable Nx_Port to have the 296 following properties: 298 - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 299 0xD, 0xE, 0xF (see section 5.1); 300 - It MUST support Class 3; 301 - It MUST support continuously increasing SEQ_CNT [FC-FS]; 302 - It MUST be able to transmit and receive an FC-4 Information Unit 303 at least 1304 octets long; 304 - It SHOULD support a receive data field size for Device_Data FC 305 frames of at least 1024 octets. 307 4. IPv6, IPv4 and ARP Encapsulation 309 4.1. FC Sequence Format for IPv6 and IPv4 Packets 311 An IPv6 or IPv4 packet is mapped to an Information Unit at the FC-4 312 level of Fibre Channel, which in turn is mapped to an FC Sequence by 313 the FC-2 level. An FC Information Unit containing an IP packet MUST 314 carry the FC Network_Header [FC-FS] and the LLC/SNAP header 315 [IEEE-LLC], resulting in the FC Information Unit format shown in 316 figure 2. 318 +---------------+---------------+---------------+---------------+ 319 | | 320 +- -+ 321 | Network_Header | 322 +- (16 octets) -+ 323 | | 324 +- -+ 325 | | 326 +---------------+---------------+---------------+---------------+ 327 | LLC/SNAP header | 328 +- (8 octets) -+ 329 | | 330 +---------------+---------------+---------------+---------------+ 331 | | 332 +- -+ 333 / IPv6 or IPv4 Packet / 334 / / 335 +- -+ 336 | | 337 +---------------+---------------+---------------+---------------+ 339 Fig. 2: FC Information Unit Mapping an IP Packet 341 The FC ESP_Header [FC-FS] MAY be used to secure the FC frames 342 composing the IP FC Sequence. [AH] or [ESP] may be used to provide 343 security at the IP layer. Other types of FC Optional Header MUST NOT 344 be used in an IP FC Sequence. 346 Typically, an IP FC Sequence consists of more than one frame. The 347 first frame of the Sequence MUST include the FC Network_Header and 348 the LLC/SNAP header. The other frames MUST NOT include them, as 349 shown in figure 3. 351 First Frame of an IP FC Sequence 352 +-----------+-------------------+-----------------+-------//--------+ 353 | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | 354 | | | | the IP Packet | 355 +-----------+-------------------+-----------------+-------//--------+ 357 Subsequent Frames of an IP FC Sequence 358 +-----------+-----------------//--------------------+ 359 | FC Header | Additional chunk of the IP Packet | 360 +-----------+----------------//---------------------+ 362 Fig. 3: Optional Headers in an IP FC Sequence 364 4.2. FC Sequence Format for ARP Packets 366 An ARP packet is mapped to an Information Unit at the FC-4 level of 367 Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 368 level. An FC Information Unit containing an ARP packet MUST carry 369 the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], 370 resulting to the FC Information Unit format shown in figure 4. 372 +---------------+---------------+---------------+---------------+ 373 | | 374 +- -+ 375 | Network_Header | 376 +- (16 octets) -+ 377 | | 378 +- -+ 379 | | 380 +---------------+---------------+---------------+---------------+ 381 | LLC/SNAP header | 382 +- (8 octets) -+ 383 | | 384 +---------------+---------------+---------------+---------------+ 385 | | 386 +- -+ 387 / ARP Packet / 388 / / 389 +- -+ 390 | | 391 +---------------+---------------+---------------+---------------+ 393 Fig. 4: FC Information Unit Mapping an ARP Packet 395 Given the limited size of an ARP packet (see section 7), an FC 396 Sequence carrying an ARP packet MUST be mapped to a single FC frame, 397 that MUST include the FC Network_Header and the LLC/SNAP header. 399 The FC ESP_Header [FC-FS] MAY be used to secure an FC frame carrying 400 an ARP packet. Other types of FC Optional Header MUST NOT be used in 401 an FC frame carrying an ARP packet. 403 4.3. FC Classes of Service 405 This specification uses FC Class 3. Control Protocol packets (e.g., 406 ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor 407 Discovery [DISC] or Multicast Listener Discovery [MLDv2] messages; 408 IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages), 409 multicast IPv6 packets, and multicast/broadcast IPv4 packets MUST be 410 encapsulated in Class 3 FC frames. Other IPv6 and IPv4 packets 411 (i.e., unicast IP packets carrying data traffic) SHOULD use Class 3 412 as well. 414 4.4. FC Header Code Points 416 The fields of the Fibre Channel Header are shown in figure 5. The 417 D_ID and S_ID fields contain respectively the destination N_Port_ID 418 and the source N_Port_ID. 420 0 1 2 3 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | R_CTL | D_ID | 424 +---------------+---------------+---------------+---------------+ 425 | CS_CTL/Prio | S_ID | 426 +---------------+---------------+---------------+---------------+ 427 | TYPE | F_CTL | 428 +---------------+---------------+---------------+---------------+ 429 | SEQ_ID | DF_CTL | SEQ_CNT | 430 +---------------+---------------+---------------+---------------+ 431 | OX_ID | RX_ID | 432 +---------------+---------------+---------------+---------------+ 433 | Parameter | 434 +---------------+---------------+---------------+---------------+ 436 Fig. 5: FC Header Format 438 To encapsulate IPv6 and IPv4 over Fibre Channel the following code 439 points apply. When a single value is listed without further 440 qualification that value MUST be used: 442 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 443 Category [FC-FS]); 444 - TYPE: 0x05 (IP over Fibre Channel); 445 - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; 446 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or 447 IPv4 Sequence, 0x00 for the following FC frames. If the FC 448 ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or 449 IPv4 Sequence, 0x40 for the following FC frames; 450 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 10, section 11, 451 and [FC-FS] for additional requirements; 452 - Parameter: if Relative Offset [FC-FS] is not used, the content of 453 this field MUST be ignored by the receiver, and SHOULD be set to 454 zero by the sender. If Relative Offset is used, see [FC-FS]. 456 To encapsulate ARP over Fibre Channel the following code points 457 apply. When a single value is listed without further qualification 458 that value MUST be used: 460 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 461 Category [FC-FS]); 462 - TYPE: 0x05 (IP over Fibre Channel); 463 - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; 464 - DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then 465 0x60; 466 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 10, section 11, 467 and [FC-FS] for additional requirements; 468 - Parameter: if Relative Offset [FC-FS] is not used, the content of 469 this field MUST be ignored by the receiver, and SHOULD be set to 470 zero by the sender. If Relative Offset is used, see [FC-FS]. 472 4.5. FC Network_Header 474 The fields of the FC Network_Header are shown in figure 6. For use 475 with IPv6, IPv4 and ARP the N_Port_Names formats MUST be one of 0x1, 476 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [FC-FS]. 478 0 1 2 3 479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 +- Destination N_Port_Name -+ 483 | | 484 +---------------------------------------------------------------+ 485 | | 486 +- Source N_Port_Name -+ 487 | | 488 +---------------------------------------------------------------+ 490 Fig. 6: FC Network_Header Format 492 4.6. LLC/SNAP Header 494 The fields of the LLC/SNAP Header [IEEE-LLC] are shown in figure 7. 496 0 1 2 3 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | DSAP | SSAP | CTRL | OUI | 500 +---------------+---------------+---------------+---------------+ 501 | OUI | PID | 502 +---------------+---------------+---------------+---------------+ 504 Fig. 7: LLC/SNAP Header Format 506 To encapsulate IPv6 over Fibre Channel the following code points MUST 507 be used: 509 - DSAP: 0xAA 510 - SSAP: 0xAA 511 - CTRL: 0x03 512 - OUI: 0x000000 513 - PID: 0x86DD 515 To encapsulate IPv4 over Fibre Channel the following code points MUST 516 be used: 518 - DSAP: 0xAA 519 - SSAP: 0xAA 520 - CTRL: 0x03 521 - OUI: 0x000000 522 - PID: 0x0800 524 To encapsulate ARP over Fibre Channel the following code points MUST 525 be used: 527 - DSAP: 0xAA 528 - SSAP: 0xAA 529 - CTRL: 0x03 530 - OUI: 0x000000 531 - PID: 0x0806 533 4.7. Bit and Byte Ordering 535 IPv6, IPv4 and ARP packets are mapped to the FC-4 level using the 536 big-endian byte ordering that corresponds to the standard network 537 byte order or canonical form. 539 4.8. Maximum Transfer Unit 541 The default MTU size for IPv6 packets over Fibre Channel is 65280 542 octets. Large IPv6 packets are mapped to a Sequence of FC frames 543 (see section 2.4). This size may be reduced by a Router 544 Advertisement [DISC] containing an MTU option that specifies a 545 smaller MTU, or by manual configuration of each Nx_Port. However, as 546 required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a 547 Router Advertisement received on an Nx_Port has an MTU option 548 specifying an MTU larger than 65280, or larger than a manually 549 configured value, that MTU option MAY be logged to system management 550 but MUST be otherwise ignored. 552 As the default MTU size far exceeds the message sizes typically used 553 in the Internet, an IPv6 over FC implementation SHOULD implement Path 554 MTU Discovery [PMTUD6], or at least maintain different MTU values for 555 on-link and off-link destinations. 557 For correct operation of IPv6 in a routed environment, it is 558 critically important to configure an appropriate MTU option in Router 559 Advertisements. 561 For correct operation of IPv6 when mixed media (e.g., Ethernet and 562 Fibre Channel) are bridged together, the smallest MTU of all the 563 media must be advertised by routers in an MTU option. If there are 564 no routers present, this MTU must be manually configured in each node 565 which is connected to a medium with a default MTU larger than the 566 smallest MTU. 568 The default MTU size for IPv4 packets over Fibre Channel is 65280 569 octets. Large IPv4 packets are mapped to a Sequence of FC frames 570 (see section 2.4). This size may be reduced by manual configuration 571 of each Nx_Port or by the Path MTU Discovery technique [PMTUD4]. 573 5. IPv6 Stateless Address Autoconfiguration 575 5.1. IPv6 Interface Identifier and Address Prefix 577 The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 578 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 579 Interface Identifier is obtained by complementing the Universal/Local 580 bit of the OUI field of the derived EUI-64 address. 582 [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), 583 or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers 584 in EUI-64 addresses. This allows the usage of these Name_Identifiers 585 to support IPv6. [FC-FS] also defines EUI-64 mapped FC 586 Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived 587 from an EUI-64 address. It is possible to reverse this address 588 mapping to obtain the original EUI-64 address in order to support 589 IPv6. 591 IPv6 stateless address autoconfiguration MUST be performed as 592 specified in [ACONF]. An IPv6 Address Prefix used for stateless 593 address autoconfiguration of an Nx_Port MUST have a length of 64 594 bits. 596 5.2. Generating an Interface ID from a Format 1 N_Port_Name 598 The Name_Identifier format 0x1 is shown in figure 8. 600 0 1 2 3 601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |0 0 0 1| 0x000 | OUI | 604 +-------+-------+---------------+---------------+---------------+ 605 | OUI | VSID | 606 +---------------+---------------+---------------+---------------+ 608 Fig. 8: Format 0x1 Name_Identifier 610 The EUI-64 address derived from this Name_Identifier has the format 611 shown in figure 9 [FC-FS]. 613 0 1 2 3 614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | OUI with complemented U/L bit |0 0 0 1| VSID | 617 +---------------+---------------+-------+-------+-------+-------+ 618 | VSID | 0x000 | 619 +---------------+---------------+-------+-------+---------------+ 621 Fig. 9: EUI-64 Address from a Format 0x1 Name_Identifier 623 The IPv6 Interface Identifier is obtained from this EUI-64 address by 624 complementing the U/L bit in the OUI field. So the OUI in the IPv6 625 Interface ID is exactly as in the FC Name_Identifier. The resulting 626 IPv6 Interface Identifier has local scope [AARCH] and the format 627 shown in figure 10. 629 0 1 2 3 630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | OUI |0 0 0 1| VSID | 633 +---------------+---------------+-------+-------+-------+-------+ 634 | VSID | 0x000 | 635 +---------------+---------------+-------+-------+---------------+ 637 Fig. 10: IPv6 Interface ID from a Format 0x1 Name_Identifier 639 As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF 640 generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. 642 5.3. Generating an Interface ID from a Format 2 N_Port_Name 644 The Name_Identifier format 0x2 is shown in figure 11. 646 0 1 2 3 647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 |0 0 1 0| Vendor Specific | OUI | 650 +-------+-------+---------------+---------------+---------------+ 651 | OUI | VSID | 652 +---------------+---------------+---------------+---------------+ 654 Fig. 11: Format 0x2 Name_Identifier 656 The EUI-64 address derived from this Name_Identifier has the format 657 shown in figure 12 [FC-FS]. 659 0 1 2 3 660 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | OUI with complemented U/L bit |0 0 1 0| VSID | 663 +---------------+-----------------------+-------+-------+-------+ 664 | VSID | Vendor Specific | 665 +---------------+-----------------------+-------+---------------+ 667 Fig. 12: EUI-64 Address from a Format 0x2 Name_Identifier 669 The IPv6 Interface Identifier is obtained from this EUI-64 address by 670 complementing the U/L bit in the OUI field. So the OUI in the IPv6 671 Interface ID is exactly as in the FC Name_Identifier. The resulting 672 IPv6 Interface Identifier has local scope [AARCH] and the format 673 shown in figure 13. 675 0 1 2 3 676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | OUI |0 0 1 0| VSID | 679 +---------------+-----------------------+-------+-------+-------+ 680 | VSID | Vendor Specific | 681 +---------------+-----------------------+-------+---------------+ 683 Fig. 13: IPv6 Interface ID from a Format 0x2 Name_Identifier 685 As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF 686 generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. 688 5.4. Generating an Interface ID from a Format 5 N_Port_Name 690 The Name_Identifier format 0x5 is shown in figure 14. 692 0 1 2 3 693 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |0 1 0 1| OUI | VSID | 696 +-------+-------+---------------+---------------+-------+-------+ 697 | VSID | 698 +---------------+---------------+---------------+---------------+ 700 Fig. 14: Format 0x5 Name_Identifier 702 The EUI-64 address derived from this Name_Identifier has the format 703 shown in figure 15 [FC-FS]. 705 0 1 2 3 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | OUI with complemented U/L bit |0 1 0 1| VSID | 709 +---------------+---------------+---------------+-------+-------+ 710 | VSID | 711 +---------------+---------------+---------------+---------------+ 713 Fig. 15: EUI-64 Address from a Format 0x5 Name_Identifier 715 The IPv6 Interface Identifier is obtained from this EUI-64 address 716 complementing the U/L bit in the OUI field. So the OUI in the IPv6 717 Interface ID is exactly as in the FC Name_Identifier. The resulting 718 IPv6 Interface Identifier has local scope [AARCH] and the format 719 shown in figure 16. 721 0 1 2 3 722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | OUI |0 1 0 1| VSID | 725 +---------------+---------------+---------------+-------+-------+ 726 | VSID | 727 +---------------+---------------+---------------+---------------+ 729 Fig. 16: IPv6 Interface ID from a Format 0x5 Name_Identifier 731 As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 732 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. 734 5.5. Generating an Interface ID from an EUI-64 mapped N_Port_Name 736 The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) 737 are derived from an EUI-64 address by compressing the OUI field of 738 such addresses. The compression is performed by removing from the 739 OUI the Universal/Local and Individual/Group bits, and by putting 740 bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and 741 bits 8 to 23 of the OUI in the second and third octet of the 742 Name_Identifier, as shown in figure 17. 744 0 1 2 3 745 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |1 1| OUI[0..5] | OUI[8..23] | VSID | 748 +---+-----------+---------------+---------------+---------------+ 749 | VSID | 750 +---------------+---------------+---------------+---------------+ 752 Fig. 17: EUI-64 Mapped Name_Identifiers Format 754 The EUI-64 address used to generate the Name_Identifier shown in 755 figure 17 has the format shown in figure 18. 757 0 1 2 3 758 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | OUI[0..5] |0 0| OUI[8..23] | VSID | 761 +-----------+---+---------------+---------------+---------------+ 762 | VSID | 763 +---------------+---------------+---------------+---------------+ 765 Fig. 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier 767 The IPv6 Interface Identifier is obtained from this EUI-64 address by 768 complementing the U/L bit in the OUI field. The resulting IPv6 769 Interface Identifier has global scope [AARCH] and the format shown in 770 figure 19. 772 0 1 2 3 773 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | OUI[0..5] |1 0| OUI[8..23] | VSID | 776 +-----------+---+---------------+---------------+---------------+ 777 | VSID | 778 +---------------+---------------+---------------+---------------+ 780 Fig. 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier 782 As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A 783 generates the IPv6 Interface Identifier 3663:46AB:0125:789A. 785 6. Link-Local Addresses 787 The IPv6 link-local address [AARCH] for an Nx_Port is formed by 788 appending the Interface Identifier, as defined in section 5, to the 789 prefix FE80::/64. The resulting address is shown in figure 20. 791 10 bits 54 bits 64 bits 792 +----------+-----------------------+----------------------------+ 793 |1111111010| (zeros) | Interface Identifier | 794 +----------+-----------------------+----------------------------+ 796 Fig. 20: IPv6 link-local Address Format 798 7. ARP Packet Format 800 The Address Resolution Protocol defined in [ARP] is designed to be a 801 general purpose protocol, to accommodate many network technologies 802 and many upper layer protocols. 804 [RFC-2625] chose to use for Fibre Channel the same ARP packet format 805 used for Ethernet networks. In order to do that, [RFC-2625] 806 restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1. 807 While this may have been a reasonable choice at that time, today 808 there are Nx_Ports with N_Port_Name format other than 0x1 in 809 widespread use. 811 This specification accommodates Nx_Ports with N_Port_Names of format 812 different than 0x1 by defining a Fibre Channel specific version of 813 the ARP protocol (FC ARP), carrying both N_Port_Name and N_Port_ID as 814 ARP HW address. 816 IANA has registered the number 18 (decimal) to identify Fibre Channel 817 as ARP HW type. The FC ARP packet format is shown in figure 21. The 818 length of the FC ARP packet is 40 octets. 820 0 1 2 3 821 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | HW Type = 0x0012 | Protocol = 0x0800 | 824 +---------------+---------------+---------------+---------------+ 825 | HW Len = 12 | Proto Len = 4 | Opcode | 826 +---------------+---------------+---------------+---------------+ 827 | | 828 +- -+ 829 | HW Address of Sender | 830 +- -+ 831 | | 832 +---------------+---------------+---------------+---------------+ 833 | Protocol Address of Sender | 834 +---------------+---------------+---------------+---------------+ 835 | | 836 +- -+ 837 | HW Address of Target | 838 +- -+ 839 | | 840 +---------------+---------------+---------------+---------------+ 841 | Protocol Address of Target | 842 +---------------+---------------+---------------+---------------+ 844 Fig. 21: FC ARP Packet Format 846 The following code points MUST be used with FC ARP: 848 - HW Type: 0x0012 (Fibre Channel); 849 - Protocol: 0x0800 (IPv4); 850 - HW Len: 12 (Length in octets of the HW Address); 851 - Proto Len: 4 (Length in octets of the Protocol Address); 852 - Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply; 853 - HW Address of Sender: the N_Port_Name and N_Port_ID of the 854 Requester in an ARP Request, or those of the Responder in an ARP 855 Reply; 856 - Protocol Address of Sender: the IPv4 address of the Requester in 857 an ARP Request, or that of the Responder in an ARP Reply; 858 - HW Address of Target: set to zero in an ARP Request, and to the 859 N_Port_Name and N_Port_ID of the Requester in an ARP Reply; 860 - Protocol Address of Target: the IPv4 address of the Responder in 861 an ARP Request, or that of the Requester in an ARP Reply. 863 The format of the HW address for Fibre Channel ARP is shown in figure 864 22. 866 0 1 2 3 867 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 +- N_Port_Name -+ 871 | | 872 +---------------+---------------+---------------+---------------+ 873 | Reserved | N_Port_ID | 874 +---------------+---------------+---------------+---------------+ 876 Fig. 22: FC ARP HW Address Format 878 Reserved fields MUST be set to zero when transmitting, and MUST be 879 ignored when receiving. 881 8. Address Mapping for Unicast 883 8.1. Overview 885 An Nx_Port has two kinds of Fibre Channel addresses: 887 - a non-volatile 64-bit address, called N_Port_Name; 888 - a volatile 24-bit address, called N_Port_ID. 890 The N_Port_Name is used to uniquely identify the Nx_Port, while the 891 N_Port_ID is used to route frames to the Nx_Port. Both FC addresses 892 are required to resolve an IPv6 or IPv4 unicast address. The fact 893 that the N_Port_ID is volatile implies that an Nx_Port MUST validate 894 the mapping between its N_Port_Name and N_Port_ID when certain Fibre 895 Channel events occur (see Appendix B). 897 8.2. IPv6 Address Mapping 899 The procedure for mapping IPv6 unicast addresses into Fibre Channel 900 link-layer addresses uses the Neighbor Discovery Protocol [DISC]. 901 The Source/Target Link-layer Address option has the format shown in 902 figure 23 when the link layer is Fibre Channel. 904 0 1 2 3 905 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Type | Length = 2 | Reserved | 908 +---------------+---------------+---------------+---------------+ 909 | | 910 +- N_Port_Name -+ 911 | | 912 +---------------+---------------+---------------+---------------+ 913 | Reserved | N_Port_ID | 914 +---------------+---------------+---------------+---------------+ 916 Fig. 23: Source/Target Link-layer Address option for Fibre Channel 918 Type: 1 for Source Link-layer address. 919 2 for Target Link-layer address. 921 Length: 2 (in units of 8 octets). 923 N_Port_Name: This field contains the Nx_Port's N_Port_Name. 924 N_Port_ID: This field contains the Nx_Port's N_Port_ID. 926 Reserved fields MUST be set to zero when transmitting, and MUST be 927 ignored when receiving. 929 8.3. IPv4 Address Mapping 931 The procedure for mapping IPv4 unicast addresses into Fibre Channel 932 link-layer addresses uses the FC ARP protocol, as specified in 933 section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets 934 to a destination Nx_Port, known by its IPv4 address, MUST perform the 935 following steps: 937 1) The source Nx_Port first consults its local mapping tables for a 938 mapping ; 940 2) If such a mapping is found, and a valid Port Login is in place 941 with the destination Nx_Port, then the source Nx_Port sends the 942 IPv4 packets to the destination Nx_Port using the retrieved 943 N_Port_ID as D_ID; 945 3) If such a mapping is not found, or a valid Port Login is not in 946 place with the destination Nx_Port, then the source Nx_Port sends 947 a broadcast FC ARP Request to its connected FC network. Appendix 948 A specifies how to transmit a Class 3 broadcast FC Sequence over 949 various Fibre Channel topologies; 951 4) When a broadcast FC ARP Request is received by the Nx_Port with 952 the matching IPv4 address, it generates a unicast FC ARP Reply. 953 If a valid Port Login to the Nx_Port that sent the broadcast FC 954 ARP Request does not exist, the Nx_Port MUST perform such a Port 955 Login, and then use it for the unicast reply. The N_Port_ID to 956 which the Port Login is directed is taken from the N_Port_ID field 957 of the Sender HW Address field in the received FC ARP packet; 959 5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP 960 Reply is returned. 962 9. Address Mapping for Multicast 964 IPv6 multicast packets, IPv4 multicast and broadcast packets, and ARP 965 broadcast packets MUST be mapped to FC Sequences addressed to the 966 broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional 967 Exchange (see section 11). The Destination N_Port_Name field of the 968 FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. 969 Appendix A specifies how to transmit a Class 3 broadcast FC Sequence 970 over various Fibre Channel topologies. 972 An Nx_Port supporting IPv6 or IPv4 MUST be able to map a received 973 broadcast Class 3 Device_Data FC frame to an implicit Port Login 974 context in order to handle IPv6 multicast packets, IPv4 multicast or 975 broadcast packets and ARP broadcast packets. The receive data field 976 size of this implicit Port Login MUST be the same across all the 977 Nx_Ports connected to the same Fabric, otherwise FC broadcast 978 transmission does not work. In order to reduce the need for FC 979 Sequence segmentation, the receive data field size of this implicit 980 Port Login SHOULD be 1024 octets. This receive data field size 981 requirement applies to broadcast Device_Data FC frames, not to ELSs. 983 Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4 984 multicast or broadcast packet, or an FC ARP broadcast packet triggers 985 some additional processing by the Nx_Port when that IPv6, IPv4 or FC 986 ARP packet requires a unicast reply. In this case, if a valid Port 987 Login to the Nx_Port that sent the multicast or broadcast packet does 988 not exist, the Nx_Port MUST perform such a Port Login, and then use 989 it for the unicast reply. In the case of Neighbor Discovery messages 990 [DISC], the N_Port_ID to which the Port Login is directed is taken 991 from the N_Port_ID field of the Source Link-layer Address option in 992 the received Neighbor Discovery message. In the case of FC ARP 993 messages, the N_Port_ID to which the Port Login is directed is taken 994 from the N_Port_ID field of the Sender HW Address field in the 995 received FC ARP packet. 997 As an example, if a received broadcast FC Sequence carries an IPv6 998 multicast unsolicited router advertisement [DISC], the receiving 999 Nx_Port processes it simply by passing the carried IPv6 packet to the 1000 IPv6 layer. Instead, if a received broadcast FC Sequence carries an 1001 IPv6 multicast solicitation message [DISC] requiring a unicast reply, 1002 and no valid Port Login exists with the Nx_Port sender of the 1003 multicast packet, then a Port Login MUST be performed in order to 1004 send the unicast reply message. If a received broadcast FC Sequence 1005 carries an IPv6 multicast solicitation message [DISC] requiring a 1006 multicast reply, the reply is sent to the broadcast N_Port_ID 1007 0xFFFFFF. 1009 10. Sequence Management 1011 FC Sequences carrying IPv6, IPv4 or ARP packets are REQUIRED to be 1012 non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by 1013 Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to 1014 use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST 1015 start by setting SEQ_CNT to zero in the first frame, and every frame 1016 transmitted after that MUST increment the previous SEQ_CNT by one. 1017 The Continue Sequence Condition field in the F_CTL field of the FC 1018 Header MUST be set to zero [FC-FS]. 1020 11. Exchange Management 1022 To transmit IPv6, IPv4 or ARP packets to another Nx_Port or to a 1023 multicast/broadcast address, an Nx_Port MUST use dedicated 1024 unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4 or 1025 ARP packet transmission and that do not transfer Sequence 1026 Initiative). As such, the Sequence Initiative bit in the F_CTL field 1027 of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the 1028 FC Header MUST be set to 0xFFFF. 1030 Unicast FC Sequences carrying unicast Control Protocol packets (e.g., 1031 ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor 1032 Discovery [DISC] or Multicast Listener Discovery [MLDv2] messages; 1033 IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD 1034 be sent in short lived unidirectional Exchanges (i.e., Exchanges 1035 containing only one Sequence, in which both the First_Sequence and 1036 Last_Sequence bits in the F_CTL field of the FC Header are set to one 1037 [FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets 1038 (i.e., unicast IP packets carrying data traffic) MUST be sent in a 1039 long lived unidirectional Exchange (i.e., an Exchange containing one 1040 or more Sequences). IP multicast packets MUST NOT be carried in 1041 unicast FC Sequences (see section 9). 1043 Broadcast FC Sequences carrying multicast or broadcast Control 1044 Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 1045 [ICMPv6], Neighbor Discovery [DISC] or Multicast Listener Discovery 1047 [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP 1048 [IGMPv3] messages) MUST be sent in short lived unidirectional 1049 Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4 1050 multicast traffic (i.e., multicast IP packets carrying data traffic) 1051 MAY be sent in long lived unidirectional Exchanges to enable a more 1052 efficient multicast distribution. 1054 Reasons to terminate a long lived Exchange include the termination of 1055 Port Login and the completion of the IP communication. A long lived 1056 Exchange MAY be terminated by setting to one the Last_Sequence bit in 1057 the F_CTL field of the FC Header, or via the ABTS (Abort Sequence) 1058 protocol [FC-FS]. A long lived Exchange SHOULD NOT be terminated by 1059 transmitting the LOGO ELS, since this may terminate active Exchanges 1060 on other FC-4s [FC-FS]. 1062 12. Interoperability with [RFC-2625] 1064 The IPv4 encapsulation defined in this document, along with Exchange 1065 and Sequence management, are as defined in [RFC-2625]. 1066 Implementations following this specification should interoperate 1067 with implementations compliant to [RFC-2625] for IPv4 packets 1068 transmission and reception. 1070 The main difference between this document and [RFC-2625] is in the 1071 address resolution procedure. [RFC-2625] uses the Ethernet format of 1072 the ARP protocol, and requires all Nx_Ports to have a format 0x1 1073 N_Port_Name. This specification defines a Fibre Channel format for 1074 the ARP protocol that supports all commonly used N_Port_Names. In 1075 addition, this specification does not use FARP [RFC-2625]. 1077 An Nx_Port following this specification, and not using format 0x1 1078 N_Port_Name, is able to interoperate with an [RFC-2625] 1079 implementation by manually configuring the mapping on the involved Nx_Ports. Through 1081 this manual configuration, the ARP protocol does not need to be 1082 performed. However, issues may still arise in the IPv4 packet 1083 communication if the [RFC-2625] implementation strictly enforces the 1084 requirement for Nx_Ports to use N_Port_Names of format 0x1. 1086 An Nx_Port following this specification, and having a format 0x1 1087 N_Port_Name, is able to interoperate with an [RFC-2625] 1088 implementation by using the manual configuration approach described 1089 above, or by performing the IPv4 address resolution as described 1090 below. Each implementation MUST implement the behavior described 1091 below, but the use of this behavior MUST be administratively 1092 configurable. 1094 - The Nx_Port MUST send, when IPv4 address resolution is attempted, 1095 two ARP Requests separated by a short time interval (e.g., less 1096 than one second), the first one according to the FC ARP format and 1097 the second one according to the Ethernet ARP format. The Nx_Port 1098 should then process the first ARP Reply received. If only an 1099 Ethernet ARP Reply is received, it provides the N_Port_Name of the 1100 Nx_Port having the destination IPv4 address. The N_Port_ID 1101 associated with the N_Port_Name received in an Ethernet ARP Reply 1102 may be retrieved from the S_ID field of the received ARP Reply, or 1103 by querying the Fibre Channel Name Server; 1104 - The Nx_Port MUST respond to a received Ethernet ARP Request with 1105 an Ethernet ARP Reply; 1106 - The Nx_Port MAY respond to FARP Requests [FC-FS]. 1108 The reception of a particular format of ARP message does not imply 1109 that the sending NX_Port will continue to use the same format later. 1111 13. Security Considerations 1113 IPv6, IPv4 and ARP do not introduce any additional security concerns 1114 beyond those that already exist within the Fibre Channel protocols. 1115 Zoning techniques based on FC Name Server masking (soft zoning) do 1116 not work with IPv6 and IPv4, because IPv6 and IPv4 over Fibre Channel 1117 do not use the FC Name Server. The FC ESP_Header [FC-FS] may be used 1118 to secure the FC frames composing FC Sequences carrying IPv6, IPv4 1119 and ARP packets. All the techniques defined to secure IP traffic at 1120 the IP layer may be used in a Fibre Channel environment. 1122 14. IANA Considerations 1124 The directory of ARP parameters should reference this document, when 1125 published, for hardware type 18. 1127 15. Acknowledgments 1129 The authors would like to acknowledge the ANSI INCITS T11.3 Task 1130 Group members who reviewed this document. 1132 16. Normative References 1134 [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and 1135 Signaling (FC-FS)". 1137 [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 1138 (FC-AL-2)". 1140 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1141 (IPv6) Specification", RFC 2460, December 1998. 1143 [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 1144 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1146 [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address 1147 Autoconfiguration", RFC 2462, December 1998. 1149 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1150 Discovery for IP Version 6 (IPv6)", RFC 2461, 1151 December 1998. 1153 [PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU 1154 Discovery for IP version 6", RFC 1981, August 1996. 1156 [IPv4] Postel, J., "Internet Protocol", STD-5, RFC 791, 1157 September 1981. 1159 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol 1160 -or- Converting Network Addresses to 48-bit Ethernet 1161 Address for Transmission on Ethernet Hardware", 1162 STD-37, RFC 826, November 1982. 1164 [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and 1165 Metropolitan Area Networks: Overview and Architecture". 1167 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1168 Requirement Levels", BCP 14, RFC 2119, March 1997. 1170 17. Informative References 1172 [RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre 1173 Channel", RFC 3831, July 2004. 1175 [RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP 1176 over Fibre Channel", RFC 2625, June 1999. 1178 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 1179 RFC 2402, November 1998. 1181 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 1182 Payload (ESP)", RFC 2406, November 1998. 1184 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 1185 Protocol (ICMPv6) for the Internet Protocol Version 6 1186 (IPv6) Specification", RFC 2463, December 1998. 1188 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD-5, 1189 RFC 792, September 1981. 1191 [MLDv2] Vida, R. and R. Costa, "Multicast Listener Discovery 1192 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1194 [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, W., and A. 1195 Thyagarajan, "Internet Group Management Protocol, 1196 Version 3", RFC 3376, October 2002. 1198 [PMTUD4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 1199 November 1990. 1201 [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", 1202 http://standards.ieee.org/db/oui/tutorials/EUI64.html 1204 18. Authors' Address 1206 Claudio DeSanti 1207 Cisco Systems, Inc. 1208 170 W. Tasman Dr. 1209 San Jose, CA 95134 1210 USA 1212 Phone: +1 408 853-9172 1213 EMail: cds@cisco.com 1215 Craig W. Carlson 1216 QLogic Corporation 1217 6321 Bury Drive 1218 Eden Prairie, MN 55346 1219 USA 1221 Phone: +1 952 932-4064 1222 Email: craig.carlson@qlogic.com 1224 Robert Nixon 1225 Emulex 1226 3333 Susan Street 1227 Costa Mesa, CA 92626 1228 USA 1230 Phone: +1 714 885-3525 1231 EMail: bob.nixon@emulex.com 1233 A. Transmission of a Broadcast FC Sequence over FC Topologies 1234 (Informative) 1236 A.1. Point-to-Point Topology 1238 No particular mechanisms are required for this case. The Nx_Port 1239 connected at the other side of the cable receives the broadcast FC 1240 Sequence having D_ID 0xFFFFFF. 1242 A.2. Private Loop Topology 1244 An NL_Port attached to a private loop must transmit a Class 3 1245 broadcast FC Sequence by using the OPN(fr) primitive signal 1246 [FC-AL-2]. 1248 1) The source NL_Port first sends an Open Broadcast Replicate 1249 (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop 1250 (except itself) to replicate the frames that they receive while 1251 examining the FC Header's D_ID field. 1252 2) The source NL_Port then removes the OPN(fr) signal when it returns 1253 to it. 1254 3) The source NL_Port then sends the Class 3 broadcast FC Sequence 1255 having D_ID 0xFFFFFF. 1257 A.3. Public Loop Topology 1259 An NL_Port attached to a public loop must not use the OPN(fr) 1260 primitive signal. Rather, it must send the Class 3 broadcast FC 1261 Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 1262 [FC-AL-2]. 1264 The Fabric propagates the broadcast to all other FC_Ports [FC-FS], 1265 including the FL_Port which the broadcast arrives on. This includes 1266 all F_Ports, and other FL_Ports. 1268 Each FL_Port propagates the broadcast by using the primitive signal 1269 OPN(fr), in order to prepare the loop to receive the broadcast 1270 sequence. 1272 A.4. Fabric Topology 1274 An N_Port connected to an F_Port must transmit the Class 3 broadcast 1275 FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric 1276 propagates the broadcast to all other FC_Ports [FC-FS]. 1278 B. Validation of the mapping 1279 (Informative) 1281 B.1. Overview 1283 At all times, the mapping must be valid 1284 before use. 1286 After an FC link interruption occurs, the N_Port_ID of an Nx_Port may 1287 change, as well as the N_Port_IDs of all other Nx_Ports that have 1288 previously performed Port Login with this Nx_Port. Because of this, 1289 address validation is required after a LIP in a loop topology 1290 [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS]. 1292 N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus 1293 address validation is not required in this case. 1295 B.2. FC Layer Address Validation in a Point-to-Point Topology 1297 No validation is required after Link Reset (LR). In a point-to-point 1298 topology, NOS/OLS causes implicit Logout of each N_Port and after a 1299 NOS/OLS each N_Port must again perform a Port Login [FC-FS]. 1301 B.3. FC Layer Address Validation in a Private Loop Topology 1303 After a LIP [FC-AL-2], an NL_Port must not transmit any data to 1304 another NL_Port until the address of the other port has been 1305 validated. The validation consists of completing ADISC [FC-FS]. 1307 If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a 1308 logged remote NL_Port exactly match the values prior to the LIP, then 1309 any active Exchange with that NL_Port may continue. 1311 If any of the three FC addresses has changed, then the remote NL_Port 1312 must be logged out. 1314 If an NL_Port's N_Port_ID changes after a LIP, then all active logged 1315 in NL_Ports must be logged out. 1317 B.4. FC Layer Address Validation in a Public Loop Topology 1319 A FAN ELS may be sent by the Fabric to all known previously logged in 1320 NL_Ports following an initialization event. Therefore, after a LIP 1321 [FC-AL-2], NL_Ports may wait for this notification to arrive, or they 1322 may perform an FLOGI. 1324 If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI 1325 response exactly match the values before the LIP and if the AL_PA 1326 [FC-AL-2] obtained by the NL_Port is the same as the one before the 1327 LIP, then the port may resume all Exchanges. If not, then FLOGI must 1328 be performed with the Fabric and all logged in Nx_Ports must be 1329 logged out. 1331 A public loop NL_Port must perform the private loop validation as 1332 specified in section B.3 to any NL_Port on the local loop that has an 1333 N_Port_ID of the form 0x00-00-XX (i.e., to any private loop NL_Port). 1335 B.5. FC Layer Address Validation in a Fabric Topology 1337 No validation is required after Link Reset (LR). 1339 After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the 1340 N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same 1341 as before the NOS/OLS, then the N_Port may resume all Exchanges. If 1342 not, all logged in Nx_Ports must be logged out [FC-FS]. 1344 C. Fibre Channel Bit and Byte Numbering Guidance 1346 Both Fibre Channel and IETF standards use the same byte transmission 1347 order. However, the bit numbering is different. 1349 Fibre Channel bit numbering can be observed if the data structure 1350 heading shown in figure 24 is cut and pasted at the top of the 1351 figures present in this document. 1353 3 2 1 0 1354 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 Fig. 24: Fibre Channel Bit Numbering 1359 D. Changes from [RFC-2625] 1361 - Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF 1362 are supported, in addition to format 0x1; 1363 - An IP capable Nx_Port MUST support Class 3; 1364 - An IP capable Nx_Port MUST support continuously increasing 1365 SEQ_CNT; 1366 - An IP capable Nx_Port SHOULD support a receive data field size for 1367 Device_Data FC frames of at least 1024 octets; 1368 - The FC ESP_Header MAY be used; 1369 - FC Classes of services other than 3 are not supported; 1370 - Defined a new FC ARP format; 1371 - Removed support for FARP, because it becomes useless with the new 1372 FC ARP and its usage creates interoperability issues, given that 1373 it is not uniformely implemented; 1374 - Added support for IPv4 multicast; 1375 - Clarified the usage of the CS_CTL and Parameter fields of the FC 1376 Header; 1377 - Clarified the usage of FC Classes of service; 1378 - Clarified the usage of FC Sequences and Exchanges. 1380 E. Changes from [RFC-3831] 1382 - Clarified the usage of the CS_CTL and Parameter fields of the FC 1383 Header; 1384 - Clarified the usage of FC Classes of service; 1385 - Clarified the mapping of IPv6 multicast on Fibre Channel; 1386 - Clarified the usage of FC Sequences and Exchanges. 1388 Intellectual Property Statement 1390 The IETF takes no position regarding the validity or scope of any 1391 Intellectual Property Rights or other rights that might be claimed to 1392 pertain to the implementation or use of the technology described in 1393 this document or the extent to which any license under such rights 1394 might or might not be available; nor does it represent that it has 1395 made any independent effort to identify any such rights. Information 1396 on the procedures with respect to rights in RFC documents can be 1397 found in BCP 78 and BCP 79. 1399 Copies of IPR disclosures made to the IETF Secretariat and any 1400 assurances of licenses to be made available, or the result of an 1401 attempt made to obtain a general license or permission for the use of 1402 such proprietary rights by implementers or users of this 1403 specification can be obtained from the IETF on-line IPR repository at 1404 http://www.ietf.org/ipr. 1406 The IETF invites any interested party to bring to its attention any 1407 copyrights, patents or patent applications, or other proprietary 1408 rights that may cover technology that may be required to implement 1409 this standard. Please address the information to the IETF at 1410 ietf-ipr@ietf.org. 1412 Disclaimer of Validity 1414 This document and the information contained herein are provided on an 1415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1417 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1418 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1419 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1422 Copyright Statement 1424 Copyright (C) The Internet Society (2004). This document is subject 1425 to the rights, licenses and restrictions contained in BCP 78, and 1426 except as set forth therein, the authors retain all their rights. 1428 Acknowledgment 1430 Funding for the RFC Editor function is currently provided by the 1431 Internet Society.