rfc2492.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 2492                 IPv6 over ATM Networks             January 1999


5.1 Interface Tokens Based on ESI values

   When the underlying ATM interface is identified by an ATM End System
   Address (AESA, formerly known as an NSAPA), the interface token MAY
   be formed from the ESI and SEL values in the AESA as follows:

          [0x00][ESI][SEL]

   [0x00] is a one octet field which is always set to 0.
          Note that the bit corresponding to the EUI-64 Global/Local bit
          [5] is always reset indicating that this address is not a
          globally unique IPv6 interface token.

   [ESI] is a six octet field.
          This field always contains the six octet ESI value for the
          AESA used to address the specific instance of the IPv6/ATM
          interface.

   [SEL] is a one octet field.
          This field always contains the SEL value from the AESA used to
          address the specific instance of the IPv6/ATM interface.

5.2 Interface Tokens Based on 48 Bit MAC Values

   Where the underlying ATM NIC driver has access to a set of one or
   more 48 bit MAC values unique to the ATM NIC (e.g. MAC addresses
   configured into the NIC's ROM), the IPv6/ATM interface MAY use one of
   these values to create a unique interface token as described in [10].

5.3 Interface Tokens Based on EUI-64 Values

   Where the underlying ATM NIC driver has access to a set of one or
   more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
   addresses configured into the NIC's ROM), the IPv6/ATM interface
   SHOULD use one of these values to create a unique interface token.
   after inverting the Global/Local identifier bit [10].  (Any
   relationship between these values and the ESI(s) registered with the
   local ATM switch by the ATM driver are outside the scope of this
   document.)

   When EUI-64 values are used for IPv6 interface tokens the only
   modification allowed to the octet string read from the NIC is
   inversion of the Global/Local identifier bit.








G. Armitage, et. al.        Standards Track                     [Page 7]

RFC 2492                 IPv6 over ATM Networks             January 1999


5.4 Interface Tokens Based on Native E.164 Addresses

   When an interface uses Native E.164 addresses then the E.164 values
   MAY be used to generate an interface token as follows:

          [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

   [D14] A single octet containing the semi-octet representing the most
   significant E.164 digit shifted left four bits to the most
   significant four bits of the octet.  The lower four bits MUST be set
   to 0.  Note that the EUI-64 Global/Local indicator is set to 0
   indicating that this is not a globally unique IPv6 interface token.

   [D13D12] A single octet containing the semi-octet representing the
   second most significant E.164 digit [D13] shifted left four places to
   the most significant bits of the octet, and the third most
   significant semi-octet in the four least significant bits of the
   octet.

   [D11D10] - [D1D0] Octets each containing two E.164 digits, one in the
   most significant four bits, and one in the least significant four
   bits as indicated.

5.5 Nodes Without Unique Identifiers

   If no MAC, EUI-64, AESA, or E.164 value is available for generating
   an interface token, then the interface token SHALL be generated as
   described in Appendix A of [10].

5.6 Multiple Logical Links on a Single Interface

   A logical ATM interface might be associated with a different SEL
   field of a common AESA prefix, or a set of entirely separate ESIs
   might have been registered with the local ATM switch to create a
   range of unique AESAs.

   The minimum information required to uniquely identify each logical
   ATM interface is (within the context of the local switch port) their
   ESI+SEL combination.

   For the vhost case described in section 5.1.2 of [1], vhost SHALL
   select a different interface token from the range of 64 bit values
   available to the ATM NIC (as described in 4.1). Each vhost SHALL
   implement IPv6/ATM interfaces in such a way that no two or more
   vhosts end up advertising the same interface token onto the same LL.
   (Conformance with this requirement may be achieved by choosing
   different SEL values, ESI values, or both.)




G. Armitage, et. al.        Standards Track                     [Page 8]

RFC 2492                 IPv6 over ATM Networks             January 1999


6. Conclusion and Open Issues.

   This document is an ATM-specific companion document to the ION
   working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
   networks" specification [1]. It specifies codepoints for the
   administratively configured PVC, and dynamically established SVC,
   modes of operation.

   There are no major open issues. Comments to the ION mailing list are
   solicited ([e-mail]).

7. Security Considerations

   While this proposal does not introduce any new security mechanisms
   all current IPv6 security mechanisms will work without modification
   for ATM.  This includes both authentication and encryption for both
   Neighbor Discovery protocols as well as the exchange of IPv6 data
   packets.

Acknowledgments

   The original IPv6/ATM work by G. Armitage occurred while employed at
   Bellcore. Elements of section 4 were borrowed from Matt Crawford's
   memo on IPv6 over Ethernet.

   The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho,
   Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi
   Hagiwara for their contributions based on actual PVC implementations.























G. Armitage, et. al.        Standards Track                     [Page 9]

RFC 2492                 IPv6 over ATM Networks             January 1999


Authors' Addresses

   Grenville Armitage
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   USA

   EMail: [e-mail]


   Peter Schulter
   BrightTiger Technologies
   125 Nagog Park
   Acton, MA 01720

   EMail: [e-mail]


   Markus Jork
   European Applied Research Center
   Digital Equipment GmbH
   CEC Karlsruhe
   Vincenz-Priessnitz-Str. 1
   D-76131 Karlsruhe
   Germany

   EMail: [e-mail]























G. Armitage, et. al.        Standards Track                    [Page 10]

RFC 2492                 IPv6 over ATM Networks             January 1999


References

   [1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over
       Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January
       1999.

   [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
       Layer 5", RFC 1483, July 1993.

   [3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
       Networks", RFC 2022, November 1996.

   [4] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

   [5] "64-Bit Global Identifier Format Tutorial",
       http://standards.ieee.org/db/oui/tutorials/EUI64.html.

   [6] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A.
       Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
       February 1995.

   [7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626,
       May 1994.

   [8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
       version 6", RFC 1981, August 1996.

   [9] ATM Forum, "ATM User Network Interface (UNI) Specification
       Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
       Cliffs, NJ, June 1995.

   [10] Hinden, B. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.














G. Armitage, et. al.        Standards Track                    [Page 11]

RFC 2492                 IPv6 over ATM Networks             January 1999


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.
























G. Armitage, et. al.        Standards Track                    [Page 12]