Slashdot Mirror
One Step Closer to IPv6
gbjbaanb writes "IPv6 came a step closer yesterday as ICANN added IPv6 host records to the root DNS servers, reports the BBC. 'Paul Twomey, president of Icann which oversees the addressing system, told the BBC News website there was a need to start moving to IPv6. "There's pressure for people to make the conversion to IPv6," he said. "We're pushing this as a major issue." The reason for the urgency, he said, was because the unallocated addresses from the total of 4,294,967,296 possible with IPv4 was rapidly running out. "We're down to 14% of the unallocated addresses out of the whole pool for version 4," he said. Projections suggest that this unallocated pool will run out by 2011 at the latest.'"
Its sad to look at the list of class a allocations and know that we're almost out. All this was done before NATs became popular. I think ICANN/IANA should work on wrestling some of those class As back from companies like Ford, Apple, HP, etc. None of those companies are going to ever have 16,000,000 hosts on public IPs. I know some of those companies have already made sub allocations. We could probably buy 5-10 years if they could reclaim just the 3, 9, 13, 17, 19, 20, 34 and 40 class As and get over 130,000,000 IPs back.
I mean, if those companies complain, who cares. They wouldn't get such large and prestigious allocations in an IPv6 network anyways. So what's the difference.
I know, I know, we should move to IPv6 anyways. Just a suggestion. Poor initial planning warrants changes down the road.
Just like how when we run out of oil, solutions will come along, when we run out of IP addresses, solutions will come along. The only problem is people don't get very motivated until we're really on the edge. I don't have much hope for IPv6 for another few years yet. Still, progress is progress.
-mrxak
Onions Will Kill You
Sadly, it can't Talk dirEctly to my Next-DOor neighbor, who runs an equally large neTwork.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The only justification you ever hear for moving to IPv6 is address exhaustion in IPv4. There's a lot of other stuff built into the protocol that will make the net a much better place. Even if IPv4 had the same amount of addresses as IPv6 it would still be worthwhile to switch. Just give this a once over for an introduction
http://en.wikipedia.org/wiki/Ipv6#Features_and_differences_from_IPv4
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
They're not going to be very eager to give up their position as a gatekeeper of a limited resource just so their customers can frolick in a vast address space for free. Since most of them operate in a monopoly or duopoly situation, the proverbial "free market" won't force them to move off IPv4 either.
Have we reached Peak IP?
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Wake me up when I can pull up the main page of Google using nothing but packets with IP6 headers.
That means that I can do a DNS query using nothing but IP6 packets - NOT IP4 packets.
That means that I can do an HTTP transfer from Google's servers using nothing but IP6 packets - NOT IP4 packets.
Hell, wake me up when there's a AAAA record for Slashdot.
This is a *baby* step towards IP6 being useful.
www.eFax.com are spammers
I get a surprising number of IPv6 hits on my webserver at home. Most of these appear to be XP or Vista boxes with Internet connection sharing turned on that automatically assign themselves a 6to4 addresses when they have an interface with a public IPv4 address.
IPv6 with 6to4 is easy to set up, and I'd recommend it to anybody who has a static IPv4 address. You can use NAT-PT so all your IPv6 hosts can still get to the IPv4 network. If you have a couple of DNS servers, you can even set up reverse DNS for your IPv6 network just the way you want using this nice web interface from the NRO.
I maintain some good links to stuff about IPv6 on del.icio.us.
I hate NAT. And I think IPv6 can be just as secure. Partly because a 64-bit address space is really hard to effectively randomly probe working addresses and partly because it's fairly easy to configure a firewall to not allow incoming connections.
Need a Python, C++, Unix, Linux develop
Lest anyone think this jackass is correct:
IPv6 barely supports firewalls or NATs, allowing any Joe Sixpack to see what your secured corporate network topology is like from anywhere.It is not up to the protocol to support the hardware. And anyway, all good firewalls support IPv6 already. NAT? It's there if you're dumb enough to want it.
It also does not support reserved IP blocks... change ISPs, and you are forced to re-ip your whole network.Step one: update your router to the new netblock.
Step two: sed -i'' 's/^old:net:block/new:addr:ess/' db.mydomain.com; rndc reload
Step three: laugh at people who go around changing ISPs all the time.
Of course, IPv6 has -zero- hooks for IP level encryption, so this has to be handled at the trensport or app level.If only it support IPSec, "the goal of [which] is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments." Oh, wait...
Dewey, what part of this looks like authorities should be involved?
While I would love to agree with you completely as I believe ARIN is a bunch of tards (can't speak for the other registries). There are/were technical reasons behind the way IPs are assigned. Machines haven't always had 2 gigs of ram. Maintaining routing tables on a network the size of the Internet was a difficult task, which required aggregating networks at upstream links and all sorts of stuff in a desperate attempt to prevent every multihomed router on the Internet from needing a few gigs to hows the paths to various subnets and determine what path was the best.
... do this on hardware from 10-15 years ago. Well, first off, unless your at a NAP 10 years ago, doing this would require expensive memory upgrades on your routers because most didn't have the ram required to deal with a such a routing table in the first place, now add in the processing increase your going to need because even though you can cache routes and deal with updating the cache only as the external paths change, it only helps so much because those external paths change a lot so your cache hits have to be revalidated more often than you think. God forbid you have a flapping connection, as I can tell you from personal experience, on many routers from 15 years ago, a flap of a line that relays BGP information resulted in a router that was busy for a few seconds dealing with the BGP changes unless it was a fairly high end router.
... the point to all that is, a lot of the way address space was assigned was because the hardware we had to work with 'back in the day' was only capable of so much.
...
... this is how businesses make money, but not doing extra work they are just going to have to do again later if they can prevent it.
... just like all the ones who made out over y2k fears/bugs.
Of course, time goes on, ram is cheap, and doing it now is somewhat easier, but it still requires ram and processing power, and that increases latency and cpu utilization.
For instance, assume that everyone was assigned address space in blocks of 256 address (class C) and had to show they utilized the address space before getting more as well as prove they continued to use it. Now assume that only half of the address space available was assigned. 2.1 billion addresses in use. Thats approximately 8.3 million class C blocks
allocated. I'm going to assume thats higher than what we have actually in use these days (not allocated, in use) but bear with me for reference purposes.
Now, for each packet you route, you have to search through those allocated blocks and find the one that contains the address you're communicating with. You also have to determine which path of the many you may have on your router is the best path to use based on number of hops to the destination (we'll pretend AS hops are real hops for simplicity), include other factors such as your internal weights for a route because its expensive for you to use the OC3 you have rather than the DS3 because you got a great deal on the DS3 but not so much on the OC3.
You've just spent a lot of CPU cycles trying ot figure out which path to use. Now
So
Okay, so now we can do better, great! Lets readdress everyone
I'm not going to bother going into the complexities of re-addressing a large network, but its rather a pain in the arse and can cost a whole hell of a lot of money in IT resources. So when you look at the big picture and think, 'well, I can readdress now and help deal with the problem and then have to eventually switch to the new protocol (for now, IPv6) eventually anyway OR I can wait till everyone has to switch to the new protocol because of this problem and only do it once'
It makes more sense to wait and do it at once, save yourself some money, deal with it when everyone else does, and deal with the least amount of work you can until that time. And
Of course, on that same note, there are plenty of businesses which don't exist yet that will make a killing off the scare of running out of IPv4 address space and the switch to IPv6
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The sad part is, most of the IP addresses in question are... dark. Nothing there. Even though we're approaching 85% allocation, utilization is probably around 1-2%. No, I'm not kidding.
And you have ANY hard data to back that up ? No. Others are trying to come up with better metrics (http://www.potaroo.net/tools/ipv4/index.html is exceptionally verbose), but you ? You are not kidding about thinking that it maybe probably is around 1-2% ... Wow.
Try it yourself - hack up some script to randomly generate IPs and then ping sweep the network blocks. You'll probably be quite surprised at the result.
Bzzzt. No, I would not be -- nor should anybody be. First of all, it's not a requirement for every address to be routable to (and you can check that much better by looking at what percentage of prefixes are actually advertized). Second, many, MANY hosts and networks are behind firewalls, intrusion detection & response systems, etc. -- a "simple pingscan" can easily land you in a black hole at the network border after a couple of pings -- if access to those machines is even allowed from your network. Sure, in consumer broadband connections you don't often have such firewalls restricting inbound access, but that's not the "entire internet". Hell, go ping amazon.com and see what you get back. Nada, that's what.
A while back, I wanted to have a way to detect if a host was "offline" so that it could modify its behavior. (EG: halt outgoing SOAP requests if the server's network connection was disrupted, preventing bogus error messages from entering the system)
A problem many others have faced and solved before you.
My first thought was to randomly generate 10 IP addresses, then ping them to see if they were offline, guessing that at least 50% would respond.
Accounting for the different classes of addresses, unroutable space, bogons, etc. in that random calculation would be more work than the result is worth, especially seeing as how the state of netblocks can change over time. I wonder, why was your first thought to crap out (at least) 10 packets to the net that really are not needed ? What possible reason could there be for you to automatically ping a cellphone in Singapore ? Just imagine everybody doing this, just to check whether they are "online" ...
How about choosing some well-known addresses (such as one of your own servers in a different locale, or possibly "well-known" servers that you know will respond and that don't mind a ping from you every now and then ... Not only do you get a 100% response rate when everything is working correctly, you also forego abusing bandwidth in remote locales you are not at all interested in.
Basically, none did. So, then I tried randomizing addresses and keeping a list of only those that had, at one time, responded. Even that turned out to be unfruitful.
You know, while still a bit dickish, it might have occured to you that most of {a-m}.root-servers.net do reply to ping or DNS requests. So do, in all likelihood, a router in your upstream, or DNS resolvers you know about. Instead, you now latch on to addresses that respond. The cellphone in Singapore, for instance.
So finally, I took a dictionary and randomly created domain names from 1-2 normal dictionary words, pinging those, and keeping a list.
Ah. So now that flooding ICMP out to the net is not enough, you have to litter it with bogus DNS requests the reply to which you are not really interested in. Again, imagine EVERYBODY doing this. Why not pick 10 known domain names and always ping those ? At least the results will be cached, and you may even choose ones whose owners you know and can ask whether they mind to be flooded with icmp every now and then.
That yielded some 40% usable responses, allowing me to keep a list of fairly