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."
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)
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
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