Internet Protocol Summary

Internet Protocol Detailed

IP Addressing and Routing

Internet Protocol Suite

IPV4

IPV6

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

OSI Model

7 Application layer
6 Presentation layer
5 Session layer
4 Transport layer
3 Network layer
2 Data link layer
1 Physical layer

 

Application layer

The application layer is the seventh (7) level of the seven-layer OSI model. It interfaces directly to and performs common application services for the application processes; it also issues requests to the presentation layer.

The common application layer services provide semantic conversion between associated application processes. Note: Examples of common application services of general interest include the virtual file, virtual terminal, and job transfer and manipulation protocols.

Transport layer

In computing and telecommunications, the transport layer is level four of the seven level OSI model. It responds to service requests from the session layer and issues service requests to the network layer.

The transport layer provides transparent transfer of data between hosts. It is responsible for end-to-end error recovery and flow control. It ensures complete data transfer. In the IP protocol Stack this function is achieved by the connection oriented Transmission Control Protocol (TCP) or the datagram type User Datagram Protocol (UDP). The purpose of the Transport layer is to provide transparent transfer of data between end users, thus relieving the upper layers from any concern with providing reliable and cost-effective data transfer.

The transport layer turns the unreliable and very basic service provided by the Network layer into one worthy of the term 'Communication'. There is a long list of services that can be optionally provided at this level. None of them are compulsory, because not all applications want all the services available. Some can be wasted overhead, or even counterproductive in

* Connection-Oriented. This is normally easier to deal with than connection-less models, so where the Network layer only provides a connection-less service, often a connection-oriented service is built on top of that in the Transport layer.
* Same Order Delivery. The Network layer doesn't generally guarantee that packets of data will arrive in the same order that they were sent, but often this is a desirable feature, so the Transport layer provides it. The simplest way of doing this is to give each packet a number, and allow the receiver to reorder the packets.
* Error 'Free' Data. The underlying network may well be noisy, and the data received may not always be the same as the data sent. The Transport layer can fix this: typically by providing a checksum of the data which detects if there has been a glitch of some kind. Of course, error free is impossible, but it is possible to substantially reduce the numbers of undetected errors. This layer may also retransmit packets which have gone missing en route.
* Flow Control. The amount of memory on a computer is limited, and without flow control a larger computer might flood a computer with so much information that it can't hold it all before dealing with it. Nowadays, this is not a big issue, as memory is cheap while bandwidth is comparatively expensive, but in earlier times it was more important. Flow control allows the receiver to say "Whoa!" before it is overwhelmed. Sometimes this is already provided by the network, but where it is not, the Transport layer may add it on.
* Byte Orientation. Rather than dealing with things on a packet-by-packet basis, the Transport layer may add the ability to view communication just as a stream of bytes. This is nicer to deal with.
* Ports. Ports are essentially ways to address multiple entities in the same location. For example, the first line of a postal address is a kind of port, and distinguishes between different occupants of the same house. Computer applications will each listen for information on their own ports, which is why you can use more than one network-based application at the same time.

On the internet there are a variety of Transport services, but the two most common are TCP and UDP. TCP is the more complicated, providing a connection and byte oriented stream which is almost error free, with flow control, multiple ports, and same order delivery. UDP is a very simple 'datagram' service, which provides limited error reduction and multiple ports. TCP stands for Transmission Control Protocol, while UDP stands for User Datagram Protocol.

Some things, such as connection orientation can be implemented at either Transport or Network layer. The idea is that the Network layer implements whatever set of options is easiest: for some underlying networks it is easiest to implement connectionless communication, while for others it is easiest to implement connection oriented communication. The Transport layer uses this simplest set of options to implement whatever combinations of options are actually desired

 

Network layer

The network layer is level three of the seven level OSI model. It responds to service requests from the transport layer and issues service requests to the data link layer.

The network layer addresses messages and translates logical addresses and names into physical addresses. It also determines the route from the source to the destination computer and manages traffic problems, such as switching, routing, and controlling the congestion of data packets.

