Classical IP and ARP over ATM
Extracted elements (29)
The default IP MTU of 9180 octets was chosen to match RFC 1209's IP MTU over SMDS, since having the same MTU for ATM AAL5 and SMDS reduces IP fragmentation and aids interoperability. NFS with overhead requires at least 8300 octets, and larger MTUs improve router performance.
The LIS model requires inter-subnet traffic to flow through an IP router even if a direct ATM VC could be established, because administrators rely on IP gateways for security, access control, routing, and filtering. ATM must not 'back-door' around these mechanisms.
The single ATMARP server model is used as a reference model for this specification, while acknowledging that future multiple-server models will provide higher reliability. The goal is a stable baseline that extensions can build upon.
For backward compatibility with RFC 1577, when a null IPv4 protocol address is received with length=4 and value 0.0.0.0, receiving stations MUST accept this format. However, on transmitting, a null IPv4 address MUST be indicated by length=0 with no storage allocated.
Old RFC 1577 clients can register with the updated ATMARP service simply by issuing ATMARP_Requests to it; the server creates a new table entry for the source information even when source IP and target IP differ.
All IP stations MUST support ATMARP and InATMARP protocols as updated and extended in this memo. All members in the LIS MUST use the same address resolution service, which MUST have authoritative responsibility for resolving ATMARP requests of all IP members within the LIS.
All members of a LIS MUST have a mechanism for resolving IP addresses to ATM addresses via ATMARP and vice versa via InATMARP when using SVCs, and MUST have a mechanism for resolving VCs to IP addresses via InATMARP when using PVCs.
All members within a LIS MUST be able to communicate via ATM with all other members in the same LIS; the Virtual Connection topology underlying the intercommunication among the members is fully meshed.
All router implementations that comply with this specification must implement the IP Path MTU Discovery mechanism as defined in RFC 1191; host implementations should also implement it.
Client ATMARP table entries are valid for a maximum of 15 minutes. When an entry ages, the client MUST invalidate it; if there is an open VC, the client MUST revalidate the entry prior to transmitting any non-address-resolution traffic on that VC.
Clients MUST implement and provide a MIB as defined in RFC 2320 'Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2'.
Hosts communicating with hosts on different IP subnets MUST communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network.
If an ATMARP client receives an ATMARP message with an operation code it does not support, it MUST gracefully discard the message and continue normal operation; it is NOT REQUIRED to return any message to the sender.
If the calling endpoint receives a CONNECT message that does not contain the AAL Parameters Information Element but the corresponding SETUP message did, it shall clear the call with cause 'AAL Parameters cannot be supported'.
Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in RFC 1483; LLC/SNAP encapsulation is the default packet format for IP datagrams.
Implementations that support SVCs MUST attempt to negotiate the AAL CPCS-SDU size using the ATM signalling protocol via the 'AAL Parameters' Information Element in the SETUP message.
IP clients MUST register their ATM endpoint address with their ATMARP server and MUST support all three ATM address structures (NSAPA-only, E.164-only, and E.164 with NSAPA subaddress).
Server ATMARP table entries are valid for 20 minutes. If an entry ages beyond 20 minutes without being refreshed by the client, that entry is deleted from the table regardless of the state of any associated VCs.
The ATMARP client MUST refresh its ATMARP information with the server at least once every 15 minutes by re-establishing an LLC/SNAP VC and transmitting an ATMARP_Request for its own IP address.
The default IP MTU for use with ATM AAL5 shall be 9180 octets. All implementations compliant with this specification shall support at least this default IP MTU value.
When the ATMARP server detects a duplicate IP address (same IP, different ATM address, open VC on existing entry), it MUST return the existing table entry in the ATMARP_Reply and MUST raise a 'duplicate IP address detected' condition to management; the table entry is not updated.
The ATMARP operation codes are: ATMARP_Request=1, ATMARP_Reply=2, InATMARP_Request=8, InATMARP_Reply=9, ATMARP_NAK=10. These reuse ARP and InARP operation code values and extend them with ARP_NAK.
The ATMARP single-server model requires clients to establish a point-to-point LLC/SNAP VC to the server, then register by sending an ATMARP_Request for their own IP address. The server builds its table from source address information in received ATMARP_Requests.
Three ATM address structures are defined: Structure 1 (ATM Forum NSAPA number, null subaddress), Structure 2 (E.164 number, null subaddress), and Structure 3 (E.164 number with ATM Forum NSAPA subaddress). All three MUST be supported by implementations.
There are known security issues relating to host impersonation via address resolution protocols used in the Internet. No special security mechanisms have been added to the ATMARP mechanism defined here; ATMARP packets are not authenticated, which is a potentially serious flaw allowing corrupt information to be introduced into the server.
ATMARP/InATMARP packet fields: ar$hrd (16 bits, hardware type = 19/0x0013 for ATM), ar$pro (16 bits, protocol type), ar$shtl/ar$sstl/ar$thtl/ar$tstl (8 bits each, TL fields for ATM number and subaddress), ar$op (16 bits, operation code), ar$spln/ar$tpln (8 bits each, protocol address lengths), followed by variable-length ATM number, subaddress, and protocol address fields.
ATMARP/InATMARP packets are encapsulated in AAL5 PDUs using LLC/SNAP: LLC 0xAA-AA-03 (3 octets), OUI 0x00-00-00 (3 octets), EtherType 0x08-06 (2 octets), yielding an 8-octet fixed LLC/SNAP header that aligns the ATMARP packet on a 64-bit boundary.
ATMARP_NAK packet format is identical to the received ATMARP_Request packet with the operation code changed to ARP_NAK (decimal 10); the request data is exactly copied for transmission.
The 8-bit TL (type and length) field encoding: bit 8 is reserved (0), bit 7 indicates address type (0 = ATM Forum NSAPA, 1 = E.164), bits 6-1 encode the octet length of the address (0 to 20 decimal).