rfc2590.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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