idnits 2.17.1 draft-ietf-imss-ip-over-fibre-channel-03.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1411. ** 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. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2625, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3831, but the abstract doesn't seem to mention this, which it should. 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 (November 2005) is 6736 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 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMSS Working Group C. DeSanti 3 Internet Draft Cisco Systems 4 draft-ietf-imss-ip-over-fibre-channel-03.txt C. Carlson 5 Category: Standards Track QLogic Corporation 6 Obsoletes: RFC 2625, RFC 3831 R. Nixon 7 Expires: May 2006 Emulex 8 November 2005 10 Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document specifies the way of encapsulating IPv6, IPv4 and ARP 38 packets over Fibre Channel. This document specifies also the method 39 of forming IPv6 link-local addresses and statelessly autoconfigured 40 IPv6 addresses on Fibre Channel networks, and a mechanism to perform 41 IPv4 address resolution over Fibre Channel networks. 43 Table Of Contents 45 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Summary of Fibre Channel. . . . . . . . . . . . . . . . . . . 4 47 2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2.2 Identifiers and Login . . . . . . . . . . . . . . . . . . . . 4 49 2.3 FC Levels and Frame Format. . . . . . . . . . . . . . . . . . 5 50 2.4 Sequences and Exchanges . . . . . . . . . . . . . . . . . . . 6 51 3. IP Capable Nx_Ports . . . . . . . . . . . . . . . . . . . . . 7 52 4. IPv6, IPv4 and ARP Encapsulation. . . . . . . . . . . . . . . 7 53 4.1 FC Sequence Format for IPv6 and IPv4 Packets. . . . . . . . . 7 54 4.2 FC Sequence Format for ARP Packets. . . . . . . . . . . . . . 9 55 4.3 FC Classes of Service . . . . . . . . . . . . . . . . . . . . 10 56 4.4 FC Header Code Points . . . . . . . . . . . . . . . . . . . . 10 57 4.5 FC Network_Header . . . . . . . . . . . . . . . . . . . . . . 11 58 4.6 LLC/SNAP Header . . . . . . . . . . . . . . . . . . . . . . . 12 59 4.7 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 12 60 4.8 Maximum Transfer Unit . . . . . . . . . . . . . . . . . . . . 12 61 5. IPv6 Stateless Address Autoconfiguration. . . . . . . . . . . 13 62 5.1 IPv6 Interface Identifier and Address Prefix. . . . . . . . . 13 63 5.2 Generating an Interface ID from a Format 1 N_Port_Name. . . . 14 64 5.3 Generating an Interface ID from a Format 2 N_Port_Name. . . . 15 65 5.4 Generating an Interface ID from a Format 5 N_Port_Name. . . . 16 66 5.5 Generating an Interface ID from an EUI-64 mapped N_Port_Name. 17 67 6. Link-Local Addresses. . . . . . . . . . . . . . . . . . . . . 18 68 7. ARP Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 69 8. Link-layer Address/Hardware Address . . . . . . . . . . . . . 20 70 9. Address Mapping for Unicast . . . . . . . . . . . . . . . . . 20 71 9.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 9.2 IPv6 Address Mapping. . . . . . . . . . . . . . . . . . . . . 20 73 9.3 IPv4 Address Mapping. . . . . . . . . . . . . . . . . . . . . 21 74 10. Address Mapping for Multicast . . . . . . . . . . . . . . . . 22 75 11. Sequence Management . . . . . . . . . . . . . . . . . . . . . 23 76 12. Exchange Management . . . . . . . . . . . . . . . . . . . . . 23 77 13. Interoperability with [RFC-2625]. . . . . . . . . . . . . . . 24 78 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 17. Normative References. . . . . . . . . . . . . . . . . . . . . 26 82 18. Informative References. . . . . . . . . . . . . . . . . . . . 26 83 19. Authors' 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 obsoletes [RFC-2625]. 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 obsoletes 123 [RFC-3831]. 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 that does not operate in a loop topology is called an 154 N_Port. A Node Port that operates in a loop topology using the loop 155 specific protocols is designated as an NL_Port. The term Nx_Port is 156 used to indicate a Node Port that is capable of operating in either 157 mode. 159 A Fabric Port that does not operate in a loop topology is called an 160 F_Port. A Fabric Port that operates in a loop topology using the 161 loop specific protocols is designated as an FL_Port. The term 162 Fx_Port is used to indicate a Fabric Port that is capable of 163 operating in either mode. 165 A Fibre Channel network, built with any combination of the FC 166 topologies described above, is a multiaccess network with broadcast 167 capabilities. 169 From an IPv6 point of view, a Fibre Channel network is an IPv6 Link 170 [IPv6]. IP-capable Nx_Ports are what [IPv6] calls Interfaces. 172 From an IPv4 point of view, a Fibre Channel network is an IPv4 Local 173 Network [IPv4]. IP-capable Nx_Ports are what [IPv4] calls Local 174 Network Interfaces. 176 2.2. Identifiers and Login 178 Fibre Channel entities are identified by non-volatile 64-bit 179 Name_Identifiers. [FC-FS] defines several formats of 180 Name_Identifiers. The value of the most significant four bits 181 defines the format of a Name_Identifier. These Name_Identifiers are 182 referred to in a more concise manner as follows: 184 - an Nx_Port's Name_Identifier is called N_Port_Name; 185 - an Fx_Port's Name_Identifier is called F_Port_Name; 186 - a Node's Name_Identifier is called Node_Name; 187 - a Fabric's Name_Identifier is called Fabric_Name. 189 An Nx_Port connected to a Fibre Channel network is associated with 190 two identifiers, its non-volatile N_Port_Name and a volatile 24-bit 191 address called N_Port_ID. The N_Port_Name is used to identify the 192 Nx_Port, while the N_Port_ID is used for communications among 193 Nx_Ports. 195 Each Nx_Port acquires an N_Port_ID from the Fabric by performing a 196 process called Fabric Login or FLOGI. The FLOGI process is used also 197 to negotiate several communications parameters between the Nx_Port 198 and the Fabric, such as the receive data field size, which determines 199 the maximum size of the Fibre Channel frames that may be transferred 200 between the Nx_Port and the Fabric. 202 Before effective communication may take place between two Nx_Ports, 203 they must complete a process called Port Login or PLOGI. The PLOGI 204 process provides each Nx_Port with the other Nx_Port's N_Port_Name, 205 and negotiates several communication parameters, such as the receive 206 data field size, which determines the maximum size of the Fibre 207 Channel frames that may be transferred between the two Nx_Ports. 209 Both Fabric Login and Port Login may be explicit (i.e., performed 210 using specific FC control messages called Extended Link Services or 211 ELS), or implicit (i.e., in which the parameters are specified by 212 configuration or other methods). 214 2.3. FC Levels and Frame Format 216 [FC-FS] describes the Fibre Channel protocol using 5 different 217 levels. The FC-2 and FC-4 levels are relevant for this 218 specification. The FC-2 level defines the FC frame format, the 219 transport services, and the control functions necessary for 220 information transfer. The FC-4 level supports Upper Level Protocols, 221 such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is shown 222 in figure 1. 224 +-----+-----------+-----------+--------//-------+-----+-----+ 225 | | | Data Field | | | 226 | SOF | FC Header |<--------------------------->| CRC | EOF | 227 | | | Optional | Frame | | | 228 | | | Header(s) | Payload | | | 229 +-----+-----------+-----------+--------//-------+-----+-----+ 231 Fig. 1: Fibre Channel Frame Format 233 The Start of Frame (SOF) and End of Frame (EOF) are special FC 234 transmission words that act as frame delimiters. The CRC is 4 octets 235 long and is used to verify the integrity of a frame. 237 The FC Header is 24 octets long and contains several fields 238 associated with the identification and control of the Data Field. 240 The Data Field is of variable size, ranging from 0 to 2112 octets, 241 and includes the user data in the Frame Payload field, and Optional 242 Headers. The currently defined Optional Headers are: 244 - ESP_Header; 245 - Network_Header; 246 - Association_Header; 247 - Device_Header. 249 The value of the SOF field determines the FC Class of service 250 associated with the frame. Five Classes of service are specified in 251 [FC-FS]. They are distinguished primarily by the method of flow 252 control between the communicating Nx_Ports and by the level of data 253 integrity provided. A given Fabric or Nx_Port may support one or 254 more of the following Classes of service: 256 - Class 1: Dedicated physical connection with delivery confirmation; 257 - Class 2: Frame multiplexed service with delivery confirmation; 258 - Class 3: Datagram service; 259 - Class 4: Fractional bandwidth; 260 - Class 6: Reliable multicast via dedicated connections. 262 Class 3 and 2 are commonly used for storage networking applications; 263 Class 1 and 6 are typically used for specialized applications in 264 avionics. Class 3 is recommended for IPv6, IPv4 and ARP (see section 265 4.3). 267 2.4. Sequences and Exchanges 269 An application level payload such as an IPv6 or IPv4 packet is called 270 an Information Unit at the FC-4 level of Fibre Channel. Each FC-4 271 Information Unit is mapped to an FC Sequence by the FC-2 level. An 272 FC Sequence consists of one or more FC frames related by the value of 273 the Sequence_ID (SEQ_ID) field of the FC Header. 275 The architectural maximum data that may be carried by an FC frame is 276 2112 octets. The maximum usable frame size depends on the Fabric and 277 Nx_Port implementations and is negotiated during the Login process. 278 Whenever an Information Unit to be transmitted exceeds this value, 279 the FC-2 level segments it into multiple FC frames, sent as a single 280 Sequence. The receiving Nx_Port reassembles the Sequence of frames 281 and delivers a reassembled Information Unit to the FC-4 level. The 282 Sequence Count (SEQ_CNT) field of the FC Header may be used to ensure 283 frame ordering. 285 Multiple Sequences may be related together as belonging to the same 286 FC Exchange. The Exchange is a mechanism used by two Nx_Ports to 287 identify and manage an operation between them. The Exchange is 288 opened when the operation is started between the two Nx_Ports, and 289 closed when the operation ends. FC frames belonging to the same 290 Exchange are related by the value of the Exchange_ID fields in the FC 291 Header. An Originator Exchange_ID (OX_ID) and a Responder 292 Exchange_ID (RX_ID) uniquely identify the Exchange between a pair of 293 Nx_Ports. 295 3. IP Capable Nx_Ports 297 This specification requires an IP capable Nx_Port to have the 298 following properties: 300 - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 301 0xD, 0xE, 0xF (see section 5.1); 302 - It MUST support Class 3; 303 - It MUST support continuously increasing SEQ_CNT [FC-FS]; 304 - It MUST be able to transmit and receive an FC-4 Information Unit 305 at least 1304 octets long (see section 4.1); 306 - It SHOULD support a receive data field size for Device_Data FC 307 frames of at least 1024 octets (see section 10). 309 4. IPv6, IPv4 and ARP Encapsulation 311 4.1. FC Sequence Format for IPv6 and IPv4 Packets 313 An IPv6 or IPv4 packet is mapped to an Information Unit at the FC-4 314 level of Fibre Channel, which in turn is mapped to an FC Sequence by 315 the FC-2 level [FC-FS]. An FC Information Unit containing an IP 316 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP 317 header [IEEE-LLC], resulting in the FC Information Unit format shown 318 in figure 2. 320 +---------------+---------------+---------------+---------------+ 321 | | 322 +- -+ 323 | Network_Header | 324 +- (16 octets) -+ 325 | | 326 +- -+ 327 | | 328 +---------------+---------------+---------------+---------------+ 329 | LLC/SNAP header | 330 +- (8 octets) -+ 331 | | 332 +---------------+---------------+---------------+---------------+ 333 | | 334 +- -+ 335 / IPv6 or IPv4 Packet / 336 / / 337 +- -+ 338 | | 339 +---------------+---------------+---------------+---------------+ 341 Fig. 2: FC Information Unit Mapping an IP Packet 343 In order to support the minimum IPv6 MTU (i.e., 1280 octects) an 344 Nx_Port supporting IP MUST be able to transmit and receive an FC-4 345 Information Unit at least 1304 octets long (i.e., 1280 + 8 + 16). 347 The FC ESP_Header [FC-FS] MAY be used to secure the FC frames 348 composing an IP FC Sequence. Other types of FC Optional Header MUST 349 NOT be used in an IP FC Sequence. 351 An IP FC Sequence often consists of more than one frame, all frames 352 having the same TYPE (see section 4.4). The first frame of the 353 Sequence MUST include the FC Network_Header and the LLC/SNAP header. 354 The other frames MUST NOT include them, as shown in figure 3. 356 First Frame of an IP FC Sequence 357 +-----------+-------------------+-----------------+-------//--------+ 358 | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | 359 | | | | the IP Packet | 360 +-----------+-------------------+-----------------+-------//--------+ 362 Subsequent Frames of an IP FC Sequence 363 +-----------+-----------------//--------------------+ 364 | FC Header | Additional chunk of the IP Packet | 365 +-----------+----------------//---------------------+ 367 Fig. 3: Optional Headers in an IP FC Sequence 369 4.2. FC Sequence Format for ARP Packets 371 An ARP packet is mapped to an Information Unit at the FC-4 level of 372 Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 373 level. An FC Information Unit containing an ARP packet MUST carry 374 the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], 375 resulting to the FC Information Unit format shown in figure 4. 377 +---------------+---------------+---------------+---------------+ 378 | | 379 +- -+ 380 | Network_Header | 381 +- (16 octets) -+ 382 | | 383 +- -+ 384 | | 385 +---------------+---------------+---------------+---------------+ 386 | LLC/SNAP header | 387 +- (8 octets) -+ 388 | | 389 +---------------+---------------+---------------+---------------+ 390 | | 391 +- -+ 392 / ARP Packet / 393 / / 394 +- -+ 395 | | 396 +---------------+---------------+---------------+---------------+ 398 Fig. 4: FC Information Unit Mapping an ARP Packet 400 Given the limited size of an ARP packet (see section 7), an FC 401 Sequence carrying an ARP packet MUST be mapped to a single FC frame, 402 that MUST include the FC Network_Header and the LLC/SNAP header. 404 The FC ESP_Header [FC-FS] MAY be used to secure an FC frame carrying 405 an ARP packet. Other types of FC Optional Header MUST NOT be used in 406 an FC frame carrying an ARP packet. 408 4.3. FC Classes of Service 410 This specification uses FC Class 3. The following types of packets 411 MUST be mapped in Class 3 FC frames: 413 - multicast IPv6 packets; 414 - multicast/broadcast IPv4 packets; 415 - Control Protocol packets (e.g., ARP packets; IPv6 packets carrying 416 ICMPv6 [ICMPv6], Neighbor Discovery [DISC] or Multicast Listener 417 Discovery [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or 418 IGMP [IGMPv3] messages; IPv6 and IPv4 Routing Protocols packets). 420 Other IPv6 and IPv4 packets (i.e., unicast IP packets carrying data 421 traffic) SHOULD be mapped in Class 3 FC frames as well. Support for 422 reception of IPv4 or IPv6 packets mapped in FC frames of any Class 423 other than Class 3 is OPTIONAL; receivers MAY ignore them. 425 4.4. FC Header Code Points 427 The fields of the Fibre Channel Header are shown in figure 5. The 428 D_ID and S_ID fields contain respectively the destination N_Port_ID 429 and the source N_Port_ID. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | R_CTL | D_ID | 435 +---------------+---------------+---------------+---------------+ 436 | CS_CTL/Prio | S_ID | 437 +---------------+---------------+---------------+---------------+ 438 | TYPE | F_CTL | 439 +---------------+---------------+---------------+---------------+ 440 | SEQ_ID | DF_CTL | SEQ_CNT | 441 +---------------+---------------+---------------+---------------+ 442 | OX_ID | RX_ID | 443 +---------------+---------------+---------------+---------------+ 444 | Parameter | 445 +---------------+---------------+---------------+---------------+ 447 Fig. 5: FC Header Format 449 To encapsulate IPv6 and IPv4 over Fibre Channel the following code 450 points apply. When a single value is listed without further 451 qualification that value MUST be used: 453 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 454 Category [FC-FS]); 455 - TYPE: 0x05 (IP over Fibre Channel); 456 - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; 457 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 or 458 IPv4 Sequence, 0x00 for the following FC frames. If the FC 459 ESP_Header is used, then 0x60 for the first FC frame of an IPv6 or 460 IPv4 Sequence, 0x40 for the following FC frames; 461 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12, 462 and [FC-FS] for additional requirements; 463 - Parameter: if Relative Offset [FC-FS] is not used, the content of 464 this field MUST be ignored by the receiver, and SHOULD be set to 465 zero by the sender. If Relative Offset is used, see [FC-FS]. 467 To encapsulate ARP over Fibre Channel the following code points 468 apply. When a single value is listed without further qualification 469 that value MUST be used: 471 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 472 Category [FC-FS]); 473 - TYPE: 0x05 (IP over Fibre Channel); 474 - CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values; 475 - DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then 476 0x60; 477 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 11, section 12, 478 and [FC-FS] for additional requirements; 479 - Parameter: SHOULD be set to zero. 481 4.5. FC Network_Header 483 The fields of the FC Network_Header are shown in figure 6. For use 484 with IPv6, IPv4 and ARP the N_Port_Names formats MUST be one of 0x1, 485 0x2, 0x5, 0xC, 0xD, 0xE, 0xF [FC-FS]. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 +- Destination N_Port_Name -+ 492 | | 493 +---------------------------------------------------------------+ 494 | | 495 +- Source N_Port_Name -+ 496 | | 497 +---------------------------------------------------------------+ 499 Fig. 6: FC Network_Header Format 501 4.6. LLC/SNAP Header 503 The fields of the LLC/SNAP Header [IEEE-LLC] are shown in figure 7. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | DSAP | SSAP | CTRL | OUI | 509 +---------------+---------------+---------------+---------------+ 510 | OUI | PID | 511 +---------------+---------------+---------------+---------------+ 513 Fig. 7: LLC/SNAP Header Format 515 To encapsulate IPv6, IPv4 and ARP over Fibre Channel the following 516 code points MUST be used: 518 - DSAP: 0xAA; 519 - SSAP: 0xAA; 520 - CTRL: 0x03; 521 - OUI: 0x000000; 522 - PID: 0x86DD for IPv6, 0x0800 for IPv4, 0x0806 for ARP. 524 4.7. Bit and Byte Ordering 526 IPv6, IPv4 and ARP packets are mapped to the FC-4 level using the 527 big-endian byte ordering that corresponds to the standard network 528 byte order or canonical form. 530 4.8. Maximum Transfer Unit 532 The default MTU size for IPv6 packets over Fibre Channel is 65280 533 octets. Large IPv6 packets are mapped to a Sequence of FC frames 534 (see section 2.4). This size may be reduced by a Router 535 Advertisement [DISC] containing an MTU option that specifies a 536 smaller MTU, or by manual configuration of each Nx_Port. However, as 537 required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a 538 Router Advertisement received on an Nx_Port has an MTU option 539 specifying an MTU larger than 65280, or larger than a manually 540 configured value, that MTU option MAY be logged to system management 541 but MUST be otherwise ignored. 543 As the default MTU size far exceeds the message sizes typically used 544 in the Internet, an IPv6 over FC implementation SHOULD implement Path 545 MTU Discovery [PMTUD6], or at least maintain different MTU values for 546 on-link and off-link destinations. 548 For correct operation of IPv6 in a routed environment, it is 549 critically important to configure an appropriate MTU option in Router 550 Advertisements. 552 For correct operation of IPv6 when mixed media (e.g., Ethernet and 553 Fibre Channel) are bridged together, the smallest MTU of all the 554 media must be advertised by routers in an MTU option. If there are 555 no routers present, this MTU must be manually configured in each node 556 which is connected to a medium with a default MTU larger than the 557 smallest MTU. 559 The default MTU size for IPv4 packets over Fibre Channel is 65280 560 octets. Large IPv4 packets are mapped to a Sequence of FC frames 561 (see section 2.4). This size may be reduced by manual configuration 562 of each Nx_Port or by the Path MTU Discovery technique [PMTUD4]. 564 5. IPv6 Stateless Address Autoconfiguration 566 5.1. IPv6 Interface Identifier and Address Prefix 568 The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 569 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 570 Interface Identifier is obtained by complementing the Universal/Local 571 (U/L) bit of the OUI field of the derived EUI-64 address. The U/L 572 bit has no function in Fibre Channel, however it has to be properly 573 handled when a Name_Identifier is converted to an EUI-64 address. 575 [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), 576 or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers 577 in EUI-64 addresses. This allows the usage of these Name_Identifiers 578 to support IPv6. [FC-FS] also defines EUI-64 mapped FC 579 Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived 580 from an EUI-64 address. It is possible to reverse this address 581 mapping to obtain the original EUI-64 address in order to support 582 IPv6. 584 IPv6 stateless address autoconfiguration MUST be performed as 585 specified in [ACONF]. An IPv6 Address Prefix used for stateless 586 address autoconfiguration of an Nx_Port MUST have a length of 64 587 bits. 589 5.2. Generating an Interface ID from a Format 1 N_Port_Name 591 The Name_Identifier format 0x1 is shown in figure 8. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 |0 0 0 1| 0x000 | OUI | 597 +-------+-------+---------------+---------------+---------------+ 598 | OUI | VSID | 599 +---------------+---------------+---------------+---------------+ 601 Fig. 8: Format 0x1 Name_Identifier 603 The EUI-64 address derived from this Name_Identifier has the format 604 shown in figure 9 [FC-FS]. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | OUI with complemented U/L bit |0 0 0 1| VSID | 610 +---------------+---------------+-------+-------+-------+-------+ 611 | VSID | 0x000 | 612 +---------------+---------------+-------+-------+---------------+ 614 Fig. 9: EUI-64 Address from a Format 0x1 Name_Identifier 616 The IPv6 Interface Identifier is obtained from this EUI-64 address by 617 complementing the U/L bit in the OUI field. So the OUI in the IPv6 618 Interface ID is exactly as in the FC Name_Identifier. The resulting 619 IPv6 Interface Identifier has local scope [AARCH] and the format 620 shown in figure 10. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | OUI |0 0 0 1| VSID | 626 +---------------+---------------+-------+-------+-------+-------+ 627 | VSID | 0x000 | 628 +---------------+---------------+-------+-------+---------------+ 630 Fig. 10: IPv6 Interface ID from a Format 0x1 Name_Identifier 632 As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF 633 generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. 635 5.3. Generating an Interface ID from a Format 2 N_Port_Name 637 The Name_Identifier format 0x2 is shown in figure 11. 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 |0 0 1 0| Vendor Specific | OUI | 643 +-------+-------+---------------+---------------+---------------+ 644 | OUI | VSID | 645 +---------------+---------------+---------------+---------------+ 647 Fig. 11: Format 0x2 Name_Identifier 649 The EUI-64 address derived from this Name_Identifier has the format 650 shown in figure 12 [FC-FS]. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | OUI with complemented U/L bit |0 0 1 0| VSID | 656 +---------------+-----------------------+-------+-------+-------+ 657 | VSID | Vendor Specific | 658 +---------------+-----------------------+-------+---------------+ 660 Fig. 12: EUI-64 Address from a Format 0x2 Name_Identifier 662 The IPv6 Interface Identifier is obtained from this EUI-64 address by 663 complementing the U/L bit in the OUI field. So the OUI in the IPv6 664 Interface ID is exactly as in the FC Name_Identifier. The resulting 665 IPv6 Interface Identifier has local scope [AARCH] and the format 666 shown in figure 13. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | OUI |0 0 1 0| VSID | 672 +---------------+-----------------------+-------+-------+-------+ 673 | VSID | Vendor Specific | 674 +---------------+-----------------------+-------+---------------+ 676 Fig. 13: IPv6 Interface ID from a Format 0x2 Name_Identifier 678 As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF 679 generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. 681 5.4. Generating an Interface ID from a Format 5 N_Port_Name 683 The Name_Identifier format 0x5 is shown in figure 14. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 |0 1 0 1| OUI | VSID | 689 +-------+-------+---------------+---------------+-------+-------+ 690 | VSID | 691 +---------------+---------------+---------------+---------------+ 693 Fig. 14: Format 0x5 Name_Identifier 695 The EUI-64 address derived from this Name_Identifier has the format 696 shown in figure 15 [FC-FS]. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | OUI with complemented U/L bit |0 1 0 1| VSID | 702 +---------------+---------------+---------------+-------+-------+ 703 | VSID | 704 +---------------+---------------+---------------+---------------+ 706 Fig. 15: EUI-64 Address from a Format 0x5 Name_Identifier 708 The IPv6 Interface Identifier is obtained from this EUI-64 address 709 complementing the U/L bit in the OUI field. So the OUI in the IPv6 710 Interface ID is exactly as in the FC Name_Identifier. The resulting 711 IPv6 Interface Identifier has local scope [AARCH] and the format 712 shown in figure 16. 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | OUI |0 1 0 1| VSID | 718 +---------------+---------------+---------------+-------+-------+ 719 | VSID | 720 +---------------+---------------+---------------+---------------+ 722 Fig. 16: IPv6 Interface ID from a Format 0x5 Name_Identifier 724 As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 725 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. 727 5.5. Generating an Interface ID from an EUI-64 mapped N_Port_Name 729 The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) 730 are derived from an EUI-64 address by compressing the OUI field of 731 such addresses. The compression is performed by removing from the 732 OUI the Universal/Local and Individual/Group bits, and by putting 733 bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and 734 bits 8 to 23 of the OUI in the second and third octet of the 735 Name_Identifier, as shown in figure 17. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |1 1| OUI[0..5] | OUI[8..23] | VSID | 741 +---+-----------+---------------+---------------+---------------+ 742 | VSID | 743 +---------------+---------------+---------------+---------------+ 745 Fig. 17: EUI-64 Mapped Name_Identifiers Format 747 The EUI-64 address used to generate the Name_Identifier shown in 748 figure 17 has the format shown in figure 18. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | OUI[0..5] |0 0| OUI[8..23] | VSID | 754 +-----------+---+---------------+---------------+---------------+ 755 | VSID | 756 +---------------+---------------+---------------+---------------+ 758 Fig. 18: EUI-64 Address from an EUI-64 Mapped Name_Identifier 760 The IPv6 Interface Identifier is obtained from this EUI-64 address by 761 complementing the U/L bit in the OUI field. The resulting IPv6 762 Interface Identifier has global scope [AARCH] and the format shown in 763 figure 19. 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | OUI[0..5] |1 0| OUI[8..23] | VSID | 769 +-----------+---+---------------+---------------+---------------+ 770 | VSID | 771 +---------------+---------------+---------------+---------------+ 773 Fig. 19: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier 775 As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A 776 generates the IPv6 Interface Identifier 3663:46AB:0125:789A. 778 6. Link-Local Addresses 780 The IPv6 link-local address [AARCH] for an Nx_Port is formed by 781 appending the Interface Identifier, as defined in section 5, to the 782 prefix FE80::/64. The resulting address is shown in figure 20. 784 10 bits 54 bits 64 bits 785 +----------+-----------------------+----------------------------+ 786 |1111111010| (zeros) | Interface Identifier | 787 +----------+-----------------------+----------------------------+ 789 Fig. 20: IPv6 link-local Address Format 791 7. ARP Packet Format 793 The Address Resolution Protocol defined in [ARP] is designed to be a 794 general purpose protocol, to accommodate many network technologies 795 and many upper layer protocols. 797 [RFC-2625] chose to use for Fibre Channel the same ARP packet format 798 used for Ethernet networks. In order to do that, [RFC-2625] 799 restricted the use of IPv4 to Nx_Ports having N_Port_Name format 0x1. 800 While this may have been a reasonable choice at that time, today 801 there are Nx_Ports with N_Port_Name format other than 0x1 in 802 widespread use. 804 This specification accommodates Nx_Ports with N_Port_Names of format 805 different than 0x1 by defining a Fibre Channel specific version of 806 the ARP protocol (FC ARP), carrying both N_Port_Name and N_Port_ID as 807 HW address. 809 IANA has registered the number 18 (decimal) to identify Fibre Channel 810 as ARP HW type. The FC ARP packet format is shown in figure 21. The 811 length of the FC ARP packet is 40 octets. 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | HW Type = 0x0012 | Protocol = 0x0800 | 817 +---------------+---------------+---------------+---------------+ 818 | HW Len = 12 | Proto Len = 4 | Opcode | 819 +---------------+---------------+---------------+---------------+ 820 | | 821 +- -+ 822 | HW Address of Sender | 823 +- -+ 824 | | 825 +---------------+---------------+---------------+---------------+ 826 | Protocol Address of Sender | 827 +---------------+---------------+---------------+---------------+ 828 | | 829 +- -+ 830 | HW Address of Target | 831 +- -+ 832 | | 833 +---------------+---------------+---------------+---------------+ 834 | Protocol Address of Target | 835 +---------------+---------------+---------------+---------------+ 837 Fig. 21: FC ARP Packet Format 839 The following code points MUST be used with FC ARP: 841 - HW Type: 0x0012 (Fibre Channel); 842 - Protocol: 0x0800 (IPv4); 843 - HW Len: 12 (Length in octets of the HW Address); 844 - Proto Len: 4 (Length in octets of the Protocol Address); 845 - Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply [ARP]; 846 - HW Address of Sender: the HW Address (see section 8) of the 847 Requester in an ARP Request, or the HW Address of the Responder in 848 an ARP Reply; 849 - Protocol Address of Sender: the IPv4 address of the Requester in 850 an ARP Request, or that of the Responder in an ARP Reply; 851 - HW Address of Target: set to zero in an ARP Request, and to the HW 852 Address (see section 8) of the Requester in an ARP Reply; 853 - Protocol Address of Target: the IPv4 address of the Responder in 854 an ARP Request, or that of the Requester in an ARP Reply. 856 8. Link-layer Address/Hardware Address 858 The Link-layer address used in the Source/Target Link-layer Address 859 option (see section 9.2) and the Hardware Address used in FC ARP (see 860 section 7) have the same format, shown in figure 22. 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 +- N_Port_Name -+ 867 | | 868 +---------------+---------------+---------------+---------------+ 869 | Reserved | N_Port_ID | 870 +---------------+---------------+---------------+---------------+ 872 Fig. 22: Link-layer Address/HW Address Format 874 Reserved fields MUST be set to zero when transmitting, and MUST be 875 ignored when receiving. 877 9. Address Mapping for Unicast 879 9.1. Overview 881 An Nx_Port has two kinds of Fibre Channel addresses: 883 - a non-volatile 64-bit address, called N_Port_Name; 884 - a volatile 24-bit address, called N_Port_ID. 886 The N_Port_Name is used to uniquely identify the Nx_Port, while the 887 N_Port_ID is used to route frames to the Nx_Port. Both FC addresses 888 are required to resolve an IPv6 or IPv4 unicast address. The fact 889 that the N_Port_ID is volatile implies that an Nx_Port MUST validate 890 the mapping between its N_Port_Name and N_Port_ID when certain Fibre 891 Channel events occur (see Appendix B). 893 9.2. IPv6 Address Mapping 895 The procedure for mapping IPv6 unicast addresses into Fibre Channel 896 link-layer addresses uses the Neighbor Discovery Protocol [DISC]. 897 The Source/Target Link-layer Address option has the format shown in 898 figure 23 when the link layer is Fibre Channel. 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length = 2 | | 904 +---------------+---------------+ -+ 905 | | 906 +- Link-layer Address -+ 907 | | 908 +- +---------------+---------------+ 909 | | Padding | 910 +---------------+---------------+---------------+---------------+ 912 Fig. 23: Source/Target Link-layer Address option for Fibre Channel 914 Type: 1 for Source Link-layer address. 915 2 for Target Link-layer address. 917 Length: 2 (in units of 8 octets). 919 Padding: MUST be set to zero when transmitting, 920 MUST be ignored when receiving 922 Link-layer Address: the Nx_Port's Link-layer Address (see section 8). 924 9.3. IPv4 Address Mapping 926 The procedure for mapping IPv4 unicast addresses into Fibre Channel 927 link-layer addresses uses the FC ARP protocol, as specified in 928 section 7 and [ARP]. A source Nx_Port that has to send IPv4 packets 929 to a destination Nx_Port, known by its IPv4 address, MUST perform the 930 following steps: 932 1) The source Nx_Port first consults its local mapping tables for a 933 mapping ; 935 2) If such a mapping is found, and a valid Port Login is in place 936 with the destination Nx_Port, then the source Nx_Port sends the 937 IPv4 packets to the destination Nx_Port using the retrieved 938 N_Port_ID as D_ID; 940 3) If such a mapping is not found, or a valid Port Login is not in 941 place with the destination Nx_Port, then the source Nx_Port sends 942 a broadcast FC ARP Request (see section 10) to its connected FC 943 network; 945 4) When a broadcast FC ARP Request is received by the Nx_Port with 946 the matching IPv4 address, that Nx_Port caches the information 947 carried in the FC ARP Request in its local mapping tables and 948 generates a unicast FC ARP Reply. If a valid Port Login to the 949 Nx_Port that sent the broadcast FC ARP Request does not exist, the 950 Nx_Port MUST perform such a Port Login, and then use it for the 951 unicast reply. The N_Port_ID to which the Port Login is directed 952 is taken from the N_Port_ID field of the Sender HW Address field 953 in the received FC ARP packet; 955 5) If no Nx_Port has the matching IPv4 address, no unicast FC ARP 956 Reply is returned. 958 10. Address Mapping for Multicast 960 IPv6 multicast packets, IPv4 multicast/broadcast packets, and ARP 961 broadcast packets MUST be mapped to FC Sequences addressed to the 962 broadcast N_Port_ID 0xFFFFFF, sent in FC Class 3 in a unidirectional 963 Exchange (see section 12). Appendix A specifies how to transmit a 964 Class 3 broadcast FC Sequence over various Fibre Channel topologies. 965 The Destination N_Port_Name field of the FC Network_Header MUST be 966 set to the value: 968 - for broadcast ARP and IPv4 packets: 0x10-00-FF-FF-FF-FF-FF-FF; 969 - for multicast IPv6 packets: 0x10-00-33-33-XX-YY-ZZ-QQ, 970 where XX-YY-ZZ-QQ are the four least significant octets of the 971 multicast destination IPv6 address; 972 - for multicast IPv4 packets: 0x10-00-01-00-5E-XX-YY-ZZ, 973 where the 23 least significant bits of XX-YY-ZZ are the 23 least 974 significant bits of the multicast destination IPv4 address and the 975 most significant bit of XX-YY-ZZ is set to zero. 977 An Nx_Port supporting IPv6 or IPv4 MUST be able to map a received 978 broadcast Class 3 Device_Data FC frame to an implicit Port Login 979 context in order to handle IPv6 multicast packets, IPv4 multicast or 980 broadcast packets and ARP broadcast packets. The receive data field 981 size of this implicit Port Login MUST be the same across all the 982 Nx_Ports connected to the same Fabric, otherwise FC broadcast 983 transmission does not work. In order to reduce the need for FC 984 Sequence segmentation, the receive data field size of this implicit 985 Port Login SHOULD be 1024 octets. This receive data field size 986 requirement applies to broadcast Device_Data FC frames, not to ELSs. 988 Receiving an FC Sequence carrying an IPv6 multicast packet, an IPv4 989 multicast/broadcast packet, or an FC ARP broadcast packet triggers 990 some additional processing by the Nx_Port when that IPv6, IPv4 or FC 991 ARP packet requires a unicast reply. In this case, if a valid Port 992 Login to the Nx_Port that sent the multicast or broadcast packet does 993 not exist, the Nx_Port MUST perform such a Port Login, and then use 994 it for the unicast reply. In the case of Neighbor Discovery messages 995 [DISC], the N_Port_ID to which the Port Login is directed is taken 996 from the N_Port_ID field of the Source Link-layer Address in the 997 received Neighbor Discovery message. In the case of FC ARP messages, 998 the N_Port_ID to which the Port Login is directed is taken from the 999 N_Port_ID field of the Sender HW Address field in the received FC ARP 1000 packet. 1002 As an example, if a received broadcast FC Sequence carries an IPv6 1003 multicast unsolicited router advertisement [DISC], the receiving 1004 Nx_Port processes it simply by passing the carried IPv6 packet to the 1005 IPv6 layer. Instead, if a received broadcast FC Sequence carries an 1006 IPv6 multicast solicitation message [DISC] requiring a unicast reply, 1007 and no valid Port Login exists with the Nx_Port sender of the 1008 multicast packet, then a Port Login MUST be performed in order to 1009 send the unicast reply message. If a received broadcast FC Sequence 1010 carries an IPv6 multicast solicitation message [DISC] requiring a 1011 multicast reply, the reply is sent to the broadcast N_Port_ID 1012 0xFFFFFF. 1014 11. Sequence Management 1016 FC Sequences carrying IPv6, IPv4 or ARP packets are REQUIRED to be 1017 non-streamed [FC-FS]. In order to avoid missing FC frame aliasing by 1018 Sequence_ID reuse, an Nx_Port supporting IPv6 or IPv4 is REQUIRED to 1019 use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST 1020 start by setting SEQ_CNT to zero in the first frame, and every frame 1021 transmitted after that MUST increment the previous SEQ_CNT by one. 1022 The Continue Sequence Condition field in the F_CTL field of the FC 1023 Header MUST be set to zero [FC-FS]. 1025 12. Exchange Management 1027 To transmit IPv6, IPv4 or ARP packets to another Nx_Port or to a 1028 multicast/broadcast address, an Nx_Port MUST use dedicated 1029 unidirectional Exchanges (i.e., Exchanges dedicated to IPv6, IPv4 or 1030 ARP packet transmission and that do not transfer Sequence 1031 Initiative). As such, the Sequence Initiative bit in the F_CTL field 1032 of the FC Header MUST be set to zero [FC-FS]. The RX_ID field of the 1033 FC Header MUST be set to 0xFFFF. 1035 Unicast FC Sequences carrying unicast Control Protocol packets (e.g., 1036 ARP packets; IPv6 packets carrying ICMPv6 [ICMPv6], Neighbor 1037 Discovery [DISC] or Multicast Listener Discovery [MLDv2] messages; 1038 IPv4 packets carrying ICMP [ICMPv4] or IGMP [IGMPv3] messages) SHOULD 1039 be sent in short lived unidirectional Exchanges (i.e., Exchanges 1040 containing only one Sequence, in which both the First_Sequence and 1041 Last_Sequence bits in the F_CTL field of the FC Header are set to one 1042 [FC-FS]). Unicast FC Sequences carrying other IPv6 and IPv4 packets 1043 (i.e., unicast IP packets carrying data traffic) MUST be sent in a 1044 long lived unidirectional Exchange (i.e., an Exchange containing one 1045 or more Sequences). IP multicast packets MUST NOT be carried in 1046 unicast FC Sequences (see section 10). 1048 Broadcast FC Sequences carrying multicast or broadcast Control 1049 Protocol packets (e.g., ARP packets; IPv6 packets carrying ICMPv6 1050 [ICMPv6], Neighbor Discovery [DISC] or Multicast Listener Discovery 1051 [MLDv2] messages; IPv4 packets carrying ICMP [ICMPv4] or IGMP 1052 [IGMPv3] messages) MUST be sent in short lived unidirectional 1053 Exchanges. Broadcast FC Sequences carrying other IPv6 or IPv4 1054 multicast traffic (i.e., multicast IP packets carrying data traffic) 1055 MAY be sent in long lived unidirectional Exchanges to enable a more 1056 efficient multicast distribution. 1058 Reasons to terminate a long lived Exchange include the termination of 1059 Port Login and the completion of the IP communication. A long lived 1060 Exchange MAY be terminated by setting to one the Last_Sequence bit in 1061 the F_CTL field of the FC Header, or via the ABTS (Abort Sequence) 1062 protocol [FC-FS]. A long lived Exchange SHOULD NOT be terminated by 1063 transmitting the LOGO ELS, since this may terminate active Exchanges 1064 on other FC-4s [FC-FS]. 1066 13. Interoperability with [RFC-2625] 1068 The IPv4 encapsulation defined in this document, along with Exchange 1069 and Sequence management, are as defined in [RFC-2625]. 1070 Implementations following this specification are expected to 1071 interoperate with implementations compliant to [RFC-2625] for IPv4 1072 packets transmission and reception. 1074 The main difference between this document and [RFC-2625] is in the 1075 address resolution procedure. [RFC-2625] uses the Ethernet format of 1076 the ARP protocol, and requires all Nx_Ports to have a format 0x1 1077 N_Port_Name. This specification defines a Fibre Channel format for 1078 the ARP protocol that supports all commonly used N_Port_Names. In 1079 addition, this specification does not use FARP [RFC-2625]. 1081 An Nx_Port following this specification, and not having a format 0x1 1082 N_Port_Name, is able to interoperate with an [RFC-2625] 1083 implementation by manually configuring the mapping on the involved Nx_Ports. Through 1085 this manual configuration, the ARP protocol does not need to be 1086 performed. However, IPv4 communication is not possible if the 1087 [RFC-2625] implementation strictly enforces the requirement for 1088 Nx_Ports to use N_Port_Names of format 0x1. 1090 An Nx_Port following this specification, and having a format 0x1 1091 N_Port_Name, is able to interoperate with an [RFC-2625] 1092 implementation by manually configuring the mapping on the involved Nx_Ports, or by 1094 performing the IPv4 address resolution in compatibility mode, as 1095 described below: 1097 - The Nx_Port MUST send, when IPv4 address resolution is attempted, 1098 two ARP Requests, the first one according to the FC ARP format and 1099 the second one according to the Ethernet ARP format. If only an 1100 Ethernet ARP Reply is received, it provides the N_Port_Name of the 1101 Nx_Port having the destination IPv4 address. The N_Port_ID 1102 associated with the N_Port_Name received in an Ethernet ARP Reply 1103 may be retrieved from the S_ID field of the received ARP Reply, or 1104 by querying the Fibre Channel Name Server; 1105 - The Nx_Port MUST respond to a received Ethernet ARP Request with 1106 an Ethernet ARP Reply; 1107 - The Nx_Port MAY respond to FARP Requests [RFC-2625]. 1109 The reception of a particular format of ARP message does not imply 1110 that the sending Nx_Port will continue to use the same format later. 1112 Support of compatibility mode is REQUIRED by each implementation. 1113 The use of compatibility mode MUST be administratively configurable. 1115 14. Security Considerations 1117 IPv6, IPv4 and ARP do not introduce any additional security concerns 1118 beyond those that already exist within the Fibre Channel protocols. 1119 Zoning techniques based on FC Name Server masking (soft zoning) do 1120 not work with IPv6 and IPv4, because IPv6 and IPv4 over Fibre Channel 1121 do not use the FC Name Server. The FC ESP_Header [FC-FS] may be used 1122 to secure the FC frames composing FC Sequences carrying IPv6, IPv4 1123 and ARP packets. All the techniques defined to secure IP traffic at 1124 the IP layer may be used in a Fibre Channel environment. 1126 15. IANA Considerations 1128 The directory of ARP parameters should reference this document, when 1129 published, for hardware type 18. 1131 16. Acknowledgments 1133 The authors would like to acknowledge the ANSI INCITS T11.3 Task 1134 Group members who reviewed this document as well as the authors of 1135 [RFC-2625] and [RFC-3831]. 1137 17. Normative References 1139 [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and 1140 Signaling (FC-FS)". 1142 [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 1143 (FC-AL-2)". 1145 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1146 (IPv6) Specification", RFC 2460, December 1998. 1148 [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 1149 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1151 [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address 1152 Autoconfiguration", RFC 2462, December 1998. 1154 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1155 Discovery for IP Version 6 (IPv6)", RFC 2461, 1156 December 1998. 1158 [PMTUD6] McCann, J., Deering, S., and J. Mogul, "Path MTU 1159 Discovery for IP version 6", RFC 1981, August 1996. 1161 [IPv4] Postel, J., "Internet Protocol", STD-5, RFC 791, 1162 September 1981. 1164 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol 1165 -or- Converting Network Addresses to 48-bit Ethernet 1166 Address for Transmission on Ethernet Hardware", 1167 STD-37, RFC 826, November 1982. 1169 [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and 1170 Metropolitan Area Networks: Overview and Architecture". 1172 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", BCP 14, RFC 2119, March 1997. 1175 18. Informative References 1177 [RFC-3831] DeSanti, C., "Transmission of IPv6 Packets over Fibre 1178 Channel", RFC 3831, July 2004. 1180 [RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP 1181 over Fibre Channel", RFC 2625, June 1999. 1183 [MLDv2] Vida, R. and R. Costa, "Multicast Listener Discovery 1184 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1186 [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, W., and A. 1187 Thyagarajan, "Internet Group Management Protocol, 1188 Version 3", RFC 3376, October 2002. 1190 [PMTUD4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 1191 November 1990. 1193 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 1194 Protocol (ICMPv6) for the Internet Protocol Version 6 1195 (IPv6) Specification", RFC 2463, December 1998. 1197 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD-5, 1198 RFC 792, September 1981. 1200 [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", 1201 http://standards.ieee.org/db/oui/tutorials/EUI64.html 1203 19. Authors' Address 1205 Claudio DeSanti 1206 Cisco Systems, Inc. 1207 170 W. Tasman Dr. 1208 San Jose, CA 95134 1209 USA 1211 Phone: +1 408 853-9172 1212 EMail: cds@cisco.com 1214 Craig W. Carlson 1215 QLogic Corporation 1216 6321 Bury Drive 1217 Eden Prairie, MN 55346 1218 USA 1220 Phone: +1 952 932-4064 1221 Email: craig.carlson@qlogic.com 1223 Robert Nixon 1224 Emulex 1225 3333 Susan Street 1226 Costa Mesa, CA 92626 1227 USA 1229 Phone: +1 714 885-3525 1230 EMail: bob.nixon@emulex.com 1232 A. Transmission of a Broadcast FC Sequence over FC Topologies 1233 (Informative) 1235 A.1. Point-to-Point Topology 1237 No particular mechanisms are required for this case. The Nx_Port 1238 connected at the other side of the cable receives the broadcast FC 1239 Sequence having D_ID 0xFFFFFF. 1241 A.2. Private Loop Topology 1243 An NL_Port attached to a private loop must transmit a Class 3 1244 broadcast FC Sequence by using the OPN(fr) primitive signal 1245 [FC-AL-2]. 1247 1) The source NL_Port first sends an Open Broadcast Replicate 1248 (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop 1249 (except itself) to replicate the frames that they receive while 1250 examining the FC Header's D_ID field. 1251 2) The source NL_Port then removes the OPN(fr) signal when it returns 1252 to it. 1253 3) The source NL_Port then sends the Class 3 broadcast FC Sequence 1254 having D_ID 0xFFFFFF. 1256 A.3. Public Loop Topology 1258 An NL_Port attached to a public loop must not use the OPN(fr) 1259 primitive signal. Rather, it must send the Class 3 broadcast FC 1260 Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 1261 [FC-AL-2]. 1263 The Fabric propagates the broadcast to all other FC_Ports [FC-FS], 1264 including the FL_Port which the broadcast arrives on. This includes 1265 all F_Ports, and other FL_Ports. 1267 Each FL_Port propagates the broadcast by using the primitive signal 1268 OPN(fr), in order to prepare the loop to receive the broadcast 1269 sequence. 1271 A.4. Fabric Topology 1273 An N_Port connected to an F_Port must transmit the Class 3 broadcast 1274 FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric 1275 propagates the broadcast to all other FC_Ports [FC-FS]. 1277 B. Validation of the mapping 1278 (Informative) 1280 B.1. Overview 1282 At all times, the mapping must be valid 1283 before use. 1285 After an FC link interruption occurs, the N_Port_ID of an Nx_Port may 1286 change, as well as the N_Port_IDs of all other Nx_Ports that have 1287 previously performed Port Login with this Nx_Port. Because of this, 1288 address validation is required after a LIP in a loop topology 1289 [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS]. 1291 N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus 1292 address validation is not required in this case. 1294 B.2. FC Layer Address Validation in a Point-to-Point Topology 1296 No validation is required after Link Reset (LR). In a point-to-point 1297 topology, NOS/OLS causes implicit Logout of each N_Port and after a 1298 NOS/OLS each N_Port must again perform a Port Login [FC-FS]. 1300 B.3. FC Layer Address Validation in a Private Loop Topology 1302 After a LIP [FC-AL-2], an NL_Port must not transmit any data to 1303 another NL_Port until the address of the other port has been 1304 validated. The validation consists of completing ADISC [FC-FS]. 1306 If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a 1307 logged remote NL_Port exactly match the values prior to the LIP, then 1308 any active Exchange with that NL_Port may continue. 1310 If any of the three FC addresses has changed, then the remote NL_Port 1311 must be logged out. 1313 If an NL_Port's N_Port_ID changes after a LIP, then all active logged 1314 in NL_Ports must be logged out. 1316 B.4. FC Layer Address Validation in a Public Loop Topology 1318 A FAN ELS may be sent by the Fabric to all known previously logged in 1319 NL_Ports following an initialization event. Therefore, after a LIP 1320 [FC-AL-2], NL_Ports may wait for this notification to arrive, or they 1321 may perform an FLOGI. 1323 If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI 1324 response exactly match the values before the LIP and if the AL_PA 1325 [FC-AL-2] obtained by the NL_Port is the same as the one before the 1326 LIP, then the port may resume all Exchanges. If not, then FLOGI must 1327 be performed with the Fabric and all logged in Nx_Ports must be 1328 logged out. 1330 A public loop NL_Port must perform the private loop validation as 1331 specified in section B.3 to any NL_Port on the local loop that has an 1332 N_Port_ID of the form 0x00-00-XX (i.e., to any private loop NL_Port). 1334 B.5. FC Layer Address Validation in a Fabric Topology 1336 No validation is required after Link Reset (LR). 1338 After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the 1339 N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same 1340 as before the NOS/OLS, then the N_Port may resume all Exchanges. If 1341 not, all logged in Nx_Ports must be logged out [FC-FS]. 1343 C. Fibre Channel Bit and Byte Numbering Guidance 1345 Both Fibre Channel and IETF standards use the same byte transmission 1346 order. However, the bit numbering is different. 1348 Fibre Channel bit numbering can be observed if the data structure 1349 heading shown in figure 24 is cut and pasted at the top of the 1350 figures present in this document. 1352 3 2 1 0 1353 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 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Fig. 24: Fibre Channel Bit Numbering 1358 D. Changes from [RFC-2625] 1360 - Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF 1361 are supported, in addition to format 0x1; 1362 - An IP capable Nx_Port MUST support Class 3; 1363 - An IP capable Nx_Port MUST support continuously increasing 1364 SEQ_CNT; 1365 - An IP capable Nx_Port SHOULD support a receive data field size for 1366 Device_Data FC frames of at least 1024 octets; 1367 - The FC ESP_Header MAY be used; 1368 - FC Classes of services other than 3 are not recommended; 1369 - Defined a new FC ARP format; 1370 - Removed support for FARP because some FC implementations do not 1371 tolerate receiving broadcast ELSs; 1372 - Added support for IPv4 multicast; 1373 - Clarified the usage of the CS_CTL and Parameter fields of the FC 1374 Header; 1375 - Clarified the usage of FC Classes of service; 1376 - Clarified the usage of FC Sequences and Exchanges. 1378 E. Changes from [RFC-3831] 1380 - Clarified the usage of the CS_CTL and Parameter fields of the FC 1381 Header; 1382 - Clarified the usage of FC Classes of service; 1383 - Clarified and updated the mapping of IPv6 multicast on Fibre 1384 Channel; 1385 - Clarified the usage of FC Sequences and Exchanges; 1386 - Clarified and updated the format of the Neighbor Discovery 1387 Link-layer option for Fibre Channel. 1389 Intellectual Property Statement 1391 The IETF takes no position regarding the validity or scope of any 1392 Intellectual Property Rights or other rights that might be claimed to 1393 pertain to the implementation or use of the technology described in 1394 this document or the extent to which any license under such rights 1395 might or might not be available; nor does it represent that it has 1396 made any independent effort to identify any such rights. Information 1397 on the procedures with respect to rights in RFC documents can be 1398 found in BCP 78 and BCP 79. 1400 Copies of IPR disclosures made to the IETF Secretariat and any 1401 assurances of licenses to be made available, or the result of an 1402 attempt made to obtain a general license or permission for the use of 1403 such proprietary rights by implementers or users of this 1404 specification can be obtained from the IETF on-line IPR repository at 1405 http://www.ietf.org/ipr. 1407 The IETF invites any interested party to bring to its attention any 1408 copyrights, patents or patent applications, or other proprietary 1409 rights that may cover technology that may be required to implement 1410 this standard. Please address the information to the IETF at 1411 ietf-ipr@ietf.org. 1413 Disclaimer of Validity 1415 This document and the information contained herein are provided on an 1416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1418 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1419 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1420 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1423 Copyright Statement 1425 Copyright (C) The Internet Society (2005). This document is subject 1426 to the rights, licenses and restrictions contained in BCP 78, and 1427 except as set forth therein, the authors retain all their rights. 1429 Acknowledgment 1431 Funding for the RFC Editor function is currently provided by the 1432 Internet Society.