Guest Blog

Are Service Providers Ready for IPv6?

President and CEO of Incognito, Stephane Bourque, is looking find out what strategies communication service providers are using to transition to IPv6 and needs your help to answer a few questions about your IPv6-readiness.  

Guest blog post by Stephane Bourque, President and CEO of Incognito Software Systems

Worldwide, the transition to IPv6 has begun — but just how ready are communication service providers for this change?

ARIN is expected to join regional Internet registries in Latin America, Europe, and Asia Pacific in exhausting public IPv4 addresses soon. Globally, this means that the number of remaining public IPv4 pools available to service providers to hand out to customers is running out, and most providers will need to consider strategies for IPv6 to enable future growth.

What are these strategies? That’s what we want to find out. For the second year, Incognito is running a global survey of communication service providers to find out IPv6 plans and strategies. The 5-10 minute survey is open to telecommunications, cable, mobile, satellite, and converged service providers of all sizes.  All participants will receive a copy of the final report compiled from survey results.

Last year’s report found that most service providers are slowly moving towards IPv6. At that stage, although more than three quarters of respondents had started preparing for IPv6, only 14% had deployed IPv6 on their networks and 4% had begun offering IPv6 addresses to end users.

Infographic 2014 Incognito Survey

The transition to IPv6 is essential for all businesses. At Incognito, we have embraced IPv6 on our internal networks and our website to prepare for an IPv6 future. When we made our website IPv6 ready in 2011, only a fraction of websites could be reached over IPv6, but we knew content was going to be a significant driver in the transition. So we enabled IPv6-support at the World IPv6 Launch Day in 2011. Our solutions already supported IPv6, so we knew we had to practice what we preach. It hasn’t been a quick process, but we look forward to being part of an IPv6 world.

Whether you are IPv6 ready or not, all communication service providers are invited to share your experiences and plans in the IPv6 Readiness in the Communication Service Provider Industry survey.

 

sbourqueStephane Bourque is the technological inspiration behind Incognito’s provisioning solutions. As CEO, Stephane has championed the development of high performance, multi-platform solutions that help service providers increase margins and reduce network upkeep.

Originally from Montreal, Canada, and educated at Concordia University, Stephane applied his computer engineering background at Banyan Systems to design enterprise network management systems for Fortune 1000 companies like Bell Canada.

 

 

 

IPv6 at the Dutch ccTLD registry SIDN

Where there’s a will, there’s a way. Senior Research Engineer at SIDN, Marco Davids, explains how Dutch ccTLD registry SIDN committed to IPv6 deployment.

Guest blog post by Marco Davids

.nl, the IPv6-enabled registry

SIDN is the registry for the Dutch country-code top-level domain. In terms of domain names per capita, we are one of the largest TLDs in the world. And even in absolute numbers, we are still among the five largest country-code TLDs. I guess that makes us kind of special. We may be a small country, but, as in so many countries, the Internet is immensely popular and has been for quite some time. In that regard, we are far from exceptional.

SIDN photoAt SIDN, we firmly believe in IPv6 as a long-term solution for the exponential growth of the Internet and the problems that arise from that. In fact, with IPv4 space running out, and prices on the secondary market rising, the need for a new addressing scheme on the internet is perhaps more acute than ever.

We are pleased to see that many organisations recognise the need for change and are acting accordingly. On the other hand, surprisingly, a considerable number of organisations haven’t even bothered to look into IPv6 at all. That is a concern. Large ISPs in the Netherlands (with a few exceptions) are moving, but they tend to take things slowly. This is one of the reasons why we are keen to promote awareness and adoption of IPv6. It goes without saying that we practise what we preach: IPv6 has been enabled on our own services for quite some time. More on that later.

The Dutch ‘comply-or-explain’ policy

The Dutch government is very much aware of the urgency of IPv6. In the Netherlands, the government maintains a so-called ‘comply-or-explain’ list, containing various Internet standards, including IPv6. Standards on the list should be used by government organisations and, for example, be part of the requirements in a procurement process. As I said, IPv6 has been on the list for quite some time, and an increasing number of government services are now reachable via IPv6. A broadly similar European list also exists, and naturally IPv6 is on that list as well.

Although we are not required to, because we are not a government agency, SIDN has decided to adhere to the comply-or-explain list. The authoritative name servers for the .nl domain have been fully IPv6-compliant for quite a number of years, but we felt we needed to go a few steps further and enable all of our services on IPv6. Naturally, we ran into a few issues. The vendor of our email appliances, for example, promised IPv6 support ‘soon’. But it turned out they needed ‘a little more time’. Quite frustrating, but also a lesson learned: be firm and serious with your vendor and make clear agreements beforehand about mutual expectations. There are still vendors out there, trying to make their customers believe that ‘no one really needs IPv6’ or claiming that IPv6 support ‘is in the next version of the firmware, scheduled for release any time soon’. My advice: show them the door.

Sometimes being pragmatic is the solution. We came to the conclusion that modifying the entire back-end infrastructure of our registry system for IPv6 was not feasible in the short term. As an interim solution, we are using load balancers to disclose our registry system via IPv6 on the Internet side, while it is still running on (RFC1918) IPv4 space internally. We also made our Whois service accessible via IPv6 in a similar fashion. So, where there’s a will, there’s often a way.

Internet.nl

The Dutch Internet Standards Platform is a private-public initiative by several organisations with the goal of promoting new standards, including IPv6. On a simple website, https://internet.nl/, anyone can easily check the quality of their connection, or a domain name for that matter, in relation to these new standards. The test is strict; some people say it’s too strict. But if you manage to achieve a 100% score, you can at least be sure that your setup is very future proof. So try it out.

Summarising, I would say that IPv6 is here and now. It’s a mature standard that is being deployed at a rapid pace. The amount of IPv6 traffic is increasing by 100% a year.  And in the interest of an ever expanding internet, everyone should join in.

 

Marco DavidsMarco Davids is a Senior Technical Policy Advisor and Senior Research Engineer at SIDN, the ccTLD for the Netherlands (.nl). He has been with SIDN since 2007 and a member of the SIDN Labs R&D-team. In this capacity he is involved in various projects, primarily with a focus on the DNS. Marco is also an active participant in the RIPE and IETF communities and has contributed to several RFCs and draft documents.

 

 

 

A Closer Look at The Internet of Things

Nick Rojas explores the Internet of Things and how some will appreciate the fundamental changes to the Internet that will allow it to come to fruition, while others will simply take it for granted.

Guest blog post by Nick Rojas

The so-called “Internet of Things” (IoT), is not just about the seemingly endless benefits of connecting everything to the internet, or as some say, making things “smart”. It’s also about infrastructure, intellectual property, education, and increasingly growing business interests. It’s how devices are tied to the cloud for commerce, research, and an endless array of applications.

While considering the benefits of having smart refrigerators and other fun gadgets, many forget the significant potential applications that the Internet of Things could change, such as water conservation due to “smart” sensors, reducing city traffic congestion, and a radical change in health care practices.

IoT

The Main Challenge: Infrastructure

Smartphones alone command a staggering share of smart devices in use today, with more than 143 million of them in use. When phones, refrigerators, bathroom scales, football stadiums, and even entire cities collectively need to connect to the Internet, we may find that we simply don’t have the infrastructure to support this yet. When IP protocols were first designed, futurists couldn’t have envisioned all the devices that would one day connect to the Internet. The concept of connecting virtually everything to the Internet goes well beyond the original framework.

Every device connected to the Internet must be given a unique identifier to function properly, so IP address exhaustion is certainly a thing that could hinder the ability to provide for the “Internet of Everything”. This is where we can enjoy a bit of good news.

IPv4 provided approximately 4.3 billion addresses, and has lasted for about 25 years. IPv6 has been available since 1999 and vastly expands the number of addresses to about 340 trillion, trillion, trillion addresses. Simply put, we’re good to go, for a very long time.

As progress is made, some of us will appreciate the fundamental change to the Internet while others will simply take it for granted.

“There will be so many IP addresses … so many devices, sensors, things that you are wearing, things that you are interacting with that you won’t even sense it. It will be part of your presence all the time.”  – Eric Schmidt, Google’s chairman and former CEO

With Increased Connectivity comes Improved Analysis

In addition to infrastructure and the increasing number of devices, the Internet of Things will prompt the continued development of analytics. Advanced statistics and predictive algorithms will play an ever larger role in decision making.   As an example, smart devices can be used by medical researchers to track the relationship between medicines consumed and heart rate.

