Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.

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!

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

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!

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

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.

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

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.

The TOS field is quite obsolete, and was never used anyway, although the adjacent 3 bit IP Precedence field was used somewhat. Both have been superseded by the 6 bit DiffServ codepoint field in IPv4 and IPv6 headers - it re-uses the TOS and IP Precedence fields.There has never been much agreement on the meaning of these fields, though DiffServ does make some headway here by defining EF and AF schemes for the meaning of such codepoints.

There is some overhead to checking (classifying on) these fields, but th

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.

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.

The trust issue is a big problem when it comes to the ToS flagging of traffic. However, it isn't unresolvable. You basically get a few options:

1. The ISP can do traffic fingerprinting to try and identify the traffic - if something looks like RTP it should probably be sent through a low-latency route whereas if something looks like bittorrent it shouldn't - irrespective of what the

Actually I think your gunshot metaphor isn't making the point you think it is.Let's say there are two people, Joe and Bob. Joe has a sucking chest wound. Bob has a bad stomach bug from some questionable Chinese food. They both want to go to the hospital, and there are two methods of getting there: the high-priority route, which involves calling 911 and getting taken there in an ambulance to a special door, and directly in to see the doctor; then there's a low priority route where you take a car, stand aroun

You miss something though: You often would want some of _your_own_ traffic to take priority over other of _your_own_ traffic.So your WoW packets should take precedence over Microsoft Windows Update, or your background email checking and IM message alerts.

If both ISP A and ISP B give you the same just barely adequate bandwidth, but ISP A supports the TOS stuff, then you'd have a better WoW experience.

The big problem with much traffic control stuff (and Linux tc is one of them) is it is hard to automatically

I never said there was no penalty. I said the extra overhead of the check is negligible. The QoS itself penalizes other traffic, so of COURSE there is a penalty. The penalty does not come from the difference between checking IP header flags and checking whether the source/destination IP numbers are within a given range, however.

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

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.

...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.

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?

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

No, IPv4 can't be a subset of IPv6. Sure, it would have been possible to let an IPv6 address send packets to an IPv4 address, using regular IPv4 packets, but then how would the target host send back a reply?
You can't have a subset; addressing needs to be 1-to-1 unless you throw logic like NAT in the middle.

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.

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.

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

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

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

I guess that I should have said, "setting up P2P between systems that are both using NAT is damn near impossible without involving third-parties". Yes, there are lots of ways to work around the problems that NAT adds to the Internet, just like there were lots of ways to work around the problems introduced by segmented memory. The fact that work-arounds exist doesn't mean a thing. Things would get done quicker and easier if there wasn't a need for such work-arounds in the first place.

Why not just order them, it's straightforward:PS3 launched (it seems obviously likely to launch soon, this will surely happen before any of the others)* PS3 tanks (it will surely either tank immediately or not at all, I'll bet on not at all, but if it does tank, it will surely be here in the ordering)Trusted Computing widely accepted (joe 6 pack sure to widely accept this, and available widely soon)Perl 6 released (this one also seems likely to happen... but possibly not before TC is widely available)Duke

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.

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.

Bullshit. QoS is all about reducing latency for streams that require it. Latency is a function of, among other things, queuing behaviour at the router, and that is an issue irrespective of the total amount of bandwidth being utilized.

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

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

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

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

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

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.

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.

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.)

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.

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.

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

I know you're joking, but you're completely correct. Not only is IPv6 _not here_, it's not even halfway here. Not by anyone's measure that would make any more sense than (for example) "IPV6 is halfway here in the same way that the PS6 is halfway here."See, there's this thing called The Internet, and Google, and AOL, and CNN are all on it. We all agree that that thing is called the Internet.

On IPV6, there's nobody.

IPV6 is just a misnomer. It should be called "Really big addresses" or something like that.

Stop bring logic and facts to our pissing contest!Seriously though the amount of terms and knowledge lost in RFC's and ignored by the self appointed "gurus of the internet" is sad.

At least the IPv6 is ready for the day we run out of IPs which will be upon us sooner than some zealots say. But the simple fact is you never need to go to V6 unless you want an IP that's v6. The theory is v6 will still remain mostly v4 compliant. The infastructure is being update for the switch over and that's all that matters

At least the IPv6 is ready for the day we run out of IPs which will be upon us sooner than some zealots say. But the simple fact is you never need to go to V6 unless you want an IP that's v6. The theory is v6 will still remain mostly v4 compliant. The infastructure is being update for the switch over and that's all that matters. If you want to remain ignorant or believe v4 will be here forever you're welcome to and it should be for the most part. But v6 will also start being used when it's time (I have yet

How are you going to convince the 3 billion people to switch?Tell them that they won't be able to access resource N (Slashdot, YouTube, whatever) unless they switch over.

How are you going to change all that software?The software is mostly changed already. The majority of that is done below the level that your typical implementation requires it to be accomplished at. There are notable exceptions, but the parts that need changing are usually very small libraries at the bottom of the application.

The software is mostly changed already. The majority of that is done below the level that your typical implementation requires it to be accomplished at. There are notable exceptions, but the parts that need changing are usually very small libraries at the bottom of the application.

This is an extremely naive view at the situation.No, the typical application cannot be converted to IPv6 by linking to another library.Even when major operating systems have IPv6 support, that does not mean that most of the softwa

So windows has a new patch, and as I stated there still legacy support for IPv4, and if you really want you can tunnel v4 to v6 or v6 to v4 if you must.Now it'll get hard but as long as Microsoft offers versions of XP networking that support v6, and IE then all those people will switch (or have the option). Firefox will upgrade when it's stating to go live, Mozilla, opera, all of these will either upgrade or become obsolete. I'm guessing they will upgrade. But even with out the upgrade there's multiple w

I know you're joking, but you're completely correct. Not only is IPv6 _not here_, it's not even halfway here. Not by anyone's measure that would make any more sense than (for example) "IPV6 is halfway here in the same way that the PS6 is halfway here."

ipv6 seems to be going backwards in fact, with the closure of the vast majority of tunnel brokers & no sign of any ISPs planning adoption (and many (most?) not supporting the anycast address any more). If it's halfway there it's facing in the wrong direct

It's quite simple, really. You start with 6to4 or Toredo (which, in case you aren't aware, is IPv6-over-IPv4, and you can run it now), and you gradually start pushing the IPv4 gateways closer and closer to the core of the Internet, until the address shortage [potaroo.net] is alleviated.