The network layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service requested by the Transport layer. The Network layer performs network routing, flow control, network segmentation/desegmentation, and error control functions.

The network layer deals with transmitting information all the way from its source to its destination - and transmitting things from anywhere you like, to anywhere you like. If you can't contact a place at the network layer, then you can't contact that place at all. However, it does it in a very basic way, without error detection or flow control, or anything else. Here are some things that the network layer needs to address:

* Is the network connection-oriented or connectionless? For example, snail mail is connectionless, because you can send a letter to someone without them doing anything and they will receive the letter. On the other hand, the telephone system is connection-oriented, because the other party has to pick up the phone before you can talk to them.
* What are the Global Addresses? Everybody in the network needs to have a unique address which determines who they are. This address will normally be hierarchical, so you can be "Fred Murphy" to Dubliners, or "Fred Murphy, Dublin" to people in Ireland, or "Fred Murphy, Dublin, Ireland" to people anywhere in the world. On the internet, these addresses are known as IP Numbers.
* How do you forward a message? This is of particular interest to mobile applications, where a user may rapidly move from place to place, and it must be arranged that his messages follow him. Version 4 of the Internet Protocol (IPv4) doesn't really allow for this, though it has been hacked somewhat since its inception. Fortunately, the forthcoming IPv6 has a much better designed solution, which should make these kinds of applications much smoother.

In the traditional postage system (commonly referred to as snail mail) this role is provided by the postman (to some extent).

 

Data link layer

The data link layer is level two of the seven-level OSI model. It responds to service requests from the network layer and issues service requests to the physical layer.

The data link layer is the layer of the model which ensures that data is transferred correctly between adjacent network nodes in a wide area network. The data link layer provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the Physical layer. Examples of data link protocols are Ethernet for local area networks and PPP, HDLC and ADCCP for point-to-point connections.

The data link is all about getting information from one place to a selection of other places. At this layer one does not need to be able to go everywhere, just able to go somewhere else. So in social contact, one needs to know at least one other person, but not necessarily know Fred Jones of Ohio, USA.

This layer is made up of two components. The first component is Logical Link Control. This component determines where one frame of data ends and the next one starts. In a snail-mail network, each letter is one frame of data, and you can tell where it begins and ends because it is inside an envelope. You might also specify that a letter will begin with a phrase like "Dear Sir", and ends with a phrase like "Yours Sincerely".

The second component is Media Access Control. This component determines who is allowed to access the media at any one time. There are generally two forms of media access control: distributed and centralised. Both of these may be compared to communication between people:

* In a network made up of people speaking, i.e. a conversation, we look for clues from our fellow talkers to see if any of them appear to be about to speak. If two people speak at the same time, they will back off and begin a long and elaborate game of saying "no, you first".
* In the UK Houses of Parliament, the speaker determines who can speak at any time and gets to say "order" very loudly if anybody breaks the rules.

 

Physical layer

The physical layer is level one in the seven level OSI model of computer networking. It performs services requested by the data link layer.

This level refers to network hardware, physical cabling or a wireless electromagnetic connection. It also deals with electrical specifications, collision control and other low-level functions.

The physical layer is the most basic network layer, providing only the means of transmitting raw bits. The shapes of the electrical connectors, what frequencies to broadcast at, and similar low-level things are specified here. An analogy of this layer in a physical mail network would be a specification for various kinds of paper and ink, for example.

The major functions and services performed by the physical layer are:

* establishment and termination of a connection to a communications medium;
* participation in the process whereby the communication resources are effectively shared among multiple users, e.g., contention resolution and flow control;
* conversion between the representation of digital data in user equipment and the corresponding signals transmitted over a communications channel.

IPV4

IPv4 is version 4 of the Internet Protocol (IP). It was the first version of the Internet Protocol to be widely deployed, and forms the basis for most of the current Internet (as of 2004).

It is described in IETF RFC 791, which was first published in September, 1981.

IPv4 uses 32-bit addresses, limiting it to 4,294,967,296 unique addresses, many of which are reserved for special purposes such as local networks or multicast addresses, reducing the number of addresses that can be allocated as public Internet addresses.

