Internet Protocol

From Citizendium
Revision as of 00:19, 15 September 2008 by imported>Howard C. Berkowitz (linked to multicast stub, another item on my list to fill in. I even have the dissertation that started it all.)
Jump to navigation Jump to search
This article is developed but not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable, developed Main Article is subject to a disclaimer.

Template:TOC-right

For more information, see: Internet Protocol Suite.
See also: Internet Protocol version 4
See also: Internet Protocol version 6

The Internet Protocol (IP) is a protocol used for communicating across a heterogeneous network. It is the protocol on which the Internet is built. This article puts the major versions and sub-versions of the basic protocol into a historical context; see Internet Protocol version 4 and Internet Protocol version 6 for the details of design. Presented here are the principle of that design.

While there were earlier laboratory versions, the first deployed version of the Internet Protocol version 4 (IPv4) was specified in January 1980, but, for reasons dealing with locators discussed below, that first specification proved inadequate in under two years. [1] A slight variation bought about a decade of utility, before serious limitations became obvious. [2] has been the standard for many years, but Internet Protocol version 6 (IPv6)[3] is the newer standard.

Architectural goals

It was a basic Internet architectural assumption that the intelligence should be at the edges of the network, while the internal forwarding elements should have no memory of previous packets or connections, and use the IP level to decide simply how to forward a packet one hop closer to the destination. The lack of memory, or statelessness, is very different than the assumption of classic telephone networks, which are more concerned with committing resources to a call, and verifying an end-to-end path exists, than forwarding information on that path.

Experience showed that the ideal lies somewhere in the middle. IP can remain stateless, and the decision of whether an end-to-end service is stateful or not is a decision for each application. IP, however, is a hop-by-hop, not an end-to-end, protocol.

Address structure

Every IP packet has a source address and a destination address. Within the routing domain in which these addresses are used, the addresses must be unique. In the global Internet, blocks of addresses are delegated from the Internet Corporation for Assigned Names and Numbers, which further delegates blocks of addresses to Regional Internet Registries at a roughly continental level.

There are two fundamental parts of an address: the locator and the identifier. While these concepts were used informally, the results of discussions in the early nineties were published in a hazy yet provocative view of the future. [4]

Locator

By analogy, a locator tells how to get somewhere, such as a street name in geography, or country and area code in telephony. Routers make decisions based on the locator, until they are on the final "street" and need to look for the "house number".

While there is considerable variation between IPv4 and IPv6, and within each of these address families, the locator, also called the prefix, is a certain number of bits starting from the left.

Local versus remote principle

One of the original architectural principles of the Internet, the local versus remote problem comes up in this context. If the host to which you want to send has the space prefix, you are on the same L2 link and can communicate with it, once you know its layer 2 address. If the destination has different prefix, you must use a router to reach it.

L2 addressing is trivial on point-to-point links; there is only the 'other end". On broadcast-capable local area networks, the Address Resolution Protocol (ARP) provides the solution in IPv4 networks: the client broadcasts the IP address of the desired destination, in a frame with his L2 address as the source; the destination hears it, and sends back an ARP reply with its MAC address.

There is no absolutely general mechanism for a nonbroadcast multiaccess medium (NBMA) such as frame relay and Asynchronous Transfer Mode (ATM), which may be set up as a hub-and-spoke topology , with only the hub available for broadcast if broadcast (or multicast) is available if it is available at all. A common method is to configure a manual L2-L3 mapping, although there are inverse ARP protocols for some NBMA media.[5]

IPv6 takes a different approach, neighbor discovery, where a host can learn passively from the announcements of all hosts sharing the link.

Prefix aggregation

Remember that "prefix" is another name for "locator". Think of international telephone calls, where, as soon as the local telephone switch recognizes the international prefix, it will look no farther than the number of digits needed to reach that country. In the North American Numbering Plan for telephones, the basic address is 10-digit:

  • 3 area code (between a state and a part of a city, based on user population)
  • 3 exchange (a locality within a reasonably small area, such as a city); a physical telephone switching office will rarely contain the switches for more than five exchanges. Exchanges are unique within area codes, but each area code can have a 945 exchange.
  • 4 line, unique within the address. Every exchange can have a line 1212.

When telephone switches look at only the international part of a number, they are aggregating all exchange and line numbers, or national equivalent. Different national numbering plans have different structures, but the international switch does not need to understand it.

In an analogous manner, major Internet routers do a great deal of prefix aggregation. They try to make decisions on a relatively few bits starting at the left, which might identify a large service provider or enterprise. Once the Internet routers deliver packets to the destination indicated by the aggregate, the routers in that location now look at more bits of the prefix, just as once an international telephone call reaches a country, the national switch looks at the next level of detail, area code in North America. Only when the call reaches the area code level of switch does the telephone routing process look for the additional information pointing to an exchange. Only at the final exchange does the switch look for the specific line.

Prefix deaggregation

Originally, the assumption was that any given site or organization would be happy with a single large "flat" address space, managed by a single large mainframe computer. This assumption was shattered by several innovations: personal compuers and servers needing at least enterprise-unique addresses, local area networks needing prefixes that could be part of the prefix seen by the rest of the public Internet but needing uniqueness within the enterprises, and organizations having multiple sites with direct (i.e., not accessible via the public Internet) between them.

Where aggregation collapses the "phone number toward the left", deaggregation extends it to the right. Aggregation, especially in the set of IPv4 techniques called classless inter-domain routing, conserves space in routing tables and processing required to maintain them.

Deaggregation, also called variable length subnet masking in IPv4, extends the prefix to the right, giving up host address space in favor of the ability to separate groups of hosts into local area networks, campuses of multiple LANs, and enterprises with munltiple campuses (i.e., sites). Sites ranged from large corporate or academic facilities, or small office and home (SOHO) networks that might have one, or a small number, of hosts, each needing an address.

