Slashdot Mirror

Instead of your imaginary "packets too fast" message let's consider the "packets too big" message which actually exists in both IPv4 and IPv6.

Now http://www.tcpipguide.com/free/t_ICMPv6PacketTooBigMessages.htm that has a few fundamental flaws in IPv4 of which one was fixed by IPv6 and one was not. The flaw which was not fixed in IPv6 is the same flaw your proposal would have -- too damn many routers out there block ALL network discovery-related traffic including all ICMP messages because organizations are scared that outsiders may learn about internal network structure.

You cannot propose a defense against attackers which depends on people being well behaved.

As we're now pretty much stuck with ipv6, they would be better off locking out all the later bits until the transition is complete and make the ipv4 directly translatable. I.e. 192.168.25.25 becomes just FFFF:C0A8:1919 and all other ipv6 numbers are off limits until the transition is complete.

They did do this, it's a standard already. Not to mention dual-stack. http://www.tcpipguide.com/free...

I have no idea WTF you are talking about. A closed TCP port emits an RST. It even says so in the very link you posted:

http://www.tcpipguide.com/free...

"Receipt of a SYN message on a port where there is no process listening for connections."

Next time you try to be a smart-ass, get your facts straight. Idiot.

You should get an ICMPv4 response with a type value of 3, and code value of 3.

RST happens when something borks up in an existing session, not in response to a SYN. (exception: when firewalls/NAT gateways are configured to reply with an RST, instead of dropping or ICMP).

Don't you kids know anything?

I have no idea where you got that information. Check http://www.tcpipguide.com/free...

I prefer this visualisation;

I wanted to make a cool graphic to show the relative sizes of the IPv4 and IPv6 address spaces. You know, where I’d show the IPv6 address space as a big box and the IPv4 address space as a tiny one. The problem is that the IPv6 address space is so much larger than the IPv4 space that there is no way to show it to scale! To make this diagram to scale, imagine the IPv4 address space is the 1.6-inch square above. In that case, the IPv6 address space would be represented by a square the size of the solar system.

I think this is why logarithms were invented.

I wanted to make a cool graphic to show the relative sizes of the IPv4 and IPv6 address spaces. You know, where I’d show the IPv6 address space as a big box and the IPv4 address space as a tiny one. The problem is that the IPv6 address space is so much larger than the IPv4 space that there is no way to show it to scale! To make this diagram to scale, imagine the IPv4 address space is the 1.6-inch square above. In that case, the IPv6 address space would be represented by a square the size of the solar system.

Having IPv6 on your LAN doesn't mean you lose IPv4 connectivity. Both protocols can and do co-exist on your network. Hosts on my networks that are dual stacked IPv4/IPv6 include Windows XP, Windows 2000 (there was a developer pack a while back), Linux and MacOS X.

Originally when I first started playing with IPv6 on my network I took one of my MacOS X machines, got a subnet from Sixxs (tunnel broker) and installed Aiccu (their client software). With a little extra configuration to setup the machine to do router advertisements and make it act as router everything was up and running. All the machines that had IPv6 activated got themselves a routable IPv6 address and were able to connect to IPv6 web sites.

Later on I decided to buy myself an Apple Airport, which has IPv6 support and then simply enabled 6to4. Ideally I would have connected to Sixxs again, but there is a firmware issue when using PPPoE, that they have failed to fix thus far (if they want better advertising then they should have a longer firmware maintenance window).

Because of the limitation of the Apple Airport, I have been keeping my eyes open for alternative solutions. For me any viable solution needs to provide a GUI for configuration. OpenWRT and DD-WRT both have IPv6 support, but not from the UI last time I looked. The one that seems the most interesting is Tomato, which has a UI and is the one that a Canadian ISP known as Teksavvy is playing with (see here). Buffalo seems to have IPv6 in its firmware, but it is not a feature that is marketed, so I will need to try one out before going for it.

It should be noted that much of my knowledge on IPv6 has been garnered by spending time on the Sixxs.net forums and wiki.

For the most part once you have IPv6 installed on your network most people shouldn't notice. One thing to make sure is the router has a properly configured IPv6 firewall.

As long as whatever solution is transparent to the application, then that's what will make the most sense. If the applications are intranet only, then they could probably exist in their own IPv4 subnet with little regards for what is happening beyond their island. If they need internet connectivity then, they will probably still be okay for the next few years since existing IPv4 addresses won't vanish, they simply won't be able allocated anymore - I assume such applications will continue speaking to the same servers. We will have an IPv4 internet for a while after the world has moved to IPv6. Even a host which only knows how to speak IPv6 will probably still be able to speak to IPv4 hosts through IPv6/IPv4 bridges. See: http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.htm