As the number of addresses available is consumed, an IPv4 address shortage appears to be inevitable in the long run.

This limitation has helped stimulate the push towards IPv6, which is currently in the early stages of deployment, and may eventually replace IPv4.

IPv4 address representations

IPv4 addresses are usually written in Dot-decimal notation. Here is an example: 207.142.131.235. But it is also possible to write in the following formats:

Dotted Decimal (normal) 207.142.131.235
Dotted Hexadecimal 0xCF.0x8E.0x83.0xEB
Dotted Octal 0317.0216.0203.0353
Decimal 3482223595
Hexadecimal 0xCF8E83EB

The above IP addresses should work in most browsers and at the time of writing point to wikipedia.org.

IPv4 header format

+	Bits 0 - 3				4 - 7				8 - 15								16 - 18			19 - 31
0	Version				Header length				Type of Service (now DiffServ and ECN)								Total Length
32	Identification																Flags			Fragment Offset
64	Time to Live								Protocol								Header Checksum
96	Source Address
128	Destination Address
160	Options
192	Data

The first header field in an IPv4 packet is the 4-bit version field.

The second field is a 4-bit Internet Header Length (IHL) telling the number of 32-bit words in the IPv4 header. Since an IPv4 header may contain a variable number of options, this field essentially specifies the offset to the data portion of an IPv4 datagram. A minimum IPv4 header is 20 bytes long, so the minimum value in decimal in the IHL field would be 5 (5×4 = 20 bytes). That is, it represents the total number of bytes occupied by header as a multiple of 4 bytes.

In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field - now DiffServ and ECN. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one host could set its IPv4 datagrams' ToS field value to prefer low delay, while another might prefer high reliability. In practice, the ToS field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined and most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168).

The next 16-bit IPv4 field defines the entire datagram size, including header and data, in 8-bit bytes. The minimum-length datagram is 20 bytes and the maximum is 65535. The maximum size datagram which any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 (see below).

The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet tracing information to datagrams in order to help trace back datagrams with spoofed source addresses.

A 3-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):

* Reserved, must be zero
* Don't Fragment (if set)
* More Fragments.

The fragment offset field is 13-bits long, and allows a receiver to determine the place of a particular fragment in the original IP datagram, measured in units of 8-byte blocks.

An 8-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internetwork. Historically the TTL field limited a datagram's lifetime in seconds, but has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded.

An 8-bit Protocol field follows. This field defines the next protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers. Common protocols and their decimal values include ICMP (1), TCP (6) and UDP (17).

The following field is a 16-bit checksum field for the IPv4 datagram header. Some values in a IPv4 datagram header may change at each packet switch hop, so the checksum must be adjusted on its way through an internetwork.

The checksum is followed by a 32-bit source address and 32-bit destination address respectively.

Additional header fields (called options) may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header.

The use of the LSSR and SSRR (Loose and Strict Source and Record Route) options is discouraged because they create security concerns; packets with them are therefore usually blocked by routers.

Fragmentation and reassembly

IPv4 supports the use of network elements (e.g. point-point links) which support small packet sizes. Rather than mandate link-local fragmentation and reassembly, which would require the router at the far end of the link to collect the separate pieces and reassemble the packet (a complicated process, especially when pieces may be lost due to errors on the link), a router which discovers that a packet which it is processing is too big to fit on the next link is allowed to break it into fragments (separate IPv4 packets which each carry part of the data in the original IPv4 packet), using a standardized procedure which allows the destination host to reassemble the packet from the fragments, after they are separately received there.

When a large IPv4 packet is split up into smaller fragments (which is usually, but not always, done at a router in the middle of the path from the source to the destination), the fragments are all normal IPv4 packets; i.e. they have a full IPv4 header. The original packet's data portion is split into segments which are small enough (when appended to the requisite IPv4 header) to fit into the next link; one segment of the original data is placed in each fragment. Almost all the header fields have the same value in them as the corresponding field in the original packet. In particular, all the fragments will have the same "identification" field value. The differences are:

* The "total length" field will be smaller; it will be set to the size of each fragment
* The "more fragments" single bit flag will be one in all but the last fragment
* The "fragment offset" field will be non-zero in all but the first fragment

Note that at the destination, in any incoming packet, if either:

* The "more fragments" single bit flag is one, or
* The "fragment offset" field is non-zero

that packet is a fragment.

To reassemble the fragments back into the original packet at the destination, the host looks for incoming packets with the same value in the identification field: they all belong to the same original packet. The offset and total length fields tell it where each piece goes, and how much of the original packet it fills in. It can work out the total size of the original packet because in the packet with the "more fragments" flag clear, the value of the size field in that packet (less the length of the IPv4 header, of course), plus the value in the offset field (multiplied by the 8-byte fragmentation block size), gives the total length of the original packet.

Note that a router can repeat the fragmentation process even if it only has a single fragment (e.g. at a later router along the path) - it takes the fragment, splits it up in the same manner as above to create two (or more) new fragments, and adjusts the offset and total length fields as appropriate. The only complication is that if the "more fragments" flag was zero, it needs to set it to one in all but the last new fragment. (It is relatively simple to set up the process so that the router does not need to know whether the packet it is fragmenting is itself a fragment, or a complete packet.)

Note also that if a packet is fragmented, and some of the fragments were lost while sending them from the source to the destination, then if it is retransmitted with the same identification number, and this second copy is also fragmented (again, potentially with the loss of some fragments), then fragments from the second copy can be used to fill in the "blank spots" from the first one.

 

IPV6

 

IPv6, or Internet Protocol version 6, is a network layer standard; i.e., it governs the addressing and routing of data packets through a network.

IPv6 is intended to replace the IPv4 standard, whose limits on network addresses are beginning to restrict Internet growth and use, especially in China, India, and other heavily populated Asian countries. But the new standard will improve service all around the globe; for example, by providing future cell phones and mobile devices with their own unique and permanent addresses.

IPv4 supports about 4 billion (4 × 109) addresses, while IPv6 supports about 3.4 × 1038 (340 undecillion) addresses -- about 4.3 × 1020 (430 quintillion) addresses per square inch (6.7 × 1017 (670 quadrillion) addresses/mm²) of the Earth's surface.

