Internet Draft Claudio DeSanti draft-desanti-ipv6-over-fibre-channel-00.txt Andiamo Systems Expires: March 2003 October 2002 IPv6 over Fibre Channel Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and IPv4, as specified in [IP-FC]. The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network. Claudio DeSanti Expires March 2003 [Page 1] INTERNET DRAFT IPv6 over Fibre Channel October 2002 1. IPv6-Capable Nx_Ports This specification assumes that an an IPv6-capable Nx_Port is compliant with [FC-MI]. In addition, and more specifically: - It MUST have an N_Port_Name of format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered). Other Name_Identifier formats are not usable to support IPv6. - It MUST support Class 3. - It MUST support continously increasing SEQ_CNT [FC-FS]. - It MUST support a FC Sequence Payload size for Device_Data FC frames of at least 1304 octects. - It SHOULD support a receive data field size for Device_Data FC frames of at least 1024 octets. 2. IPv6 Encapsulation 2.1 FC Sequence Encapsulation An application level payload such as IPv6 is called an Information Unit at the FC-4 Level of Fibre Channel. Lower FC levels map this to a FC Sequence. An IPv6 Sequence MUST carry the FC Network_Header and the LLC/SNAP header. This leads to the following FC Sequence Payload format: +---------------+---------------+---------------+---------------+ | | +- -+ | Network_Header | +- (16 bytes) -+ | | +- -+ | | +---------------+---------------+---------------+---------------+ | LLC/SNAP header | +- (8 bytes) -+ | | +---------------+---------------+---------------+---------------+ | | +- -+ | | / IPv6 Packet / | | +- -+ | | +---------------+---------------+---------------+---------------+ Claudio DeSanti Expires March 2003 [Page 2] INTERNET DRAFT IPv6 over Fibre Channel October 2002 The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing the FC Sequence, although also [AH] or [ESP] may instead be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence. Typically, a Sequence consists of more than one frame. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/ SNAP header, the other frames MUST NOT include them, as depicted in the following figure. First Frame of an IPv6 FC Sequence +-----------+-------------------+-----------------+-------//--------+ | FC Header | FC Network_Header | LLC/SNAP header | First chunk of | | | | | the IPv6 Packet | +-----------+-------------------+-----------------+-------//--------+ Subsequent Frames of an IPv6 FC Sequence +-----------+-----------------//------------------+ | FC Header | Additional chunk of the IPv6 Packet | +-----------+----------------//-------------------+ 2.2 Classes of Service An IPv6 packet MUST be encapsulated in Fibre Channel using FC Class 3. Other FC Classes of Service are not supported. 2.3 FC Header The figure below depicts the fields of the Fibre Channel Header: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+===============+ | R_CTL | D_ID | +---------------+---------------+---------------+---------------+ | CS_CTL/Prio | S_ID | +---------------+---------------+---------------+---------------+ | TYPE | F_CTL | +---------------+---------------+---------------+---------------+ | SEQ_ID | DF_CTL | SEQ_CNT | +---------------+---------------+---------------+---------------+ | OX_ID | RX_ID | +---------------+---------------+---------------+---------------+ | Parameter | +---------------+---------------+---------------+---------------+ Claudio DeSanti Expires March 2003 [Page 3] INTERNET DRAFT IPv6 over Fibre Channel October 2002 To encapsulate IPv6 over FC the following code points MUST be used: - R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information Category [FC-FS]) - TYPE: 0x05 (IP over Fibre Channel) - CS_CTL/Prio: 0x0 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 Sequence, 0x00 for the following FC frames. - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 8. 2.4 FC Network_Header The figure below depicts the fields of the FC Network_Header: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+===============+ | | +- Destination N_Port_Name -+ | | +---------------------------------------------------------------+ | | +- Source N_Port_Name -+ | | +---------------------------------------------------------------+ For use with IPv6 the N_Port_Names MUST be of format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered). Other Name_Identifier formats are not usable to support IPv6. 2.5 LLC/SNAP Header The figure below depicts the fields of the LLC/SNAP Header: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+===============+ | DSAP | SSAP | CTRL | OUI | +---------------+---------------+---------------+---------------+ | OUI | PID | +---------------+---------------+---------------+---------------+ To encapsulate IPv6 over FC the following code points MUST be used: - DSAP: 0xAA - SSAP: 0xAA - CTRL: 0x03 - OUI: 0x00-00-00 - PID: 0x86-DD Claudio DeSanti Expires March 2003 [Page 4] INTERNET DRAFT IPv6 over Fibre Channel October 2002 2.6 Bit and Byte Ordering IPv6 packets are mapped to FC-4 Level using the big-endian byte ordering, which corresponds to the standard network byte order or canonical form. 3. Maximum Transfer Unit The default MTU size for IPv6 [IPV6] packets over Fibre Channel is 65280 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each Nx_Port. However, as required by [IPV6], the MTU MUST NOT be lower than 1280 octects. If a Router Advertisement received on an Nx_Port has an MTU option specifying an MTU larger than 65280, or larger than a manually configured value, that MTU option MAY be logged to system management but MUST be otherwise ignored. 4. Stateless Autoconfiguration 4.1 IPv6 Interface Identifier and Address Prefix The IPv6 Interface Identifier [AARCH] for an Nx_Port is based on the EUI-64 identifier [EUI64] derived from the Nx_Port's N_Port_Name [FC-FS]. The IPv6 Interface Identifier is obtained by complementing the Universal/Local bit of the OUI field of the derived EUI-64 identifier. For use with IPv6 the N_Port_Name MUST be a Name_Identifier of format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered). [FC-FS] specifies a method to map these FC Name_Identifiers in EUI-64 identifiers [EUI64]. An IPv6 Address Prefix used for stateless autoconfiguration [ACONF] of an Nx_Port MUST have a length of 64 bits. Claudio DeSanti Expires March 2003 [Page 5] INTERNET DRAFT IPv6 over Fibre Channel October 2002 4.2 IPv6 Interface Identifier with FC Name_Identifier of Format 0x1 The Name_Identifier format 0x1 is as follows: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +=======+=======+===============+===============+===============+ | 0x1 | 0x000 | OUI | +-------+-------+---------------+---------------+---------------+ | OUI | VSID | +---------------+---------------+---------------+---------------+ The EUI-64 identifier derived from this Name_Identifier has the following format [FC-FS]: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI with negated U/L bit | 0x1 | VSID | +---------------+---------------+-------+-------+-------+-------+ | VSID | 0x000 | +---------------+---------------+-------+-------+---------------+ The IPv6 Interface Identifier is obtained from this EUI-64 identifier complementing (again) the U/L bit in the OUI field. So the OUI in the IPv6 Interface Identifier is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local validity [AARCH] and the following format: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI | 0x1 | VSID | +---------------+---------------+-------+-------+-------+-------+ | VSID | 0x000 | +---------------+---------------+-------+-------+---------------+ As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. Claudio DeSanti Expires March 2003 [Page 6] INTERNET DRAFT IPv6 over Fibre Channel October 2002 4.3 IPv6 Interface Identifier with FC Name_Identifier of Format 0x2 The Name_Identifier format 0x2 is as follows: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +=======+=======+===============+===============+===============+ | 0x2 | Vendor Specific | OUI | +-------+-------+---------------+---------------+---------------+ | OUI | VSID | +---------------+---------------+---------------+---------------+ The EUI-64 identifier derived from this Name_Identifier has the following format [FC-FS]: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI with negated U/L bit | 0x2 | VSID | +---------------+-----------------------+-------+-------+-------+ | VSID | Vendor Specific | +---------------+-----------------------+-------+---------------+ The IPv6 Interface Identifier is obtained from this EUI-64 identifier complementing (again) the U/L bit in the OUI field. So the OUI in the IPv6 Interface Identifier is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local validity [AARCH] and the following format: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI | 0x2 | VSID | +---------------+-----------------------+-------+-------+-------+ | VSID | Vendor Specific | +---------------+-----------------------+-------+---------------+ As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. Claudio DeSanti Expires March 2003 [Page 7] INTERNET DRAFT IPv6 over Fibre Channel October 2002 4.4 IPv6 Interface Identifier with FC Name_Identifier of Format 0x5 The Name_Identifier format 0x5 is as follows: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | 0x5 | OUI | VSID | +-------+-------+---------------+---------------+-------+-------+ | VSID | +---------------+---------------+---------------+---------------+ The EUI-64 identifier derived from this Name_Identifier has the following format [FC-FS]: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI with negated U/L bit | 0x5 | VSID | +---------------+---------------+---------------+-------+-------+ | VSID | +---------------+---------------+---------------+---------------+ The IPv6 Interface Identifier is obtained from this EUI-64 identifier complementing (again) the U/L bit in the OUI field. So the OUI in the IPv6 Interface Identifier is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local validity [AARCH] and the following format: +---------------+---------------+---------------+---------------+ | bit <31:24> | bit <23:16> | bit <15:08> | bit <07:00> | +===============+===============+===============+=======+=======+ | OUI | 0x5 | VSID | +---------------+---------------+---------------+-------+-------+ | VSID | +---------------+---------------+---------------+---------------+ As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. Claudio DeSanti Expires March 2003 [Page 8] INTERNET DRAFT IPv6 over Fibre Channel October 2002 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ 6. Address Mapping for Unicast An Nx_Port has two kinds of Fibre Channel link-layer addresses: - a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID. The N_Port_Name is used to uniquely identify the Nx_Port, while the N_Port_ID is used to route frames to the Nx_Port. Resolving an IPv6 unicast address means find both addresses. The fact that the N_Port_ID is volatile implies that the mapping between N_Port_Name and N_Port_ID MUST be valid before use. Appendix B discusses the validation process. The procedure for mapping IPv6 unicast addresses into Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Fibre Channel. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | | +---------------+---------------+ -+ | Name_Identifier | +- +---------------+---------------+ | | FC_ID | +---------------+---------------+---------------+---------------+ | FC_ID | Reserved | +---------------+---------------+---------------+---------------+ Type: 1 for Source Link-layer address. 2 for Target Link-layer address. Length: 2 (in units of 8 octets). Name_Identifier: This field contains the Nx_Port's N_Port_Name. FC_ID: This field contains the Nx_Port's N_Port_ID. Claudio DeSanti Expires March 2003 [Page 9] INTERNET DRAFT IPv6 over Fibre Channel October 2002 7. Address Mapping for Multicast By default, all best-effort IPv6 multicast packets MUST be mapped to FC Sequences addressed to the broadcast FC address 0xFF-FF-FF. In particular, datagrams addressed to all-nodes multicast address, all-routers multicast address, and solicited-node multicast addresses [AARCH] MUST be sent as Class 3 FC Sequences addressed to the broadcast FC address 0xFF-FF-FF. In this case, the Destination N_Port_Name field of the Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A describes how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies. An Nx_Port supporting IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context in order to handle IPv6 multicast packets. In order to reduce the need of FC Sequence segmentation, the receive data field size of this implicit Port Login SHOULD be 1024 bytes. This size requirement applies to Device_Data FC frames. Receiving a FC Sequence carrying an IPv6 multicast packet MAY trigger some additional processing by the Nx_Port if that IPv6 packet requires a reply. In this case, if a valid Port Login to the Nx_Port which sent the IPv6 multicast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast IPv6 reply. The N_Port_ID to which perform the Port Login is taken from FC_ID field of the Source/Target Link-layer Address option. As an example, an Nx_Port processes a received broadcast FC Sequence carrying an IPv6 multicast unsolicited router advertisement [DISC] simply by passing the carried IPv6 packet to the IPv6 layer. Instead, if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a reply, and no valid Port Login exists with the Nx_Port sender of the multicast packet, then such a Port Login MUST be performed in order to send the unicast reply message. Best-effort IPv6 multicast for other multicast group addresses MAY use the Fibre Channel Alias Server to be mapped over a Fibre Channel Multicast Group, if this functionality is supported by the particular FC topology and implementation [FC-FS, FC-GS-3]. 8. Sequence and Exchange Management 8.1 Sequence Management This specification is based on FC Class 3. As such, FC Sequences are REQUIRED to be non-streamed. Additionally, in order to avoid missing Claudio DeSanti Expires March 2003 [Page 10] INTERNET DRAFT IPv6 over Fibre Channel October 2002 FC frame aliasing by Sequence ID reusing, an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that MUST increment the previous SEQ_CNT by one. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT. 8.2 Exchange Management To transfer IPv6 packets, each Nx_Port MUST have a dedicated OX_ID for sending data to each Nx_Port in the network and a dedicated RX_ID for receiving data from each Nx_Port as well. An Exchange Responder is not required to assign RX_IDs. If a RX_ID of 0xFFFF is assigned, it is identifying Exchanges based on S_ID / D_ID / OX_ID only. When an Exchange is created between 2 Nx_Ports for unicast IPv6 packets, it remains active while the Nx_Ports are logged in with each other. FC Broadcasts and ELSs [FC-FS] may use short lived Exchanges. For IPv6, Exchanges are used in a unidirectional mode, they MUST NOT transfer Sequence Initiative. For IPv6, setting Sequence Initiative in the F_CTL field of the FC Header [FC-FS] is not valid. The mechanism for aging or expiring exchanges based on activity, timeout, or other method is outside the scope of this document. The Exchange Originator MAY terminate Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator or Exchange Responder by using the ABTS protocol. IPv6 Exchanges SHOULD NOT be terminated by Logout, since this may terminate active Exchanges on other FC-4s [FC-FS]. 9. Security Considerations IPv6 does not introduce any additional security concerns beyond what already exists within the Fibre Channel protocols. 10. Acknowledgment The author would like to acknowledge the authors of [IP-FC], [ETHER], and [IPv6-1394], since some part of this document has been derived from them. Claudio DeSanti Expires March 2003 [Page 11] INTERNET DRAFT IPv6 over Fibre Channel October 2002 11. References [FC-FS] ANSI INCITS Project 1331-D, "Fibre Channel - Framing and Signaling (FC-FS)", Rev 1.70, February 2002. [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel-Arbitrated Loop-2 (FC-AL-2)". [FC-MI] ANSI INCITS Project 1377-DT, "Fibre Channel - Methodologies for Interconnects (FC-MI)", Rev 1.92, December 2001. [FC-GS-3] ANSI INCITS 348-2000, "Fibre Channel - Generic Services-3 (FC-GS-3)", Rev 7.01, November 2000. [IP-FC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999. [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 December 1998. [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Claudio DeSanti Expires March 2003 [Page 12] INTERNET DRAFT IPv6 over Fibre Channel October 2002 12. Author's Address Claudio DeSanti Andiamo Systems, Inc. 375 E. Tasman Dr. San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@andiamo.com Claudio DeSanti Expires March 2003 [Page 13] INTERNET DRAFT IPv6 over Fibre Channel October 2002 A. Transmission of a Broadcast FC Sequence over FC Topologies A.1 Point-to-Point Topology No particular mechanisms are required for this case. The Nx_Port connected at the other side of the cable receives the broadcast FC Sequence. A.2 Private Loop Topology An NL_Port attached to a private loop transmits a Class 3 broadcast FC Sequence by using the OPN(fr) signal primitive [FC-AL-2]. a)The source NL_Port first sends an Open Broadcast Replicate primitive (OPN(fr))Signal forcing all the NL_Ports in the loop (except itself), to replicate the frames that they receive while examining the frame header's Destination_ID field. b)The source NL_Port then removes this OPN(fr) signal when it returns to it. c)The source NL_Port now sends the Class 3 broadcast FC Sequence. A.3 Public Loop Topology An NL_Port attached to a public loop MUST NOT use the OPN(fr) signal primitive. Rather, it sends the Class 3 broadcast FC Sequence to the FL_Port at AL_PA = 0x00 [FC-AL-2]. The FC Fabric propagates the broadcast to all other FC_Ports, including the FL_Port which the broadcast arrived on. This includes all F_Ports, and other FL_Ports. Each FL_Port propagates the broadcast by first using the primitive signal OPNfr, in order to prepare the loop to receive the broadcast sequence. A.4 Fabric Topology An N_Port connected to an F_Port simply transmits the Class 3 broadcast FC Sequence to the F_Port. The Fabric propagates the broadcast to all other FC_Ports. Claudio DeSanti Expires March 2003 [Page 14] INTERNET DRAFT IPv6 over Fibre Channel October 2002 B. Validation of the mapping B.1 General Discussion At all times, the mapping MUST be valid before use. The following discussion addresses conditions when such a validation is required. After a FC link interruption occurs, the N_Port_ID of a Nx_Port may change, as well as the N_Port_IDs of all other Nx_Ports that have previously performed Port Login with this Nx_Port. Because of this, address validation is required after a LIP in a loop topology [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS]. N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus address validation is not required in this case. In addition to actively validating devices after a link interruption, if a Nx_Port receives any FC-4 data frames (other than broadcast frames), from a Nx_Port that is not currently logged in, then it MUST send LOGO ELS request [FC-FS] to that port. B.2 FC Layer Address Validation in a Point-to-Point Topology No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS, each N_Port MUST perform again a PLOGI [FC-FS]. B.3 FC Layer Address Validation in a Private Loop Topology After a LIP, a NL_Port MUST not transmit any link data to another NL_Port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC [FC-FS]. As a requester, this specification prohibits PDISC and requires ADISC. As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications. If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a logged remote NL_Port exactly match the values prior to the LIP, then any active exchanges with that NL_Port may continue. Claudio DeSanti Expires March 2003 [Page 15] INTERNET DRAFT IPv6 over Fibre Channel October 2002 If any of the three FC addresses has changed, then the remote NL_Port MUST be explicitly Logged out. If a NL_Port's N_Port ID changes after a LIP, then all active N_Port_ID to N_Port_Name mappings at this NL_Port must be explicitly Logged out. B.4 FC Layer Address Validation in a Public Loop Topology A FAN (Fabric Address Notification) ELS command is sent by the Fabric to all known previously logged in NL_Ports following an initialization event. Therefore, after a LIP, NL_Ports may wait for this notification to arrive or they may perform a FLOGI. If the F_Port_Name and Fabric_Name of the Fabric FL_Port contained in the FAN ELS or FLOGI response exactly match the values before the LIP, and if the AL_PA obtained by the NL_Port is the same as the one before the LIP, then the port may resume all exchanges. If not, then FLOGI (Fabric Login) must be performed with the Fabric and all logged in Nx_Ports MUST be explicitly Logged out. A public loop NL_Port MUST perform the private loop validation to any NL_Port on the local loop which have an N_Port_ID of the form 0x00-00-XX. B.5 FC Layer Address Validation in a Fabric Topology No validation is required after LR (link reset). After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same as before the NOS/OLS, then the N_Port may resume all exchanges. If not, all logged in Nx_Ports MUST be explicitly Logged out [FC-FS, FC-MI]. Claudio DeSanti Expires March 2003 [Page 16]