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.
Until some new technology that everyone wants comes along and requires IPv6, no one will care about it.
The killer app for IPv6 is maintaining a global network of PEERS. It's what you or others don't have to worry about loosing which makes a transition more appealing than accepting status quo for eternity.
Content extracts value by reaching everyone directly without having to worry about degregation through additional hops/congested CGNs.
Service providers extract value by not having to operate expensive CGN.
Governments and LEA extract value by not having to deal with multiple devices cloaked behind a CGN.
Even partial deployment provides some value to all stakeholders.
It makes no sense for businesses to pay thousands on larbor to reconfigure their entire network for IPv6, and see no beneficial gain.
Nobody is suggesting they do. All they need to do is make their *external* presence accessible via IPv6. They can keep IPv4 internally forever for all anyone cares.
Not to mention a lot of legacy hardware still don't support IPv6, like network printers/copiers, camera systems, security systems, etc.
IPv4 is not going away anytime soon. IPv6 is being added. Noone is taking away your toys. You don't have to go out and buy new stuff.
Even if the global IPv4 network went away IPv4 private networks would still be avaliable. You could still tunnel your IPv4 network over IPv6 with anyone you chose to have access to it.
It also complicates maters worse when you try to network across long distances
Having more globally unique addresses complicates matters? I won't pretend I understand how this complicates matters more than attempting to communicate with two peers both stuck behind CGNs.
-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.
NAT acted as a pseudo-firewall because you had to explicitly forward to your box .. rather than the IPv6 approach of having to explicitly block.
This only works if the attacker cannot send packets to the internal addresses, which is a dangerous assumption. I have seen several firewalls where only NAT was keeping them from being fully open. Standard security scans won't show anything wrong, but any attacker who can get onto the outside network has complete access to the inside. Suddenly your outside modem and/or router become your security perimeter, and they often fail miserably at that task.
Finally! A year of moderation! Ready for 2019?
When our name is on the back of your car, we're behind you all the way!
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