For backward compatibility with previous implementations, a null IPv4
protocol address may be received with length = 4 and an allocated
address in storage set to the value 0.0.0.0. Receiving stations MUST
be liberal in accepting this format of a null IPv4 address. However,
on transmitting an ATMARP or InATMARP packet, a null IPv4 address
MUST only be indicated by the length set to zero and MUST have no
storage allocated.
8.8 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
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 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.
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, RFC1209, March 1991.
[2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, 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, RFC1700,
July 1992.
[5] Postel, J., and J. Reynolds, "A Standard for the Transmission
of IP Datagrams over IEEE 802 Networks", STD 43, RFC1042,
February 1988.
[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, RFC1122, 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,
RFC1112, August 1989.
[11] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
NSAP Allocation in the Internet", RFC1237, July 1991.
[12] Bradely, T., and C. Brown, "Inverse Address Resolution
Protocol", RFC1293, 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", RFC1435, March 1993.
[15] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
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", RFC1191,
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", RFC2320, 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.
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
15. AUTHORS' ADDRESSES
Mark Laubach
Com21, Inc.
750 Tasman Drive
Milpitas, CA 95035
Phone: 408.953.9175
FAX: 408.953.9299
EMail: laubach@com21.com
Joel Halpern
Newbridge Networks, Inc.
593 Herndon Parkway
Herndon, VA 22070-5241
Phone: 703.736.5954
FAX: 703.736.5959
EMail: jhalpern@Newbridge.com
APPENDIX A - Update Information
This memo represents an update to RFC1577 and RFC1626. 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 RFC1626 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
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 OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."