As the volume of people using such devices increases, and the amount of data reaches statistical significance, analyzing the data can help researchers glean valuable information about the impact of certain foods on heart rate.

According to M.V. Greene, “”The “Internet of Things,” where objects in the physical world are connected to electronic virtual networks, is poised to turn retail on its head. Not since the introduction of online shopping – and before that credit and debit cards for purchasing – has something in retail had the potential to be so transformative.”

As the applications of these smart devices are dreamed of and manufactured, the opportunities for scientists and researchers are endless. Dreaming up ways of connecting human activities with data can lead to major advances in how we lead our lives. With the recent launch of Apple’s Smart Watch, which signifies the first massive step into mass adoption of wearable technology, the potential of the Internet of Things has just begun.

 

Nick RojasNick Rojas is a business consultant and writer who lives in Los Angeles. He has consulted small and medium-sized enterprises for over twenty years. He has contributed articles to Visual.ly, Entrepreneur, and TechCrunch. You can follow him on Twitter @NickARojas, or you can reach him at NickAndrewRojas@gmail.com.

 

 

 

 

 

 

Turning Bits into Bites

I can has IPv6? Mathew Newton knows how to make IPv6 fun – by involving cats of course. Here’s how he connected a DIY device to the Internet of Things to solve a problem and make his feline friends extra happy on World IPv6 Day.

Guest blog post by Mathew Newton

If we are to believe the figures being banded around, the Internet looks set to be dominated by the number of devices connecting under the ‘Internet of Things’ banner at some point over the coming years. If there’s any domination of the Internet before then it is arguably by cats – cat photos, cat videos, pretty much cat anything. I actually think there’s room for both though in the form of Internet-enabled cat feeders

Back in 2009 I was looking for a solution to ensure our two cats didn’t go hungry if my wife and I had to work late or go out for the evening straight from work. I couldn’t help but feel that I already had half the solution by virtue of my home-grown security solution based around the use of IP cameras. We could see the cats via the Internet wherever we were, so why not feed them this way on an occasional basis also? Cutting a long story short (the full details of which can be found on my website with the obligatory cat video on YouTube) I built the first version (the ‘Mark 1’) of my cat feeder:

Cat Feeder

Aesthetics didn’t feature on the requirements list (well, not mine anyway – it turns out they did on my wife’s!) but function and reliability definitely did. It seemed to tick both of these boxes completely with little room for improvement.

That’s not to say my work was done however – I had to do something about the Cisco Catalyst switch (I know, pun intended; it was clearly meant to be!) which I’d used to interface the feeder to the network through some hacked-together RJ45 loopback adapters and piggybacking on the port status LED driver ICs. Not only was the switch noisy but also bulky and had to be tethered to a nearby network port. After rummaging through piles of kits that ‘may come in handy one day’ I found a Cisco-Linksys WRT54GL broadband router and used it to make the improved ‘Mark 2’ version:

Cat Feeder 2

Cat Feeder Schematic

Not only was the feeder now a self-contained device, but it was also wireless (well, apart from the main power) and, by reflashing the firmware, could also support IPv6! The immediate benefit of this was, of course, being able to assign an appropriate ‘vanity’ address involving ::f00d and ::feed and no doubt others! Once that novelty wore off, the other benefits became obvious – there was no messing about with port forwarding and dynamic DNS update scripts. It just worked. Out of the box. This could of course be a double-edged sword where network security relies solely on the stateful property of a NAT and so my first IoT lesson to learn was making sure that my firewall was configured to protect the feeder accordingly.

The second lesson was also security-themed, and I’ve only got myself to blame for this one. On World IPv6 Day in June 2011, I decided to open up the feeder for 24 hours for anyone to access. For those connecting over IPv4 they could only view the feeder-mounted webcams, but for those with IPv6 they could also take control of the feeder and feed the cats. You can probably imagine how it went – food pretty much everywhere and two very full cats! The real problem, however, was that some users had spotted that I was passing control parameters through the URL to a PHP script (e.g. /catfeedercontrol.php?action=feed&time=5) and so were trying to abuse this by manipulating the feed durations, fishing for other commands and goodness knows what else. I quickly added some sanity checking to the scripts to mitigate this (I didn’t do this previously because access was usually password controlled). A key point to note here is that this attack vector was not directly related to the use of IPv6 as such – the vulnerability was at the application layer after all – however the ease with which IPv6 allows devices to be reachable from the Internet highlights the importance of ensuring that security is properly considered at all layers of the stack.

Even with sanity checking I would have benefited from being able to rate limit access but didn’t have time to work out how to do this. Instead, I opted to filter the source address of repeat offenders using the firewall and this became my third security lesson. The IPv6 double-edge sword was back – the offender was either hopping between addresses (whether that be manually or using short-term privacy addresses) or an entire organisation was seemingly in on the act because the addresses were all over the place within a very large prefix! I assumed the former but given the futility of playing cat and mouse with the offender (pun not intended!) I gave up blocking individual addresses and filtered the entire prefix instead. In a ‘real world’ application this could of course have significant unintended consequences, and so it did make me realise that our approach to filter-by-address strategies in IPv4 might need further thought when it comes to IPv6.

All in all, the cat feeder has been a great success and has never let us down in the six years we’ve been using it (I should point out that we only use it on occasion and not as a substitute for in-person contact with our pets!). Indeed, the cats seem to love it although it has to be said they’d love anything that feeds them! I suspect though that they might be particularly keen on the IPv6 aspect as normally they are fed twice a day but on World IPv6 Day they were fed a total of 168 meals. So from their perspective, this answers the question as to how much better IPv6 is than IPv4… 84 times of course!

 

Mathew NewtonMathew has nearly 20 years of network-related experience with a particular focus on all aspects relating to the design and deployment of IP (v4 and v6) and DNS.

His interest in computing, electronics and ‘how things work’ arguably stems from a childhood of taking things apart. He is now at the level where hardly any screws are left over when putting them back together again.

 

 

 

 

Webpass Deploys IPv6 For ARIN 35 Event

The IPv4-IPv6 dual stack network at ARIN 35 last week went off without a hitch. Webpass VP of Technology, Blake Drager, explains what it took to get it up and running. 

Guest blog post by Blake Drager

ARIN partnered with Webpass, an industry leading Internet Service Provider (ISP), to provide the network for the ARIN 35 event held in San Francisco from April 12-15, 2015.

We met with ARIN to determine what type of connectivity was needed:

  • BGP
  • Webpass allocated IPv4 / IPv6
  • ARIN netblocks statically routed to Webpass WAN

Since ARIN has a specifically reserved IPv4 /20 and IPv6 /48 for ARIN and NANOG meeting events, statically routing ARIN’s netblocks within the Webpass network was the best solution.

webpass_microwave_link

Webpass’ network is 100% dual-stacked and running on a Brocade CER and MLXe platform so setting up the IP circuit was as simple as:

  1. Adding an IPv4 /30 and an IPv6 /64 for connectivity between networks
  2. Statically routing ARIN’s netblocks with the next-hop being the Webpass WAN IPs
  3. Redistributing the static routes into our OSPF and OSPFv3 tables

After setting up the IP circuit, ARIN’s netblocks were routing within the Webpass network, but we wanted to redistribute these blocks to our eBGP peers so we had to do the following:

  1. Create prefix lists for the ARIN blocks
  2. Add those prefix lists as an applicable route-map statement attached to eBGP neighbors
  3. Verify that the routes were being advertised to Webpass’ eBGP peers
  4. Contact eBGP NOCs, send them the ARIN LOA for  Webpass to advertise ARIN’s netblocks and request that they update their prefix lists accordingly. This took a few emails and a little coercion with some networks, but after a while, ARIN was able to verify their routes were visible in public BGP looking glasses and route servers.

Once all of the above steps had been successfully executed, and the microwave link was installed at the JW Marriott, ARIN was able to verify public connectivity for both IPv4 and IPv6. All things considered, the process was very simple. IPv6 setup required no additional configuration when compared to the IPv4 setup. This is contrary to popular narrative that IPv6 is overly complicated and makes IP provisioning more difficult. Nothing can be further from the truth. Once your network is 100% dual-stacked and your staff is appropriately trained, IPv6 provisioning gets easier.

In fact, if ARIN’s meeting requirements were for IPv6 only, the configuration would have been as simple as Webpass providing ARIN with a /56 or a /48 via DHCPv6 Prefix Delegation. DHCPv6 would automatically assign them a /48 with a next hop of their local “fe80″ IPv6 address. The Brocade router would see this delegation occur (via DHCPv6 relay) and automatically insert that route into the routing table as a “delegated static” entry. This is the common Webpass customer IPv6 connectivity configuration.

 

 

