3. NETWORK NAME ISSUES AND DISCUSSION

The issues involved in the design were the definition of network name syntax, the mappings to be provided, and possible support for similar functions at the subnet level.

3.1. Network name syntax

The current syntax for network names, as defined by [RFC 952] is an alphanumeric string of up to 24 characters, which begins with an alpha, and may include "." and "-" except as first and last characters. This is the format which was also used for host names before the DNS. Upward compatibility with existing names might be a goal of any new scheme.

However, the present syntax has been used to define a flat name space, and hence would prohibit the same distributed name allocation method used for host names. There is some sentiment for allowing the NIC to continue to allocate and regulate network names, much as it allocates numbers, but the majority opinion favors local control of network names. Although it would be possible to provide a flat space or a name space in which, for example, the last label of a domain name captured the old-style network name, any such approach would add complexity to the method and create different rules for network names and host names.

For these reasons, we assume that the syntax of network names will be the same as the expanded syntax for host names permitted in [HR]. The new syntax expands the set of names to allow leading digits, so long as the resulting representations do not conflict with IP addresses in decimal octet form. For example, 3Com.COM and 3M.COM are now legal, although 26.0.0.73.COM is not. See [HR] for details.

The price is that network names will get as complicated as host names. An administrator will be able to create network names in any domain under his control, and also create network number to name entries in IN-ADDR.ARPA domains under his control. Thus, the name for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa- network.MIL., depending on the preferences of the owner.

3.2. Mappings

The desired mappings, ranked by priority with most important first, are:

• Mapping a IP address or network number to a network name.

  This mapping is for use in debugging tools and status displays of various sorts. The conversion from IP address to network number is well known for class A, B, and C IP addresses, and involves a simple mask operation. The needs of other classes are not yet defined and are ignored for the rest of this RFC.

• Mapping a network name to a network address.

  This facility is of less obvious application, but a symmetrical mapping seems desirable.

• Mapping an organization to its network names and numbers.

  This facility is useful because it may not always be possible to guess the local choice for network names, but the organization name is often well known.

• Similar mappings for subnets, even when nested.

  The primary application is to be able to identify all of the subnets involved in a particular IP address. A secondary requirement is to retrieve address mask information.

3.3. Network address section of the name space

The network name syntax discussed above can provide domain names which will contain mappings from network names to various quantities, but we also need a section of the name space, organized by network and subnet number to hold the inverse mappings.

The choices include:

• The same network number slots already assigned and delegated in the IN-ADDR.ARPA section of the name space.

          For example, 10.IN-ADDR.ARPA for class A net 10,
          2.128.IN-ADDR.ARPA for class B net 128.2, etc.
  

• Host-zero addresses in the IN-ADDR.ARPA tree. (A host field of all zero in an IP address is prohibited because of confusion related to broadcast addresses, et al.)

          For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
          0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
          first scheme, it uses in-place name space delegations to
          distribute control.
  

  The main advantage of this scheme over the first is that it allows convenient names for subnets as well as networks. A secondary advantage is that it uses names which are not in use already, and hence it is possible to test whether an organization has entered this information in its domain database.

• Some new section of the name space.

  While this option provides the most opportunities, it creates a need to delegate a whole new name space. Since the IP address space is so closely related to the network number space, most believe that the overhead of creating such a new space is overwhelming and would lead to the WKS syndrome. (As of February, 1989, approximately 400 sections of the IN-ADDR.ARPA tree are already delegated, usually at network boundaries.)