Networking

IPv6: What is Internet Protocol?

The members have spoken, advising that a high-level peek at the underlying principles of Internet Protocol would be a good jumping-off point. After which we can forge ahead, starting the IPv6 discussion.

Internet Protocol (IP) is one of many communications protocols that compose the Internet Protocol Suite (IPS) and is arguably the most important protocol. Experts usually describe IPS as a stack of protocols that convert application information (like e-mail or Web traffic) into digital packets capable of traversing networks, including the Internet.

Specifically, IP is responsible for transmitting the digital packets from a source host to a destination host over a network connection. The Request for Comment (RFC) 791 is the last word about IP and provides the following definition:

"The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service."

Packets and datagrams: Is there a difference?

When discussing IP, many people (including me) interchange the terms packet and datagram as both terms have similar (identical, some argue) definitions. RFC 1594 defines a datagram/packet as:

"A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between the source and destination computer and the transporting network."

Since they're the same, why worry about definitions? Well, sometimes experts define packets differently from datagrams, and that's when it gets confusing. They use the term packet when discussing reliable data transmission protocols such as TCP/IP, and then use the term datagram when talking about best-effort data transmission protocols like UDP. For our discussion of IP, it doesn't matter which term is used, but I'd like to stick with datagram (you'll see why in a moment).

IP attributes

IP has several attributes that define how data is transmitted, and they're important regardless of whether we're discussing IPv4 or IPv6. So, let's take a look at them:

  • Host addressing: IP defines the addressing scheme for each host on the network and uses the addresses to facilitate datagram delivery.
  • Protocol independence: IP by design is able to work with any type of underlying network protocol using protocol stack technology.
  • Connectionless delivery: IP does not set up a relationship between the sending host and the receiving host. The sending host just creates datagrams and sends them on their way.
  • Best-effort delivery: IP tries its best to ensure that the receiving host actually gets the datagrams addressed to it, but there are no guarantees.
  • No provision for delivery acknowledgments: The receiving host does not acknowledge the fact that it indeed did receive the data addressed to it.

One wonders how IP datagrams get where they're supposed to, when the last three attributes create less than a perfect environment. Why leave those features out of the protocol? The simple reason is better performance. Using established connections, error-checking, and guaranteed delivery require additional processing power and network bandwidth. So if the datagram being transmitted does not require certain attributes, it's better they aren't used. Besides, the people who developed IP are a smart bunch, designing a more efficient approach that uses protocol stacking.

Protocol or TCP/IP stack

If you recall, I mentioned something called a protocol stack (officially TCP/IP) earlier. If the type of transmitted data (such as e-mail) requires guaranteed delivery, receipt acknowledgment, or an official connection handshake, the information is appended earlier in the datagram-building process, or what is called "further up the stack." It turns out to be good solution, especially since it conserves network resources.

On a side note, I debated whether to include information about the TCP/IP stack in this discussion, as we're supposed to be focused on IP. The only problem is that it's very hard to divorce TCP from IP. Especially since a large percentage of datagrams include TCP information.

TCP/IP Guide has an excellent explanation of what a TCP/IP stack is and how it works. The process of encapsulation (ultimately why I included this information) also takes place in the TCP/IP stack. Encapsulation is where the next protocol in the stack encapsulates the datagram, giving it additional information that's required, so the packet can successfully reach its destination. The following diagram (courtesy of TCP/IP Guide) depicts the encapsulation process:

ip-encap.png

IP datagram format

To get a better understanding of what (besides data) is sent in a datagram, we need to look at the datagram's format. The following diagram (courtesy of TCP/IP Guide) shows all the various fields of an IPv4 datagram. For more information about each field in the datagram, please refer to this TCP/IP Guide link.

ipv4format.png

As a point of comparison, the next diagram (courtesy of TCP/IP Guide) is the IPv6 datagram format. Once again, for more information about the individual fields, please refer to this TCP/IP Guide link.

ipv6format.png

It's interesting how the IPv6 datagram format is consolidated and actually makes more sense. For example, changing the TTL field to hop limit is a much better description.

Next time

In this article, I tried to point out the commonalities shared by IPv4 and IPv6, with the exception of the datagram formats. The rest of the series will deal with IPv6, the differences between it and IPv4, and why IPv4 needs to be phased out. If everything works out, the next edition will be a podcast with Mr. Joe Klein, senior security researcher for Command Information and a member of the North American IPv6 Task Force. He'll be discussing why IPv4 is on its last legs.

Final thoughts

I first wanted to thank everyone for all the useful comments and suggestions in my previous article, "IPv6: Where to Begin." This article is the direct result of those comments. Besides, truth be told, I needed a starting point, and a high-level review seemed like a good idea. I hope you agree; now we can move the discussion to IPv6 and all its nuances.

I also wanted to make mention of the Web site TCP/IP Guide. It's written and maintained by Mr. Charles M. Kozierok and, in my world, is one of the best resources for anything dealing with TCP/IP.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

55 comments
seanferd
seanferd

I think it would be popular. Even an omnibus version with all the articles rolled into one. Edit: Maybe including a transcript or bundled/embedded version of the relevant podcasts?

mikifinaz1
mikifinaz1

Should be setup as a PDF download.

steve6375
steve6375

OK - so it has happened again! Why did we decide that 128 bits is more than we can ever possibly need? Why did they assume that that is more than the number of people times the number of devices owned so it must be more than enough? Lets turn this on its head - assume that every electronic device ever made will have it's own unique IP address. Now assume that each manufacturer will be issued a range of IP addresses (as he will have to allocate unique IP addresses to each device he makes). So we have how many millions of devices being made by hundreds of thousands of manufacturers every year with millions of 'ranges' needing to be reserved for each manufacturer and model. Now consider that each device has a limited lifetime, etc. etc. Now consider nano-technology and how we will address the millions of these tiny devices. Now consider how many planets we will expand into in the next few hundred years and how many space colonies we will have... My point is why was 128 bits considered 'ample' when time and time again, history has shown that we never choose a big enough number when defining standards? Isn't that what was thought when the ipv4 standard was defined? Why didn't we choose say 256 bits? What is a few bytes compared with the pain of revising a standard? Will we never learn!

gurudev_sajwan
gurudev_sajwan

Hi This is really a good starting. Please keep it up.

Dumphrey
Dumphrey

and as always, worth the read. I look forward to the next installment. I would LOVE to hear some podcasts with the ARIN people if you can pull that off.

edmicman1
edmicman1

Nice background info! I'll throw out a question then - where do I go from here and what do I do? What should I do? What can I do? As a home user with cable internet (local cable co, not a big guy like Comcast) with WinXP and Ubuntu machines, as well as Internet connected devices like a Wii, all going through a WRT54G router, what should I be doing? As a business user who is "sort of" in charge of our small business network, what should I be doing? We have a T1 through AT&T, and a Windows network. What should I be doing, if anything? The IPv6 sounds great, and I'd love to take advantage of some things. But I just don't know where to start!

letter_2_roy
letter_2_roy

Hi ! Dear Sir/Madam, With due respect, I am acknowledging that this is very important for near future for networking because IPv4 range is getting finished. with thanks & regards, Swapan.

john.johnson
john.johnson

I appreciate your cogent efforts in such a compact space and look forward to reading further editions of upcoming articles.

laman
laman

It has "IPv6" in the title but very very little about IPv6 in the article. What a waste of my time to provide me the common knowledge most good IT Administrators already know.

nsotonye
nsotonye

very educative and informative article for the IT personnel. Thank you very much

seanferd
seanferd

Thanks for the refresher course. I wait for further articles with anticipation. Thanks Michael.

MGP2
MGP2

Michael, Thanks for taking the time to put together an informative series. If you're still open for suggestions, what would be great is if, when completed, it's offered as a TechRepublic Download. That way, people who come along later can get it all in one shot. Keep up the good work and thanks for keeping us informed. MGP

Michael Kassner
Michael Kassner

I'll comment on the 10+ thing article and link all of the articles and podcasts. I'll pass your request on to my editor as well. I think they do something like that. I seem to remember a download where they had all of the articles in my road warrior series.

Dumphrey
Dumphrey

be around in 20 years...

Michael Kassner
Michael Kassner

I'm working on it. You will have to promise to not laugh too hard at my poor attempts of being a noob interviewer.

Patrick Bowman
Patrick Bowman

This advice goes to everyone, not just Pete. Educating yourself is key. I recently wrote my Master's thesis on v6 transition and when I looked into the hows and whys, every single source stressed that educating interested parties was key. Depending on the organization, that may encompass as many as three or four levels - executive, network stakeholders, lower level IT staff, and general staff. Educating the right people properly will help your organization make better decisions regarding when and how to implement IPv6. That aside, picking the right training is important too. Books are OK, and reading blogs and articles like this series are helpful, but Classroom training, preferably w/ some sort of labs is better. At risk of sounding like a shill, I work for Command Information, "the premier provider of next generation networking services to Communication Providers, Fortune 1000 and government entities," so v6 is what we do. That includes training. There is an open enrollment "Building IPv6 Networks" class October 20-24 that is a good stepping off point. Info at this link: http://www.commandinformation.com/labs/catalogue/

Michael Kassner
Michael Kassner

I hope to cover most of what you are asking in the next several articles and pod casts. IPv6 is a very complex subject that I'm learning about as well. My goal is to explain IPv6 in terms that even I understand. I also want you to hold me to the task of answering your questions as all of them are very important. I hope that you will be patient though and please stay tuned.

Michael Kassner
Michael Kassner

I'm very interested in learning about IT professionals and how they have or how they plan to implement IPv6. If you have any thoughts, it would be great to hear about them.

Michael Kassner
Michael Kassner

Thank you very much, I was curious to learn what your plans were with regards to implementing IPv6? It's interesting to hear how IT professionals are going about it.

Michael Kassner
Michael Kassner

Are you considering the move to IPv6? I'd like to hear your thoughts about it. Also make sure to let me know what you'd like to see written about.

Gate keeper
Gate keeper

You obviously have never taught anything or attempted to explain a very complex technical concept to someone in great detail. you start from 1+1=2 and work your way up .. and before you know it .. you will be going "hold up, hold up run that by me again " 90% of the people reading this most likely already know what was posted but, Michael cannot afford to make assumptions. this is a great series and is really appreciated keep up the excellent work !

Neon Samurai
Neon Samurai

.. was there s subscription fee? A door cover for the privaledge of reading it? Did a large man in a suite show up at your office and force you do read it?.. no? Now, if you knew all that was presented in the article. Perhaps you might want to skim the next articles in the series until they catch up to your increadable level of omnipotence. The rest of us noobs will likely do the same and see what new information is increasingly offered as the author and TR is good enough to provide the information free of cost.

NickNielsen
NickNielsen

None of which ensure good reading comprehension. This is the article lead-in: [i]The members have spoken, advising that a high-level peek at the underlying principles of Internet Protocol would be a good jumping-off point. After which we can forge ahead, starting the IPv6 discussion.[/i]

Michael Kassner
Michael Kassner

If you read the lead-in to this article, I mentioned that this was going to be a review as requested by the members of TR. The series isn't close to being finished. I hope to even setup some pod casts interviewing members of the IPv6 task force and ARIN. I'm not sure if you would be interested, but the first article was IPv6: Where to begin? http://blogs.techrepublic.com.com/networking/?p=666 Finally, I'm sorry if you felt mislead, that certainly wasn't my intent.

nsotonye
nsotonye

A very educative and informative article for IT personnel. Thank you very much.

Michael Kassner
Michael Kassner

I'm glad you think it was OK. I was very unsure about how to start the series. I'm really excited about the experts I've been working with. There's absolutely no way I could have garnered all the information without their help. It's interesting, in that the more I learn the more I'm impressed with the work being done by the IPv6 work groups and task forces.

Michael Kassner
Michael Kassner

Thanks MGP, I'll see what the response is to the series and if the editors agree. I hope it turns out OK. I'm excited about getting several experts involved and their willingness to spend time with us.

seanferd
seanferd

I think it would be useful for a lot of people, and a bit more consistent in terms of publication. Some articles in a series are available as PDF, some aren't, and I occasionally wonder why. Another of life's wonderful mysteries, I suppose. :)