Adopted by the Internet Engineering Task Force in 1994 (when it was called "IP Next Generation" or IPng), IPv6 accounts so far for just a few percent [1] (http://bgp.potaroo.net/index-v6.html) of the addresses in the publicly-accessible Internet, which is still dominated by IPv4 [2] (http://bgp.potaroo.net/index-bgp.html). The adoption of IPv6 has been slowed by the introduction of network address translation (NAT), which partially alleviates the problem of address exhaustion. But NAT makes it difficult or impossible to use some peer-to-peer applications, such as VoIP and multi-user games. Currently, the big drive for IPv6 is new uses, such as mobility, quality of service, privacy extension and so on. The U.S. Department of Defense has also specified that all of its networked devices use the IPv6 standard by 2010.

It is expected that IPv4 will be supported until at least 2025, to allow time for bugs and system errors to be corrected.

IPv6 is the second version of the Internet Protocol to be formally adopted for general use. (There was also an IPv5, but it was not a successor to IPv4; rather, it was an experimental flow-oriented streaming protocol, intended to support voice, video, and audio.)

IPv6 addressing

The most dramatic change from IPv4 to IPv6 is the length of network addresses. IPv6 addresses, as defined by RFC 2373 and RFC 2374, are 128 bits long; this corresponds to 32 hexadecimal digits, which are normally used when writing IPv6 addresses, as described in the following section.

The number of possible addresses in IPv6 is 2128 ˜ 3.4 x 1038. The number of IPv6 addresses can also be thought of as 1632 as each of the 32 hexadecimal digits can take 16 values (see combinatorics).

In many situations, IPv6 addresses are composed of two logical parts: a 64-bit network prefix, and a 64-bit host-addressing part, which is often automatically generated from the interface MAC address.

It is often argued that 128-bit addresses are overkill, and that the Internet will never need that many. It should be noted that the rationale for the 128-bit address space is not primarily to make sure that addresses never run out, but rather to ensure that routing can be handled smoothly by keeping the address space unfragmented, rather than as the current situation is with IPv4, where a great number of discrete netblocks can be, and often are, assigned to one organization.

Notation for IPv6 addresses

IPv6 addresses, which are 128 bits long, are normally written as eight groups of four hexadecimal digits.

For example,

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

is a valid IPv6 address.

If a four-digit group is 0000, it may be omitted. For example,

2001:0db8:85a3:0000:1319:8a2e:0370:7344

is the same IPv6 address as

2001:0db8:85a3::1319:8a2e:0370:7344

Following this rule, if more than two consecutive colons result from this omission, they may be reduced to two colons, as long as there is only one group of two or more consecutive colons. Thus

2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab

are all valid and mean the same thing, but

2001::25de::cade

is invalid because it is not clear how many 0000 groups are on each side.

Leading zeros in a group can be omitted. Thus

2001:0DB8:02de::0e13

is the same thing as

2001:DB8:2de::e13

If the address is an IPv4 address in disguise, the last 32 bits may be written in decimal; thus

::ffff:192.168.89.9 is the same as ::ffff:c0a8:5909, but not the same as ::192.168.89.9 or ::c0a8:5909.

The ::ffff:1.2.3.4 format is called an IPv4-mapped address. The ::1.2.3.4 format is an IPv4-compatible address.

IPv4 addresses are easily converted to IPv6 format. For instance, if the decimal IPv4 address was 135.75.43.52 (in hexadecimal, 0x874B2B34), it could be converted to 0000:0000:0000:0000:0000:0000:874B:2B34 or ::874B:2B34. Then again, one could use the hybrid notation (IPv4-compatible address), in which case the address would be ::135.75.43.52. These IPv4-compatible addresses are being deprecated, because IPv6 transition mechanisms no longer use them. The respective RFCs will reflect this shortly.

Special addresses

There are a number of addresses with special meaning in IPv6. This is a brief table of these, in CIDR notation.

* ::/128 – the address with all zeroes is used to specify any address, and is only to be used in software.
* ::1/128 – the loopback address is a host-local address which echoes back all the packets sent to it (corresponding to 127.0.0.1 in IPv4).
* ::/96 – The IPv4-compatible address is used as a transition mechanism in dual IPv4/IPv6 networks.
* ::ffff/96 – The IPv4-mapped address is used as a transition mechanism in dual-stack hosts.
* fe80::/10 – The link-local prefix specifies that the address only is valid in the local physical link.
* fec0::/10 – The site-local prefix specifies that the address only is valid inside the local organization. Its use has been deprecated in September 2004 by RFC 3879 and future systems must not implement any support for this special type of address anymore.
* ff00::/8 – The multicast prefix is used for multicast addresses.

IPv6 packet
The structure of an IPv6 packet header.
Enlarge
The structure of an IPv6 packet header.

The IPv6 packet is composed of two main parts: the header and the payload.

The header is in the first 40 bytes of the packet and contains both source and destination addresses (128 bits each), as well as the version (4-bit IP version), traffic class (8 bits, Packet Priority), flow label (20 bits, QoS management), payload length (16 bits), next header (8 bits), and hop limit (8 bits, time to live). Next comes the payload, which can be up to 64k in size in standard mode, or larger with a "jumbo payload" option.

There have been two slightly different versions of IPv6. The now-obsolete initial version, described in RFC 1883, differs from the current proposed standard version, described in RFC 2460, in two fields: 4 bits have been reassigned from flow label to traffic class. All other differences are minor.

Fragmentation is handled in the host only in IPv6. In IPv6, options also move out of the standard header and are specified by the Next Header field, similar in function to IPv4's Protocol field. A handwaving example: in IPv4 one would add a Strict Source and Record Routing (SSRR) option to the IPv4 header itself in order to enforce a certain route for the packet, but in IPv6 one would make the Next Header field indicate that a Routing header comes next. The Routing header would then specify the additional routing information for the packet, and then indicate that the, for example, TCP header comes next. This is analogous to the handling of AH and ESP in IPSec for IPv4 (which applies to IPv6 as well, of course).

IPv6 and the Domain Name System

IPv6 addresses are represented in the Domain Name System by AAAA records (so-called quad-A records) for forward lookups (by analogy with A records for IPv4); reverse lookups take place under ip6.arpa (previously ip6.int), where address space is delegated on nibble boundaries. This scheme is defined in RFC 3596.

The AAAA scheme was one of two proposals at the time the IPv6 architecture was being designed. The other proposal would have had A6 records for the forward lookup and a number of other innovations such as bit-string labels and DNAME records. It is defined in the experimental RFC 2874 and its references.

While the AAAA scheme is a simple generalisation of the IPv4 DNS, the A6 scheme was an overhaul of the DNS to be more general, and hence more complex:

* A6 records allowed a single IPv6 address to be broken across several records, perhaps held in different zones; this allowed in principle for rapid renumbering of networks, for example.
* Address delegation by use of NS records was largely replaced with DNAME records (analogous to the existing CNAME but renaming an entire tree). This permitted related forward and reverse components to be managed together.
* A new data type called the bit label was introduced to domain names, primarily for reverse lookups.

The AAAA scheme was effectively standardized on in August 2002 by RFC 3363 (with further discussion of the pros and cons of both schemes in RFC 3364).

IPv6 deployment

On 20 July 2004 ICANN announced[3] (http://icann.org/announcements/announcement-20jul04.htm) that the root DNS servers for the Internet had been modified to support both IPv6 and IPv4.

Disadvantages:

* the need for roll out of pervasive support for IPv6 throughout the Internet and its connected devices
* to be reachable from the IPv4 universe during the transition phase, you still need an IPv4-address or some kind of NAT (=shared IP-address) in the gateway routers (IPv6<-->IPv4) which adds complexity there and means the large address space promised by the specification can't be immediately used effectively.
* remaining architectural problems, such as the lack of agreement for proper support for IPv6 multihoming.
* 6bone
* ICMPv6

Transition mechanisms

Until IPv6 native connectivity becomes widely available and supported by the routing infrastructure, it is necessary to use transition mechanisms to tunnel IPv6 through IPv4 networks. That can be achieved with:

* configured static IPv6-in-IP tunnels between two dual-stack nodes, or
* 6to4, which is an automatic and asymmetric tunnel mechanism.

These tunnels work by encapsulating IPv6 packets into IPv4 packets with IP next-layer protocol number 41, hence the name proto-41. Similarly, ISATAP allows the transmission of IPv6 packets through an internal IPv4-only networking infrastructure. It also uses protocol number 41.

When IPv6 connectivity is desired from behind a NAT device, many of which do not forward proto-41 packets properly, one may use the Teredo protocol which encapsulates IPv6 over UDP over IPv4. It is also possible to use IPv6-to-IPv4 and IPv6-to-IPv6 proxies, though that is typically application-layer specific (eg. HTTP).

Major IPv6 announcements

* In 2003, Nihon Keizai Shimbun (as cited in CNET Asia Staff, 2003) reported that Japan, China, and South Korea claimed to have made themselves determined to become the leading nations in internet technology, which would partially take the form of jointly developing IPv6, and completely adopting IPv6 starting in 2005.
* ICANN announced on 20 July 2004 that the IPv6 AAAA records for the Japan (.jp) and Korea (.kr) country code Top Level Domain (ccTLD) nameservers became visible in the DNS root server zone files with serial number 2004072000. The IPv6 records for France (.fr) were added a little later. This made IPv6 operational in a public fashion.

 

Information obtained from the following Sources:

http://www.answers.com

For Further reference the following sites contain detailed references:

http://www.tcpipguide.com/free/

http://www.answers.com

http://www.wisegeek.com/what-is-ip-or-internet-protocol.htm

http://www.rfc-editor.org/rfcxx00.html

 

Back