Archive for the ‘IPcalypse’ Category

Stupid IPv6 Tricks

Monday, June 22nd, 2015

Today, I was given a VM with an IPv6 address, but it had no IPv6 default route:

$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2001:db8:80:fd::/64 * U 256 1 0 eth1
fe80::/64 * U 256 0 0 eth1
localhost/128 * U 0 48 1 lo
2001:db8:80:fd::67:8/128 * U 0 77 1 lo
fe80::a00:32ff:feb7:73cd/128 * U 0 53 1 lo
ff00::/8 * U 256 0 0 eth1

Sadness.

I was also not given the router I needed to set the default route to. But no fear, we can ping the router multicast address!

$ ping6 ff02::2 -I eth1 -c1
PING ff02::2(ff02::2) from fe80::a00:32ff:feb7:73cd eth1: 56 data bytes
64 bytes from fe80::a00:32ff:fe4f:9ebc: icmp_seq=1 ttl=64 time=0.411 ms
--- ff02::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.411/0.411/0.411/0.000 ms

And all is solved!

# route -A inet6 add default gw fe80::a00:43ff:fe4f:9ebc dev eth1
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2001:db8:80:fd::/64 * U 256 1 0 eth1
fe80::/64 * U 256 0 0 eth1
*/0 fe80::a00:32ff:fe4f:9ebc UG 1 0 0 eth1
localhost/128 * U 0 48 1 lo
2001:db8:80:fd::67:8/128 * U 0 77 1 lo
fe80::a00:32ff:feb7:73cd/128 * U 0 53 1 lo
ff00::/8 * U 256 0 0 eth1
$ ping6 facebook.com -c1
PING facebook.com(edge-star6-shv-12-frc3.facebook.com) 56 data bytes
64 bytes from edge-star6-shv-12-frc3.facebook.com: icmp_seq=1 ttl=48 time=163 ms
--- facebook.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 163.953/163.953/163.953/0.000 ms

And there was much rejoicing!

Tags:
Posted in IPcalypse, IPv6, Linux | No Comments »

Writing an IPv6 Address – The 6 Commandments of RFC5952

Monday, February 13th, 2012

When we write down IPv4 addresses, no one really has to go over just how you write them. Most people get it after only a little while of seeing it done. 4 sets of numbers, from 0 to 255, each separated by a “.”.
When IPv6 started to be developed, it quickly became apparent that there needed to be an easier way to write it out than (for example)
2001:0db8:0000:0000:0000:0000:0000:0001.
Even if you quickly realize that you could drop the leading zeros (as we naturally do in “dotted decimal”), it’s still fairly unwieldy:
2001:db8:0:0:0:0:0:1
even if it is much better.
So the idea of the double colon was introduced to combine sets of zero’s together. The first RFC’s said that 1 or more groups of 16 bits of zeros could be combined to “::”
2001:db8::1
That’s almost usable! Of course it won’t always go that easily, especially if you start using SLAAC to configure your network:
2001:db8::93e6:baff:febd:6533
Darn. But still better than nothing.
Unfortunately, even with these rules, there wasn’t enough of them for the machines who are the ultimate users of these. By the rules that are defined in earlier RFC’s, all of these are valid:
2001:db8::1
2001:0db8::1
2001:0db8:0::1
2001:0db8:0::0:0001
(etc)
and case wasn’t ever discussed either:
2001:dB8:0::DeAd:BEEF
is perfectly legit.
This makes it harder to write code for things that need to decode these addresses. And RFC 5952 was written to try and address these shortcomings.

Here are the 6 commandments of RFC 5952:
1) Thou shalt not SHOUT your IPv6 address.

    IPv6 must be written in lowercase. 2001:db8::1 not 2001:DB8::1

2) Thou shall destroy leading zeros.

    Always truncate leading zeros. 2001:0db8::1 is not acceptable, you must use 2001:db8::1

3) Thou shalt not use the double colon where there is only one 16 bit set of zeros.

    If you only have one set of 4 zeros, you can no longer use the double colon, instead it just gets shortened to one zero. An address such as 2001:db8:0000:4:5:6:7:8 can’t use the double colon and only gets shortened to 2001:db8:0:4:5:6:7:8

4) Thou shall use the double colon to it’s greatest potential.

    If you have multiple sets of more than 8 zeros, you have to use the set with the most zeros. So if you have 2001:db8:0000:0000:1:0000:0000:0000 you have to use the double colon on the right set of 0’s – 2001:db8:0:0:1::

5) Wheresoever thou has two places to use the double colon, thou shall use the leftmost.

    If there are 2 equal sets of zeros, use the double colon on the one on the left, and single zeros on the right. 2001:db8:0000:0000:1:0000:0000:1 would become 2001:db8::1:0:0:1

