IPv4 Space Shrinks To 5% – Final Addresses To Be Issued In Early 2011(techcrunch.com)
techcrunch.com
IPv4 Space Shrinks To 5% – Final Addresses To Be Issued In Early 2011
http://techcrunch.com/2010/10/18/ipv4/
12 comments
It is, but not in the way you think. IPv4 addresses are also cognitively nasty (try to remember two of them, walk to the other end of your building, and recite them from memory). People don't often use them directly.
The problem is that IPv4 addresses happen to fit in machine registers, and so virtually all of the world's networking software has been written to assume that they are just a gossamer-thin semantic layer on top of a scalar integer. IPv6 addresses emphatically do not work as scalar integers.
It's not just that this means you can't do math on an IPv6 address (though without a bignum library you can't). It's also the case that, as far as a lot of C programmers are concerned, you can't even directly assign them; they're "memcpy big".
When Daniel J. Bernstein talks about the "IPv6 mess", this is one of the things he's talking about; it's not just that the whole world needs to be renumbered (note: hasn't ever been done before), but also that all our software needs to be upgraded.
The problem is that IPv4 addresses happen to fit in machine registers, and so virtually all of the world's networking software has been written to assume that they are just a gossamer-thin semantic layer on top of a scalar integer. IPv6 addresses emphatically do not work as scalar integers.
It's not just that this means you can't do math on an IPv6 address (though without a bignum library you can't). It's also the case that, as far as a lot of C programmers are concerned, you can't even directly assign them; they're "memcpy big".
When Daniel J. Bernstein talks about the "IPv6 mess", this is one of the things he's talking about; it's not just that the whole world needs to be renumbered (note: hasn't ever been done before), but also that all our software needs to be upgraded.
Out of curiosity, what software do you use that still lacks support for ipv6? Most everything I use has been ipv6-capabable for years. Earlier this week iftop got ipv6 support, and so the last non-ipv6-capable software I use is rtorrent. There are only about 100 packages out of all of Debian that have ipv6 problems: http://bugs.debian.org/tag:ipv6
My experience converting software to ipv6 has mostly been of converting from gethostbyname(3) to getaddrinfo(3), and those are really the common cases for anything that simply needs to do dns lookups. Neither exposes an IP address outside a semi-opaque structure.
My experience converting software to ipv6 has mostly been of converting from gethostbyname(3) to getaddrinfo(3), and those are really the common cases for anything that simply needs to do dns lookups. Neither exposes an IP address outside a semi-opaque structure.
There's quite more to this than just simply replacing gethostbyname() with getaddrinfo().
That may be true most of the time for TCP/UDP client-side, but even there you'll run into OS-specific
quirks the moment you try to support more than one OS (or even more than one version of the same OS).
I've done my share of porting and here's some of the things I've ran into:
- OSs don't support all (major) RFCs, so e.g. you don't get inet_pton() or even some getaddrinfo() flags
- OSs support some draft RFC version (socklen_t mess)
- getaddrinfo() return values are system-specific (EAI_NODATA, EAI_PROTOCOL)
- getaddrinfo() with AI_ADDRCONFIG doesn't work or works differently on each system
- IPv6-mapped IPv4 addresses (don't get me started)
- server-side: IPv6 sockets cannot handle IPv4 traffic on all systems, so you end up having two separate sockets listening to the same port
- retrieving a list of local IP addresses from NICs - all ioctl()s changed, no proper documentation (except for BSDs fantastic getifaddrs(), also ported to newer Linuxes)
- if you're dealing with non-standard ports, you now have to fiddle with two sockaddr structures (_in and _in6)
- comparing two network addresses for equality is a pain in the ass - for example, one is an IPv6 address and the other is an IPv6-mapped IPv4 address
- huge piles of OS bugs (AIX being the winner here)
- xinetd/inetd configuration changes (IPv6-only, dual stack) are different for each system
- nslookup output (AAAA addresses) is different for each system
- accessing Windows network shares via IP addresses
- using IPv6 addresses with existing tools (e.g. ping -6 vs. ping6, ssh [addr]:port?)
Then there are differences in multicasting, raw sockets, addressing schemes (link-local, no broadcasting), transition mechanisms (6to4, Teredo etc.) and so on and so forth.
IMO, porting to IPv6 is light years from being transparent.
- OSs don't support all (major) RFCs, so e.g. you don't get inet_pton() or even some getaddrinfo() flags
- OSs support some draft RFC version (socklen_t mess)
- getaddrinfo() return values are system-specific (EAI_NODATA, EAI_PROTOCOL)
- getaddrinfo() with AI_ADDRCONFIG doesn't work or works differently on each system
- IPv6-mapped IPv4 addresses (don't get me started)
- server-side: IPv6 sockets cannot handle IPv4 traffic on all systems, so you end up having two separate sockets listening to the same port
- retrieving a list of local IP addresses from NICs - all ioctl()s changed, no proper documentation (except for BSDs fantastic getifaddrs(), also ported to newer Linuxes)
- if you're dealing with non-standard ports, you now have to fiddle with two sockaddr structures (_in and _in6)
- comparing two network addresses for equality is a pain in the ass - for example, one is an IPv6 address and the other is an IPv6-mapped IPv4 address
- huge piles of OS bugs (AIX being the winner here)
- xinetd/inetd configuration changes (IPv6-only, dual stack) are different for each system
- nslookup output (AAAA addresses) is different for each system
- accessing Windows network shares via IP addresses
- using IPv6 addresses with existing tools (e.g. ping -6 vs. ping6, ssh [addr]:port?)
Then there are differences in multicasting, raw sockets, addressing schemes (link-local, no broadcasting), transition mechanisms (6to4, Teredo etc.) and so on and so forth.
IMO, porting to IPv6 is light years from being transparent.
As you said, anything that uses gethostbyname(), or directly works with sin_addr.s_addr.
Here's the Microsoft guide:
http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx
Note: I'm 100% sure Linux is much closer to IPv6 shangri-la than the rest of the world.
Here's the Microsoft guide:
http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx
Note: I'm 100% sure Linux is much closer to IPv6 shangri-la than the rest of the world.
Do you think it would have been better if they'd gone to a 64-bit format instead of 128-bit?
Yes, they definitely should have used 64-bits instead of 128-bits for the IPv6 address. At 64-bits, you have over 2 billion addresses per person on earth. At 128-bits, the number of addresses, you have is close to incomprehensible.
You don't need the host component of the IPv6 address to be 64-bits in length.
Also, they made the network component unnecessarily long in order to improve summarization. But until you solve the multi-homing problem summarization won't work.
You don't need the host component of the IPv6 address to be 64-bits in length.
Also, they made the network component unnecessarily long in order to improve summarization. But until you solve the multi-homing problem summarization won't work.
No way! It took us almost 20 years to start moving towards IPv6, at great costs. It was better to exaggerate on the address space so that to we don't have to bother with another transition for a long, long time. I don't expect the next transition to happen before we start colonizing Alpha Centauri.
You realize that just like 64 bit addresses presume we'll never have a 18446744073709551616th host, 128 bit addresses presume we'll never have another network layer, right?
Have you considered whether we're putting entirely too much emphasis on whether or not there is an end-to-end "Internet Protocol" Internet with a single coherent address space? Most people don't use Internet addresses. In fact: most people already use an entirely application-intermediated address format: it's called "the first 4 results on a Google SERP".
Have you considered whether we're putting entirely too much emphasis on whether or not there is an end-to-end "Internet Protocol" Internet with a single coherent address space? Most people don't use Internet addresses. In fact: most people already use an entirely application-intermediated address format: it's called "the first 4 results on a Google SERP".
right. but the old internet... the way it used to be was that there was no real difference between a "client" and a "server" - an IP address was an IP address. Yeah, for most people, the Internet is the web, and that's enough. And nat works great for that.
The problem with enforcing this idea (that you have "clients" with private addresses behind a NAT and "servers" with public addresses) is that this won't be able to change. Doing peer to peer gaming, filesharing, video chat, etc... through multi-later (or carrier) nat is very difficult. It works through our home NATs right now, well, sortof, because there is one public IP for 2 or 3 computers. Upnp and other tricks can usually handle getting through a single layer nat with only a few private IPs behind it. If your ISP owns the nat and has hundreds of people behind the same v4 public IP, or in a double layer nat, where the ISP gives you a private IP behind a nat (that obviously doesn't support Upnp) suddenly this is going to work a lot less well.
Now, you can solve the problem by just making everything client-server. Want to video chat or game? each person needs to connect to a server with a public IP and talk through that server. It's doable, but it means that the Internet the next generation grows up with will be a different sort of network than the Internet I grew up with. This network will be one where you are either a "server" or a "consumer"
Some people say we've been moving in this direction for a long time, but this doesn't make it any less sad.
(also note... it's not just nerds that get screwed... if anything, gamers will get screwed more than nerds. Nerds can get VPSs that work just fine for most anything a nerd would want to do. VPSs, generally speaking, make shitty game servers, though.)
The problem with enforcing this idea (that you have "clients" with private addresses behind a NAT and "servers" with public addresses) is that this won't be able to change. Doing peer to peer gaming, filesharing, video chat, etc... through multi-later (or carrier) nat is very difficult. It works through our home NATs right now, well, sortof, because there is one public IP for 2 or 3 computers. Upnp and other tricks can usually handle getting through a single layer nat with only a few private IPs behind it. If your ISP owns the nat and has hundreds of people behind the same v4 public IP, or in a double layer nat, where the ISP gives you a private IP behind a nat (that obviously doesn't support Upnp) suddenly this is going to work a lot less well.
Now, you can solve the problem by just making everything client-server. Want to video chat or game? each person needs to connect to a server with a public IP and talk through that server. It's doable, but it means that the Internet the next generation grows up with will be a different sort of network than the Internet I grew up with. This network will be one where you are either a "server" or a "consumer"
Some people say we've been moving in this direction for a long time, but this doesn't make it any less sad.
(also note... it's not just nerds that get screwed... if anything, gamers will get screwed more than nerds. Nerds can get VPSs that work just fine for most anything a nerd would want to do. VPSs, generally speaking, make shitty game servers, though.)
This is exactly the opposite of reality.
In reality, having an IP address does not put you on an equal footing --- in a service model sense --- with other servers or companies that have paid massive amounts of money for peering. BigCo IP addresses are already "super-addresses", because they're BGP-advertiseable, and yours aren't.
So long as "full membership in the Internet" means "publicly routable IP address", you're going to get what your ISP is willing to give you and nothing more. This is true even in an IPv6 world! I'm not comfortable with this and you shouldn't be either. IP addresses are what network operators are giving greybeards to geek out over while they continue gobbling up the Internet.
What we need to do is accept an IPv4/NAT IP layer, define a minimum acceptable service model for ISPs to offer over it ("access to the web" being a good starting point), and then build application-layer overlay networks that provide the real services applications want, like broadcasting, peer-to-peer, location, presence, automatic configuration, and multihoming.
This isn't my crazy pie-in-the-sky idea (though the first startup I personally cofounded got this idea funded for several million dollars during the bubble). Is also the MIT PDOS RON idea, which Paul Graham's friend Robert Morris helped oversee.
It is also, for what it's worth, the logical conclusion of Saltzer and Reed's "End to End Argument In Systems Design". When you meet a challenge with a lower-level protocol, the answer tends to be to dumb it down to a point where you can build multiple variants of "something smarter" on top of it. We're at a point now where IP is simultaneously getting less relevant (organically, as more intelligence moves into HTTP-driven protocols) and more important (as we run out of addresses). The answer is not investing more effort in IP.
From a pragmatic perspective, the nice thing about this strategy is that it requires nothing from normal people. They'll use whatever IP their ISP gives them (NAT'd or otherwise), and it won't matter; it'll work just fine for the web today, and it'll work just fine for the TCP/SCTP/whatever-driven overlay networks we come up with tomorrow, where all the real action will be anyways. It's also nice to sit back and not worry about the IPv4acolypse and concentrate on building stuff instead.
In reality, having an IP address does not put you on an equal footing --- in a service model sense --- with other servers or companies that have paid massive amounts of money for peering. BigCo IP addresses are already "super-addresses", because they're BGP-advertiseable, and yours aren't.
So long as "full membership in the Internet" means "publicly routable IP address", you're going to get what your ISP is willing to give you and nothing more. This is true even in an IPv6 world! I'm not comfortable with this and you shouldn't be either. IP addresses are what network operators are giving greybeards to geek out over while they continue gobbling up the Internet.
What we need to do is accept an IPv4/NAT IP layer, define a minimum acceptable service model for ISPs to offer over it ("access to the web" being a good starting point), and then build application-layer overlay networks that provide the real services applications want, like broadcasting, peer-to-peer, location, presence, automatic configuration, and multihoming.
This isn't my crazy pie-in-the-sky idea (though the first startup I personally cofounded got this idea funded for several million dollars during the bubble). Is also the MIT PDOS RON idea, which Paul Graham's friend Robert Morris helped oversee.
It is also, for what it's worth, the logical conclusion of Saltzer and Reed's "End to End Argument In Systems Design". When you meet a challenge with a lower-level protocol, the answer tends to be to dumb it down to a point where you can build multiple variants of "something smarter" on top of it. We're at a point now where IP is simultaneously getting less relevant (organically, as more intelligence moves into HTTP-driven protocols) and more important (as we run out of addresses). The answer is not investing more effort in IP.
From a pragmatic perspective, the nice thing about this strategy is that it requires nothing from normal people. They'll use whatever IP their ISP gives them (NAT'd or otherwise), and it won't matter; it'll work just fine for the web today, and it'll work just fine for the TCP/SCTP/whatever-driven overlay networks we come up with tomorrow, where all the real action will be anyways. It's also nice to sit back and not worry about the IPv4acolypse and concentrate on building stuff instead.
>In reality, having an IP address does not put you on an equal footing --- in a service model sense --- with other servers or companies that have paid massive amounts of money for peering. BigCo IP addresses are already "super-addresses", because they're BGP-advertiseable, and yours aren't.
Ok, I often find I need to check myself before calling someone out on hacker news... several times I've found myself arguing with someone who was way more qualified than I was on the subject at hand.
but this is the exact opposite of what I understand "peering" to mean. From what I understand, settlement free peering is just that... it's free. Each party pays for half the cost of maintaining the line between them and packets bound from the customers of one peer to the other and vis-a-vis can traverse that link for free.
Generally speaking, when you pay for transit, it's called transit rather than peering.
(Now, my understanding is that there are cases where you would pay for peering... in this case, say you want to shave miliseconds off your ping time to some stock exchange... you can essentially buy transit that is limited to just the customers of your peer. In this case, there is "settlement" based on the number of packets going one way or the other. But, my understanding is that this isn't how it's usually done. Normally you look people up on peeringDB, and if you are exchanging enough traffic for it to make sense and you are on the same exchange, you set up a settlement-free peering agreement. Of course, all this shit is covered by NDA, so all we really have is hearsay)
Also, uh, all IPs are BGP advertisable. If you are small, your ISP does the BGP advertising (and the peering) I mean, if I buy my connectivity from above.net, they peer with everyone, right? so that's pretty close to me peering with everyone. Now, if you buy connectivity from a poorly connected ISP, sure, your network is going to be slightly slower... but it's still certainly BGP-advertiseable - it's just that you've outsourced the management of that BGP advertisement to your ISP.
Right now I'm working on moving the BGP router into my control, so I'm getting first hand experience with things I've watched people do in the past. And really, unless your primary business is infrastructure (and, well, mine is) it often doesn't make sense for you to run your own BGP router. I mean, it's one of those easy to screw up things. Most places I've worked that did their own BGP had more outages due to the new guy jacking with the router than due to upstream outages (which controlling your own BGP router, assuming you have multiple transit providers, can protect you from.)
Ok, I often find I need to check myself before calling someone out on hacker news... several times I've found myself arguing with someone who was way more qualified than I was on the subject at hand.
but this is the exact opposite of what I understand "peering" to mean. From what I understand, settlement free peering is just that... it's free. Each party pays for half the cost of maintaining the line between them and packets bound from the customers of one peer to the other and vis-a-vis can traverse that link for free.
Generally speaking, when you pay for transit, it's called transit rather than peering.
(Now, my understanding is that there are cases where you would pay for peering... in this case, say you want to shave miliseconds off your ping time to some stock exchange... you can essentially buy transit that is limited to just the customers of your peer. In this case, there is "settlement" based on the number of packets going one way or the other. But, my understanding is that this isn't how it's usually done. Normally you look people up on peeringDB, and if you are exchanging enough traffic for it to make sense and you are on the same exchange, you set up a settlement-free peering agreement. Of course, all this shit is covered by NDA, so all we really have is hearsay)
Also, uh, all IPs are BGP advertisable. If you are small, your ISP does the BGP advertising (and the peering) I mean, if I buy my connectivity from above.net, they peer with everyone, right? so that's pretty close to me peering with everyone. Now, if you buy connectivity from a poorly connected ISP, sure, your network is going to be slightly slower... but it's still certainly BGP-advertiseable - it's just that you've outsourced the management of that BGP advertisement to your ISP.
Right now I'm working on moving the BGP router into my control, so I'm getting first hand experience with things I've watched people do in the past. And really, unless your primary business is infrastructure (and, well, mine is) it often doesn't make sense for you to run your own BGP router. I mean, it's one of those easy to screw up things. Most places I've worked that did their own BGP had more outages due to the new guy jacking with the router than due to upstream outages (which controlling your own BGP router, assuming you have multiple transit providers, can protect you from.)
Say you want to run an app out of your house. You can trivially afford both DSL and cable. Can you multihome your app using IPv4?
Your IP addresses aren't (in all likelihood) portable. If you have less than a certain number of addresses, they're actually not advertiseable, because ISPs will filter smaller announcements. Even if you have a portable allocation, you may find it difficult (ie, expensive) to get your ISP to advertise it.
It is obviously possible to overcome all these problems with skillful application of money, but that's my point: the IP address itself isn't giving you this power, but rather the juice you pay to your ISP to make that happen.
(It's been over 10 years since I had to configure default-free BGP4 anywhere, though I've spent a lot of time working with BGP4 since then. Feel free to call me out on any of this.)
Now consider your cable connection, your DSL connection, and BitTorrent. BitTorrent can trivially scale across multiple Internet connections. You don't (heh) have to ask your ISP for permission to multihome it. That's because BitTorrent lifts the task of endpoint rendezvous out of IP and up to the app layer.
The future belongs to things like BitTorrent, where the average user never has to care whether packets are being carried by IPv4 native, IPv4 NAT, IPv6, or carrier pidgeons.
Your IP addresses aren't (in all likelihood) portable. If you have less than a certain number of addresses, they're actually not advertiseable, because ISPs will filter smaller announcements. Even if you have a portable allocation, you may find it difficult (ie, expensive) to get your ISP to advertise it.
It is obviously possible to overcome all these problems with skillful application of money, but that's my point: the IP address itself isn't giving you this power, but rather the juice you pay to your ISP to make that happen.
(It's been over 10 years since I had to configure default-free BGP4 anywhere, though I've spent a lot of time working with BGP4 since then. Feel free to call me out on any of this.)
Now consider your cable connection, your DSL connection, and BitTorrent. BitTorrent can trivially scale across multiple Internet connections. You don't (heh) have to ask your ISP for permission to multihome it. That's because BitTorrent lifts the task of endpoint rendezvous out of IP and up to the app layer.
The future belongs to things like BitTorrent, where the average user never has to care whether packets are being carried by IPv4 native, IPv4 NAT, IPv6, or carrier pidgeons.
>Your IP addresses aren't (in all likelihood) portable. If you have less than a certain number of addresses, they're actually not advertiseable, because ISPs will filter smaller announcements. Even if you have a portable allocation, you may find it difficult (ie, expensive) to get your ISP to advertise it.
Yes, my home IP addresses are not portable... but IP portability doesn't matter until you have a large number of IP addresses. Ok, so I have to renumber the 8 servers I have in the garage, big deal. Now, if I have to renumber the 1000+ virtuals I've got in the data center, that is a big deal. But my understanding is that everyone filters what's smaller than a /24, and some people filter below a /22... but at a bit over 1000, you are pushing a /22, so by the time that renumbering becomes a really impossible task, nobody filters you any longer.
Now, if you are multihoming for reliability rather than ease of switching ISPs, yeah, you have a good point. DSL has been neutered in that regard, which is really fucking irritating... but I understand why they did it. You know as well as I do that every route eats up a few bytes of ram in everyone else's BGP router, and TCAM is fucking expensive, so having a grand a month barrier before you can start adding your data to every bgp router in the world seems reasonable to me.
On the other hand, the barrier to getting some data center space and a multihomed /24 is pretty trivial by bay area sysadmin salary standards. Over the next week, that's one of my projects. One of my customer has an old /24 of swamp space he wants me to announce. It sounds like a good deal all around just 'cause my BGP foo was never good and what experience I have is old, so I get to practice on something I can break, and he gets to play in his swamp. It's going to cost the guy nothing 'cause I want to play around... It'd probably cost him something around a grand a month if he was going with someone more professional than I am and/or if he didn't already have the swamp space.
But my point was that if you pay for an ISP with good connectivity, you get all the benefits of their peering efforts. You are outsourcing your BGP management to your ISP, which for most people is going to result in better service than doing it themselves.
I think you can get 90% of the benefits of running your own BGP with a lot less hassle out of a $200/month co-lo plan. (just to be clear, that won't get you BGP you control or portable addresses, but if you've only got a few addresses, and the isp you chose is competent, well, that doesn't matter all that much for at least 90% of use cases.)
Edit: I know little of the bittorrent protocol... but my understanding, and this may be incorrect, was that bittorrent from one computer behind a nat (without upnp or the like) to another computer behind another nat (again without upnp or a port forward or the like) did not work well or at all... if you were behind a nat without a port forward (or upnp) you could only talk to peers that were on a public IP or had a port forward.
Yes, my home IP addresses are not portable... but IP portability doesn't matter until you have a large number of IP addresses. Ok, so I have to renumber the 8 servers I have in the garage, big deal. Now, if I have to renumber the 1000+ virtuals I've got in the data center, that is a big deal. But my understanding is that everyone filters what's smaller than a /24, and some people filter below a /22... but at a bit over 1000, you are pushing a /22, so by the time that renumbering becomes a really impossible task, nobody filters you any longer.
Now, if you are multihoming for reliability rather than ease of switching ISPs, yeah, you have a good point. DSL has been neutered in that regard, which is really fucking irritating... but I understand why they did it. You know as well as I do that every route eats up a few bytes of ram in everyone else's BGP router, and TCAM is fucking expensive, so having a grand a month barrier before you can start adding your data to every bgp router in the world seems reasonable to me.
On the other hand, the barrier to getting some data center space and a multihomed /24 is pretty trivial by bay area sysadmin salary standards. Over the next week, that's one of my projects. One of my customer has an old /24 of swamp space he wants me to announce. It sounds like a good deal all around just 'cause my BGP foo was never good and what experience I have is old, so I get to practice on something I can break, and he gets to play in his swamp. It's going to cost the guy nothing 'cause I want to play around... It'd probably cost him something around a grand a month if he was going with someone more professional than I am and/or if he didn't already have the swamp space.
But my point was that if you pay for an ISP with good connectivity, you get all the benefits of their peering efforts. You are outsourcing your BGP management to your ISP, which for most people is going to result in better service than doing it themselves.
I think you can get 90% of the benefits of running your own BGP with a lot less hassle out of a $200/month co-lo plan. (just to be clear, that won't get you BGP you control or portable addresses, but if you've only got a few addresses, and the isp you chose is competent, well, that doesn't matter all that much for at least 90% of use cases.)
Edit: I know little of the bittorrent protocol... but my understanding, and this may be incorrect, was that bittorrent from one computer behind a nat (without upnp or the like) to another computer behind another nat (again without upnp or a port forward or the like) did not work well or at all... if you were behind a nat without a port forward (or upnp) you could only talk to peers that were on a public IP or had a port forward.
This thread is officially unwieldy. I think you know what I'm saying now (even if you don't agree with it). My contact info is pretty easy to find.
I think 32 bits are fine, because I think IP addresses should be to 2020 what ethernet addresses were to 1994. We shouldn't forklift out IPv4; we should build a new city on the ruins.
More direct answer: yeah, I think 64 bits is a more reasonable addressing size, particularly if you accept the notion of second-class entities (that is to say, that the 15th heat sensor inside your toaster just might be OK with an RFC19180 private /8 address relayed through the toaster master control system's publicly routable address).
More direct answer: yeah, I think 64 bits is a more reasonable addressing size, particularly if you accept the notion of second-class entities (that is to say, that the 15th heat sensor inside your toaster just might be OK with an RFC19180 private /8 address relayed through the toaster master control system's publicly routable address).
From a purely aesthetic standpoint, IPv6 addresses look nasty.
IP addresses are supposed to be used by machines, not humans (considering network administrators are not humans). Humans should deal with domain names.
They vary in length,
IPv4 addresses also do. strlen("10.1.2.4") == 8; strlen("192.168.123.234") == 15.
The physical addresses don't vary in either case. IPv4 is always 32 bit, IPv6 is always 128 bits.
they're hard to remember,
As an administrator, you can make the particular addresses that you need to remember simple. The last 80 bits of the address are entirely yours, and the first 48 bits are fixed for your entire organisation. With IPv4 you end up having multiple very different /24s dispersed through your organisation, and having to fit your important servers in whatever free address space you can find.
So, for example, you know that 2001:db8:1245::/48 is the prefix for your organisation. It is only one you have to remember. Then you can set your DNS to 2001:db8:1245::1, your web server to 2001:db8:1245::2, etc... Not hard to remember.
they're a little bit harder to parse and print than v4s
This is the sort of problem that you have to solve only once (and it was already solved), then use that function/library wherever you want. See inet_ntop(3) and getnameinfo(3) (as a bonus, these functions work identically to both IPv4 and IPv6, the application becomes agnostic to the address class being used).
IP addresses are supposed to be used by machines, not humans (considering network administrators are not humans). Humans should deal with domain names.
They vary in length,
IPv4 addresses also do. strlen("10.1.2.4") == 8; strlen("192.168.123.234") == 15.
The physical addresses don't vary in either case. IPv4 is always 32 bit, IPv6 is always 128 bits.
they're hard to remember,
As an administrator, you can make the particular addresses that you need to remember simple. The last 80 bits of the address are entirely yours, and the first 48 bits are fixed for your entire organisation. With IPv4 you end up having multiple very different /24s dispersed through your organisation, and having to fit your important servers in whatever free address space you can find.
So, for example, you know that 2001:db8:1245::/48 is the prefix for your organisation. It is only one you have to remember. Then you can set your DNS to 2001:db8:1245::1, your web server to 2001:db8:1245::2, etc... Not hard to remember.
they're a little bit harder to parse and print than v4s
This is the sort of problem that you have to solve only once (and it was already solved), then use that function/library wherever you want. See inet_ntop(3) and getnameinfo(3) (as a bonus, these functions work identically to both IPv4 and IPv6, the application becomes agnostic to the address class being used).
I remember hearing some apocryphal story about a tech being frustrated that the numpad on your keyboard doesn't have a-f or ':' keys. Another way in which it doesn't fit with the way we do things in v4.
More to your point, I think this illustrates two things -- the need to use DNS more instead of static numbering in v6, and to number your infrastructure in the lowest /48 or /64 subnet of your allocation so that you can enjoy the benefit of omission of leading zeros for things you might actually need to type in by hand (e.g. 2001:db8:1f70::1)
More to your point, I think this illustrates two things -- the need to use DNS more instead of static numbering in v6, and to number your infrastructure in the lowest /48 or /64 subnet of your allocation so that you can enjoy the benefit of omission of leading zeros for things you might actually need to type in by hand (e.g. 2001:db8:1f70::1)
You can use hexadecimal for IPv4 already.
By the way, you can also give IPv4 addresses directly as one big number. E.g. `ping 1249729897' pings 74.125.93.105 (which is google.co.uk for me).
You can also go to http://74.125.93.105/ with your browser. (Though it depends on your browser, if it can parse this format. Chrome does.)
By the way, you can also give IPv4 addresses directly as one big number. E.g. `ping 1249729897' pings 74.125.93.105 (which is google.co.uk for me).
You can also go to http://74.125.93.105/ with your browser. (Though it depends on your browser, if it can parse this format. Chrome does.)
I don't think my router even supports IPv6. This is going to be -such- a fun transition.
I really thought people would get serious about it 2 years ago.
I really thought people would get serious about it 2 years ago.
Devices that don't support IPv6, or don't have IPv6 enabled, will just share an IPV4 address in a NAT pool at the ISP level. It's not pretty but it works.
Sort of. There are some very real limitations what what how much you can NAT too.
Never mind what happens when various services break due to double NATing and the various port filtering, think VOIP and the like. Probably not terribly difficult for a few P2P programs to DoS your ISP wide NAT as well.
Never mind what happens when various services break due to double NATing and the various port filtering, think VOIP and the like. Probably not terribly difficult for a few P2P programs to DoS your ISP wide NAT as well.
That still means that everything anyone wants to get to needs to be dual-stacked for the forseeable future.
Most of your software doesn't support IPv6, which I think is a bigger problem. Most everything that works with sockets assumes that a network address fits in a machine int type; IPv6 addresses aren't even scalar.
You mentioned twice that IPv6 addresses aren't scalar in this discussion. Why?
Are you talking about the scope identifier or the flow label? The scope identifier is not used by the Network Layer, it is used to disambiguate between addresses in different Data Link Layer outputs by the operating system, but plays no role in routing after the packet leaves the network card. There is no field for it in the IPv6 packet.
The flow label is part of the IPv6 packet, but it is used for routing and quality of service, it is not used for addressing.
So, the IPv6 address is actually just a 128-bit scalar integer, that goes from 0 to 340282366920938463463374607431768211455, with different sub-ranges designated to different purposes.
Are you talking about the scope identifier or the flow label? The scope identifier is not used by the Network Layer, it is used to disambiguate between addresses in different Data Link Layer outputs by the operating system, but plays no role in routing after the packet leaves the network card. There is no field for it in the IPv6 packet.
The flow label is part of the IPv6 packet, but it is used for routing and quality of service, it is not used for addressing.
So, the IPv6 address is actually just a 128-bit scalar integer, that goes from 0 to 340282366920938463463374607431768211455, with different sub-ranges designated to different purposes.
In very few languages people use today is there a 128 bit scalar integer type. You're right to point out that I'm being imprecise with my terms, but I think now you get what I'm saying.
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-... Once this is published as an RFC we can all start asking the vendors to support it.
It would be fixed with firmware updates in an ideal world.
There are a lot of addresses that should be 'reclaimed' . These days, most enterprises really only need a few public addresses, and many of them are 'sitting on' large chunks of addresses they acquired in the 90s.
It would be a better use of everybody's energy to actually get to work on the IPv6 transition, rather than trying to squeeze another couple of years out of IPv4. I think it should be pretty much obvious to everyone by now that until we actually hit the wall of IPv4, no one is going to get serious about the transition. NAT is not a great solution - it's a hack, and as anybody that has had to set up a server behind a NAT knows, it can be a real pain.
I'll wager that most residential Internet users are NAT'd, as are most corporate Internet users. The Internet works better today than it did back in 1996, when virtually nobody was NAT'd (back then, the big imposition was dynamic addresses instead of static).
NAT'd by their own router you mean? Because that seems like a world of difference from ISP-level NAT which I can imagine breaking a lot of shit.
When people argue that IPv6 is necessary because NAT is a terrible hack that breaks applications, they are talking about the concept of NAT, the thing that makes it hard to pass a callback address in protocols they design and that requires their routers to peek into their FTP traffic.
I'm sure ISP NAT is at some level worse than home NAT, but the point is, we can scale our IPv4 address space if companies stop, for instance, spending /19's to give every one of their desktops a routable IP address (which are then firewalled off the Internet anyways). We'll simply have to accept some form of self-managed NAT to do that.
I'm fine with that. We're freighting IP with too much responsibility and it's holding us back. We'd have multicast in several different service models by now if people would just stop trying to get Cisco IOS routers to do it for us.
I'm sure ISP NAT is at some level worse than home NAT, but the point is, we can scale our IPv4 address space if companies stop, for instance, spending /19's to give every one of their desktops a routable IP address (which are then firewalled off the Internet anyways). We'll simply have to accept some form of self-managed NAT to do that.
I'm fine with that. We're freighting IP with too much responsibility and it's holding us back. We'd have multicast in several different service models by now if people would just stop trying to get Cisco IOS routers to do it for us.
Please don't. This would just be another temporary solution allowing us to get even more invested in a flawed technology. We need to do the move as soon as possible so I really hope no "hero" comes in and buys us 5 more years on this.
As opposed to "reclaiming" addresses i.e. returning addresses to the registries, we should come up with a scheme were institutions can sell their addresses (i.e. IPv4 addresses should become property). This would give institutions that possess very large blocks of addresses a large incentive to effectively utilize their address space.
We could go on for a long-time with IPv4 if the above were to occur.
We could go on for a long-time with IPv4 if the above were to occur.
While I agree, reclaiming them would only delay the inevitable by a few months or a couple years, perhaps.
There certainly is. As of a couple of years ago IBM's 9.0.0.0/8 network was only used for their intranet and not routed outside. I believe several legacy /8's are in the same boat.
I'm already on IPv6. Find yourself an old 486 in the trash somewhere, get an OpenBSD install CD, and you can be too.
Every host on an IP network, from servers to personal computers to networked printers, is assigned an IP address, a unique identifying number that is used to communicate with other hosts on the same network, or globally.
This is misleading: computers (and especially printers) attached to a local network do not deplete public IP addresses, even if the network is connected to the global internet.
Should not the TC crowd be a little more computer savvy than this?
This is misleading: computers (and especially printers) attached to a local network do not deplete public IP addresses, even if the network is connected to the global internet.
Should not the TC crowd be a little more computer savvy than this?
> This is misleading: computers (and especially printers) attached to a local network do not deplete public IP addresses
A device connected to a LAN in someone's house will often just have a private IP and go through a NAT for its internet access.
However many big organisations will have been allocated a large address space at some point, often the size of a Class B. Their machines internally will often use a global IP address. The printers I use at university have their own public IPs. I'm guessing that's not unusual.
A device connected to a LAN in someone's house will often just have a private IP and go through a NAT for its internet access.
However many big organisations will have been allocated a large address space at some point, often the size of a Class B. Their machines internally will often use a global IP address. The printers I use at university have their own public IPs. I'm guessing that's not unusual.
Good point. I thought that there is not much use for a public IP for a printer, but I did not think about big address allocations.
But is there any convenience in this? Can't they just switch a private LAN infrastructure connected through NAT?
But is there any convenience in this? Can't they just switch a private LAN infrastructure connected through NAT?
If they have the allocation, why wouldn't they use it?
That's how IP was supposed to work. And once you've worked in a network where everyone has a real, non-RFC1918 address, you'll probably not want to go back. It just makes things really convenient; you never need to worry about address space collisions if you decide to connect two building networks together, for instance ... it's a whole lot more elegant than private addressing.
The places I've worked at that have legacy allocations have absolutely no interest in switching to RFC1918, and their allocation agreements are old enough that they don't contain any clawback provisions. It'll be "from my cold, dead hands" before they transition, and I can't blame them. It's how the Internet was supposed to work.
It's unfortunate that IPv6 got used as a way to shoehorn in a lot of stuff besides just increasing the address space. I've periodically seen much more conservative proposals that would have been less of a "forklift upgrade" and I think in retrospect it's unfortunate that these weren't considered.
But if IPv6 manages to kill or at least discourage the widespread use of RFC1918 addresses and bring back a more peer-to-peer architecture, it will be worth it in the long haul. The variety of applications and use cases we would be killing off without even knowing it by continuing down the path towards multiple layers of private addresses (because they just wouldn't be possible under that topology, and hence would never get developed) ought to sober anyone interested in development and new technology.
It may be possible for the Internet of today to work just fine with ISP-level NAT on top of home-network NAT, but if we resign ourselves to that we're shutting out a whole lot of interesting future possibilities that can only happen with an Internet that has end-to-end routability without second-class citizens. That would be truly sad.
That's how IP was supposed to work. And once you've worked in a network where everyone has a real, non-RFC1918 address, you'll probably not want to go back. It just makes things really convenient; you never need to worry about address space collisions if you decide to connect two building networks together, for instance ... it's a whole lot more elegant than private addressing.
The places I've worked at that have legacy allocations have absolutely no interest in switching to RFC1918, and their allocation agreements are old enough that they don't contain any clawback provisions. It'll be "from my cold, dead hands" before they transition, and I can't blame them. It's how the Internet was supposed to work.
It's unfortunate that IPv6 got used as a way to shoehorn in a lot of stuff besides just increasing the address space. I've periodically seen much more conservative proposals that would have been less of a "forklift upgrade" and I think in retrospect it's unfortunate that these weren't considered.
But if IPv6 manages to kill or at least discourage the widespread use of RFC1918 addresses and bring back a more peer-to-peer architecture, it will be worth it in the long haul. The variety of applications and use cases we would be killing off without even knowing it by continuing down the path towards multiple layers of private addresses (because they just wouldn't be possible under that topology, and hence would never get developed) ought to sober anyone interested in development and new technology.
It may be possible for the Internet of today to work just fine with ISP-level NAT on top of home-network NAT, but if we resign ourselves to that we're shutting out a whole lot of interesting future possibilities that can only happen with an Internet that has end-to-end routability without second-class citizens. That would be truly sad.
> Can't they just switch a private LAN infrastructure connected through NAT?
They could and given that in most organisations devices are already generally subject to restrictive firewall rules it shouldn't impact them all that much.
I think it would be better to focus efforts on making these organisations move to IPv6. This could possibly be achieved by ordering them to give back most of their IPv4 addresses. Since they will then be forced to reorganise their infrastructure anyway they could use this opportunity to switch on IPv6 across their organisation at the same time, if they haven't already.
They could and given that in most organisations devices are already generally subject to restrictive firewall rules it shouldn't impact them all that much.
I think it would be better to focus efforts on making these organisations move to IPv6. This could possibly be achieved by ordering them to give back most of their IPv4 addresses. Since they will then be forced to reorganise their infrastructure anyway they could use this opportunity to switch on IPv6 across their organisation at the same time, if they haven't already.
> This could possibly be achieved by ordering them to give back most of their IPv4 addresses.
That would take years and cost millions of dollars, just for the lawyers.
New address allocations make it clear that you're really only being loaned the addresses -- but the old allocations didn't. Insofar as you can "own" a bunch of addresses, the companies and organizations with legacy allocations really do own them, and I suspect many of them (the ones that haven't voluntarily given them up already) probably aren't interested in giving them up and might decide to fight back.
Look over a list of Class As and tell me which you'd like to take on in court.
Obviously they could be bribed into giving those addresses up, if someone wanted to cover the cost of switching ... but if you're going to spend the money, there are probably better things you could do to spur IPv6 adoption than spend it on corporate networks with a well-defined upgrade policy. You'd probably do better to work with the big residential ISPs, or maybe with the wireless carriers, since that's where a lot of the new demand growth is.
The legacy allocation ship sailed a long time ago, and there are better things we can do now than try to chase it down and board it by force.
That would take years and cost millions of dollars, just for the lawyers.
New address allocations make it clear that you're really only being loaned the addresses -- but the old allocations didn't. Insofar as you can "own" a bunch of addresses, the companies and organizations with legacy allocations really do own them, and I suspect many of them (the ones that haven't voluntarily given them up already) probably aren't interested in giving them up and might decide to fight back.
Look over a list of Class As and tell me which you'd like to take on in court.
Obviously they could be bribed into giving those addresses up, if someone wanted to cover the cost of switching ... but if you're going to spend the money, there are probably better things you could do to spur IPv6 adoption than spend it on corporate networks with a well-defined upgrade policy. You'd probably do better to work with the big residential ISPs, or maybe with the wireless carriers, since that's where a lot of the new demand growth is.
The legacy allocation ship sailed a long time ago, and there are better things we can do now than try to chase it down and board it by force.
Printing from off-site is easier with a public IP, I don't know how often that is necessary.
This would be better done with a VPN than simply allowing external access to your printers.
That works until you're sitting behind another NAT that uses the same internal IP range as the one you connect to over VPN - which is very likely since everyone uses 192.168.0.0/24.
Assuming the VPN server doesn't just allocate from a pool of public IPs owned by the organisation you're connecting into (the scenario I had in mind here) then yes this is an issue.
I'd guess that the NAT+NAT problem is more common than the enterprise variant, since very few companies other than enterprises have more than a few IPs.
I'd wager it's done more often by accident than on purpose.
[deleted]
Every host on an IP network, from servers to personal computers to networked printers, is assigned an IP address, a unique identifying number that is used to communicate with other hosts on the same network, or globally.
This statement stands for itself. I don't see where it is implied that locally assigned addresses deplete the global IP space. Are you sure you aren't misappropriating the "or globally" part?
This statement stands for itself. I don't see where it is implied that locally assigned addresses deplete the global IP space. Are you sure you aren't misappropriating the "or globally" part?
Haven't we been told that IPv4 will run out "next year" for the past couple of years?
I mean, yeah, it's a legitimate concern and all, but if you keep crying wolf...
I mean, yeah, it's a legitimate concern and all, but if you keep crying wolf...
http://ipv6.he.net/statistics/
Check the "v4 Exhaustion" widget on the right. It currently reckons there are 228 days left. I wrote an article about it on the 28th of May this year, and on that date, the widget calculated there were 427 days left.
Check the "v4 Exhaustion" widget on the right. It currently reckons there are 228 days left. I wrote an article about it on the 28th of May this year, and on that date, the widget calculated there were 427 days left.
No - the estimates I've seen have always been 'the space will run out in a few years'.
It was a best estimate at the time. Reclaiming unused/wasted IPv4 space has helped some but routers have probably had a bigger impact. 5 years ago most ISPs were working under the assumption that the average customer was going to need (at least) 2 IPv4 addresses. My guess is the economic meltdown probably slowed down the growth of the Internet worldwide as well. I haven't seen any firm numbers to back that up it though.
Most recent previous discussion http://news.ycombinator.com/item?id=1742305
I just keep thinking about some of the "greybeards" as @tptacek said. The US Dept of Defense owns TEN class A blocks. HP owns two class A blocks, due to acquiring DEC (indirectly) Do they need that much space? I doubt it. Getting them to give back some space is not a long-term solution, but it would give this a little more time
Can I buy cheap IPv6 SSL certificates yet?
Will it be auctioned on eBay?
Consider a pair of random IPs in standard written form:
From a purely aesthetic standpoint, IPv6 addresses look nasty. They vary in length, they're hard to remember, they're a little bit harder to parse and print than v4s. Much like an email address, an IPv4 address is iconic (to the right people) and immediately recognizable, whereas it would be easy to confuse a v6 for a MAC address. Is it at all possible that this is hampering adoption of IPv6?