This transition is not the first time is happened. For example companies who were using Novel Networks or IPX had to deal with migration to TCP/IP somehow.

Sorry, I meant 120 bits of multicast.

It'll be dynamic - the protocol doesn't use DHCP as we know it; it uses 'neighbor discovery,' which is described here: http://www.tcpipguide.com/free/t_TCPIPIPv6NeighborDiscoveryProtocolND.htm

I've experimented with it on a number of various networks - some professional, some personal - and it's not so bad. THe implementation isn't as complete as IPv4, but given the user base, it's not that surprising....

Do you think the current owners are hanging onto their address spaces out of pure spite? If they rely on the Internet to do business, this crisis hurts them more than anybody.

This mess happened because of the simplistic addressing schemes that were implemented without taking into account the explosive growth of the Internet. One result is that that some early adopters ended up with Class A networks (16 million addresses) because they needed more than the 64 thousand addresses in a Class B network. Only one Class A space belongs to a university (MIT). (There used to be two, but Stanford gave its IP space back.) Other owners include Halliburton, Apple, IBM, and Xerox PARC. HP has two, counting the one that was originally issued to DEC. DoD has eight.

Reassigning all these addresses would be a logistical nightmare, because you're changing the basic logic of network routing. Imagine all the routers that would have to be reprogrammed or replaced, and the expensive down time that would result. Much more cost effective to just go to IPv6 already. Plus there are other features of IPv6 we really, really need.

Except that nobody's doing it. I used to work at Sun, where I kept suggesting that our embedded lights-out management system (all Sun servers have them) start supporting IPv6. The answer I always got was, "customers aren't asking for it." Which means that everybody is putting off this problem until the last minute. As usual.

ALSO - Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm [tcpipguide.com]

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx [microsoft.com]

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

The ONLY thing I am not certain of, is does this disallow SMALLER windows being negotiated, such as the setsockopt 0 uses in this type of DOS/DDOS attack. This I need feedback on, thanks.

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts

Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts = 0 which STALLS "SLIDING WINDOW SIZES" (Tcp Scaling in other words), then, this attack (which seems like it is using the "Silly Window Syndrome" per the above) cannot work...