Dumphrey
Dumphrey

ME: Drink Coffee? Victim: Umm, Yes? Me: Is that my coffee your holding? Victim: Um, No? ME: LIES!

Neon Samurai
Neon Samurai

I'm limited to what information I can get locally on limited budget.

Dumphrey
Dumphrey

aspect to a certain point. Its not so much the classroom as the lab, hands on beats just reading every time. I am slowly building an lab at my house from old computers and (ancient =\) cisco gear. That being said, it is good to have access to someone that knows the material in depth. Some times simple miss understanding can be avoided that way.

Patrick Bowman
Patrick Bowman

From a very nit-picky technical standpoint, your header diagrams are incorrect. They are 32 bits across, so they can be labeled 0-31 or 1-32, but 0-32 would be, as I said, "nit-picky-wise", technically inaccurate. EDIT: OK, I just noticed the watermark indicating that they are from the TCP/IP guide. So THEIR diagrams are inaccurate.

Neon Samurai
Neon Samurai

Word, Acrobat and copy/paste gives MS a happy smile.. (just be good to the TR folks and leave the author's name on the top)

Michael Kassner
Michael Kassner

I had a link for my Road Warrior series, but it's not available anymore. Strange.

Michael Kassner
Michael Kassner

Still, I'm nervous to be sure. It's amazing how Bill, Sonja and Jason are so good at it.

Neon Samurai
Neon Samurai

I figured it would have been posted clearly on the site if available. Educators have to eat too though. :)

