Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

IPv6 Essentials 266

Posted by samzenpus
from the we-fear-change dept.
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.
This discussion has been archived. No new comments can be posted.

IPv6 Essentials

Comments Filter:
  • by El Royo (907295) on Monday October 02, 2006 @03:07PM (#16282599) Homepage
    So, does that mean we're using IPv5 now?
  • by Bryansix (761547) on Monday October 02, 2006 @03:09PM (#16282623) Homepage
    Everytime I see QoS mentioned I get a little feeling that we are being had. Based on the needs of customers, VOIP and streaming video should be prioritized ahead of non-time-sensative packets. Yet you know ISP's actually prioritize in reverse. They actually put hardware in place that throttles VOIP and Streaming Video traffic. I wish I could give ISP's a good figurative slap on the back of the head!
    • Re: (Score:2, Funny)

      by manifoldronin (827401)
      I wish I could give ISP's a good figurative slap on the back of the head!
      So do I. And without the "figurative" part!
    • Re: (Score:2, Interesting)

      by Daemonstar (84116)
      Being a former network admin for a small ISP in Texas, throttling back on "bandwidth intensive" applications was pretty much a requirement. With low funds for backbone connections and having several wireless customers, just a few users could drain the entire uplink.

      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 b
      • by bigpat (158134)
        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.

        Unfortuneately, once you have effective QoS with differentiated services that will mean
    • You are describing an inherant flaw in Vonage/Sunrocket/Etc. style VoIP services.

      As a cable company, their traffic looks no different then Jo Shmoe next door torrenting the latest Back Door Betty DVD. So we CAN'T apply QOS to that traffic. We don't throttle it down OR up. We just let it go, and rely on the subscriber to know how to set up QOS on their equipment to maximize problems caused by their INTERNAL network.

      However, VoIP services such as those offered by Time Warner, Comcast, and actual ISPs CAN be prioritized because the MTA in the customer's home gets it's own IP address, and we know all traffic from that block of addresses is VoIP, and thus gets priority!

      Full Disclosure: Time Warner Cable Tier 3 Technician here.
      • Re: (Score:3, Interesting)

        by DamnStupidElf (649844)
        However, VoIP services such as those offered by Time Warner, Comcast, and actual ISPs CAN be prioritized because the MTA in the customer's home gets it's own IP address, and we know all traffic from that block of addresses is VoIP, and thus gets priority!

        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, whet
        • Re: (Score:2, Informative)

          by screevo (701820)
          At this point you have to consider how much it will cost to implement such a feature and weigh it against how many people would actually use or benefit from a feature. It IS still a business. If you are truly concerned about QoS, quality begins at home. Prioritize your own traffic in your router.
  • isn't it gigabit and multi-gigabit backbones?

    gigabytes and gigabit are two completely different things
    • by jascat (602034)
      isn't it gigabit and multi-gigabit backbones?

      Yes. That was the first thing I noticed in the summary.

    • The real problem isn't the factor of 8, it's that both "gigabyte" and "gigabit" are measures of instantaneous data size, where networking connections are more usefully measured in terms of data rate (bandwidth)... bits (or bytes) per second.

      We don't really care how many gigabytes of data the backbone can store at once... but we do care how fast data can get in and out.

      In some cases we also care about latency, how long it takes a specific piece of data to transit the network (which is a straight measurement
      • by karnal (22275)
        ... how long it takes a specific piece of data to transit the network (which is a straight measurement of time), but that's neither here nor there.

        *snicker*

        If it's the endpoints where the data is coming from/going to that concerns you, then it truly is here and there...

        OK, that was bad. I apologize in advance.
  • by Ancient_Hacker (751168) on Monday October 02, 2006 @03:24PM (#16282869)
    It's nice to sit in some aitr-conditioned office and write a book about how easy it is to get into IPV6.

    And someday Britney will learn to sing and parent, and all rappers will go sign up as sunday-school superintendents.

    In the meantime, the folks at the end of the ISP wires will have to spend kilo to megabucks on hardware and software upgrades, not to mention training themsleves, and training the users. Think of the millions of linksys home routers and wireless access points that will haev to be tossed out or reflashed! THink of all the books with xxx.xxx.xxx.xxx ip addresses that will be obsoleted! Lots of frustrated human-hours, even if the IP6 world will run as smoothly as the book suggests.

    • I think back 8 years or so ago during the boom years, there was some apprehension about "running out" of IPv4 addresses, which I think drove a lot of the desire for IPv6.

      I think it probably solves other weaknesses in IPv4 -- spoofing and some other cracker-ish issues that are difficult to mitigate against in IPv4.

      I think, though, that it's a little like alternative fuels -- we know they're good for us, but nobody wants to bother with them until we have to.

  • Riiight... (Score:2, Funny)

    by Guppy06 (410832)
    "IPv6 is halfway here,"

    Will it be here before or after viable fusion? What about DNF?
  • ...Or could the problem of supposedly running out of addresses be 'addressed' (sorry) simply by adding another octet to IPv4? If I've done my math right, this would result in a 40-bit address instead of 32.

    Example: 192.168.1.2.3

    Or is the goal to try and push IPv6 simply because it's "better?"

    I will say that V6 certainly seems to have its advantages, but I've tried (and failed) to learn its structure based on reading Lord only knows how many existing FAQs and white papers.

    As far as the time frame goes: I'm s
    • by arodland (127775)
      Let's call your idea "IPv4.1". It would still be incompatible with IPv4. It would, in fact, require just as much effort to roll out as IPv6 would... but it wouldn't make any other fundamental improvements. Same cost, less benefit. What's the point?
    • by Tony Hoyle (11698)
      I always thought that could work... use an extra octet or two to reference the machines behind the NAT.

      eg. you have 1.2.3.4, use a NAT router, and 'ipv4++' you get 1.2.3.4.0.0

      The advantage is nobody needs to learn a new addressing scheme, the routers don't need to be changed (you keep the packets compatible) so it's dirt cheap to implement.. That's the big problem with ipv6 - no sane transition plan.. everyone needs to upgrade their routers overnight and it just aint gonna happen (you cannot buy a consume
    • by BobSutan (467781)
      A better solution would be to unlock the 127 network. Poof! A whole shitload of address for people to use, all with just the authoring of an RFC.
    • by Vellmont (569020) on Monday October 02, 2006 @04:44PM (#16284279) Homepage

      Example: 192.168.1.2.3

      Or is the goal to try and push IPv6 simply because it's "better?"

      As I understand it one of the main reasons IPV4 wasn't just extended in address space was because routing becomes too difficult with such a large address space, so you need to build routing into the protocol. There's also some very cool features of IPV6 like multi-casting that's been very poorly supported under IPV4. This would allow things like broadcasting internet based TV without multi-gigabyte connections.

      When the day comes that said ISP calls me up to tell me "Hey, we're changing over to IPv6 at the end of the month (or year, or whatever), so you need to be ready for it," THEN I will start worrying about how to implement it.

      That'll probbably never happen (or at least not for 20 years maybe). IPV4 isn't going away, what'll happen (someday) is your ISP will one day support IPV6 and you'll be able to get an IPV6 IP address. No one is going to call you up, you'll probbably have to call them up and ask if they're supporting it.

      Until then, V4 and NAT are working perfectly well for me, thanks.


      Well, I'm sure horse and buggy owners thought that horses were perfectly good transportation when the car first came out too. There weren't many paved roads, the things were expensive, and took special fuel to run them where horses just ran on oats. It's often hard to see the advantages of a new technology before it's hit the mainstream.
      • by guruevi (827432)
        Some providers are already supporting ipv6 and ipv4 together or you can connect through a ipv6overipv4 tunnel to some server that connects you to other ipv6-enabled networks etc.

        ipv6 and ipv4 can co-exist without a problem. I currently use ipv6 on my network while the rest of the company doesn't really implement v6 yet. So ad-hoc, the Apple's are talking ipv6 while for other hosts, they'll have to talk v4. There is also support in IPv6 to encapsulate IPv4 traffic so basically, if a host talks v4 to a router
    • OK, fine. Where are you going to stick the extra octet? The only legal place to put it is in the IPv4 options. A proposal that did just that, IPv7, was actually floated. IIRC, it was dubbed "toasternet" because the proposal got "toasted". Interestingly enough, I was able to experimentally route "toasted" IPv4 packets, and hit about half of the web sites I tested. I had no way to verify end-to-end transmission, but sometimes my SYNs worked and sometimes they didn't. AFAIK, The existing infrastructure

  • The subject line says it all, but the lameness filter would appreciate a few more words.

    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.

    • by Tony Hoyle (11698)
      The analogy doesn't work. Segmented memory was a pain because you had to implement special measures to access it (in fact now we go one step further - using virtual memory there is no way to access the memory of another process).

      OTOH with network devices 99.99% of them simply do not need to be accessed remotely - NAT is fine for them, and presents zero issues.

      IPV6 has NAT, btw. It's an essential part of network infrastructure and is not going away. It's required to hide the real addresses from the world
      • by 955301 (209856)
        OTOH with network devices 99.99% of them simply do not need to be accessed remotely - NAT is fine for them, and presents zero issues.

        I somewhat disagree with this for reasons you will see in the future. *Current* use of network devices do not require remote access, so to a degree, you're pointing to the symptom to justify the cause. Examples include appliances with health checking connections to the service departments, a personal authentication server which maintains the private info you might like to sele
    • by Zeio (325157)
      v4 isnt going anywhere. I rarely like or agree with DJB, but here is a great article to read and consider about why IPv6 brings a lot of bad stuff with the large address expansion.

      That and why dont all the IPv6 lovers go look up switching performance for IPv6 packets - all the IPv4 L3+ line rate switches turn to MUSH with IPv6, and have fun with linked list headers making switching super fast really hard. Its really fun to watch super expensive Cisco, Foundry, Extreme and Force10 gear turn into a boat ancho
  • by DeepCerulean (741098) on Monday October 02, 2006 @03:39PM (#16283153)
    Duke Nukem Forever promises to support IPv6!
  • by KonoWatakushi (910213) on Monday October 02, 2006 @03:44PM (#16283265)
    The summary cites QoS as a motivating feature to adopt IPv6, and this is not a good thing. The very nature of the Internet (as an end to end best effort network) makes it impossible to guarantee any sort of service. As such, the only usage of prioritization is unfairly biasing some network resources at the expense of others. This is a direct affront on network neutrality.

    The only place packet prioritization and traffic shaping should take place is on private networks, where QoS can be guaranteed. Services such as VOIP and IPTV would ideally be offered over these ISP local networks at an additional cost. This is not to say that VOIP over the Internet impossible, but it should not have an unfair advantage over other Internet traffic.

    The only place where things break down is in the last mile, where ISPs are selling bandwidth that does not exist. In this case, something has to give, and so they must implement unfair prioritization schemes. The obvious solution is to honestly advertise minimum guaranteed rates instead. This makes it possible to prioritize a customers own traffic as the customer wishes without affecting others. (For example, if you want VOIP prioritized to the ISP local VOIP network.)

    Of course, such a scheme would still allow different speed grades, and excess capacity to be utilized. It can not be emphasized enough though that prioritization has no place on the Internet itself.
    • Re: (Score:3, Informative)

      by asuffield (111848)

      As such, the only usage of prioritization is unfairly biasing some network resources at the expense of others.

      This is grossly untrue. If I am downloading a DVD image, and using ssh at the same time, I want to tag the download packets as "low priority" and the ssh packets as "minimum latency". The internet routers can then queue packets according to my wishes, and my service is greatly improved.

      Just because it's possible to abuse prioritisation does not mean that it has no valid applications.

  • We will not switch to IPv6 until the spam problem is neutralized to a great degree. RBLs are the most effective method of stopping spam now. IPv6 would set anti-spam efforts back to the beginning almost. The larger amount of IP space would make stopping spamming exponentially more problemmatic. I urge other ISPs and networks to REJECT ipV6 until the industry cleans its own house, stops zombie PCs and spammers. Then and ONLY THEN should we consider ipV6.

    No increased address space on the net until the ro
    • by Micah (278)
      Actually, the ipv4 to v6 change would be a freeking *EXCELLENT* time to dump SMTP for something better, like Bernstein's Internet Mail 2000.

      The spam problem is probably solveable, but not with SMTP.
      • by TheLink (130905)
        Bernstein's IM 2000 doesn't work the way people expect mail to work, and so I'll say it will NEVER be widely used.

        The fact that the sender needs a machine to always be accessible for the receiver to fetch it from, if you have 2000 possible senders does that mean the receiver has to poll 2000 different servers regularly?

        If the receiver just has one IM2000 server to poll, and the senders with transient machines upload their mails to that server then that start to look like SMTP and POP3 doesn't it? And with t
        • by Micah (278)
          Are you sure you understand IM2000?

          You would not need to poll any possible server that might send something to you. A small "token" message is sent ... maybe somewhat like SMTP, but it would have a maximum size of maybe 200 bytes. Then the recipient knows exactly where to pull the whole message from -- IF it passes the blacklist check.

          The sender stores the mail until retrieved, and there should be a good realtime blacklist system. When a spammer attempts to send a payload, it is blacklisted before the va
    • by gbjbaanb (229885)
      Why would IPv6 be any different? The ip address is simply a bigger number - 128 bits instead of 32. The ability to lookup is slightly more difficult, but not particularly so and your text based lookups are significantly slower anyway.

      On the other hand, if everything has its own IP address (instead of NAT), and a much faster routing and DNS system, then you will have better tools to tell whether an email came from the server it claims to. If it doesn't, then you can guarantee its a trojaned machine sending s
    • by vadim_t (324782)
      Actually, no, it'll help a lot.

      It looks like lately spamming botnets are getting popular. It's easy enough, infect lots of computers, then use them to relay spam working around the blacklists. At least something will get through, and given enough boxes, a LOT will get through.

      By MASSIVELY increasing address space, IPv6 will make brute force scanning completely impractical. Currently a single box with a good connection can test every IPv4 address in a short time (measured in hours IIRC), IPv6 will make that
  • by Aqualung812 (959532) on Monday October 02, 2006 @04:18PM (#16283877)
    I know, I used a 90's buzzword, but that is part of my point. The Internet with IPv4 was on a slow and steady expansion with gopher, ftp, and telnet. Then with HTTP and enough bandwidth to get .jpgs in with the page, it just exploded. Everyone HAD TO HAVE IT.

    Until we have something that everyone wants and ONLY works with IPv6, we're not going to switch. That "thing" might be here today, but it seems we're all unaware what it is.

    Sure, there may be things that are better, but I can do all of the things IPv6 can do with IPv4 and a slew of extra services that I'm already familar with (VLAN or service-based QoS, NAT, DNS, DHCP, etc).

    I for one REALLY want IPv6 to get here, but the people who make my software and pay for my equipment won't change until they need to.

    • Re: (Score:2, Funny)

      Until we have something that everyone wants and ONLY works with IPv6, we're not going to switch. That "thing" might be here today, but it seems we're all unaware what it is.
      If so, chances are it's some kind of pr0n.
    • by gbjbaanb (229885)
      the anonymous post to this was close to the truth, I think video-on-demand will be the driver for IPv6, so yes... it'll be porn that is the killer app :-)

      Chances are all it'll take is for Vista to come with IPv6 support enabled by default, and that'll kick it all off, once ISPs support it (and I think the majority already do, even if they don't yet advertise or use it), then it'll start to snowball.
    • how about "communication with China"? Last I heard they're planning on being ipv6 only soon enough. I have a feeling the private sector will quickly scramble to enable ipv6 if that does in fact happen.
    • Sure, there may be things that are better, but I can do all of the things IPv6 can do with IPv4

      Nope, you can't (at least, not without extra infrastructure).

      IPv6 is useful for any peer-to-peer application purely because you're not having to deal with NAT. For example - want to run bittorrent on your workstation instead of your internet-facing router? That's going to involve setting up port forwards on your router (which is doing NAT), etc.

      Possibly a better example: VoIP. If you have a SIP phone, people ca
  • No thanks (Score:2, Interesting)

    by Anonymous Coward

    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

  • I had half started to believe all the hype about IP address shortages... until one of my clients purchased a T1 from AT&T. AT&T gave them 32 addresses without even asking how many they needed. They need two of them. If AT&T can blindly fork over 32 publicly routable IPs for a small business running a 1.5MB T1 connection, I think the "shortage" is just a bunch of hype.
  • It's been a while since I've bothered to look at IPv6 -- so, did folks ever work out the multi-homing issues with IPv6, so that companies (like, say the current favorite, Google,) could have multiple simultaneous connections with multiple backbone providers?

    (This seemed problematic for a while due to the hierarchial nature of the IPv6 address space forcing a tree-like structure into the routing and preventing the possiblities of having links between branches.)
    • by Cato (8296)
      I don't think so, but router and host autoconfiguration, and other features like address lifetimes, make it really much, much easier to switch over to a new ISP and address space, by simply configuring once at a central point. IPv6 is an enormous improvement in this area.
  • by VGPowerlord (621254) on Monday October 02, 2006 @09:09PM (#16287083)
    A lot of people are resisting the move to IPv6 simply because of the size of the address space. Particularly since under current manufacturing space, we could never fill it.

    Why? Simply: MAC addresses are only 48-bit, or 64-bit if everyone were to switch over EUI-64 [ieee.org]. IPv6's 128-bit size is a lot larger. There are 281474976710656 MAC addresses, 18446744073709551616 EUI-64 addresses, and 3.4e38 IPv6 addresses.

    So, IPv6 is approximately 1208925819614629174706176 times larger than the MAC address space.

    If you need help visualing this, here are the address space sizes padded with 0s in a monospace font. A space has been added in the middle to prevent /. from breaking the lines.
    0000000000000000000 00000281474976710656
    0000000000000000000 18446744073709551616
    3402823669209384634 63374607431770000000
  • Slashdot, please see my sig.
    Bloody luddites running this site.
  • IPv6 is not required to do QoS, and I really wish people would stop trying to associate the two - IPv4 has had QoS (via the 3-bit IP Precedence field and the 6-bit DiffServ codepoint that has superseded it) for decades, and virtually every router has QoS support. Both IPv4 and IPv6 have identical 6-bit DiffServ fields, termed the TOS byte in IPv4 and the Traffic Class in IPv6.

    This is a bit like IPSec, which works fine on IPv4 even though it was designed alongside IPv6 (maybe that's why it was initially so

To downgrade the human mind is bad theology. - C. K. Chesterton

Working...