rfc2225.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,543 行 · 第 1/5 页

   Traditionally, address resolution requests are broadcast to all
   directly connected IP members within a LIS.  It is conceivable in the
   future that larger scaled ATM networks may handle ATMARP requests to
   destinations outside the originating LIS, perhaps even globally;
   issues raised by ATMARPing outside the LIS or by a global ATMARP
   mechanism are beyond the scope of this memo.

9.  IP BROADCAST ADDRESS

   ATM does not support broadcast addressing, therefore there are no
   mappings available from IP broadcast addresses to ATM broadcast
   services.  Note: this lack of mapping does not restrict members from
   transmitting or receiving IP datagrams specifying any of the four
   standard IP broadcast address forms as described in [8].  Members,
   upon receiving an IP broadcast or IP subnet broadcast for their LIS,
   MUST process the packet as if addressed to that station.

   This memo recognizes the future development of standards and
   implementations that will extend the operations as defined in this
   memo to provide an IP broadcast capability for use by the classical
   client.

10.  IP MULTICAST ADDRESS

   ATM does not directly support IP multicast address services,
   therefore there are no mappings available from IP multicast addresses
   to ATM multicast services.  Current IP multicast implementations
   (i.e., MBONE and IP tunneling, see [10]) will continue to operate
   over ATM based logical IP subnets if operated in the WAN
   configuration.

   This memo recognizes the future development of ATM multicast service
   addressing by the ATM Forum.  When available and widely implemented,
   the roll-over from the current IP multicast architecture to this new
   ATM architecture will be straightforward.

   This memo recognizes the future development of standards and
   implementations that will extend the operations as defined in this
   memo to provide an IP multicast capability for use by the classical
   client.

11.  SECURITY CONSIDERATIONS

   Not all of the security issues relating to IP over ATM are clearly
   understood at this time, due to the fluid state of ATM
   specifications, newness of the technology, and other factors.





Laubach & Halpern           Standards Track                    [Page 23]

RFC 2225                  IP and ARP over ATM                 April 1998


   It is believed that ATM and IP facilities for authenticated call
   management, authenticated end-to-end communications, and data
   encryption will be needed in globally connected ATM networks.  Such
   future security facilities and their use by IP networks are beyond
   the scope of this memo.

   There are known security issues relating to host impersonation via
   the address resolution protocols used in the Internet [13].  No
   special security mechanisms have been added to the address resolution
   mechanism defined here for use with networks using IP over ATM.

12.  MIB SPECIFICATION

   Clients built to this specification MUST implement and provide a
   Management Information Base (MIB) as defined in "Definitions of
   Managed Objects for Classical IP and ARP Over ATM Using SMIv2" [18].

13.  OPEN ISSUES

   o   Automatic configuration of client ATM addresses via DHCP [15] or
       via ATM UNI 3.1 Interim Local Management Interface (ILMI)
       services would be a useful extended service addition to this
       document and should be addressed in a separate memo.

   o   ATMARP packets are not authenticated.  This is a potentially
       serious flaw in the overall system by allowing a mechanism by
       which corrupt information may be introduced into the server
       system.

14. REFERENCES

   [1] Piscitello, D., and J. Lawrence, "The Transmission of IP
       Datagrams over the SMDS Service", STD 52, RFC 1209, March 1991.

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

   [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet
       Address for Transmission on Ethernet Hardware", STD 37, RFC
       826, November 1982.

   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       July 1992.

   [5] Postel, J., and J. Reynolds, "A Standard for the Transmission
       of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042,
       February 1988.



Laubach & Halpern           Standards Track                    [Page 24]

RFC 2225                  IP and ARP over ATM                 April 1998


   [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
       Geneva, 19-29 January 1993.

   [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
       - 2 October 1992.

   [8] Braden, R., "Requirements for Internet Hosts -- Communication
       Layers", STD 3, RFC 1122, October 1989.

   [9] ATM Forum, "ATM User-Network Interface (UNI) Specification
       Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper
       Saddle River, NJ, 07458, September, 1994.

   [10] Deering, S., "Host Extensions for IP Multicasting", STD 5,
        RFC 1112, August 1989.

   [11] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
        NSAP Allocation in the Internet", RFC 1237, July 1991.

   [12] Bradely, T., and C. Brown, "Inverse Address Resolution
        Protocol", RFC 1293, January 1992.

   [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
        Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
        pp. 32-48, 1989.

   [14] Knowles, S., "IESG Advice from Experience with Path MTU
        Discovery", RFC 1435, March 1993.

   [15] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
        March 1997.

   [16] Kent C., and J. Mogul, "Fragmentation Considered Harmful",
        Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in
        Computer Communications Technology, August 1987.

   [17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
        November 1990.

   [18] Green, M., Luciani, J., White, K., and T. Kuo, "Definitions of
        Managed Objects for Classical IP and ARP over ATM Using
        SMIv2", RFC 2320, April 1998.

   [19] ATM Forum, "ATM User-Network Interface (UNI) Specification
        Version 4.0", ATM Forum specfication af-sig-0061.000,
        ftp://ftp.atmforum.com/, July, 1996.





Laubach & Halpern           Standards Track                    [Page 25]

RFC 2225                  IP and ARP over ATM                 April 1998


   [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

15. AUTHORS' ADDRESSES

   Mark Laubach
   Com21, Inc.
   750 Tasman Drive
   Milpitas, CA 95035

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


   Joel Halpern
   Newbridge Networks, Inc.
   593 Herndon Parkway
   Herndon, VA  22070-5241

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




























Laubach & Halpern           Standards Track                    [Page 26]

RFC 2225                  IP and ARP over ATM                 April 1998


APPENDIX A - Update Information

   This memo represents an update to RFC 1577 and RFC 1626.  The
   following changes are included in this memo:

   o   Pointer to Classical MIB I-D for setting of variables

   o   Single ATMARP server address to ATMARP server list, configurable
       via the MIB.

   o   RFC 1626 text replaces MTU section

   o   Client registration procedure from In_ATMARP to first
       ATMARP_Request

   o   Clarification of variable length ATMARP packet format

   o   Clarification of ARP_NAK packet format

   o   Clarification of InATMARP packet format for null IPv4 addresses

   o   Clarification on ATMARP registration and use of InATMARP_Reply
       for clients having more than one IP address in a LIS




























Laubach & Halpern           Standards Track                    [Page 27]

RFC 2225                  IP and ARP over ATM                 April 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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 implmentation may be prepared, copied, published
   andand 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