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:
  • Re:And... (Score:4, Informative)

    by mph (7675) <mph@freebsd.org> on Monday October 02, 2006 @04:35PM (#16283085)
    No, see, there _was_ no IPV4 before IPV6 come out, and that should be your first clue that we're doomed
    WTF? See section 3.1 (specifically the "version" field) of RFC 791 [faqs.org].
  • by Anonymous Coward on Monday October 02, 2006 @04:41PM (#16283185)
    Yes, IPv6 is better. Security, QoS, transparent roaming, autoconfiguration, etc, etc. Its not just more numbers. And IPv6 can interoperate with IPv4. All the sites on the internet would still be accessible to you if you were using an IPv6 ISP instead of an IPv4 ISP. Nobody needs to stop using the internet, we just need to transition over to a new protocol ON THE INTERNET. Its like saying paved roads were stupid because everyone was already using dirt roads and all the stores were on dirt roads, so it would be impossible to convince people to move off of the existing roads, and onto the paved ones where nothing was. Nobody is making new roads, just paving the existing ones dumbass.
  • 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.
  • Your linksys router monitors all of your trafic to do proper routing. Do you want your ISP to monitor all your packets and their content and see if thats porn or vonage coming in and out of your house? Learn how TCP/IP packets are built. Till then, you're just rambling. SM
  • by dgatwood (11270) on Monday October 02, 2006 @06:07PM (#16284673) Journal

    There are already accepted standards for how to do flag packets has having higher priority. From the IP spec:

    Type of Service

    The type of service (TOS) is for internet service quality selection.
    The type of service is specified along the abstract parameters
    precedence, delay, throughput, and reliability. These abstract
    parameters are to be mapped into the actual service parameters of
    the particular networks the datagram traverses.

    Precedence. An independent measure of the importance of this
    datagram.

    Delay. Prompt delivery is important for datagrams with this indication.

    Throughput. High data rate is important for datagrams with this
    indication.

    So there are already flags in the IP header, which if honored consistently, would allow for consistent routing of time-sensitive packets like audio in the presence of bulk data. Since introspection of the IP header is required for routing anyway, if the ISP is already doing QoS by IP range, the penalty for an additional check of these IP header flags for traffic from a different IP range is negligible. Any ISP that says differently is trying to sell their own overpriced VoIP service.

  • by VGPowerlord (621254) on Monday October 02, 2006 @10:09PM (#16287083) Homepage
    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
  • by asuffield (111848) <asuffield@suffields.me.uk> on Monday October 02, 2006 @10:40PM (#16287245)
    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.
  • 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.
  • by Anonymous Coward on Tuesday October 03, 2006 @01:40AM (#16288149)
    QoS is needed exactly for things like voip and iptv. IPv6 having QoS doesn't mean internet traffic needs to be prioritized, it means that they can run internet traffic, voip traffic, iptv or other streaming video traffic all over the same lines, each with different priorities, inside their network. Exactly what you describe with ISPs providing these extra services is exactly where IPv6 excels. That's the whole point.
  • Actually... (Score:3, Informative)

    by schwaang (667808) on Tuesday October 03, 2006 @02:38AM (#16288439)
    MAC addresses don't go outside of the broadcast domain, dimwit.

    Actually, your MAC address, which is a globally unique identifier, forms half of your IPV6 address [wikipedia.org] unless you do something unusual to avoid that. So it is a very valid privacy concern.

    The AOL search data episode showed how easy it is to unmask anonymity when all you have is a bunch of URLs coming from the same unique anonymous identifier. IPV6 increases the risk of this kind of aggregation of supposedly anonymous activity.

    When IPV6 is here, Choicepoint will probably pay for your MAC address. And everyone else will pay Choicepoint to know who the "anonymous" person is visiting their website.

    As a bonus, NSA will find it easier to know exactly who is using the free public wifi at the library.

The secret of success is sincerity. Once you can fake that, you've got it made. -- Jean Giraudoux

Working...