As promised in my last post about the tinc IPv6 VPN router on Raspberry Pi I’ll provide cut-and-paste setup instructions to get the setup off the ground. I have used Ubuntu 14.04.l LTS to create this howto, but most other Debian-based distributions will work for this, and most other distributions also carry the tinc package.
Prepared requirements to complete this howto is: a) One installed virtual or physical server with dualstack IPv4 and IPv6 connectivity to the Internet without port filtering. (Must be added after installation is done). b) Static IPv6 addressing with atleast one static address (eth0) and two /64 networks routed to this address. c) An Raspberry Pi with an Raspbian installed. d) The Nordic Semiconductor (Bluetooth Smart) Raspbian 6LoWPAN-enabled 3.17.4+-release Linux kernel image package downloadable from their devzone site (direct download link: here)
Note: Please replace the IPv4 and IPv6 example networking with your own networks as needed in the following configuration examples. To get this working you need to know that the eth0 interface of the router has the IPv6 address 2001:0db8:85a3:a1a1::1/64 facing the Internet and the IPv6 network 2001:0db8:85a3:ef00::/56 routed to it. The virtual interface running the v6router has the /56 prefix routed to it locally and does the routing for it’s clients on the “inside” of this interface virtually.
On your server carry out the following steps to get tinc installed and ready for action:
aptitude install tinc echo "v6router" >> /etc/tinc/nets.boot mkdir -p /etc/tinc/v6router/hosts cd /etc/tinc/v6router cat <<EOT >> /etc/tinc/v6router/tinc.conf Name = v6router Mode = switch EOT cat <<EOT >> /etc/tinc/v6router/tinc-up #!/bin/sh # Enable tinc - add things ip link set $INTERFACE up ip -6 addr add 2001:0db8:85a3:ef00::1/64 dev \$INTERFACE ip -6 route add 2001:0db8:85a3:ef00::/56 dev \$INTERFACE # Static routing table - five client networks ip -6 route add 2001:0db8:85a3:ef11::/64 via 2001:0db8:85a3::11 ip -6 route add 2001:0db8:85a3:ef12::/64 via 2001:0db8:85a3::12 ip -6 route add 2001:0db8:85a3:ef13::/64 via 2001:0db8:85a3::13 ip -6 route add 2001:0db8:85a3:ef14::/64 via 2001:0db8:85a3::14 ip -6 route add 2001:0db8:85a3:ef15::/64 via 2001:0db8:85a3::15 EOT chmod +x /etc/tinc/v6router/tinc-up cat <<EOT >> /etc/tinc/v6router/tinc-down #!/bin/sh # Disable tinc - remove things # Static routing table - remove routes for clients ip -6 route del 2001:0db8:85a3:ef11::/64 via 2001:0db8:85a3::11 ip -6 route del 2001:0db8:85a3:ef12::/64 via 2001:0db8:85a3::12 ip -6 route del 2001:0db8:85a3:ef13::/64 via 2001:0db8:85a3::13 ip -6 route del 2001:0db8:85a3:ef14::/64 via 2001:0db8:85a3::14 ip -6 route del 2001:0db8:85a3:ef15::/64 via 2001:0db8:85a3::15 # Disable tinc - remove routes and interface ip -6 route del 2001:0db8:85a3:ef00::/56 dev \$INTERFACE ip -6 addr del 2001:0db8:85a3:ef00::1/64 dev \$INTERFACE ip -6 link set \$INTERFACE down EOT chmod +x /etc/tinc/v6router/tinc-down cat <<EOT >> /etc/tinc/v6router/hosts/v6router Address = 10.0.0.1 Subnet = 2001:0db8:85a3:ef00::1/128 EOT tincd -n v6router -K4096 echo "net.ipv6.conf.all.forwarding = 1" >> /etc/sysctl.conf
Now, we should repeat this process on the Raspberry Pi, slightly modified, as we should not set up as much networking here as on the central router. Here are the commands to copy-and-paste for your Pi after logging in as root (yes, we require Internet access for this):
apt-get install tinc mkdir -p /etc/tinc/v6router/hosts cd /etc/tinc/v6router cat <<EOT >> /etc/tinc/v6router/tinc.conf Name = node-one Mode = switch ConnectTo = v6router EOT cat <<EOT >> /etc/tinc/v6router/tinc-up #!/bin/sh ip link set \$INTERFACE up ip -6 addr add 2001:0db8:85a3::11/64 dev \$INTERFACE ip -6 route add default via 2001:0db8:85a3::1 dev v6router EOT chmod +x /etc/tinc/v6router/tinc-up cat <<EOT >> /etc/tinc/v6router/tinc-down #!/bin/sh ip -6 route del default via 2001:0db8:85a3::1 ip -6 addr del 2001:0db8:85a3::11/64 dev \$INTERFACE ip -6 link set \$INTERFACE down EOT chmod +x /etc/tinc/v6router/tinc-down cat <<EOT >> /etc/tinc/v6router/hosts/node-one Subnet = 2001:0db8:85a3::11/128 EOT tincd -n node-one -K2048
You now need to copy the file /etc/tinc/v6router/hosts/v6router from your central server to the node-one Raspberry Pi and place the contents of it in the exactly same file on the Pi. Then copy the contents of the file /etc/tinc/v6router/hosts/node-one from your Raspberry Pi to the same file on the central server.
If you would like your Raspberry Pi to automatically connect to the v6router on power-on you should add one more set of commands to it:
cat <<EOT >> /etc/tinc/nets.boot v6router EOT
You should now reboot your v6router server and make sure that it displays a virtual interface named v6router when done, it should look something like this:
v6router Link encap:Ethernet HWaddr c0:ff:ee:c0:ff:ee inet6 addr: fe80::50c0:35ff:eec0:ffee/64 Scope:Link inet6 addr: 2001:0db8:85a3::1/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0 MB) TX bytes:0 (0 MB)
Now reboot your Raspberry Pi and see if it’ll respond back to you with a ping on it’s IPv6 address. If you get a ping reply you are set for the last part that we’ll do in part four: – Getting the Raspberry Pi to connect devices on it’s local network with the routed IPv6 subnet.
Warning: The following paragraphs will be a bit technical, but that’s unfortunately the only way to differentiate between the users and administrators of such solutions. Hence, if you are not a sysadmin, or more than mildly interested in poking around with servers running Linux, configuring network interfaces and adding software to your servers.. get in touch with your local guru, as she or he will help you get things sorted quite nicely!
TL;DR: Quick and dirty copy-paste howto for both server/router and Raspberry Pi will follow in part three.
In part one we looked at setting the Raspberry Pi up with the needed connectivity to be able to download software from the Internet and explore it though SSH. Now, let’s get to the good stuff.
After getting the Pi onto the Internet, we can SSH into it and get tinc set up. You also need a dual stack connected server somewhere that talks to the Internet. I’m in luck as I happen to have native IPv6 connectivity all around, at work (ITsjefen AS), at my spare time NGO cyber anti crime organisation (Underworld), at home (Canal Digital/Telenor Norway) and of course the place that pioneered IPv6 connectivity in Norway – The Student Society of Trondheim (Studentersamfundet). For this project we’ll use a virtual server on a dedicated network at ITsjefen.
First you need to set up your server running Linux. I enjoy Ubuntu, so I’ll stick with Ubuntu 14.04.1 LTS 64bit for this one. After installing your server and getting it up and running IPv4 and IPv6 with dual stack connectivity you need to install and configure the tinc VPN software along with the needed configuration to act as a IPv6 router.
tinc Tinc (yes, I know they spell their project name with small letters, even if it’s in the beginning of a sentence) is installed from the standard Ubuntu package repositories using your choice of apt or aptitude. I usually prefer aptitude. Run ‘aptitude install tinc‘ as root to get tinc installed. The configuration files are in /etc/tinc – the directory will seem a bit empty and you will need to populate it yourself with the proper configuration files.
The structure of the /etc/tinc directory should be as follows: nets.boot – contains network that you would like to auto-connect/launch at boot-time: “v6router” v6router – create this directory to contain the configuration of your IPv6 router.
The /etc/tinc/v6router directory should have the following files in it: tinc.conf – the configuration file for this VPN. tinc-down – script file to run at shutdown. Remember to make this an executable after creation. tinc-up – script file to run at startup. Remember to make this an executable after creation. hosts – directory containing one file: v6router The /etc/tinc/v6router/tinc.conf file should look somewhat as follows:
Name = v6router Mode = switch
The v6router file in the hosts directory should contain an IPv4 address line and an IPv6 subnet definition (of one IP). It also should have your public key to authenticate against connecting clients. The layout of the file is as follows:
Address = 92.62.3X.XXX Subnet = 2a02:2c8:ffff::1/128
Now you need to generate the private and public keys for your router you need to run the command ‘tincd -n v6router -K4096‘. This will create a key pair with the names rsa_key.priv and the public key being automatically added to the v6router-file in the hosts directory. The files tinc-down and tinc-up are the script files that contain the commands needed to make your router act as a router and route a subnet to your Raspberry Pi and getting it connected to your router. You need to make these two executable scripts. The layout of the tinc-up script file is as follows:
tincd -n v6router -K4096
#!/bin/sh # Enable tinc - add routes ip link set $INTERFACE up ip -6 addr add 2a02:2c8:ffff::1/64 dev $INTERFACE ip -6 route add 2a02:2c8:ffff::/48 dev $INTERFACE # Static routing table – clients ip -6 route add 2a02:2c8:ffff:2::/64 via 2a02:2c8:ffff::2
As you can see, the file contains both a definition of your router itself and sets up a /48 to use for your clients (e.g. your Raspberry Pi). If you only have ONE Raspberry Pi, a whole /48 is a bit over the top, but since we’re creating a design that can be used by hundred or thousands of nodes here, we’ll spend a whole /48. A /48 is also the default delegation handed out to Business customers at most ISPs so having a /64 for your router with a /48 added for it’s nodes makes sense Business-wise. The file tinc-down does the above in reverse, tearing down the connectivity and routing when tinc is shut down. The contents of the file should be something like:
#!/bin/sh # Static routing table - remove routes for clients ip -6 route del 2a02:2c8:ffff:2::/64 via 2a02:2c8:ffff::2 # Disable tinc - remove routes and interface ip -6 route del 2a02:2c8:ffff::/48 dev $INTERFACE ip -6 addr del 2a02:2c8:ffff::1/64 dev $INTERFACE ip -6 link set $INTERFACE down
The idea behind the setup is so that you will know the node by it’s IPv6 address based upon it’s prefix and endpoint address. Hence, using this configuration your Raspberry Pi would be 2a02:2c8:ffff::2 and talk to your v6router server at 2a02:2c8:ffff::1. The v6router would then hand out the subnet 2a02:2c8:ffff:2::/64 to your Raspberry Pi, giving it a network to attach clients on it’s LAN on. An IPv6-enabled device on your LAN would then be able to talk to the Internet via the IPv6 VPN.
In the case of the project for Nordic these “clients” was the nRF51 kits with their Bluetooth connectivity. The nice part of this is that you are able to add and manage solutions based on static IPv6 nodes behind dynamic IPv4 network endpoints and the traversal of NAT have so far been no problem with the providers this have been tested with. Until we reach a stage with fully deployed IPv6 networking in both corporate and residential networks, this will in some way probably be the best way to achieve managed services based on this technology.
Future connected homes The scope of the Bluetooth IPv6 connectivity are not yet observed by the general public, but I myself see a connected not too distant future home with smart devices that actually will tell my shopping application on my phone that “YES, your wife have already taken the last milk out of the fridge, you need to buy two, not one litres”. There will probably also be initiatives from makers of such devices, such as Electrolux and Samsung (yes I know they are already playing with both their heat pumps and their washing machines over your local WLAN) who will provide on-site remote service by the use of connected appliances that talk to services at the manufacturers network. Such services could be perhaps a monthly check in that will give you a nice status page saying that yes, your Samsung fridge motor is still running and that ice crusher machine on the freezer-part of the two-door monster is actually in need of a check up – Would you like a repairman on site or a remote diagnostic ran? In part three I will provide the cut-and-paste setup howto for your own tinc IPv6 VPN mesh network and explore some of the things you need to think about before setting up any services that actually talk with the Internet on any such solutions. Until then I would very much recommend the Nordic Semiconductor IPv6 brewed coffee demo at CES2015. I hope lot’s of people have had good IPv6 brewed coffee! Hope to see that machine at Trondheim Developer Conference 2015 in October!
In December 2014 I had the opportunity to work with Nordic Semiconductor (Nordic) on a consultancy project aimed to equip their sales team with a demonstration kit that allowed Bluetooth Smart technology (Bluetooth low energy devices) to talk to services on the Internet using IPv6.
The problem Nordic faced is that one can not know what kind of network you will be presented with when doing a demonstration and most networks are set up with only IPv4 RFC1918 local network addressing with NAT and one public IPv4 address on the outside (WAN) before you reach the Internet. There is close to zero native IPv6 connectivity in most venues, hence, you need to do some level of tunnelling / VPN to get IPv6 onto your kit that talks IPv6. The do and do-not. Before I was invited to the project Nordic had already started out with the basic idea that a broad band router with dual stack IPv4/IPv6 connectivity could cater for this with a Raspberry Pi on it’s local WLAN or wired LAN. The Raspberry Pi would then allow the Bluetooth devices to connect to it through the bluetooth network interface using the 6LoWPAN technology that recently has emerged in kernel space (starting with the Linux kernel series 3.17).
However, we quickly became aware of the issues with such broadband routers: Their IPv6 capabilities exist on paper, but for the most, are rather often than not, badly implemented or even tacked onto the software part of the devices after initial design is done. Opening an web browser talking to your broadband router will mostly give you menus saying things like “Network => WAN, WLAN, LAN” and at the very end of the row of other tabs like “Security” and “Administration” you get this new one.. “IPv6”. Right.
Disappointed with the sorry state of technology at this stage I went back home and thought about how to do things properly. “Properly” in this context must be, I thought, some kind of device that always will try to connect to the Internet and present you with an IPv6 connection you can share with devices on your LAN, no matter what state the local network is in. I used Google. I used IRC, I talked to other skilled people on the phone and took a long walk.
Enter tinc Then I found this project called “tinc”. The tinc VPN website says this about the software: “Tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private network between hosts on the Internet. Tinc is Free Software and licensed under the GNU General Public License version 2 or later. Because the VPN appears to the IP level network code as a normal network device, there is no need to adapt any existing software. This allows VPN sites to share information with each other over the Internet without exposing any information to others.” Tinc uses private/public keys to authenticate all nodes in a VPN and can therefore cater for incoming clients without static endpoints (e.g. static IPv4/IPv6 connectivity) as long as the router has both a IPv4 and IPv6 address with static connectivity.
I decided to give tinc a run. I then remembered the request from Nordic that the Raspberry Pi was to be the device connecting things to the router and then to the Internet. I researched the Raspbian (Debian based operating system to run on Raspberry Pi devices) software repositories and happily discovered that tinc was already packaged for Debian and had made it’s way into the Raspbian repositories as well.
Basic connectivity – the Raspberry Pi, you and the Internet Connecting to the Raspberry Pi from your computer has always been the main problem for people trying to explore the device and it’s usage. To be able to talk to the device directly from your computer you could give it a LAN IPv4 address and talk to it directly by your computer LAN port. Most modern computers automatically cross their RJ45-ports so that devices can be connected directly. Thus, you can use your computer as a gateway for the Raspberry Pi and onto your WLAN and the Internet.
This is quite easily done using the howto at http://www.penguintutor.com/linux/raspberrypi-headless or similar pages. However, to be able to always have the option to connect by LAN to the Pi you would need to modify the howto a bit. Do as the howto says, but at the stage describing the interfaces file, modify so that you use the following entries:
auto lo iface lo inet loopback
auto eth0 iface eth0 inet dhcp iface eth0:1 inet static address 192.168.1.6 netmask 255.255.255.0 gateway 192.168.1.1
By all means, edit the above to reflect your your local network requirements. The idea here is that the eth0 (wired Ethernet) interface on the Pi will always try to get an DHCP IPv4 address from a DHCP-server on the network it is connected to, but you will by the same time also have a eth0:1 interface defined with a static IPv4 RFC1918-address that allows you to directly plug your Pi into your computer network port and after editing your own LAN configuration to match the above network for eth0:1 (use any other address than .0, .1, .6 and .255) you will be able to SSH into your Pi. If you do not have a switch that you can connect your Pi to, this is the way to do it. After this, your computer is connected to the Pi and you can access it in headless mode with SSH. If you also happen to run Linux and use a WLAN for your Internet access you can follow these steps to act as a NAT router for your Pi and give it Internet access:
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE iptables -A FORWARD -i eth0 -j ACCEPT echo 1 > /proc/sys/net/ipv4/ip_forward
With this setup in place you can now download software from the Internet to your Raspberry Pi, and make it a node in a tinc VPN network. In part two we will look at setting up the two critical pieces of software – the tinc VPN router (on a separate dual stack machine/server on the Internet) and the tinc VPN router software on the Raspberry Pi.
Who governs the Internet? If asked this question, different people will answer very differently, shaped by their previous experiences, background, objectives and history in general.
Recently I started on an six month eLearning online course by the Internet Society titled “Shaping the Internet – History and Futures”. As the NGL programme web-page says: “The course curriculum covers the essential topics required for effective interactions and relationships within the Internet ecosystem, as well as key concepts and emerging issues in Internet governance”.
I’m absolutely thrilled to be on this and have a clear goal of delivering my absolutely best with participating in discussions, classes, doing my assigned activities and being available to my fellow course participants!
..back to the question asked. A Google-search will return what I’d say is a slim selection of responses. A quick read-through of some of the hits give a hint to the complexity of the issue. Some of them gives you pointers to the UN, the ITU, the Internet Society (ISOC) and of course, the World Summit of the Information Society (WSIS) in 2003/2005. If you work in the private part of the ICT sector in a western country in Europe and you speak English as your primary or second language, you are probably going to find that the answers Google will return with, matches your views in many ways. But what if you work with the governmental ICT of an emerging economy in another part of the world, with a different language and a different set of rules in daily life? Will your answer be different?
With the NGL programme in my head and the Internet governance as an very interesting subject, I’m giving this a great deal of thought and will probably write more on this subject in the weeks ahead.
Now, where did I put my book of Roman warfare?
I was pleased this morning when I through IRC learned that Norway’s largest newspaper have enabled IPv6 at their domain, vg.no. Not that I read VG much, but the fact that there is a push forward with IPv6 in the media sector is great, since it’s only about 8-9 months until there are no more IPv4 addresses left.
Here at work we’re doing lot’s of fun stuff with IPv6, and are currently actively pushing forward with dualstack implementations for our customers.
But today, we end with a delicious traceroute to VG via IPv6:
traceroute to ipv6.vg.no (2a02:c0:1010::16) from 2a02:2c8:1:42::4, 30 hops max, 16 byte packets 1 r-vl400.pir1-4.ipv6.as44381.net (2a02:2c8:1:400::1) 0.271 ms 0.245 ms 0.232 ms 2 2a01:560:207::1 (2a01:560:207::1) 0.597 ms 0.485 ms 0.491 ms 3 xe-1-1-0-13.cr3.hmg9.no.v6.linpro.net (2001:7f8:12:1::3:9029) 8.733 ms 8.914 ms 8.61 ms 4 2a02:c0:1000:2::3 (2a02:c0:1000:2::3) 9.015 ms 9.207 ms 10.083 ms 5 2a02:c0:1010::16 (2a02:c0:1010::16) 8.637 ms 8.774 ms 8.709 ms
Since my employer (ITsjefen AS of Trondheim, Norway) have given me the opportunity to work with free software (we base most of our customer-fronting solutions on free software) I’m mostly spending my days deep within the realms of servers, command line options and back end systems (that is when I’m not on a one month holiday).
Yesterday, after getting a report from a co-worker that a customer using our free wireless network on a dual stack (IPv4/IPv6) Windows 7 could not read his e-mail I dug into a tiny, but yet, frustrating problem with our mail proxy software — perdition. While perdition it self does indeed support IPv6 it seemed to be a bit easier to enable IPv6 for the xinetd service for perdition (I really, really thought IPv6 was in place as a default these days). After setting the proper flags (you just add the line “flags = IPv6” to the service you wish to enable IPv6 for) I went about restarting xinetd, discovering that no IPv6 was functioning in xinetd. I promptly tried to add other services to xinetd with IPv6, thinking perdition must be the culprit, but no dice.
Thus, downloading a reading in the source for the Debian-package I soon discovered that the tiny config-option of “–with-inet6” was left out. A quick recompile on the compile-box and pinning of packages later, IPv6 was working flawlessly for the perdition services.
Does anyone know of other, possibly more easily ways of getting proper IPv6-support for services in xinetd? If so, do let me know! 🙂
In march 2001 I was introduced to IPv6. IPv6 will coexist with, and eventually replace IPv4 when the pool of available IPv4-addresses run out. Currently the estimates says that there will be no more IPv4-blocks available by 2012 for Europe and North America. This will probably all linger on, since there exist some methods to distribute addresses in private networks with NAT and I also believe the regional Internet registries (RIR) will do some kind of coordinated “official thing” when things get “bad enough” in the Internet-based services-sector.
Up until today the uptake of IPv6-based networks and services have been very slow. Here in Norway it’s really just UNINETT and the members of the national science network that have good access to native IPv6-based services and networks without the use of IPv6-via-IPv4 tunnels and such.
As some of you who read my weblog from time to time might know, I work for a small Norwegian Internet Services-provider, ITsjefen, who have six employees. We’ve tasked (thanks Dilbert) ourself with the task to deliver digitally good services in our own fibre- and ethernet-based network. As a part of this strategy we’re members of RIPE, and a local Internet registry (LIR) for ourself and our customers. Through the membership in RIPE I’ve had the pleasure of formalizing my knowledge of alot of subjects, and among them, IPv6. I’ve come to the conclusion that we need to speed up the uptake of IPv6 among the large Internet Service Providers here in Norway before it’s too late. – To get Telenor, Ventelo(BaneTele), NExtGenTel, Get, Canal Digital and others, including service providers in the mobile Internet sector (Telenor Mobile, Network Norway, NetCom and Tele2) to plan the implementation, roll-out and marketing of IPv6 is a very heavy process. This will take time. Thus the task of getting these large players aboard is a thing for the powers of the free market, and it’s here I enter the picture again, with my funny little plan. – Why not begin with the smaller and medium companies and through them create enough push so that the large companies will get aboard and see the purpose of rolling out services before it’s just-too-late? Well. As planned, I embarked on this with my special idea to get this done.
Five weeks ago, I was given a link to the picture submitted by American ISP Hurricane Electric (HE) with their cunning plan to solve the IPv6-disconnect in their peering with also American ISP Cogent Co. The technical guys at HE nailed it with baking a cake and bringing it to a NANOG-meeting (The North American Network Operators Group). The cake can be viewed here.
With this as backdrop and the blatant steal of the cake as an idea I thought that I could perhaps convince the upstream providers ITsjefen get the bandwidth from to implement IPv6 before 2012. To begin this I thoght it best to approach a company we share many values with and have a good partnership with, NTE Broadband. We called the local bakery in their city headquarters location in Steinkjer, Norway and asked them to bake us a kake to be delivered to the NTE NOC on Friday in time for their 1400 CET coffe-break (a tradition in Norway). This was two weeks ago, and the cake looked like this:
(click on the picture for a larger edition)
The days passed, and we wondered what NTE would do. Suddenly it was Friday again, and we got a delivery to our office at 1330 CET. The delivery was this:
So, what kind of conclusions can we bring to the first phase of my IPv6-by-cake uptake in the Internet Service Provider-sector of Norway? 1) It really helps to have your own IPv6-block available and ready for use when your upstreams are ready. Then you have reason to bug them for IPv6 already. 2) A cake helps even old engineers to get interested in new and shiny services in the form of one and zeroes. 3) It helps to have a good tone with your peers, the providers, partners and customers. New services should be fun and something you look forward to using.
The question now is, should we send someone else a cake, and to whom?
