Slashdot Mirror
Microsoft Runs Out of US Address Space For Azure, Taps Its Global IPv4 Stock
alphadogg (971356) writes "Microsoft has been forced to start using its global stock of IPv4 addresses to keep its Azure cloud service afloat in the U.S., highlighting the growing importance of making the shift to IP version 6. The newer version of the Internet Protocol adds an almost inexhaustible number of addresses thanks to a 128-bit long address field, compared to the 32 bits used by version 4. The IPv4 address space has been fully assigned in the U.S., meaning there are no additional addresses available, Microsoft said in a blog post earlier this week. This requires the company to use the IPv4 address space available to it globally for new services, it said."
So after years of panic, someone finally ran out of IPs. No, wait a minute... They still didn't.
I am not sure what this "globally assigned" means, but I imagine it means that they had a pile of IP addresses allocated to them decades ago and that they weren't using, and now they started using them. Doesn't sound like a bad thing if it is so...
My first program:
Hell Segmentation fault
OR they could migrate those services to IPv6??
Considering how much bashing MS gets for not being a leader, this would have made a really good opportunity for them.
(I hate it when people say they're doing something because they were "forced" or "had no choice", when in reality, they had aa choice, they made a choice, and now don't want to take ownership of the outcome)
I work for the Department of Redundancy Department.
I tried to use Azure, but all of my EU-hosted virtual machines geolocated to US, and I wanted none of that.
Underprovisioning your cloud service in IP addresses (or in servers, bandwidth, etc) causes people to think that your service is growing faster than you expected. Brillant.
of each member of my family. That way the various atoms can self report as to the location of their component parts bypassing the quantum mechanical problems of actually looking at electrons (for example) to find out where they are at and by looking changing their orbital pattern.
Facebook: Electron six is coming around the top bend at approximately 186,000mps, whoooeeeeeee!!!!!"
Electrons 5 and 9 narrowly avoided a collision at the bottom half of their orbit, only their charges saved them from a disastrous end.
If this catches on, we will probably start running out of IPv6 addresses sooner than originally thought. Besides, this is far more exciting than watching Facebook to see if your friends are going to the hardware store.
They're only really memorable to computers. Which is fine as far as it goes but IP4 addresses were something you could sorta remember if you dealt with the same number over and over again.
Obviously for internal networks there's no need for IP6. But even beyond that... I wonder if we couldn't improve on the DNS system so that we could assign names to IP addresses differently.
I don't know... something so we never have to work with the IP6 numbers which are so large and random that a human being really has no chance at remembering any of them short of the old copy paste.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Amazingly IPv6 will be sufficient for a long time:
2^128 IPv6 addresses * (1 atom / address) / (7*10^27 atoms/human) = 48 billion humans.
It's never to late to procrastinate.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Amazingly IPv6 will be sufficient for a long time:
2^128 IPv6 addresses * (1 atom / address) / (7*10^27 atoms/human) = 48 billion humans.
Actually, why not solve it for all time? Given the estimate of 10^80 particles in the universe, then moving to 266 bit addressing (i.e. 80/log(2)) would allow each particle to be addressed individually. Bumping to 512 bit addressing would accommodate the typical logical addressing inefficiencies.
Cloud is forcing many legacy network problems to be solved.
Spanning tree, broadcast ARP, excessive IPv4 subnetting, and NAT.
Spanning tree to TRILL, broadcast ARP to multicast NDP with corresponding reduction in subnets and elimination of NAT for true end to end connectivity (think what happens with a Skype call in your house behind a NAT).
These cloud lead solutions all lead to radically simpler and more scalable networks.
It's only 4 times as long! Surely if we're only quadrupling the number of addresses, they'll get eaten up in a hurry.
This is obviously caused by Global Warming. The models predicted it years ago.
This is why we keep running out. In the beginning of the internets large enterprises[HP,Msoft,ATT,Level3,Cogent,etc.] gobbled up large swaths of address space and then didn't come close to using it all. So ARIN, whose existence is without purpose once their IPv4 printing press runs out of ink, keeps yelling from the rooftops that the sky is falling...but it is clearly not.
I know 128bit addressing sounds reasonable when one thinks about how many devices will one day be connected to the net...but the fact is that DNS is very vulnerable to hijacking....and maybe I don't want everything I own exposed to the world-wide-web-of-script-kiddies-and-bots. Call me a sadist, but I like having one central and strong firewall to manage performing NAT. I also like being able to memorize my public IP which I don't think I could do with 128bits.
I'm currently building a new router, so I did some research thinking now might be a good time to make the switch to IPv6. I found this: http://www.kloepfer.org/ipv6-h... Is there really no way to implement IPv6 without making every one of my machines dependent on the DHCP whims of my ISP?
You can still get around the address space limitations of ipv6 with NAT... but unlike IPv4, with IPv6 it is possible to design a NAT system that you can route packets through via extension headers, so even on the other side of a ipv6 NAT (which acts technically more like an extra 128 bit prefix on the ip address than it does a conventional NAT, but it still essentially functions the same way in that it would still change ip address headers like current ipv4 nats do), a computer could still potentially directly connect to yours.
Of course, some people might scream about security issues if this is done, but bear in mind that NAT isn't really something that one should be using for security anyways.
File under 'M' for 'Manic ranting'
This will only solve it for people who think that addresses should be assigned to objects. Other people think that addresses should be assigned to locations. To solve that for all time you need to be able to address the volume of the observable universe in cubic Planck lengths.
Actually, why not solve it for all time? Given the estimate of 10^80 particles in the universe, then moving to 266 bit addressing (i.e. 80/log(2)) would allow each particle to be addressed individually. Bumping to 512 bit addressing would accommodate the typical logical addressing inefficiencies.
Yeah, that'll work great, until we discover multiple universes...
This will only solve it for people who think that addresses should be assigned to objects.
I don't know about you, but every time I am communicating with something or someone, I am communicating with something physical rather than a location.
Do you have a use case for why we should be communicating based on locations rather than physical objects? Relativity would make your idea a real bitch. Furthermore, I don't care where my server is located (and I don't want to have to care, either), but with your idea our communication would involve constantly changing IPs for every Planck time (because, no doubt, both my device and my server are constantly in motion relative to your IP addressing scheme's frame of reference).
Yeah, that'll work great, until we discover multiple universes...
The question then becomes "if there is another universe we cannot communicate with, do we really need to be able to address their physical particles with our communication networks?"
Hopefully everyone in this thread is joking, but it's worth noting that it's not quite that clear cut. The smallest assignment that an ISP can hand out is a /64, so you can really only have 2^64 sites. IPv6 has 2^128 addresses, but a lot of the design works around having sparse routing tables. You really want each /64 to correspond to a broadcast domain, and you don't want to fragment the routing tables too much to get to the /64, so you've actually got a lot fewer addresses. A /64 per human is not enough to assign one IP per atom in the person, but it likely is enough for every device that a person may reasonably want to own and give an IP to, even if that person has a lot of injected sensor nodes.
I am TheRaven on Soylent News
When is the IETF going to smarten up and design a new IP protocol that is backwards compatible with IPv4 and can solve the address exhaustion problem?
Guess what: If you design a new system that causes widespread frustration and expense, then you cannot expect widespread adoption. If you want to push out a new system, make it (1) clearly better and (2) easy to migrate with low costs and east uptake. IPv6 may be technically far superior, but it fails on point "2". Time for a rethink.
It is a sure bet that once it gets codified into a standard that we can only communicate with our universe and integrated into a host of products, we will discover that we can in fact communicate with multiple universes. Luckily, there is the likely possibility that there are a host of other universes won't make this mistake.
You don't want to do that
I think the deniers are the same people, with the same arguments.
It's easy to spot the people who don't know what they're talking about. Over the last few days:
1) Just re-assign multicast!
2) Hey, they don't appear to be using those addresses, let's take those!
3) Double/Triple-NAT is good enough for me and everyone else!
4) Let's give out one IP address to everyone and we'll be set for awhile!
5) Let's make a new protocol!
6) IPv6 addresses are too big to remember!
7) You just need to sell it better!
All of those show fundamental misunderstandings about networking. And that part is OK. The problem is that people think they know about flying a plane because they've flown a paper airplane.
Calm down people. Stop trying to barge into the cockpit.
or making certain features v6-only to penalise ISPs that don't provide v6 connectivity by making their customers complain.
"IPv6 is scheduled for testing in 2017. If you want it sooner, we don't have to care; we're the phone company." How many people are willing to move their family or their business from a city without an IPv6 capable cable, DSL or fiber ISP to one with one?
Leave it to Microsoft to screw up the map.
I agree that relativity would fuck that up, but do you seriously doubt that people want to communicate based on locations?
"There's a supernova nearby! Look out!".
But a perhaps better argument is that just because you can address every object, doesn't mean you're using the best addressing. Maybe with twice the address space you could implement multiple different hierarchies for different purposes, enabling more efficient multicast scenarios at the expense of memory-per-address.
Which would in fact be a large part of why we're jumping straight to 128 instead of just doubling to 64.
Why not simply require everything in the cloud to use IPv6 with IPv6-over-IPv4 tunnels as necessary?
For public-facing services that don't want to have customers use IPv4, have an IPv4-IPv6 translating proxy.
IPv6 is inherently faster, more secure, more robust and more in tune with how people use hardware these days. IPv4 is dead, I wish Netcraft would confirm it, but until it does, there is absolutely no benefit in running IPv4 in the cloud. The cloud's architecture is ideal for IPv6, you need less memory on the routers, the configuration is simpler and the configurations are self-maintaining in a proper setup.
NAT isn't something one should ONLY be using for security, but it's a damn useful tool in addition to other things. Those who want to take useful NAT away either aren't considering that, or they're considering it very carefully (like the NSA perhaps?)
Netflix is going to have fun with this!
"But I do live in the USA! Its not my fault I was issued an IP address out of a North Korean allocation block."
Have gnu, will travel.
I can't believe I haven't heard of this approach until now. That could really help to solve the problem with prefixes changing due to dynamic assignment. Basically each device can have both a globally routable address (which changes often), and a local address (which never changes).
Alas, this still means that I can't use the same DNS on the inside and outside of the network. It also means that I still have to deal with dynamic DNS updates for multiple hosts if I want them to have globally-reachable addresses.
The specification for ipv4 has already been extended to 64 bit address space. The extension is called enip. (Enhanced ip). It extends rfc1918 address space to the end of your current space.
http://www.computer.org/csdl/mags/co/2014/02/mco2014020062-abs.html
.... So I can get your IPV4 addresses!
IPV4 is like the fax machine... it will never go away :-D
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
Never say never. If they keep giving every cellphone, toilet, refrigerator, ATM, etc etc etc public IP addresses, we'll run out of IPv6 in no time flat. It only took us 30 years to exhaust IPv4. Watch this, we will exhaust IPv6 in another 40 years.
The sad part is, they can't really transition to IPv6 because their own OS doesn't really support it.
Sure, some groundwore is present, but there's something critical missing: Windows can't retrieve a DNS server over RA. That means, it can get an IP, but not DNS servers.
It is a sure bet that once it gets codified into a standard that we can only communicate with our universe and integrated into a host of products, we will discover that we can in fact communicate with multiple universes. Luckily, there is the likely possibility that there are a host of other universes won't make this mistake.
NAT. You know that would be the de facto solution, and I grin at the thought of future address space purists wringing their hands over the solution as much as their 21st century ancestors did...
You are still always communicating to objects, never locations. You described a scenario where you want to talk to physical objects (people) who happen to be in a location.
Have you ever walked into an empty room with the intention to communicate with a location? Because that's what addressing based on location rather than objects implies. Normal communication would involve going into a room that wasn't empty and talking to a person or people. You aren't communicating to space itself, but rather with physical objects.
Imagine if your phone number constantly changed based on which room of the house you were in, and it continued to change as you walked around while talking with someone.
There is no use case I can conceive of where addressing a location makes more sense than addressing a particular object/person. Communication is fundamentally about objects passing information. Location is metadata or is something that is incidental to the objects communicating. Locations don't communicate, objects/people do. Therefore, objects/people should be the basis for the addressing scheme.
And when I said relativity makes the proposed plank-length location addressing idea a bitch, I really meant that it is essentially impossible.
Rounding up to 512 bit addressing allows the ~266 bit identifier to be unique (ala the typical MAC aspect of IPv6) while allowing substantial overhead for logical addressing hierarchy based on some allocation system that makes sense.
That's an odd definition of "already", given that it came years and years after v4 was extended to 128 bits. Also the 128-bit version is actually big enough to handle the number of hosts we need it to handle, and it has far wider support and deployment than that 64-bit extension.
So really, there's no point in it.
IP addresses based on location are ideal for routing. If IP addresses have no connection to location whatsoever, then the size of routing tables would be O(number of objects).
This trend is annoyingly spreading to a lot of websites and software vendors. "Hey, I see you have a public IP that's located in some tiny country with an obscure language. Let's assume you want to use their language, never mind your preferences set in your web browser or the language setting of the OS you have installed." Naming and shaming here not just Google, but Adobe, LibreOffice and Avast as well. Got more offenders to add? Please do.
I was promised a flying car. Where is my flying car?
Migrating those services would mean shutting off IPv4.
That would mean that every customer that would want to access these services, would have to have IPv6 connectivity. If anything, MicroSoft should encourage their customers to get IPv6 connected, so they can eventually shut off the IPv4 connectivity for their services.
Given the time frame they'll have to observe for their Enterprise customers, an announcement to do the shut down would have to be at least 3 years prior to the shut down date. They can't get away with shutting off more than say 5% of their customers with an action like this, so they can't do that until they have a good indication at what date over 95% of the internet globally will have IPv6 connectivity. Even if the entire planet will start trying to accomplish that really hard all of a sudden, it will be at least two years before the bulk of it will have end to end facilities for IPv6 in place.
This puts a realistic time frame of at least 4, probably more like 5 to 7 years on your suggestion to "migrate to IPv6 so they can free up IPv4 space". That's hardly a solution for a problem they are facing right now, is it?
I was promised a flying car. Where is my flying car?
and we still haven't abandoned v4? Sheesh, we as a species deserve extinction.
Very interesting graph! The increase seems to be pretty exponential, though perhaps a bit more linear at the very end? As you say 3.5% is already a significant number, so hopefully this will put a damper on the sale of ipv4-only home routers.
Does this solution exist at this time? If the answer is "Yes", than the OP was using the normal definition of the word "already".
The truth is that all men having power ought to be mistrusted. James Madison
First, Windows XP with SP3 has enough support for ipv6 with a nated ipv4 address to allow connecting to the local DNS cache server/firewall. We can connect to all of our XP machines via ipv6 from the internet, embed and other hardware issues are holding back upgrades. They can also connect to any ipv6 site through DNS assuming the connecting application supports ipv6. Unfortunately, isps would have a hard time making sure their customer's machines where setup correctly for ipv6. Getting it right for our sites wasn't difficult. You can install a working ipv6 for 95, 98, ME, NT, and 2000. I think there is even a stack for windows for workgroups aka 3.11. Unfortunately, it costs money and don't know how well applications support it.
Secound, This is how the transition should be done. ISPs should soon default to issuing people ipv4 addresses that are nat'ed. That's what you'll get and it will work for 90% of ipv4 only users. If you need a ipv4 address, you'll have to pay up, however if you're lucky If you're luckily they'll give you a website where you can setup some sort of port forwarding for your freed nat'ed connection. Hopefully, a Class A will be converted to private or assigned as an ISP internal only addresses to avoid conflicts with people's intranets. Also,only ipv6 websites will get there own nat'ed ipv4 address which will be assigned when a DNS query is filled for ipv6 only site, it's called DNS-ALG. I believe you can even connect to non dns ipv6 address by changing the : to a - thus making it a valid domain name which the DNS server/router sets up as a ipv4 to ipv6 connection for you. It would be best to assign at least one Class A for ipv4 to NAT ipv6 only addresses. We might have to add more CLASS A subnets for nat forwarding as time progresses but since they'll be less ipv4 only users it might not even be a problem. Also, if an ipv6 only client wants to connect to ipv4 only server this is what should happen.
Stupid lameness filter. here is the rest of my rant... Also, if an ipv6 only client wants to connect to ipv4 only server this is what should happen. All the ipv4 address are mapped to a special subnet of ipv6. When the connection comes in a router assigns a nated ipv4 address that it then translates automatically to the ipv6. This could be done on a per server* bases so IPs could be reused just not for the same server. One problem is if the router doesn't have enough available ipv4 to ipv6 mask addresses and too many clients try to connect, it will fail but if a whole class A is available for the purpose it won't be a problem especially since bigger servers operations will their own ipv6. The above should be a requirement that backbone providers start adding to their peering and connection agreements or a fcc mandate. I think cisco and juniper already support doing all or most of this but you need to set it up which is a pain. With this system in place ipv4 clients could be supported indefinitely with only minor pain.
*By server I just mean the computer where the open port is waiting for a connection.
ps, I meant to put the title for first comment as "Reply to 90% of above comments"
Again, that does not imply that communication is between locations. Communication is between/among physical objects/entities.
512 bit addressing allows over 200 bits of logical addressing to go with the 266 bits of unique addressing. If general location makes the most sense for logical blocks for routing, then use that. It still does not imply that the address itself should be some "absolute" (*cough*) location.
How do you show that 246 bits will solve logical addressing for all time?
On my OWN PC, & right in my hometown - I'll never forgot it, circa 1993: Was the COOLEST THING EVER I felt! I was hitting "BBS" systems thru them, but much larger than the local ones in my city... I could hop thru them all over the place easily, get what was considered 'great wares' back then (DOS & OS/2 days for me, & eventually Windows 3.x too) but... next year came "internet for the masses" so I quit doing that & got into Gopher/FTP & the like then - eventually the "WWW" too.
WoW... this is making me reminisce times back then in academia for both degrees I pursued 1984-1988 + 1993 & still ongoing (between jobs usually, 60 Associates credits long done, & into 90/120 for the Bachelors in Comp. Sci. purely - taking my time, since I've already worked professionally as a programmer-analyst, software engineer, or network admin 1995 - present in that timeframe...)
Still, this is bigtime reminiscing for me - blows my mind how much more advanced the internet's become for users really... makes you wonder how much MORESO it will be, in the future (especially in another 20++ yrs.).
* :)
(It was fun: S.U. used to be my "young man's hangout" for a period, since I went to another college VERY nearby, only *maybe* 5++ miles away or so... I remember all that, regarding SU! That, along with scoring on them BEFORE it in 1984 @ Manley Field House field, on the team that because the national champion for decades to come... we got "whipped" 21-1, but a former classmate of mine in the WG School District who became practically "All-World" in the history of the game, Mr. Todd Curry said "Nice shot AL...", big compliment from him 4 yr. straight HighSchool All-American & I *think* also in College, onto World Games & Pro even...)
He's one of the most physically powerful guys I've ever know for our weight class, for lack of a better term here (then 170-190 or so) & FAST too (I always had 1/2 step on him, but he had me by 1 pullup) - I never got to play @ WG with him wish I did (divorced family stuff) - they were great!
I've been to SU's computer facilities back then. They were MILES above the VAX 1180 VMS OS based stuff we used @ the college I attended - especially since they let you go online (I never really did @ LeMoyne - was more burning LOADS OF TIME writing COBOL (just had a memory, lol, that I told myself I'd recall one day in the FAR future, & "here 'tis" - Looking out the dorm basement computer lab windows watching the sun come up as I JUST finished a lab for that COBOL class, just in the nick of time... lol!).
APK
P.S.=>S.U.'s a pretty phenomenal school, not known for their Comp. Sci. but more Law, & Communications iirc, but I am SURE they have one heck of a setup there (was Sun OS of some sort when I used to dialin to them "way, Way, WAY Back when" noted above @ the outset of this reply of mine)... apk
Since you noted SU & I replied here (regarding my online experience "in the days dinosaurs walked the earth" http://it.slashdot.org/comment... ) & took a peek @ your posting history - perhaps incorrectly, I am assuming YOU go to SU (my hometown) & you mention Atlanta Ga. frequently in your posting history - I lived there long ago @ near the start of my career as a programmer 1995-2000 too!
* Small world & oddly coincidental too on the note of locations we both dwelled in...
APK
P.S.=> I liked your post about Hartsville airport... that place always blew my mind: It's practically a small town with a train type setup in it (saw one like it in Chicago's Ohare airport too) - noted your post on Atari type games (you're dating yourself there) in it as well, made me laugh when you said "That was the BEST THING for a kid in the mall there"... anyhow/anyway - thought I'd mention it! apk
Many end users have IPv6 support. Many servers are capable of it. The issue is mostly the US ISPs and middle-tier transit providers dragging their feet. My systems all support IPv6, my m0n0wall box supports it, but neither of the two ISPs I can buy service from support it. In fact they won't sell it to me even if I offer to pay extra money for it!
My pet theory is that Verizon et al wants to convert IPv4 address space into a "resource" they can buy/sell/trade. A bunch of lawyers and MBAs are rubbing their greedy fingers together, hoping we stay in a "resource shortage" for as long as possible.
We could switch over, probably within a year or two, but it would take a government-imposed mandate to force people to stop screwing around and make the change.
Natural != (nontoxic || beneficial)
I don't know about V7. But at the same time that V6 work was started, there was also work on a V8 system.
V8 was based on master regional gateways, if I remember correctly, called stargates. The central assumption in V8: Throw away the assumption that a single IP address always refers to the same machine everywhere. Within a single region, there is a mapping from name to IP to machine. But that mapping does not hold across stargates.
If I want to talk to a machine in my region, then getHostByName() returns an IP address that maps and routes just as normal.
If I want to talk to a machine in a different region, then getHostByName() returns a special 4 byte magic token that talks to the stargate that sits between me and whatever it takes to get to the destination.
It is another level of routers. Just as now, I can work within my regional area network -- perhaps I'm a comcast customer talking to another comcast customer -- or, I can go out over the "backbone" of routers that talk to routers with the special gateway router protocol (sorry, I forget the exact acronym -- BGP, I think?) to reach the final region for "last mile" delivery.
This extends it another layer. But at the same time, each region now has an independent IPv4 space.
Want to really enforce a "firewall of china"? V8 would actually permit it. If something like this was in place, then any attempt to talk to someone outside of china would have to send that hostname to a central authority router, which could then return either an accepted "cookie" (looks like an IP address, but treated special by the routers), or "no such host", or "here's the government re-education website".
What is the major compatibility problem? It is suddenly impossible to cache the outcome of "getHostByName()" across runs -- the cookie returned only has a lifespan as determined by the gateways.
===
There is a much better, much deeper question to ask.
** WHY THE BLEEP ** are we still using things like getHostByName()?
Why the bleep do we still expose struct sockaddr to programs? It's an OS internal.
Way, way, way back when, before there was an internet, when arpanet was just one of many networking protocols in use, networking changed far faster than BSD releases could come out. So a bunch of stuff that should have been OS internals were exposed, so network drivers could talk to application programs without an out-of-date kernel in the way.
Today, that should be gone.
Today, there should be a simple open() call that returns a network connection -- and for simple TCP streams, that's all you would need. Message-based (UDP/etc) would probably have a flag on open, just as we have for "read only", "create if not found", etc, there might be "best effort only". Heck, imagine a file system that could recover from "out of disk space" by eliminating old "best effort" files automatically. Sure, put up a warning on the console -- but programs can keep running.
All the issues we see from "How do we re-write all those programs from v4 to v6", all those "how do we migrate X from 4 to 6", etc. -- all come down to "Why do we even care?"
This is serious.
Why worry about the program ever knowing what address to talk to?
Why worry about the program ever knowing that port X is the destination?
Why would you ever want to say "This program/server can only run once on this machine because the port number must be reserved and known ahead of time to the users"?
Why not just say "Give me a channel to service X running on machine Y", and not worry about "I want a TCP channel over 4 bytes of address".
Why worry about "Hey, the TCP protocol fails spectacularly over networks that have a very high bit length wire" and "well, we'll fake the TCP protocol with a new one that looks sort-of like TCP, can handle high bit-length wires, but can be reset by a random packet from an attacker with a 1-in-4 chance of success". (High bit length wires == satellite links. TCP has a packet size, and a window size; put th
If you can't figure out how to manage addresses using practically enough bits to allow every particle in the universe to be able to individually directly address every other particle in the universe, You're Doing It Wrong.
Direct connection routing is n^2. 512 is close to allowing n^2, but the 10^80 is an estimate as well.
You don't think a future logical addressing scheme would be able to at least do as well, efficiency wise, as a directly connected, n^2 network?
N^2 is the trivial case, mind you, and is practically not even a network (if everything can directly communicate with everything else, then is it really a routing network?)
Don't Panic, or be afraid of IPv6.
People often talk of "switching" to IPv6. One does not "switch". You simply deploy it alongside IPv4. Right now my home network is happily running IPv4 and IPv6 at the same time, called a "dual-stack" environment. This sort of set up will be common for decades until IPv4 use dwindles to nothing, and people start turning it off.
Nearly all operating systems and devices supporting IPv6 have it turned on by default, so you're already running IPv6. You just don't have globally routable addresses assigned (most likely). You could actually use ping (windows) and ping6 (*nix) to ping other hosts on your LAN using link local addresses, which have automatically been assigned (see those addresses starting with fe80 on all of your interfaces?), if you knew how, right now. :-)
If you know IPv4 routing and subnetting, you already know most of what you need to know about IPv6. Except that IPv6 is simpler since there's no need to NAT. Just set up your firewall exactly as you would under IPv4 (same security policy), minus the NAT. Subnetting is also simpler, with no need to fret over "right sizing" your subnets so they're "just big enough" and don't use too much of your precious IPv4 space. Just assign a /64 out of your /48 (businesses will be easily be able to request multiple /48s) and you're done. Never run out of host numbers, or subnets.
Some folks are frightened by the use of hexadecimal for IPv6 addresses. No need to fret. It makes sense, and would have made sense for IPv4 also. Hex for IPv6 not only makes the IPv6 addresses more compact., it's also far easier to translate hex into binary, and work with prefix-lengths than decimal IPv4 address are. I can do it in my head all day with no issue. All you have to do is memorize 16 bin patterns from 0000 to 1111, each represents a hex digit from 0 - F. Piece of cake. No more annoying math and base conversion to try to figure out which subnet some IPv6 address belongs to like with IPv4. No more subnet masks either (which are also decimal), instead, just prefix lengths (although this is also true of IPv4 with CIDR, adopted long ago, many user interfaces still require a netmask for IPv4 instead of just a /prefix-length, sigh).
Anyway. Go play with IPv6. It will be an essential skill to add to your Resume/CV, and will only take a short time to figure out. Go set up an tunnel with Hurricane Electric or some other tunnel broker to get some globally routable IPv6s. It's simple and you'll learn a lot and quickly! And best of all, you'll stop being afraid of IPv6! :-)
(apologies to those who already have adopted IPv6 and know all this already ... this isn't addressed to you!)
Sixty-four bit operations are beginning to be the normal thing now and 128 bit operations are not a big deal.
Does that show you simply enough that the use-case of fixed objects is not universal and that tracking moving ones is not such a big deal as to give up on them for arbitrary historical reasons?
The reason we have man in the middle cobbled together things like Skype is because we can't find the unique address of a device owned by the person we want to contact (mainly due to NAT, but there are other things in the way as well). IPv6 is about solving that. Halfway measures such as what you suggest, to be blunt, show a lack of thought about the issue before commenting.
It also seems I seem to have to remind you that people can travel far outside of the area in which they live so your "giant subnet per carrier" is yet another kneejerk with no thought of such things are people being able to travel long distances and still have others find them. Your suggestion is just exchanging a formal routing table with an informal one.
There is plenty of value for IP addresses to "roam" as telephone numbers are already doing.
Is that enough to aid understanding or were you merely pretending not to get the point earlier and have just been stringing me along as some sort of childish game?
Skype address are fine. Skype maintains a unique identifier and the device ties its IP to that unique identifier. My issue is not that people don't need to find devices, its that IP shouldn't be the mechanism for doing so.
As for the general rudeness in your post that's unnecessary. Believe it or not, people can have considered an issue and still disagree with you.
Not as such.
Your homepage implies you are some sort of computing professional. I can only assume that you are deliberately pretending to be more ignorant than a high schooler as some sort of game to wind me up.
Once again you've missed the point of the example - I can only assume by now deliberately as some sort of game.