6) Thou shall use the square brackets to separate IPv6 address from thy port number.

    When writing an IPv6 address with a port number, use square brackets around the IPv6 address to keep confusion at bay, since ports are appended with a : (the same separator as IPv6 sections): [2001:db8::1]:80 With the square brackets, we know it’s IPv6 address 2001:db8::1 on port 80, not IPv6 address 2001:db8::1:80

Tags: ,
Posted in IPcalypse, IPv6 | 3 Comments »

IPv6 Firewalling with ip6tables

Wednesday, March 30th, 2011

Now that you’ve gotten IPv6 configured on your home network, forget about relying on NAT to be your “firewall”. All your devices now have a globally routed IP (v6) address, so it’s time to get familiar with a setting up a “real” firewall.

Since my IPv6 router is a linux box that is also other things (server, wireless access point, etc) I can’t set up a nice dedicated firewall like pfsense (currently IPv6 is enabled on the beta versions) without spending more money and quite a bit more work. So I’ll work with what I have – ip6tables

Here’s a simple set of ip6tables rules I’ve come up with. You’ll want to tweak these for your specific site. Mine are called from /etc/rc.local

# IPv6 firewall (ipv6tables)
WAN_IF=he-ipv6
LAN_IF=eth0
WLAN_IF=wlan0
#flush tables
ip6tables -F

#Define Policy
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

# Input to the router
# Allow all loopback traffic
ip6tables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

#Allow unrestricted access on internal network
ip6tables -A INPUT -i $LAN_IF -j ACCEPT
ip6tables -A INPUT -i $WLAN_IF -j ACCEPT

#Allow unrestricted outgoing connections
ip6tables -A INPUT -i $WAN_IF -m state --state RELATED,ESTABLISHED -j ACCEPT

# Forwarding through from the internal network
# For now allow unrestricted access out from the internal network
ip6tables -A FORWARD -i $LAN_IF -j ACCEPT
ip6tables -A FORWARD -i $WLAN_IF -j ACCEPT

#Allow unrestricted outgoing connections
ip6tables -A FORWARD -i $WAN_IF -m state --state RELATED,ESTABLISHED -j ACCEPT

# allow SSH in
ip6tables -A FORWARD -s 2000::/3 -i $WAN_IF -p tcp -m tcp --dport 22 -j ACCEPT

# allow remote desktop in
ip6tables -A FORWARD -s 2000::/3 -i $WAN_IF -p tcp -m tcp --dport 3389 -j ACCEPT

# Drop everything else
ip6tables -A FORWARD -i $WAN_IF -j DROP

#allow everything to our router/server.
ip6tables -A INPUT -s 0/0 -d 2001:470:81e5::1/128 -j ACCEPT

# Drop everything else
ip6tables -A INPUT -i $WAN_IF -j DROP

In a few places, I only allow packets from 2000::/3. Currently this encompasses all of the global IPv6 addresses, so I could have easily used 0/0 (equivalent to ::/0 or “anywhere”) but I’m okay with being a little more specific here. In fact, for some of them (like ssh and remote desktop) I should be even more specific, but this is a start.

Ensure you can test your rules before leaving them on. I had some rules ordered incorrectly (I tried adding some rules after the “Drop everything else” rule for the chain) and broke www to ipcalypse.ca for a while. (oops!). To verify www, dns and smtp on my server, I used http://go6.se/check/ to test these rules.

Posted in IPcalypse, IPv6, Ubuntu | 2 Comments »

When will we run out of IPv4 addresses?

Sunday, November 14th, 2010

I’ve been kind of working on a post about IPv4 exhaustion. It’s been hard though, because I’m not much of a statistics nut. Fortunately, there exists a Veng Diagram where someone falls into an IP nut *and* a statistics nut.

Geoff Huston has provided us with some good info on IPv4 exhaustion with this guide. He also gives us a “when” prediction here.

The number that most people are currently throwing out is the date that IANA will run out of numbers. But there are at least 2 levels below them. RIRs (Regional Internet Registries) and LIRs/ISPs (Local Internet Registries/Internet Service Providers. An LIR is usually some type of ISP). So there will be some time after IANA runs out before RIRs run out, then some time after that before ISPs run out.

However, if you think that means that you can take your time before implementing IPv6, you’re quite wrong. We’re not looking at much more than 3 or 4 years before ISPs run out (and that’s quite optimistic.) If you deal in anyway with the Asia Pacific area, it’s likely MUCH less. That’s not a lot of time to get a whole new infrastructure tested, tuned, hardened, implemented and supported. If you deal with home users, you’re going to have to do a whole lot more work. There aren’t a lot of end users that are even prepared to deal with IPv6 yet. You’ll have to figure out how to support devices that don’t work on IPv6 (CGN is one way, and it’s not pretty). If you aren’t mired in the details by now, you’re behind, and it’s just going to start costing more and more to get your network up to snuff the longer you delay. There are a few ISPs starting trials to their end customers. These guys will have the clear advantage in support and knowledge base when the time comes that IPv6 is needed.

Will you?

Posted in IPcalypse, IPv6 | 3 Comments »