Blake Drager Blake joined Webpass in 2006 and serves as the Vice President of Technology, leading the Webpass software development and network teams.  Blake started his career at Webpass building systems used to deploy Webpass’ Internet and providing technical support to residential customers. Webpass needed a scalable network that could interface with customers and employees and Blake rose to the challenge of building it. Today, Blake continues to drive software development that enables Webpass to run efficient operations.

 

 

 

 

Tinkering with IPv6 on a Home Router

Working in the IT world, Chris Harvey was naturally curious about IPv6, so he decided to set up IPv6 on his home network when it was time to upgrade his router, and now he blogs about his experience.

Guest blog post by Chris Harvey

Some may say I’m crazy, and a few of them would be right, but I’ve long tracked the growth of IPv6 given that I worked at Comcast for a number of years and my manager was instrumental in the Comcast push into IPv6. As a result it’s been fairly well drummed into me that this is something we all have to tackle at some point, or else the results of inaction will tackle everyone to the ground.

I guess you could say that I’m lucky enough to have been in the IT world for all of my career, so I’m one of many IT savvy people that are not too phased by configuring networks and getting my seemingly ever growing body of electrical devices connected to a network. Having said that, what less IT literate folks realize (I’m thinking of my mother here) is that even for those of us “in” the industry, change is usually a learning process too. We just have a level of experience to lean on that helps us catch on a little quicker than someone who’s not exposed at all.

I can clearly remember a few (ok, maybe many) years ago being completely mystified by many aspects of IT that my more senior and experienced colleagues took for granted. My point of saying this is, don’t think “it must be easy for him, because he knows what he’s doing”. Well actually most of the time I don’t, I’m just trying things and seeing the results. I may be able to interpret the results faster than someone with no experience, but I don’t have a magic wand that instantly makes me understand the new technology any more than my mother leaning on years of cooking experience to realize that leaving that toast in for just a bit too long is going to burn it.

Being “in” the industry always makes me lean towards new projects like initiating IPv6 with both a little excitement and trepidation. For my wife it’s more a dread of “oh great, now I’m going to lose my husband to the computer for two days while he figures this out, and in that time nothing else will get done”. That being said, it was time to upgrade my router from Comcast. I’d received a few emails saying it needed upgrading, so I decided to make the change knowing that the next generation of DOCSIS 3 modems would finally give me access to IPv6 for all my computers, tablets, phones and other ancillary and ever-connected devices in the house.

Frankly, enabling IPv6 couldn’t have been easier. Of course I made it much more complex by trying to understand the changes and morph them to my own desires.  At the end of the day simply plugging in the new modem was enough of a change to enable IPv6 to the devices on my network that could already speak that language, which is about every single one of them.

Because it would be pretty boring if I just stopped there, let me give a little more detail around what I did do, what worked and what didn’t and where I’ve ended up.

Firstly, it’s worth knowing we have an almost entirely Apple-based house. There are some devices in my house that are not Apple products, such as Internet radios and wireless HVAC thermostats, but mostly it’s Apple products. OSX has been IPv6-enabled for a long time so I expected this to be relatively easy and in fact it was.

Comcast supplied the modem, and it was provisioned into the account by customer care when I picked it up. Once home, I plugged it into the power and the coax cable. It took a few minutes to get up and running, but all status lights came on correctly.

The xfinity modem by default has a home WIFI which you can either immediately use with the SSID passcode that’s provided, or using the admin interface, you can rename it. Whether you connect an ethernet cable directly to the modem or use the WIFI, it’s IPv6-enabled.

The administration screen is easy to access, although not all that obvious, but Google (or the search engine of your choice) solved that. Essentially from any of your devices that connect to the modem, either hard wired, or wirelessly through the SSID mentioned above, the admin screen can be found on 10.0.0.1 and the administrative credentials are easily found online. As you’d expect, you cannot administer this from the outside network unless you specifically enable it, so just because the admin user’s ID and password are easily discovered, doesn’t mean anyone can access your router.

Since I already have an Apple Airport that is my wireless router, I wanted to keep it. The modem by default comes configured as a router, so having another one inside the network means you end up with a “double NAT” scenario. I’ve yet to find anything specifically poor about this arrangement, but it’s certainly not ideal, and it does not allow for you to have an IPv6 address on your devices. So for that reason, I put the new modem into a “bridge mode”, which essentially makes it transparent to the network and passes traffic through to my Airport which means my devices automagically obtain IPv6 addresses.

To test whether you either have or are using an IPv6 address, the easiest method is to use your web browser. There are many sites to choose from, but I found these two particularly useful: http://test-ipv6.com and http://ipv6-test.com, with the latter doing a very nice job of telling you what your browser is doing. If you want to do something a little more hardcore, you can issue the following command on an OSX terminal.

ifconfig en1

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether c8:e0:cb:1c:48:69

inet6 fe80::cbb0:ebff:f3fc:4869%en1 prefixlen 64 scopeid 0x5

inet 192.168.0.30 netmask 0xffffff00 broadcast 192.168.0.255

inet6 2601:8:a80:edef9:cab0:ebff:fe3c:4869 prefixlen 64 autoconf

inet6 2601:8:a80:edef9:dd47:5cd1:eaa1:1a4a prefixlen 64 deprecated autoconf temporary

inet6 2601:8:a80:edef9:5ded:d7c2:27b8:de85 prefixlen 64 autoconf temporary

nd6 options=1<PERFORMNUD>

media: autoselect

status: active

But at the end of the day, you shouldn’t need to do this. The point of IPv6 is that it simply works, so you shouldn’t need to mess around trying to make it work. The new modem and the Airport negotiate how to handle the address allocation, and it all works smoothly.

I took a bunch of extra steps that I could document for you regarding setting up my guest network, allocating a different network segment for it and essentially delving pretty deep into getting things setup how I wanted.  But in the end, the only thing I really needed to do to ensure my Airport environment worked was to alter the modem to bridge mode. If I didn’t have my own router and wanted to use the built in SSID that comes on the modem, which by the way you can rename if you want to, then out of the box my IPv6-capable devices would all have started using IPv6. Where they don’t, they fall back to IPv4, which we all still mostly rely on. I note with interest that my Airport Utility still has a strong focus on IPv4. Although it supports IPv6 transparently, any IP setup option still mostly involves IPv4 addresses. I wonder if that will change over time?

 

Chris HarveyChris has over 20 years of experience in the computer industry, including software sales engineering, implementation, consulting and solutions architecture. Chris’ career diversity stems from many years as a successful independent consultant, sales engineer, internal and external solutions architect; all within a variety of well respected companies in senior positions providing leadership, mentoring, product or solution delivery.

 

 

 

 

IPv6-Brewed Coffee Over Bluetooth Smart

Glenn Ruben Bakke explains how Nordic Semiconductor is connecting to the Internet of Things using IPv6 over Bluetooth Smart in everything from keyboards to coffee makers.

Guest blog post by Glenn Ruben Bakke

IOT IPv6 Over Bluetooth Smart

Believe it or not, the day has come when your coffee machine could know what exactly what kind of coffee you like to drink depending on the cup you’re using, the time of day, and a multitude of other factors. Earlier this year, the Nordic Semiconductor team demonstrated a smart coffee machine at CES that brewed coffee over IPv6. But coffee machines aren’t the only place where innovation is possible. As a leader in Bluetooth Smart solutions you will find our chips in products all around your home from wireless keyboards and mouse, TV remote controls all the way through to wirelessly controlled toys. Basically, we are already in a wide range of diverse devices. So, for us, extending those devices connectivity through the internet was the next logical step.

We are a strong advocate and believer that the right long term approach for connecting everything to the Internet is by using open standards. In this way obstructive barriers to cross-platform, device and OS communications will be dissolved.

IPv6 Over Bluetooth Smart

Recently a lot of effort has been made by the Internet Engineering Task Force (IETF) to make the Internet suitable for smaller devices, something that is referred to as 6LoWPAN. Bluetooth Smart Specific adaptations and recommendations for 6LoWPAN are being defined as BLE 6LoWPAN and can be found here.

BLE 6LoWPAN enables compression of IPv6 traffic and optimizations in procedures (for example, neighbor discovery) on Bluetooth Smart. BLE 6LoWPAN defines Stateless Address Autoconfiguration (SLAAC) of IPv6 addresses using the Bluetooth Smart Device Addresses. The 6LoWPAN-enabled Bluetooth Smart device will derive a EUI-64 address based on its own EUI-48 MAC address and this is combined with the assigned prefix to form an IPv6 address.

