From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3831.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc3831.txt (limited to 'doc/rfc/rfc3831.txt') diff --git a/doc/rfc/rfc3831.txt b/doc/rfc/rfc3831.txt new file mode 100644 index 0000000..7dcfa4c --- /dev/null +++ b/doc/rfc/rfc3831.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group C. DeSanti +Request for Comments: 3831 Cisco Systems +Category: Standards Track July 2004 + + + Transmission of IPv6 Packets over Fibre Channel + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document specifies the way of encapsulating IPv6 packets over + Fibre Channel, and the method of forming IPv6 link-local addresses + and statelessly autoconfigured addresses on Fibre Channel networks. + +Table Of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3 + 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3 + 2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4 + 2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5 + 3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6 + 4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6 + 4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8 + 4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8 + 4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9 + 4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9 + 4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9 + 5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10 + 6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10 + 6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10 + 6.2. Generating an Interface ID from a Format 1 + N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11 + 6.3. Generating an Interface ID from a Format 2 + N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12 + + + +DeSanti Standards Track [Page 1] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + 6.4. Generating an Interface ID from a Format 5 + N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13 + 6.5. Generating an Interface ID from an EUI-64 + mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14 + 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15 + 8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15 + 9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16 + 10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17 + 11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17 + 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.1. Normative References. . . . . . . . . . . . . . . . . . 18 + 14.2. Informative References. . . . . . . . . . . . . . . . . 19 + A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20 + B. Validation of the mapping . . . . . . 21 + C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24 + +1. Introduction + + Fibre Channel (FC) is a high speed serial interface technology that + supports several Upper Layer Protocols including Small Computer + System Interface (SCSI) and IPv4 as specified in [IPFC]. + + 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. + + Warning to readers familiar with Fibre Channel: both Fibre Channel + and IETF standards use the same byte transmission order. However, + the bit numbering is different. See Appendix C for guidance. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + + + + + + + + + + +DeSanti Standards Track [Page 2] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +2. Summary of Fibre Channel + +2.1. Overview + + Fibre Channel (FC) is a gigabit speed network technology primarily + used for Storage Networking. Fibre Channel is standardized in the + T11 Technical Committee of the InterNational Committee for + Information Technology Standards (INCITS), an American National + Standard Institute (ANSI) accredited standards committee. + + Fibre Channel devices are called Nodes. Each Node has one or more + Ports that connect to Ports of other devices. Fibre Channel may be + implemented using any combination of the following three topologies: + + - a point-to-point link between two Ports; + - a set of Ports interconnected by a switching network called a + Fabric, as defined in [FC-FS]; + - a set of Ports interconnected with a loop topology, as defined in + [FC-AL-2]. + + A Node Port is more precisely called an N_Port. A Node Port that is + capable of operating in a loop topology using the loop specific + protocols is designated as an NL_Port. The term Nx_Port is used to + generically indicate these two kinds of Node Port. + + A Fabric Port is more precisely called an F_Port. A Fabric Port that + is capable of operating in a loop topology using the loop specific + protocols is designated as an FL_Port. The term Fx_Port is used to + generically indicate these two kinds of Fabric Port. + + From an IPv6 point of view, a Fibre Channel network, built with any + combination of the FC topologies described above, is an IPv6 Link + [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces. + +2.2. Identifiers and Login + + Fibre Channel entities are identified by permanent 64 bit long + Name_Identifiers. [FC-FS] defines several formats of + Name_Identifiers. The value of the first four bits defines the + format of a Name_Identifier. These names are referred to in a more + precise manner as follows: + + - an Nx_Port's Name_Identifier is called N_Port_Name; + - an Fx_Port's Name_Identifier is called F_Port_Name; + - a Node's Name_Identifier is called Node_Name; + - a Fabric's Name_Identifier is called Fabric_Name. + + + + + +DeSanti Standards Track [Page 3] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + An Nx_Port connected to a Fibre Channel network is associated with + two identifiers, its permanent N_Port_Name and a volatile 24 bit + address called N_Port_ID. The N_Port_Name is used to identify the + Nx_Port, while the N_Port_ID is used for communications among + Nx_Ports. + + Each Nx_Port acquires an N_Port_ID from the Fabric by performing a + process called Fabric Login or FLOGI. The FLOGI process is used also + to negotiate several communications parameters between the Nx_Port + and the Fabric, such as the receive data field size, which determines + the maximum size of the Fibre Channel frames that may be transferred + between the Nx_Port and the Fabric. + + Before effective communication may take place between two Nx_Ports, + they must complete a process called Port Login or PLOGI. The PLOGI + process provides each Nx_Port with the other Nx_Port's N_Port_Name, + and negotiates several communication parameters, such as the receive + data field size, which determines the maximum size of the Fibre + Channel frames that may be transferred between the two Nx_Ports. + + Both Fabric Login and Port Login may be explicit, i.e., performed + using specific FC control messages (called Extended Link Services or + ELS), or implicit, in which the parameters are specified by + configuration or other methods. + +2.3. FC Levels and Frame Format + + [FC-FS] describes the Fibre Channel protocol using 5 different + levels. The FC-2 and FC-4 levels are relevant for this + specification. The FC-2 level defines the FC frame format, the + transport services, and control functions necessary for information + transfer. The FC-4 level supports Upper Level Protocols, such as + IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in + figure 1. + + +-----+-----------+-----------+--------//-------+-----+-----+ + | | | Data Field | | | + | SOF | FC Header |<--------------------------->| CRC | EOF | + | | | Optional | Frame | | | + | | | Header(s) | Payload | | | + +-----+-----------+-----------+--------//-------+-----+-----+ + + Fig. 1: Fibre Channel Frame Format + + The Start of Frame (SOF) and End of Frame (EOF) are special FC + transmission words that act as frame delimiters. The CRC is 4 octets + long and uses the same 32-bit polynomial used in FDDI. + + + + +DeSanti Standards Track [Page 4] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + The FC Header is 24 octets long and contains several fields + associated with the identification and control of the Data Field. + + The Data Field is of variable size, ranging from 0 to 2112 octets, + and includes the user data in the Frame Payload field, and Optional + Headers. The currently defined Optional Headers are: + + - ESP_Header; + - Network_Header; + - Association_Header; + - Device_Header. + + The value of the SOF field determines the FC Class of service + associated with the frame. Five Classes of service are specified in + [FC-FS]. They are distinguished primarily by the method of flow + control between the communicating Nx_Ports and by the level of data + integrity provided. A given Fabric or Nx_Port may support one or + more of the following Classes of service: + + - Class 1: Dedicated physical connection with delivery confirmation; + - Class 2: Frame multiplexed service with delivery confirmation; + - Class 3: Datagram service; + - Class 4: Fractional bandwidth; + - Class 6: Reliable multicast via dedicated connections. + +2.4. Sequences and Exchanges + + An application level payload such as IPv6 is called Information Unit + at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is + mapped to an FC Sequence by the FC-2 level. An FC Sequence consists + of one or more FC frames related by the value of the Sequence_ID + (SEQ_ID) field of the FC Header. + + The maximum data that may be carried by an FC frame is 2112 octets. + The maximum usable frame size depends on the Fabric and Nx_Port + implementations and is negotiated during the Login process. Whenever + an Information Unit to be transmitted exceeds this value, the FC-2 + level segments it into multiple FC frames, sent as a single Sequence. + The receiving Nx_Port reassembles the Sequence of frames and delivers + a reassembled Information Unit to the FC-4 level. The Sequence Count + (SEQ_CNT) field of the FC Header may be used to ensure frame + ordering. + + Multiple Sequences may be related together as belonging to the same + FC Exchange. The Exchange is a mechanism used by two Nx_Ports to + identify and manage an operation between them. The Exchange is + opened when the operation is started between the two Nx_Ports, and + closed when the operation ends. FC frames belonging to the same + + + +DeSanti Standards Track [Page 5] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + Exchange are related by the value of the Exchange_ID fields in the FC + Header. An Originator Exchange_ID (OX_ID) and a Responder + Exchange_ID (RX_ID) uniquely identify the Exchange. + +3. IPv6 Capable Nx_Ports + + This specification requires an IPv6 capable Nx_Port to have the + following properties: + + - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, + 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other + Name_Identifier formats is outside the scope of this + specification; + - It MUST support Class 3; + - It MUST support continuously increasing SEQ_CNT [FC-FS]; + - It MUST be able to transmit and receive an FC-4 Information Unit + at least 1304 octets long; + - It SHOULD support a receive data field size for Device_Data FC + frames of at least 1024 octets. + +4. IPv6 Encapsulation + +4.1. FC Sequence Format + + An IPv6 packet is mapped to an Information Unit at the FC-4 level of + Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 + level. An FC Information Unit containing an IPv6 packet MUST carry + the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], + resulting in the FC Information Unit format depicted in figure 2. + + + + + + + + + + + + + + + + + + + + + + +DeSanti Standards Track [Page 6] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + +---------------+---------------+---------------+---------------+ + | | + +- -+ + | Network_Header | + +- (16 octets) -+ + | | + +- -+ + | | + +---------------+---------------+---------------+---------------+ + | LLC/SNAP header | + +- (8 octets) -+ + | | + +---------------+---------------+---------------+---------------+ + | | + +- -+ + / IPv6 Packet / + / / + +- -+ + | | + +---------------+---------------+---------------+---------------+ + + Fig. 2: FC Information Unit Mapping an IPv6 Packet + + The FC ESP_Header [FC-FS] MAY be used to secure the FC frames + composing the FC Sequence. [AH] or [ESP] may 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 figure 3. + + + 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 | + +-----------+----------------//-------------------+ + + Fig. 3: Optional Headers in an IPv6 FC Sequence + + + + + +DeSanti Standards Track [Page 7] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +4.2. FC Classes of Service + + This specification uses FC Class 3. IPv6 packets carrying Neighbor + Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. + Other IPv6 packets SHOULD use Class 3 as well. The use of other + Classes of service is outside the scope of this specification. + +4.3. FC Header Code Points + + The fields of the Fibre Channel Header are depicted in figure 4. The + D_ID and S_ID fields contain respectively the destination N_Port_ID + and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel 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. If the FC ESP_Header + is used, then 0x60 for the first FC frame of an IPv6 Sequence, + 0x40 for the following FC frames. + - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10, + section 11, and [FC-FS] for additional requirements. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R_CTL | D_ID | + +---------------+---------------+---------------+---------------+ + | CS_CTL/Prio | S_ID | + +---------------+---------------+---------------+---------------+ + | TYPE | F_CTL | + +---------------+---------------+---------------+---------------+ + | SEQ_ID | DF_CTL | SEQ_CNT | + +---------------+---------------+---------------+---------------+ + | OX_ID | RX_ID | + +---------------+---------------+---------------+---------------+ + | Parameter | + +---------------+---------------+---------------+---------------+ + + Fig. 4: FC Header Format + + + + + + + + + +DeSanti Standards Track [Page 8] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +4.4. FC Network_Header + + The fields of the FC Network_Header are depicted in figure 5. For + use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, + 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats + is outside the scope of this specification. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- Destination N_Port_Name -+ + | | + +---------------------------------------------------------------+ + | | + +- Source N_Port_Name -+ + | | + +---------------------------------------------------------------+ + + Fig. 5: FC Network_Header Format + +4.5. LLC/SNAP Header + + The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure + 6. To encapsulate IPv6 over Fibre Channel the following code points + MUST be used: + + - DSAP: 0xAA + - SSAP: 0xAA + - CTRL: 0x03 + - OUI: 0x00-00-00 + - PID: 0x86-DD + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DSAP | SSAP | CTRL | OUI | + +---------------+---------------+---------------+---------------+ + | OUI | PID | + +---------------+---------------+---------------+---------------+ + + Fig. 6: LLC/SNAP Header Format + +4.6. Bit and Byte Ordering + + IPv6 packets are mapped to the FC-4 level using the big-endian byte + ordering that corresponds to the standard network byte order or + canonical form. + + + +DeSanti Standards Track [Page 9] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +5. 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 that 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 octets. 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. + + As the default MTU size far exceeds the message sizes typically used + in the Internet, an IPv6 over FC implementation SHOULD implement Path + MTU Discovery [PMTUD], or at least maintain different MTU values for + on-link and off-link destinations. + + For correct operation in a routed environment, it is critically + important to configure an appropriate MTU option in Router + Advertisements. + + For correct operation when mixed media (e.g., Ethernet and Fibre + Channel) are bridged together, the smallest MTU of all the media must + be advertised by routers in an MTU option. If there are no routers + present, this MTU must be manually configured in each node which is + connected to a medium with a default MTU larger than the smallest + MTU. + +6. Stateless Address Autoconfiguration + +6.1. IPv6 Interface Identifier and Address Prefix + + The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 + address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 + Interface Identifier is obtained by complementing the Universal/Local + bit of the OUI field of the derived EUI-64 address. + + [FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), + or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers + in EUI-64 addresses. This allows the usage of these Name_Identifiers + to support IPv6. [FC-FS] also defines EUI-64 mapped FC + Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived + from an EUI-64 address. It is possible to reverse this address + mapping to obtain the original EUI-64 address in order to support + IPv6. + + + + + + +DeSanti Standards Track [Page 10] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + Stateless address autoconfiguration MUST be performed as specified in + [ACONF]. An IPv6 Address Prefix used for stateless address + autoconfiguration of an Nx_Port MUST have a length of 64 bits. + +6.2. Generating an Interface ID from a Format 1 N_Port_Name + + The Name_Identifier format 0x1 is depicted in figure 7. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1| 0x000 | OUI | + +-------+-------+---------------+---------------+---------------+ + | OUI | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 7: Format 0x1 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + depicted in figure 8 [FC-FS]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 0 0 1| VSID | + +---------------+---------------+-------+-------+-------+-------+ + | VSID | 0x000 | + +---------------+---------------+-------+-------+---------------+ + + Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier + + The IPv6 Interface Identifier is obtained from this EUI-64 address by + complementing the U/L bit in the OUI field. So the OUI in the IPv6 + Interface ID is exactly as in the FC Name_Identifier. The resulting + IPv6 Interface Identifier has local scope [AARCH] and the format + depicted in figure 9. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI |0 0 0 1| VSID | + +---------------+---------------+-------+-------+-------+-------+ + | VSID | 0x000 | + +---------------+---------------+-------+-------+---------------+ + + Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier + + + + + +DeSanti Standards Track [Page 11] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF + generates the IPv6 Interface Identifier 3463:461A:BCDE:F000. + +6.3. Generating an Interface ID from a Format 2 N_Port_Name + + The Name_Identifier format 0x2 is depicted in figure 10. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 0| Vendor Specific | OUI | + +-------+-------+---------------+---------------+---------------+ + | OUI | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 10: Format 0x2 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + depicted in figure 11 [FC-FS]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 0 1 0| VSID | + +---------------+-----------------------+-------+-------+-------+ + | VSID | Vendor Specific | + +---------------+-----------------------+-------+---------------+ + + Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier + + The IPv6 Interface Identifier is obtained from this EUI-64 address by + complementing the U/L bit in the OUI field. So the OUI in the IPv6 + Interface ID is exactly as in the FC Name_Identifier. The resulting + IPv6 Interface Identifier has local scope [AARCH] and the format + depicted in figure 12. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI |0 0 1 0| VSID | + +---------------+-----------------------+-------+-------+-------+ + | VSID | Vendor Specific | + +---------------+-----------------------+-------+---------------+ + + Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier + + As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF + generates the IPv6 Interface Identifier 3463:462A:BCDE:F789. + + + +DeSanti Standards Track [Page 12] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +6.4. Generating an Interface ID from a Format 5 N_Port_Name + + The Name_Identifier format 0x5 is depicted in figure 13. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 0 1| OUI | VSID | + +-------+-------+---------------+---------------+-------+-------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 13: Format 0x5 Name_Identifier + + The EUI-64 address derived from this Name_Identifier has the format + depicted in figure 14 [FC-FS]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI with complemented U/L bit |0 1 0 1| VSID | + +---------------+---------------+---------------+-------+-------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier + + The IPv6 Interface Identifier is obtained from this EUI-64 address + complementing the U/L bit in the OUI field. So the OUI in the IPv6 + Interface ID is exactly as in the FC Name_Identifier. The resulting + IPv6 Interface Identifier has local scope [AARCH] and the format + depicted in figure 15. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI |0 1 0 1| VSID | + +---------------+---------------+---------------+-------+-------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier + + As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 + generates the IPv6 Interface Identifier 3463:465A:BCDE:F789. + + + + + + +DeSanti Standards Track [Page 13] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +6.5. Generating an Interface ID from an EUI-64 mapped N_Port_Name + + The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) + are derived from an EUI-64 address by compressing the OUI field of + such addresses. The compression is performed by removing from the + OUI the Universal/Local and Individual/Group bits, and by putting + bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and + bits 8 to 23 of the OUI in the second and third octet of the + Name_Identifier, as shown in figure 16. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 1| OUI[0..5] | OUI[8..23] | VSID | + +---+-----------+---------------+---------------+---------------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 16: EUI-64 Mapped Name_Identifiers Format + + The EUI-64 address used to generate the Name_Identifier shown in + figure 16 has the format depicted in figure 17. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI[0..5] |0 0| OUI[8..23] | VSID | + +-----------+---+---------------+---------------+---------------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier + + The IPv6 Interface Identifier is obtained from this EUI-64 address by + complementing the U/L bit in the OUI field. The resulting IPv6 + Interface Identifier has global scope [AARCH] and the format depicted + in figure 18. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OUI[0..5] |1 0| OUI[8..23] | VSID | + +-----------+---+---------------+---------------+---------------+ + | VSID | + +---------------+---------------+---------------+---------------+ + + Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier + + + + +DeSanti Standards Track [Page 14] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A + generates the IPv6 Interface Identifier 3663:46AB:0125:789A. + +7. Link-Local Addresses + + The IPv6 link-local address [AARCH] for an Nx_Port is formed by + appending the Interface Identifier, as defined in section 6, to the + prefix FE80::/64. The resulting address is depicted in figure 19. + + 10 bits 54 bits 64 bits + +----------+-----------------------+----------------------------+ + |1111111010| (zeros) | Interface Identifier | + +----------+-----------------------+----------------------------+ + + Fig. 19: IPv6 link-local Address Format + +8. Address Mapping for Unicast + + An Nx_Port has two kinds of Fibre Channel 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. Both FC addresses + are required to resolve an IPv6 unicast address. The fact that the + N_Port_ID is volatile implies that an Nx_Port MUST validate the + mapping between its N_Port_Name and N_Port_ID when certain Fibre + Channel events occur (see Appendix B). + + 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 format depicted + in figure 20 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 | Reserved | + +---------------+---------------+---------------+---------------+ + | | + +- N_Port_Name -+ + | | + +---------------+---------------+---------------+---------------+ + | Reserved | N_Port_ID | + +---------------+---------------+---------------+---------------+ + + Fig. 20: Source/Target Link-layer Address option for Fibre Channel + + + +DeSanti Standards Track [Page 15] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + Type: 1 for Source Link-layer address. + 2 for Target Link-layer address. + + Length: 2 (in units of 8 octets). + + N_Port_Name: This field contains the Nx_Port's N_Port_Name. + N_Port_ID: This field contains the Nx_Port's N_Port_ID. + + Reserved fields MUST be zero when transmitting, and MUST be ignored + when receiving. + +9. Address Mapping for Multicast + + By default, all best-effort IPv6 multicast packets MUST be mapped to + FC Sequences addressed to the broadcast N_Port_ID 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 N_Port_ID 0xFF-FF-FF. In this case, the Destination + N_Port_Name field of the FC Network_Header MUST be set to the value + 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies 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. The receive data field size + of this implicit Port Login MUST be the same across all the Nx_Ports + connected to the same Fabric, otherwise FC broadcast transmission + does not work. In order to reduce the need for FC Sequence + segmentation, the receive data field size of this implicit Port Login + SHOULD be 1024 octets. This receive data field size requirement + applies to broadcast Device_Data FC frames, not to ELSs. + + Receiving an FC Sequence carrying an IPv6 multicast packet MAY + trigger some additional processing by the Nx_Port if that IPv6 packet + requires a unicast reply. In this case, if a valid Port Login to the + Nx_Port that 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. In the case of Neighbor Discovery messages + [DISC], the N_Port_ID to which the Port Login is directed is taken + from the N_Port_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 unicast reply, and + + + +DeSanti Standards Track [Page 16] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + no valid Port Login exists with the Nx_Port sender of the multicast + packet, then a Port Login MUST be performed in order to send the + unicast reply message. If a received broadcast FC Sequence carries + an IPv6 multicast solicitation message [DISC] requiring a multicast + reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF. + + Best-effort IPv6 multicast for other multicast group addresses MAY + use Fibre Channel Multicast Groups [FC-FS], if supported by the + particular FC topology and implementation. + +10. Sequence Management + + FC Sequences are REQUIRED to be non-streamed. In order to avoid + missing FC frame aliasing by Sequence_ID reuse, 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. + +11. Exchange Management + + To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange + for sending data to each Nx_Port in the network and a dedicated + Exchange for receiving data from each Nx_Port. + + An Exchange Responder is not required to assign RX_IDs. If an RX_ID + of 0xFFFF is assigned, the Exchange Responder is identifying + Exchanges based on S_ID / D_ID / OX_ID only. + + When an Exchange is created between two Nx_Ports for unicast IPv6 + packets, it remains active while the Nx_Ports are logged in with each + other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short + lived Exchange. + + For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because + they are used in a unidirectional mode. The Sequence Initiative bit + in the F_CTL field of the FC Header [FC-FS] MUST be set to 0. + + The mechanism for aging or expiring exchanges based on activity, + timeout, or other methods 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 (Abort Sequence) + protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, + since this may terminate active Exchanges on other FC-4s [FC-FS]. + + + + +DeSanti Standards Track [Page 17] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +12. Security Considerations + + IPv6 does not introduce any additional security concerns beyond those + that already exist within the Fibre Channel protocols. Zoning + techniques based on FC Name Server masking (soft zoning) do not work + with IPv6, because IPv6 over Fibre Channel does not use the FC Name + Server. The FC ESP_Header [FC-FS] may be used to secure the FC + frames composing FC Sequences carrying IPv6 packets. All the + techniques defined to secure IPv6 traffic at the IPv6 layer may be + used in a Fibre Channel environment. + +13. Acknowledgments + + The author would like to acknowledge the authors of [IPFC], [ETHER], + and [IPv6-1394], since some part of this document has been derived + from them, as well as the ANSI INCITS T11.3 Task Group members who + reviewed this document. + +14. References + +14.1. Normative References + + [FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and + Signaling (FC-FS)". + + [FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 + (FC-AL-2)". + + [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [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. + + [PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and + Metropolitan Area Networks: Overview and Architecture". + + + + + +DeSanti Standards Track [Page 18] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +14.2. Informative References + + [IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP + over Fibre Channel", RFC 2625, June 1999. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +DeSanti Standards Track [Page 19] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +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 having D_ID 0xFFFFFF. + +A.2. Private Loop Topology + + An NL_Port attached to a private loop MUST transmit a Class 3 + broadcast FC Sequence by using the OPN(fr) primitive signal + [FC-AL-2]. + + a) The source NL_Port first sends an Open Broadcast Replicate + (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop + (except itself) to replicate the frames that they receive while + examining the FC Header's D_ID field. + b) The source NL_Port then removes the OPN(fr) signal when it returns + to it. + c) The source NL_Port then sends the Class 3 broadcast FC Sequence + having D_ID 0xFFFFFF. + +A.3. Public Loop Topology + + An NL_Port attached to a public loop MUST NOT use the OPN(fr) + primitive signal. Rather, it MUST send the Class 3 broadcast FC + Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 + [FC-AL-2]. + + The Fabric propagates the broadcast to all other FC_Ports [FC-FS], + including the FL_Port which the broadcast arrives on. This includes + all F_Ports, and other FL_Ports. + + Each FL_Port propagates the broadcast by using the primitive signal + OPN(fr), in order to prepare the loop to receive the broadcast + sequence. + +A.4. Fabric Topology + + An N_Port connected to an F_Port MUST transmit the Class 3 broadcast + FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric + propagates the broadcast to all other FC_Ports [FC-FS]. + + + + + + + + +DeSanti Standards Track [Page 20] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +B. Validation of the mapping + +B.1. Overview + + At all times, the mapping must be valid + before use. + + After an FC link interruption occurs, the N_Port_ID of an 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. + +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 again perform a Port Login [FC-FS]. + +B.3. FC Layer Address Validation in a Private Loop Topology + + After a LIP [FC-AL-2], an NL_Port must not transmit any 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]. + + For 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 Exchange with that NL_Port may continue. + + If any of the three FC addresses has changed, then the remote NL_Port + must be logged out. + + If an NL_Port's N_Port_ID changes after a LIP, then all active logged + in NL_Ports must be logged out. + + + + + + + + + +DeSanti Standards Track [Page 21] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +B.4. FC Layer Address Validation in a Public Loop Topology + + A FAN ELS may be sent by the Fabric to all known previously logged in + NL_Ports following an initialization event. Therefore, after a LIP + [FC-AL-2], NL_Ports may wait for this notification to arrive, or they + may perform an FLOGI. + + If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI + response exactly match the values before the LIP and if the AL_PA + [FC-AL-2] 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 must + be performed with the Fabric and all logged in Nx_Ports must be + logged out. + + A public loop NL_Port must perform the private loop validation as + specified in section B.3 to any NL_Port on the local loop that has 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 logged out [FC-FS]. + +C. Fibre Channel Bit and Byte Numbering Guidance + + Both Fibre Channel and IETF standards use the same byte transmission + order. However, the bit numbering is different. + + Fibre Channel bit numbering can be observed if the data structure + heading shown in figure 21 is cut and pasted at the top of the + figures present in this document. + + 3 2 1 0 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fig. 21: Fibre Channel Bit Numbering + + + + + + + + + + +DeSanti Standards Track [Page 22] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +Author's Address + + Claudio DeSanti + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA + + Phone: +1 408 853-9172 + EMail: cds@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +DeSanti Standards Track [Page 23] + +RFC 3831 IPv6 over Fibre Channel July 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +DeSanti Standards Track [Page 24] + -- cgit v1.2.3