Slashdot Mirror
Dispelling the IPv4 Address Shortage Myth
Zocalo writes "While looking up some WHOIS information at RIPE just now I noticed a couple of articles about the IPv4 address space allocation status. IPv4 Address Space: October 2003 is a short summary by RIPE themselves, and IPv4 - How long have we got? is from July 2003, but has lots more detail and pretty graphs!
In short, the "Death of the Internet" due to lack of IP space is a myth, which doesn't bode well for getting IPv6 rolled out any time soon."
Class E addresses are still under the "Reserved for Future Use" mantra.
The US military is moving to solely IPv6 by the end of the decade. The rest of the US government will probably be not too far behind. IPv6 is happening right now, and will replace IPv4.
Using the MAC address is only one way to assign addresses, and MAC addresses can be changed. RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" gives another, based on frequently changing random addresses.
Even with static addresses, ISP logs would still be necessary to see who owns them. You might be able to find out some other way, like if you have logs of them logging into a web site with a username or email address - but this works for dynamic addresses too.
There is more to IPv6 than a larger address space. The address space issue is just what is commonly pushed, since it's something that's easily grasped even by non-techies.
The true benefits of IPv6 are things like; improved routing, multicasting scope, greater flexibility in what packets contain, flow labeling, privacy and authentication.
Especially flow labeling will be important if the net is going to be a source of media. Streams could get a higher priority, so low latency and glitch free audio and video can be possible. Makes me wonder if this couldn't be abused though.
How small a thought it takes to fill a whole life
NAT does nothing that any decent real router/gateway cannot do as well. You install a router at the entrance to your network. It hands out REAL IP adresses to your hosts, and you put rules in your router that say 'drop TCP/UDP packets that are heading for port 1024', excluding those hosts that you want to run web/email/SSH on, etc.
Whereas this isn't really related, I've just put up a resource for geolocation of IP's to country/city. It'd be cool if some slashdotters were to type in/select their city - only takes 10 seconds :-)
:-)
The url is hostip.info. The idea is to provide a free geolocation service that you can download the DB from. All the other ones I've found are either pay-for, limited in what you can do, or only to country-resolution. At the moment, this is just to country-resolution as well, but who knows how far it'll go
Simon.
Physicists get Hadrons!
Survey says........ WRONG... try reading the article. I know it's a lot to ask , and that this is /. but just try before posting.
I quote
it has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true.
"(I) have this unfortunate condition that causes me not to believe a single thing any politician says when a mic's on.
Not at all.
Just because you have an assigned network doesn't mean that that network (or all parts of that network) has to be connected. You could even NAT an assigned address behind a firewall if you wanted, and never put out any routing information. It would be just as secure as a non-assigned address, but very convenient in many situations.
For example, I'm setting up an ad hoc VPN right now between several companies collaborating on a project. Naturally, we are not giving access to each others LANs, but separate segments. Howver, we can't ignore the unassigned addresss used by the other partners. If he uses 192.168.100.0/24 for his LAN, I can't use it for my VLAN segment.
Another example is when companies merge. They could just plug their LANs in and know everythign would work.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
When the Bell system was broken up, the phone system's allocation scheme for area codes and prefix blocks was disrupted. Phone service providers were issued blocks of 10,000 phone numbers with a given prefix, from which they allocated local customers. There was no method for reclaiming unused portions of blocks from independent phone companies. So long as one number from a block remained in use, that prefix block could not be reallocated. THAT is why we suddenly needed new area codes--not because we had run out of unused phone numbers. At the time the new area codes were issued, the actual in service phone numbers comprised less than 50% of the available pool.
wouldn't you have to run some sort of firewall on each individual machine, rather than just the gateway/router?
No. The questions of whether computers on a LAN have their own IP addresses and whether they are firewalled by a dedicated box are independent. Even if each machine has an IP address by which it is publically addressable, you can still have a system which protects it by blocking known-dangerous ports.
The advantage of a situation like that, for instance, would be that you could have the firewall block file-sharing/RPC ports, while still allowing port 80 inbound so the individual machines can run webservers. With a NAT, only one local system could have a webserver, and you'd have to configure which one got it on the firewall.
You don't want your local network having a public IP address, even if you do have a firewall and the best IDP system available. Why create the risk?
That argument makes no sense.
1. The parent poster clearly DOES want to have more public IP addresses. So do I.
2. Do you block all outbound connections from your NAT'd machines? That's the only way you could be more secure than blocking all inbound connections using a firewall.
3. If you want to keep NATing, go for it. IPv6 ain't gonna stop you.
If you like to keep your MAC there, you can use that. It has a lot of advantages. But if you don't like it, you don't have to use it. It's a free world. You can number your machines in a Fibonacci sequence if you prefer.
Finally! A year of moderation! Ready for 2019?
Most of the $100 DSL/Cable appliances from Linksys, Belkin, 3com and similar vendors perform NAT out of the box. Plug it in and go. They DHCP to the ISP to get the public address and provide RFC1918 addresses internally via a built-in DHCP server. For small/ customers who don't have static address from their ISP, these devices also provide IP address stability internally. I can assign printers static addresses and know that I won't be subject to the whim of the dynamicly assigned number from the ISP. Most home users are probably unaware, at least at any level of detail, of the fact that they are being NAT'ed. I've even recommended these devices to people as cheap firewalls.
This is a boring sig
Not exactly. If you have a professional grade NAT device you can bind multiple real IPs to the router and then forward internally based on port and IP. So if you have x.x.x.1 and x.x.x.2 bound to your NAT, you can point x.x.x.1:80 to 192.168.0.1 and x.x.x.2:80 to 192.168.0.2. Just like with a firewall and real IPs.
actually it's in 2038 and we've already started the conversion, and it seems like it will last us for a bit, of course perhaps I'm being shortsighted...
from
64-bit UNIX time would be safe for the indefinite future, as this variable won't overflow until 2**63 or 9,223,372,036,854,775,808 (over nine quintillion) seconds after the beginning of the UNIX epoch - corresponding to GMT 15:30:08, Sunday, December 4, 292,277,026,596 C.E. This is a rather artificial and arbitrary date, considering that it is several times the average lifespan of a sun like our solar system's, the very same celestial body by which we measure time. The sun is estimated at present to be about four and a half billion years old, and it may last another five billion years before running out of hydrogen and turning into a white dwarf star.
I'll take all the addresses I can. Do you work at MIT?
From the article: The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space.
Europe has far fewer IP addresses than North American organizations, which have been assigned 74% of all current IPv4 addresses.
Both Stanford and MIT have more IP addresses than all of China.
I think HP has a lead on you. At last check they had both the 15 (HP) and 16 (DEC) Class A's and a few class B's. So thats a whole lot of the total address space right there. Better start buying up old tech companies :) Among others that I can recall IBM, MIT, and Berkley also had class A's.
This point was somewhat unclear in the article. He mentions how assignment has moved away from the class licenses, but as far as I know, HP anyway, still maintains control over all of the 15 and 16 addresses. I believe something like 1/4 of the total address space was allocated to companies and organizations (DARPA, etc) initially. Though this may have changed in the last year or two, if so please feel free to correct me.
could get a higher priority, so low latency and glitch free audio and video can be possible. Makes me wonder if this couldn't be abused though.
Until the Internet supports some sort of network service contract negotiation (with end users, yes, but more importantly between various ISPs), you can't really have classes of service. Without differential pricing, there's no reason for anyone to specify anything but the best service available for their traffic.
IP v6 is not a particularly good solution. The address fields are way too wide - and when you try to layer TCP on there, the per-packet overhead is just too big.
That, plus it doesn't seem to be backwards-compatible enough. I think a solution could be engineered whereby hosts that are really on the internet (not behind a firewall) switch to whatever new scheme is supposed to be in use, and regular client machines continue to operate behind NAT's, etc. You could unify the TCP port number and the IPv4 address into some IPv7 (or whatever) unique destination/service identifier.
Considering that there are almost no uses for IP without TCP (or UDP), not unifying those two protocols is just wasteful.
...is the biggest fallacy I have ever heard of, especially for people who make extensive use of them. You end up forwarding legions of ports for all the services that must be exposed to the internet, all from one ip address. This means hackers have ONE ip address that effectively has hundreds of services running on it, instead of many different computers with one or two services, which takes much longer to scan.
It is true that public ip addresses might expose all the *nix computers running sshd, and all the windows computers running smb, but that's what a firewall is for! And one has to have a firewall equivalent (i.e., a machine that all packets must route through) anyway if he's using NAT. Most NAT boxes are firewalls, too.
The only downside to public ip addresses is that it isn't strictly necessary to have a packet filtering solution to get up and running. But only a fool would set up a corporate network w/o some sort of protection.
In short, it is actually less work to configure a simple firewall which blocks everything to public ips than it is to configure a simple NAT solution which blocks everything to private ips. And once you start forwarding ports, it's actually the NAT that's less secure, because of the single point of entry. Let's not forget as well that people often "DMZ" one of their internal machines, exposing an entire machine to the outside, which again is far worse than a public, firewalled ip.
Again, public ips w/o a firewall is an even more insecure situation, but public ips aren't less secure per se. They're less secure in the hands of a fool.
-Dan
So does Windows XP, FreeBSD, OpenBSD, NetBSD, Linux... but that's hardly the point.
A more cogent point to be made: all of these operating systems that currently support IPv6 do not have the full suite of transition mechanisms that are required to keep the user from having to know whether they are using IPv4 or IPv6 for any given application.
There's a long list of important transition mechanism protocols that need to be deployed to smooth the transition to IPv6, e.g. 6to4, Teredo, NAPT, etc. And they just aren't there yet.
Another thing that has to be fixed before IPv6 will start showing up is dual-stack IPv6/IPv4 residential gateway boxes. There are specs for these things floating around, and that implies that there are people planning to build them and roll them out.
But right now, your average cable-modem system and DSL router are designed to give customers exactly one IPv4 address (and maybe not even a public realm one). Getting IPv6 deployed over the top of this infrastructure is an ongoing process. It's happening now, but it will take years. Maybe even the better part of this decade. Maybe more.
Most people reading this thread will eventually upgrade to IPv6... without knowing it. A few will upgrade only when they discover how much more they're spending on maintainance of their old IPv4 network compared to what they would have spent if they had upgraded to IPv6 earlier. The rest of you will be killing yourselves, trying to keep from upgrading to IPv6, because you all belong to some kind of sick religious cult.
--
jhw