Stack Diagram

BLE 6LoWPAN defines two roles for Bluetooth Smart devices: the 6LoWPAN node role and 6LoWPAN edge router role. In the 6LoWPAN node role Bluetooth Smart devices can connect to the internet over Bluetooth Smart using a border router. The border router role acts as a device that is connected to the internet and provides access for the nodes to the internet.

6lowpan Roles

IPv6-enabled Coffee Machine

We wanted to demonstrate the exciting possibilities that this technology enables and we wanted to show that by doing something practical. What better way than brewing coffee over IPv6? – not only demonstrating a connected appliance that can be controlled and monitored from the Internet, but also getting a nice cup of coffee at the end of it.

The coffee machine, being IP enabled, has its own IPv6 address which means it is directly addressable from the Internet. Also, native support IP protocols allow the coffee machine and the cloud application to use the same protocol without any need of proxy or translations. The application protocol used in this demo is MQTT, a TCP based protocol.

In this demo you can request a brew through the web interface. You can also see if the coffee machine is brewing or idle, the number of cups brewed etc. – all examples of monitoring a remote appliance.

We used the following hardware components to brew coffee over IPv6:

  1. Coffee machine – connected to the nRF51 Development Kit playing the role of BLE 6LowPAN node role and an MQTT client.
  2. Raspberry PI   – playing the role of BLE 6LoWPAN router providing connectivity to the internet to the coffee machine by routing packets between its Bluetooth and Ethernet network interfaces.
  3. PC symbolizing a cloud server. The PC provides the software infrastructure of the demo.

Coffe Machine Setup

The software pieces we used are:

  1. MQTT broker. MQTT protocol requires a central broker that manages messages between various clients that connect to it. Here, HiveMQ is used as the broker.
  2. Django web server providing an interface to control the coffee machine.
  3. Database is used to store information related to the coffee machine.
  4. A controller module that listens for messages from coffee machines. Any updates or request to the database are handled by this module.

Coffee Web Interface

Routing on Raspberry Pi

Once a 6LoWPAN node connects to the Raspberry PI, a Bluetooth network interface appears on the Raspberry Pi. Routing packets to this Bluetooth Network interface is like routing packets on any network interface. Linux provides a router advertisement daemon, radvd, which is used in this setup.

The radvd is setup to delegate an IPv6 prefix to all the endpoints connecting to the switch so that global IPv6 address can be created on the nodes using State-Less Address Auto-Configuration (SLAAC). The Ethernet interface (eth0) takes care of devices connecting to the simulated global network, and the Bluetooth interface (bt0) takes care of the IPv6/6LoWPAN over Bluetooth Smart devices connection. For Bluetooth, radvd will give each node on the link (bt0) a 2001:def:: prefix, and for Ethernet each node will get a 2003:abc:: prefix using 2003:abc::1 as gateway.

radvd.conf

6 radvd config

A route is also put up between the global network (eth0) and the Bluetooth/6LoWPAN network (bt0) that connects the 2001:def:: subnet to 2003:abc:: subnet. This makes the Bluetooth nodes available in the simulated global network.

Routing on Raspberry PI

With this setup each coffee machine can create a TCP connection to the MQTT broker using its global IPv6 address, publish messages and listen to responses or commands.

We were proud to demo our IPv6 coffee machine at CES earlier this year and see it as the first – and major – step of many devices into IoT over IPv6.

 

Glenn Ruben BakkeGlenn Ruben Bakke is a Software Engineer who has been developing software for Nordic Semiconductor’s nRF51 Series ICs as well as working on the development of the IoT SDK.

 

 

 

 

The Per Scholas Approach to Bringing IPv6 into the Classroom

Eduardo Hernandez of Per Scholas shows why IPv6 is an essential part of the curriculum for IT students as they prepare for jobs in the tech industry.

Guest blog post by Eduardo Hernandez

I am an instructor at Per Scholas, a national nonprofit organization that provides free technology education, career development and job placement services to unemployed and underemployed individuals throughout Columbus and Cincinnati, OH; Dallas, New York City, and Silver Spring, MD. We take pride in providing comprehensive technical training to individuals with no background in technology, and on average the school trains approximately 800 students a year and 75 percent successfully go on to land jobs in tech.   I take a lead role in making curriculum enhancements and adjustments based on the industry trends (I am also a graduate of the program myself!), and recently we decided to add IPv6 to the curriculum.

Per Scholas Teaching

Despite struggles in adaptation, IPv6 is clearly the future when it comes to finding a solution to the currently depleting addressing space.  It is with this thought that Per Scholas is beginning to roll out changes in our curriculum, which not only embrace IPv6, but successfully train students in becoming proponents and implementers of the addressing scheme.  This means that we are assisting nearly 600 freshly trained students with broad technical skills and new perspectives to enter the IT workforce this year with IPv6 networking skills that employers are looking for.

For those unfamiliar with networking, IPv6 can be overwhelming and exceedingly complex. As educators it is imperative that we approach IPv6 via active student participation. To implement this philosophy my students create an account on https://www.sixxs.net at the beginning of my first IPv6 lesson.  SixXs is a free IPv6 tunnel broker.  Once students create an account they may apply for their own tunnel.  Upon tunnel creation students are given their own IPv6 address to a public PoP, along with a range of routable subnets.  The idea behind this approach is that students will go home and do the same procedure on their home networks, thus increasing their knowledge base and preparing for the future of total IPv6 implementation.  Once a student has successfully created a 6-to-4 tunnel on their computer, various other lessons are assigned which further their understanding of IPv6.

Following this preliminary experience with IPv6, we are then ready to tackle the complicated task of IPv6 subnetting.  When it comes to subnetting most educators will agree that it is one of the most difficult concepts for students to understand.  With IPv4, subnetting was necessary, and although with IPv6 it is not required it is still very important for a network technician to know.  Subnetting IPv6 is rather daunting since students need to train their brains into working with hexadecimals.  As practice exercises students work with the subnets given to them from the tunnel broker and apply them in class.  This allows them to see the fruits of their labor.

IPv6 is here to stay! As more and more people get connected to the web, with every device having its own IP address, and the Internet of Things (IOT) becoming a reality, there will be more demand for technicians who can implement IPv6.  The Per Scholas approach is to give students the best tools to succeed in the ever-changing IT world, so that is why we have added IPv6 to our curriculum. It is important that IT educators give the tools necessary for success to their students.  I for one am glad to finally get rid of NAT and the complexities of setting up IPv4 networks.  IPv6 is the future; it is time to embrace it.

 

Eduardo HernandezEduardo Hernandez is an Associate Director of Technical Instruction at Per Scholas. He began his career there 2 years ago as a student.  He took part in an advanced IT training program called Project Scale.  Upon graduation Eduardo obtained valuable industry certifications: CompTia A+, Security +, and Cisco CCNA certification. Prior to his position at Per Scholas, Eduardo graduated with a Bachelor’s Degree in Computer Science from Pace University and worked as a Network and Security consultant. He also ran a successful after-school tutoring business.

Set Up IPv6 in Your Own Home

Jeremy Duncan, Managing Partner and IPv6 Architect at  Tachyon Dynamics, gives his opinion on some good applications and tunneling providers you can use to get IPv6 in your home if your ISP doesn’t offer it already.

Guest blog post by Jeremy Duncan, Tachyon Dynamics

IPv6 in home or residential networks is getting much better.  North America has seen exponential IPv6 use on the Internet year after year since World IPv6 Launch (6 June 2012).  Residential Internet service providers like Comcast and Time Warner are almost singularly responsible for this sharp and dramatic growth.  However, if you aren’t a Comcast or Time Warner user, it’s a totally different story.  I’m one of those users, and I want to pass on some of the great ways to setup your own IPv6 internet access using one of the great (and free) IPv6 over IPv4 tunnel providers.

Don’t Have IPv6 at Home?

So your ISP is one of any of the minor and major ISPs that have no IPv6 implementation currently.  What can one do?  Do it yourself!  I’ll show you a few applications and tunneling providers to use, as well as ones to never use.

Hurricane Electric

This is probably the best IPv6 in IPv4 tunneling provider out there today. Also, it’s free for small networks. The provisioning is very easy. The graphic below shows how to provision a tunnel and it gives you sample configurations for your gateway of choice. Basically, anything that can do a 6in4 tunnel (IPv4 protocol 41) can use this service. This includes any workstation or server operating system, router, firewall, or custom CPE (e.g. OpenWRT).

