The Second Internet HTML version

onto the network wire, in compliance with Ethernet or other standards. Output to wire: Ethernet packet
using MAC addresses (or the equivalent if other network hardware is used, such as Wi-Fi).
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.
3.3.2 – IPv4: The Internet Protocol, Version 4
IPv4 is the foundation of TCP/IPv4 and accounts for many of its distinguishing characteristics, such as its
32-bit address size, its addressing model, its packet header structure and routing. IPv4 was first defined
in RFC 791 “Internet Protocol”, September 1981.
The following standards are relevant to IPv4:
RFC 791, “Internet Protocol” , September 1981 (Standards Track)
RFC 792, “Internet Control Message Protocol”, September 1981 (Standards Track)
RFC 826, “An Ethernet Address Resolution Protocol”, November 1982 (Standards Track)
RFC 1256, “ICMP Router Discovery Messages”, September 1991 (Standards Track)
RFC 2390, “Inverse Address Resolution Protocol”, September 1998 (Standards Track)
RFC 2474, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers”, December 1998 (Standards Track)
RFC 4650, “HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)”,
September 2006 (Standards Track)