Classical IP and ARP over ATM
draft-ietf-atm-classic-ip-06

#x27;s VC Routing specification is not complete
   at this time and therefore its impact on the operational use of ATM
   Address Structure 3 is undefined. The ATM Forum will be defining this
   relationship in the future.  It is for this reason that IP members
   need to support all three ATM address structures.

8.7 ATMARP/InATMARP Packet Encapsulation

   ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using
   LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field
   for ATMARP/InATMARP PDUs is:

               Payload Format for ATMARP/InATMARP PDUs:
               +------------------------------+
               |        LLC 0xAA-AA-03        |
               +------------------------------+
               |        OUI 0x00-00-00        |
               +------------------------------+
               |     Ethertype 0x08-06        |
               +------------------------------+
               |                              |
               |   ATMARP/InATMARP Packet     |
               |                              |
               +------------------------------+

   The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a
   SNAP header.

   The OUI value of 0x00-00-00 (3 octets) indicates that the following
   two-bytes is an ethertype.

   The Ethertype value of 0x08-06 (2 octets) indicates ARP [4].

   The total size of the LLC/SNAP header is fixed at 8-octets. This
   aligns the start of the ATMARP packet on a 64-bit boundary relative
   to the start of the AAL5 CPCS-SDU.

   The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is
   consistent with the treatment of multiprotocol encapsulation of IP

Laubach                                                        [Page 14]

DRAFT                Classical IP and ARP over ATM         December 1993

   over ATM AAL5 as specified in [2] and in the format of ATMARP over
   IEEE 802 networks as specified in [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 ATMARP'ing 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.

10.  IP Multicast Address

   ATM does not support 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.

11.  Security

   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.

   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

Laubach                                                        [Page 15]

DRAFT                Classical IP and ARP over ATM         December 1993

   mechanism defined here for use with networks using IP over ATM.

12.  Open Issues

   o   Interim Local Management Interface (ILMI) services will not be
       generally implemented initially by some providers and vendors and
       will not be used to obtain the ATM address network prefix from
       the network [9].  Meta-signalling does provide some of this
       functionality and in the future we need to document the options.

   o   Well known ATM address(es) for ATMARP servers?  It would be very
       handy if a mechanism were available for determining the "well
       known" ATM address(es) for the client's ATMARP server in the LIS.

   o   There are many VC management issues which have not yet been
       addressed by this specification and which await the unwary
       implementor.  For example, one problem that has not yet been
       resolved is how two IP members decide which of duplicate VCs can
       be released without causing VC thrashing.  If two IP stations
       simultaneously established VCs to each other, it is tempting to
       allow only one of these VCs to be established, or to release one
       of these VCs immediately after it is established.  If both IP
       stations simultaneously decide to release opposite VCs, a
       thrashing effect can be created where VCs are repeatedly
       established and immediately released.  For the time being, the
       safest strategy is to allow duplicate VCs to be established and
       simply age them like any other VCs.

REFERENCES

   [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
       Service", RFC1209, USC/Information Sciences Institute, March
       1991.

   [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC1483, USC/Information Sciences Institute, July 1993.

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

   [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
       Information Sciences Institute, July 1992.

   [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
       Sciences Institute, February 1988.

Laubach                                                        [Page 16]

DRAFT                Classical IP and ARP over ATM         December 1993

   [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", RFC1122, USC/Information Sciences Institute, October
       1989.

   [9] ATM Forum, "ATM User-Network Interface Specification Version
       3.0.", ATM Forum, 480 San Antonio Road, Suite 100, Mountain View,
       CA 94040, June 1993.

   [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112,
       USC/Information Sciences Institute, August 1989.

   [11] Colella, Richard, and Gardner, Ella, and Callon, Ross,
       "Guidelines for OSI NSAP Allocation in the Internet", RFC1237,
       USC/Information Sciences Institute, July 1991.

   [12] Bradely, T., and Brown, C., "Inverse Address Resolution
       Protocol", RFC1293, USC/Information Sciences Institute, 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.

Author's Address

   Mark Laubach
   Hewlett-Packard Laboratories
   1501 Page Mill Road
   Palo Alto, CA 94304

   Phone: 415.857.3513
   FAX:   415.857.8526
   EMail: laubach@hpl.hp.com

Laubach                                                        [Page 17]