HE

Just go to http://tunnelbroker.net. Once there, you can create an account, and select “Create Regular Tunnel.” There it will ask you which PoP you’d like to use and what your public IPv4 source address is. Once you click “apply,” the full configuration screen will be presented and your tunnel is activated and ready to connect. If you aren’t sure how to do tunneling configured you can click “example configurations,” and it will give you the exact CLI configuration needed for your gateway of choice. For example, here is one for a Cisco IOS router:

configure terminal

interface Tunnel0

description Hurricane Electric IPv6 Tunnel Broker

no ip address

ipv6 enable

ipv6 address 2001:db:1:1::2/64

tunnel source 1.1.1.1

tunnel destination 2.2.2.2

tunnel mode ipv6ip

ipv6 route ::/0 Tunnel0

end

Once you have the tunnel up and running, go back into the provisioning page and click “request a routed /48 prefix.” With this prefix you can assign 65,536 /64 network on your home LAN. That will probably be enough for now. :)

Other Hurricane Electric Services:

SixXs

SixXs is more of a community supported tunneling service. They aren’t backed by a large corporate entity like Hurricane Electric, but still provide a few good tunneling services. They were one of the first 6in4 tunneling providers to the industry.

When you navigate to https://www.sixxs.net, sign up for an account. SixXs is very diligent about keeping tunnels up and healthy and are constantly checking on the health. When you have an account you get points for how long your tunnel remains up, and are subtracted points when your tunnel is down. You can cash these points in for /48 prefixes and other little goodies along the way. These incentives keep the overhead of maintaining dead tunnels to a minimum as it is community supported.

Their data rates don’t match Hurricane Electric. I see comparable IPv4 to IPv6 tests with Hurricane Electric, but much slower with SixXs. However, it remains a very good, free, and relevant IPv6 in IPv4 tunneling service. SixXs also provides:

  • Automatic IPv6 Client Utility (AICCU): This is a client-side software application that uses UDP port 5072 to tunnel IPv6 over IPv4 UDP. Certain networks may not allow UDP port 5072 outbound, so use this with care. Details are here: https://www.sixxs.net/tools/aiccu/
  • IPv6 website gateway: This URL-based proxy allows you to connect to IPv6 enabled website using an IPv6 domain name. For example, http://ipv6.google.com.ipv4.sixxs.org will get you to the IPv6 only Google website, but the SixXs gateways will proxy you using IPv4 to your web browser. Details are here: https://www.sixxs.net/tools/gateway/
  • IPv6 Unique Local Address (ULA) registration site: As per RFC 4193, ULA address must not be routable, but must still be globally unique. This site will use the algorithm to generate globally unique addresses, then will register them so organizations can use them later as bogon lists if needed. Details are here: https://www.sixxs.net/tools/grh/ula/

GoGo6

GoGo6 was a company that sprang from Hexago. Hexago was the company that created the appliance-based IPv6 tunnel broker. It was an all in one, and easy to deploy, full tunneling solution. The company is called GoGo6 now and it’s product is called GoGoServer. It offers a free service for users to connect using a client application similar to SixXs, but with more tunneling options: 6in4, UDP port 3653, and DS-Lite. More details on this service is here: http://www.gogo6.com/freenet6/tunnelbroker  That client application configuration looks like this:

gogo

GoGo6 also offers the following services:

  • Appliance/CPE for the client-side tunneling called GoGoCPE that is sold for a very small cost: http://www.gogo6.com/gogoware/gogocpe
  • You can register for the free IPv6 social network called GoGoNET. Most of the IPv6 industry professionals are here and able to talk and answer questions. Details are here: http://www.gogo6.com/getting-started
  • GoGo6 also has an annual conference where they bring in industry experts and talk about IPv6 issues of the day called GoGoNET Live. Details for that event is here: http://gogonetlive.com/

Tunneling You Should Never Do – Ever!

The previous services and providers I mentioned are very good and have a lot of management and oversight around them. However, there are a few services you should never use for the following reasons:

Teredo

Don’t ever enable this. If your Windows machine is on a Windows domain, whatever you do don’t re-enable it. If you have a home PC, then you need to disable it ASAP! Use the DisabledComponents registry key to do this. Just follow this registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters

Now in this path create (or edit) the 32-bit DWORD file DisabledComponents with a decimal value of 1. Then reboot your machine. This setting will disable all IPv6 tunneling mechanisms on your machine. This is best practice for all Windows machines unless it is a DirectAccess Server.

So why is Teredo so bad? One word: control. First, the tunneling mechanism uses UDP port 3544 for client-to-server communication. However, that’s not the only port. Once the server assignes the address to the client it then directs the client to a Teredo relay based on Anycast. This means the client could theoretically be pointed to a Teredo relay anywhere in the world. At this point the Teredo-enabled client can get to the IPv6 Internet through the Teredo relay anywhere in the world. That is the bad part. So I recommend never using it, ever.

  • Disable IPv6 tunneling in DisabledComponents
  • Block UDP destination port 3544 and 3545 on your gateway device

6to4

Don’t ever enable this either. Regardless if your Windows machine is on a domain or not this function is always enabled. However, it will not configure itself unless it has a public IPv4 address. However, if it does have a public IPv4 address, then the Windows machine does not need a server to configure its address. It uses a 6to4 addressing algorithm as explained in RFC 3056. This algorithm from an IPv4 only client to the IPv6 Internet uses the 6to4 prefix, IPv4 public source address, the subnet ID, and the local IPv4 private address. So it looks something like this: 2002:4A7D:2B63: 5EFE::C0A8:0064

When setting up 6to4 on a local LAN, the subnet ID can be configurable, but Microsoft uses the 5EFE subnet ID. Once it auto configures this address the windows machine will go out to ipv6.microsoft.com. That DNS name resolves to the public IPv4 address of the Anycast 6to4 relay. This machine will then be able to go to the IPv6 Internet. The same security problems remains as with Teredo, it could go anywhere in the world.

Recommendations:

  • Disable IPv6 tunneling in DisabledComponents
  • Block protocol 41 on your gateway device

Summary

The residential ISPs are doing better. Between Comcast and Time Warner, users mostly likely have IPv6 in their networks. However, others still trail behind. There are many good and free tunneling solutions from Hurricane Electric, SixXS, GoGo6, for home users to try. However, I recommend to never use Teredo and 6to4 for security reasons outlined above. If you have any questions or comments about this blog please don’t hesitate to reach out to me at jduncan@tachyondynamics.com

 

Jeremy DuncanJeremy has spent over 10 years working in enterprise IT doing next generation technology deployments like IPv6, advanced networking, and open source solutions.  He participates regularly with the North American IPv6 Task Force; often speaking at the North American IPv6 Summits each year.  Jeremy spent 11 years in the U.S Marine Corps deploying to Iraq twice during Operation Iraqi Freedom 1 and 2 as a Communications and Information Systems Officer.  Jeremy has worked in the DoD with a wide range of information security, network engineering, and network architecture experiences with DISA, JITC, DTRA, and DTIC.  He currently leads up Tachyon Dynamics’ DoD UC APL and IPv6 training and engineering portfolios. He has a Masters of Science in Information Systems and is married with two wonderful children.

 

8 steps to get your site ready for IPv6

Republished with permission from the Mythic Beasts blog detailing how to get 10/10 on their IPv6 domain readiness checker.

1. Add an IPv6 address to your web server

The first step is to get your web server listening on an IPv6 address, as well as an IPv4 address. How you achieve this will depend on how your web server is managed. If you’re on a shared hosting account, you’ll be dependent on your hosting provider. If you run your own server, you’ll need to obtain an IPv6 address from your hosting provider (assuming they support IPv6), configure your server to use it and then ensure that your web server (e.g. Apache is listening on this address).

2. Add an AAAA record for your website

AAAA records are the IPv6 equivalent of A records, which resolve hostnames to IP addresses.  In order for users to find your website over IPv6, you will need to add an AAAA record for www.yourdomain.com pointing to the IPv6 address configured above.  You can check that this is in place using the dig command:

$ dig +short A www.mythic-beasts.com
93.93.131.39

$ dig +short AAAA www.mythic-beasts.com
2a00:1098:0:86:1000::15

It’s possible that your existing “www” record will be a CNAME for another hostname, in which case you should add the AAAA record to that hostname, rather than the “www” record.

Our health checker will skip this test if your domain doesn’t have an A record for “www”.

3. Add an AAAA record for your bare domain

