IPv4 is specified in RFC 791, “INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, September 1981.
IPv4 first went live on January 1, 1983. Prior to that, only an earlier protocol usually referred to as NDP was used. From that date forward, only IPv4 was used. This kind of abrupt transition is not possible with the changeover from IPv4 to IPv6. For one thing, NDP supported a maximum of 256 nodes, and there were a very small number of highly technical people using it. Even so, things did not go well, and there periods of several months in which things like world-wide e-mail stopped working. With IPv4 to IPv6, there are billions of users, and breaking e-mail or web, even for a few days, would cause massive problems and financial damage around the world.
IPv4 uses 32-bit addresses. Internally, and “on the wire” these are just an ordered set of 32 binary digits. For the convenience of humans, these are represented in dotted-decimal notation. Software converts between the internal binary representation and the external dotted-decimal representation.
In dotted-decimal notation, the 32 bits are split into 4 groups of 8 bits. Each group of 8 bits is represented by a decimal (base 10) value from 0 (0000 00002) to 255 (1111 11112). The four groups of digits are separated by the “.” character (here called “dot”). Hence, the name “dotted-decimal”.
A typical IPv4 address is “172.20.2.1”. Represented in hexadecimal, that would be 0xAC140201. In binary that would be 1010 1100 0001 0100 0000 0010 0000 00012.
Before allocation was turned over to IANA, a gentleman named Jon Postel was in charge of allocating IPv4 addresses. The first allocation scheme was based on “classes“. Eventually, the IETF realized that we would run out of IPv4 public addresses very quickly using this “three sizes fit all” scheme, so a better scheme was adopted in RFC 1519, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, September 1993.
Review of TCP/IPv4
This section contains is a brief review of TCP/IPv4, the foundation of the Second Internet. Its purpose is to help you understand what is new and different in TCP/IPv6. It is not intended to be comprehensive. There are many great books listed in the bibliography if you wish to understand TCP/IPv4 at a deeper level. The reason it is relevant here is because the design of IPv6 is based heavily on that of IPv4. First, IPv4 can be considered one of the great achievements in IT history, based on its worldwide success, so it was a good model to copy from. Second, there were several attempts to do a new design “from the ground up” with IPv6 (a “complete rewrite”). These involved really painful migration and interoperability issues. You need to understand what the strengths and weaknesses of IPv4 are to see why IPv6 evolved the way it did. You can think of IPv6 as “IPv4 on steroids”, which takes into account the radical differences in the way we do networking today, and fixing problems that were encountered in the first 27 years of the Internet, as network bandwidth and number of nodes increased exponentially. We are doing things over networks today than no one could have foreseen a quarter of a century ago, no matter how visionary they were.
The software that made the Second Internet (and virtually all Local Area Networks) possible has actually been around for quite some time. It is actually a suite (family) of protocols. The core protocols of this suite are TCP (the Transmission Control Protocol) and IP (Internet Protocol), which gave it its common name, TCP/IP. Its official name is The Internet Protocol Suite.
TCP was first defined officially in RFC 675, “Specification of Internet Transmission Control Program”, December 1974 (yes, 36 years ago). The protocol described in this document does not look much like the current TCP, and in fact, the Internet Protocol (IP) did not even exist at the time. Jon Postel was responsible for splitting the functionality described in RFC 675 into two separate protocols: (the new) TCP and IP. RFC 675 is largely of historical interest now. The modern version of TCP was defined in RFC 795, “Transmission Control Protocol – DARPA Internet Program Protocol Specification”, September 1981 (seven years later). It was later updated by RFC 1122, “Requirements for Internet Hosts – Communication Layers” October 1989, which covers the link layer, IP layer and transport layer. It was also updated by RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP”, September 2001, which adds ECN to TCP and IP.
Both of these core protocols, and many others, will be covered in considerable detail in the rest of this chapter.
Unlike the OSI network stack, which really does have seven layers, the DoD network model has four layers, as shown below:
Four Layer TCP/IPv4 Model
It just confuses the issue to try to figure out which of the seven OSI layers the various layers of TCP/IP fit into. It is simply not applicable. It’s like trying to figure out what color “sweet” is. The OSI seven layer model did not even exist when TCP/IP was defined. Unfortunately, many people use terms like “layer 2” switches versus “layer 3” switches. These refer to the OSI model. Books from Cisco Press and the Cisco certification exams are particularly adamant about using OSI terminology. Unfortunately no one actually uses OSI networks today. In this book we will try to consistently use the four layer model terminology, while referring to the OSI terminology when necessary for you to relate the topic to actual products or other books.
Note: outgoing data begins in the application and is passed down the layers of the stack (adding headers at each layer) until it is written to the wire. Incoming data is read off the wire, and travels up the layers of the stack (having headers stripped off at each layer) until it is accepted by the application. In the following discussion, for simplicity, I describe only the outgoing direction.
The Application Layer implements the protocols most people are familiar with (e.g. HTTP). The software routines for these are typically contained in application programs such as browsers or web servers that make “system calls” to subroutines (or “functions” in C terminology) in the “socket API” (an API is an Application Program Interface, or a collection of related subroutines, typically supplied with the operating system or C programming language compiler). The application code creates outgoing data streams, and then calls routines in the API to actually send the data via TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). Output to Transport Layer: [DATA] using IP addresses.
The Transport Layer implements TCP (the Transmission Control Protocol) and UDP (the User Datagram Protocol). The routines that implement these are internal to the Network Stack (in the OS Kernel). They do not exist in user applications (“application space”). In the case of TCP, packet sequencing, plus error detection and retransmission are handled. This layer adds a TCP or UDP packet header to the data passed down from the Application Layer, and then pass the resulting packet down to the Internet Layer for further processing. Output to Internet Layer: [TCP HDR[DATA]], using IP addresses.
The Internet Layer implements IP (the Internet Protocol) and various other related protocols such as ICMP (which includes the “ping” function among other things). The IP routine takes the data passed down from the Transport Layer routines, adds an IP packet header onto it, then passes the now complete IPv4 packet down to routines in the Link Layer. Output to Link layer: [IP HDR[TCP HDR[DATA]]] using IP addresses.
The Link Layer implements protocols such as ARP that convert IP addresses to MAC addresses. It also contains routines that actually read and write data (as fed down to it by routines in the Internet Layer) onto the network wire, in compliance with Ethernet or other standards. Output to wire: Ethernet frame containing the IP packet, using MAC addresses (or other Link Layer addresses for non-Ethernet networks).
Each layer “hides” the details (and/or hardware dependencies) from the higher layers. This is called “levels of abstraction”. An architect thinks in terms of abstractions such as roofs, walls, windows, etc. The next layer down (the builder) thinks in terms of abstractions such as bricks, glass, mortar, etc. Below the level of the builder, an industrial chemist thinks in terms of formulations of clay or silicon dioxide to create bricks and glass. If the architect tried to think at the chemical or atomic level, it would be very difficult to design a house. His job is made possible by using levels of abstraction. Network programming is analogous. If application programmers had to think in terms of writing bits to the actual hardware, things like web browsers would be almost impossible. Each network layer is created by specialists that understand things at their level, and lower layers can be treated as “black boxes” by people working at higher layers.
Another important thing about network layers is that you can make major changes to one layer, without impacting the other layers much at all. The connections between layers are well defined, and don’t change (much). This provides a great deal of separation between the layers. In the case of IPv6, the Internet layer is almost completely redesigned internally, while the Link Layer and Transport Layer are not affected much at all (other than providing more bytes to store the larger IPv6 addresses). If your product is “IPv6 only”, that’s about the only change you would need to make to your application software (unless you display or allow entry of IP addresses). If your application is “dual stack” (can send and receive data over IPv4 or IPv6), then a few more changes are required in the application layer (e.g. to accept multiple IPv4 and IPv6 addresses from DNS and try connecting to one or more of them based on various factors, or to accept incoming connections over both IPv4 and IPv6). This makes it possible to migrate (or “port”) network software (created for IPv4) to IPv6 or even dual stack with a fairly minor effort. In comparison, changing network code written for TCP/IP to use OSI instead would probably involve a complete redesign and major recoding effort.