idnits 2.17.1 draft-ietf-imss-ipv6-over-fibre-channel-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7287 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. 'PMTUD') (Obsoleted by RFC 8201) -- 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 IMSS Working Group C. DeSanti 3 Internet Draft Cisco Systems 4 draft-ietf-imss-ipv6-over-fibre-channel-02.txt April 2004 5 Expires: October 2004 6 Category: Standards Track 8 Transmission of IPv6 Packets over Fibre Channel 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies the way of encapsulating IPv6 packets over 35 Fibre Channel, and the method of forming IPv6 link-local addresses 36 and statelessly autoconfigured addresses on Fibre Channel networks. 38 Table Of Contents 40 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 41 2. Summary of Fibre Channel. . . . . . . . . . . . . . . . . . . 3 42 2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2.2 Identifiers and Login . . . . . . . . . . . . . . . . . . . . 4 44 2.3 FC Levels and Frame Format. . . . . . . . . . . . . . . . . . 4 45 2.4 Sequences and Exchanges . . . . . . . . . . . . . . . . . . . 5 46 3. IPv6 Capable Nx_Ports . . . . . . . . . . . . . . . . . . . . 6 47 4. IPv6 Encapsulation. . . . . . . . . . . . . . . . . . . . . . 6 48 4.1 FC Sequence Format. . . . . . . . . . . . . . . . . . . . . . 6 49 4.2 FC Classes of Service . . . . . . . . . . . . . . . . . . . . 8 50 4.3 FC Header Code Points . . . . . . . . . . . . . . . . . . . . 8 51 4.4 FC Network_Header . . . . . . . . . . . . . . . . . . . . . . 9 52 4.5 LLC/SNAP Header . . . . . . . . . . . . . . . . . . . . . . . 9 53 4.6 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 9 54 5. Maximum Transfer Unit . . . . . . . . . . . . . . . . . . . . 10 55 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 10 56 6.1 IPv6 Interface Identifier and Address Prefix. . . . . . . . . 10 57 6.2 Generating an Interface ID from a Format 1 N_Port_Name. . . . 11 58 6.3 Generating an Interface ID from a Format 2 N_Port_Name. . . . 12 59 6.4 Generating an Interface ID from a Format 5 N_Port_Name. . . . 13 60 6.5 Generating an Interface ID from an EUI-64 mapped N_Port_Name. 14 61 7. Link-Local Addresses. . . . . . . . . . . . . . . . . . . . . 15 62 8. Address Mapping for Unicast . . . . . . . . . . . . . . . . . 15 63 9. Address Mapping for Multicast . . . . . . . . . . . . . . . . 16 64 10. Sequence Management . . . . . . . . . . . . . . . . . . . . . 17 65 11. Exchange Management . . . . . . . . . . . . . . . . . . . . . 17 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 69 15. Normative References. . . . . . . . . . . . . . . . . . . . . 18 70 16. Informative References. . . . . . . . . . . . . . . . . . . . 19 71 17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 19 73 A. Transmission of a Broadcast FC Sequence over FC Topologies. . 20 74 B. Validation of the mapping. . . . . . 21 75 C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 22 77 1. Introduction 79 Fibre Channel (FC) is a high speed serial interface technology that 80 supports several Upper Layer Protocols including Small Computer 81 System Interface (SCSI) and IPv4 as specified in [IPFC]. 83 The purpose of this document is to specify a way of encapsulating IP 84 version 6 [IPv6] over Fibre Channel and to describe a method of 85 forming IPv6 link-local addresses [AARCH] and statelessly 86 autoconfigured addresses on Fibre Channel networks. This document 87 also describes the content of the Source/Target Link-layer Address 88 option used in Neighbor Discovery [DISC] when the messages are 89 transmitted on a Fibre Channel network. 91 Warning to readers familiar with Fibre Channel: both Fibre Channel 92 and IETF standards use the same byte transmission order. However, the 93 bit numbering is different. See Appendix C for guidance. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [KEYWORDS]. 99 2. Summary of Fibre Channel 101 2.1 Overview 103 Fibre Channel (FC) is a gigabit speed network technology primarily 104 used for Storage Networking. Fibre Channel is standardized in the T11 105 Technical Committee of the InterNational Committee for Information 106 Technology Standards (INCITS), an American National Standard 107 Institute (ANSI) accredited standards committee. 109 Fibre Channel devices are called Nodes. Each Node has one or more 110 Ports that connect to Ports of other devices. Fibre Channel may be 111 implemented using any combination of the following three topologies: 112 - a point-to-point link between two Ports; 113 - a set of Ports interconnected by a switching network called a 114 Fabric, as defined in [FC-FS]; 115 - a set of Ports interconnected with a loop topology, as defined in 116 [FC-AL-2]. 118 A Node Port is more precisely called an N_Port. A Node Port that is 119 capable of operating in a loop topology using the loop specific 120 protocols is designated as an NL_Port. The term Nx_Port is used to 121 generically indicate these two kinds of Node Port. 123 A Fabric Port is more precisely called an F_Port. A Fabric Port that 124 is capable of operating in a loop topology using the loop specific 125 protocols is designated as an FL_Port. The term Fx_Port is used to 126 generically indicate these two kinds of Fabric Port. 128 From an IPv6 point of view, a Fibre Channel network, built with any 129 combination of the FC topologies described above, is an IPv6 Link 130 [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces. 132 2.2 Identifiers and Login 134 Fibre Channel entities are identified by permanent 64 bit long 135 Name_Identifiers. [FC-FS] defines several formats of 136 Name_Identifiers. The value of the first four bits defines the format 137 of a Name_Identifier. These names are referred to in a more precise 138 manner as follows: 139 - an Nx_Port's Name_Identifier is called N_Port_Name; 140 - an Fx_Port's Name_Identifier is called F_Port_Name; 141 - a Node's Name_Identifier is called Node_Name; 142 - a Fabric's Name_Identifier is called Fabric_Name. 144 An Nx_Port connected to a Fibre Channel network is associated with 145 two identifiers, its permanent N_Port_Name and a volatile 24 bit 146 address called N_Port_ID. The N_Port_Name is used to identify the 147 Nx_Port, while the N_Port_ID is used for communications among 148 Nx_Ports. 150 Each Nx_Port acquires an N_Port_ID from the Fabric by performing a 151 process called Fabric Login or FLOGI. The FLOGI process is used also 152 to negotiate several communications parameters between the Nx_Port 153 and the Fabric, such as the receive data field size, which determines 154 the maximum size of the Fibre Channel frames that may be transferred 155 between the Nx_Port and the Fabric. 157 Before effective communication may take place between two Nx_Ports, 158 they must complete a process called Port Login or PLOGI. The PLOGI 159 process provides each Nx_Port with the other Nx_Port's N_Port_Name, 160 and negotiates several communication parameters, such as the receive 161 data field size, which determines the maximum size of the Fibre 162 Channel frames that may be transferred between the two Nx_Ports. 164 Both Fabric Login and Port Login may be explicit, i.e. performed 165 using specific FC control messages (called Extended Link Services or 166 ELS), or implicit, in which the parameters are specified by 167 configuration or other methods. 169 2.3 FC Levels and Frame Format 171 [FC-FS] describes the Fibre Channel protocol using 5 different 172 levels. The FC-2 and FC-4 levels are relevant for this specification. 173 The FC-2 level defines the FC frame format, the transport services, 174 and control functions necessary for information transfer. The FC-4 175 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The 176 Fibre Channel frame format is depicted in figure 1. 178 +-----+-----------+-----------+--------//-------+-----+-----+ 179 | | | Data Field | | | 180 | SOF | FC Header |<--------------------------->| CRC | EOF | 181 | | | Optional | Frame | | | 182 | | | Header(s) | Payload | | | 183 +-----+-----------+-----------+--------//-------+-----+-----+ 185 Fig. 1: Fibre Channel Frame Format 187 The Start of Frame (SOF) and End of Frame (EOF) are special FC 188 transmission words that act as frame delimiters. The CRC is 4 octets 189 long and uses the same 32-bit polynomial used in FDDI. 191 The FC Header is 24 octets long and contains several fields 192 associated with the identification and control of the Data Field. 194 The Data Field is of variable size, ranging from 0 to 2112 octets, 195 and includes the user data in the Frame Payload field, and Optional 196 Headers. The currently defined Optional Headers are: 197 - ESP_Header; 198 - Network_Header; 199 - Association_Header; 200 - Device_Header. 202 The value of the SOF field determines the FC Class of service 203 associated with the frame. Five Classes of service are specified in 204 [FC-FS]. They are distinguished primarily by the method of flow 205 control between the communicating Nx_Ports and by the level of data 206 integrity provided. A given Fabric or Nx_Port may support one or more 207 of the following Classes of service: 208 - Class 1: Dedicated physical connection with delivery confirmation; 209 - Class 2: Frame multiplexed service with delivery confirmation; 210 - Class 3: Datagram service; 211 - Class 4: Fractional bandwidth; 212 - Class 6: Reliable multicast via dedicated connections. 214 2.4 Sequences and Exchanges 216 An application level payload such as IPv6 is called Information Unit 217 at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is 218 mapped to an FC Sequence by the FC-2 level. An FC Sequence consists 219 of one or more FC frames related by the value of the Sequence_ID 220 (SEQ_ID) field of the FC Header. 222 The maximum data that may be carried by an FC frame is 2112 octets. 223 The maximum usable frame size depends on the Fabric and Nx_Port 224 implementations and is negotiated during the Login process. Whenever 225 an Information Unit to be transmitted exceeds this value, the FC-2 226 level segments it into multiple FC frames, sent as a single Sequence. 227 The receiving Nx_Port reassembles the Sequence of frames and delivers 228 a reassembled Information Unit to the FC-4 level. The Sequence Count 229 (SEQ_CNT) field of the FC Header may be used to ensure frame 230 ordering. 232 Multiple Sequences may be related together as belonging to the same 233 FC Exchange. The Exchange is a mechanism used by two Nx_Ports to 234 identify and manage an operation between them. The Exchange is opened 235 when the operation is started between the two Nx_Ports, and closed 236 when the operation ends. FC frames belonging to the same Exchange are 237 related by the value of the Exchange_ID fields in the FC Header. An 238 Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) 239 uniquely identify the Exchange. 241 3. IPv6 Capable Nx_Ports 243 This specification requires an IPv6 capable Nx_Port to have the 244 following properties: 246 - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 247 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other 248 Name_Identifier formats is outside the scope of this 249 specification; 250 - It MUST support Class 3; 251 - It MUST support continuously increasing SEQ_CNT [FC-FS]; 252 - It MUST be able to transmit and receive an FC-4 Information Unit 253 at least 1304 octets long; 254 - It SHOULD support a receive data field size for Device_Data FC 255 frames of at least 1024 octets. 257 4. IPv6 Encapsulation 259 4.1 FC Sequence Format 261 An IPv6 packet is mapped to an Information Unit at the FC-4 level of 262 Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 263 level. An FC Information Unit containing an IPv6 packet MUST carry 264 the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], 265 resulting in the FC Information Unit format depicted in figure 2. 267 +---------------+---------------+---------------+---------------+ 268 | | 269 +- -+ 270 | Network_Header | 271 +- (16 octets) -+ 272 | | 273 +- -+ 274 | | 275 +---------------+---------------+---------------+---------------+ 276 | LLC/SNAP header | 277 +- (8 octets) -+ 278 | | 279 +---------------+---------------+---------------+---------------+ 280 | | 281 +- -+ 282 / IPv6 Packet / 283 / / 284 +- -+ 285 | | 286 +---------------+---------------+---------------+---------------+ 288 Fig. 2: FC Information Unit Mapping an IPv6 Packet 290 The FC ESP_Header [FC-FS] MAY be used to secure the FC frames 291 composing the FC Sequence. [AH] or [ESP] may be used to provide 292 security at the IPv6 layer. Other types of FC Optional Header MUST 293 NOT be used in an IPv6 FC Sequence. 295 Typically, a Sequence consists of more than one frame. Only the first 296 frame of the Sequence MUST include the FC Network_Header and the 297 LLC/SNAP header. The other frames MUST NOT include them, as depicted 298 in figure 3. 300 First Frame of an IPv6 FC Sequence 301 +-----------+-------------------+-----------------+-------//--------+ 302 | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | 303 | | | | the IPv6 Packet | 304 +-----------+-------------------+-----------------+-------//--------+ 306 Subsequent Frames of an IPv6 FC Sequence 307 +-----------+-----------------//------------------+ 308 | FC Header | Additional chunk of the IPv6 Packet | 309 +-----------+----------------//-------------------+ 311 Fig. 3: Optional Headers in an IPv6 FC Sequence 313 4.2 FC Classes of Service 315 This specification uses FC Class 3. IPv6 packets carrying Neighbor 316 Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. 317 Other IPv6 packets SHOULD use Class 3 as well. The use of other 318 Classes of service is outside the scope of this specification. 320 4.3 FC Header Code Points 322 The fields of the Fibre Channel Header are depicted in figure 4. The 323 D_ID and S_ID fields contain respectively the destination N_Port_ID 324 and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the 325 following code points MUST be used: 327 - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information 328 Category [FC-FS]) 329 - TYPE: 0x05 (IP over Fibre Channel) 330 - CS_CTL/Prio: 0x0 331 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 332 Sequence, 0x00 for the following FC frames. If the FC ESP_Header 333 is used, then 0x60 for the first FC frame of an IPv6 Sequence, 334 0x40 for the following FC frames. 335 - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10, 336 section 11, and [FC-FS] for additional requirements. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | R_CTL | D_ID | 342 +---------------+---------------+---------------+---------------+ 343 | CS_CTL/Prio | S_ID | 344 +---------------+---------------+---------------+---------------+ 345 | TYPE | F_CTL | 346 +---------------+---------------+---------------+---------------+ 347 | SEQ_ID | DF_CTL | SEQ_CNT | 348 +---------------+---------------+---------------+---------------+ 349 | OX_ID | RX_ID | 350 +---------------+---------------+---------------+---------------+ 351 | Parameter | 352 +---------------+---------------+---------------+---------------+ 354 Fig. 4: FC Header Format 356 4.4 FC Network_Header 358 The fields of the FC Network_Header are depicted in figure 5. For use 359 with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 360 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is 361 outside the scope of this specification. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 +- Destination N_Port_Name -+ 368 | | 369 +---------------------------------------------------------------+ 370 | | 371 +- Source N_Port_Name -+ 372 | | 373 +---------------------------------------------------------------+ 375 Fig. 5: FC Network_Header Format 377 4.5 LLC/SNAP Header 379 The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 380 6. To encapsulate IPv6 over Fibre Channel the following code points 381 MUST be used: 382 - DSAP: 0xAA 383 - SSAP: 0xAA 384 - CTRL: 0x03 385 - OUI: 0x00-00-00 386 - PID: 0x86-DD 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | DSAP | SSAP | CTRL | OUI | 392 +---------------+---------------+---------------+---------------+ 393 | OUI | PID | 394 +---------------+---------------+---------------+---------------+ 396 Fig. 6: LLC/SNAP Header Format 398 4.6 Bit and Byte Ordering 400 IPv6 packets are mapped to the FC-4 level using the big-endian byte 401 ordering that corresponds to the standard network byte order or 402 canonical form. 404 5. Maximum Transfer Unit 406 The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 407 65280 octets. This size may be reduced by a Router Advertisement 408 [DISC] containing an MTU option that specifies a smaller MTU, or by 409 manual configuration of each Nx_Port. However, as required by [IPv6], 410 the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement 411 received on an Nx_Port has an MTU option specifying an MTU larger 412 than 65280, or larger than a manually configured value, that MTU 413 option MAY be logged to system management but MUST be otherwise 414 ignored. 416 As the default MTU size far exceeds the message sizes typically used 417 in the Internet, an IPv6 over FC implementation SHOULD implement Path 418 MTU Discovery [PMTUD], or at least maintain different MTU values for 419 on-link and off-link destinations. 421 For correct operation in a routed environment, it is critically 422 important to configure an appropriate MTU option in Router 423 Advertisements. 425 For correct operation when mixed media (e.g., Ethernet and Fibre 426 Channel) are bridged together, the smallest MTU of all the media must 427 be advertised by routers in an MTU option. If there are no routers 428 present, this MTU must be manually configured in each node which is 429 connected to a medium with a default MTU larger than the smallest 430 MTU. 432 6. Stateless Address Autoconfiguration 434 6.1 IPv6 Interface Identifier and Address Prefix 436 The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 437 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 438 Interface Identifier is obtained by complementing the Universal/Local 439 bit of the OUI field of the derived EUI-64 address. 441 [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), 442 or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers 443 in EUI-64 addresses. This allows the usage of these Name_Identifiers 444 to support IPv6. [FC-FS] also defines EUI-64 mapped FC 445 Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived 446 from an EUI-64 address. It is possible to reverse this address 447 mapping to obtain the original EUI-64 address in order to support 448 IPv6. 450 Stateless address autoconfiguration MUST be performed as specified in 451 [ACONF]. An IPv6 Address Prefix used for stateless address 452 autoconfiguration of an Nx_Port MUST have a length of 64 bits. 454 6.2 Generating an Interface ID from a Format 1 N_Port_Name 456 The Name_Identifier format 0x1 is depicted in figure 7. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |0 0 0 1| 0x000 | OUI | 462 +-------+-------+---------------+---------------+---------------+ 463 | OUI | VSID | 464 +---------------+---------------+---------------+---------------+ 466 Fig. 7: Format 0x1 Name_Identifier 468 The EUI-64 address derived from this Name_Identifier has the format 469 depicted in figure 8 [FC-FS]. 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | OUI with complemented U/L bit |0 0 0 1| VSID | 475 +---------------+---------------+-------+-------+-------+-------+ 476 | VSID | 0x000 | 477 +---------------+---------------+-------+-------+---------------+ 479 Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier 481 The IPv6 Interface Identifier is obtained from this EUI-64 address by 482 complementing the U/L bit in the OUI field. So the OUI in the IPv6 483 Interface ID is exactly as in the FC Name_Identifier. The resulting 484 IPv6 Interface Identifier has local scope [AARCH] and the format 485 depicted in figure 9. 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 | OUI |0 0 0 1| VSID | 491 +---------------+---------------+-------+-------+-------+-------+ 492 | VSID | 0x000 | 493 +---------------+---------------+-------+-------+---------------+ 495 Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier 497 As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF 498 generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. 500 6.3 Generating an Interface ID from a Format 2 N_Port_Name 502 The Name_Identifier format 0x2 is depicted in figure 10. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |0 0 1 0| Vendor Specific | OUI | 508 +-------+-------+---------------+---------------+---------------+ 509 | OUI | VSID | 510 +---------------+---------------+---------------+---------------+ 512 Fig. 10: Format 0x2 Name_Identifier 514 The EUI-64 address derived from this Name_Identifier has the format 515 depicted in figure 11 [FC-FS]. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | OUI with complemented U/L bit |0 0 1 0| VSID | 521 +---------------+-----------------------+-------+-------+-------+ 522 | VSID | Vendor Specific | 523 +---------------+-----------------------+-------+---------------+ 525 Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier 527 The IPv6 Interface Identifier is obtained from this EUI-64 address by 528 complementing the U/L bit in the OUI field. So the OUI in the IPv6 529 Interface ID is exactly as in the FC Name_Identifier. The resulting 530 IPv6 Interface Identifier has local scope [AARCH] and the format 531 depicted in figure 12. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | OUI |0 0 1 0| VSID | 537 +---------------+-----------------------+-------+-------+-------+ 538 | VSID | Vendor Specific | 539 +---------------+-----------------------+-------+---------------+ 541 Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier 543 As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF 544 generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. 546 6.4 Generating an Interface ID from a Format 5 N_Port_Name 548 The Name_Identifier format 0x5 is depicted in figure 13. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |0 1 0 1| OUI | VSID | 554 +-------+-------+---------------+---------------+-------+-------+ 555 | VSID | 556 +---------------+---------------+---------------+---------------+ 558 Fig. 13: Format 0x5 Name_Identifier 560 The EUI-64 address derived from this Name_Identifier has the format 561 depicted in figure 14 [FC-FS]. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | OUI with complemented U/L bit |0 1 0 1| VSID | 567 +---------------+---------------+---------------+-------+-------+ 568 | VSID | 569 +---------------+---------------+---------------+---------------+ 571 Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier 573 The IPv6 Interface Identifier is obtained from this EUI-64 address 574 complementing the U/L bit in the OUI field. So the OUI in the IPv6 575 Interface ID is exactly as in the FC Name_Identifier. The resulting 576 IPv6 Interface Identifier has local scope [AARCH] and the format 577 depicted in figure 15. 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | OUI |0 1 0 1| VSID | 583 +---------------+---------------+---------------+-------+-------+ 584 | VSID | 585 +---------------+---------------+---------------+---------------+ 587 Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier 589 As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 590 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. 592 6.5 Generating an Interface ID from an EUI-64 mapped N_Port_Name 594 The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) 595 are derived from an EUI-64 address by compressing the OUI field of 596 such addresses. The compression is performed by removing from the OUI 597 the Universal/Local and Individual/Group bits, and by putting bits 0 598 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 599 to 23 of the OUI in the second and third octet of the 600 Name_Identifier, as shown in figure 16. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |1 1| OUI[0..5] | OUI[8..23] | VSID | 606 +---+-----------+---------------+---------------+---------------+ 607 | VSID | 608 +---------------+---------------+---------------+---------------+ 610 Fig. 16: EUI-64 Mapped Name_Identifiers Format 612 The EUI-64 address used to generate the Name_Identifier shown in 613 figure 16 has the format depicted in figure 17. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | OUI[0..5] |0 0| OUI[8..23] | VSID | 619 +-----------+---+---------------+---------------+---------------+ 620 | VSID | 621 +---------------+---------------+---------------+---------------+ 623 Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier 625 The IPv6 Interface Identifier is obtained from this EUI-64 address by 626 complementing the U/L bit in the OUI field. The resulting IPv6 627 Interface Identifier has global scope [AARCH] and the format depicted 628 in figure 18. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | OUI[0..5] |1 0| OUI[8..23] | VSID | 634 +-----------+---+---------------+---------------+---------------+ 635 | VSID | 636 +---------------+---------------+---------------+---------------+ 638 Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier 640 As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A 641 generates the IPv6 Interface Identifier 3663:46AB:0125:789A. 643 7. Link-Local Addresses 645 The IPv6 link-local address [AARCH] for an Nx_Port is formed by 646 appending the Interface Identifier, as defined in section 6, to the 647 prefix FE80::/64. The resulting address is depicted in figure 19. 649 10 bits 54 bits 64 bits 650 +----------+-----------------------+----------------------------+ 651 |1111111010| (zeros) | Interface Identifier | 652 +----------+-----------------------+----------------------------+ 654 Fig. 19: IPv6 link-local Address Format 656 8. Address Mapping for Unicast 658 An Nx_Port has two kinds of Fibre Channel addresses: 659 - a non-volatile 64-bit address, called N_Port_Name; 660 - a volatile 24-bit address, called N_Port_ID. 662 The N_Port_Name is used to uniquely identify the Nx_Port, while the 663 N_Port_ID is used to route frames to the Nx_Port. Both FC addresses 664 are required to resolve an IPv6 unicast address. The fact that the 665 N_Port_ID is volatile implies that an Nx_Port MUST validate the 666 mapping between its N_Port_Name and N_Port_ID when certain Fibre 667 Channel events occur (see Appendix B). 669 The procedure for mapping IPv6 unicast addresses into Fibre Channel 670 link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The 671 Source/Target Link-layer Address option has the format depicted in 672 figure 20 when the link layer is Fibre Channel. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Type | Length = 2 | Reserved | 678 +---------------+---------------+---------------+---------------+ 679 | | 680 +- N_Port_Name -+ 681 | | 682 +---------------+---------------+---------------+---------------+ 683 | Reserved | N_Port_ID | 684 +---------------+---------------+---------------+---------------+ 686 Fig. 20: Source/Target Link-layer Address option for Fibre Channel 688 Type: 1 for Source Link-layer address. 689 2 for Target Link-layer address. 691 Length: 2 (in units of 8 octets). 693 N_Port_Name: This field contains the Nx_Port's N_Port_Name. 694 N_Port_ID: This field contains the Nx_Port's N_Port_ID. 696 Reserved fields MUST be zero when transmitting, and MUST be ignored 697 when receiving. 699 9. Address Mapping for Multicast 701 By default, all best-effort IPv6 multicast packets MUST be mapped to 702 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In 703 particular, datagrams addressed to all-nodes multicast address, 704 all-routers multicast address, and solicited-node multicast addresses 705 [AARCH] MUST be sent as Class 3 FC Sequences addressed to the 706 broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination 707 N_Port_Name field of the FC Network_Header MUST be set to the value 708 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a 709 Class 3 broadcast FC Sequence over various Fibre Channel topologies. 711 An Nx_Port supporting IPv6 MUST be able to map a received broadcast 712 Class 3 Device_Data FC frame to an implicit Port Login context in 713 order to handle IPv6 multicast packets. The receive data field size 714 of this implicit Port Login MUST be the same across all the Nx_Ports 715 connected to the same Fabric, otherwise FC broadcast transmission 716 does not work. In order to reduce the need for FC Sequence 717 segmentation, the receive data field size of this implicit Port Login 718 SHOULD be 1024 octets. This receive data field size requirement 719 applies to broadcast Device_Data FC frames, not to ELSs. 721 Receiving an FC Sequence carrying an IPv6 multicast packet MAY 722 trigger some additional processing by the Nx_Port if that IPv6 packet 723 requires a unicast reply. In this case, if a valid Port Login to the 724 Nx_Port that sent the IPv6 multicast packet does not exist, the 725 Nx_Port MUST perform such a Port Login, and then use it for the 726 unicast IPv6 reply. In the case of Neighbor Discovery messages 727 [DISC], the N_Port_ID to which the Port Login is directed is taken 728 from the N_Port_ID field of the Source/Target Link-layer Address 729 option. 731 As an example, an Nx_Port processes a received broadcast FC Sequence 732 carrying an IPv6 multicast unsolicited router advertisement [DISC] 733 simply by passing the carried IPv6 packet to the IPv6 layer. 734 Instead, if a received broadcast FC Sequence carries an IPv6 735 multicast solicitation message [DISC] requiring a unicast reply, and 736 no valid Port Login exists with the Nx_Port sender of the multicast 737 packet, then a Port Login MUST be performed in order to send the 738 unicast reply message. If a received broadcast FC Sequence carries an 739 IPv6 multicast solicitation message [DISC] requiring a multicast 740 reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF. 742 Best-effort IPv6 multicast for other multicast group addresses MAY 743 use Fibre Channel Multicast Groups [FC-FS], if supported by the 744 particular FC topology and implementation. 746 10. Sequence Management 748 FC Sequences are REQUIRED to be non-streamed. In order to avoid 749 missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting 750 IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each 751 Exchange MUST start with SEQ_CNT = 0 in the first frame, and every 752 frame transmitted after that MUST increment the previous SEQ_CNT by 753 one. Any frames received from the other N_Port in the Exchange shall 754 have no effect on the transmitted SEQ_CNT. 756 11. Exchange Management 758 To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange 759 for sending data to each Nx_Port in the network and a dedicated 760 Exchange for receiving data from each Nx_Port. 762 An Exchange Responder is not required to assign RX_IDs. If an RX_ID 763 of 0xFFFF is assigned, the Exchange Responder is identifying 764 Exchanges based on S_ID / D_ID / OX_ID only. 766 When an Exchange is created between two Nx_Ports for unicast IPv6 767 packets, it remains active while the Nx_Ports are logged in with each 768 other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short 769 lived Exchange. 771 For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because 772 they are used in a unidirectional mode. The Sequence Initiative bit 773 in the F_CTL field of the FC Header [FC-FS] MUST be set to 0. 775 The mechanism for aging or expiring exchanges based on activity, 776 timeout, or other methods is outside the scope of this document. 778 The Exchange Originator MAY terminate Exchanges by setting the F_CTL 779 LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator 780 or Exchange Responder by using the ABTS (Abort Sequence) protocol 781 [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since 782 this may terminate active Exchanges on other FC-4s [FC-FS]. 784 12. Security Considerations 786 IPv6 does not introduce any additional security concerns beyond those 787 that already exist within the Fibre Channel protocols. Zoning 788 techniques based on FC Name Server masking (soft zoning) do not work 789 with IPv6, because IPv6 over Fibre Channel does not use the FC Name 790 Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames 791 composing FC Sequences carrying IPv6 packets. All the techniques 792 defined to secure IPv6 traffic at the IPv6 layer may be used in a 793 Fibre Channel environment. 795 13. IANA Considerations 797 None. 799 14. Acknowledgments 801 The author would like to acknowledge the authors of [IPFC], [ETHER], 802 and [IPv6-1394], since some part of this document has been derived 803 from them, as well as the ANSI INCITS T11.3 Task Group members who 804 reviewed this document. 806 15. Normative References 808 [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and 809 Signaling (FC-FS)". 811 [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 812 (FC-AL-2)". 814 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 815 (IPv6) Specification", RFC 2460, December 1998. 817 [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 818 (IPv6) Addressing Architecture", RFC 3513, April 2003. 820 [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address 821 Autoconfiguration", RFC 2462, December 1998. 823 [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 824 Discovery for IP Version 6 (IPv6)", RFC 2461, 825 December 1998. 827 [PMTUD] McCann, J., Deering, S. and J. Mogul, "Path MTU 828 Discovery for IP version 6", RFC 1981, August 1996. 830 [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and 831 Metropolitan Area Networks: Overview and Architecture". 833 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, March 1997. 836 16. Informative References 838 [IPFC] Rajagopal, M., Bhagwat, R. and W. Rickard, "IP and ARP 839 over Fibre Channel", RFC 2625, June 1999. 841 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 842 RFC 2402, November 1998. 844 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 845 Payload (ESP)", RFC 2406, November 1998. 847 [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", 848 http://standards.ieee.org/db/oui/tutorials/EUI64.html 850 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 851 Networks", RFC 2464, December 1998. 853 [IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 854 over IEEE 1394 Networks", RFC 3146, October 2001. 856 17. Author's Address 858 Claudio DeSanti 859 Cisco Systems, Inc. 860 170 W. Tasman Dr. 861 San Jose, CA 95134 862 USA 864 Phone: +1 408 853-9172 865 EMail: cds@cisco.com 867 A. Transmission of a Broadcast FC Sequence over FC Topologies 869 A.1 Point-to-Point Topology 871 No particular mechanisms are required for this case. The Nx_Port 872 connected at the other side of the cable receives the broadcast FC 873 Sequence having D_ID 0xFFFFFF. 875 A.2 Private Loop Topology 877 An NL_Port attached to a private loop MUST transmit a Class 3 878 broadcast FC Sequence by using the OPN(fr) primitive signal 879 [FC-AL-2]. 881 a) The source NL_Port first sends an Open Broadcast Replicate 882 (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop 883 (except itself) to replicate the frames that they receive while 884 examining the FC Header's D_ID field. 885 b) The source NL_Port then removes the OPN(fr) signal when it returns 886 to it. 887 c) The source NL_Port then sends the Class 3 broadcast FC Sequence 888 having D_ID 0xFFFFFF. 890 A.3 Public Loop Topology 892 An NL_Port attached to a public loop MUST NOT use the OPN(fr) 893 primitive signal. Rather, it MUST send the Class 3 broadcast FC 894 Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 895 [FC-AL-2]. 897 The Fabric propagates the broadcast to all other FC_Ports [FC-FS], 898 including the FL_Port which the broadcast arrived on. This includes 899 all F_Ports, and other FL_Ports. 901 Each FL_Port propagates the broadcast by using the primitive signal 902 OPN(fr), in order to prepare the loop to receive the broadcast 903 sequence. 905 A.4 Fabric Topology 907 An N_Port connected to an F_Port MUST transmit the Class 3 broadcast 908 FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates 909 the broadcast to all other FC_Ports [FC-FS]. 911 B. Validation of the mapping 913 B.1 Overview 915 At all times, the mapping must be valid 916 before use. 918 After an FC link interruption occurs, the N_Port_ID of an Nx_Port may 919 change, as well as the N_Port_IDs of all other Nx_Ports that have 920 previously performed Port Login with this Nx_Port. Because of this, 921 address validation is required after a LIP in a loop topology 922 [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS]. 924 N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus 925 address validation is not required in this case. 927 B.2 FC Layer Address Validation in a Point-to-Point Topology 929 No validation is required after LR. In a point-to-point topology, 930 NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS 931 each N_Port must again perform a Port Login [FC-FS]. 933 B.3 FC Layer Address Validation in a Private Loop Topology 935 After a LIP [FC-AL-2], an NL_Port must not transmit any data to 936 another NL_Port until the address of the other port has been 937 validated. The validation consists of completing either ADISC or 938 PDISC [FC-FS]. 940 For a requester, this specification prohibits PDISC and requires 941 ADISC. As a responder, an implementation may need to respond to both 942 ADISC and PDISC for compatibility with other FC specifications. 944 If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a 945 logged remote NL_Port exactly match the values prior to the LIP, then 946 any active Exchange with that NL_Port may continue. 948 If any of the three FC addresses has changed, then the remote NL_Port 949 must be logged out. 951 If an NL_Port's N_Port_ID changes after a LIP, then all active logged 952 in NL_Ports must be logged out. 954 B.4 FC Layer Address Validation in a Public Loop Topology 956 A FAN ELS may be sent by the Fabric to all known previously logged in 957 NL_Ports following an initialization event. Therefore, after a LIP 958 [FC-AL-2], NL_Ports may wait for this notification to arrive, or they 959 may perform an FLOGI. 961 If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI 962 response exactly match the values before the LIP and if the AL_PA 963 [FC-AL-2] obtained by the NL_Port is the same as the one before the 964 LIP, then the port may resume all Exchanges. If not, then FLOGI must 965 be performed with the Fabric and all logged in Nx_Ports must be 966 logged out. 968 A public loop NL_Port must perform the private loop validation as 969 specified in section B.3 to any NL_Port on the local loop that has an 970 N_Port_ID of the form 0x00-00-XX. 972 B.5 FC Layer Address Validation in a Fabric Topology 974 No validation is required after LR (link reset). 976 After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the 977 N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same 978 as before the NOS/OLS, then the N_Port may resume all Exchanges. If 979 not, all logged in Nx_Ports must be logged out [FC-FS]. 981 C. Fibre Channel Bit and Byte Numbering Guidance 983 Both Fibre Channel and IETF standards use the same byte transmission 984 order. However, the bit numbering is different. 986 Fibre Channel bit numbering can be observed if the data structure 987 heading shown in figure 21 is cut and pasted at the top of the 988 figures present in this document. 990 3 2 1 0 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 Fig. 21: Fibre Channel Bit Numbering 996 Full Copyright Statement 998 Copyright (C) The Internet Society (2003). All Rights Reserved. 1000 This document and translations of it may be copied and furnished to 1001 others, and derivative works that comment on or otherwise explain it 1002 or assist in its implementation may be prepared, copied, published 1003 and distributed, in whole or in part, without restriction of any 1004 kind, provided that the above copyright notice and this paragraph are 1005 included on all such copies and derivative works. However, this 1006 document itself may not be modified in any way, such as by removing 1007 the copyright notice or references to the Internet Society or other 1008 Internet organizations, except as needed for the purpose of 1009 developing Internet standards in which case the procedures for 1010 copyrights defined in the Internet Standards process must be 1011 followed, or as required to translate it into languages other than 1012 English. 1014 The limited permissions granted above are perpetual and will not be 1015 revoked by the Internet Society or its successors or assigns. 1017 This document and the information contained herein is provided on an 1018 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1019 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1020 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1021 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1022 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Acknowledgement 1026 Funding for the RFC Editor function is currently provided by the 1027 Internet Society. 1029 Notice of Intellectual Property Rights 1031 The IETF takes no position regarding the validity or scope of any 1032 intellectual property or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; neither does it represent that it 1036 has made any effort to identify any such rights. Information on the 1037 IETF's procedures with respect to rights in standards-track and 1038 standards-related documentation can be found in BCP-11. Copies of 1039 claims of rights made available for publication and any assurances 1040 of licenses to be made available, or the result of an attempt made 1041 to obtain a general license or permission for the use of such 1042 proprietary rights by implementors or users of this specification 1043 can be obtained from the IETF Secretariat. 1045 The IETF invites any interested party to bring to its attention any 1046 copyrights, patents or patent applications, or other proprietary 1047 rights which may cover technology that may be required to practice 1048 this standard. Please address the information to the IETF Executive 1049 Director.