Table of Contents 
IP
RoutingInternet addresses can be symbolic or numeric. The symbolic form is easier to read, for example: myname@ibm.com. The numeric form is a 32-bit unsigned binary value which is usually expressed in a dotted decimal format. For example, 9.167.5.8 is a valid Internet address. The numeric form is used by the IP software. The mapping between the two is done by the Domain Name System discussed in Domain Name System (DNS). We shall first look at the numeric form, which is called the IP address.
The standards for IP addresses are described in RFC 1166 -- Internet Numbers.
To be able to identify a host on the internet, each host is assigned an address, the IP address, or Internet Address. When the host is attached to more than one network, it is called multi-homed and it has one IP address for each network interface. The IP address consists of a pair of numbers:
IP address = <network number><host number>The network number part of the IP address is centrally administered by the Internet Network Information Center (the InterNIC) and is unique throughout the Internet. (1)
IP addresses are 32-bit numbers usually represented in a dotted decimal form (as the decimal representation of four 8-bit values concatenated with dots). For example 128.2.7.9 is an IP address with 128.2 being the network number and 7.9 being the host number. The rules used to divide an IP address into its network and host parts are explained below.
The binary format of the IP address 128.2.7.9 is:
10000000 00000010 00000111 00001001
IP addresses are used by the IP protocol (see Internet Protocol (IP)) to uniquely identify a host on the internet. IP datagrams (the basic data packets exchanged between hosts) are transmitted by some physical network attached to the host and each IP datagram contains a source IP address and a destination IP address. To send a datagram to a certain IP destination, the target IP address must be translated or mapped to a physical address. This may require transmissions on the network to find out the destination's physical network address (for example, on LANs the Address Resolution Protocol, discussed in Address Resolution Protocol (ARP), is used to translate IP addresses to physical MAC addresses).
The first bits of the IP address specify how the rest of the address should be separated into its network and host part.
The terms network address and netID are sometimes used instead of network number, but the formal term, used in RFC 1166, is network number. Similarly, the terms host address and hostID are sometimes used instead of host number.
There are five classes of IP addresses. These are shown in
Figure - Assigned Classes of Internet
Addresses.
Figure: Assigned Classes of Internet Addresses
Note: Two numbers out of each of the class A, class B and class C network numbers, and two host numbers out of every network are pre-assigned: the ``all bits 0'' number and the ``all bits 1'' number. These are discussed below in Special IP Addresses.
It is clear that a class A address will only be assigned to networks with a huge number of hosts, and that class C addresses are suitable for networks with a small number of hosts. However, this means that medium-sized networks (those with more than 254 hosts or where there is an expectation that there may be more than 254 hosts in the future) must use Class B addresses. The number of small- to medium-sized networks has been growing very rapidly in the last few years and it was feared that, if this growth had been allowed to continue unabated, all of the available Class B network addresses would have been used by the mid-1990s. This is termed the IP Address Exhaustion problem. The problem and how it is being addressed are discussed in The IP Address Exhaustion Problem.
One point to note about the split of an IP address into two parts is that this split also splits the responsibility for selecting the IP address into two parts. The network number is assigned by the InterNIC, and the host number by the authority which controls the network. As we shall see in the next section, the host number can be further subdivided: this division is controlled by the authority which owns the network, and not by the InterNIC.
Due to the explosive growth of the Internet, the use of assigned IP addresses became too inflexible to allow easy changes to local network configurations. These changes might occur when:
To avoid having to request additional IP network addresses in these cases, the concept of subnets was introduced.
The host number part of the IP address is sub-divided again into a network number and a host number. This second network is termed a subnetwork or subnet. The main network now consists of a number of subnets and the IP address is interpreted as:
<network number><subnet number><host number>The combination of the subnet number and the host number is often termed the ``local address'' or the ``local part''. ``Subnetting'' is implemented in a way that is transparent to remote networks. A host within a network which has subnets is aware of the subnetting but a host in a different network is not; it still regards the local part of the IP address as a host number.
The division of the local part of the IP address into subnet number and host number parts can be chosen freely by the local administrator; any bits in the local part can be used to form the subnet accomplished. The division is done using a subnet mask which is a 32 bit number. Zero bits in the subnet mask indicate bit positions ascribed to the host number, and ones indicate bit positions ascribed to the subnet number. The bit positions in the subnet mask belonging to the network number are set to ones but are not used. Subnet masks are usually written in dotted decimal form, like IP addresses.
The special treatment of ``all bits zero'' and ``all bits one'' applies to each of the three parts of a subnetted IP address just as it does to both parts of an IP address which has not been subnetted. See Special IP Addresses. For example, a subnetted Class B network, which has a 16-bit local part, could use one of the following schemes:
There are two types of subnetting: static and variable length. Variable length is the more flexible of the two. Which type of subnetting is available depends upon the routing protocol being used; native IP routing supports only static subnetting, as does the widely used RIP protocol. However, RIP Version 2 supports variable length subnetting as well. See Routing Information Protocol (RIP) for a description of RIP and RIP2. Routing Protocols discusses routing protocols in detail.
Static subnetting means that all subnets in the subnetted network use the same subnet mask. This is simple to implement and easy to maintain, but it implies wasted address space for small networks. For example, a network of four hosts that uses a subnet mask of 255.255.255.0 wastes 250 IP addresses. It also makes the network more difficult to reorganize with a new subnet mask. Currently, almost every host and router supports static subnetting.
When variable length subnetting is used, the subnets that make up the network may use different subnet masks. A small subnet with only a few hosts needs a subnet mask that accommodates only these few hosts. A subnet with many hosts attached may need a different subnet mask to accommodate the large number of hosts. The possibility to assign subnet masks according to the needs of the individual subnets will help conserve network addresses. Also, a subnet can be split into two parts by adding another bit to the subnet mask. Other subnets in the network are unaffected by the change. Not every host and router supports variable length subnetting.
Only networks of the size needed will be allocated and routing problems will be solved by isolating networks with routers that support variable subnetting. A host that does not support this kind of subnetting would have to route to a router that supports variable subnetting.
At first sight, it appears that the presence of a host which only supports static subnetting would prevent variable length subnetting from being used anywhere in the network. Fortunately this is not the case. Provided that the routers between subnets with different subnet masks are using variable length subnetting, the routing protocols employed are able to hide the difference between subnet masks from the hosts in a subnet. Hosts can continue to use basic IP routing and offload all of the complexities of the subnetting to dedicated routers.
Assume that our IP network has been assigned the class B IP network number 129.112. We have to implement multiple physical networks throughout our network. and some of the routers we will be using do not support variable length subnetting. We must therefore choose a subnet mask for the whole network. We have a 16-bit local address for our whole network and must divide it into two parts appropriately. At the moment, we do not anticipate having more than 254 physical networks, nor more than 254 hosts per network, so a logical subnet mask to use is 255.255.255.0 (which also has the advantage of being an ``easily readable'' one). This decision should be made with care, since it will be difficult to change it later. If the number of networks or hosts grows beyond the planned numbers, we may have to implement variable length subnetting to make the best use of the 65,534 local addresses we have.
Figure - A Subnet Configuration shows an
example of an implementation with three subnets.
Figure: A Subnet Configuration - Three physical networks form one IP
network. The two routers are performing slightly different tasks. Router 1 is
acting as a router between subnets 1 and 3 and as a router between the whole of
our network and the rest of the internet. Router 2 acts only as a router
between subnets 1 and 2.
Let us now consider a different subnet mask:
255.255.255.240. The fourth octet is then divided in two parts:
The following table contains the valid subnets using this subnet mask:
Table: Subnet Values for Subnet Mask 255.255.255.240
For each of these subnet values, only 14 addresses (from 1 to 14) for hosts are available, because only the right part of the octet can be used and because addresses 0 and 15 (all bits set to one) have a special meaning as described in Special IP Addresses.
Thus, subnet number 9.67.32.16 will contain hosts whose IP addresses are in the range of 9.67.32.17 to 9.67.32.30, and subnet number 9.67.32.32 will contain hosts whose IP addresses are in the range of 9.67.32.33 to 9.67.32.46, etc.
To route an IP datagram on the network, the general IP
routing algorithm has the following form:
Figure: IP Routing without Subnets
To be able to differentiate between subnets, the IP routing algorithm changes
and has the following form:
Figure: IP Routing with Subnets
Some implications of this algorithm are:
In case one or more hosts do not support subnetting, an alternative way to achieve the same goal exists in the form of proxy-ARP, which doesn't require any changes to the IP routing algorithm for single-homed hosts, but does require changes on routers between subnets in the network. This is explained in more detail in Proxy-ARP or Transparent Subnetting.
All IBM TCP/IP implementations support subnetting but there is currently no support for proxy-ARP routers.
Usually, hosts will store the subnet mask to be used in a configuration file. However, sometimes this cannot be done, as for example in the case of a diskless workstation. The ICMP protocol includes two messages, address mask request and address mask reply, which allow hosts to obtain the correct subnet mask from a server. See Address Mask Request (17) and Address Mask Reply (18) for more information.
Whenever a host has a physical connection to multiple networks or subnets, it is described as being multi-homed. All routers are multi-homed since their purpose is to join networks or subnets. A multi-homed host always has different IP addresses associated with each network adapter, since each adapter is in a different subnet or network.
There is one apparent exception to this rule: with some systems (for example VM and MVS) it is possible to specify the same IP address for multiple point-to-point links (such as channel-to-channel adapters) if the routing protocol used is limited to the basic IP routing algorithm. For example, a VM ``hypervisor'' system running TCP/IP connected to a token-ring LAN via a 3172 Interconnect Controller may run a number of ``guest'' VM and/or MVS systems. A very cost-effective solution for connecting these guests to the token-ring is to connect them to the hypervisor's TCP/IP with virtual channel-to-channel connections. The IP addresses can be chosen so that the channel-to-channel connected systems constitute their own subnet, in which case the hypervisor acts as a router. Because the routing protocols available on VM and MVS only support static subnetting, it may be difficult to find an additional subnet number if the address space is constrained. Therefore, the channel-to-channel connected systems may be given IP addresses in the same subnet as the token ring, in which case the hypervisor is taking the place of a bridge, and is not multi-homed. One disadvantage of this configuration is that other hosts on the LAN need static definitions to route datagrams for the hosts on the far side of the ``bridge'' via the hypervisor because the 3172 is not aware that it has this bridging responsibility. The ``transparency'' of bridges described in Bridges, Routers and Gateways is missing in this scenario.
As noted above, any component of an IP address with a value ``all bits 0'' or all ``all bits 1'' has a special meaning
There is another address of special importance: the ``all bits 1'' class A network number 127 is reserved for the loopback address. Anything sent to an address with 127 as the value of the high order byte, for example 127.0.0.1, must not be routed via a network but must be routed directly from the IP implementation's output driver to its input driver. (2)
The majority of IP addresses refer to a single recipient: these are called unicast addresses. However, as noted above, there are two special types of IP address which are used for addressing multiple recipients: broadcast addresses and multicast addresses. These addresses are used for sending messages to multiple recipients. Any protocol which is connectionless may send broadcast or multicast messages as well as unicast messages. A protocol which is connection-oriented can only use unicast addresses because the connection exists between a specific pair of hosts. See Transmission Control Protocol (TCP) for more information on connection-oriented protocols.
There are a number of addresses which are used for IP broadcasting: all use the convention that ``all-bits 1'' indicates ``all''. Broadcast addresses are never valid as source addresses, only as destination addresses. The different types of broadcast addresses are listed here:
There is one exception to this rule, called BOOTP forwarding. The BOOTP protocol uses the limited broadcast address to allow a diskless workstation to contact a boot server. BOOTP forwarding is a configuration option available on some routers, including the IBM 6611 and 2210 Network Processors to make an exception for UDP datagrams for ports 67 (used by the BOOTP protocol). Without this facility, a separate BOOTP server would be required on each subnet. However, this is not simple forwarding because the router also plays a part in the BOOTP protocol. See BOOTstrap Protocol - BOOTP for more information about BOOTP forwarding and User Datagram Protocol (UDP) for an explanation of UDP ports.
If routers do respect all-subnets-directed broadcast address they use an algorithm called Reverse Path Forwarding to prevent the broadcast messages from multiplying out of control. See RFC 922 for more details on this algorithm.
Broadcasting has a major disadvantage: its lack of selectivity. If an IP datagram is broadcast to a subnet, every host on the subnet will receive it, and have to process it to determine whether the target protocol is active. If it is not, the IP datagram is discarded. Multicasting avoids this overhead by using groups of IP addresses.
Each group is represented by a 28-bit number, which is included in a Class D
address. Recall that a class D address has the format:
So multicast group addresses are IP addresses in the range 224.0.0.0 to
239.255.255.255. For each multicast address there is a set
of zero or more hosts which are listening to it. This set is called the host
group. There is no requirement for any host to be a
member of a group to send to that group. There are two kinds of host group:
Some other examples used by the OSPF routing protocol (see Open Shortest Path First Protocol (OSPF) Version 2) are:
Multicasting on a single physical network which supports the use of multicasting is simple. To join a group, a process running on a host must somehow inform its network device drivers that it is wishes to be a member of the specified group. The device driver software itself must map the multicast address to a physical multicast address and enable the reception of packets for that address. The device driver must also ensure that the receiving process does not receive any spurious datagrams by checking the destination address in the IP header before passing it to the IP layer.
For example, Ethernet supports multi-casting if the high-order byte of the 48-byte address is X'01' and IANA owns an Ethernet address block, which consists of the addresses between X'00005E000000' and X'00005EFFFFFF'. The lower half of this range has been assigned by IANA for multicast addresses, so on an Ethernet LAN there is a range of physical addresses between X'01005E000000' and X'01005E7FFFFF' which is used for IP multicasting. This range has 23 usable bits, so the 28-bit multicast addresses are mapped to the Ethernet addresses by considering the low-order 23 bits, that is 32 multicast addresses are mapped to each Ethernet address. Because of this non-unique mapping, filtering by the device driver is required. There are two other reasons why filtering might still be needed:
Multicasting is not limited to a single physical network. There are two aspects to multicasting across physical networks:
The first problem is easily solved: the multicast datagram has a Time To Live (TTL) value like every other, which is decremented with each hop to a new network. When the Time to Live field is decremented to zero, the datagram can go no further. The mechanism for deciding whether a router should forward a multicast datagram is called Internet Group Management Protocol (IGMP) or Internet Group Multicast Protocol. This is described further in Internet Group Management Protocol (IGMP). IGMP and multicasting are defined in RFC 1112 - Host extensions for IP multicasting.
The number of networks on the Internet has been approximately doubling annually for a number of years. However, the usage of the Class A, B and C networks differs greatly: nearly all of the new networks assigned in the late 1980s were Class B, and in 1990 it became apparent that if this trend continued, the last Class B network number would be assigned during 1994. On the other hand, Class C networks were hardly being used.
The reason for this trend was that most potential users found a Class B network to be large enough for their anticipated needs, since it accommodates up to 65534 hosts, whereas a class C network, with a maximum of 254 hosts, severely restricts the potential growth of even a small initial network. Furthermore, most of the class B networks being assigned were small ones. There are relatively few networks that would need as many as 65,534 host addresses, but very few for which 254 hosts would be an adequate limit. In summary, although the Class A, Class B and Class C divisions of the IP address are logical and easy to use (because they occur on byte boundaries), with hindsight they are not the most practical because Class C networks are too small to be useful for most organizations while Class B networks are too large to be densely populated by any but the largest organizations.
Table - IP network number usage between 1990
and 1994 shows the usage of network numbers between 1991 and 1994.
Table: IP network number usage between 1990 and 1994 - Source:
netinfo/ip_network_allocations.95Jan from anonymous FTP site
rs.internic.net
Some points about this table require explanation.
Note: IANA actually reports a network as either assigned or allocated, but this table treats allocated as a superset of assigned so that the reader can subtract the Allocated percentage from 100 to easily determine how much ``free'' space is left.
Another way to look at these numbers is to examine the proportion of the address space which has been used: the figures in the table do not show for example that the Class A address space is as big as the rest combined, or that a single Class A network can theoretically have as many hosts as 66,000 Class C networks. Figure - IP Address Space Usage shows the usage of the address space from this point of view. The full pie represents a 32-bit flat address space, that is 2(superscript 32) or 4,294,967,296 addresses. The Class A, B and C address spaces are divided as follows:
The assigned space is shown with ``exploded'' slices: the combined area of the exploded slices represents the proportion of the IP address space in use.
The allocated space is shown with shaded but not exploded slices.
Examination of Table - IP network number usage between 1990 and 1994 shows that since 1990, the number of assigned Class B networks has been increasing at a much lower rate than the total number of assigned networks and that the anticipated exhaustion of the Class B network numbers has not occurred. The reason for this is that the policies of the InterNIC on network number allocation were changed in late 1990 to preserve the existing address space, in particular to avert the exhaustion of the Class B address space. The new policies can be summarized as follows.
and
Any requirements for a Class A network would be handled on an individual case basis.
The upper half of the Class C address space (208.0.0 to 223.255.255) remains unassigned and unallocated.
The maximum number of network numbers assigned contiguously is 64, corresponding to a prefix of 18 bits. An organization requiring more than 4096 addresses but less than 16,384 addresses can request either a Class B or a range of Class C addresses. In general, the number of Class C networks assigned is the minimum required to provide the necessary number of IP addresses for the organization on the basis of a two-year outlook. However, in some cases, an organization may request multiple networks to be treated separately. For example, an organization with 600 hosts would normally be assigned four class C networks. However, if those hosts were distributed across 10 token-ring LANs with between 50 and 70 hosts per LAN, such an allocation would cause serious problems, since the organization would have to find 10 subnets within a 10-bit local address range. This would mean at least some of the LANs having a subnet mask of 255.255.255.192 which allows only 62 hosts per LAN. The intent of the rules is not to force the organization into complex subnetting of small networks, and the organization should request 10 different Class C numbers, one for each LAN.
The current rules are to be found in RFC 1466 - Guidelines for Management of IP Address Space. The reasons for the rules for the allocation of Class C network numbers will become apparent in the next section. The use of Class C network numbers in this way has averted the exhaustion of the Class B address space, but it is not a permanent term solution to the overall address space constraints that are fundamental to IP. The long-term solution is discussed in IP: The Next Generation (IPng).
Another approach to conservation of the IP address space is described in RFC 1597 - Address Allocation for Private Internets. Briefly, it relaxes the rule that IP addresses are globally unique by reserving part of the address space for networks which are used exclusively within a single organization and which do not require IP connectivity to the Internet. There are three ranges of addresses which have been reserved by IANA for this purpose:
Any organization may use any addresses in these ranges without reference to any other organization. However, because these addresses are not globally unique, they cannot be referenced by hosts in another organization and they are not defined to any external routers. Routers in networks not using private addresses, particularly those operated by Internet service providers, are expected to quietly discard all routing information regarding these addresses. Routers in an organization using private addresses are expected to limit all references to private addresses to internal links; they should neither advertise routes to private addresses to external routers nor forward IP datagrams containing private addresses to via external routers. Hosts having only a private IP address do not have IP-layer connectivity to the Internet. This may be desirable and may even be a reason for using private addressing. All connectivity to external Internet hosts must be provided with application gateways.There is a major problem with the use of a range of Class C addresses instead of a single Class B addresses: each network must be routed separately. Standard IP routing understands only the class A, B and C network classes. Within each of these types of network, subnetting can be used to provided better granularity of the address space within each network, but there is no way to specify that multiple class C networks are actually related. The result of this is termed the routing table explosion problem: a Class B network of 3000 hosts requires one routing table entry at each backbone router, but if the same network is addressed as a range of Class C networks, it requires 16 entries.
The solution to this problem is a scheme called Classless Inter-Domain Routing (CIDR). CIDR is a proposed standard protocol with a status of elective.
CIDR does not route according to the class of the network number (hence the term classless) but solely according to the high order bits of the IP address which are termed the IP prefix. Each CIDR routing entry contains a 32 bit IP address and a 32 bit network mask, which together give the length and value of the IP prefix. This can be represented as <IP_address network_mask>. For example <194.0.0.0 254.0.0.0> represents the 7 bit IP prefix B'1100001'. CIDR handles the routing for a group of networks with a common prefix with a single routing entry. This is the reason why multiple Class C network numbers assigned to a single organization have a common prefix. This process of combining multiple networks into a single entry is termed address aggregation or address summarization. It is also called supernetting because routing is based upon network masks which are shorter than the natural network mask of the IP address, in contrast to subnetting where the network masks are longer than the natural mask.
Unlike subnet masks, which are normally contiguous but may have a discontiguous local part, supernet masks are always contiguous.
If IP addresses are represented with a tree showing the routing topology, with each leaf of the tree representing a group of networks which are considered as a single unit (called a routing domain) and the IP addressing scheme is chosen so that each fork in this tree corresponds to an increase in the length of the IP prefix, then CIDR allows address aggregation to be performed very efficiently. For example, if a router in North America routes all European traffic via a single link, then a single routing entry for <194.0.0.0 254.0.0.0> includes the group of Class C network addresses assigned to Europe as described above. This single entry takes the place of all the entries for all of the assigned network numbers in this range which is a possible maximum of 2(superscript 17) or 131,072 numbers. At the European end of this link, there are routing entries with longer prefixes which map to the European network topology but this routing information is not needed at the American end of the link. CIDR uses a longest match is best approach, so if the router in the US needs to make an exception for one range of addresses, such as the 64 network range <195.1.64.0 255.555.192.0> it needs just one additional entry, since this entry overrides the more general (shorter) one for those networks it contains. It is apparent from this example that as the usage of the IP address space increases, particularly the Class C address space, the benefits of CIDR increase as well, provided that the assignment of addresses follows the network topology. The existing state of the IP address space does not follow such a scheme since it pre-dates the development of CIDR. However, new Class C addresses are being assigned in such a way as to enable CIDR, and this should have the effect of alleviating the routing table explosion problem in the near term. In the longer term, a restructuring of the IP address space along topological lines may be necessary. This would involve the re-numbering of a large number of networks, implying an enormous amount of implementation effort, and so would be a gradual process.
It is an over-simplification to assume that routing topology can be represented as a simple tree; although most routing domains have a single attachment which provides access to the rest of the Internet, there are also many domains which have multiple attachments. Routing domains of these two types are called single-homed and multi-homed. Furthermore, the topology is not static. Not only are new organizations joining the Internet at an ever-increasing rate, but existing organizations may change places within the topology, for example if they change between service providers for commercial or other reasons. Although such cases complicate the practical implementation of CIDR-based routing and reduce the efficiency of address aggregation that can be achieved, they do not invalidate the approach.
The current Internet address allocation policies and the assumptions on which those policies were based is described in RFC 1518 - An Architecture for IP Address Allocation with CIDR. They can be summarized as follows:
Note: This implies that if an organization changes its Internet service provider, it should change all of its IP addresses. This is not the current practice, but the widespread implementation of CIDR is likely to make it much more common.
Because multi-homed domains may vary greatly in character and none of the above schemes is suitable for all such domains, there is no single policy which is best and RFC 1518 does not specify any rules for choosing between them.
The implementation of CIDR in the Internet is primarily based on Border Gateway Protocol Version 4 (see Border Gateway Protocol Version 4 (BGP-4)). In future CIDR will also be implemented by a variant of the ISO standard Inter-Domain Routing Protocol (IDRP, ISO 10747), called IDRP for IP, which is closely related to BGP-4.
The implementation strategy, described in RFC 1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment involves a staged process through the routing hierarchy beginning with backbone routers. Network service providers are divided into four types:
The Domain Name System protocol is a standard protocol (STD 13). Its status is recommended. It is described in:
The early internet configurations required users to use only numeric IP addresses. Very quickly, this evolved to the use of symbolic host names. For example, instead of typing TELNET 128.12.7.14 one could type TELNET eduvm9, and eduvm9 is then translated in some way to the IP address 128.12.7.14. This introduces the problem of maintaining the mappings between IP addresses and high-level machine names in a coordinated and centralized way.
Initially, host names to address mappings were maintained by the Network Information Center (NIC) in a single file (HOSTS.TXT) which was fetched by all hosts using FTP. This is called a flat namespace.
Due to the explosive growth in the number of hosts, this mechanism became too cumbersome (consider the work involved in the addition of just one host to the Internet) and was replaced by a new concept: Domain Name System. Hosts may continue to use a local flat namespace (the HOSTS.LOCAL file) instead of or in addition to the Domain Name System, but outside small networks, the Domain Name System is practically essential. The Domain Name System allows a program running on a host to perform the mapping of a high-level symbolic name to an IP address for any other host without the need for every host to have a complete database of host names.
For the remainder of this section we will examine how the Domain Name System works from the user's point of view. See Domain Name System (DNS) for more details about the implementation of domain name resolvers and servers and the types of records stored in the Domain Name System.
Consider the internal structure of a large organization. As the chief executive cannot do everything, the organization will probably be partitioned into divisions, each of them having autonomy within certain limits. Specifically, the executive in charge of a division has authority to make direct decisions, without permission from his chief executive.
Domain names are formed in a similar way, and will often reflect the hierarchical delegation of authority used to assign them. For example, consider the name
lcs.mit.edu
Here, lcs.mit.edu is the lowest-level domain name, a subdomain of mit.edu,
which again is a subdomain of edu (education) which is called a top-level
domain. We can also represent this naming concept by a
hierarchical tree (see Figure - Hierarchical
Namespace).
When using the Domain Name System, it is common to work with only a part of the domain hierarchy, for example the ral.ibm.com domain. The Domain Name System provides a simple method of minimizing the typing necessary in this circumstance. If a domain name ends in a dot (for example, wtscpok.itsc.pok.ibm.com.) it is assumed to be complete. This is termed a Fully Qualified Domain Name (FQDN) or an absolute domain name. If, however it does not end in a dot (for example, wtscpok.itsc) it is incomplete and the DNS resolver (see below) may complete this, for example by appending a suffix such as .pok.ibm.com to the domain name. The rules for doing this are implementation dependent and locally configurable.
The three-character top-level names are called the
generic domains or the organizational domains.
Since the Internet began in the United States, the organization of the
hierarchical namespace initially had only US organizations at the top of the
hierarchy, and it is still largely true that the generic part of the namespace
contains US organizations. However, only the .gov and .mil domains are
restricted to the US.
There are also top-level domains named for the each of
the ISO 3166 international 2-character country codes (from ae for the
United Arab Emirates to zw for Zimbabwe). These are
called the country domains or the geographical domains. Many
countries have their own second-level domains underneath which parallel the
generic top-level domains. For example, in the United Kingdom, the domains
equivalent to the generic domains .com and .edu are .co.uk and .ac.uk (``ac''
is an abbreviation for academic). There is a .us top-level domain, which is
organized geographically by state (for example, .ny.us refers to the state of
New York). See RFC 1480 for a detailed description of the .us domain.
The mapping of names to addresses, a process called
domain name resolution, is provided by independent,
cooperating systems called name servers. A name
server is a server program answering requests from a client called a name
resolver.
Each name resolver is configured with a name server to
use (and possibly a list of alternatives to contact if the primary is
unavailable). Figure - Domain Name
Resolution shows schematically how a program uses a name resolver to
convert a host name to an IP address. A user provides a host name, and the user
program uses a library routine, called a stub resolver, to communicate with a
name server which resolves the host name to an IP address and returns it to the
stub, which returns it to the main program. The name server may obtain the
answer from its name cache, its own database or another name server.
The Domain Name System provides for a mapping of
symbolic names to IP addresses and vice versa. While it is a simple
matter in principle to search the database for an IP address given its symbolic
name because of the hierarchical structure, the reverse process cannot follow
the hierarchy. Therefore, there is another namespace for the reverse mapping.
It is found in the domain in-addr.arpa (``arpa'' because the Internet was
originally the ARPA Internet). Because IP addresses are normally written in
dotted decimal format, there is one layer of domains for each hierarchy.
However, because domain names have the least-significant parts of the name
first but dotted decimal format has the most significant bytes first, the
dotted decimal address is shown in reverse order. For example, the domain in
the domain name system corresponding to the IP address 129.34.139.30 is
30.139.34.129.in-addr.arpa. Given an IP address, the Domain Name System can be
used to find the matching host name. A domain name query to find the host names
associated with an IP address is called a ``pointer query''.
The Domain Name System is designed to be capable of
storing a wide range of information. One of the most important of these is
mail exchange information, which is used for electronic mail routing.
This provides two facilities: transparent re-routing of mail to a different
host than that specified and the implementation of mail gateways where
electronic mail can be received by a mail gateway and re-directed using a
different mail protocol from the intended recipient. This is explained in more
detail in SMTP and the Domain Name System.
For more details on the implementation of the Domain
Name System and the format of the messages between Name Servers, see
Domain Name System (DNS). The following RFCs
define the Domain Name System standard and the information kept in the system.
Domain Name
Meaning
Figure: The Generic Top-level Domains
2.2.8.4 Country Domains
2.2.8.5 Mapping Domain Names to IP Addresses
Figure: Domain Name Resolution
2.2.8.6 Mapping IP Addresses to Domain Names - Pointer
Queries
2.2.8.7 Other Uses for the Domain Name System
2.2.8.8 References
Internet
Protocol (IP)