rfc2590.txt

中、英文RFC文档大全打包下载完全版 .

        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: [phone]
   EMail: [e-mail]


   Andrew Malis
   Ascend Communications
   1 Robbins Rd
   Westford, MA 01886

   Phone: [phone]
   EMail: [e-mail]


   Martin Mueller
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742

   PHone: [phone]
   EMail:  [e-mail]
























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]