@DCN6.ARPA:mills@dcn6.arpa (11/03/85)
From: mills@dcn6.arpa Gents, I sense we need to clear a few sinuses here. The issue is how to assign Internet addresses so that somehow we can make the AX.25 packet-radio channel safe for Internet end systems. Note that I take AX.25 as given with the assumption that datagram service is available in addition to virtual-circuit service, but that neither is exclusive. We already have an excellent generator of random but unique identifiers as our assigned individual callsigns, but these are useless for routing purposes. Nevertheless, unique identifiers are so precious in the network world that we would be foolish to abandon the use of callsigns as local-net (AX.25) addresses. The Internet address space has already been sculpted at three levels: net, subnet and host, which makes it convenient for at least upper-level routing. It is inviting to map every callsign into a unique Internet address, but there isn't enough practical real estate to do this without doing violence to one or more of these levels. In order to realize the inherent routing capability of the Internet address, while allowing some degree of station mobility, the binding of local-net addresses (callsigns) to Internet addresses cannot be established on a permanent basis and may change from time to time. While this could be handled in principle by some responsive administrative body, it would be far better to establish some procedure that could do this automatically. The procedure should be designed so it would work in the absence of automated assistance, for instance by mutual cooperation among the local users. Eventually, the procedure should become part of the channel-access protocol architecture. If the primary incentive to adopt Internet addressing is to facilitate wide-area routing, then the primary decomposition of nets and subnets should be on the basis of the geographical locations and coverage areas of the gateways. If the AX.25 community is to be integrated to any degree with any part of the existing Internet it would be a fatal mistake to use a single net number everywhere, regardless of the use of subnets, because that would allow only a single port of entry to the AX.25 community. Datagrams sent from Stanford U could easily fly to a gateway in Washington, DC, and then swim laboriously back across the AX.25 continent to a station in Palo Alto. The decomposition and net-number issues need more study. Presumably, individual stations can be homed to one or more gateways and gateways can serve more than one net in an area. Nevertheless, since the primary function of the Internet address is to facilitate routing to the eventual destination, the end result of the binding should be to associate each station with the net having the best first-hop gateway on the path to most destinations. Let's assume that some hosts serving a particular net or subnet in an area collectively manage the space of host addresses for that net or subnet and are prepared to hand out unique Internet addresses on demand. Every player using Internet (not necessarily all players) could not only request assignment of an Internet address, but could learn the assignment of other players as well. This must be done with a reliable, distributed protocol, since the result will be that, for at least a time, all gateways and hosts serving that net must know how to reliably construct the AX.25 address from the given Internet address. Binding protocols (ARP and Reverse ARP) which could serve the above purposes have been developed for diskless Ethernet workstations; however, the characteristics of Ethernets and AX.25 channels are far different, most dramatically in that the channel is far less robust and not all stations can hear each other. We leave the development of such a protocol as an exercise for the gateway system implementors and concentrate on how to do this manually for the near future. The easiest and most obvious way is simply using a data base (file) maintained at designated BBS sites and copied occasionally by individual stations, much like the famous Internet file HOSTS.TXT is often used now. A pointer to this file could be advertised in beacons broadcast by that BBS. The table would be maintained informally, either cooperatively or by a designated referee. A station would become registered on a particular net by request and be confirmed by periodic re-registration requests thereafter. It would be de-registered if not re-registered within a renewal interval. In priniciple, a station could be registered on any nets served by gateways it can work, directly or indirectly; however, some mechanism may be necessary to discourage heroic paths. Using this simple scheme, how does a station in one net learn the Internet address of a station in another net? There are two ways to approach this problem. One is using domain nameservers as implemented by many Internet systems, including all likely to be reachable via AX.25. The domain nameserver provides the Internet address(es) and related information for a set of names registered in its data base. The data base is hierarchically partitioned with provisions for distributed update, backup and access from anywhere. Domain registration procedures and nameservers exist now all over the ARPANET centric Internet and at some trouble spots in the MILNET centric Internet. In principle we could register one or more domains and subdomains, for example AX25.ORG (!), and hijack a couple of Unix systems to run nameserver interference. We then cajole the hijacker(s) to update the hijackee(s) occasionally in response to electronic mail, which could of course originate on either side of the AX.25 gateways. I might wind up W3HCF.AX25.ORG as an alias for my beloved gateway/fuzzball DCN6.ARPA. In principle, domain nameservers could be accessed from within the AX.25 community as well, whether implemented on the AX.25 side of the gateways or not. It would certainly be feasable to operate a domain nameserver on any particular net, probably homed to a gateway; however, the AX.25 community is at present highly fragmented and can not be expected at the present time to provide a community-wide name-address translation service without outside help. I have a much more radical interim proposal designed to bridge the gap between the present chaos and the time such services are viable from anywhere in the AX.25 community. In the Internet architecture there are two reserved values in the net, subnet and host fields. The "broadcast" address consists of all ones in a field, while the "unspecified" address consists of all zeros. Ones in the host field means to broadcast to all hosts on the subnet, while ones in the subnet field means broadcast to all subnets on the net. Ones in the network field is considered rude and wouldn't work anyway. The use of zeros in the net, subnet and host fields usually is interpereted as "don't know," which is useful for various address-resolution procedures. Of course, no host or gateway should be assigned these as their primary addresses. My radical proposal involves a new Internet option called the local-route option. This option is operative only when a datagram with zeros in the host field appears at the destination gateway and is net-specific. The destination gateway is expected to construct the local-net address from the information in the option, which might override information it already has. In the case of AX.25 gateways, the option would take the form of an ASCII string containing at least the destination callsign and maybe the digipeater route. Let's say a station in an area not served by a domain nameserver wishes to contact another station in some other area. Using a map or some other means a list of nets serving that area is constructed. The station then selects one of these net addresses with zeros in the host field and inserts the local-route option containing the destination callsign. If the datagram can be punched through whatever network plumbing exists to reach the destination gateway, that gateway simply copies the local-route text into the frame header and tosses the datagram on the channel. If no response is heard the originator can try another net. Hopefully, the size of the list of nets is small, so that the number of alternate paths is manageable. This mechanism will work only in a participating host that provides the local-route option; moreover, it requires every participating host to be multiply-homed on both the unspecified co-address and any other specific addresses it has. In principle, these obstacles can be overcome easily in new IP/TCP implementations built especially for the AX.25 channel and maybe even in some existing ones. Fuzzballs already recognize the unspecified co-address and could be taught the local-route option in a few minutes. No Internet gateways other than those serving AX.25 nets and subnets will need to know or care about the proposed mechanism. It can be implemented almost trivially in the simplest AX.25 gateway that has fixed net-routing tables and no other topological knowledge. Again note the mechanism is intended only for use during a transitional period until the AX.25 community develops a degree of cohesiveness and robustness sufficient to support reliable domain nameservers. Dave -------