What about IPv6 right here on earth?
What about IPv6 right here on earth?
Posted Jan 25, 2011 18:30 UTC (Tue) by cmorgan (guest, #71980)In reply to: What about IPv6 right here on earth? by daniel
Parent article: LCA: Vint Cerf on re-engineering the Internet
Posted Jan 25, 2011 20:24 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (31 responses)
... in the US.
Posted Jan 25, 2011 22:14 UTC (Tue)
by daniel (guest, #3181)
[Link] (1 responses)
...or anywhere else.
Posted Jan 26, 2011 9:10 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Jan 25, 2011 22:18 UTC (Tue)
by drag (guest, #31333)
[Link] (28 responses)
Although Just This Weekend I got a /48 network assigned to me for free.. as well as a /64 network. For my personal use.
This was for FREE. No cost. It was easier signing up for a ISP size of networkable addresses then it is for most internet forums. All these addresses are routable on the internet. Meaning if you have a computer on IPv6 network on the internet you can reach any of those IP addresses. I could provide addresses for a good sized country with what I was given for nothing.
How much does your company pay for IPv4 addresses? I know I can get extra ones from my ISP for about 10 dollars a month or something like that.
I now have 1,208,925,819,614,629,174,706,176 worth of internet addresses to play around with.
Or something else like that that is completely insane. Over 25 thousand subnets? I still have a hard time grasping the numbers.
And talk about security... have you ever wanted remove the ability for anybody to portscan you? They have a mode of addressing IPv6 addresses now were you literally pick a random address for yourself every 5 minutes or so. Even every new connection if you would like. And it works fine... you can have dozens of addresses assigned to a single network connection and you just drop them as TCP sessions end. Fantastic stuff.
Want to be able to control what is allowed on your network? They have a mode of addressing were machines pick out for themselves new addresses based on a cryptographic scheme. Unless a machine is able to guess what new IP address is in the sequence then it won't be able to use your network.
Now compare that to the IPv4 world were we they are now moving to carrier grade NAT called NAT444. Meaning that your tunnelling Ipv4 addresses over IPv4 IPs being tunnelled through IPv4 IPs. NAT routers being NAT routers behind NAT routers!
You DO NOT have to put up with that crap!
http://tunnelbroker.net/main.php
If your in the USA don't be a internet luddite! Join the IPv6 revolution today!
:-D
Posted Jan 26, 2011 1:21 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (26 responses)
Posted Jan 26, 2011 3:42 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (25 responses)
If you mean that they are literally not to configure anything whatsoever, including with autoconfiguration if that's provided by the OS then: No, obviously. Without a configuration change you're stuck with IPv4 and if we could have figured out a way to make hundreds of billions of nodes addressable using IPv4's 32-bit addressing, we would have used this hole in number theory to solve world hunger or make our own pocket universe or something not wasted time on trivia like the Internet.
If you meant reconfigure the local node (possibly automatically) but not any intermediary nodes in the network the answer is yes, with a caveat. You will have to tunnel, and so you may (will) have a less direct route than you would natively and the overhead of the tunnel. Several autoconfigurable (ie you say "I want to enable this" and then it works) tunnel protocols exist, with varying parameters for how much infrastructure someone else has to have built somewhere (an anycast address? a router? lots of routers?), what sort of performance you can expect and how robust it will be against badly designed NAT / firewalls / etc.
This isn't how things could really work for most people though. A world of tunnels and ad-hoc connectivity is not a future millions of people can live in, it's temporary local solution. ISPs will have to deploy native IPv6, the problem is that they should have done this (at least) five years ago, and instead they'll probably start just after it's too late.
Posted Jan 26, 2011 7:49 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (24 responses)
Like this. I have my DNS configured now. I have my DHCP configured now. I have my static hosts configured now. I have my firewalls configured now. I have my services configured now. Without touching any of that (i.e. configuration), can I talk to IPv6 hosts out there? I'm guessing the answer to this question is probably no.
What DJB pointed out is that deployment of new software on all computers in existence is surprisingly easy (in fact, it happens all the time with updates). Deployment of new configuration is hard (each admin has to figure out their new addresses, firewalls, DNS, tunnels etc.). Ergo, IPv6 should have embedded IPv4 in itself. And because it didn't, we have the current interoperability disaster where hosts with IPv4 addresses cannot talk to hosts with IPv6 addresses natively.
Sure, eventually all this will be overcome and we'll all end up being on IPv6, but the plan was not very good.
Posted Jan 26, 2011 8:10 UTC (Wed)
by dlang (guest, #313)
[Link] (15 responses)
the issue is having a transition while everyone still has addresses that fit in 32 bits that would allow some machines to be on IPv4 and some machines to be on IPv6, all talking togeather, and it would only be as machines started to use addresses that didn't fit into 32 bits that there would be any incompatibility.
If this had been done, most of the systems out there would be running IPv6 now, and talking to IPv4. but since IPv6 was made completely incompatible with IPv4, running IPv6 became a significant effort rather than a transparent upgrade. As a result, almost nobody is running IPv6 except as a showpiece or hobby.
Posted Jan 26, 2011 8:48 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
I already have all this for IPv4, so doing this duplicative work is really idiotic. If DJB's suggestion was followed, my various OSes would already have been upgraded to understand 16 byte long addresses and it would just work.
PS. And I am actually interested in making a transition. Many large companies don't see anything being done related to IPv6 for the next few years at least. Simply too much hassle for no immediate benefit.
Posted Jan 26, 2011 16:10 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (13 responses)
1. IPvDlangA is deployed on some boxes. This hypothetical protocol is just 100% compatible with IPv4 so these boxes can talk directly to IPv4 boxes.
IPvDlangA is junk - it doesn't get us anywhere we weren't with IPv4 so it doesn't matter if its deployed or not.
2. IPvDlangB is deployed on some boxes. This is a very sophisticated hypothetical protocol. It uses some magic IPv4 flag bits to detect other IPvDlangB boxes and when talking to them it embeds enhanced 128-bit addresses, with the top 96 bits cleared. To transit over the IPv4 network the packets must of course all have valid IPv4 headers too.
Everybody who gets IPvDlangB sees slower performance AND less bandwidth because IPvDlangB is wasting a lot of both. So every smart individual or organisation disables or avoids IPvDlangB. No uptake.
3. IPvDlangC does protocol conversion. It probes next hop routers (good luck with that) and if they also do IPvDlangC it speaks IPvDlangC otherwise it converts every packet to IPv4 and strips 96 bits of address. When receiving packets from such routers, it adds 96 bits of zeroes, and converts to IPvDlangC.
IPvDlangC is very resource-intensive, far more than mere IP routing. It would be tremendously expensive to deploy in core systems. This expenditure will never be authorised. In terms of development effort, code footprint, attack surface etc. it's much the same as the dual-stack solution today except without any of the benefits.
Do you have more options? We can look at those too (I can't promise to be swift, I have lots of real work to do)
Posted Jan 26, 2011 20:45 UTC (Wed)
by dlang (guest, #313)
[Link] (12 responses)
you could have left the existing 32 bits of addressing where they are in the packet header and set an option flag to enable additional addressing bytes later in the header.
If you did something like this, the 32 bit addresses would route you to the ISP that handles the 'full' address, and that ISP could have a router that implemented NAT by just grabbing the bottom 24 bits of the expanded address space and using the 10/8 network with these addresses internally (or a different class A could have been allocated for this purpose)
this would have allowed the address space to be transparently extended from 32 bits to 56 bits without any existing routers needing to be changed at all (including home routers), the client endpoints would need new software to send the extended headers, and the ISPs that run out of addresses would have to have new routers to move the bits from one point in the headers to the other (which is a _very_ cheap thing to do, much cheaper than current NAT where the router needs to maintain a table of translations, time them out, etc).
systems with the new 'extended' IP addresses would have trouble initiating connections outside their ISP to endpoints that did not include these additional headers in their response packets, but all that would take is 'if you see this flag and extra info in the headers of a packet that comes to you, include them in the response', and that's a pretty simple thing for the OS vendors to do.
I'm not worried about network vendors doing this for the network gear, as that should not have to be maintained across ISPs
Posted Jan 27, 2011 12:21 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (11 responses)
First of all you've moved the legacy 32-bits from a suffix, in one corner of the address space, to a prefix. So you don't actually fix the exhaustion problem, because now there are far more addresses, but they're still all allocated to someone already. So your whole plan just wastes everybody's time. Ouch.
And your "pretty simple thing for the OS vendors to do" needs to be done in every IP stack deployed, which realistically means it needs to be in IP itself, or in one of the very early tweaks. By the 1990s it's just too late to make a difference. (IPng working groups were created in 1992 or so)
FWIW Solutions that require time travel (e.g. to go change the IPv4 standard before it was widely deployed) are cheating. Sorry, try again?
Posted Jan 27, 2011 18:55 UTC (Thu)
by dlang (guest, #313)
[Link] (8 responses)
and the IP spec has been changed over time to include new features. there are reserved feature bits in the header that could be used to indicate the presense of these changes.
this is just plain going to be a horrible mess. there are few possible outcomes
1. we have a long period of using NAT and then move to IPv6
2. we have a long period of using NAT and then move to something else (probably at least as painful in the meantime as the move to IPv6)
3. extensive use of NAT becomes permanent
4. the internet as we know it collapses (extremely unlikely in my opinion)
Posted Jan 27, 2011 22:49 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (7 responses)
Surprisingly little has changed in IP, except in cases where two peers can identify that the other implements some newer feature. Most of what gets done in the stacks is optimisation, taking advantage of features that exist in the specification already. And sometimes even that fails - just because the specification says you can do something, does not mean it always actually works in the real world. Life is full of disappointments.
Yes, there will be a mess. That is not a new observation. We have no useful prior experience to judge exactly how big the mess will be. Some of the things we've been doing to try to give ourselves more time will, as with NAT, contribute to the mess.
FWIW Options 1 and 3 are the only ones that look reasonably likely. Option 3 is really bad, but only in the same way that widespread private ownership of motor vehicles was really bad. It didn't bring about the end of civilisation or anything, and it made our culture what it is, for better or worse.
Option 2 basically won't happen NOW (even in the unlikely event you can come up with a better alternative in our "What if?" scenario) because it would be too late to the party. Achieving even IPv6's tiny penetration will take an alternative decades.
Option 4 won't happen because people like captioned images of kittens. An expensive, inefficient network that continues to deliver cat pictures is still enough to keep the lights on at the ISPs. I'm being flippant, but millions of people are now used to having this service and paying for it. Address exhaustion doesn't make that demand go away. Of course "as we know it" could be construed to include Option 3 in some ways. A network without end-to-end is not the Internet we thought we knew and loved.
Posted Jan 29, 2011 7:48 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (6 responses)
Then NAT reigns supreme for several years while this IPv4 plus protocol gradually disseminates through software and hardware upgrades and ten or so years later the extended IPv4 plus addresses are actually routable across the public Internet.
Posted Jan 29, 2011 15:08 UTC (Sat)
by cesarb (subscriber, #6266)
[Link] (5 responses)
Posted Jan 29, 2011 16:53 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (4 responses)
I like a plan where a.b.c.d address format is changed to an administratively compatible format where each of the four components is a 16 bit number represented in text format in decimal form.
In binary form the IPv4 address C0 A0 20 01 would become 00C0 00A0 0020 0001. All existing address prefixes would be preserved, except in expanded form when represented in binary. In text format the address would be 192.160.32.1 in both cases. Then one day about ten years later, addresses like 300.278.22.1 would become publicly routable. Or even addresses like 6700.45320.658.33781.
A straightforward expansion would allow a variable number of components where the number varied from 4 to 8 or so. That way everyone with an IPv4 style 4 component address could add publicly addressable sub networks without getting a new allocation. The network core would generally only do routing on the first four components (64 bits) for economic reasons, but hardware routers with 128 bit prefix capability would eventually be come common, starting at large edge networks. Trailing zero bits would be implied.
Existing configurations would be preserved, although alternative netmask indicators would eventually have to be added, because a current "/24" would in actuality be a 48 bit prefix, and if you want to specify netmasks that end on any of the inserted bits a different syntax would need to be used. "//48" style perhaps.
One of the other advantages of a variable length addressing scheme like this is that most addresses would only be 64 bits, not 128, significantly reducing the overhead for small packets like those used in VOIP, especially on lower bandwidth connections. Who really wants their MAC address broadcast all over the Internet anyway? For servers, it is practically useless. For individuals it is a privacy nightmare.
Posted Jan 30, 2011 15:15 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (3 responses)
It's a huge sprawling mess, far more invasive than the eventual IPv6. I can only say that I'm indebted to whoever persuaded its author that his entirely new routing protocol and algorithms deserved their own "informational" RFC alongside this one, so that people asked to read about one needn't waste their time reading the other.
The economics (remember, that's why IPv6 has a fraction of a percent of penetration, rather than say 80%) are if anything worse. First you must get enough people to deploy "version 7". Your ten year estimate seems optimistic when you realise that although this costs a lot of money it delivers no immediate benefit whatsoever. Far more so than deploying IPv6 today, deploying "version 7" would have been a leap in the dark, trusting that some day we'd get the wider addresses working and it would be for the best. But then they must upgrade _again_ to have wider addresses. In fact they might have to do so repeatedly.
Ullmann's plan reserves 75% of addresses, rationalising that they can be used if the initial proposal turns out to be a bad idea. A similar strategy was chosen in IPv6. But Ullman reserves the wrong bits. An experienced engineer would know that if you leave the top few bits empty, some clown will either use them for a purpose you didn't intend meaning they can never be put into production, or they will confuse signed and unsigned terms and drop the top bit, again rendering it useless in practice. IPv6 was careful to use those top few bits for something obligatory, so implementers would notice and correct such bugs. [ For another example look at the way x86-64 handles virtual addresses ]
There are also numerous technical errors in the specification. e.g. Like some earlier LWN comments it assumes that DNS records are just arbitrary text strings so changing to a system where 'A' answers are sometimes too long for IPv4 is fine, everything will just work. Leaving aside the naivety of imagining that no-one would inadvertently rely on something that's been true for as long as the system has existed the simple technical answer is: No, can't do that, DNS unambiguously defines A records as exactly 32-bits. Hence the existence of 'AAAA' records.
Posted Feb 5, 2011 16:46 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (1 responses)
In short, the counterargument here has to be not against the weaknesses of a seventeen year old network proposal per se, but rather against the entire idea of preserving the existing address space on a long term basis without renumbering.
Posted Feb 9, 2011 14:21 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
Reality isn't interested in proof by assertion, if I call a frog a bird it will not make it fly. TP/IX is a completely new stack. "Just" widening the address field (which is not what TP/IX does) is like "just" adding an extra floor to the middle of every house in the country.
"no one would have to dual stack"
"routers would do wire format conversion"
Do you even read what you're writing? In order to "do wire format conversion" the routers not only need to have both stacks, but they have to be able to convert from one to the other, a major additional expense. Worse, for TP/IX (and any alternative I can imagine) this is stateful. So the plan becomes "instead of buying an expensive IPv4 and IPv6 router, buy an even more expensive IPv4 and TP/IX router-converter" and you've made things worse, not better.
"technical errors in the TP/IX RFC have no bearing on the merit of the principle described. The IETF was just incredibly short sighted"
Of course, how stupid of me. It doesn't need to actually work, someone who needs things to work is being "short sighted". I can't address problems in a non-existent alternative and neither can the IETF.
Fortunately thanks to such "short sighted" people we have a plan, not a painless or easy plan, but one that will work. Now it remains to be seen if everyone will implement it, and how long that will take.
Posted Feb 9, 2011 17:21 UTC (Wed)
by daniel (guest, #3181)
[Link]
For the proposal at hand, which as I understand it is to extend the IPv4 address space by 16 bits on the right, an 'AA' record will do and only needs to be implemented at the edges of the classic IPv4 space. In other words, at points under complete control of participants in the experiment.
An 'AA' record would sensibly be defined with the classic IPv4 space in the middle four bytes, the IPv4++ bytes on the right, and the two remaining bytes on the left reserved for future expansion.
Posted Feb 8, 2011 18:45 UTC (Tue)
by daniel (guest, #3181)
[Link] (1 responses)
Wait, could you back up and step through that again for me? I fail to see why more addresses is not a step in the right direction, even if they are "already allocated to someone". Reallocate, maybe? Share maybe?
I'm labelling your argument "bifuraction" for the time being.
Posted Feb 8, 2011 23:56 UTC (Tue)
by dlang (guest, #313)
[Link]
yes, my plan favors the established ISPs who have IP addresses as each IP address they currently have becomes a class A network (or larger), but in practice you have to get the established ISPs agreement anyway before you can use any IP addresses (they have to agree to peer with you and accept your advertisement), so I don't see this as a major problem
Posted Jan 26, 2011 12:24 UTC (Wed)
by drag (guest, #31333)
[Link] (7 responses)
Yeah. Nobody in IPv4 can talk to you unless you have a IPv4 address. In my case I will still use the IPv4 NAT firewall for that.
But if your running commercial services then you can use a IPv4 compatible IPv6 address.
Most commercial routers besides home consumer kits have been IPv6 for a long time now. Probably most stuff sold to businesses since 2005 or so has IPv6 support. Most corporations are going to have IPv6 aware devices on their network right now. My Android phone supports IPv6 access points.
It's going to be a security issue for a lot of networks... if I use IPv6 I can bypass most restrictions in most networks. Just because your not using IPv6 on your network, doesn't mean that somebody else isn't. :P
I'd say that most corporate networks deployed in 2006 or so is probably IPv6 ready now... or nearly so. They just have to turn it on.
There are enough reasons to use IPv6 besides just the bigger IP space that people are going to look back and say "WTF didn't we do this earlier?"
Posted Jan 26, 2011 14:23 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (6 responses)
Posted Jan 26, 2011 15:20 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
Posted Jan 26, 2011 16:11 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (4 responses)
In other words, systems would be upgraded to IPv6 in place, with no additional configuration required. Networks, dns, firewalls, services, routers etc. would keep working as usual.
We would have had almost 10 years for all this. More than enough. Too late now.
Posted Jan 26, 2011 19:27 UTC (Wed)
by johill (subscriber, #25196)
[Link] (3 responses)
You're assuming that it's all software, and that upgrading your stack to a hypothetical IPv6 that is fully backward compatible with IPv4 would essentially have been free. Neither of those is true. Vendors would simply have offered to sell new, improved revisions of their existing, "legacy", IPv4-only devices -- without adding the more expensive silicon that is aware of the new, longer address matching.
Posted Jan 26, 2011 22:18 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
And that's fine. If they don't want to route new, IPv6, hosts. Ever.
However, people connected to their network would automatically start asking for this routing. Because they would already be on IPv6. Without doing anything. Any new host they wished to access that had a real IPv6 address (i.e. not legacy IPv4) would be out of their reach. This would create a lot of complaints (hey, my friend can see this cool new site and I can't), which would either get rid of idiotic ISPs or force them to upgrade. Without the need to tell customers that they need to do something special to see IPv6 hosts.
Posted Jan 27, 2011 12:01 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Posted Feb 3, 2011 14:43 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
We already have the situation you're discussing - I have today's IPv6 and IPv4, and can get to any cool sites that exist on IPv6 only.
Problem; there are no cool sites that are available on IPv6 and not IPv4. The reason? If I'm available on IPv4, close to 100% of my target market can get to me; if I'm not, only a tiny fraction of a percentage point can get to me. The economics are simply not there; in your hypothetical "IPv4++" world, the idiotic ISP would respond with "you need to do this very complex thing (at least as complex as deploying IPv6 is in today's world) to get access - it's the site's fault for using IPv4++". Net result? Everyone continues to use plain IPv4, ignoring the extended addresses possible in IPv4++, because you haven't solved the chicken and egg problem.
Note also that thanks to buggy systems, it's not safe to dual-stack your hosts by default. There are machines out there which think they have working IPv6 routing, but don't - about 0.1% of Google users last time I looked for the figures. So, real world experiments tell us that even co-existence of two protocols doesn't work properly; this leads to a thought experiment. How exactly does IPv4++ handle the case of two IPv4++ hosts with an IPv4 only segment in the middle, such that you can successfully talk IPv4 but not IPv4++?
Any answer that assumes that IPv4++ can transit the IPv4 segment has failed already - IPv6 can transit over IPv4 segments, yet we still see brokenness. Any answer that implies that an IPv4 only host cannot distinguish IPv4++ traffic from traditional IPv4 traffic has failed already - the most common form of brokenness in the IPv6 world is IPv6 in IPv4 tunnelling, where the IPv4 network deliberately blocks protocol 41, and there would have to be some similar indication that this is IPv4++ traffic.
Posted Jan 26, 2011 3:47 UTC (Wed)
by jthill (subscriber, #56558)
[Link]
Jeez, they only gave you enough addresses to cover about 5kg of you. Stingy bastards.
What about IPv6 right here on earth?
What about IPv6 right here on earth?
>
>... in the US.
What about IPv6 right here on earth?
What about IPv6 right here on earth?
http://www.sixxs.net/pops/occaid/
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
TP/IX and similar plans
TP/IX and similar plans
TP/IX and similar plans
TP/IX and similar plans
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
What about IPv6 right here on earth?
No, no, that big number is 2^80, so the entire IPv6 space is that much *times* your allocated /48 range. Let's see.... Mass of the Earth: 5.9724e27g. IPv6 net: 2^128. per address: 1.755e-11g, 17.55 picograms.
What about IPv6 right here on earth?