IPv6 Essentials 266
Carla Schroder writes "IPv6 is halfway here, so network administrators need to learn their way around it whether they want to or not. Adoption has been slower in the United States because we possess the lion's share of IPv4 addresses, but even so, someday IPv4 is going away for good. And, there is more to it than just increasing the pool of available addresses. IPv6 has enough improvements over IPv4 to make it worth the change even if we weren't running out of IPV4 addresses, such as built-in IPSec, simplified routing and administration, and scalability that IPv4 simply can't support. We're moving into gigabyte and multi-gigabyte backbones, and high-demand real-time services like voice-over-IP and streaming audio and video that require sophisticated QoS (quality of service) and bandwidth prioritization. IPv6 can handle these, IPv4 can't." Read on for the rest of Carla's review.
| IPv6 Essentials, 2nd Edition | |
| author | Silvia Hagen |
| pages | 436 |
| publisher | O'Reilly Media, Inc. |
| rating | 10 |
| reviewer | Carla Schroder |
| ISBN | 0-596-10058-2 |
| summary | practical, in-depth guide to implementing and administering IPv6 |
IPv6 Essentials, 2nd edition, by Silvia Hagen, released in May 2006, is a well-written, clear, up-to-date guide to understanding IPv6 in-depth. This is a real accomplishment, because computer networking protocols are completely abstract, and translating all of these abstractions into understandable language is a noteworthy feat. The book explains how it all works to a very practical depth, so that the reader will be well-prepared to begin implementation.
What it does not cover is the specifics of configuring network devices, such as routers, switches, and interface cards, and this is not a flaw, because those things are platform- and vendor-dependent. Having a solid understanding of the protocol itself is more important, and something that is sadly lacking even in today's IPv4 world. The Internet would be a better place if more network admins would take the time to learn IP fundamentals.
Ms. Hagen does a nice job of covering the following topics: Strengths and advantages, such as auto-configuration, and good-bye to NAT, The structure of the protocol itself, including header format, Improved security, Real genuine QoS, Simplified routing, Co-existence with IPv4, Painless mobile networking, and Addressing. Addressing is one of the scariest parts. When you're used to slinging around something like 192.168.1.100 with ease, coming eye-to-eye with something like this, 3ffe:ffff:1001:0000:2300:6eff:fe04:d9ff, is a bit disconcerting.
But fear not, for Ms. Hagen dissects IPv6 addresses clearly and in detail, showing that they have a logical, consistent, understandable structure. For example, the first quad (3ffe) tells you that this is a 6bone.net address, so it is already obsolete because the 6bone closed down in June 2006. Other prefixes tell you if it is a private address, link-local, site-local, and so on. The book lays this all out in tables, and explains what each one is for.
How would you like to retire your DHCP servers permanently? No problem. IPv6 auto-configures hosts all by itself, or you may exercise as much control as you like. Ms. Hagen explains the various options- link-local, site-local, stateful, stateless, neighbor discovery, and so forth, and what you can do with them. For example, with IPv6 you can whip up an ad-hoc LAN with hardly any effort, and without needing special servers or client software.
Security is built-in to IPv6, instead of bolted-on as it is for IPv4. However, IPSec (IP Security) is still largely untested and unproven on a number of levels, so the book discusses both the pros and cons.
The book covers the problems, hassles, and compromises that come with using NAT (network address translation). We're used to it now, but sometime down the road we're going to look back and think "Wow, that was one big fat pain. Good thing it's gone."
The chapter on Mobile IPv6 is almost worth the price of the book by itself. IPv6 supports both wired and wireless mobile users in an elegant, hassle-free way. Say good-bye to setting up multiple profiles, or hassling with scripts. Roaming users can keep the same IP as they travel — across different networks, wired to wireless- anywhere they go. This little bit of magic occurs because IPv6 assigns them multiple IPs. One is the home address, which is permanent. A second address is the care-of address, which changes as the user moves around. Of course there is a lot more to it that just having multiple addresses, and like everything else in this book, Ms. Hagen explains how it works clearly and understandably.
The book is abundantly illustrated in the usual quality O'Reilly fashion, and the illustrations are invaluable for understanding the material.
We're at the stage where IPv6 support is pretty much universal- you can count on both network hardware and software supporting it. So the network administrator only needs to focus on learning the ins and outs of implementation. I recommend IPv6 Essentials as an essential reference, and a great starting point for mastering IPv6.
You can purchase IPv6 Essentials, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Update on the link (Score:0, Interesting)
Re:QoS (Quality of Service or crap for customers?) (Score:2, Interesting)
That being said, we were a local area ISP. Now for big providers, as long as you pay for it (and the service contract covers it), you should receive your bandwidth, IMHO; I do agree that they probably do the same thing in order to conserve bandwidth and the allmighty dollar. Otherwise, if they don't limit UserA's bandwidth (along with probably UserB, C and D), you, being UserZ, wouldn't be able to get much done in a day.
I think QoS comes more into play within the corporate intranet where you have video conferencing, etc, like we do at my current job. Besides, you don't have to use different (or even the same ISP) to connect 2 sites; you can always get (or make) your own private link.
NAT is the IPv4 version of segmented memory (Score:5, Interesting)
Back in the day, the 8080 architecture had 16-bit addresses, which limited you to 64 KB of memory. The 8086 used segement registers to allow 16-bit registers to address up to 1 MB of memory. But data structures were still limited to 64 KB unless you were willing to slow down your access time by a factor of four or more, and sharing data between code running in different segments required even more jumping through hoops. NAT allows more devices than IPv4 can address to communicate with central servers that aren't running NAT, but setting up P2P between systems that are both using NAT is damn near impossible.
Good-bye, IPv4, and good riddance.
Save yourself $7.65 by buying the book here!! (Score:0, Interesting)
No thanks (Score:2, Interesting)
IPv6 is halfway here
In other words, it's not here. Just as always.
so network administrators need to learn their way around it whether they want to or not.
I'm a system and network admin and I haven't needed to learn my way "around" it. Unless by that you mean, to "turn it off whenever possible". Which I do. Just upgraded some FreeBSD machines and made sure all the IPv6 stuff wasn't built.
Adoption has been slower in the United States because we possess the lion's share of IPv4 addresses, but even so, someday IPv4 is going away for good.
No, adoption is slower because IT SOLVES NO PROBLEM. Do you know how many customers we've had ask about IPv6? Exactly one. Because he read a post on slashdot like this one and wanted to know "if it was something he needed to know about". Guess what answer he got?
IPv6 has enough improvements over IPv4 to make it worth the change even if we weren't running out of IPV4 addresses
No, there is only one reason to switch to IPv6: if the sites you want to reach aren't on IPv4 any more. I assume since you are posting to slashdot (IPv4) you agree with me. (By "switch" I mean STOP using IPv4 completely. Otherwise you haven't "switched").
I'm going to treat IPv6 the same way I always have: as a sort of intellectual curiosity, and not something that affects my day-to-day internet use or professional responsibilities.
Re:QoS (Quality of Service or crap for customers?) (Score:3, Interesting)
By that same argument, I could tunnel WoW data instead of audio data from a VoIP IP number and do the same thing. Either you trust that the data you think should be high priority actually should be or you don't. You can't have it both ways.
In the end, you have to trust that the kernel in commercial OSes will set reasonable packet priorities for different types of traffic. While there might be occasional people who find ways to abuse this, the only alternative to this trust is to not do any QoS at all. Restricting QoS to a certain IP range is just playing into the hands of those who would make internet telephony a private, for-pay exchange. It should not be.
One of the greatest features of the Internet is that it levels the playing field and allows for free communication around the world. Let's not take a giant step backwards just because a handful of jerks are going to hack their kernel to mark their WoW traffic as "needs real-time". That isn't in anyone's best interest.
Re:QoS (Quality of Service or crap for customers?) (Score:3, Interesting)
Just a question, since you're on the inside. How feasible would it be to allow the customer to specify, say, 1% to 5% of their total bandwidth as QoS packets by setting the QoS flags in the IP header? That way they could use any service they wanted, whether it be Skype, bittorrent, email, or ssh and have their packets delivered faster. By only giving them a fraction of their total bandwidth available for QoS, you prevent download hogs from wasting QoS traffic for other users and avoid having to set up QoS specifically for each customer's application. The other idea I've had was to simply base QoS on the average amount of traffic from a given subscriber, so that a customer using VoIP, email, ssh, etc. would only use a small amount of bandwidth and thus have a higher priority than someone sucking down torrents as fast as they can.