Classical Internet Protocol

For ATM to work transparently under IP, an IP address must be resolved to an ATM address and a connection to that destination must be established. Classical IP does this via a database of IP/ATM address pairs that is either provided by an ATM ARP server that is accessible to all hosts on the subnet, or is maintained locally in each host.

ATM Address Resolution

Traditional TCP/IP and UDP/IP applications use IP addresses for communicating to a destination. For these applications to run like traditional applications, IP addresses need to be resolved into ATM addresses. The ATM address then signals to establish an ATM connection to the destination. An ATM connection in turn is represented by a VPI/VCI. The host must use this returned VPI/VCI to send packets to the destination that represents the ATM connection.

ATM address resolution, also called ATM ARP, follows RFC 1577, the classic draft that describes the ATM ARP process.

RFC 1577 assumes the existence of an ATM ARP server on every subnet. Every client on the subnet communicates with the ATM ARP server to derive the destination's ATM address from its IP address. The ATM ARP server holds the IP-to-ATM address information for all hosts in the ATM subnet. It is likely that initial ATM configurations will not rely on dynamic ATM address resolution because it requires the presence of an ATM ARP server on every subnet. Also, there are no specified standards for providing redundant ATM ARP servers for a subnet. As specified, the ATM ARP server would constitute a single point of failure in the system. From a practical standpoint, however, early configurations can use an IP-to-ATM address database in every system, thus avoiding the IP-to-ATM address resolution step altogether.

The RFC requires a router for passing data between subnets. SunATM software provides ATM utilities that allow configurations to specify IP-to-ATM addresses in /etc/opt/SUNWconn/atm/aarconfig files. The aarsetup program uses the information in /etc/opt/SUNWconn/atm/aarconfig to create IP-to-ATM address resolution tables. Dynamic entries into a server's resolution table are also supported.

Table 3-1 shows the format of the /etc/opt/SUNWconn/atm/aarconfig file for specifying the IP-to-ATM address. It is important for the file to be consistent on all systems in the subnet. See "Editing the /etc/opt/SUNWconn/atm/aarconfig File".

ATM ARP Address Resolution Tables

Depending on the aarconfig file, the Classical IP software runs as either a server or a client. As a server, the Classical IP software handles ATM ARP requests originating from its clients. An ATM server has to be configured for each subnet. The ATM ARP server code conforms to RFC 1577: clients send ATM ARP requests to the server to resolve a destination IP address to an ATM address. The server then replies to ATM ARP requests by sending an ATM ARP response. If the server does not have the IP-to-ATM address entry, then it replies with NAK.

All the IP-to-ATM address entries specified in the /etc/opt/SUNWconn/atm/aarconfig file are entered into a kernel resident table by the ATM ARP setup program, aarsetup. Additional entries in the kernel table are added dynamically using the inverse ARP process. When a client connects to the server, the server sends an inverse ARP request back to the client to obtain the client's IP address. When a response is received, an entry is created for that client. The Classical IP software also responds to client ARP requests. The software looks up a kernel IP-to-ATM address entry and responds to an ATM ARP request with either an ATM ARP reply or ATM ARP NAK (if there is no entry in the table). Note that an ATM ARP client uses the virtual channel (VC) specified in the /etc/opt/SUNWconn/atm/aarconfig file to communicate with the server; or, if an ATM address is specified, it establishes a switched virtual circuit (SVC) connection to communicate with the server.

While dynamic entries in the ARP server's table make network administration less complex, they also create a security problem. Any host can register with the ARP server and therefore gain access to the subnet. To resolve this issue, you can provide a list of hosts or networks with a entries in the server's /etc/opt/SUNWconn/atm/aarconfig file. If no a entries appear, any host can connect to the server. If any a entries exist, only those hosts whose addresses match those specified will be allowed to connect.

Although the a entry requires a complete ATM address, you can reference multiple addresses in a single entry using the provided wildcards. See "Using Variables in the  /etc/opt/SUNWconn/atm/aarconfig File" for more information about this feature.

The advantage of having an ATM ARP server in the subnet is that it represents a known source for all address resolutions. It is the only host that a client must know about to have IP addresses resolved to ATM connections, and it allows for access control in the ATM network.

When the /etc/opt/SUNWconn/atm/aarconfig file has been modified on a system, it is necessary to rerun aarsetup.

For better caching, all clients have the option of adding to their configuration file the IP-to-ATM address information for other clients. This can benefit clients that communicate frequently because it eliminates having to go through the ATM ARP server for IP-to-ATM address resolution.

If a host has multiple SunATM cards, the host can be a server for one IP subnet and a client for another. This is handled transparently by aarsetup.

IPv6 Address Resolution Process

IPv6 addressing works diffferntly than IPv4. IPv6 uses Neighbor Discovery process (RFC 2461) rather than ARP protocol for the address resolution. SunATM 5.1 does not currently support address resolution through RFC 2461 over IPv6. Thus PVC and SVC address resolution over IPv6 must be statically configured. You must enter all destination hosts and ATM Address/VCI entries on each host's local aarconfig file.