Identifiers

Think of a basic locator address as a street, and the identifier as the house name on it. In IPv4, the numbering may be static (i.e., administrator defined) or dynamic (i.e., next available number from a pool). IPv6 also has static and dynamic identifier assignment, but its much longer identifier field length allows autoconfiguration using a physical identifier defined as unique. This identifier, on local area networks, is the 48-bit medium access control address.

Rethinking requirements

One of the problems of Internet Protocol development was that it started as a research project, when there were no local area networks and no personal computers. The first version of the Internet Protocol could interconnect 255 sites, more than anyone thought would be necessary. Large computers at the sites were expected to know the locations of thousands of computers.

The need for larger addresses

Within a year or so of the first specification, it was quickly realized there would be many more than 255 sites, and the sites would be of different size. Since the original IP had no way to indicate the prefix length, various administrative conventions were used to infer the length from the value of the first few bits, but, by the early 1990s, this relatively inflexible structure was wasting a great amount of address space. Allocations tended to be of two sizes: too large and too small.

A number of "just in time" extensions managed to make address allocation more efficient,[6] but more and more limits appeared, due to the 32 bit total size of IPv4 addresses. While a great many computers could be counted serially within a 32 bit number, the need to split the address into locator and identifier meant that some of the potential numbers were not usable. More and more elaborate workarounds were put into service, but just so much could be done with 32 bits. The management of the address space became especially challenging for Internet Service Providers. [7]

One of the proposals to deal with the problem was relatively modest: IPv4 with larger addresses, called TUBA. [8]

Need for a new protocol?

It was not, at first, a given that an entirely new Internet Protocol was needed. after various user communities expressed their needs, four main proposals emerged, with two combining into what became the new Internet starship, IP version 6.

When the problem was put out to the Internet engineering community, one of the the Internet Engineering Task Force solicited proposals for "IP, the Next Generation", in conscious imitation of the second Star Trek series. [9]

By 1993, it was clear that IPv4 was reaching its limits, not only from the address size. Aspects of the header were harder and harder to process at increasing line speed. T The first IPv6 specification was published in 1995, but the Internet research and engineering communities continue to refine it.[10] The cited first specification has been superceded; see Internet Protocol version 6 for more current work.

The much larger 128 bit addresses, in IPv6, are not so large because we expect to have 128 bits' worth of unique computer addresses. IPv6 addresses are so long because lengthening the address greatly simplifies the work of separating the locator from the identifier, and having a hierarchy of levels of locators/prefixes.

Address scope

See also: Locality of networks

The scope of an address describes the area in which it must be unique..

Intranets have no need to have addresses unique with respect to the global Internet, and, indeed, there are blocks in IPv4 and IPv6 that are defined not to be routable in the global system. One way to extend the lifetime of the increasingly scarce IPv4 address space is to use "registered" IPv4 addresses only on the Internet-facing side of network address translators, and use private space in the enterprise side.

Extranets may use private space if the address administration does not become overwhelming; extranets of the size of U.S. military networks such as NIPRNET, SIPRNET and JWICS have unique address space that is delegated by military administrators. In practice, there is no conflict even if every address on the public Internet were duplicated, because the secure networks have an "air gap" to the Internet; there is no direct connectivity at the IP level.

IP is transmission medium agnostic

IP architects call it "agnostic" as to the underlying medium access control that manages shared access to the medium, the physical layer protocol managing the access of single devices to the medium, and to the transmission medium. It commonly runs over multimegabit or gigabit links, but has been demonstrated to operate, in conjunction with the Transmission Control Protocol, over avian media (i.e., carrier pigeons). [11][12][13] IP provides computers with communicable addresses that are globally unique.

IP is a connectionless protocol and provides best-effort delivery for its data payload, making no guarantees with respect to reliability. Without notification to either the sender or receiver, packets may become corrupted, lost, reordered, or duplicated. This design reduces the complexity of Internet routers. When reliable delivery is needed, the Internet Protocol Suite has mechanisms at the end-to-end (e.g., Transmission Control Protocol) or application (e.g., Hypertext Transfer Protocol) levels.

References

  1. Postel, J. (January 1980), Internet Protocol, Internet Engineering Task Force, RFC0760
  2. Postel, J. (September 1981), Internet Protocol, Internet Engineering Task Force, RFC0791
  3. Deering, S. & Hinden, R. (December 1998), Internet Protocol, Internet Engineering Task Force, RFC2460
  4. I. Castineyra, N. Chiappa, M. Steenstrup (August 1996), The Nimrod Routing Architecture, RFC1992
  5. T. Bradley, C. Brown, A. Malis (September 1998), Inverse Address Resolution Protocol, RFC2390
  6. V. Fuller, T. Li, J. Yu, K. Varadhan (September 1993), Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC1519
  7. Berkowitz, Howard C. (November 1998), "Good ISPs Have No Class: Addressing Nuances and Nuisances", North American Network Operators Group
  8. R. Callon (June 1992), TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing, RFC1347
  9. S. Bradner, A. Mankin (December 1993), IP: Next Generation (IPng) White Paper Solicitation., RFC1550
  10. S. Deering, R. Hinden (December 1995), Internet Protocol, Version 6 (IPv6) Specification, RFC1883
  11. Waitzman, D. (April 1 1990), Standard for the transmission of IP datagrams on avian carriers, Internet Engineering Task Force, RFC1149
  12. Waitzman, D. (April 1 1999), IP over Avian Carriers with Quality of Service, Internet Engineering Task Force, RFC2549
  13. Bergen Linux Users Group (April 28 2001, 12:00), The highly unofficial CPIP WG