doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc2590.txt b/doc/rfc/rfc2590.txt
new file mode 100644
index 0000000..53f7bc3
--- /dev/null
+++ b/doc/rfc/rfc2590.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                          A. Conta
+Request for Comments: 2590                                       Lucent
+Category: Standards Track                                      A. Malis
+                                                                 Ascend
+                                                             M. Mueller
+                                                                 Lucent
+                                                               May 1999
+
+
+         Transmission of IPv6 Packets over Frame Relay Networks
+                             Specification
+
+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 (1999).  All Rights Reserved.
+
+Abstract
+
+   This memo describes mechanisms for the transmission of IPv6 packets
+   over Frame Relay networks.
+
+Table of Contents
+
+   1. Introduction.................................................2
+   2. Maximum Transmission Unit....................................3
+   3. Frame Format.................................................4
+   4. Stateless Autoconfiguration..................................5
+      4.1 Generating the MID field.................................7
+   5. Link-Local Address...........................................9
+   6. Address Mapping -- Unicast, Multicast........................9
+   7. Sending Neighbor Discovery Messages.........................14
+   8. Receiving Neighbor Discovery Messages.......................15
+   9. Security Considerations.....................................15
+   10. Acknowledgments............................................16
+   11. References.................................................16
+   12. Authors' Addresses.........................................18
+   13. Full Copyright Statement...................................19
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 1]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+1. Introduction
+
+   This document specifies the frame format for transmission of IPv6
+   packets over Frame Relay networks, the method of forming IPv6 link-
+   local addresses on Frame Relay links, and the mapping of the IPv6
+   addresses to Frame Relay addresses.  It also specifies the content of
+   the Source/Target link-layer address option used in Neighbor
+   Discovery [ND] and Inverse Neighbor Discovery [IND] messages when
+   those messages are transmitted over a Frame Relay link.  It is part
+   of a set of specifications that define such IPv6 mechanisms for Non
+   Broadcast Multi Access (NBMA) media [IPv6-NBMA], [IPv6-ATM], and a
+   larger set that defines such mechanisms for specific link layers
+   [IPv6-ETH], [IPv6-FDDI], [IPv6-PPP], [IPv6-ATM], etc...
+
+   The information in this document applies to Frame Relay devices which
+   serve as end stations (DTEs) on a public or private Frame Relay
+   network (for example, provided by a common carrier or PTT.) Frame
+   Relay end stations can be IPv6 hosts or routers. In this document
+   they are referred to as nodes.
+
+   In a Frame Relay network, a number of virtual circuits form the
+   connections between the attached stations (nodes). The resulting set
+   of interconnected devices forms a private Frame Relay group which may
+   be either fully interconnected with a complete "mesh" of virtual
+   circuits, or only partially interconnected.  In either case, each
+   virtual circuit is uniquely identified at each Frame Relay interface
+   (card) by a Data Link Connection Identifier (DLCI).  In most
+   circumstances, DLCIs have strictly local significance at each Frame
+   Relay interface.
+
+   A Frame Relay virtual circuit acts like a virtual-link (also referred
+   to as logical-link), with its own link parameters, distinct from the
+   parameters of other virtual circuits established on the same wire or
+   fiber. Such parameters are the input/output maximum frame size,
+   incoming/outgoing requested/agreed throughput, incoming/outgoing
+   acceptable throughput, incoming/outgoing burst size,
+   incoming/outgoing frame rate.
+
+   By default a DLCI is 10 bits in length. Frame Relay specifications
+   define also 16, 17, or 23 bit DLCIs. The former is not used, while
+   the latter two are suggested for use with SVCs.
+
+   Frame Relay virtual circuits can be created administratively as
+   Permanent Virtual Circuits -- PVCs -- or dynamically as Switched
+   Virtual Circuits -- SVCs.  The mechanisms defined in this document
+   are intended to apply to both permanent and switched Frame Relay
+   virtual circuits, whether they are point to point or point to multi-
+   point.
+
+
+
+Conta, et al.               Standards Track                     [Page 2]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
+   SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
+   in [RFC 2119].
+
+2. Maximum Transmission Unit
+
+   The IPv6 minimum MTU is defined in [IPv6].
+
+   In general, Frame Relay devices are configured to have a maximum
+   frame size of at least 1600 octets. Therefore, the default IPv6 MTU
+   size for a Frame Relay interface is considered to be 1592.
+
+   A smaller than default frame size can be configured but of course not
+   smaller than the minimum IPv6 MTU.
+
+   An adequate larger than default IPv6 MTU and Frame Relay frame size
+   can be configured to avoid fragmentation. The maximum frame size is
+   controlled by the CRC generation mechanisms employed at the HDLC
+   level. CRC16 will protect frames up to 4096 bytes in length, which
+   reduces the effective maximum frame size to approximately 4088 bytes.
+   A larger desired frame size (such as that used by FDDI or Token
+   Ring), would require the CRC32 mechanism, which is not yet widely
+   used and is not mandatory for frame relay systems conforming to Frame
+   Relay Forum and ITU-T standards.
+
+   In general, if upper layers provide adequate error
+   protection/detection mechanisms, implementations may allow
+   configuring a Frame Relay link with a larger than 4080 octets frame
+   size but with a lesser error protection/detection mechanism at link
+   layer. However, because IPv6 relies on the upper and lower layer
+   error detection, configuring the IPv6 MTU to a value larger than 4080
+   is strongly discouraged.
+
+   Although a Frame Relay circuit allows the definition of distinct
+   maximum frame sizes for input and output, for simplification
+   purposes, this specification assumes symmetry, i.e. the same MTU for
+   both input and output.
+
+   Furthermore, implementations may limit the setting of the Frame Relay
+   maximum frame size to the interface (link, or card) level, which then
+   is enforced on all of the PVCs or SVCs on that interface (on that
+   link, or card). For an SVC, the maximum frame size parameter
+   negotiated during circuit setup will not exceed the configured
+   maximum frame size.
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 3]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+3. IPv6 Frame Format
+
+   The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs)
+   follows [ENCAPS], which allows a VC to carry IPv6 packets along with
+   other protocol packets. The NLPID frame format is used, in which the
+   IPv6 NLPID has a value of 0x8E:
+
+            0                       1                       (Octets)
+           +-----------------------+-----------------------+
+(Octets)0  |                                               |
+           /                 Q.922 Address                 /
+           /            (length 'n' equals 2 or 4)         /
+           |                                               |
+           +-----------------------+-----------------------+
+        n  | Control (UI)  0x03    |      NLPID  0x8E      |  NLPID
+           +-----------------------+-----------------------+  indicating
+      n+2  |                       .                       |  IPv6
+           /                       .                       /
+           /                  IPv6 packet                  /
+           |                       .                       |
+           +-----------------------+-----------------------+
+           |                                               |
+           +                      FCS                      +
+           |                                               |
+           +-----------------------+-----------------------+
+
+      "n" is the length of the Q.922 address which can be 2 or 4 octets.
+
+      The Q.922 representation of a DLCI (in canonical order - the first
+      bit is stored in the least significant, i.e., the right-most bit
+      of a byte in memory) [CANON] is the following:
+
+            7     6     5     4     3     2     1     0      (bit order)
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+(octet) 0  |            DLCI(high order)       |  0  |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        1  |  DLCI(low order)      |  0  |  0  |  0  |  1  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+
+              10 bits DLCI
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 4]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+            7     6     5     4     3     2     1     0      (bit order)
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+(octet) 0  |            DLCI(high order)       |  0  |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        1  |  DLCI                 |  0  |  0  |  0  |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        2  |             DLCI(low order)             |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        3  |       unused (set to 0)           |  1  |  1  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+
+              17 bits DLCI
+
+            7     6     5     4     3     2     1     0      (bit order)
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+(octet) 0  |            DLCI(high order)       |  0  |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----
+        1  |  DLCI                 |  0  |  0  |  0  |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        2  |             DLCI                        |  0  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+        3  |       DLCI (low order)            |  0  |  1  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+
+              23 bits DLCI
+
+   The encapsulation of data or control messages exchanged by various
+   protocols that use SNAP encapsulation (with their own PIDs) is not
+   affected. The encoding of the IPv6 protocol identifier in such
+   messages MUST be done according to the specifications of those
+   protocols, and [ASSNUM].
+
+4. Stateless Autoconfiguration
+
+   An interface identifier [AARCH] for an IPv6 Frame Relay interface
+   must be unique on a Frame Relay link [AARCH], and must be unique on
+   each of the virtual links represented by the VCs terminated on the
+   interface.
+
+   The interface identifier for the Frame Relay interface is locally
+   generated by the IPv6 module.
+
+   Each virtual circuit in a Frame Relay network is uniquely identified
+   on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen
+   as an identification of the end point of a virtual circuit on a Frame
+   Relay interface. Since each Frame Relay VC is configured or
+   established separately, and acts like an independent virtual-link
+   from other VCs in the network, or on the interface, link, wire or
+
+
+
+Conta, et al.               Standards Track                     [Page 5]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   fiber, it seems beneficial to view each VC's termination point on the
+   Frame Relay interface as a "pseudo-interface" or "logical-interface"
+   overlaid on the Frame Relay interface. Furthermore, it seems
+   beneficial to be able to generate and associate an IPv6
+   autoconfigured address (including an IPv6 link local address) to each
+   "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a
+   Frame Relay interface.
+
+   In order to achieve the benefits described above, the mechanisms
+   specified in this document suggest constructing the Frame Relay
+   interface identifier from 3 distinct fields (Fig.1):
+
+   (a)  The "EUI bits" field. Bits 6 and 7 of the first octet,
+        representing the EUI-64 "universal/local" and respectively
+        "individual/group" bits converted to IPv6 use. The former is set
+        to zero to reflect that the 64 bit interface identifier value
+        has local significance [AARCH]. The latter is set to 0 to
+        reflect the unicast address [AARCH].
+
+   (b)  The "Mid" field. A 38 bit field which is generated with the
+        purpose of adding uniqueness to the interface identifier.
+
+   (c)  The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23
+        bit DLCI value which MUST be extended with 0's to 24 bits. A
+        DLCI based interface identifier -- which contains a valid DLCI
+        -- SHOULD be generated as a result of successfully establishing
+        a VC -- PVC or SVC.
+
+        If a DLCI is not known, the field MUST be set to the
+        "unspecified DLCI" value which consists of setting each of the
+        24 bits to 1.
+
+   Since DLCIs are local to a Frame Relay node, it is possible to have
+   Frame Relay distinct virtual circuits within a Frame Relay network
+   identified with the same DLCI values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 6]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+             7     6     5     4     3     2     1     0   (bit order)
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+(Octets) 0  |                                   |"EUI bits" |
+            +                                   +-----+-----+
+         1  |                                               |
+            +                                               +
+         2  |                   "Mid"                       |
+            +                                               +
+         3  |                                               |
+            +                                               +
+         4  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+         5  |                                               |
+            +                                               +
+         6  |                   "DLCI"                      |
+            +                                               +
+         7  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+
+            Fig.1 Frame Relay Pseudo-Interface Identifier
+
+   The Duplicate Address Detection specified in [AUTOCONF] is used
+   repeatedly during the interface identifier and local-link address
+   generation process, until the generated identifier and consequently
+   the link-local address on the link -- VC -- are unique.
+
+4.1  Generating the "Mid" field.
+
+   The "Mid" can be generated in multiple ways. This specification
+   suggests two mechanisms:
+
+ (b.1)  "Use of Local Administrative Numbers"
+
+        The "Mid" is filled with the result of merging:
+
+   (b.1.1)  A random number of 6 bits in length (Fig.2).
+
+
+   (b.1.2)  The Frame Relay Node Identifier -- 16 bits -- is a user
+            administered value used to locally identify a Frame Relay
+            node (Fig.2).
+
+   (b.1.3)  The Frame Relay Link Identifier -- 16 bits -- is a numerical
+            representation of the Frame Relay interface or link (Fig.2).
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 7]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+             7     6     5     4     3     2     1     0  (bit order)
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+(Octets) 0  |          Random Number            |    MBZ    |
+            +-----------------------------------+-----+-----+
+         1  |                                               |
+            +          Frame Relay Node Identifier          +
+         2  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+         3  |                                               |
+            +          Frame Relay Link Identifier          +
+         4  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+         5  |                                               |
+            +                                               +
+         6  |                    "DLCI"                     |
+            +                                               +
+         7  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+
+            Fig.2  Frame Relay Pseudo-Interface Identifier
+
+   or,
+
+ (b.2)  "Use of The Frame Relay address - E.164 [E164], X.121
+       [X25] numbers, or NSAP [NSAP] address"
+
+       If a Frame Relay interface has an E.164 or a X.121 number, or an
+       NSAP address, the "Mid" field MUST be filled in with a number
+       resulted from it as follows:  the number represented by the BCD
+       encoding of the E.164 or X.121 number, or the binary encoding of
+       the NSAP address is truncated to 38 bits (Fig.3). Since the Frame
+       Relay interface identifier has a "local" significance, the use of
+       such a value has no real practical purposes other than adding to
+       the uniqueness of the interface identifier on the link. Therefore
+       the truncation can be performed on the high order or low order
+       bits. If the high order bits truncation does not provide
+       uniqueness on the link -- perhaps the DLCI value is not unique --
+       this most likely means that the VC spans more for instance than a
+       national and/or international destination area for an E.164
+       number, and therefore the truncation of the low order bits should
+       be performed next, which most likely will provide the desired
+       uniqueness.
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 8]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+             7     6     5     4     3     2     1     0     (bit order)
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+(Octets) 0  |                                   |    MBZ    |
+            +                                   +-----+-----+
+         1  |                                               |
+            +          E.164, X.121 (BCD encoding)          +
+         2  |               or NSAP Address                 |
+            +                                               +
+         3  |            (truncated to 38 bits)             |
+            +                                               +
+         4  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+         5  |                                               |
+            +                                               +
+         6  |                    "DLCI"                     |
+            +                                               +
+         7  |                                               |
+            +-----+-----+-----+-----+-----+-----+-----+-----+
+
+            Fig.3   Frame Relay (Pseudo) Interface Identifier
+
+5. Link-Local Addresses
+
+   The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface
+   is formed by appending the interface identifier, formed as defined
+   above, to the prefix FE80::/64 [AARCH].
+
+       10 bits            54 bits                  64 bits
+     +----------+-----------------------+----------------------------+
+     |1111111010|         (zeros)       |Frame Relay Interface Ident.|
+     +----------+-----------------------+----------------------------+
+
+6. Address Mapping -- Unicast, Multicast
+
+   The procedure for mapping IPv6 addresses to link-layer addresses is
+   described in [IPv6-ND]. Additionally, extensions to Neighbor
+   Discovery (ND) that allow the mapping of link-layer addresses to IPv6
+   addresses are defined as Inverse Neighbor Discovery (IND) in [IND].
+   This document defines the formats of the link-layer address fields
+   used by ND and IND. This specification does not define an algorithmic
+   mapping of IPv6 multicast addresses to Frame Relay link-layer
+   addresses.
+
+   The Source/Target Link-layer Address option used in Neighbor
+   Discovery and Inverse Neighbor Discovery messages for a Frame Relay
+   link follows the general rules defined by [IPv6-ND]. IPv6 addresses
+   can map two type of identifiers equivalent to link-layer addresses:
+
+
+
+
+Conta, et al.               Standards Track                     [Page 9]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   DLCIs, and Frame Relay Addresses.  Therefore, for Frame Relay, this
+   document defines two distinct formats for the ND and IND messages
+   Link-Layer Address field:
+
+   (a)  DLCI Format -- used in ND and/or IND messages on VCs that were
+        established prior to the ND or IND message exchange --  mostly
+        PVCs. The use on SVCs makes sense with Inverse Neighbor
+        Discovery [IND] messages if IND is employed after the successful
+        establishing of an SVC to gather information about other IPv6
+        addresses assigned to the remote node and that SVC.
+
+   (b)  Frame Relay Address Format -- used mostly prior to establishing
+        a new SVC, to get the  Frame Relay remote node identifier
+        (link-layer address) mapping to a certain IPv6 address.
+
+        Note: An implementation may hold both types of link layer
+        identifiers in the Neighbor Discovery cache. Additionally, in
+        case of multiple VCs between two nodes, one node's Neighbor
+        Discovery cache may hold a mapping of one of the remote node's
+        IPv6 addresses to each and every DLCI identifying the VCs.
+
+        The mechanisms which in such an implementation would make the
+        distinction between the Neighbor Discovery Cache mapping of an
+        IPv6 address to a "Frame Relay Address Format" and a "DLCI
+        Format" link-layer address, or among several mappings to a "DLCI
+        Format" addresses are beyond the scope of this specification.
+
+        The use of the override "O" bit in the advertisement messages
+        that contain the above Link-Layer Address formats SHOULD be
+        consistent with the [ND] specifications. Additionally, there
+        should be consistency related to the type of Link-Layer Address
+        format: an implementation should override one address format in
+        its Neighbor Discovery cache with the same type of address
+        format.
+
+   The "DLCI Format" is defined as follows:
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          0  |                      Type                     |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          1  |                     Length                    |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 10]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   with a DLCI (Q.922 address) encoded as option value:
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          2  |                                   |  1  |  1  |
+             +              unused               +-----+-----+
+          3  |                                               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          4  |            DLCI(high order)       |  0  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          5  |  DLCI(low order)      |  0  |  0  |  0  |  1  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          6  |                                               |
+             +                   Padding                     +
+          7  |                   (zeros)                     |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+                 10 bits DLCI
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          2  |                                   |  1  |  1  |
+             +              unused               +-----+-----+
+          3  |                                               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          4  |            DLCI(high order)       |  0  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          5  |  DLCI                 |  0  |  0  |  0  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          6  |             DLCI(low order)             |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          7  |       unused (set to 0)           |  1  |  1  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+                 17 bits DLCI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 11]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          2  |                                   |  1  |  1  |
+             +              unused               +-----+-----+
+          3  |                                               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          4  |            DLCI(high order)       |  0  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----
+          5  |  DLCI                 |  0  |  0  |  0  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          6  |             DLCI                        |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          7  |       DLCI (low order)            |  0  |  1  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+                 23 bits DLCI
+
+
+     Option fields:
+
+        Type        1 for Source Link-layer address.
+                    2 for Target Link-layer address.
+
+        Length      The Length of the Option (including the Type
+                    and Length fields) in units of 8 octets.
+                    It has the value 1.
+
+        Link-Layer Address        The DLCI encoded as a Q.922 address.
+
+      Description
+
+        The "DLCI Format" option value field has two components:
+
+
+        (a)  Address Type -- encoded in the first two bits of the first
+             two octets. Both bits are set to 1 to indicate the DLCI
+             format. The rest of the bits in the two first octets are
+             not used -- they MUST be set to zero on transmit and MUST
+             be ignored by the receiver.
+
+        (b)  DLCI -- encoded as a Q.922 address padded with zeros to the
+             last octet of the 6 octets available for the entire Link-
+             Layer Address field of this format.
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 12]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   The "Frame Relay Address Format" is defined as follows:
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          0  |                      Type                     |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          1  |                     Length                    |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+   with an E.164, X.121, number or NSAP  address encoded as option
+   value:
+
+              7     6     5     4     3     2     1     0    (bit order)
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          2  |             size                  |  1  |  0  |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          3  |            E.164 or X.121, or NSAP            |
+             +---          Address Family Number          ---+
+          4  |               (Assigned Number)               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+          5  |                                               |
+             /       E.164, or X.121 number (BCD encoded)    /
+             /               or  NSAP address                /
+      4+size |                                               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+      5+size |                                               |
+             /                    Padding                    /
+             /                    (zeros)                    /
+   8*Length-1|                                               |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+      Option fields:
+
+        Type        1 for Source Link-layer address.
+                    2 for Target Link-layer address.
+
+        Length      The length of the Option (including the
+                    Type and Length fields) in units of 8 octet.
+                    It may have the value:
+
+                     2 -- for E.164, or X.121 numbers or NSAP
+                          addresses not longer than 11 octets
+                          [E164], [X25], [NSAP].
+
+                     3 -- for NSAP addresses longer than 11 but
+                          not longer than 19 octets.
+
+
+
+
+Conta, et al.               Standards Track                    [Page 13]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+                     4 -- for NSAP addresses longer than 19 octets
+                          (not longer than the maximum NSAP address
+                          length) [NSAP].
+
+        Link-Layer Address       The E.164, X.121, number encoded in
+                                 Binary Coded Decimal (BCD), or the NSAP
+                                 address.
+
+   Description
+
+     The "Frame Relay Address" option value has three components:
+
+     (a)  Address Type -- encoded in the first two bits of the first
+          octet.  The first bit is set to 0, the second bit is set to 1.
+
+     (b)  Size -- encoded in the last (high order) 6 bits of the first
+          octet. The maximum value of the field is the maximum size of
+          the E.164, X.121, or NSAP addresses.
+
+     (c)  Address Family Number -- the number assigned for the E.164,
+          X.121, or NSAP address family [ASSNUM].
+
+     (d)  E.164, X.121, number -- encoded in BCD (two digits per octet).
+          If the E.164, or X.121 has an even number of digits the
+          encoding will fill all encoding octets -- half the number of
+          digits. If the E.164, or X.121 number has an odd number of
+          digits, the lowest order digit fills only half of an octet --
+          it is placed in the first 4 bits of the last octet of the
+          E.164, or X.121 BCD encoding. The rest of the field up to the
+          last octet of the 11 octets available is padded with zeros.
+
+          NSAP address -- the NSAP address. It is padded with zeros if
+          the NSAP address does not fit in a number of octets that makes
+          the length of the option an even number of 8 octets.
+
+7. Sending Neighbor Discovery Messages
+
+   Frame Relay networks do not provide link-layer native multicasting
+   mechanisms. For the correct functioning of the Neighbor Discovery
+   mechanisms, link-layer multicasting must be emulated.
+
+   To emulate multicasting for Neighbor Discovery (ND) the node MUST
+   send frames carrying ND multicast packets to all VCs on a Frame Relay
+   interface. This applies to ND messages addressed to both all-node and
+   solicited-node multicast addresses. This method works well with PVCs.
+   A mesh of PVCs MAY be configured and dedicated to multicast traffic
+   only.  An alternative to a mesh of PVCs is a set of point-to-
+   multipoint PVCs.
+
+
+
+Conta, et al.               Standards Track                    [Page 14]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+8. Receiving Neighbor Discovery Messages
+
+   If a Neighbor Discovery Solicitation message received by a node
+   contains the Source  link-layer  address option with a DLCI, the
+   message MUST undergo Frame Relay specific preprocessing required for
+   the correct interpretation of the field during the ND protocol engine
+   processing. This processing is done before the Neighbor Discovery
+   message is processed by the Neighbor Discovery (ND) protocol engine.
+
+   The motivation for this processing is the local significance of the
+   DLCI fields in the Neighbor Discovery message: the DLCI significance
+   at the sender node is different than the DLCI significance at the
+   receiver node. In other words, the DLCI that identifies the Frame
+   Relay virtual circuit at the sender may be different than the DLCI
+   that identifies the virtual circuit at the receiver node.
+   Furthermore, the sender node may not be aware of the DLCI value at
+   the receiver. Therefore, the Frame Relay specific preprocessing
+   consists in modifying the Neighbor Discovery Solicitation message
+   received, by storing into the Source link-layer address option the
+   DLCI value of the virtual circuit on which the frame was received, as
+   known to the receiver node. The DLCI value being stored must be
+   encoded in the appropriate format (see previous sections). The
+   passing of the DLCI value from the Frame Relay module to the Neighbor
+   Discovery preprocessing module is an implementation choice.
+
+9. Security Considerations
+
+   The mechanisms defined in this document for generating an IPv6 Frame
+   Relay interface identifier are intended to provide uniqueness at link
+   level -- virtual circuit.  The protection against duplication is
+   achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address
+   Detection mechanisms. Security protection against forgery or accident
+   at the level of the mechanisms described here is provided by the IPv6
+   security mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to
+   Neighbor Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND]
+   messages.
+
+   To avoid an IPsec Authentication verification failure, the Frame
+   Relay specific preprocessing of a Neighbor Discovery Solicitation
+   message that contains a DLCI format Source link-layer address option,
+   MUST be done by the receiver node after it completed IP Security
+   processing.
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 15]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+10. Acknowledgments
+
+   Thanks to D. Harrington, and M. Merhar for reviewing  this document
+   and providing useful suggestions. Also thanks to G. Armitage for his
+   reviewing and suggestions. Many thanks also to Thomas Narten for
+   suggestions on improving the document.
+
+11. References
+
+   [AARCH]      Hinden, R. and S. Deering, "IPv6 Addressing
+                Architecture", RFC 2373, July 1998.
+
+   [ASSNUM]     Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
+                RFC 1700, October 1994.  See also:
+                http://www.iana.org/numbers.html
+
+   [AUTOCONF]   Thomson, S. and T. Narten, "IPv6 Stateless
+                Autoconfiguration", RFC 2462, December 1998.
+
+   [CANON]      Narten, T. and C. Burton, "A Caution on the Canonical
+                Ordering of Link-Layer Addresses", RFC 2469, December
+                1998.
+
+   [ENCAPS]     Brown, C. and A. Malis, "Multiprotocol Interconnect over
+                Frame Relay", STD 55, RFC 2427, November 1998.
+
+   [IND]        Conta, A., "Extensions to IPv6 Neighbor Discovery for
+                Inverse Discovery", Work in Progress, December 1998.
+
+   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol Version 6
+                Specification", RFC 2460, December 1998.
+
+   [IPv6-ATM]   Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
+                Networks", RFC 2492, January 1999.
+
+   [IPv6-ETH]   Crawford, M., "Transmission of IPv6 packets over
+                Ethernet Networks", RFC 2464, December 1998.
+
+   [IPv6-FDDI]  Crawford, M., "Transmission of IPv6 packets over FDDI
+                Networks", RFC 2467, December 1998.
+
+   [IPv6-NBMA]  Armitage, G., Schulter, P., Jork, M. and G. Harter,
+                "IPv6 over Non-Broadcast Multiple Access (NBMA)
+                networks", RFC 2491, January 1999.
+
+   [IPv6-ND]    Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+                Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                1998.
+
+
+
+Conta, et al.               Standards Track                    [Page 16]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+   [IPv6-PPP]   Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
+                2472, December 1998.
+
+   [IPv6-TR]    Narten, T.,  Crawford, M. and M. Thomas, "Transmission
+                of IPv6 packets over Token Ring Networks", RFC 2470,
+                December 1998.
+
+   [IPSEC]      Atkinson, R. and S. Kent, "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
+                RFC 2402, December 1998.
+
+   [IPSEC-ESP]  Atkinson, R. and S. Kent, "IP Encapsulating Security
+                Protocol (ESP)", RFC 2406, November 1998.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [E164]       International Telecommunication Union - "Telephone
+                Network and ISDN Operation, Numbering, Routing, amd
+                Mobile Service", ITU-T Recommendation E.164, 1991.
+
+   [NSAP]       ISO/IEC, "Information Processing Systems -- Data
+                Communications -- Network Service Definition Addendum 2:
+                Network Layer Addressing". International Standard
+                8348/Addendum 2, ISO/IEC JTC 1, Switzerland 1988.
+
+   [X25]        "Information Technology -- Data Communications -- X.25
+                Packet Layer Protocol for Data Terminal Equipment",
+                International Standard 8208, March 1988.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 17]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+12. Authors' Addresses
+
+   Alex Conta
+   Lucent Technologies Inc.
+   300 Baker Ave, Suite 100
+   Concord, MA 01742
+
+   Phone: +1-978-287-2842
+   EMail: aconta@lucent.com
+
+
+   Andrew Malis
+   Ascend Communications
+   1 Robbins Rd
+   Westford, MA 01886
+
+   Phone: +1-978-952-7414
+   EMail: malis@ascend.com
+
+
+   Martin Mueller
+   Lucent Technologies Inc.
+   300 Baker Ave, Suite 100
+   Concord, MA 01742
+
+   PHone: +1-978-287-2833
+   EMail:  memueller@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 18]
+
+RFC 2590             IPv6 over Frame Relay Networks             May 1999
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 19]
+