Most websites are configured to work if the user omits the “www” prefix from the name, for example http://mythic-beasts.com

In order for this to work, you will need an A record for your domain name itself, and to be IPv6-enabled, you’ll also need a corresponding AAAA record.

Once again, our checker will skip this test if the bare domain doesn’t have an A record.

4. Ensure your DNS servers have IPv6 addresses

The steps above make it possible to access your website over IPv6, but unless your DNS servers are accessible over IPv6, users (or more specifically, their DNS resolvers) will still need to use IPv4 in order to find your site in the first place. To avoid this, you need to ensure that your nameservers have IPv6 addresses.

You can find the nameservers for your domain using “whois”, and you can check whether the servers have IPv6 addresses using dig, as before:

$ whois mythic-beasts.com
[ ... ]
Name Server: NS0.BEASTS.ORG
Name Server: NS3.MYTHIC-BEASTS.COM
Name Server: NS2.MYTHIC-BEASTS.COM
Name Server: NS0.MYTHIC-BEASTS.COM
Name Server: NS1.MYTHIC-BEASTS.COM
[ ... ]
$ dig +short AAAA ns1.mythic-beasts.com
2600:3c00::f03c:91ff:fe96:beac

If your nameservers do not have IPv6 addresses, then unless you run your own nameservers, you’ll either need to persuade your hosting provider to enable IPv6, or switch your DNS provider to a different provider.

For a full pass, our health checker requires that at least two of your servers have IPv6 addresses.

5. Add IPv6 glue for your nameservers, if necessary

In order to find the address for your website, a DNS resolver will first need to find the address of your nameservers. If your nameservers are in your own domain, this creates a bootstrapping problem. For example, in order to find the address for ns1.mythic-beasts.com, you need to ask the nameservers for mythic-beasts.com, which includes ns1.mythic-beasts.com. The solution to this is a glue record, a record containing the address of your nameserver which is held by the nameserver for the next zone up. In this case, the next zone up is .com, so the .com nameservers would contain glue records for the ns*.mythic-beasts.com nameservers.

If a nameserver has an IPv6 address, then any glue records for it should also contain that IPv6 address.

Checking for glue records is a little bit involved. The quickest way to do it is to use “dig +trace” to find a nameserver for the next zone up:

$ dig +trace ns1.mythic-beasts.com
[...]
com.      172800  IN  NS  a.gtld-servers.net.
com.      172800  IN  NS  b.gtld-servers.net.
com.      172800  IN  NS  c.gtld-servers.net.
[...]

We can now ask any of those servers for the NS records for our domain. Any glue records that exist will be returned in the “additional” section of the response:

$ $ dig NS mythic-beasts.com @a.gtld-servers.net.
[...]
;; ADDITIONAL SECTION:
ns1.mythic-beasts.com.  172800  IN  AAAA  2600:3c00::f03c:91ff:fe96:beac
ns1.mythic-beasts.com.  172800  IN  A 69.56.173.190
ns2.mythic-beasts.com.  172800  IN  AAAA  2a00:1098:0:80:1000::10
ns2.mythic-beasts.com.  172800  IN  A 93.93.128.67
[...]

If your servers are missing glue records, you will need to get your domain registrar to add them.

It’s worth noting that even if you don’t directly require glue because your nameservers are in a different zone, at some point along the chain there will be a nameserver that does require glue.

For a full pass, our glue checker requires at least two nameservers to be discoverable by a single-stack IPv6 resolver at every step of the chain of delegation.

6. Add IPv6 addresses for your incoming mail servers

In order to receive mail over IPv6, at least some of the mail servers listed in the MX records for your domain must have IPv6 addresses. You can find the mail servers for your domain using dig:

$ dig +short MX mythic-beasts.com
10 mx1.mythic-beasts.com.
10 mx2.mythic-beasts.com.

You can then check that these servers have IPv6 address by using dig to resolve an AAAA record, as before.

In order to pass this test, at least one of the servers listed in your MX records must have an IPv6 address.

7. Add reverse DNS for your mail servers’ IPv6 address

It is generally advisable to have working reverse DNS for any addresses from which you send outgoing mail. In the case of IPv6, this becomes pretty much essential, as one of the biggest mail providers in the world, Google, will reject mail over IPv6 unless the sending server has working reverse DNS for its IPv6 address.

Unless you run your own mail servers, adding support for IPv6 will be down to your mail provider.

Unfortunately, there is no reliable way to obtain the outgoing mail servers that are used for a particular domain, so instead our health check makes a bold assumption that your outgoing servers are the same as the incoming servers listed in your MX records, and checks those. This assumption is certainly not true of all domains, which is why a failure of this test is only treated as a warning.

8. Check your SPF records

SPF (Sender Policy Framework) is a mechanism for publicly listing your outgoing mail servers, so that receivers can detect spoofed email sent from other servers. If you enable your outgoing mail servers to start sending mail over IPv6, and you have an existing SPF record, it is important that you make sure that it includes the IPv6 addresses for your mailservers.

There are various ways of doing this. If your incoming and outgoing mail servers are the same, then you can use the “mx” mechanism in your SPF record. This means that any hosts listed in the MX records for your domains will be regarded as a legitimate source of mail for your domain, and this will automatically include any IPv6 addresses (assuming you’ve done step 6).

If you list IPv4 addresses or address ranges in your SPF record explicitly, then you will need to add corresponding IPv6 addresses for those servers.

The rules applied by our health checker aren’t entirely trivial, as it’s not uncommon for legitimate third party servers to be included in a domain’s SPF record, and there’s no way of pairing up IPv6 addresses with their IPv4 counter parts. Our health checker applies some very broad rules: if you use the “mx” mechanism, then the checker requires at least one IPv6 address for a server listed in the relevant MX records. If there are any explicit “ip4″ addresses or ranges specified in the record, then the health checker expects to find at least one explicit “ip6″ mechanism.

If your domain does not list an SPF record then this test will pass automatically, as this effectively defaults to “accept from all”.

These rules aren’t watertight, but have proven to be quite effective in identifying mail sources that either haven’t been enabled by IPv6, or which have but haven’t been added to the SPF record.

 

Build Your Own IPv6 Lab

Get your hands dirty. Playing with IPv6 can be the best way learn it. Jeffrey L. Carrell lays out how you can build an IPv6 lab from the comfort of your own home for no more than a few dollars.

Guest Blog Post by Jeffrey L. Carrell

IPv6 is called the new Internet protocol. However, it’s been running on the Internet since 1999, so it’s really not so new, it’s just that not a lot of networks have implemented it as of yet. The challenge is that it is different from what we are all used to working with. It’s a bigger number: 128 bits compared to IPv4’s 32 bits. It has colons instead of periods (ok, dots for us diehard networking folks).  It has all new routing protocol components. And on, and on. But, it has WAY MORE possible addresses than IPv4! The theory is, we should never run out in our lifetimes! But, it is different.

So, how do you learn about IPv6 if your company is not implementing IPv6? How do you afford the equipment that is capable of running IPv6? More importantly, should you spend your own money and time to learn about IPv6 if there are no other compelling reasons or funding? The answer: YES, you should learn it on your own! A professional technologist should realize that investing in yourself is important and generally does payoff in the future.  How much are you willing to invest, money wise? How about very little (and I mean ‘little’ as in a few bucks)?

For a small investment of a computer (which you probably already have), a free virtualization application, a free full-blown routing application, an Internet connection (even free WiFi at the coffee shop will work), $5.00 USD investment for an IPv6 tunnel account, and free or evaluation versions of client operating systems; you can build a sophisticated lab and learn IPv6 just as effectively as if you had invested a lot more money.

The platform I’d recommend consists of a single computer with 8+ GB ram, 200MB hard disk, dual-core or better processor, one or more networking interfaces, Oracle’s VirtualBox, VyOS (routing software), Freenet6 account and software (IPv6 tunnel service), client OS’s such as a Linux platform and/or Microsoft Windows evaluation versions, and an Internet connection that is IPv4 only. With this as a base system platform, you can also add external equipment and build a larger lab environment.

The purpose here is to “play” with IPv6. What I have found not only for myself, but for many others who I’ve had in IPv6 training classes, only reading about IPv6 does not provide adequate knowledge or the hands-on experience that leads to the actual learning of IPv6. You need to see the configuration components; you need to look at the packets with a protocol analyzer; you need to try different configuration scenarios. The doing will drive home the learning!

