idnits 2.17.1 draft-desanti-ipv6-over-fibre-channel-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([AARCH], [IPv6], [DISC], [IPFC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2003) is 7621 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-LLC' -- Obsolete informational reference (is this intentional?): RFC 2625 (ref. 'IPFC') (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) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Claudio DeSanti 3 draft-desanti-ipv6-over-fibre-channel-02.txt Andiamo Systems 4 Expires: December 2003 June 2003 6 IPv6 over Fibre Channel 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Fibre Channel (FC) is a high speed serial interface technology that 33 supports several Upper Layer Protocols including Small Computer 34 System Interface (SCSI) and IPv4, as specified in [IPFC]. 35 The purpose of this document is to specify a way of encapsulating IP 36 version 6 [IPv6] over Fibre Channel and to describe a method of 37 forming IPv6 link-local addresses [AARCH] and statelessly 38 autoconfigured addresses on Fibre Channel networks. This document 39 also describes the content of the Source/Target Link-layer Address 40 option used in Neighbor Discovery [DISC] when the messages are 41 transmitted on a Fibre Channel network. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [KEYWORDS]. 49 Table Of Contents 51 1. Introduction to Fibre Channel . . . . . . . . . . . . . . . . 3 52 1.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Identifiers and Login . . . . . . . . . . . . . . . . . . . . 3 54 1.3 FC Levels and Frame Format. . . . . . . . . . . . . . . . . . 4 55 1.4 Sequences and Exchanges . . . . . . . . . . . . . . . . . . . 5 56 2. IPv6 Capable Nx_Ports . . . . . . . . . . . . . . . . . . . . 6 57 3. IPv6 Encapsulation. . . . . . . . . . . . . . . . . . . . . . 6 58 3.1 FC Sequence Format. . . . . . . . . . . . . . . . . . . . . . 6 59 3.2 Classes of Service. . . . . . . . . . . . . . . . . . . . . . 7 60 3.3 FC Header Code Points . . . . . . . . . . . . . . . . . . . . 7 61 3.4 FC Network_Header . . . . . . . . . . . . . . . . . . . . . . 8 62 3.5 LLC/SNAP Header . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.6 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 9 64 4. Maximum Transfer Unit . . . . . . . . . . . . . . . . . . . . 9 65 5. Stateless Autoconfiguration . . . . . . . . . . . . . . . . . 9 66 5.1 IPv6 Interface Identifier and Address Prefix. . . . . . . . . 9 67 5.2 Generating an Interface ID from a Format 1 N_Port_Name. . . . 10 68 5.3 Generating an Interface ID from a Format 2 N_Port_Name. . . . 11 69 5.4 Generating an Interface ID from a Format 5 N_Port_Name. . . . 12 70 5.5 Generating an Interface ID from a EUI-64 mapped N_Port_Name . 13 71 6. Link-Local Addresses. . . . . . . . . . . . . . . . . . . . . 14 72 7. Address Mapping for Unicast . . . . . . . . . . . . . . . . . 14 73 8. Address Mapping for Multicast . . . . . . . . . . . . . . . . 15 74 9. Sequence and Exchange Management. . . . . . . . . . . . . . . 16 75 9.1 Sequence Management . . . . . . . . . . . . . . . . . . . . . 16 76 9.2 Exchange Management . . . . . . . . . . . . . . . . . . . . . 16 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 12. Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . 17 80 13. Normative References. . . . . . . . . . . . . . . . . . . . . 17 81 14. Informative References. . . . . . . . . . . . . . . . . . . . 18 82 15. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18 84 A. Transmission of a Broadcast FC Sequence over FC Topologies. . 19 85 B. Validation of the mapping. . . . . . 20 86 C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 21 88 Warning to readers familiar with Fibre Channel: both Fibre Channel 89 and IETF standards use the same byte transmission order. However, the 90 bit numbering is different. See Appendix C for guidance. 92 1. Introduction to Fibre Channel 94 1.1 Overview 96 Fibre Channel (FC) is a gigabit speed network technology primarily 97 used for Storage Networking. Fibre Channel is standardized in the T11 98 Technical Committee of the InterNational Committee for Information 99 Technology Standards (INCITS), an American National Standard 100 Institute (ANSI) accredited standards committee. 102 Fibre Channel devices are called Nodes. Each Node has one or more 103 Ports that connect to Ports of other devices. Fibre Channel may be 104 implemented using any combination of the following three topologies: 105 - a point-to-point link between two Ports; 106 - a set of Ports interconnected by a switching network called a 107 Fabric, as defined in [FC-FS]; 108 - a set of Ports interconnected with a loop topology, as defined in 109 [FC-AL-2]. 111 A Node Port is more precisely called an N_Port. A Node Port that is 112 capable of operating in a loop topology using the loop specific 113 protocols is designated as an NL_Port. The term Nx_Port is used to 114 generically indicate these two kinds of Node Port. 116 A Fabric Port is more precisely called an F_Port. A Fabric Port that 117 is capable of operating in a loop topology using the loop specific 118 protocols is designated as an FL_Port. The term Fx_Port is used to 119 generically indicate these two kinds of Fabric Port. 121 From an IPv6 point of view, a Fibre Channel network, built with any 122 combination of the FC topologies described above, is an IPv6 Link 123 [IPv6] connecting any IPv6-capable Nx_Port acting as an IPv6 124 Interface. 126 1.2 Identifiers and Login 128 Fibre Channel entities are identified by permanent 64 bit long 129 Name_Identifiers. [FC-FS] defines several formats of 130 Name_Identifiers. The value of the first four bits defines the format 131 of a Name_Identifier. These names are referred to in a more precise 132 manner as follows: 133 - an Nx_Port's Name_Identifier is called N_Port_Name; 134 - an Fx_Port's Name_Identifier is called F_Port_Name; 135 - a Node's Name_Identifier is called Node_Name; 136 - a Fabric's Name_Identifier is called Fabric_Name. 138 An Nx_Port connected to a Fibre Channel network is associated with 139 two identifiers, its permanent N_Port_Name and a volatile 24 bit 140 address called N_Port_ID. The N_Port_Name is used to identify the 141 Nx_Port, while the N_Port_ID is used for communications among 142 Nx_Ports. 144 Each Nx_Port acquires an N_Port_ID from the Fabric by performing a 145 process called Fabric Login or FLOGI. The FLOGI process is used also 146 to negotiate several communications parameters between the Nx_Port 147 and the Fabric, such as the receive data field size, which determines 148 the maximum size of the Fibre Channel frames that may be transferred 149 between the Nx_Port and the Fabric. 151 Before effective communication may take place between two Nx_Ports, 152 they must complete a process called Port Login or PLOGI. The PLOGI 153 process provides each Nx_Port with the other Nx_Port's N_Port_Name, 154 and negotiates several communication parameters, such as the receive 155 data field size, which determines the maximum size of the Fibre 156 Channel frames that may be transferred between the two Nx_Ports. 158 Both Fabric Login and Port Login may be explicit, i.e. performed 159 using specific FC control messages (called Extended Link Services or 160 ELS), or implicit, in which the parameters are specified by 161 configuration or other methods. 163 1.3 FC Levels and Frame Format 165 [FC-FS] describes the Fibre Channel protocol using 5 different 166 levels. The FC-2 and FC-4 levels are relevant for this specification. 167 The FC-2 level defines the FC frame format, the transport services, 168 and control functions necessary for information transfer. The FC-4 169 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The 170 Fibre Channel frame format is depicted in figure 1. 172 +-----+-----------+-----------+--------//-------+-----+-----+ 173 | | | Data Field | | | 174 | SOF | FC Header |<--------------------------->| CRC | EOF | 175 | | | Optional | Frame | | | 176 | | | Header(s) | Payload | | | 177 +-----+-----------+-----------+--------//-------+-----+-----+ 179 Fig. 1: Fibre Channel Frame Format 181 The Start of Frame (SOF) and End of Frame (EOF) are special FC 182 transmission words that act as frame delimiters. The CRC is 4-octets 183 long and uses the same 32-bit polynomial used in FDDI. 185 The FC Header is 24-octets long and contains several fields 186 associated with the identification and control of the Data Field. 188 The Data Field is of variable size, ranging from 0 to 2112 octets, 189 and includes the user data in the Frame Payload field, and Optional 190 Headers. The currently defined Optional Headers are: 191 - ESP_Header; 192 - Network_Header; 193 - Association_Header; 194 - Device_Header. 196 The value of the SOF field determines the FC Class of service 197 associated with the frame. Five Classes of service are specified in 198 [FC-FS]. They are distinguished primarily by the method of flow 199 control between the communicating Nx_Ports and by the level of data 200 integrity provided. A given Fabric or Nx_Port may support one or more 201 of the following Classes of service: 202 - Class 1: Dedicated physical connection with delivery confirmation; 203 - Class 2: Frame multiplexed service with delivery confirmation; 204 - Class 3: Datagram service; 205 - Class 4: Fractional bandwidth; 206 - Class 6: Reliable multicast via dedicated connections. 208 1.4 Sequences and Exchanges 210 An application level payload such as IPv6 is called Information Unit 211 at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is 212 mapped to an FC Sequence by the FC-2 level. An FC Sequence consists 213 of one or more FC frames related by the value of the Sequence_ID 214 (SEQ_ID) field of the FC Header. 216 The maximum data that may be carried by an FC frame is 2112 octets. 217 The maximum usable frame size depends on the Fabric and Nx_Port 218 implementations and is negotiated during the Login process. Whenever 219 an Information Unit to be transmitted exceeds this value, the FC-2 220 level segments it into multiple FC frames, sent as a single Sequence. 221 The receiving Nx_Port reassembles the Sequence of frames and delivers 222 a reassembled Information Unit to the FC-4 level. The Sequence Count 223 (SEQ_CNT) field of the FC Header may be used to ensure frame 224 ordering. 226 Multiple Sequences may be related together as belonging to the same 227 FC Exchange. The Exchange is a mechanism used by two Nx_Ports to 228 identify and manage an operation between them. The Exchange is opened 229 when the operation is started between the two Nx_Ports, and closed 230 when the operation ends. FC frames belonging to the same Exchange are 231 related by the value of the Exchange_ID fields in the FC Header. An 232 Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) 233 uniquely identify the Exchange. 235 2. IPv6 Capable Nx_Ports 237 This specification requires an IPv6 capable Nx_Port to have the 238 following properties: 240 - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 241 0xD, 0xE, 0xF. Other Name_Identifier formats are not acceptable to 242 support IPv6; 243 - It MUST support Class 3; 244 - It MUST support continuously increasing SEQ_CNT [FC-FS]; 245 - It MUST be able to transmit and receive an FC-4 Information Unit 246 at least 1304 octets long; 247 - It SHOULD support a receive data field size for Device_Data FC 248 frames of at least 1024 octets. 250 3. IPv6 Encapsulation 252 3.1 FC Sequence Format 254 An IPv6 packet is an Information Unit at the FC-4 level of Fibre 255 Channel, and is mapped to an FC Sequence by the FC-2 level. An FC 256 Sequence containing an IPv6 packet MUST carry the FC Network_Header 257 [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting to the FC 258 Sequence format depicted in figure 2. 260 +---------------+---------------+---------------+---------------+ 261 | | 262 +- -+ 263 | Network_Header | 264 +- (16 octets) -+ 265 | | 266 +- -+ 267 | | 268 +---------------+---------------+---------------+---------------+ 269 | LLC/SNAP header | 270 +- (8 octets) -+ 271 | | 272 +---------------+---------------+---------------+---------------+ 273 | | 274 +- -+ 275 / IPv6 Packet / 276 / / 277 +- -+ 278 | | 279 +---------------+---------------+---------------+---------------+ 281 Fig. 2: FC Sequence Carrying an IPv6 Packet 283 The FC ESP_Header [FC-FS] MAY be used to secure the FC frames 284 composing the FC Sequence. [AH] or [ESP] may be used to provide 285 security at the IPv6 layer. Other types of FC Optional Header MUST 286 NOT be used in an IPv6 FC Sequence. 288 Typically, a Sequence consists of more than one frame. Only the first 289 frame of the Sequence MUST include the FC Network_Header and the 290 LLC/SNAP header. The other frames MUST NOT include them, as depicted 291 in figure 3. 293 First Frame of an IPv6 FC Sequence 294 +-----------+-------------------+-----------------+-------//--------+ 295 | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | 296 | | | | the IPv6 Packet | 297 +-----------+-------------------+-----------------+-------//--------+ 299 Subsequent Frames of an IPv6 FC Sequence 300 +-----------+-----------------//------------------+ 301 | FC Header | Additional chunk of the IPv6 Packet | 302 +-----------+----------------//-------------------+ 304 Fig. 3: Optional Headers in an IPv6 FC Sequence 306 3.2 Classes of Service 308 This specification uses FC Class 3. IPv6 packets carrying Neighbor 309 Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. 310 Other IPv6 packets SHOULD use Class 3 as well. The use of other 311 Classes of service is outside the scope of this specification. 313 3.3 FC Header Code Points 315 The fields of the Fibre Channel Header are depicted in figure 4. To 316 encapsulate IPv6 over Fibre Channel the following code points MUST be 317 used: 319 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 320 Category [FC-FS]) 321 - TYPE: 0x05 (IP over Fibre Channel) 322 - CS_CTL/Prio: 0x0 323 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 324 Sequence, 0x00 for the following FC frames. If the FC ESP_Header 325 is used, then 0x60 for the first FC frame of an IPv6 Sequence, 326 0x40 for the following FC frames. 327 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 9, and [FC-FS] 328 for additional requirements. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | R_CTL | D_ID | 334 +---------------+---------------+---------------+---------------+ 335 | CS_CTL/Prio | S_ID | 336 +---------------+---------------+---------------+---------------+ 337 | TYPE | F_CTL | 338 +---------------+---------------+---------------+---------------+ 339 | SEQ_ID | DF_CTL | SEQ_CNT | 340 +---------------+---------------+---------------+---------------+ 341 | OX_ID | RX_ID | 342 +---------------+---------------+---------------+---------------+ 343 | Parameter | 344 +---------------+---------------+---------------+---------------+ 346 Fig. 4: FC Header Format 348 3.4 FC Network_Header 350 The fields of the FC Network_Header are depicted in figure 5. For use 351 with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 352 0xD, 0xE, 0xF. Other Name_Identifier formats are not acceptable to 353 support IPv6. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 +- Destination N_Port_Name -+ 360 | | 361 +---------------------------------------------------------------+ 362 | | 363 +- Source N_Port_Name -+ 364 | | 365 +---------------------------------------------------------------+ 367 Fig. 5: FC Network_Header Format 369 3.5 LLC/SNAP Header 371 The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 372 6. To encapsulate IPv6 over Fibre Channel the following code points 373 MUST be used: 374 - DSAP: 0xAA 375 - SSAP: 0xAA 376 - CTRL: 0x03 377 - OUI: 0x00-00-00 378 - PID: 0x86-DD 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | DSAP | SSAP | CTRL | OUI | 384 +---------------+---------------+---------------+---------------+ 385 | OUI | PID | 386 +---------------+---------------+---------------+---------------+ 388 Fig. 6: LLC/SNAP Header Format 390 3.6 Bit and Byte Ordering 392 IPv6 packets are mapped to the FC-4 level using the big-endian byte 393 ordering, that corresponds to the standard network byte order or 394 canonical form. 396 4. Maximum Transfer Unit 398 The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 399 65280 octets. This size may be reduced by a Router Advertisement 400 [DISC] containing an MTU option that specifies a smaller MTU, or by 401 manual configuration of each Nx_Port. However, as required by [IPv6], 402 the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement 403 received on an Nx_Port has an MTU option specifying an MTU larger 404 than 65280, or larger than a manually configured value, that MTU 405 option MAY be logged to system management but MUST be otherwise 406 ignored. 408 5. Stateless Autoconfiguration 410 5.1 IPv6 Interface Identifier and Address Prefix 412 The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 413 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 414 Interface Identifier is obtained by complementing the Universal/Local 415 bit of the OUI field of the derived EUI-64 address. 417 [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), 418 or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers 419 in EUI-64 addresses. This allows the usage of these Name_Identifiers 420 to support IPv6. [FC-FS] also defines EUI-64 mapped FC 421 Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived 422 from an EUI-64 address. It is possible to reverse this address 423 mapping to obtain the original EUI-64 address in order to support 424 IPv6. 426 An IPv6 Address Prefix used for stateless autoconfiguration [ACONF] 427 of an Nx_Port MUST have a length of 64 bits. 429 5.2 Generating an Interface ID from a Format 1 N_Port_Name 431 The Name_Identifier format 0x1 is depicted in figure 7. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |0 0 0 1| 0x000 | OUI | 437 +-------+-------+---------------+---------------+---------------+ 438 | OUI | VSID | 439 +---------------+---------------+---------------+---------------+ 441 Fig. 7: Format 0x1 Name_Identifier 443 The EUI-64 address derived from this Name_Identifier has the format 444 depicted in figure 8 [FC-FS]. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | OUI with complemented U/L bit |0 0 0 1| VSID | 450 +---------------+---------------+-------+-------+-------+-------+ 451 | VSID | 0x000 | 452 +---------------+---------------+-------+-------+---------------+ 454 Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier 456 The IPv6 Interface Identifier is obtained from this EUI-64 address by 457 complementing the U/L bit in the OUI field. So the OUI in the IPv6 458 Interface ID is exactly as in the FC Name_Identifier. The resulting 459 IPv6 Interface Identifier has local scope [AARCH] and the format 460 depicted in figure 9. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | OUI |0 0 0 1| VSID | 466 +---------------+---------------+-------+-------+-------+-------+ 467 | VSID | 0x000 | 468 +---------------+---------------+-------+-------+---------------+ 470 Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier 472 As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF 473 generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. 475 5.3 Generating an Interface ID from a Format 2 N_Port_Name 477 The Name_Identifier format 0x2 is depicted in figure 10. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0 0 1 0| Vendor Specific | OUI | 483 +-------+-------+---------------+---------------+---------------+ 484 | OUI | VSID | 485 +---------------+---------------+---------------+---------------+ 487 Fig. 10: Format 0x2 Name_Identifier 489 The EUI-64 address derived from this Name_Identifier has the format 490 depicted in figure 11 [FC-FS]. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | OUI with complemented U/L bit |0 0 1 0| VSID | 496 +---------------+-----------------------+-------+-------+-------+ 497 | VSID | Vendor Specific | 498 +---------------+-----------------------+-------+---------------+ 500 Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier 502 The IPv6 Interface Identifier is obtained from this EUI-64 address by 503 complementing the U/L bit in the OUI field. So the OUI in the IPv6 504 Interface ID is exactly as in the FC Name_Identifier. The resulting 505 IPv6 Interface Identifier has local scope [AARCH] and the format 506 depicted in figure 12. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | OUI |0 0 1 0| VSID | 512 +---------------+-----------------------+-------+-------+-------+ 513 | VSID | Vendor Specific | 514 +---------------+-----------------------+-------+---------------+ 516 Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier 518 As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF 519 generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. 521 5.4 Generating an Interface ID from a Format 5 N_Port_Name 523 The Name_Identifier format 0x5 is depicted in figure 13. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |0 1 0 1| OUI | VSID | 529 +-------+-------+---------------+---------------+-------+-------+ 530 | VSID | 531 +---------------+---------------+---------------+---------------+ 533 Fig. 13: Format 0x5 Name_Identifier 535 The EUI-64 address derived from this Name_Identifier has the format 536 depicted in figure 14 [FC-FS]. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | OUI with complemented U/L bit |0 1 0 1| VSID | 542 +---------------+---------------+---------------+-------+-------+ 543 | VSID | 544 +---------------+---------------+---------------+---------------+ 546 Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier 548 The IPv6 Interface Identifier is obtained from this EUI-64 address 549 complementing the U/L bit in the OUI field. So the OUI in the IPv6 550 Interface ID is exactly as in the FC Name_Identifier. The resulting 551 IPv6 Interface Identifier has local scope [AARCH] and the format 552 depicted in figure 15. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | OUI |0 1 0 1| VSID | 558 +---------------+---------------+---------------+-------+-------+ 559 | VSID | 560 +---------------+---------------+---------------+---------------+ 562 Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier 564 As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 565 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. 567 5.5 Generating an Interface ID from a EUI-64 mapped N_Port_Name 569 The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) 570 are derived from a EUI-64 address by compressing the OUI field of 571 such addresses. The compression is performed by removing from the OUI 572 the Universal/Local and Individual/Group bits, and by putting bits 0 573 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 574 to 23 of the OUI in the second and third octet of the 575 Name_Identifier, as shown in figure 16. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |1 1| OUI[0..5] | OUI[8..23] | VSID | 581 +---+-----------+---------------+---------------+---------------+ 582 | VSID | 583 +---------------+---------------+---------------+---------------+ 585 Fig. 16: EUI-64 Mapped Name_Identifiers Format 587 The EUI-64 address used to generate the Name_Identifier shown in 588 figure 16 has the format depicted in figure 17. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | OUI[0..5] |0 0| OUI[8..23] | VSID | 594 +-----------+---+---------------+---------------+---------------+ 595 | VSID | 596 +---------------+---------------+---------------+---------------+ 598 Fig. 17: EUI-64 Address from a EUI-64 Mapped Name_Identifier 600 The IPv6 Interface Identifier is obtained from this EUI-64 address by 601 complementing the U/L bit in the OUI field. The resulting IPv6 602 Interface Identifier has global scope [AARCH] and the format depicted 603 in figure 18. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | OUI[0..5] |1 0| OUI[8..23] | VSID | 609 +-----------+---+---------------+---------------+---------------+ 610 | VSID | 611 +---------------+---------------+---------------+---------------+ 613 Fig. 18: IPv6 Interface ID from a EUI-64 Mapped Name_Identifier 615 As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A 616 generates the IPv6 Interface Identifier 3663:46AB:0125:789A. 618 6. Link-Local Addresses 620 The IPv6 link-local address [AARCH] for an Nx_Port is formed by 621 appending the Interface Identifier, as defined in section 5, to the 622 prefix FE80::/64. The resulting address is depicted in figure 19. 624 10 bits 54 bits 64 bits 625 +----------+-----------------------+----------------------------+ 626 |1111111010| (zeros) | Interface Identifier | 627 +----------+-----------------------+----------------------------+ 629 Fig. 19: IPv6 link-local Address Format 631 7. Address Mapping for Unicast 633 An Nx_Port has two kinds of Fibre Channel addresses: 634 - a non-volatile 64-bit address, called N_Port_Name; 635 - a volatile 24-bit address, called N_Port_ID. 637 The N_Port_Name is used to uniquely identify the Nx_Port, while the 638 N_Port_ID is used to route frames to the Nx_Port. Both FC addresses 639 are required to resolve an IPv6 unicast address. The fact that the 640 N_Port_ID is volatile implies that the mapping between N_Port_Name 641 and N_Port_ID MUST be valid before use. Appendix B discusses the 642 validation process. 644 The procedure for mapping IPv6 unicast addresses into Fibre Channel 645 link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The 646 Source/Target Link-layer Address option has the format depicted in 647 figure 20 when the link layer is Fibre Channel. 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Type | Length = 2 | Reserved | 653 +---------------+---------------+---------------+---------------+ 654 | | 655 +- N_Port_Name -+ 656 | | 657 +---------------+---------------+---------------+---------------+ 658 | N_Port_ID | Reserved | 659 +---------------+---------------+---------------+---------------+ 661 Fig. 20: Source/Target Link-layer Address option for Fibre Channel 663 Type: 1 for Source Link-layer address. 664 2 for Target Link-layer address. 666 Length: 2 (in units of 8 octets). 668 N_Port_Name: This field contains the Nx_Port's N_Port_Name. 669 N_Port_ID: This field contains the Nx_Port's N_Port_ID. 671 8. Address Mapping for Multicast 673 By default, all best-effort IPv6 multicast packets MUST be mapped to 674 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In 675 particular, datagrams addressed to all-nodes multicast address, 676 all-routers multicast address, and solicited-node multicast addresses 677 [AARCH] MUST be sent as Class 3 FC Sequences addressed to the 678 broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination 679 N_Port_Name field of the FC Network_Header MUST be set to the value 680 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a 681 Class 3 broadcast FC Sequence over various Fibre Channel topologies. 683 An Nx_Port supporting IPv6 MUST be able to map a received broadcast 684 Class 3 Device_Data FC frame to an implicit Port Login context in 685 order to handle IPv6 multicast packets. The receive data field size 686 of this implicit Port Login MUST be the same across all the Nx_Ports 687 connected to the same Fabric, otherwise FC broadcast transmission 688 does not work. In order to reduce the need for FC Sequence 689 segmentation, the receive data field size of this implicit Port Login 690 SHOULD be 1024 octets. This receive data field size requirement 691 applies to broadcast Device_Data FC frames, not to ELSs. 693 Receiving an FC Sequence carrying an IPv6 multicast packet MAY 694 trigger some additional processing by the Nx_Port if that IPv6 packet 695 requires a reply. In this case, if a valid Port Login to the Nx_Port 696 that sent the IPv6 multicast packet does not exist, the Nx_Port MUST 697 perform such a Port Login, and then use it for the unicast IPv6 698 reply. In the case of Neighbor Discovery messages [DISC], the 699 N_Port_ID to which the Port Login is directed is taken from the 700 N_Port_ID field of the Source/Target Link-layer Address option. 702 As an example, an Nx_Port processes a received broadcast FC Sequence 703 carrying an IPv6 multicast unsolicited router advertisement [DISC] 704 simply by passing the carried IPv6 packet to the IPv6 layer. 705 Instead, if a received broadcast FC Sequence carries an IPv6 706 multicast solicitation message [DISC] requiring a reply, and no valid 707 Port Login exists with the Nx_Port sender of the multicast packet, 708 then a Port Login MUST be performed in order to send the unicast 709 reply message. 711 Best-effort IPv6 multicast for other multicast group addresses MAY 712 use Fibre Channel Multicast Groups [FC-FS], if supported by the 713 particular FC topology and implementation. 715 9. Sequence and Exchange Management 717 9.1 Sequence Management 719 FC Sequences are REQUIRED to be non-streamed. In order to avoid 720 missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting 721 IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each 722 Exchange MUST start with SEQ_CNT = 0 in the first frame, and every 723 frame transmitted after that MUST increment the previous SEQ_CNT by 724 one. Any frames received from the other N_Port in the Exchange shall 725 have no effect on the transmitted SEQ_CNT. 727 9.2 Exchange Management 729 To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange 730 for sending data to each Nx_Port in the network and a dedicated 731 Exchange for receiving data from each Nx_Port. 733 An Exchange Responder is not required to assign RX_IDs. If a RX_ID of 734 0xFFFF is assigned, the Exchange Responder is identifying Exchanges 735 based on S_ID / D_ID / OX_ID only. 737 When an Exchange is created between two Nx_Ports for unicast IPv6 738 packets, it remains active while the Nx_Ports are logged in with each 739 other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short 740 lived Exchange. 742 For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because 743 they are used in a unidirectional mode. The Sequence Initiative bit 744 in the F_CTL field of the FC Header [FC-FS] MUST be set to 0. 746 The mechanism for aging or expiring exchanges based on activity, 747 timeout, or other methods is outside the scope of this document. 749 The Exchange Originator MAY terminate Exchanges by setting the F_CTL 750 LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator 751 or Exchange Responder by using the ABTS protocol. IPv6 Exchanges 752 SHOULD NOT be terminated by Logout, since this may terminate active 753 Exchanges on other FC-4s [FC-FS]. 755 10. Security Considerations 757 IPv6 does not introduce any additional security concerns beyond those 758 that already exist within the Fibre Channel protocols. Zoning 759 techniques based on FC Name Server masking (soft zoning) do not work 760 with IPv6, because IPv6 over Fibre Channel does not use the FC Name 761 Server. All the techniques defined to secure IPv6 traffic may be used 762 in a Fibre Channel Environment. 764 11. IANA Considerations 766 None. 768 12. Acknowledgment 770 The author would like to acknowledge the authors of [IPFC], [ETHER], 771 and [IPv6-1394], since some part of this document has been derived 772 from them, as well as the ANSI INCITS T11.3 Task Group members who 773 reviewed this document. 775 13. Normative References 777 [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and 778 Signaling (FC-FS)", Rev 1.90, April 2003. 780 [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 781 (FC-AL-2)". 783 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 784 (IPv6) Specification", RFC 2460, December 1998. 786 [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 787 (IPv6) Addressing Architecture", RFC 3513, April 2003. 789 [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address 790 Autoconfiguration", RFC 2462, December 1998. 792 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 793 Discovery for IP Version 6 (IPv6)", RFC 2461, 794 December 1998. 796 [IEEE-LLC] IEEE Standards for Local Area Networks: Logical Link 797 Control", IEEE, New York, 1985. 799 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 14. Informative References 804 [IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP 805 over Fibre Channel", RFC 2625, June 1999. 807 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 808 RFC 2402, November 1998. 810 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 811 Payload (ESP)", RFC 2406, November 1998. 813 [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", 814 http://standards.ieee.org/db/oui/tutorials/EUI64.html 816 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 817 Networks", RFC 2464, December 1998. 819 [IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 820 over IEEE 1394 Networks", RFC 3146, October 2001. 822 15. Author's Address 824 Claudio DeSanti 825 Andiamo Systems, Inc. 826 375 E. Tasman Dr. 827 San Jose, CA 95134 828 USA 830 Phone: +1 408 853-9172 831 EMail: cds@andiamo.com 833 A. Transmission of a Broadcast FC Sequence over FC Topologies 835 A.1 Point-to-Point Topology 837 No particular mechanisms are required for this case. The Nx_Port 838 connected at the other side of the cable receives the broadcast FC 839 Sequence having D_ID 0xFFFFFF. 841 A.2 Private Loop Topology 843 An NL_Port attached to a private loop MUST transmit a Class 3 844 broadcast FC Sequence by using the OPN(fr) primitive signal 845 [FC-AL-2]. 847 a) The source NL_Port first sends an Open Broadcast Replicate 848 (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop 849 (except itself) to replicate the frames that they receive while 850 examining the FC Header's D_ID field. 851 b) The source NL_Port then removes the OPN(fr) signal when it returns 852 to it. 853 c) The source NL_Port then sends the Class 3 broadcast FC Sequence 854 having D_ID 0xFFFFFF. 856 A.3 Public Loop Topology 858 An NL_Port attached to a public loop MUST NOT use the OPN(fr) 859 primitive signal. Rather, it MUST send the Class 3 broadcast FC 860 Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 861 [FC-AL-2]. 863 The Fabric propagates the broadcast to all other FC_Ports [FC-FS], 864 including the FL_Port which the broadcast arrived on. This includes 865 all F_Ports, and other FL_Ports. 867 Each FL_Port propagates the broadcast by using the primitive signal 868 OPN(fr), in order to prepare the loop to receive the broadcast 869 sequence. 871 A.4 Fabric Topology 873 An N_Port connected to an F_Port MUST transmit the Class 3 broadcast 874 FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates 875 the broadcast to all other FC_Ports [FC-FS]. 877 B. Validation of the mapping 879 B.1 Overview 881 At all times, the mapping must be valid 882 before use. 884 After an FC link interruption occurs, the N_Port_ID of an Nx_Port may 885 change, as well as the N_Port_IDs of all other Nx_Ports that have 886 previously performed Port Login with this Nx_Port. Because of this, 887 address validation is required after a LIP in a loop topology 888 [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS]. 890 N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus 891 address validation is not required in this case. 893 B.2 FC Layer Address Validation in a Point-to-Point Topology 895 No validation is required after LR. In a point-to-point topology, 896 NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS 897 each N_Port must again perform a Port Login [FC-FS]. 899 B.3 FC Layer Address Validation in a Private Loop Topology 901 After a LIP [FC-AL-2], an NL_Port must not transmit any data to 902 another NL_Port until the address of the other port has been 903 validated. The validation consists of completing either ADISC or 904 PDISC [FC-FS]. 906 For a requester, this specification prohibits PDISC and requires 907 ADISC. As a responder, an implementation may need to respond to both 908 ADISC and PDISC for compatibility with other FC specifications. 910 If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a 911 logged remote NL_Port exactly match the values prior to the LIP, then 912 any active Exchange with that NL_Port may continue. 914 If any of the three FC addresses has changed, then the remote NL_Port 915 must be logged out. 917 If an NL_Port's N_Port_ID changes after a LIP, then all active logged 918 in NL_Ports must be logged out. 920 B.4 FC Layer Address Validation in a Public Loop Topology 922 A FAN ELS may be sent by the Fabric to all known previously logged in 923 NL_Ports following an initialization event. Therefore, after a LIP 924 [FC-AL-2], NL_Ports may wait for this notification to arrive, or they 925 may perform an FLOGI. 927 If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI 928 response exactly match the values before the LIP and if the AL_PA 929 [FC-AL-2] obtained by the NL_Port is the same as the one before the 930 LIP, then the port may resume all Exchanges. If not, then FLOGI must 931 be performed with the Fabric and all logged in Nx_Ports must be 932 logged out. 934 A public loop NL_Port must perform the private loop validation as 935 specified in section B.3 to any NL_Port on the local loop that has an 936 N_Port_ID of the form 0x00-00-XX. 938 B.5 FC Layer Address Validation in a Fabric Topology 940 No validation is required after LR (link reset). 942 After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the 943 N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same 944 as before the NOS/OLS, then the N_Port may resume all Exchanges. If 945 not, all logged in Nx_Ports must be logged out [FC-FS]. 947 C. Fibre Channel Bit and Byte Numbering Guidance 949 Both Fibre Channel and IETF standards use the same byte transmission 950 order. However, the bit numbering is different. 952 Fibre Channel bit numbering can be observed if the data structure 953 heading shown in figure 21 is cut and pasted at the top of the 954 figures present in this document. 956 3 2 1 0 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 Fig. 21: Fibre Channel Bit Numbering