The UK has an entire IPv4 /8 that it isn't using(blog.jgc.org)
blog.jgc.org
The UK has an entire IPv4 /8 that it isn't using
http://blog.jgc.org/2012/09/the-uk-has-entire-unused-ipv4-8-that-is.html
19 comments
"fiat allocation doesn't work"
Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.
The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.
I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.
Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.
[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.
Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.
The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.
I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.
Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.
[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.
If we're talking about advertisable blocks, the Germany scenario doesn't happen. For the time being, there can't be a liquid market for /32's, at least not one that works acros multiple ISPs.
I agree with you strongly that the 128 bit IP address is a huge design mistake, one that has unnecessarily retarded the deployment of IPv6 (I personally believe fatally so). Even in the '90s, a 64 bit number was still a scalar on most platforms you'd care about. And even in 2012, 128 bit numbers aren't. I think people drastically underestimate the amount of work it's going to take to upgrade the huge amount of software built on the assumption that you can store an IP address in a scalar.
I agree with you strongly that the 128 bit IP address is a huge design mistake, one that has unnecessarily retarded the deployment of IPv6 (I personally believe fatally so). Even in the '90s, a 64 bit number was still a scalar on most platforms you'd care about. And even in 2012, 128 bit numbers aren't. I think people drastically underestimate the amount of work it's going to take to upgrade the huge amount of software built on the assumption that you can store an IP address in a scalar.
> huge amount of software built on the assumption that you can store an IP address in a scalar
The truly huge universe of code is at the application level. Sane applications use strings for remote hosts, or work with URL's, and let library- or OS-level code deal with the details of turning that into an address.
OS'es -- even Windows -- have supported IPv6 for nearly a decade. Most networking libraries I've come across also have IPv6 support.
The main problem isn't software, it's configuration. Namely the configuration of the interface between the customer network and the ISP. The ISP doesn't want to turn on IPv6 because it might break some customers, and the customer can't test IPv6 functionality since their ISP doesn't support it.
These problems are compounded for residential ISP's, since most of their customers can't be bothered to learn anything technical.
The truly huge universe of code is at the application level. Sane applications use strings for remote hosts, or work with URL's, and let library- or OS-level code deal with the details of turning that into an address.
OS'es -- even Windows -- have supported IPv6 for nearly a decade. Most networking libraries I've come across also have IPv6 support.
The main problem isn't software, it's configuration. Namely the configuration of the interface between the customer network and the ISP. The ISP doesn't want to turn on IPv6 because it might break some customers, and the customer can't test IPv6 functionality since their ISP doesn't support it.
These problems are compounded for residential ISP's, since most of their customers can't be bothered to learn anything technical.
That is nice to hear. My biggest problem with IPv6 has always been the size of the addresses, which I think is too big, but I always thought I was just being old-fashioned. It's interesting to see other people think the same, although probably for different or more justified reasons.
At the time it was really frustrating to hear people say "64 bits is just twice as big as it is now, that will never last" and I would say emphatically "No, that is FOUR BILLION times bigger!" and get hit with "Well what if every light switch in the world had its own IP address huh? huh?" and I would say "Yup, if that happened we MIGHT use up may 10 or 16 BILLIONTHS of the address space just for lights, the equivalent impact of dedicating a class B in the current address space to lights, which nobody would really think twice about."
Alas, such discussions were not compelling.
Alas, such discussions were not compelling.
>More evidence for the core problem: fiat allocation doesn't work. If there was a functioning, liquid, accessible market for advertisable IP prefixes, you wouldn't have to convince anyone that a /8 was worth $1bn; it just would be.
you are missing a big point. This isn't like real-estate. This is plumbing.
Go do a search on "routing table growth"
This is actually a much larger problem than IPv4 runout. I mean, it's a problem that is further out, but it is going to hit well within my expected lifetime, and it's going to be a dramatically more difficult problem to solve.
The thing is, every time you break up a larger block into a smaller block, every router on the internet needs an entry in their routing tables[1] Usually, in content-addressable memory; Expensive stuff.
The thing is, the size of the global routing table? it's growing faster than moore's law.[2] I mean, it's not a huge deal now; for the price of a new compact car, you can get a router that has enough content-addressable memory to handle full tables and two 10g uplinks with 48 1g downlinks. reasonable cost of entry, if you ask me, and if you use dram (good luck with line rate 10G. don't think about faster line-rate.) well, then the cost is trivial. The routing table is under 500,000 entries in IPv4, so it's a trivial amount of dram.
The problem is that if this continues? (and all indications are that it's going to /massively accelerate/ if IPv6 catches on. At a minimum, you're gonna see the same number of ipv6 routes as ipv4 routes... and because IPv6 addresses are larger, ipv6 routes are larger) those routers are going to get more and more expensive.
So yeah, really? we need a way of charging, not for each IP, but for each announced route. Of course, that comes down hard on the little guys, whereas a per-IP charge is much more progressive. (a /8 takes up as many routing table entries as a /24.)
Getting by with a reduced number of IPs would be way easier for me than getting by without announcing my own block. Without BGP announcing my own block, my ISP has my balls in a vice. If they go down? I go down. More importantly, I need to change IPs when I switch to a new ISP.
I know what this is like, because I started out on my ISPs IP addresses, like almost everyone does. My provider found out that it's hard for me to switch off those IPs, so now I'm paying them, in total, for all the services they provide me, about twice market rate.
(It's actually really interesting, watching the dynamics of this problem play out on PPML or the like. Small players, like me, want to keep it easy to announce smaller blocks. We are fucked if you can only announce large blocks. Large players want tight restrictions on what size of a block you can announce, because they have the address space and they would rather not pay for more super-expensive CAM every time a Luke Crawford gets it in his head to start an ISP.)
[1] This is not strictly true. "every router that matters" would be closer to the truth. If you don't have full tables from multiple upstreams, well, you will be effected by rather more partial outages than if you do.
[2]http://bgp.potaroo.net/
[3]http://bgp.potaroo.net/index-bgp.html
you are missing a big point. This isn't like real-estate. This is plumbing.
Go do a search on "routing table growth"
This is actually a much larger problem than IPv4 runout. I mean, it's a problem that is further out, but it is going to hit well within my expected lifetime, and it's going to be a dramatically more difficult problem to solve.
The thing is, every time you break up a larger block into a smaller block, every router on the internet needs an entry in their routing tables[1] Usually, in content-addressable memory; Expensive stuff.
The thing is, the size of the global routing table? it's growing faster than moore's law.[2] I mean, it's not a huge deal now; for the price of a new compact car, you can get a router that has enough content-addressable memory to handle full tables and two 10g uplinks with 48 1g downlinks. reasonable cost of entry, if you ask me, and if you use dram (good luck with line rate 10G. don't think about faster line-rate.) well, then the cost is trivial. The routing table is under 500,000 entries in IPv4, so it's a trivial amount of dram.
The problem is that if this continues? (and all indications are that it's going to /massively accelerate/ if IPv6 catches on. At a minimum, you're gonna see the same number of ipv6 routes as ipv4 routes... and because IPv6 addresses are larger, ipv6 routes are larger) those routers are going to get more and more expensive.
So yeah, really? we need a way of charging, not for each IP, but for each announced route. Of course, that comes down hard on the little guys, whereas a per-IP charge is much more progressive. (a /8 takes up as many routing table entries as a /24.)
Getting by with a reduced number of IPs would be way easier for me than getting by without announcing my own block. Without BGP announcing my own block, my ISP has my balls in a vice. If they go down? I go down. More importantly, I need to change IPs when I switch to a new ISP.
I know what this is like, because I started out on my ISPs IP addresses, like almost everyone does. My provider found out that it's hard for me to switch off those IPs, so now I'm paying them, in total, for all the services they provide me, about twice market rate.
(It's actually really interesting, watching the dynamics of this problem play out on PPML or the like. Small players, like me, want to keep it easy to announce smaller blocks. We are fucked if you can only announce large blocks. Large players want tight restrictions on what size of a block you can announce, because they have the address space and they would rather not pay for more super-expensive CAM every time a Luke Crawford gets it in his head to start an ISP.)
[1] This is not strictly true. "every router that matters" would be closer to the truth. If you don't have full tables from multiple upstreams, well, you will be effected by rather more partial outages than if you do.
[2]http://bgp.potaroo.net/
[3]http://bgp.potaroo.net/index-bgp.html
A Xeon E3-1220 has an 8MB L3 cache and costs about $210. If you deaggregate the entire IPv4 routing table to /24s to support fast lookups and store one nibble of destination data per route (probably just a destination interface number, if you can live with only 15 or 16 possible destinations, but you probably don't have that many upstreams), doesn't that mean that the entire routing table can fit in the L3 cache on the CPU (with a bit of the L3 not used by class E space, which will leave a bit of space for code, assuming you aren't doing anything but routing on this CPU)?
Now, it's quite possible that the Linux kernel's routing isn't dimensioned to provide this sort of performance, but if you want to avoid CAM in the IPv4 world, I don't see why you'd really need CAM...
(Also, I haven't looked carefully at how the L3 cache actually works on the E3s to make sure that it's shared between code and data, etc etc etc. Also, if you're actually implementing this, you presumably do want to include class E in the table, and then hope/assume that when class E doesn't get used, the CPU will be smart enough to cache the code instead.)
Now, it's quite possible that the Linux kernel's routing isn't dimensioned to provide this sort of performance, but if you want to avoid CAM in the IPv4 world, I don't see why you'd really need CAM...
(Also, I haven't looked carefully at how the L3 cache actually works on the E3s to make sure that it's shared between code and data, etc etc etc. Also, if you're actually implementing this, you presumably do want to include class E in the table, and then hope/assume that when class E doesn't get used, the CPU will be smart enough to cache the code instead.)
>A Xeon E3-1220 has an 8MB L3 cache and costs about $210. If you deaggregate the entire IPv4 routing table to /24s to support fast lookups and store one nibble of destination data per route (probably just a destination interface number, if you can live with only 15 or 16 possible destinations, but you probably don't have that many upstreams), doesn't that mean that the entire routing table can fit in the L3 cache on the CPU (with a bit of the L3 not used by class E space, which will leave a bit of space for code, assuming you aren't doing anything but routing on this CPU)?
Hm. interesting. so, uh, for simplicity, we have 256^3 routes, right? each one is, uh, what,33 bits of data? I mean, you need 3 bytes for the network and then what, uh, 5 bits for the mask? then okay 4 bits for the dest so 33 bits per route, no? so (33*256^3)/8 is 69206016 bits, or what,66 megabytes? sweet jesus, you are right. I mean, you are off by an order of magnitude, but at this scale, who gives a shit about an order of magnitude.
Interesting. 'cause none of the commercial routers do this. which is fucking weird. With this optimization (only store the first 3 octets, as you aren't routing anything smaller, have a lookup table for dest. addresses.) you could take full tables in puny amounts of CAM that come on, say, l3 switches. I will ask around as to why this isn't done.
(of course, with IPv6, this does not come close to solving the problem. /32 is the 'standard' handout for ISPs, and usually the smallest prefix you accept is a /48. There are a lot of fucking /32s.)
Also, you'd have some complications, as /32s are commonly used to blackhole DDoS targets, but you only have a handful of those, so that would add complexity but it wouldn't kill the idea.
I bet I'm missing something- I mean, every two bit ISP would be really happy to give you ten grand for a 10G full-tables bgp router, and you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
Hm. interesting. so, uh, for simplicity, we have 256^3 routes, right? each one is, uh, what,33 bits of data? I mean, you need 3 bytes for the network and then what, uh, 5 bits for the mask? then okay 4 bits for the dest so 33 bits per route, no? so (33*256^3)/8 is 69206016 bits, or what,66 megabytes? sweet jesus, you are right. I mean, you are off by an order of magnitude, but at this scale, who gives a shit about an order of magnitude.
Interesting. 'cause none of the commercial routers do this. which is fucking weird. With this optimization (only store the first 3 octets, as you aren't routing anything smaller, have a lookup table for dest. addresses.) you could take full tables in puny amounts of CAM that come on, say, l3 switches. I will ask around as to why this isn't done.
(of course, with IPv6, this does not come close to solving the problem. /32 is the 'standard' handout for ISPs, and usually the smallest prefix you accept is a /48. There are a lot of fucking /32s.)
Also, you'd have some complications, as /32s are commonly used to blackhole DDoS targets, but you only have a handful of those, so that would add complexity but it wouldn't kill the idea.
I bet I'm missing something- I mean, every two bit ISP would be really happy to give you ten grand for a 10G full-tables bgp router, and you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
So, I /really/ made myself look like an idiot here:
>you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
Because I was confusing TCAM with DRAM; rather different sorts of things. (and that, I'd classify as a mistake of inattention. I made other mistakes in that message due to lack of knowledge, but, uh, yeah; I'm not usually /that/ dumb.)
Anyhow, uh, yeah. Looks like I also misunderstood what the parent comment was trying to do (/increase/ the size of the lookup table by breaking larger blocks into /24s, in order to reduce the number of cycles the CPU spends on the lookup.)
So yeah, in full? I'd delete my comment that I'm responding to here if I could. As I can't, I'd like to acknowledge my ignorance, for the record.
If I could rewrite that, I'd say something to the effect that huge amounts of effort have gone into making TCAM obsolete, and so far? well, progress is being made, but the progress isn't moving any faster than line-rates are going up, as far as I can tell. There are very smart people working on the problem, and they say it's a big problem. (my understanding and experience, as a sysadmin that also deals with networks, is that your linux-based PC routers can route something between 1G and 10G of line-rate small packets. Above that, PC routers can't cope with the PPS.)
Note, uh, I do have two spare E3 xeons laying about the office, and 10G interface cards for both, as well as (at least for a short while longer) two nice arista brand 10G switches, so if you are in the sunnyvale area, and you do want to test an idea or bench the current state of the art of software routers, well, it's something I've gotta do anyhow. I still don't have anything even attempting to route my new 10GbE Cogent port. (I've split off a 1Gbe connection using a switch, and plugged the 1Gbe connection into my existing quagga router.)
>you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
Because I was confusing TCAM with DRAM; rather different sorts of things. (and that, I'd classify as a mistake of inattention. I made other mistakes in that message due to lack of knowledge, but, uh, yeah; I'm not usually /that/ dumb.)
Anyhow, uh, yeah. Looks like I also misunderstood what the parent comment was trying to do (/increase/ the size of the lookup table by breaking larger blocks into /24s, in order to reduce the number of cycles the CPU spends on the lookup.)
So yeah, in full? I'd delete my comment that I'm responding to here if I could. As I can't, I'd like to acknowledge my ignorance, for the record.
If I could rewrite that, I'd say something to the effect that huge amounts of effort have gone into making TCAM obsolete, and so far? well, progress is being made, but the progress isn't moving any faster than line-rates are going up, as far as I can tell. There are very smart people working on the problem, and they say it's a big problem. (my understanding and experience, as a sysadmin that also deals with networks, is that your linux-based PC routers can route something between 1G and 10G of line-rate small packets. Above that, PC routers can't cope with the PPS.)
Note, uh, I do have two spare E3 xeons laying about the office, and 10G interface cards for both, as well as (at least for a short while longer) two nice arista brand 10G switches, so if you are in the sunnyvale area, and you do want to test an idea or bench the current state of the art of software routers, well, it's something I've gotta do anyhow. I still don't have anything even attempting to route my new 10GbE Cogent port. (I've split off a 1Gbe connection using a switch, and plugged the 1Gbe connection into my existing quagga router.)
I'm not in the bay area.
Given your constraints, I wonder if what you actually want is one switch for each upstream, and a gigabit link from each of your physical Xen servers to each switch that goes to an upstream. If your switches have to route at all, they can each have a default route to the one respective upstream connected to that switch. Then, have a VM on each physical Xen server with full routing tables to control how the outbound packets from all the VMs on that physical host get routed. And hopefully your switches can deal with a /32 route for each VM or something, if they just have a route per VM plus a default route to the one ISP they're connected to.
There's also the variant where you have a /24 block (or something) which has one IP address which is your ISP's router, and then one IP address per physical Xen server, and if your ISP is willing to take individual /32 announcements to your servers (I think this is technically feasible, but may require more mental flexibility than some ISPs have; on the other hand, I think you're talking Cogent, and mentioned that Cogent is willing to peer directly with your customers, which may imply that you're dealing with a flexible ISP), you can have the ISP do the layer 3 routing to the right physical host for traffic going to each VM. (The idea is that the ISP would not propagate the /32s to their peers; you'd separately send them a broader announcement that they could pass along to their peers.)
One other issue in this scheme is that if a single gigabit link between one physical Xen host and the switch going to one ISP breaks, inbound traffic that happens to come to the ISP attached to the switch with the broken link ought to have some mechanism to find its way over to the other switch for the one physical Xen host that has the broken link. I think there are ways that OSPF and or iBGP with the non-default next-hop-self setting can be made to do this.
Given your constraints, I wonder if what you actually want is one switch for each upstream, and a gigabit link from each of your physical Xen servers to each switch that goes to an upstream. If your switches have to route at all, they can each have a default route to the one respective upstream connected to that switch. Then, have a VM on each physical Xen server with full routing tables to control how the outbound packets from all the VMs on that physical host get routed. And hopefully your switches can deal with a /32 route for each VM or something, if they just have a route per VM plus a default route to the one ISP they're connected to.
There's also the variant where you have a /24 block (or something) which has one IP address which is your ISP's router, and then one IP address per physical Xen server, and if your ISP is willing to take individual /32 announcements to your servers (I think this is technically feasible, but may require more mental flexibility than some ISPs have; on the other hand, I think you're talking Cogent, and mentioned that Cogent is willing to peer directly with your customers, which may imply that you're dealing with a flexible ISP), you can have the ISP do the layer 3 routing to the right physical host for traffic going to each VM. (The idea is that the ISP would not propagate the /32s to their peers; you'd separately send them a broader announcement that they could pass along to their peers.)
One other issue in this scheme is that if a single gigabit link between one physical Xen host and the switch going to one ISP breaks, inbound traffic that happens to come to the ISP attached to the switch with the broken link ought to have some mechanism to find its way over to the other switch for the one physical Xen host that has the broken link. I think there are ways that OSPF and or iBGP with the non-default next-hop-self setting can be made to do this.
...and, anyone who didn't have $1bn to spend would be SOL.
There's plenty of numbers to go around; the sooner we get to v6 and get around this mess, the better.
There's plenty of numbers to go around; the sooner we get to v6 and get around this mess, the better.
What an embarrassing failure of economic reasoning.
IPv4 addresses are a scare resource. Acknowledging that, and allowing them to be traded at a price that reflects their value, is the surest way to get them out of the hands of those who are wasting them in the way tptacek and the article describe and into the hands of those who will do something more productive with them. Pricing IPv4 addresses would hasten adoption of IPv6 by providing a financial incentive to switch from IPv4 to IPv6 to those who can do so most easily (i.e., cheaply).
In other words, if you want to "get around this mess", stop allocating scarce and valuable IPv4 addresses as if they have no value.
IPv4 addresses are a scare resource. Acknowledging that, and allowing them to be traded at a price that reflects their value, is the surest way to get them out of the hands of those who are wasting them in the way tptacek and the article describe and into the hands of those who will do something more productive with them. Pricing IPv4 addresses would hasten adoption of IPv6 by providing a financial incentive to switch from IPv4 to IPv6 to those who can do so most easily (i.e., cheaply).
In other words, if you want to "get around this mess", stop allocating scarce and valuable IPv4 addresses as if they have no value.
But (and someone correct me if I'm wrong), but individual IP addresses are not a commodity. If you broke apart that /8 and auctioned them off, if would be a routing nightmare.
It would if you auctioned off small prefixes, but the answer to that is just not to do that.
Are there any /8 which can't be broken down to at least /16? I think you can often get down to /19 or sometimes /22.
Smallest prefix that can be meaningfully used is /24 (you cannot advertise smaller prefix), but I think that everyone advertising random /24s would lead to even larger costs for router upgrades than IPv6.
I think there are still bigger than /24s where /24 announcements aren't allowed. People filtered for a while (at least around 2000-2002) in those ranges, so you couldn't just take a random swamp /16 and turn it into a bunch of /24s and expect them to be visible to everyone, although it did work to most. I haven't paid much attention to routing politics for the past 5 years or so though.
> What an embarrassing failure of economic reasoning.
1. IPv4 addresses are overdemanded and undersupplied.
2. IPv6 addresses are practically limitless and will serve the same purpose once we switch over.
3. We should switch to IPv6 ASAP.
Where's the economic flaw?
(Also, it should be pointed out that allowing trades on IPv4 would not decrease availability, it would only increase it: Right now, you can't switch the owner of /x blocks without IANNA approval, so right now you have no choice but to push for switching to v6, whereas with trading you could waste money on v4 instead. Moreover, this would encourage the companies with the most money to buy IPv4 blocks rather than invest in switching over to v6, which would slow down the process for everyone since they're the biggest companies. TLDR -- force investment in IPv6 not IPv4. There's also a fairness issue since these IPv4 blocks were originally allocated for free -- should MIT be able to make billions on their block?)
1. IPv4 addresses are overdemanded and undersupplied.
2. IPv6 addresses are practically limitless and will serve the same purpose once we switch over.
3. We should switch to IPv6 ASAP.
Where's the economic flaw?
(Also, it should be pointed out that allowing trades on IPv4 would not decrease availability, it would only increase it: Right now, you can't switch the owner of /x blocks without IANNA approval, so right now you have no choice but to push for switching to v6, whereas with trading you could waste money on v4 instead. Moreover, this would encourage the companies with the most money to buy IPv4 blocks rather than invest in switching over to v6, which would slow down the process for everyone since they're the biggest companies. TLDR -- force investment in IPv6 not IPv4. There's also a fairness issue since these IPv4 blocks were originally allocated for free -- should MIT be able to make billions on their block?)
BTW, address trading does exist.
There is usually a little more indirection, like buying a fuckedcompany with a /16.
Not any more. Within the ARIN region it's legal to straight-up sell addresses as long as the buyer is actually going to use them (people argue about this point a lot but it doesn't seem like a big deal IMO).
Where is this done now? I would be happy to pick up a /16 for a project.
Actually no, IP addresses are not a resource. They're not limited at all, except by convenience which was chosen at a time when they had to chose a limit and it was not practical to set it any higher. All that is needed is to make a new standard which allows for a higher practical limit -- and that's what we're doing with IPv6.
So I?v4 addresses only seem valuable in this moment, because so many of them have been distributed -- bvut something that can be added in unlimited quantities (like a number) is inherently not valuable.
Do you remember when DOS and Windows file names could only contain eight plus three letters? Was the solution to proclaim file names valuable and charge extra for adding new combinations? Or simply to develop a new platform which allowed for longer names?
So I?v4 addresses only seem valuable in this moment, because so many of them have been distributed -- bvut something that can be added in unlimited quantities (like a number) is inherently not valuable.
Do you remember when DOS and Windows file names could only contain eight plus three letters? Was the solution to proclaim file names valuable and charge extra for adding new combinations? Or simply to develop a new platform which allowed for longer names?
What you've done here is generalized the concept out so far that we can't discuss it. We're not talking about a fuzzy concept of "addresses"; we're talking specifically about IPv4 RIB entries.
The opposite is true. The current situation incentivizes entities with billion dollar budgets to hold address space forever, because there is no cost to them for doing so.
If you need 16 million IP addresses, you probably have $1bn.
What the heck? If you want an /8 you're probably SOL anyway.
Realistically, anyone with an /8 to sell would probably break it up. There is some speculation that legacy holders are selling off their unused addresses slowly because a glut would reduce prices.
[deleted]
I'm not sure about the definition of 'unused', just because a network is not visible from the Internet and has no publicly registered ASNs doesn't mean its numbers are not in private use (which AFAIK, was always a legitimate use-case for getting an allocation, and in many ways preferable to reusing RFC1918 space).
Added to that, even if it was seeing only minuscule internal use, the UK government's IT project reputation suggests the renumbering would cost at least as much as the block would sell for, assuming the project would even complete prior to the entire planet properly migrating to v6 and the block losing its value.
Added to that, even if it was seeing only minuscule internal use, the UK government's IT project reputation suggests the renumbering would cost at least as much as the block would sell for, assuming the project would even complete prior to the entire planet properly migrating to v6 and the block losing its value.
If there are no networks defined, as far as RIPE is concerned, it's un-used.
We just got audited for RIPE for exactly this reason, and they made us specify details for all of the networks we use on our allocation to be allowed to keep our address space.
We just got audited for RIPE for exactly this reason, and they made us specify details for all of the networks we use on our allocation to be allowed to keep our address space.
That's not the case for older legacy networks. Those don't fall under the purview of RIPE as they were allocated before RIPE existed.
I'm wondering if RIPE can even do anything regarding that netblock in terms of possibly pulling it and re-allocating it.
I'm wondering if RIPE can even do anything regarding that netblock in terms of possibly pulling it and re-allocating it.
As far as I know, they can't.
All they can do (and have already done) is ask nicely for it back.
All they can do (and have already done) is ask nicely for it back.
Well, if they were feeling ballsy, they could just declare it unused, break it up, and start assigning it. A lot more network nerds would listen to RIPE than to some random UK pension bureaucracy.
Under what circumstances is it the best thing for people to use otherwise routable IP addresses instead of private IP space?
Under all circumstances: I'm sure we've all been faced at some stage with the unplanned need to route between two RFC1918 subnets, only to find they collide, in situations as simple as a home VPN connection dialling into the office LAN, up to corporate mergers involving hundreds of thousands of desktops.
A central address registry along with 'public' allocations is the only way to avoid this kind of mess. The fact that public addresses are currently scarce doesn't make having unified addressing any less desirable (just presently impractical).
A central address registry along with 'public' allocations is the only way to avoid this kind of mess. The fact that public addresses are currently scarce doesn't make having unified addressing any less desirable (just presently impractical).
Sorry, I was imprecise. I meant, under what circumstances today is it the best thing to spend routable IP addresses for machines that aren't exposed directly to the Internet? I'm getting directly at the practicality of these schemes. Obviously, if routable IP addresses were easy to get, there would be lots of cases where it would make sense to use them.
I just gave you a reason. Without coordination of private network addressing, those networks essentially speak different protocols, needing horrendous transforms like NAT which only works in specific situations and myriad crap over the application layer (like DNS views) in order to get them to talk.
If anything, today, networks are more likely to end up interconnected than they were in 1994.
If anything, today, networks are more likely to end up interconnected than they were in 1994.
> under what circumstances today is it the best thing to spend routable IP addresses for machines that aren't exposed directly to the Internet
Under the circumstance that you have a spare /8 you aren't using for anything.
You could argue that "the best thing" in that case would be giving, selling, or leasing pieces of the /8 to someone who needs the space. But maybe you aren't in the philanthropy business, so giving's out.
And maybe the prices aren't high enough for your taste, so selling or leasing are out. Or maybe there's simply not enough demand on the market to absorb 16m addresses. Or maybe the terms of the allocation agreement say you're not allowed to transfer them, and you're afraid that trying to do so will give the Internet people a justification to give them to someone else.
> if routable IP addresses were easy to get, there would be lots of cases where it would make sense to use them
If your organization has a spare /8, routable IP addresses are easy to get for you, so these cases do make sense, for you.
Under the circumstance that you have a spare /8 you aren't using for anything.
You could argue that "the best thing" in that case would be giving, selling, or leasing pieces of the /8 to someone who needs the space. But maybe you aren't in the philanthropy business, so giving's out.
And maybe the prices aren't high enough for your taste, so selling or leasing are out. Or maybe there's simply not enough demand on the market to absorb 16m addresses. Or maybe the terms of the allocation agreement say you're not allowed to transfer them, and you're afraid that trying to do so will give the Internet people a justification to give them to someone else.
> if routable IP addresses were easy to get, there would be lots of cases where it would make sense to use them
If your organization has a spare /8, routable IP addresses are easy to get for you, so these cases do make sense, for you.
No doubt part of the strategic IP reserve :-)
There are a number of ways the IP addresses can not appear to the outside user and still be used as several have mentioned, and of course they can be for some project that isn't yet 'done' (the Coast Guard had a huge block like that as I recall) but the more interesting bit is to track the cost of getting an /24 network its inching up. At the time where the easy stuff has been reclaimed it will shoot up.
There are a number of ways the IP addresses can not appear to the outside user and still be used as several have mentioned, and of course they can be for some project that isn't yet 'done' (the Coast Guard had a huge block like that as I recall) but the more interesting bit is to track the cost of getting an /24 network its inching up. At the time where the easy stuff has been reclaimed it will shoot up.
We need to quit looking back at the v4 space like this, bite the bullet and deploy v6. It's already in use on some networks, and inevitable on 95+% of the rest.
The amount of time spent bike-shedding "well, v4 isn't running out as fast as they say it is" or "NAT will save us" (lol, no) that time is better spent deploying v6. For many installations, its actually not that big of a deal to do.
The amount of time spent bike-shedding "well, v4 isn't running out as fast as they say it is" or "NAT will save us" (lol, no) that time is better spent deploying v6. For many installations, its actually not that big of a deal to do.
And we will move, but it's not going to happen until 98% of the world's networking infrastructure (both public and private) is IP6 ready, which probably won't be for another decade.
That's the thing though. If everyone is waiting on everyone else, nothing gets done.
If your network doesn't already support v6, you're the person everyone is waiting on! You don't need to wait for your upstream provider to supply you with v6, tunnels are super easy to get.
The only exception to tunneling is if you're hosting a public-facing service, don't have v6 connectivity and don't trust existing tunnel providers. In this case: First, why are you at you're current host or colo center? They're probably shit. Second, set up a box at a provider with good connectivity to run the tunnel yourself. This is basically what we already do when we want to use our public v4 space but the ISP doesn't want to let us talk BGP.
If your network doesn't already support v6, you're the person everyone is waiting on! You don't need to wait for your upstream provider to supply you with v6, tunnels are super easy to get.
The only exception to tunneling is if you're hosting a public-facing service, don't have v6 connectivity and don't trust existing tunnel providers. In this case: First, why are you at you're current host or colo center? They're probably shit. Second, set up a box at a provider with good connectivity to run the tunnel yourself. This is basically what we already do when we want to use our public v4 space but the ISP doesn't want to let us talk BGP.
This is a hackers perspective and doesn't apply to the normal consumer.
Thats kind of my point. If you're the type of person to actually know what v6 is, you're the type of person we're all waiting on.
edit: And its not a "hackers" thing, its a "technical competency" thing.
edit: And its not a "hackers" thing, its a "technical competency" thing.
It's also a "business competency" thing. Which, sadly, does not overlap very much with "technical competency" in many organizations.
Hooray, another /8, that'll last us for a good month or so. Exponential growth people, reclaiming unused IP blocks isn't going to stop it.
And that's ignoring the possibilities that a) it's being used internally by its legitimate owners b) it's being used internally by other people. T-Mobile were seen to be (mis)using the /8 that belongs to the UK MOD for their internal networks, I wouldn't be surprised if they were doing that with this as well.
There aren't that many IPv4 addresses. There are no easy fixes. Just move to IPv6 already.
And that's ignoring the possibilities that a) it's being used internally by its legitimate owners b) it's being used internally by other people. T-Mobile were seen to be (mis)using the /8 that belongs to the UK MOD for their internal networks, I wouldn't be surprised if they were doing that with this as well.
There aren't that many IPv4 addresses. There are no easy fixes. Just move to IPv6 already.
Do you have an idea of how many IPv4 addresses that are unused or not really needed?
Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
There are approximately 52 unadvertised /8s. Before the addresses ran out, we were using about one /8 per month. So even if we'd reclaim all unadvertised ranges, that would still buy us maybe 4 years (probably less considering the explosive growth in Asia).
The design of IPv6 began in the mid-90s, and RFCs were released in 96-98. Now, 15 years later, we are mostly still using IPv4.
In conclusion I think saying that we would have enough time to implement entirely new protocol if we'd reclaim unused addresses is way too optimistic. Even getting IPv6 really deployed at large in 4 years would be challenging enough.
The design of IPv6 began in the mid-90s, and RFCs were released in 96-98. Now, 15 years later, we are mostly still using IPv4.
In conclusion I think saying that we would have enough time to implement entirely new protocol if we'd reclaim unused addresses is way too optimistic. Even getting IPv6 really deployed at large in 4 years would be challenging enough.
I have no clue about serious networking, so I have to ask: why would you have your public, routable addresses unadvertised?
What's the benefit of using them instead of a 10.0.0.0/8?
What's the benefit of using them instead of a 10.0.0.0/8?
Somebody explained up above, but one example is that it can be used to mitigate collisions. If you have a company merge with another, and both are using 10.0.0.0/8 you could spend a lot of time and money renumbering or you could use unadvertised IPs to connect the networks.
>Do you have an idea of how many IPv4 addresses that are unused or not really needed?
If by "really needed" you mean just in terms of having one address for each machine then sure there's a bunch not being used. Let's suppose half of them. Assuming a constant growth rate, that would last us for ten more years. But actually internet adoption is still accelerating. A safer assumption would be something like five.
But our routers would collapse under the strain of the enormous routing tables long before then. To be able to route efficiently subnets need to be logical regions in the network topology, not arbitrary collections of 2^n machines. CIDR, needed to mitigate against the shortage of IPv4 addresses (or more properly the shortage of subnets) has been slowing the internet down since 1993.
>Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
Given that we've been working on IPv6 for 15 years and it's not fully deployed yet, no we can't. Even if every single address was unallocated today, we'd use them up before then.
If by "really needed" you mean just in terms of having one address for each machine then sure there's a bunch not being used. Let's suppose half of them. Assuming a constant growth rate, that would last us for ten more years. But actually internet adoption is still accelerating. A safer assumption would be something like five.
But our routers would collapse under the strain of the enormous routing tables long before then. To be able to route efficiently subnets need to be logical regions in the network topology, not arbitrary collections of 2^n machines. CIDR, needed to mitigate against the shortage of IPv4 addresses (or more properly the shortage of subnets) has been slowing the internet down since 1993.
>Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
Given that we've been working on IPv6 for 15 years and it's not fully deployed yet, no we can't. Even if every single address was unallocated today, we'd use them up before then.
There's a lot of companies in the Class A club that don't necessarily need their whole allocations, but for reasons of legacy it might be difficult to displace them.
When Apple and MIT got their allocations it probably seemed pretty reasonable at the time. "How many organizations like that would be interested in the internet? A dozen? That sounds about right."
There was a time where anyone with a .net domain name would be able to apply for and probably get a /16 allocation with hardly any questions asked.
When Apple and MIT got their allocations it probably seemed pretty reasonable at the time. "How many organizations like that would be interested in the internet? A dozen? That sounds about right."
There was a time where anyone with a .net domain name would be able to apply for and probably get a /16 allocation with hardly any questions asked.
At MIT a 30 person living group gets 18.n.x.x
Posting from our own 18.n.0.0/16 Class B subnet right now. There's a few thousand available IPs for each person who lives here.
Which will be great for testing my Raspberry Pi distributed web server. But useless for anyone who doesn't know / care what an IP address is (70% of us?)
I would imagine that you'd have more of a problem finding enough ethernet ports than ip addresses.
[deleted]
As an 18.205.x.x alum, I can confirm this incredible fact.
18.209.0.1 is still my default test IP (it was our internal router interface at Fenway, but it also is a reasonable remote test IP). Heh.
No traces of this block in the public Internet doesn't mean it isn't being used. It may be in use in some internal network(s) instead of a private address range (yes, that happens).
Spot on. Some of the unused blocks owned by the MoD are actually provided to a few top secret things. It wouldn't surprise me if this is the case for this as well.
This. From a comment on the page:
"The 51.* addresses are in fact heavily used by DWP, but only internally. The best bit is this: for security reasons, there is a policy that in any communication, the leading octet of all such IP addresses must be redacted. Not like it's a matter of public record or anything. I did once toy with the idea of printing out the XKCD map of the IP4 address space, write "you are here" on it and pin it to the wall near DWP data networks teams, but I didn't think it would go down well."
"The 51.* addresses are in fact heavily used by DWP, but only internally. The best bit is this: for security reasons, there is a policy that in any communication, the leading octet of all such IP addresses must be redacted. Not like it's a matter of public record or anything. I did once toy with the idea of printing out the XKCD map of the IP4 address space, write "you are here" on it and pin it to the wall near DWP data networks teams, but I didn't think it would go down well."
Running NAT behind a routable IP address range AND using a totally different range for all servers, VPNs, and various sysadmin crap? I don't believe it.
There's no way they would be so diligent to use that IP range internally without even a tiny bit of evidence externally.
There's no way they would be so diligent to use that IP range internally without even a tiny bit of evidence externally.
This is the government, so it's practically guaranteed that there's at least two layers of firewalls between any internal networks and the internet. If any of those layers was installed by an average IT consultancy then they'll have used NAT (because that's what you always do, right?) and hidden 51./8 completely.
If you're using a /8 for LAN addresses you are doing the entire internet a disservice.
Who cares? IPv4 is a dead technology and this is like complaining that the UK has a bunch of fax machines in storage somewhere. 10 years ago, this would have been a waste. Now it doesn't even matter.
Even Comcast supports IPv6.
Even Comcast supports IPv6.
Comcast is only one ISP. AT&T hasn't yet deployed IPv6 for their residential customers. (I think there are ipv6rd routers available, but you have to know about them and configure your own router to use them, and since it's not an official service, it could be discontinued at any time).
Then there's software. Many web apps don't support IPv6 (db fields limited to ipv4 format, or code assuming ipv4 format). For instance, Internet Brands is too busy with important business, like frivolous lawsuits, to fully support IPv6 in vBulletin. [1]
Some webapps have 3rd party hacks (or even first party hacks) to "support" ipv6 without modifying a lot of ipv4-dependent code, typically by hashing the ipv6 address, taking 32 bits, and using that as the ipv4 address. It's both disgusting and funny.
There's a long way to go before IPv4 is dead.
[1] http://tracker.vbulletin.com/browse/VBIV-9397 (you need a vbulletin.com forum login, unfortunately, and maybe also a linked license; in summary, it's a 2-year-old bug for full support of IPv6, it has no comments from vbulletin devs and no assignee.)
Then there's software. Many web apps don't support IPv6 (db fields limited to ipv4 format, or code assuming ipv4 format). For instance, Internet Brands is too busy with important business, like frivolous lawsuits, to fully support IPv6 in vBulletin. [1]
Some webapps have 3rd party hacks (or even first party hacks) to "support" ipv6 without modifying a lot of ipv4-dependent code, typically by hashing the ipv6 address, taking 32 bits, and using that as the ipv4 address. It's both disgusting and funny.
There's a long way to go before IPv4 is dead.
[1] http://tracker.vbulletin.com/browse/VBIV-9397 (you need a vbulletin.com forum login, unfortunately, and maybe also a linked license; in summary, it's a 2-year-old bug for full support of IPv6, it has no comments from vbulletin devs and no assignee.)
Here's my "bold" (aka safe) prediction: IPv4 will still be the dominant network addressing system in use in 2025.
So how do you envision the transition taking place? Given that 6 and 4 talk past each other.
The transition has sort of already happened. Most software stacks support IPv6 now, and many server hosting companies are giving out IPv6 addresses like candy. (I think I have a /48 or something for jrock.us. That's 2 to the 48th IPv4 Internets! I have a lot of computers, but not that many.)
All that's left are the clients, and the way I see that transition happening is in the low-cost sector. Sort of like an AOL where you won't have IPv4, so you'll have to access everything through a proxy except IPv6 sites. Eventually businesses will want to cater to this demographic and the stragglers will flip the IPv6 switch. With nobody on IPv4, it won't be a premium value-add anymore, and that era will be a distant memory of the past like BBSes are now.
Right now the IPv4 situation is not bad enough to make widespread IPv6 support critical to one's economic viability yet. Being able to see the animated turtle on kame.net isn't quite enough of an incentive, but the incentives will slowly shift.
(I see the same transition away from fossil fuels. Right now, an investment in alternative energies is pure speculation: it may pay off someday, but we don't know when that day is. When we've run out, though, the payoff will be clear: you will get infinite money the second you figure out some way to give humanity energy. This will encourage more investment than some nebulous LEED certification will. Tax credits are nice, but not as nice as cash.)
All that's left are the clients, and the way I see that transition happening is in the low-cost sector. Sort of like an AOL where you won't have IPv4, so you'll have to access everything through a proxy except IPv6 sites. Eventually businesses will want to cater to this demographic and the stragglers will flip the IPv6 switch. With nobody on IPv4, it won't be a premium value-add anymore, and that era will be a distant memory of the past like BBSes are now.
Right now the IPv4 situation is not bad enough to make widespread IPv6 support critical to one's economic viability yet. Being able to see the animated turtle on kame.net isn't quite enough of an incentive, but the incentives will slowly shift.
(I see the same transition away from fossil fuels. Right now, an investment in alternative energies is pure speculation: it may pay off someday, but we don't know when that day is. When we've run out, though, the payoff will be clear: you will get infinite money the second you figure out some way to give humanity energy. This will encourage more investment than some nebulous LEED certification will. Tax credits are nice, but not as nice as cash.)
"The transition has sort of already happened," he says, over IPv4.
Seriously, unless you want to be posting to HN via IPv4 in 2050, there is clearly something major left undone. Don't call it a transition if you think that concept is undone, but it's not yet functionally possible to be on the Internet with no IPv4 stack or (possibly NATted) address, and I don't see that becoming the case anytime soon.
See http://cr.yp.to/djbdns/ipv6mess.html for a description of the problem that I mostly agree with. The depressing thing is that those complaints are no less valid a decade later.
Seriously, unless you want to be posting to HN via IPv4 in 2050, there is clearly something major left undone. Don't call it a transition if you think that concept is undone, but it's not yet functionally possible to be on the Internet with no IPv4 stack or (possibly NATted) address, and I don't see that becoming the case anytime soon.
See http://cr.yp.to/djbdns/ipv6mess.html for a description of the problem that I mostly agree with. The depressing thing is that those complaints are no less valid a decade later.
Only because HN is IPv4-only. I'm sitting in a remote office on my laptop this morning, and it has an IPv6 address. When I visit google.com, it's over IPv6.
It's happening.
It's happening.
Why is HN IPv4-only? And why should they bother to spend any effort fixing it? Given that, e.g., techcrunch.com and github.com and everything else linked from HN is IPv4-only, you can't usefully use Hacker News from an IPv6-only connection, so why should HN care?
You're expecting altruism or geekiness on the part of every single website ever -- it's fair to expect that from Google, but not from everyone. The transition may or may not be happen_ing_, but it will never finish.
You're expecting altruism or geekiness on the part of every single website ever -- it's fair to expect that from Google, but not from everyone. The transition may or may not be happen_ing_, but it will never finish.
No I'm not, I'm expecting anti-altruism from low-cost ISPs. (Name one consumer ISP that you think is altruistic.) Then, to capture that market, servers will start deploying IPv6.
Today, IPv6 is billed as a premium feature. Tomorrow, IPv4 will be the premium feature.
Today, IPv6 is billed as a premium feature. Tomorrow, IPv4 will be the premium feature.
Wait, you expect any low-cost ISPs to offer IPv6-only, and have any customers at all? And that IPv4-only sites will say "gee, better support those IPv6-only users" instead of saying "get a better ISP" (or more likely "We have no idea what's wrong, but it works from Comcast, complain to your ISP")?
I don't think you understand how the Internet works. Or business. There is no foreseeable point at which it makes sense to bill an "Internet" service that's IPv6-only. That's doable _after_ the transition, but expecting that to happen now is not a transition.
I don't think you understand how the Internet works. Or business. There is no foreseeable point at which it makes sense to bill an "Internet" service that's IPv6-only. That's doable _after_ the transition, but expecting that to happen now is not a transition.
I think for the same reason HN doesn't do DNSSEC or HSTS -- pg isn't a full-time sysadmin.
I feel like a lot of the issues raised in that article aren't as relevant anymore. The issue of IPv6 only clients communicating over IPv4 can be solved via tunneling in both directions. Reading over that article again, it really does seem like he's complaining about the transition not the protocol. The solution to what he's complaining about is being solved by a slow and gradual approach that's taken place for well over a decade. The details have been worked out as time has gone on.
The biggest issue will not be getting everybody onto IPv6. That will happen at some point, however distant. The bigger issue is that clients slow to transition to IPv6, for whatever reason, will experience IPv4 service degradation as more and more of the internet switches to an IPv6 only stack.
The biggest issue will not be getting everybody onto IPv6. That will happen at some point, however distant. The bigger issue is that clients slow to transition to IPv6, for whatever reason, will experience IPv4 service degradation as more and more of the internet switches to an IPv6 only stack.
Yes, he's complaining about the transition, not the protocol. One perfectly acceptable transition method, from a technical viewpoint (though probably not a political one), is the one that got us on IPv4 in the first place: a declaration that the Internet's core routers will stop routing the old protocol come January 1. Another transition method would be to write a protocol that doesn't need such tactics to get people to switch to.
If it's been "being solved" over the last ten years, neither you or I will see the end of IPv4 on the public Internet within our lifetimes. Or, if we do, it's because something bigger and better will come along, obsoleting every version of IP. The debate over whether to switch to IPv6 will sound as silly as a debate about Morse code in the 1960s.
The future will come up with their protocols. IPv6, or maybe something other than IPv6, needs to be a protocol we can start using now (and not just because it's cool, but because it's useful) and not feel like it's wasted if it becomes irrelevant in 2025.
If it's been "being solved" over the last ten years, neither you or I will see the end of IPv4 on the public Internet within our lifetimes. Or, if we do, it's because something bigger and better will come along, obsoleting every version of IP. The debate over whether to switch to IPv6 will sound as silly as a debate about Morse code in the 1960s.
The future will come up with their protocols. IPv6, or maybe something other than IPv6, needs to be a protocol we can start using now (and not just because it's cool, but because it's useful) and not feel like it's wasted if it becomes irrelevant in 2025.
That was the answer that my question was leading to. Thanks.
The transition plan is called Dual Stack Lite or NAT64.
How did you get a /48?
Its pretty standard, you either get a /64 or a /48, normally just ask your ISP.
I find this funny. The IANA holds 15 IPv4 /8 blocks, even mentions "Reserved for future use" when whoissing, and nobody cares.
Not really. All the blocks that are marked "reserved" are more like "unusable"; e.g. real equipment cannot use class E. People have been over this stuff with a fine-toothed comb. http://www.iana.org/assignments/ipv4-address-space/ipv4-addr...
I know, but I still think it's stupid. Nevermind though, it's an endless opinionated discussion.
Amateur radio also has an unused IPv4 /8 block as well. That $500 mil could go quite a ways towards building a few amsats.
Hey, some of us HAMS are still using AMPRNet ... not many, but some.
That being said, here is a list of people in charge of allocations: http://www.ampr.org/oldsite/amprnets.txt
That being said, here is a list of people in charge of allocations: http://www.ampr.org/oldsite/amprnets.txt
I'm currently enjoying its usage as well. Whoever said it was unused doesn't know what they're talking about.
Is it held by the ARRL?
How many mobile phones made per day that support some form of internet access and how many of those use IPV6?
Scary thought is it not!
The first real opertunity to move to IPV6 in any way would be mobile smartphones and there like and yet that is not happening. It realy is a case of the ISP's and mobile telco's that need to start initiating the IPV6 move and until they do nobody will be dragged into following.
Maybe if it was illegal to sell devices that don't at least support IPV6. But of a messy situation when you can buy devices made brand new that still dont offer IPV6 support, criminal realy.
Still when you look into the history of British railways and the better modern alternatives you can see how some legacy designs just carry on with there limitations of capacity oversight.
Another aspect is cunsumers have in many respects forgotten how to complain to a company and let there frustrations out on the internet in area's were the companys offering the services will completely fail to notice and allow you to complain and vent of without them even knowing or indeed having to care.
How many of you have asked there internet service provider if they support IPV6 or indeed what there plans are to offer it? Reason I ask is that I can bet it's lower than 1 in 100 or indeed 1 in 100,000. I can't even recall any one of my friends or anybody I know or have dealing with ever mentioning they had made such an enquiry. I know I have, please tell me I'm not alone at least.
Scary thought is it not!
The first real opertunity to move to IPV6 in any way would be mobile smartphones and there like and yet that is not happening. It realy is a case of the ISP's and mobile telco's that need to start initiating the IPV6 move and until they do nobody will be dragged into following.
Maybe if it was illegal to sell devices that don't at least support IPV6. But of a messy situation when you can buy devices made brand new that still dont offer IPV6 support, criminal realy.
Still when you look into the history of British railways and the better modern alternatives you can see how some legacy designs just carry on with there limitations of capacity oversight.
Another aspect is cunsumers have in many respects forgotten how to complain to a company and let there frustrations out on the internet in area's were the companys offering the services will completely fail to notice and allow you to complain and vent of without them even knowing or indeed having to care.
How many of you have asked there internet service provider if they support IPV6 or indeed what there plans are to offer it? Reason I ask is that I can bet it's lower than 1 in 100 or indeed 1 in 100,000. I can't even recall any one of my friends or anybody I know or have dealing with ever mentioning they had made such an enquiry. I know I have, please tell me I'm not alone at least.
Verizon and T-Mobile are running quite a bit of IPv6 but nobody noticed since it just works.
How much does it cost to "produce" an /8? Nothing. In the "magical" world of the internet, you don't even need to build a network to use the addresses on. Nor do you need to prove that you actually have any sort of "rights" (as the legal kind) over the addresses. Because there is no one who can grant you such rights. Hate to spoil the magick trick, but no one owns the internet. The whole scheme works on cooperation of network admins and acquiescence of everyone else.
And the top post claims it would be worth $1BB. Keep dreaming.
The truth is that the value is not in addresses, the value is in the network, and those who own the infrastructure, but of course there is no single infrastructure for the internet because it's a network of networks, owned by various parties.
The telephone company can charge you for a telephone number. It owns the network that you're going to use it on. If it didn't own the network, you would not pay for the number. You are paying to use the network. The number is just a formality.
This same is not true for the internet and IP numbers. The RIR's don't own any networks. There isn't even a clear line to the source of their authority to "allocate" address space. Does the US Government own the internet? Good luck with that argument. RIR's charge fees to "allocate" addresses, an administrative job, but we have no idea how the fees are spent. Maybe to pay the CEO's generous salary? How much work is it to keep track of some numbers? Maybe we should ask IANA. The whole scheme works based on cooperation and acquiescence.
No organisation ever paid $1BB for an /8. They got theirs for "free" (inconsequential maintenance fees notwithstanding).
And the top post claims it would be worth $1BB. Keep dreaming.
The truth is that the value is not in addresses, the value is in the network, and those who own the infrastructure, but of course there is no single infrastructure for the internet because it's a network of networks, owned by various parties.
The telephone company can charge you for a telephone number. It owns the network that you're going to use it on. If it didn't own the network, you would not pay for the number. You are paying to use the network. The number is just a formality.
This same is not true for the internet and IP numbers. The RIR's don't own any networks. There isn't even a clear line to the source of their authority to "allocate" address space. Does the US Government own the internet? Good luck with that argument. RIR's charge fees to "allocate" addresses, an administrative job, but we have no idea how the fees are spent. Maybe to pay the CEO's generous salary? How much work is it to keep track of some numbers? Maybe we should ask IANA. The whole scheme works based on cooperation and acquiescence.
No organisation ever paid $1BB for an /8. They got theirs for "free" (inconsequential maintenance fees notwithstanding).
51.0.0.0/8 the secret IP block otherwise known as Block 51.
The argument is that if our government disposed of this 'asset' now, they'd rake in almost £1bn.
IPv6 is still not mainstream, so this figure can reasonably increase over time with the increase in IPv4 scarcity.
Thus it stands to reason not to sell out just yet.
IPv6 is still not mainstream, so this figure can reasonably increase over time with the increase in IPv4 scarcity.
Thus it stands to reason not to sell out just yet.
Can IP blocks actually be sold?
Yes. Privately and normally as part of bankruptcy proceedings. The most famous recent example is probably Microsoft's purchase of Nortel's addresses, http://www.bbc.co.uk/news/technology-12859585
Not generally, say ARIN an RIPE: http://en.wikipedia.org/wiki/IPv4_address_exhaustion#Markets...
IP blocks are "licensed", not sold. These licenses can be transferred, but only under certain strict conditions.
The ARIN CEO stated [1]
«As you may be aware, ARIN is the Regional Internet Registry (RIR) responsible for Internet number resource management for Canada, United States, and parts of the Caribbean. In keeping with the policies developed by the community in this region, there are two possible ways to transfer IPv4 number resources to another party (via merger & acquisition transfer or via specified transfer), and these are detailed in section 8 of the Number Resource Policy Manual on the ARIN website at <https://www.arin.net/policy/nrpm.html>;
It is important to note that transfer of number resources via either method must be to another party that can demonstrate corresponding need. ARIN's registration services department can assist with this determination in advance or at the time of transfer. ARIN reiterates the importance of veracity in transfer requests and supporting documentation as fraudulent information can result in resource revocation.»
NRPM section 8 [2] says
«Number resources are nontransferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer.
…
It should be understood that number resources are not 'sold' under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, …»
Older blocks allocated directly from IANA have different conditions attached to them that may render the transfer of the these licenses simpler or harder.
[1] http://mailman.nanog.org/pipermail/nanog/2011-August/038888....
[2] https://www.arin.net/policy/nrpm.html#eight
IP blocks are "licensed", not sold. These licenses can be transferred, but only under certain strict conditions.
The ARIN CEO stated [1]
«As you may be aware, ARIN is the Regional Internet Registry (RIR) responsible for Internet number resource management for Canada, United States, and parts of the Caribbean. In keeping with the policies developed by the community in this region, there are two possible ways to transfer IPv4 number resources to another party (via merger & acquisition transfer or via specified transfer), and these are detailed in section 8 of the Number Resource Policy Manual on the ARIN website at <https://www.arin.net/policy/nrpm.html>;
It is important to note that transfer of number resources via either method must be to another party that can demonstrate corresponding need. ARIN's registration services department can assist with this determination in advance or at the time of transfer. ARIN reiterates the importance of veracity in transfer requests and supporting documentation as fraudulent information can result in resource revocation.»
NRPM section 8 [2] says
«Number resources are nontransferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer.
…
It should be understood that number resources are not 'sold' under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, …»
Older blocks allocated directly from IANA have different conditions attached to them that may render the transfer of the these licenses simpler or harder.
[1] http://mailman.nanog.org/pipermail/nanog/2011-August/038888....
[2] https://www.arin.net/policy/nrpm.html#eight
Eventually in the future, people will come to realize the over-exaggeration of running out of ipv4 addresses. The unused blocks will come out of woodwork from everywhere. Well, I hope my opinion is wrong.
There's still a finite number of IP addresses that is below all reasonable expectations for how many devices will be wanting an IP address. Reclaiming unused blocks just softens the shock by making the exhaustion less sudden and more gradual. We're still definitely going to run out.
There are a little over 4 billion IPv4 addresses. If they cost even 10c / month the vast majority of them would still be unused. However, because they where free well over half of them are simply wasted and we are "running out".
My ISP feels it is 'reasonable' to charge $10\month for one.
$10 x 4B x 12 months would solve the national debt in just a few years...
$10 x 4B x 12 months would solve the national debt in just a few years...
Assuming you mean the American national debt, not really. That's only $480 billion/year. That wouldn't even plug our current deficit, let alone start paying off the debt.
By future do you mean right now where NAT is being used by some providers already? I know Rogers in Canada has all mobile devices going through NAT unless you pay a nice "VPN" fee.
Also the assigned but unused IPv4 blocks don't do anything for other providers that actually need addresses.
Also the assigned but unused IPv4 blocks don't do anything for other providers that actually need addresses.
Rogers only blocks PPTP VPN connections. Also it's not a VPN "fee" exactly, it's an entirely different APN. If your device doesn't allow you to manually edit the APN, you have no hope of getting your Rogers device to create a PPTP VPN connection over 3G because you cant access the internet.vpn.com APN.
However, L2TP and IPSec VPN connections work just fine over 3G on Rogers, no fees or APN changes required. So I'm not positive that NAT is the issue if I can establish the other types of VPN connections although this is hardly my area of expertise.
However, L2TP and IPSec VPN connections work just fine over 3G on Rogers, no fees or APN changes required. So I'm not positive that NAT is the issue if I can establish the other types of VPN connections although this is hardly my area of expertise.
So a home network will be NAT'ed twice. How nice, we almost got things sort of working with one NAT, now the Internet breaks again.
Once no more unused addresses turn up, they can start economizing on the used ones too. For example my university gives a publicly routed IP address to EVERY computer, even though most are completely firewalled off.
IBM has an entire /8 that they use internally for addressing their computers, none of them are publicly routable or even publicly accessible.
Even if they were to start announcing them or selling them it would be a HUGE project for IBM internally to make sure that their computers aren't going out on the web for internal resources, and it becomes an huge issue of having to renumber.
Unfortunately there is no good way to support something like that. Some companies didn't need to use the private LAN addresses because they had their own /8 and changing it now would require too much effort and work.
Even if they were to start announcing them or selling them it would be a HUGE project for IBM internally to make sure that their computers aren't going out on the web for internal resources, and it becomes an huge issue of having to renumber.
Unfortunately there is no good way to support something like that. Some companies didn't need to use the private LAN addresses because they had their own /8 and changing it now would require too much effort and work.
I see that it would be a lot of work, but so will switching to IPv6 be. The question is: which will be worse? which will actually happen? I don't know.
I'm probably forgetting a lot of things but to me it would seem doable to switch to private LAN addresses using DHCP and NAT, as long as there are no hardcoded IPs lingering around (but only hostnames which can be updated in a central location).
I'm probably forgetting a lot of things but to me it would seem doable to switch to private LAN addresses using DHCP and NAT, as long as there are no hardcoded IPs lingering around (but only hostnames which can be updated in a central location).
The problem comes when two companies using 10.0.0.0/8 decide to merge. For example, IBM acquires multiple companies every year.
Very valid point - especialy given that many text-books and other Ip education material would tend to bias you to use 10.0.0.0/8 as that is what you do, remember many companies who used the old SCO IP range as there `network chap` learned IP from a popular book that used SCO IP's in there examples.
Thing is though, if a pretty compitent company like IBM who know how to do IT have not moved to IPV6 and use public IP ranges for there internal networks albiet router blocked. Well, it just don't bode well for other less technicaly compitent people to move now does it and the cycle of procrastination with IPV4 carry's on :(.
Thing is though, if a pretty compitent company like IBM who know how to do IT have not moved to IPV6 and use public IP ranges for there internal networks albiet router blocked. Well, it just don't bode well for other less technicaly compitent people to move now does it and the cycle of procrastination with IPV4 carry's on :(.
You could still keep the networks separate.
They wouldn't have to fix the whole thing.
They could carve out /16 blocks, one at a time and give them back, starting with the ones that are currently not in use.
And this is exactly how it is supposed to be! The solution is switching to IPv6, not more NAT and ever more complicated routing to support the fragmentation of networks.
I have my own /24 routed to my basement. Back in the early/mid 90's could get their own provider independent block.
If I knew now what I knew then, I would've gone for a class B block. lol.
If I knew now what I knew then, I would've gone for a class B block. lol.
This is why organizations should pay $1 per year for each IP address they own.
what if IP addresses were allocated / confirmed by a bitcoin-like network?
You mean completely unstable and essentially useless? No thanks.
Every router would then need several gigabytes of memory for routing tables.
you mean namecoin?
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alter...
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alter...
More evidence for the core problem: fiat allocation doesn't work. If there was a functioning, liquid, accessible market for advertisable IP prefixes, you wouldn't have to convince anyone that a /8 was worth $1bn; it just would be.