GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3831

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 <N_Port_Name, N_Port_ID> 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:
  1. a point-to-point link between two Ports;
  2. a set of Ports interconnected by a switching network called a

Fabric, as defined in [FC-FS];

  1. 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:
  1. an Nx_Port's Name_Identifier is called N_Port_Name;
  2. an Fx_Port's Name_Identifier is called F_Port_Name;
  3. a Node's Name_Identifier is called Node_Name;
  4. 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:
  1. ESP_Header;
  2. Network_Header;
  3. Association_Header;
  4. 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:
  1. Class 1: Dedicated physical connection with delivery confirmation;
  2. Class 2: Frame multiplexed service with delivery confirmation;
  3. Class 3: Datagram service;
  4. Class 4: Fractional bandwidth;
  5. 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:
  1. 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:
  1. R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information

Category [FC-FS])

  1. TYPE: 0x05 (IP over Fibre Channel)
  2. CS_CTL/Prio: 0x0
  3. 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:
  1. DSAP: 0xAA
  2. SSAP: 0xAA
  3. CTRL: 0x03
  4. OUI: 0x00-00-00
  5. 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:
  1. a non-volatile 64-bit address, called N_Port_Name;
  2. 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 <N_Port_Name, N_Port_ID> mapping

B.1. Overview

 At all times, the <N_Port_Name, N_Port_ID> 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3831.txt · Last modified: 2004/07/19 18:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki