Slashdot Mirror
Sale of IPv4 Addresses Hindering IPv6 Adoption
hal9000(jr) writes "While IPv6 day was a successful marketing campaign, is anyone really moving to IPv6? On World Launch Day, Arbor Networks noted a peak of only .2% of IPv6 network traffic. It appears that IPv4 addresses are still valuable and are driving hosting acquisitions. Windows 8 will actually prefer IPv6 over IPv4. If you want IPv6, here's what to do about it."
For sale, one barely used 127.0.0.1 ip address. $5000. First come first serve!
Scan your network topology from anywhere in the world?
See also: stateful firewall. NAT is not a firewall.
Yes, I think worrying about someone scanning the 18,446,744,073,709,551,616 addresses in your /64 is a valid concern.
ip6tables is a doddle to use, and assuming you have a new enough kernel pretty much all you'll need will be a variation upon:
ip6tables -A FORWARD -i lo -j ACCEPT
ip6tables -A FORWARD -i $lan_if -o $upstream_if -j ACCEPT
ip6tables -A FORWRRD -i $upstream_if -o $lan_if -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -P FORWARD DROP
sysctl net.ipv6.conf.all.forwarding=1
(NB: you probably want more than that, but assuming your $lan_if and $upstream_if have appropriate IPv6 subnets on, and everything is routing correctly, then you get "the same behaviour you used to" when you had your IPv4 NAT... only now you have "real" end-to-end connectivity)
Each and every one of you reading this is a customer of service providers and equipment vendors. It's time to use your voice and demand an IPv6 migration strategy that you can plan on.
On my walk in to work, there is this beautiful historic stone fence with cobblestone walk way for about a 2 block stretch... and demanding an IPv6 migration strategy I can plan on from it would likely be a better use of my time...
The article does nail the obvious problem on the head... the fact that IPv6 offers no benefit anyone cares about (we've learned to work with nat and even come to love it) except a solution to a problem that hasn't actually hit yet. Thing is this is the easy part. We all _know_ why IPv6 isn't being adopted. The hard part is how do we change that.. and "call up your ISP" is a really silly answer.
1: No NAT, so an intruder can fire up a scan and find your network topology from anywhere in the world. Only way to deal with this is to tunnel to IPV4 then back again, which is a hack.
Maybe you should install FreeBSD then, it's pf has supported IPv6 NAT since 2010 (at least).
2: No support for packet level encryption. It is mentioned, but it is an option that vendors don't need to follow or bother with.
Which is how ipsec works now. In other words, you and your partner obtain compatible implementations and it works.
3: no address independence
See nat66 (or freebsd).
4: Unknown 0-day security holes. Just what we want... to relive the days of pings of death, land, teardrop, smurf, SYN flooding and other attacks.
Now it's true that there are probably buggy implementations, after all the implementations have only been around a decade or so and only 0.2% of the internet has used them. That's what, 10 people?
If I have been able to see further than others, it is because I bought a pair of binoculars.
I'm mostly wondering what to do about my iptables in linux.
The good news is that ipv6 has been available on linux for I donno a decade or so, and ipv6 tunnels have been available, etc. The ipv6 land rush is very much like people in 1997 talking about that "brand new" internet thing, and just like the great ipv4 rollout its a good thing there's a decade or so of sound traffic engineering experience out there already for ipv6.
1) I guess it depends a lot on your distro.
2) Some terms to google for beyond the obvious are "ip6tables".
3) nobody needs NAT on ipv6 which inherently provided stateful firewalling on ipv4. TCP is pretty easy, SYN packets only allowed in one interface...
4) Personally I find it easiest to make two firewall scripts a ipv4 and a ipv6. If for no other reason than totally screwing up ipv6 will not mess up your ipv4 access and vice versa making it simpler to recover from mistakes.
5) Good luck wrapping your head around the concept of "every host is a multihomed host" aka "link-local addresses". Please don't attempt to route LL out on the greater internet, mkay, they're for mdns / bonjour type stuff.
6) Good luck with dynamic addresses and revdns. If you never used BIND's ORIGIN lines well you best learn how, and quickly.
7) Please block all RH0 aka rt-type 0 packets they're the ipv6 evil bit
8) Go to Hurricane Electric (they rock in general, BTW) and become a sage ipv6 dude. I found this quite easy when they initially rolled this out several years ago, maybe its harder now. You need to do this "course" to learn the ropes and glossary before you can learn to firewall or you'll turn all sorcerers apprentice.
http://ipv6.he.net/certification/
9) Once you know ipv6 you could do worse than to start at
http://www.sixxs.net/wiki/IPv6_Firewalling
SIXXS is kind of like a major cell phone company, in that everyone's opinion of them seems exclusively driven by their local sixxs pop or their local cellphone tower quality. So you'll get meaningless comments all over the map about how they rock or suck based on the little neighborhood the commenter lives in. That said if you live in range of the Chicago pop, it rocks, although it had some exciting momentary outages a couple years ago. I use them on a dynamic endpoint and HE's tunnelbroker on a static endpoint and I'm very happy with both... your mileage may vary...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
When our name is on the back of your car, we're behind you all the way!
Vista and Windows 7 "prefer" IPv6 too... Heck even Windows XP with its crappy IPv6 stack turned on prefers IPv6.
If you read the whole cnet article what has changed is network awareness sending an IPv6 only HTTP request periodically to a Microsoft server using this to judge if IPv6 connectivity is actually available.
In other words the behavior of all windows 8 systems on the planet with regards to IPv6 usage is dictated by the availability by a single Microsoft URL. What could possibly go wrong with that? Is it not also wonderful MS having their system ping out to MS servers by default periodically without anyone knowing or providing a user choice to turn it off not involving registry hacks?
With regards to IPv6 usage I just checked the interface stats on my gateway with an HE tunnel configured. Very interesting...IPv6 Internet traffic is a full 25% of overall Internet usage over the last 145 day period. This predates the June 6th IPv6 go live day by several months.
IPv6 = 32GB
IPv4 = 129GB
ISPs are still dragging their feet lighting up IPv6.. I fear we will have to wait another two years before most large ISPs get their act together on full production deployment.
The most interesting thing seems to be the "long tail" effect reflected in my actual usage.
Given current environment where just a handful of megasites are responsible for the majority of all Internet traffic by volume huge changes in traffic patterns can tip the scales on IPv6 usage rapidly while the countless millions of other sites run by the rest take just as long to switch over as the IPv6 naysayers say it will.
so with a 1ms response time, it'll only take 584,942 years to scan the pathetically small /64 my ISP has given me. Go for it hackers.
-i X means 'if the packet is inbound on interface X'
-o Y means 'if the packet will be forwarded (outbound) on interface Y
$lan_if and $upstrea_if are variables to which you've assigned the proper names for the interfaces conected to the LAN side and the Internet side (respectively)
# accept anything originating at localhost (this machine/router)
ip6tables -A FORWARD -i lo -j ACCEPT
# Allow outbound connections to be initiated by machines on the inside net.
ip6tables -A FORWARD -i $lan_if -o $upstream_if -j ACCEPT
# allow packets associated with aformentioned connections to come back in.
ip6tables -A FORWRRD -i $upstream_if -o $lan_if -m state --state ESTABLISHED,RELATED -j ACCEPT
# Drop anything else.
ip6tables -P FORWARD DROP
# Turn on packet forwarding of IP6 packets between interfaces. (off by default)
sysctl net.ipv6.conf.all.forwarding=1
This effectively gives you the same protections as an IP4 NAT setup -- but with none of the disadvantages. -- Like the fact that each machine on the inside gets it's own (external) IP address. This means that if you want you can give machines on the inside the ability to be servers (acccept inbound conections to the machine and port) without the NAT thing of also having to assign each machine an inbound (non-standard) port number.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Perhaps somebody has an (expert) answer here to this question: Why was IPv4 even allowed or implemented in the first place? Did this have to do with computing and/or memory limitations back in the day (1974 to 1981) that nobody every thought could be overcome or even required? I know hindsight is 20/20.
I find it hard to understand how the researchers developing the IP protocol could think that 4.29 billion address would be sufficient given the scale of possible adoption in the future.
First things first: due to all of the reserved address ranges, particularly (what were once called) Class D and E addresses, there are fewer publicly routable internet addresses than ~4.29 billion. The number is ~3.70 billion addresses once you take the various reserved address ranges out.
With that out of the way, the world was a vastly different place back in the 1970's when IPv4 was first defined. The idea of everyone carrying a telephone with them everywhere was science fiction, and the notion that such devices would feature processing functionality that would be able to take advantage of being network-enabled probably wasn't even conceived. The personal computer revolution hadn't happened yet either. As you said, hindsight is 20/20. It's easier to see how we got to now from there than the other way around.
It's also worth keeping in mind that when IPv4 was standardized in 1981 ([RFC 791]), computers were not particularly powerful; a state of the art desktop machine of the era would have little RAM, an 8 bit processor, and would run at less than 5Mhz. A device with an 8 bit processor would require at least 4 LOAD instructions to load an address from memory into registers, plus whatever processing would be required against the address (particularly for routing). Newer 16 bit processors (such as the 8088 and 8086) could do the same sort of processing with only two MOV instructions, but using a 128 bit address like in IPv6 would have required 8 bit systems to do a lot of processing just to handle the addresses -- you'd have to run 16 LOAD instructions just to read every part of the address into registers. This would be very significant processing wise for the time; I'd venture to say you'd need a supercomputer just to act as an IPv6 router back in 1981 (even with the limited number of hosts actually on the network). Memory would be a consideration as well -- 16KB fills up pretty quickly, so squeezing every byte out that you can would have been advantageous.
I'm also not particularly sure that the designers of IPv4 had a public Internet in mind. It wasn't until the early 1990's that the Internet was generally opened to commercial use; prior to that it was limited to government and research use. I don't think in the mid 1970's when Robert E. Kahn and Vint Cerf started work on trying to unify the various networks then in operation, that they considered that people would have a dozen or more Internet enabled devices in their homes (at current count there are 24 IP enabled devices in my home, although I certainly don't claim to be typical). That is, the "purpose" of the protocol at the time wasn't to provide a pervasive network that covered the globe, and the idea of 2^32 hosts was probably completely inconceivable. IPv4 has since invention been shoehorned into uses and purposes that were never conceived at the time of its invention. Indeed, considering how many protocols were being invented, and how quickly new iterations were being introduced, it probably wasn't expected that the world would still be using IPv4 over thirty years after it had been first defined.
IPv4 is getting to be a creaky, old technology with all sort of band-aids applied to it over the years. It is time for replacement -- the research and development community has been saying so for fifteen years or more. Unfortunately, the momentum behind IPv4 is massive, and entrenched inte