Michael Kassner
Michael Kassner

I guess I see both sides of this debate. The teaching companies spend a great deal of time and money to setup the courses and need to recoup that in order to stay in existence. Yet, it's great PR to release the course notes to the public. I see IPv6 courses as a very high priority right now and the companies need to take advantage of that I guess.

Michael Kassner
Michael Kassner

The courses are a hot item now and only the people taking the course get the material.

Neon Samurai
Neon Samurai

.. and bless you for saying "Internet" instead of "Google".

Neon Samurai
Neon Samurai

I apreciate that. So far, it's been primarily personal interest (pretty heavy motivation for my particular mind set) but it will be very applicable outside of personal interest in the near future.

sandsdenver
sandsdenver

You always have our friend, the internet for all your course materials ;)

Michael Kassner
Michael Kassner

Neon, Peter is with the same company that Joe Klein is with and I'm already doing pod casts with him. I'll see what I can do to get Peter to help in that regard.

Michael Kassner
Michael Kassner

I emailed the author and hopefully it will be rectified.

Dumphrey
Dumphrey

when looking at packets.

Michael Kassner
Michael Kassner

That's can be important (especially if you are packet sniffing). Thank you for pointing the error out. I'll be mentioning that to TCP/IP Guide. To his credit, he constantly asks if there are any errors or omissions. I also apologize to the members for not catching that when I decided to use the diagram.