Free IPv4 Pool Now Down To Seven /8s
Zocalo writes "For those of you keeping score, ICANN just allocated another four /8 IPv4 blocks; 23/8 and 100/8 to ARIN, 5/8 and 37/8 to RIPE, leaving just seven /8s unassigned. In effect however, this means that there are now just two /8s available before the entire pool will be assigned due to an arrangement whereby the five Regional Internet Registries would each automatically receive one of the final five /8s once that threshold was met. The IPv4 Address Report counter at Potaroo.net is pending an update and still saying 96 days, but it's now starting to look doubtful that we're going to even make it to January."
http://en.wikipedia.org/wiki/IPv4_address_exhaustion
No kitty, this is my pot pie!
Class E? That "reserved" block, for "future expansion"? That "future expansion" would be now.
There you go, another 16 blocks to break out. Plus the 7 we already have, that makes 385,875,968 addresses left still unallocated. Still over a third of a billion to go, which should be more than enough time for everyone to replace equipment that doesn't support IPv6, and deal with applications like Teredo that leak IPv6 address space across NATs and through VPNs.
THE INTERWEBZ EXPLODZ!!! Ok no seriously, once ICANN allocates the final blocks the IPv4 space will be declared as "used up" but it is still up to the regional RIRs to *use* those IPs. ie if ICANN issues IPs they are not automatically used. Thus it will still be a while after that when they are really all used up. Even then we could maybe see a sharing of sub-blocks between regional RIRs (?) For example AfriNic will probably have quite a surplus if it receives another /8 range.
Lastly there are (not so preferable) technologies available such as NAT to allow the internet to continue functioning as it did (more or less).
In the end we will need to move to IPv6.
it is still up to the regional RIRs to *use* those IPs
Regional Internet Registry.
sic transit gloria mundi
status of comcast ip6 http://www.comcast6.net/ at&t - lagging http://www.networkworld.com/news/2010/102710-att-ipv6.html
It's not just providers. There're enterprises who have some quite expensive routers that don't do v6. Not all home gear does v6; my iPhone 3G doesn't, and I'm pretty sure some of the consoles I have don't do it either. My printer doesn't. There are solutions to this, but that's still more work.
SSC
They did not bother, because they thought if there was a freaking decade to roll it out, that would be plenty of time.
Go green: turn off your refrigerator.
Sure I have, /22, /23 are used all over the place.
But I doubt anyone would except your announcement if it was a /25.
New things are always on the horizon
3ffe:1900:4545:3:200:f8ff:fe21:67cf
That would be 63.254.25.0.69.69.0.3.2.0.248.255.254.33.103.207 using your scheme which is horrible. Is also leaves out the most useful compression feature, so you can write 3ffe:1900::/32 instead of 63.254.25.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0/32. Just counting out the correct numbers of .0 is horrible.
Practical real life IPv6 addresses often use compression: ipv6.l.google.com has IPv6 address 2a00:1450:8005::63, ipv6.myip.dk has IPv6 address 2001:470:27:f9::2, ipv6.net has IPv6 address 2a00:1188:5:2::8. If you care about your address you can make it short, since the last 64 bits is yours to decide.
Any iOS device with 4.0 or later supports IPv6, including your iPhone.
Actually it does support TLS, it just doesn't support SNI. Or actually IE and Safari only, because they use the windows library. Firefox and Chrome use the library first developed at Netscape and Opera uses OpenSSL.
But as SNI is the part that adds 'Namebased virtual hosts' to TLS, the result is the same as you mentioned. Everything that wants to use a certificate still needs it's own IPv4-address (and/or IPv6 address) for now.
New things are always on the horizon
Just tacking on more numbers becomes a problem because IPv6 addresses are 128 bits long and not 32 bits like IPv4. 1.1.209.85.255.147 is only a 48 bit number. An example of a 128 bit IP address in decimal would be 209.85.255.147.236.152.95.220.51.119.152.21.201.103.118.1 Having to use up to 64 digits to describe one address is not efficient, even if using only numbers are easier to say or remember than alphanumeric hex.
That being the case, we as a culture have also decided that decades start a year x0, centuries start at x00, and millenniums start at x000.
No we have not. You will have a very hard time relating to historic dates if you think so. Ever wondered why we are currently in the 21st century and not the 20th? Because the first century was not the number 0 century, as you would have it. The same way, the first year was not the number 0 year, the first decade was not the number 0 decade and the first millenia was not the number 0 millenia.
Just because uneducated people have a hard time grasping this, does not make it less so. If you start calling this the 20th century just because the year is 20xx you will not be understood correctly.
That said, because the general public seems to be quite uneducated about our calendar system, the mainstream media must be careful when the exact years of the boundaries of decades, centuries and millenias is important. Books for professionals can assume the reader knows the calendar.
Configure your home router to pass the port for whatever service you want to access from work to the system that can deal with it at home. Connect to that address using that port.
This is where the trouble begins. You can do this today because it is _your_ router doing the NAT. With no more IPv4 available, you will be sharing your IPv4 with your neighbours. This means carrier NAT. How do you program your ISPs router? You don't.
Privacy
a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
Not true at all. It is possible to establish a direct peer to peer connection between two hosts which are *both* behind NAT. You do need a "rendezvous" server to bounce a few packets - that's not hard to do, and can be easily accommodated as part of any other P2P infrastructure (or even outside of it).
In fact, running P2P in that manner would significantly increase privacy of its participants because to anyone outside a given network there will no longer be a visible single mapping of IP to a "person" (or household etc).
Well, first of all, it sort of is. The typical way to get an address on an IPv6 network is stateless auto-configuration, which basically allows your client to combine an advertised route prefix with the EUI-64 (basically a longer version of a MAC address that can be generated from a MAC address) to determine its IP. You don't need any configuration for new clients and they always get the same IP address. Note that Windows Vista/7 use a hashing function with random data and the MAC address so that you can't track a single machine based on its IPv6 address, which solves privacy concerns.
Second, you can't just use the MAC address because it's not easy to route traffic that way. Routing works today because networks are assigned contiguous blocks of addresses, so it's easy to tell where to route traffic based on the address prefix. If we just had MAC addresses (which contain no information about which devices are connected to which networks), routing would require huge tables that would frequently change. This works OK for a small to medium sized network (e.g. switched Ethernet) but it doesn't work at all for the Internet. Even medium-large organizations need to use subnets to effectively manage traffic, which aren't possible without network prefixes.
FTFY
What is the difference for IPv6 ?
Their currently is one IPv6-DNS-blocklist, they use something like: 5 bad IP's in one /64, block the whole /64, 5 bad /64 block the whole /48. Or some system like that.
Or do you mean their isn't enough tooling yet ?
New things are always on the horizon
Lots and lots of documentation on that. Google for "nat" and "rendezvous".
Here is a first random link I came up with: http://www.brynosaurus.com/pub/net/p2pnat/
Basically, rendezvous server (a host with "real" IP out there) punches a "hole" in each NAT for and on behalf of the respective counterparty. Once it made those "holes", parties communicate directly. Done.