doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

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 <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:
+
+   -  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 <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]
+