You can create your own IPv6 lab environment with just about any option to what I’ve outlined above. Any VM application will work, many routers and/or routing applications will work, and there are a few choices in choosing an IPv6 tunnel provider. My personal goal was to find the combination that didn’t require a lot of money or special hardware, and didn’t require specific types of Internet connectivity (e.g. you’re not required to have a static IPv4 address, generally the way home Internet services is provided). Another major aspect of this IPv6 lab system, is to have real IPv6 Internet connectivity over an IPv4 only connection, which means you can actually use IPv6 to communicate to the outside world. You can even configure a client VM to not have any IPv4 at all! I have tested this system at various WiFi hotspots, friends’ networks, and even at 37K feet in the air while flying on a plane that had WiFi.

I started with an account with Freenet6, which allowed me to build a system that provides for a /56 subnet for IPv6, which could provide up to 256 /64 IPv6 subnets. I generally design breaking the /56 into 16 /60s and then each /60 provides 16 /64s. This lets me build multiple networks, and I can then enable different IPv6 routing protocols to really test my configs. A most excellent resource specifically covering IPv6 addressing topics soon to be published is “IPv6 Address Planning” by Tom Coffeen by O’Reilly. Another great resource is Rick Graziani’s book “IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6” by Cisco Press which covers not only IPv6 basics but routing in an IPv6 network as well, with a focus on Cisco IOS.

So far I’ve made it sound easy to throw all this stuff together in a pot, stir it around a bit, and presto-changeo you have a way-cool IPv6 lab. Unfortunately that is not exactly the case. It does take a bit of tweaking and modifying to make the base system work. Initially you download all the software you need and also sign up for your Freenet6 account. Then you install VirtualBox and create a VyOS virtual machine (VM). After getting the VyOS VM going, the real fun begins. You must do some updates to the Debian base which VyOS runs on and then install the freenet6 (called gogo6) client software. After getting that all going, there are a few tweaks to the gogo6 main configuration file for account info, etc., and to the router config file gogo6 calls within VyOS. It’s a bit more complicated than I have time or space to cover here. After all this, you can then configure one or more client VMs to play with.

Here is what the IPv6 Lab system could look like:

Network Diagram Screenshot

After configuring the system, I have an IPv6 tunnel up and running, and a Linux client on a different IPv6 subnet, on an IPv4 only connection to the Internet, all in VirtualBox:

VB VyOS Screenshot

If you want to learn more about how you can set up your own IPv6 home lab, I will be facilitating two half-day hands-on workshops on this project at the upcoming 2014 North American IPv6 Summit on September 23-25 in Denver Colorado. There is still time to register for the workshop and/or the IPv6 Summit.

 

Jeff Carrell

Jeffrey L. Carrell is Network Consultant at Network Conversions. Jeff is a frequent industry speaker, freelance writer, blogger, IPv6 Forum Certified Trainer, network instructor and course developer to major networking manufacturers, and technical lead and co-author on 2 books: Guide to TCP/IP 4th Edition (contributing IPv6 content) and Fundamentals of Communications and Networking 2nd Edition. Jeff focus’s on IPv6 interoperability, and delivers lectures and IPv6 hands-on labs at technical conferences worldwide. As an IPv6 Forum Certified IPv6 Trainer, Jeff offers IPv6 Forum Silver and Gold Certified courses, customized IPv6 training courses, is an IPv6 Instructor for HP Education Services for their IPv6 Foundations course, and an IPv6 Instructor for Nephos6 for their IPv6 Foundations course. Jeff is a featured IPv6 instructor for the gogoNET online community, offering webinars and online workshops on IPv6 technologies via the gogoTRAINING initiative. Jeff is also a “Protocol Analysis Workshop” facilitator for Riverbed. Jeff has been involved in the computer industry for 35 years and has concentrated his endeavors in the internetworking portion of the industry for over 28 of those years. Jeff actively participates on IPv6 topics on twitter @JeffCarrell_v6.

 

What do terms like multistakeholderism, Internet governance, and technical community really mean?

Reflecting on the Internet Governance Forum, Suzanne Woolf explains how difficult it can be to come to a common understanding about the terminology used at the IGF and her impressions as a first-time attendee last year.

Guest blog post by Suzanne Woolf

Last year I went to my first Internet Governance Forum in Bali, Indonesia.  I was involved in several workshops and discussions about “the role of the technical community in Internet governance,” including the Regional Internet Registries (RIRs) and Internet Engineering Task Force (IETF); the role of governments; questions of increasing access to communications resources for the next billion users; and reactions to “pervasive monitoring” of Internet communications by US and other intelligence agencies.

I’ve been involved with “Internet policy” for many years now, as a member of ARIN’s AC, on various ICANN Advisory Committees, and as a liaison to the ICANN Board of Directors…which turned out to be a useful perspective, but by no means complete!

Words, Words, Words

For the perspective of someone who is new to the IGF, but familiar with “Internet governance” from experience of other venues, it was striking how much confusion there seems to be about many of the key terms thrown around. 

Multistakeholderism.  It’s easy for a techie to listen to 20 minutes of IGF workshops and speeches and conclude the term itself doesn’t actually mean anything. But a few days later I’d concluded it actually means too many things. I think there’s already a partial shared definition, though, in what it *isn’t*. It’s sometimes hard to tell what “multistakeholderism” means, but it does seem to be based on the idea that “Decisions aren’t only made by governments and implemented in treaties.” The problem then becomes figuring out who *does* make decisions, organized by what processes, so the decisions make sense and don’t just represent one or a few interests.

Internet Governance.  “Internet governance” is itself another slippery term. It’s not just about what the RIRs and ICANN do, it also includes topics like spam and child protection online and intellectual property protection and so on. The things RIRs and the Internet Corporation for Assigned Names and Numbers (ICANN) and the IETF oversee are “critical Internet resources” and considered really important, but the technical and operational details of how the Internet actually works are only a small part of what people talk about as “Internet governance”. This by itself can be disorienting for an engineer!

Technical Community.  Another thing that jumped out at me was the phrase: “technical community”. This is another term that’s hard to define in the IGF context. It doesn’t mean there what it means to the ARIN community, where people are “technical” if their primary knowledge/skills/work involves things like routers and peering. In the IGF context, people and roles are defined from astarting point of “some kind of stakeholder, not government”. The definition of “technical community” is lots broader than what we’re used to, and lots less clear.  It’s distinguished from “government,” “business,” and “civil society,” and it includes not only people whose background is technology and engineering, but anyone from an organization oriented on technology, from large ISPs and software companies to the RIRs, the Internet Society (ISOC), and World Wide Web Consortium (W3C). These categories can overlap, too.

Overall Impressions

Techies who step into the IGF, and meetings like it, should be prepared to be a little disoriented, but willing to listen and persist. IGF participants are people of good will and genuine concern for the future of the Internet. They don’t entirely agree on how to go about it, but they want a future that’s not owned only by governments or special interests, and they’re willing to work for it. The rhetoric can be confusing and the outcomes hard to define, but there’s a lot of positive energy and some real insight to be found as well. And the “technical community” has our own contribution to make, if we’re willing to engage.

I think RIR members should know that the Number Resource Organization (NRO) is doing very good work in just showing up, being visible in venues like IGF, and answering questions about the mysteries of how the net really works and the nature of “critical Internet resources” like IP addresses. If we don’t explain those things to “the other stakeholders,” its going to be even more difficult to make progress on “Internet governance” issues.

 

Suzanne WoolfSuzanne Woolf has extensive experience in internet infrastructure technology and management, particularly DNS and routing, and technical policy for names and addresses, including two terms on ARIN’s Advisory Council. She currently serves as co-chair of the DNSOP working group in the IETF and liaison from the Root Server System Advisory Committee to the ICANN Board of Directors. She’s a freelance consultant in Internet infrastructure and policy, based in the northeastern US.

 

 

 

For more information about the NRO’s participation in this year’s Internet Governance Forum, visit the NRO website.

 

Live Beyond Layer 3

Based on his time at CANTO, Owen DeLong, ARIN Advisory Council member & Senior Backbone Engineer at Black Lotus, encourages fellow Internet technologists to take the time to field questions from senior management and government officials.

Guest Blog Post by Owen DeLong 

I’m a layer three guy, which means that I am a network guy, specifically an Internet guy. I work on routers and connect big networks to other big networks to try and make the Internet work better. For a long time, I, and many people like me have tried very hard to ignore what we call layers 8/9/10 (the financial, administrative, and governmental entities involved with the Internet).  Or worse, sometimes we have been known to sneer at them as “damage to be routed around”. I know that attitude still persists among some, but it really fails to take in the whole story.