(As "setsockopt 0" cannot reset/renegotiate the TcpWindowSize & the sy

RFC1323 - TCP Extensions for High Performance: -> http://www.faqs.org/rfcs/rfc1323.html

Specifically, as regards "Window Scaling", & these pertinent quotes (& how Tcp123Opts = 0 shuts off ALL of these hi-performance TCP/IP options (slower, but sounds like a safety measure vs. this setsockopt 0 "silly windows syndrome" attack))

Please, read on:

"The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793). The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened

(Note that LAST bolded statement? THAT only "holds true", IF these RFC1323 options are 'turned on', first of all, & what turns them COMPLETELY off (@ the price of performance, perhaps, but not of safety vs. this "sliding windows scale/sliding windows/silly window syndrome" attack? Tcp1323Opts does))

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2?

Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

So, by setting them properly against this attack, by altering them, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters accordingly.

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

You can nullify this attack it seems, because SynAttackProtect = 2 AND Tcp1323Opts = 0 (& using a set TcpWindowSize also) can stall out "sliding/scaling TCP Window Sizes", which this attack seems to exploit a vulnerability of via setsockopt 0 calls...!

APK

P.S.=> See my point now? Using Tcp1323Opts = 0, SynAttackProtect =2, & setting a TcpWindowSize to 64k (or whatever)? This setsockopt 0 type DOS/DDOS attack may be nullified it appears, because "sliding windows/tcp scaling" doesn't even take effect anymore, & this "setsockopt 0" seems to exploit it, via the "silly window syndrome" here -> http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Hope you see my point... &, again, I'd like your "Feedback/Thoughts" on this as well - Thanks for your time, because I am trying to figure out a way, hopefully, to stall this attack on Windows 2000 rigs (I h

See subject-line above, & "SWS" was short for "silly window syndrome" ->

TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Again - please, read on & offer your thoughts after reading the above article especially & its KEY POINT/CONCEPT, quoted above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.

I am only looking for possible defenses for Windows 2000 users (MS stating PORT FILTERING will do it? Fine for workstations, but for servers that solicit connections?? Not so fine imo, as they have to offer connections, & THAT means they are "DOS'able"!)

Please, read on, offer your thoughts futhers on these points:

----

"Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

By "negotiated", don't/or do you rather, mean "Tcp Window Scaling", per the above about "Silly Window Syndrome"? I do know that SynAttackProtect, set to a value of "2", STOPS TcpWindowScaling... per this quote from MS:

SOURCE -> http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

----

Also: GlobalTcpWindow MAY NOT BE USEFUL HERE, since it is "deprecated", but?

The other parameter I noted apparently is, of TcpWindowSize, per your source no less here -> http://support.microsoft.com/kb/q263088/

----

"Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using http://support.microsoft.com/kb/q263088/ -

PERTINENT QUOTE: "To resolve this issue, set the TCPWindowSize value globally or use a value smaller than 64240 (this value is a multiple of the Ethernet Maximum Segment Size)." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

I never SAID it "hardened" the IP stack...

I figured it MIGHT help "mitigate" the setsockopt 0 that a 'badware' for DOS/DDOS would use to set a WindowsSize of 0, which IS the problem here, per the setsockopt 0 call, & what SynAttackProtect stops (sliding window sizes), & the fact that you can set that WindowsSize for Tcp via the TcpWindowSize parameter in the registry for TCP/IP's parameterizations...

Again - Thoughts/Feedback on these replies/points? Thanks for your time...

APK

P.S.=> BOTTOM-LIN

I like this box-size example...

TCP checksums would catch it before the user would.

http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader.htm

Ahh, I figured as much. I tried searching for it before but I didn't have BGP in there, so my search for "network announcement AS" resulted in "OWN: The Oprah Winfrey Network Announcement", lol. My modified search landed me on http://www.tcpipguide.com/free/t_BGPDetailedMessagingOperationandMessageFormats.htm which I think will help me out. I think I remember reading this years ago, didn't the PDF used to be free?

What is .027% of 2**128

Here's a neat (and understandable) place to find out just how stupid it is to say that "only X%" if IPv6 is assigned: http://www.tcpipguide.com/free/t_IPv6AddressSizeandAddressSpace-2.htm

IPv6 is HUGE. I didn't even understand how huge until I found out I can get an address for every friggin cell in my body.

Weeeee!

Easy multicast enables a whole new class of applications and mobile devices that could be very useful, but are very difficult to produce today.

Interesting. I wasn't aware that IPv6 changed anything with respect to multicasting. I Googled it and came up with this:

http://www.tcpipguide.com/free/t_IPv6MulticastandAnycastAddressing.htm

One of the most significant modifications in the general addressing model in IPv6 was a change to the basic types of addresses and how they were used. Unicast addresses are still the choice for the vast majority of communications as in IPv4, but the "bulk" addressing methods are different in IPv6. Broadcast as a specific addressing type has been eliminated. Instead, support for multicast addressing has been expanded and made a required part of the protocol, and a new type of addressing called anycast has been implemented.

Ok, having multicast a required part of the protocol means people would actually be able to use it. Right now multicast over the internet often gets filtered/ignored. Multicast makes a compelling case for content distributors - send out one copy of your stream and routers along the way will duplicate it as necessary.

All this really does is save you from having the buy more bandwidth/servers. I don't see how this enables new classes of applications; I can't think of many non-media applications that would benefit from multicast. That may just be my poor imagination. I have seen systems that use UDP multicast to deliver realtime stock quotes for traders, but that was run over a private IPv4 network.

As a workaround, content distribution networks could easily replicate streaming protocols for you without multicast; they already do it for HTTP. You set up one copy of your stream to Akamai, and they replicate it as necessary as clients connect to them. They already have distribution points scattered across the globe, close to the endpoint users.

Oh wait, they already do that. http://www.akamai.com/html/technology/products/streaming.html

No need to change the whole world over to IPv6; just shell out a few bucks. So if by "difficult" you mean "expensive" - yes. Difficult as in requiring new technology - not really.

TCP resets can occur for many reasons. All that client software can know and report is that the TCP reset occurred. But, for example, it can't know whether it got a reset because the software on the other end of the connection crashed, or had a bug, or the computer was turned off, or there was some corrupted communications between the two causing the TCP connection to get confused and need to be reset. This is all explained at http://www.tcpipguide.com/free/t_TCPConnectionManagementandProblemHandlingtheConnec.htm (for example).

Vuze's test only counted reset rates, so it can't prove anything about what's going on. At most, it could suggest areas where it might be productive to do more investigation.

With IPv6, every computer in your house, and every piece of dirt in your finger nail (including every finger nail on the planet) can have it's own unique IP address.

The only reason to keep a LAN around that has separate addressing is if it improves security - i.e. if it prevents your personal local traffic (or sensitive business information) from going on to a more public network when it otherwise would be restricted to local lines that are less able to be wire sniffed via ethereal/snort etc.

If a switch is properly configured, this shouldn't be a problem - assuming that you don't tell your banking machine to send unencrypted traffic between sites without having your own OC line to wherever the traffic is going.

Where's the problem with a LAN dissapearing in this scenario? Besides that right now we know sending traffic to any 192.168.x.x IP will not get routed on a public network?

reference re: address space size

not me, but you could use google. Or try this link: http://www.tcpipguide.com/free/t_MajorChangesAndAdditionsInIPv6.htm

Given how many problems with IPv4 this new revision solves and that a thorough look was taken at the protocol in its entirety, of all things, I'm surprised *geeks* usually just try to find reasons to not like it. Sure, admins may need to retrain, and there'll be infrastructure costs, but since when did geeks stop looking at positive evolution as being bigger than these things?

There's also always a lot of FUD spread around this matter, and one can find it even in this topic, for example IPv6 increasing routing complexity. IPv6 uses hierarchical address ranges *and* is modularized so there's not just less complexity, but even less *traffic* to route unless using more advanced features of IPv6. After the transition, IPv6 is better for your routers.

NAT's also seem to be a common enough argument against IPv6 that someone should have written a damn "Why NAT's won't solve address space issues" FAQ to uninformed people already. There is something similar enough for that though.

Anyway, instead of just ranting, here's a document about some of the changes IPv6 makes. Maybe especially this part is educative to some.

Given how many problems with IPv4 this new revision solves and that a thorough look was taken at the protocol in its entirety, of all things, I'm surprised *geeks* usually just try to find reasons to not like it. Sure, admins may need to retrain, and there'll be infrastructure costs, but since when did geeks stop looking at positive evolution as being bigger than these things?

There's also always a lot of FUD spread around this matter, and one can find it even in this topic, for example IPv6 increasing routing complexity. IPv6 uses hierarchical address ranges *and* is modularized so there's not just less complexity, but even less *traffic* to route unless using more advanced features of IPv6. After the transition, IPv6 is better for your routers.

NAT's also seem to be a common enough argument against IPv6 that someone should have written a damn "Why NAT's won't solve address space issues" FAQ to uninformed people already. There is something similar enough for that though.

Anyway, instead of just ranting, here's a document about some of the changes IPv6 makes. Maybe especially this part is educative to some.

You know, TCP/IP already has the ability to set a priority bit... so it is merely a matter of turning those bits on or off to offer different speeds for people.

The "vast majority of people" live on 2 dollars a day and don't have computers. The vast majority of computer users don't purchase software that didn't come on their computer. The vast majority of IT depts don't purchase software without some sort of justification. A good IT person would be able to evaluate their needs and match to the appropriate solution given resources available.

Doesn't mean that VMWare doesn't rock. Just that there are considerations you and other failed to take into account when marking the parent as flamebait.

It is worth mentioning (since the reviewer didn't) that the book is available free online in HTML format. Start with the table of contents. He also sells (erm, "licenses") PDFs for $35, though I'd rather buy the book itself for $50 at Amazon. The HTML version has those annoying fake-link ads that pop up sundry advertisements when you mouse over them, but I still commend him for posting the book. I have bookmarked it for future reference, and I'll likely buy the book if it proves more useful than the RFCs next time I need it.

He makes the material available gratis on his website and if you buy direct from him you pay only $5 more than amazon and you get a CD of the PDFs and he'll autograph it on request.

Why not kick back a few bucks his way to reward him for his good work?

"How long does it take to download The TCP/IP Guide?
About 2.5 hours using a 28.8kbps dialup modem; about 1.3 hours at 50kbps; about 8 minutes with 500kbps broadband." (http://www.tcpipguide.com/faq.htm)

Has anyone seen a 28.8kbps modem lately? I thought they were extinct.

I wrote to him to discuss something I'd noticed in the IPv6 sections, and he wrote back. It was very nice to discuss it with him directly, and I'll gladly echo the fact that his work is both easy to read and informative.

I've read a LOT of networking crap over the 25 years I've been doing computer networking, this ease of reading is not common to the genre.

His work is also online:

http://www.tcpipguide.com/free/index.htm

Bob-

And the full contents of this book, including BOOTP Client/Server Messaging and Addressing are really entirely available on its ADdicting website as it seems to claim!?!

::ffff:64.125.75.24
(see http://www.tcpipguide.com/free/t_IPv6IPv4AddressEm bedding-2.htm)

btw you can't have 3 ':' in a row in a valid ipv6 address.

". IPv6 is intended to replace the previous standard, IPv4, which only supports up to about 4 billion (4 × 109) addresses, whereas IPv6 supports up to about 3.4 × 1038 (3.4 dodecillion) addresses. This is the equivalent of 4.3 × 1020 addresses per inch (6.7 × 1017 addresses/mm) of the Earth's surface."

It should hold for a little while.

It's enough addresses for many trillions of addresses to be assigned to every human being on the planet.

The earth is about 4.5 billion years old.

If we had been assigning IPv6 addresses at a rate of 1 billion per second since the earth was formed, we would have by now used up less than one trillionth of the address space.

From tcpipguide