Because even back in '92 they could see a time when 40 bits wouldn't be enough. So rather than choosing a limit based on the number of nodes they chose a scheme that would allow cheaper and faster routing. If you can allocate the addresses so that a short prefix eg: 2a00:1450:8006::/48 goes to one physical location the size of the routing tables drops and the speeds go back up.
As for remembering IP addresses, I don't. I'll remember a network address like 10.243.56.0/24 but I'll always put a short name against the address (eg: dc01, t41b, tv, cam1). So if even if there's a short IP like Googles 2a00:1450:8006::93 I'll use the name.
With an address space of only 64 bits the routing tables are still likely to be large (exacerbated by recent allocation policies). Full CIDR routing practices will have to be followed because some sites will need a/40 or larger. (ignoring your evil/-2 suggestion!) Normal sites/users will probably have to be limited to a/58 ie 256 (254) addresses.
The packet is slower to process (uses more CPU time) than a simple packet; especially as all the options have to be checked every hop (even with the ordering limitation).
There is no way for an IPv4 router that doesn't understand Option 29 to realise that it's about to fuckup big time. It will route the packet based on the least significant bytes of the address and so the only way to make it do a slightly 'reasonable' thing is to have the words of the address inverted in order relative to the bytes in the words!!!
Current allocations will have to be reclaimed and reallocated otherwise we'll still have an address shortage problem (or a routing table size problem). This is far harder than allocating from a clean new pool.
In the end every IP header will carry a fake 'Option 29' that servers no purpose on the modern internet wasting time and transmitting junk for the rest of time. You will be cursed by every tecky till the sun goes cold.
IPv6 was chosen from the candidates in part because it isn't a "dirty hack". It's a reimplementation of the core parts of IPv4 that have proven to be good choices. The less useful parts have been pushed out to the edges of the network so the core megarouters of the network can run faster and more reliably. The only major 'baggage' of IPv6 is IPSec, this is an end to end protocol so doesn't impact the core performance. In fact it's a bolt on to such a large part that the right 'red pen' could remove it from the standard in a few seconds.
There is one thing that's missing though. How to make a really crap piece of IPv6 hardware/software without it failing completely. So at this point in time if you buy good equipment it will work perfectly. If you buy cheap crap it will fail; unlike IPv4 where the cheap crap will, kinda, work.
This can also have an impact where the IPv6 is tunnelling over crap IPv4 stacks.
You know a whole new IPv4 internet of IP addresses would last about 9 years at the current allocation rates. Rates that are in fact going up in an exponential manner in some parts (two of five, including the largest) of the world. It would also make the global routing tables even worse than they now are.
Yep, DJB is pretty good at that. His arrogance shows through in a lot of his writing, unfortunately he is often right, at least in part. He's right, in part, here too the switchover from IPv4 to IPv6 is a PITA, but all his objections were raised around ten years before he thought of them and this was the best solution. (he wrote this in 2002, IPng was being designed in 1992 and was eventually assigned as IP version 6)
One thing he doesn't seem to understand is the actual nature of a packet network. The fact that every packet must have the address of the host it's going to. So for his seamless scheme to connect IP hosts with IPng hosts to work the IP host must be able to put a huge (128/256/variable bits) IPng address into the 4 bytes available in an IP packet. This is obviously physically impossible. Though it can be faked by creating a connection oriented proxy; eg: with NAT. Of course that brings a load more problems.
He also seems to think that the 16777216 addresses available in 10.0/8 are enough for any local network; the mobile phone companies will disagree big time.
Nope, not a typo. I hadn't even noticed the difference in terminology.
Though, really, I don't see any difference between the two methods worthy of a difference in name. Using an anycast address and implied IPv6 addresses is a really minor difference to using a fully configured point to point tunnel. Now "6over4" where you again have exactly the same protocol but interfere with the link addresses is such a difference. Or maybe not, it's just "6in4 with ipv4 link addresses"...
You're probably even using the same supplier for "6to4" as you do for "6in4".
Scheesh, what's this "6rd" thing. It's not even original it's just (err... ) "6to4" with different numbers!!
I am NOT. The ISP is forcing NAT on the IPv4 connection and IPv6 tunnels don't work through it.
BTW: NAT isn't a firewall. If you have a firewall that does NAT it will probably work like a reasonable firewall even when the firewall part is turned off. BUT a pure "full cone" NAT works by creating port mappings from the public to the private. Once a port is open anything goes through; a modern firewall only lets through the original connection.
"Hurricane Electric" will give me a 6to4 tunnel; that needs IP protocol 41 to get through to me. Works fine if I have a public IP but needs admin access to a NAT device.
I can use the anycast 6to4 address 192.88.99.1 for my 6to4 endpoint, but that's the same as a registered tunnel plus it's a bit of a pain if you have a dynamic IPv4 address.
I can use teredo but while that works properly through 'full cone' NATs (ie really dumb ones) it's anything from unreliable to completely broken for real ISP style NATs.
So has anyone got a reliable IPv6 connection through a real (ISP like, "commercial grade") NAT device, with multiple sessions going through it?
That gives you two weeks and the current world burn rate. Just barely enough time for a committee to decide to scratch their collective asses.
What will probably happen to that block is that it'll stay in ARIN's pool and be reallocated to America/Canada. For just America I understand it might give you a month and a half or so.
APNIC -- Asia Pacific region, have just been allocated 2 more/8's, once the final distribution is done they will have just under 6 free/8's allocated to them. This is expected to last until September... THIS Year.
The current 'burn rate' of/8 for the world is about one every two weeks. Whatever happens IPv4 is running out of addresses RIGHT NOW and it will mean that ISPs will be running out before the end of 2012, some of them by the end of this year.
The Mayans were right. The end of the world is nigh!
You will not connect to anything in the 240.0 to 255.0 address range, windows will error. Windows isn't the only one.
Plus at the current burn rate 16/8s will last just seven months...
Some of the mobile operators are getting close to the stage where they need an entire IPv4 internet just for their devices and there are already more devices connected to the internet than there are addresses.
I've got 10/10 for both IPv4 and IPv6 using firefox with adblock and NoScript. I get some complaints unless I unblock them from NoScript but I still get 10/10.
That isn't the problem, as far as we can tell the hardware is intact turned on and working. The problem is that key software has been turned off, with a finger on the right keyboard it could be turned back on straight away.
You think you're joking, but in Windows a lot of the GUI stuff depends on timer ticks and it's very easy to end up waiting for the next tick. So it doesn't matter how fast the CPU is, some jobs will take exactly the same time.
Possibly the worst part of this is that for "windows task manager" the CPU time taken by these timer tick tasks is invisible. The tick is assigned to whatever task is running at the end of the timer tick and these tasks must not run that long because they'll run into their next start time. Occasionally this can mean that 90% of the CPU time is just 'lost'.
Still a 20-30 second wait is likely to be the result of caching (indexing?), a machine on the network is assumed to still exist, but it was turned off six months ago...
But it might also be the Von Neumann Bottleneck. If your working set - either data or instructions - is bigger than the on-chip caches, you get constant cache misses. It's like thrashing but between cache and memory rather than between memory and the swap partition.
This manifests as a larger than expected CPU time on just about every performance tool you can mention.
If you're running multiple tasks you can sometimes measure it as a decrease in the amount of work done per cycle in other tasks on the machine.
If they're bribing someone it's reducing their profits. A bribe is "lost money".
I guess you mean they dropped their prices, but if you mean they started putting in some Microsoft style anti-competitive terms into their OEM contracts, this can only work if you've got a near monopoly, Intel are not in that position. They could get away with it in the short term because lead times on new designs are very long, but in the longer term working round such contract terms isn't difficult and the differences between AMD and Intel hardware are so minor that the "take my marbles home" threat is quite realistic.
Well, yea. I did say I've got a firewall. But really the address isn't worth much.
You see it's not a 'false sense' of security, it's an extra layer of security. With client devices choosing their IP addresses they can choose to change the IP address on a schedule so your logs are valid for only a short time. Windows does this by default and it can be turned on with Linux. So if your log is more than a few hours old the machine has moved to somewhere else in the::/64. (See:/proc/sys/net/ipv6/conf/all/use_tempaddr )
Slashdot Mirror
T-Mobile already have this problem.
They use network 10 repeatedly, they use (formerly) bogon (unallocated) addresses and HUGE NATs.
They're moving to IPv6 ONLY and using NAT64 only to talk to the IPv4 internet.
Because even back in '92 they could see a time when 40 bits wouldn't be enough. So rather than choosing a limit based on the number of nodes they chose a scheme that would allow cheaper and faster routing. If you can allocate the addresses so that a short prefix eg: 2a00:1450:8006::/48 goes to one physical location the size of the routing tables drops and the speeds go back up.
As for remembering IP addresses, I don't. I'll remember a network address like 10.243.56.0/24 but I'll always put a short name against the address (eg: dc01, t41b, tv, cam1). So if even if there's a short IP like Googles 2a00:1450:8006::93 I'll use the name.
Can the sarcasm it's really happening T-Mobile already cannot get enough addresses.
Reported by Derek Morr about a presentation by Cameron Byrne
Okay, quickly ...
IPv6 was chosen from the candidates in part because it isn't a "dirty hack". It's a reimplementation of the core parts of IPv4 that have proven to be good choices. The less useful parts have been pushed out to the edges of the network so the core megarouters of the network can run faster and more reliably. The only major 'baggage' of IPv6 is IPSec, this is an end to end protocol so doesn't impact the core performance. In fact it's a bolt on to such a large part that the right 'red pen' could remove it from the standard in a few seconds.
NAT-PT put NAT in as part of IPv6 in many peoples eyes.
The new names NAT64 and NAT46 make it explicit that these are transition features for the early and late periods respectively.
The pragmatic result is the same; the political result is that they are IPv4 standards not IPv6 standards.
IPv6 is robust and working very reliably.
There is one thing that's missing though. How to make a really crap piece of IPv6 hardware/software without it failing completely. So at this point in time if you buy good equipment it will work perfectly. If you buy cheap crap it will fail; unlike IPv4 where the cheap crap will, kinda, work.
This can also have an impact where the IPv6 is tunnelling over crap IPv4 stacks.
You know a whole new IPv4 internet of IP addresses would last about 9 years at the current allocation rates. Rates that are in fact going up in an exponential manner in some parts (two of five, including the largest) of the world. It would also make the global routing tables even worse than they now are.
This is why NAT isn't a viable solution.
Yep, DJB is pretty good at that. His arrogance shows through in a lot of his writing, unfortunately he is often right, at least in part. He's right, in part, here too the switchover from IPv4 to IPv6 is a PITA, but all his objections were raised around ten years before he thought of them and this was the best solution. (he wrote this in 2002, IPng was being designed in 1992 and was eventually assigned as IP version 6)
One thing he doesn't seem to understand is the actual nature of a packet network. The fact that every packet must have the address of the host it's going to. So for his seamless scheme to connect IP hosts with IPng hosts to work the IP host must be able to put a huge (128/256/variable bits) IPng address into the 4 bytes available in an IP packet. This is obviously physically impossible. Though it can be faked by creating a connection oriented proxy; eg: with NAT. Of course that brings a load more problems.
He also seems to think that the 16777216 addresses available in 10.0/8 are enough for any local network; the mobile phone companies will disagree big time.
Yes! This looks like it'll work till June, when I can give this ISP "the old heave ho".
Nope, not a typo. I hadn't even noticed the difference in terminology.
Though, really, I don't see any difference between the two methods worthy of a difference in name. Using an anycast address and implied IPv6 addresses is a really minor difference to using a fully configured point to point tunnel. Now "6over4" where you again have exactly the same protocol but interfere with the link addresses is such a difference. Or maybe not, it's just "6in4 with ipv4 link addresses"...
You're probably even using the same supplier for "6to4" as you do for "6in4".
Scheesh, what's this "6rd" thing. It's not even original it's just (err ... ) "6to4" with different numbers!!
Okay, okay I give up, call it what you like!!!!
I am NOT. The ISP is forcing NAT on the IPv4 connection and IPv6 tunnels don't work through it.
BTW: NAT isn't a firewall. If you have a firewall that does NAT it will probably work like a reasonable firewall even when the firewall part is turned off. BUT a pure "full cone" NAT works by creating port mappings from the public to the private. Once a port is open anything goes through; a modern firewall only lets through the original connection.
"Hurricane Electric" will give me a 6to4 tunnel; that needs IP protocol 41 to get through to me. Works fine if I have a public IP but needs admin access to a NAT device.
I can use the anycast 6to4 address 192.88.99.1 for my 6to4 endpoint, but that's the same as a registered tunnel plus it's a bit of a pain if you have a dynamic IPv4 address.
I can use teredo but while that works properly through 'full cone' NATs (ie really dumb ones) it's anything from unreliable to completely broken for real ISP style NATs.
So has anyone got a reliable IPv6 connection through a real (ISP like, "commercial grade") NAT device, with multiple sessions going through it?
If they demand a surcharge make sure you don't pay it to your ISP.
Use a 'VPN' service for IPv4. eg: Swiss VPN give you an unfiltered public IPv4 for just 6 CHF per month.
Of course IPv6 tunnels are there for the asking.
So what?
That gives you two weeks and the current world burn rate. Just barely enough time for a committee to decide to scratch their collective asses.
What will probably happen to that block is that it'll stay in ARIN's pool and be reallocated to America/Canada. For just America I understand it might give you a month and a half or so.
He won't, it won't look original any more.
But you can do it. Here's the source data.
Just to put the rates into perspective ...
APNIC -- Asia Pacific region, have just been allocated 2 more /8's, once the final distribution is done they will have just under 6 free /8's allocated to them. This is expected to last until September ... THIS Year.
The current 'burn rate' of /8 for the world is about one every two weeks. Whatever happens IPv4 is running out of addresses RIGHT NOW and it will mean that ISPs will be running out before the end of 2012, some of them by the end of this year.
The Mayans were right. The end of the world is nigh!
Long live the world (of IPv6).
You run MS windows right ?
You will not connect to anything in the 240.0 to 255.0 address range, windows will error. Windows isn't the only one.
Plus at the current burn rate 16 /8s will last just seven months...
Some of the mobile operators are getting close to the stage where they need an entire IPv4 internet just for their devices and there are already more devices connected to the internet than there are addresses.
At the current burn rate it's actually less than half a month per /8 ...
I've got 10/10 for both IPv4 and IPv6 using firefox with adblock and NoScript. I get some complaints unless I unblock them from NoScript but I still get 10/10.
That isn't the problem, as far as we can tell the hardware is intact turned on and working. The problem is that key software has been turned off, with a finger on the right keyboard it could be turned back on straight away.
You think you're joking, but in Windows a lot of the GUI stuff depends on timer ticks and it's very easy to end up waiting for the next tick. So it doesn't matter how fast the CPU is, some jobs will take exactly the same time.
Possibly the worst part of this is that for "windows task manager" the CPU time taken by these timer tick tasks is invisible. The tick is assigned to whatever task is running at the end of the timer tick and these tasks must not run that long because they'll run into their next start time. Occasionally this can mean that 90% of the CPU time is just 'lost'.
Still a 20-30 second wait is likely to be the result of caching (indexing?), a machine on the network is assumed to still exist, but it was turned off six months ago...
But it might also be the Von Neumann Bottleneck. If your working set - either data or instructions - is bigger than the on-chip caches, you get constant cache misses. It's like thrashing but between cache and memory rather than between memory and the swap partition.
This manifests as a larger than expected CPU time on just about every performance tool you can mention.
If you're running multiple tasks you can sometimes measure it as a decrease in the amount of work done per cycle in other tasks on the machine.
If they're bribing someone it's reducing their profits. A bribe is "lost money".
I guess you mean they dropped their prices, but if you mean they started putting in some Microsoft style anti-competitive terms into their OEM contracts, this can only work if you've got a near monopoly, Intel are not in that position. They could get away with it in the short term because lead times on new designs are very long, but in the longer term working round such contract terms isn't difficult and the differences between AMD and Intel hardware are so minor that the "take my marbles home" threat is quite realistic.
Well, yea. I did say I've got a firewall. But really the address isn't worth much.
You see it's not a 'false sense' of security, it's an extra layer of security. With client devices choosing their IP addresses they can choose to change the IP address on a schedule so your logs are valid for only a short time. Windows does this by default and it can be turned on with Linux. So if your log is more than a few hours old the machine has moved to somewhere else in the ::/64. (See: /proc/sys/net/ipv6/conf/all/use_tempaddr )
Oh god, every device has an infinite number of addresses.
WHAT did you say about reverse DNS ?