ARIN at CANTO 2014

For the last several years, I’ve had the opportunity to work with ARIN doing outreach in the Caribbean at the annual CANTO conference and exhibition. While there are lots of layer 1/2/3 (fiberoptics, switches, routers, etc.) products on display, but the reality is that most of this show is for senior management and government officials. This year, the opening ceremony included speeches from the secretary general of the ITU and the prime minister of the Bahamas (where the meeting was held). There was no shortage of senior government officials.

There are several reasons that CANTO attracts so many senior executives and government officials. First, the Caribbean has traditionally had a number of state-run and/or state-owned telecommunications services or monopoly telecommunications services that were licensed by the state(s). That’s been changing, but slowly. CANTO has always been a forum where those groups and other industry representatives can come together to learn about new technologies, see what is happening in other parts of the region, and talk about issues that are unique to the region and/or require coordination among various countries in the region. In recent years, it has come to include not only telecom, but all of ICT and has also served as a forum to help move away from monopoly telecommunications towards more deregulated and diverse provider choices.

The Internet has become important enough that we layer 1/2/3 folks can no longer pretend government isn’t relevant, nor can we pretend that government won’t notice us and will continue to leave us alone. It’s critical that we increase our awareness about how things work in the wider world and start educating regulators and senior management in ways that will allow them to do their jobs without damaging what we’ve built. As nice as it is to live in layer 3 without caring what’s above or below, strict layering simply doesn’t work with human relationships. In the end, networks are about connecting people, and that’s a process that transcends all layers.

When a manager or a regulator approaches you and starts asking questions you don’t think are worth your time, remember, your answers are going to shape how they decide many things that may affect your future. Answer wisely and carefully. Be available for follow-ups. Be courteous, and this experiment that escaped from the laboratory might just be able to remain the most awesome tool ever developed for democratizing communications.

 

Why Is the Transition To IPv6 Taking So Long?

IPv6 is an essential technology if the Internet is to grow, but adoption has been slow. Graeme Caldwell of Interworx takes a look at why organizations are holding back on IPv6.

Guest blog post by Graeme Caldwell 

We stand on the cusp of an explosion in the number of Internet-connected devices. The mobile revolution was just the beginning. Combined, the burgeoning wearables market and the Internet of Things will potentially create billions of new connected devices over the next few years. Every device will need an IP address and there are far too few available addresses within the IPv4 system to handle the sheer quantity of connections. It’s a problem that’s been predicted and solved for many years, in theory at least. But IPv6 is being adopted at a glacially slow pace.

The reasons for the gradual adoption are simple to understand. It’s expensive. The Internet is made up of tens of millions of servers, routers, and switches that were designed to work with IPv4. Upgrading that infrastructure entails a significant capital investment. As things stand, workarounds like NAT take some of the pressure off — but they are a temporary band-aid solution. In the long-term, transition to IPv6 will have to happen, but, given the level of the required investment, there’s not a compelling business argument to make the transition immediately.

To get the full benefit of IPv6, a significant proportion of the net’s infrastructure has to support it, and, with the exception of a few organizations, many don’t want to invest in infrastructure upgrades that don’t have any immediate benefit.

When they were developing IPv6, the Internet Engineering Task Force decided that, in order to implement new features in IPv6, the protocol would not be backward compatible with IPv4. IPv6 native devices are not capable of straightforwardly communicating with IPv4 devices. That makes incremental updating of systems difficult, because workarounds have to be put in place to ensure that legacy hardware and newer IPv6 hardware have a way of talking to each other — most IPv4 hardware will never be updated.

According to Leslie Daigle, Former Chief Internet Technology Officer for the Internet Society, “The lack of real backwards compatibility for IPv4 was the single critical failure. There were reasons at the time for doing that. But the reality is that nobody wants to go to IPv6 unless they think their friends are doing it, too.”

Forward thinking software companies have already included the necessary functionality to handle IPv6 in their products. At InterWorx, we could have left implementing IPv6 support until we absolutely had to, but the benefits of the transition for us and our users in the web hosting industry were undeniable. We wanted to give clients the option of using IPv6 so they can begin to prepare for the inevitable move and implement IPv6 systems. InterWorx includes a full suite of IPv6 management tools, including IPv6 pools management, IPv6 clustering, and diagnostic tools.

In a Feburary 2014 report, Google revealed that their IPv6 traffic had hit 3 percent and it’s currently at about 4 percent. That seems unimpressive, but it’s a sign that adoption rates are accelerating — the move from 2 percent to 3 percent took only 5 months and from 3 percent to 4 percent even less time. Under pressure from the proliferation of connected devices, we can expect to see organizations adopting IPv6 ever more quickly.

 

GraemeGraeme works as an inbound marketer for InterWorx, a revolutionary web hosting control panel for hosts who need scalability and reliability. Follow InterWorx on Twitter at @interworx, Like them on Facebook and check out their blog.

 

Caribbean Internet Governance Forum (CIGF) Celebrates 10 Years

CTU Telecommunications Specialist, Nigel Cassimire, shares what happened at this year’s Caribbean Internet Governance forum.

Guest blog post by Nigel Cassimire, Telecommunications Specialist, CTU

Caribbean IGFThe 10th edition of the Caribbean Internet Governance Forum (CIGF) was held at the Atlantis, Paradise Island Resort in The Bahamas from 6th to 8th August 2014. The CIGF is a regional, multi-stakeholder forum which was initiated by the Caribbean Telecommunications Union (CTU) and the Caribbean Community (CARICOM) Secretariat in 2005 in order to coordinate a regional approach to Internet Governance issues for the final session of the World Summit on the Information Society (WSIS) in Tunis that year.

The CIGF has since been convened annually by the CTU and lays claim to being the first such regional forum in the world, all others having been convened after the initial global Internet Governance Forum in 2006. The primary product of the work of the CIGF has been the formulation of a Caribbean Internet Governance Policy Framework issued in 2009, and updated in 2013, which:

  • Articulates a vision, mission and guiding principles for Internet Governance (IG) in the Caribbean
  • Identifies current priority areas in IG of greatest relevance to the Caribbean
  • Offers policy recommendations in such priority areas for the attention of all stakeholders

The theme of the 10th CIGF was “Building National Capacity for Global Influence” and specific objectives addressed in the agenda were to:

  • Build regional capacity in the area of ccTLD operation and administration
  • Review and update the Caribbean Internet Governance Framework V 2.0
  • Facilitate open discussion on the Net Mundial Outcomes, and the proposed NTIA transition.
  • Explore and spread awareness on Opportunities for Caribbean Growth through the Internet Economy
  • Develop a mechanism to ensure effective Caribbean representation at Global Internet Governance Fora.

There were over 40 registered participants representing Caribbean stakeholders in government, operating companies and other private sector, academia, civil society and, in particular, Caribbean ccTLDs for whom dedicated content had been included on the agenda. ICANN, ARIN, LACNIC, ISOC and Google all provided financial support as well as valuable agenda content. Agenda information as well as presentation slides are archived on the CTU’s event web page.

The 10th CIGF successfully addressed its objectives through presentations and several vibrant discussion sessions and, when necessary, focussed review of the policy framework document. Suggested refinements were identified for subsequent wider circulation and comment. This is the first step in the current revision cycle towards a third revision of the document for likely issuance in 2016.

Most importantly, the CTU Secretary General, Ms. Bernadette Lewis proposed an approach for fostering capacity building in IG at the national level in order to enhance Caribbean participation and influence globally in IG, consistent with the 2014 theme. This approach is based on mobilising relevant ICT resources and expertise in the Caribbean not currently focussed on IG e.g. computer societies, IT professional associations and the like.

The CTU will continue to foster multi-stakeholder collaboration in the Caribbean region on Internet issues and in particular through the medium of the CIGF. More deliberate efforts will also be taken in the near future to coordinate the work of the CIGF with the wider regional LACIGF and the global IGF. Please plan to attend the 11th CIGF that will be held in Suriname at a date to be fixed in 2015.

 

Nigel CassimireNigel Cassimire has been serving as a Telecommunications Specialist at Caribbean Telecommunications Union since July 2005, when he started independent consultancy. The CTU is a regional organisation with responsibility for the development of ICT policy within the Caribbean region. Its members are drawn from Caribbean Governments, private sector and civil society organisations. Nigel has over 30 years of experience in telecommunication industry. He has extensive knowledge in telecommunications technologies and services and is now working in telecommunications policy development at the Caribbean Telecommunications Union Secretariat.