Yes, IPv6 is better. Security, QoS, transparent roaming, autoconfiguration, etc, etc. Its not just more numbers. And IPv6 can interoperate with IPv4.

Yuk. Security, transparent roaming, buzzwords. And QoS? That acronym always brings me out in a rash.

Simple fact is that no one cares that IPv6 is better, or that some people think it's better. My ISP isn't using it, neither is any other ISP I know and I know of no one who is using an IPv6 supporting device like an access point or something and I know of no

"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."

Sure, you can use the same "tubes" with IPv6 as you did with IPv4 (bits are bits, after all), but just because IPv6-compatible routers and such are backwards compatible with IPv4 doesn't magically

IPv6 is more secure because communications within a subnet use a special address coding that (a) can never leave the subnet (b) can never be introduced from outside the subnet, and (c) can be positively identified as coming from inside the subnet. IPv6 has other security features, but this one all by itself blocks a couple of categories of intrusion technique.

QoS has a single field in IPv4 that has no implementation attached to it, and is thus implemented as an afterthought in a collection of vendor-specific ways. Saying it has QoS is kind of like saying that your house comes with a jacuzzi because there's a place out back where you can put one and plug it in. IPv6, on the other hand, has a full standard implementation associated with it.

Um, IPv6 IS at the network level. Duh. Are you talking at the hardware link layer? That's only supposed to connect one device to the next, not keep track of network topology. Roaming isn't tunneling either - the old address actually replies to a packet letting it know where it should send the information to, thus making the switchover quick, transparent, and very, very lightweight.

IPv6 autoconfiguration is STATELESS. It doesn't require a server to figure out what addresses it has available, which ones it's handed out already, which ones have expired, etc, etc. DHCP is nice, but it requires maintenance. You can tell me how easy DHCP is to configure all day long, but it'll always be tougher than none at all.

QoS is nothing to do with IPv6 - both IPv4 and IPv6 support DiffServ, which is the closest we have got so far to QoS standards that are actually deployed (mostly for MPLS IP VPNs and VoIP in closed IP networks run by telcos for business customers). The flow label is IPv6's only unique QoS feature and it is mostly for use by RSVP, which is undeployed and doesn't scale in current form.See http://books.slashdot.org/comments.pl?sid=198651&c id=16289245 [slashdot.org] for more details.

Transparent roaming makes plenty of sense. You can plug in your machine anywhere and it will work. You don't have to make a "home" and "work" network profile, or change setting or anything.

Err, no. Sorry, there will still be multiple network protocols. If I allocate my machine a link-local address and try and serve a web-site, I'll need to make network configuration changes if I move a few cities over. IPNG talked about making it possible to do this (self-allocated addresses), but then smart people who have

The OMB mandated all US Government agencies be on IPv6 by June of 2008. So I think it's much closer than many realize. And while few things in government meet deadlines, you can be sure this will be seen through. Just think of the joy of paying your taxes to the IRS over IPv6 in 2009:0

Beware, the US Government also decided to ban NTSC over-the-air signals in 2007, so I don't really put that much faith in their intelligence on the matter either.

Obviously you are not on any IETF working groups as you are completely ignorant of the fact that IPv6 is a DOCUMENTED STANDARD that is ALREADY IS USE on the Internet! (See stupid comment about: "IPV6 is just a misnomer")

Really? Go ahead then. Remove your IPV4 stack.

The rest of us are on the Internet. It uses dotted-quads, and A records. None of this AAAA or D6 or A6 garbage. It's also where google and cnn and aol are. It's where we're communicating now- and where slashdot is. _THIS_ is the Internet.

Misnomer means named incorrectly (or inappropriately). IPV6 is a misnomer because it is called "Internet Protocol Version Six", but it doesn't include the Internet.

The whole of the IPv4 address space is included in the IPv6 space.

Would've been a good thing if it were true.::ffff:0:0/96 addresses are simply IPV4 addresses in IPv6 format. You still need an IPV4 address to communicate with this network.::/96 has been reassigned, so it's no longer used for IPV4 encapsulation.

Huh, bizarre.Do you know that you can change your MAC address when you want it? You could use the same mechanism to your advantage instead, changing it constantly and make it look as if there was an entire server room on that connection.

They can write books and have conferences, but as long as people like me work quietly together towards the common goal, we can keep IPv6 where it belongs - in the gutter.

Sorry to break it for you, but your opinion doesn't matter a damn. What matters is: Do the government and

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.

if i have a MAC based IPv6 address hostinga website and then upgrade the server does that mean a mass DNS routing update or a simple change of a setting on the new server?

Well, for a start there's no such thing as "DNS routing". You would simply need to change the RR on your primary DNS server. And if the server happens to be a DNS server you'll need to update the root NS glue - not really a lot of effort.

Alternatively, you probably wouldn't use a auto configured address for a server - zeroconf type syste