Classical IP and ARP over ATM
obsoleted by
- rfc-2225 — Classical IP and ARP over ATM
Extracted elements (26)
A single ATMARP Server per LIS was chosen as a simple reference model. The memo acknowledges this is less robust than multiple synchronized servers, but does not prohibit more robust approaches that use the same client-server interface.
ARP_NAK was added as a new operation code extension so that a client can distinguish between a catastrophic ATMARP server failure (no response) and an ATMARP table lookup failure (explicit negative reply), improving robustness of the address resolution mechanism.
The ATMARP packet format extends classic ARP by replacing fixed-length hardware address fields with variable-length ATM number and ATM subaddress fields, each preceded by an 8-bit type/length indicator, because ATM addresses are not fixed-length hardware addresses and support multiple structures (NSAPA and E.164).
The LIS model follows traditional IP subnet boundaries because administrators will initially replicate existing deployment models, policy administration relies on IP gateway security and filtering capabilities (firewalls) that ATM cannot yet replace, and standards for global IP over ATM will take time to complete.
ATM does not support broadcast addressing, so there are no mappings from IP broadcast addresses to ATM services. Separately, ATM does not support multicast address services; current IP multicast implementations (MBONE and IP tunneling) continue to operate over ATM-based logical IP subnets in WAN configuration.
A single ATMARP Server MUST be located within the LIS and MUST have authoritative responsibility for resolving the ATMARP requests of all IP members within the LIS. There is to be one and only one ATMARP Server operational per logical IP subnet.
All members of a LIS MUST have a mechanism for resolving IP addresses to ATM addresses via ATMARP when using SVCs, and 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; i.e., the virtual connection topology underlying the intercommunication among members is fully meshed.
Client ATMARP table entries are valid for a maximum time of 15 minutes. Server ATMARP table entries are valid for a minimum time of 20 minutes.
Hosts of differing 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 the ATMARP client does not maintain an open VC to the server, the client MUST refresh its ATMARP information with the server at least once every 20 minutes by opening a VC to the server and exchanging the initial InATMARP packets.
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.
In a strict PVC environment, all IP members supporting PVCs are required to use InATMARP on those VCs using LLC/SNAP encapsulation. When the ATM source and/or target address is unknown, the corresponding ATM address length field MUST be set to zero.
IP members MUST register their ATM endpoint address with their ATMARP server using the ATM address structure appropriate for their network connection. Implementations MUST support all three ATM address structures (NSAPA-only, E.164-only, and E.164 with NSAPA subaddress).
Members, upon receiving an IP broadcast or IP subnet broadcast for their LIS, MUST process the packet as if addressed to that station. ATM does not support broadcast addressing, so there are no mappings from IP broadcast addresses to ATM broadcast services.
Prior to aging an ATMARP table entry, an ATMARP server MUST generate an InARP_REQUEST on any open VC associated with that entry; if an InARP_REPLY is received, the entry is updated and not deleted. If no open VC exists, the entry is deleted.
The default MTU size for IP members operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, so the default ATM AAL5 PDU size is 9188 octets. Non-default values may be used only if all LIS members are configured with that value.
When an ATMARP table entry ages, an ATMARP client MUST invalidate the entry. If an invalidated entry has an associated open VC, the client must revalidate via InARP_REQUEST (PVC) or ARP_REQUEST to the server (SVC) before transmitting non-address-resolution traffic.
ATMARP defines five operation codes: ARP_REQUEST=1, ARP_REPLY=2, InARP_REQUEST=8, InARP_REPLY=9, and ARP_NAK=10. The ARP_NAK is an extension to the protocol; its packet format is the same as the received ARP_REQUEST with the operation code field changed to ARP_NAK.
Three ATM address structures are defined for ATMARP: Structure 1 uses ATM Forum NSAPA number with null subaddress; Structure 2 uses E.164 number with null subaddress; Structure 3 uses E.164 number with ATM Forum NSAPA subaddress.
A unique hardware type value of 19 decimal (0x0013) has been assigned to ATM Forum address family for use in the ar$hrd field of ATMARP packets, as listed in the Assigned Numbers RFC.
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/InATMARP address resolution mechanism defined in this memo. Authenticated call management, end-to-end communications authentication, and data encryption are believed to be needed in globally connected ATM networks but are beyond this memo's scope.
The ATMARP server maintains a table of <ATM address, IP address> entries with timestamps. On new VC with LLC/SNAP: server sends InARP_REQUEST; on InARP_REPLY: add/update entry. On duplicate IP with different ATM address and open VC: discard and make no change. On ARP_REQUEST: reply with ARP_REPLY or ARP_NAK. VC teardown does NOT remove table entries.
ATMARP and InATMARP packets are encoded in AAL5 PDUs using LLC/SNAP encapsulation with LLC=0xAA-AA-03 (3 octets), OUI=0x00-00-00 (3 octets), Ethertype=0x08-06 (2 octets), for a fixed 8-octet LLC/SNAP header that aligns the ATMARP packet on a 64-bit boundary.
The 8-bit type/length fields (ar$shtl, ar$sstl, ar$thtl, ar$tstl) are encoded with bit 8 reserved (0), bit 7 indicating address type (0=ATM Forum NSAPA, 1=E.164), and bits 6-1 as a 6-bit unsigned octet length of the address.
The ATMARP/InATMARP packet contains: ar$hrd (16 bits), ar$pro (16 bits), ar$shtl (8 bits, type+length of source ATM number), ar$sstl (8 bits), ar$op (16 bits), ar$spln (8 bits), ar$thtl (8 bits), ar$tstl (8 bits), ar$tpln (8 bits), followed by variable-length source ATM number, source ATM subaddress, source protocol address, target ATM number, target ATM subaddress, and target protocol address fields.