Breath deeply, a /64 is a good thing

by Craig Miller

Earth's atmosphere is vast

IPv6 is a different networking protocol from IPv4. To illustrate, just look at how a host can get a globally unique IP address (GUA) without requiring any servers, without sending a packet*.  This is made possible by the fact that IPv6 does not have variable subnet-masking. All end user LANs are a /64.

There are some who say that it is a waste of address space to use an entire /64 (4 billion * 4 billion) on a single subnet. I would suggest that those who do are still in a IPv4-frame-of-mind. The IPv6 address space is vast (see Simplifying Subnetting).

Take a breath

Think of it this way, how many breaths have your taken since getting up this morning? I have no idea how many I have taken. But if you are scuba diving, and are breathing off of a tank of compressed air, you pay close attention to how much air you have (usually measured in minutes, but when diving, that can change depending on how deep you are, and what kind of effort you are expending). We don't think about how many breaths we take driving into work, because Earth's atmosphere is vast.

A prefix longer than /64?

There is the additional problem, that if the LAN subnet is defined as something other than /64, many things will break, much more than just SLAAC (Stateless Address Auto Config). The authors of RFC 7421 have exhaustively gone through the RFCs to examine what assumes the end user LAN is a /64.

Some failure modes highlighted by RFC 7241:

• Routers may drop packets on interfaces /65 to /126 (inclusive)
• Specific Multicast Addresses will fail (resulting in NDP failures)
• The Cryptographically Generated Address format [RFC3972] relies on /64
• Many Transition mechanisms, such as NAT64, XLAT464 
• Duplicate Address risk, should SLAAC be modified to work with more than /64
• Link-Local, defines the Interface ID (IID) as 64 bits wide
• IP Address Management (IPAM) systems assume /64
• Firewall look up issues (where there are not enough content addressable memory bits to include longer prefixes + L4 port numbers)

Although not specifically a failure mode, a smaller subnet space takes less time for attackers to scan.

Think Different, Think Vast

Think about how many breaths you take in a day, a month, a year. Compared to how much air is in the world, what you breath is insignificant. So take a deep breath, and remember IPv6 address space is vast.


* Duplicate Address Detection (DAD) is performed, but only after a GUA has been selected.
** Photo licences under Creative Commons

Swiss Cheese, or Is that your Firewall?

by Craig Miller

Yummy yes, but not a good firewall

While debugging connectivity issues a user was having with my v6brouter project, I discovered that I was not the only one to see a brouter as a solution to extending the ISPs IPv6 network (when they don't provide prefix delegation). And the humbling thing is, that IPSOL did it more elegantly than my clunky code.

So if extending an IPv6 prefix can be done so elegantly, why not rewrite my v6brouter to utilize that better idea. And while I was there, I thought I would provide value add of a bridging firewall (see v6Brouter Part 2: v6Bridge Firewall). The first bridging firewall was more of a proof of concept, but not that useful if you are directly connected to the internet, since it only blocked external SSH access.

Creating a static bridging firewall

My first attempt at rewriting the firewall, was to block all external access, and only allow external in-bound SSH connections. This seemed like a better default firewall configuration.

And it worked great! It blocked all all in-bound connections except SSH. It also blocked responses to web requests, and any external response to a host on my LAN. Very secure, but not all that useful.

A more useful, stateful firewall

This led me to think more about how firewalls work, and the delicate balance of security vs convenience. I had created a very secure firewall, but certainly wasn't convenient. Modern firewalls are stateful machines which keep track of outbound requests, and open holes to permit external responses to those requests, thus making the firewall useful to the users inside on the LAN.

Fortunately, OpenWrt is linux-based, and I could utilize ip6tables features to create a stateful bridging firewall. It would block unsolicited external access, while allowing internal LAN hosts to receive external responses to their requests. All of this without altering the packets, just bridging, and extending the IPv6 prefix into user's LAN.

We tend to think of firewalls as a monolithic non-combustible barrier providing protection from the firestorm that is the Internet these days. But even a car firewall has holes: holes for brake lines, accelerator linkages, steering wheel linkage, wiring, coolant pipes (for the heater), etc.

Check for Holes

A network firewall can begin to look like Swiss cheese, after all the special user requested holes, connection-based holes (for external responses), and UPnP (Universal Plug n Play) holes that are requested by software on LAN hosts. If you don't know how many holes are in your firewall, it might be time to take a look. Don't forget to check your IPv6 firewall as well. Swiss cheese is good on a sandwich, but not as a firewall.


* Swiss cheese photo - Creative Commons

Excuse me, your MAC is showing

by Craig Miller 

MACs exposed*

Stateless Address AutoConfiguration (SLAAC) is an easy way to get an IPv6 network up and running quickly. But  RFC 4291 states that the  the interface MAC address should be used when generating a Global Unique Address (GUA).

For the most part, this works quite well. Most MAC addresses are unique (although they only need to be unique within the same broadcast domain). But it has problems when it comes to hardware repair. What happens when you need to replace a NIC card, the GUA changes. Not good.

I have argued in the past that this was a small issue, since servers are probably going to have static IPv6 addresses, which get mapped in DNS to names. Therefore changing a NIC card won't change your GUA.

Exposing information

Other's have expressed concerns that using the MAC address in the GUA exposes that information to the outside world. But on the far side of a router, the MAC address is no longer significant, and therefore pretty useless for network attacks.

But sharing the MAC address globally does reveal the hardware vendor of your NIC, since the first 3 bytes of a MAC address is registered to a manufacturer. This may lead some try to infer an installed OS, and limit their attacks based on this assumption. But the privacy extensions (RFC 4941) have all but eliminated this problem, since temporary GUAs are used for outbound connections.

When infinite is only 16 million

But in-bound connections are still received on the SLAAC MAC-based GUAs.  Reading RFC 7707 (Network Reconnaissance in IPv6 Networks) has convinced me that it is time to move beyond the old MAC-based GUA. RFC 7707 discusses how an attacker can limit the number of addresses being probed from the 2^64 address space by selecting a common NIC vendor (such as Apple, 10:9a:dd:xx:yy:zz) thus reducing the address pool to 2^24. Or in more humanly understandable numbers reducing the potential address from 1 in 18,446,744,073,709,551,616 to 1 in 16,777,216 (or 16 million). Suddenly, the seemingly infinite address space of 2^64 is quite manageable to probe.

A Standard to the rescue

Fortunately, there's a new standard to disconnect the MAC address from the GUA. RFC 7217 (Semantically Opaque Address Generation). Rather than use the MAC address, the RFC recommends using a cryptographic method to generate the lower 64 bits of an address. This opens the entire 2^64 address space again for a GUA on a device. Making it very difficult to guess by an attacker.

The latest version of Mac OSX (10.12) and Windows (10) support this method of GUA generation. Unfortunately, Linux a former leader in the realm of IPv6 support, is behind. A feature enhancement (#4625) has been submitted to systemd for RFC 7217 support.

SLAAC, letting you slack off

Where does this leave us? IPv6 is improving, clever people are fixing the problems of the earlier implementations. With RDNSS (see IPv6 RA, RA, RA) and Semantically Opaque addresses, a SLAAC environment can be viable option to run IPv6 networks with the minimum of management hassle**.


* Macadamia Nuts in and out of the shell
** OK, if you have Windows machines on the network, it may not be enough (see Dual Stack, the good, bad, and ugly)

IPv6 & Systemd, another look

by Craig Miller

Lennart Poettering on systemd*

Systemd is coming to a computer near you. All the major linux distributions have adopted it. Systemd is a replacement for init, PID 1, and if the developers had stopped their, there would be no real impact. But the developers have expanded the influence of systemd to include many other aspects of how your linux workstation operates.

• networkd - Controls the aspects of networking, including DHCPv6 Client, RA processing, SLAAC address assignment, IPv6 route insertion, etc
• resolved - Acts like DNSMasq (but more limited) in resolving Domain Names. It gets pointed to DNS servers via networkd.
• Other aspects of the linux host, including logind, hostnamed, locald, timedated, machined, importd to name a few.

The systemd daemons will also process IPv4 information, but that is beyond the scope of this blog.

Another Look at systemd

It has been six months since I took a good look at systemd and IPv6. You may remember that there were some clear issues which may cause one to pause before deploying a systemd host in an IPv6 production network.

A recap of IPv6 issues with systemd

The devs at systemd (and Redhat) have decided to re-implement functionality already in the kernel code. Therefore there are a few things which worked just fine in a non-systemd system, but do not in a modern system. Retesting with systemd version 231, we see there are improvements (below).

Description	Issue	Status
IPv6 RA flood (THC flood_router6) causes network disconnection even after flood ceases	#2977	FIXED
Temporary addresses (RFC 4941) are broken from version 224 to 228	#2242	FIXED
nterface disable/enable IPv4 will reaquire and address, but IPv6 will not (other than link-local), and will remain address-less until restarting networkd	#2912	Still broken
Fails to send Router Solicitation	#2365	Still broken
Unable to view DUID (DHCPv6 Identifier) on host	#2952	Closed but Still broken
Bridged Interfaces get IPv6 SLAAC addresses	#2572	FIXED
Systemd in a VM failed to start due to RA parsing error	#2228	FIXED
IPv6 incorrectly not enabled on Virtuozzo containers	#2059	FIXED
IPv6cceptRouterAdvertisements=yes or unset accepts too many prefixes	#2004	FIXED
Does not support DHCPV6-PD	#1080	Still broken
Does not support SLAAC RDNSS	#1079	FIXED

A few more issues have been added in the past 6 months

Description	Issue	Status
networkd does not support DNS List option in RA	#4590	Open
Semantically Opaque Interface Identifiers with IPv6 SLAAC RFC 7217	#4625	Open
networkd: handle MTU field in IPv6 RA	#4464	Open
RFC 7084 support in networkd (automatic ipv6 prefix delegation)	#4073	Open

Time will improve systemd

It is unfortunate that the systemd team has decided to re-implement existing functionality (e.g. in the kernel, dnsmasq, odhcpd). But like fine wine, it is improving. Be sure to check the details of the issues which may impact your testing/deployment and save yourself a bunch of time. As always, taking the time to plan your IPv6 deployment will save you time in the end.

*Lennart Poettering T Shirt 

IPv6 in the palm of your hand

by Craig Miller

With the all of the major wireless providers in the US, and large service providers, like Sky, in Europe now offering native IPv6 service (see Glass Half Full), there is no time like the present to learn the new protocol, IPv6.

No IPv6 here

And yet even with all this new IPv6 access available, there are still many who's first reaction to a problem is to turn off IPv6. Like ostriches, it seems like they would rather stick their head in the sand, and hope that IPv6 will go away.

A new IPv6 device

I recently bought a new Android cell phone. Alas, in Canada there is only one provider, Telus, who offers IPv6 wireless service. And I am not their customer. Fortunately, I do have an IPv6 WLAN. While re-installing my useful apps on the new phone, I took a look at the Android IPv6 apps that are out there. And I was surprised and disappointed  to see the abundance of "disable IPv6" apps out there. Seriously, there has got to be a better way.

Step into the future, rather than disable IPv6

Helpful apps

But there were other apps as well, to help one learn IPv6. There is an excellent Hurricane Electric* IPv6 Network Tools, which can tell you a lot about your network.

There are even an IPv6 subnet calculators, which of course, aren't really required, since IPv6 does not have variable subnet masking (see Simplifying Subnetting), making things much easier than IPv4.

IPv6 in the palm of your hand

With Apple pushing in iOS 10 for full IPv6-only networking in their apps, and Android IPv6 helpful apps, you can now learn IPv6 on your phone while waiting for your coffee at Starbucks. Ah, good coffee, and the future of the internet in your hand,  it is a good time to explore IPv6.


*Hurricane Electric is an excellent IPv6 service provider, and offers free IPv6 tunnels for those who do not have native IPv6 service.

Extending a /64 Prefix

by Craig Miller

Extending a /64 Prefix

It would appear that ISPs are still learning how to deploy IPv6, and the old "conserve address space" thinking continues. Amazingly there are many ISPs still using a single /64 for their customers, with no Prefix Delegation (PD).

Some math, how far will a /32 go?

ISPs with only a /32, and not giving their customers more than a /64, have failed to understand just how big a /32 is. With a /32, there are only 4 billion subnets to give out to their customers. If the ISP gives out an additional /64 (using DHPCv6 PD) to each customer, that is still 2 billion customers, each with a /64 in their home network.

But what if the ISP was a little more generous, and gave out a /56, allowing customers to subnet within their home (255 subnets)? That /32 would be exhausted only after 16 million customers (or about the total number of internet customers of AT&T in 2016 Q2. That is just one /32, if an ISP runs out, they can apply for another. As I have stated before, we need to shed the "conserve address space" thinking of IPv4 when doing network planning in IPv6.

Wireless 3GPP and an IPv6 Hotspot

But what if your ISP only provides a /64 for the end device with NO additional subnets. Telstra does this with their wireless network. Phones only need to attach to the IPv6 wireless network, right?

What if the customer wanted to run a hotspot? Since there is no additional /64 for the "LAN" network what is one to do? Fortunately there are smart minds suggesting solutions. OpenWRT has a "relay-mode" which relays RAs and NDP traffic from upstream, thus extending the WAN-side /64 prefix into the LAN-side. There is also the v6brouter project which uses bridging for IPv6 while maintaining IPv4 NAT.

Standards to the Rescue

And there is RFC 7278 Extending an IPv6 /64 prefix from a 3GPP mobile interface to a LAN link. The RFC describes processing RA and NDP packets which sounds very similar in concept to the OpenWRT/odhcpd implementation.

The good news is that ISPs are learning more about IPv6 deployment. If you are one of the unlucky ones with only a /64 or less (no PD), comment to your ISP, and let them know there is plenty of room. And if you want to set up that IPv6 enabled hotspot on your phone, go ahead, and thank the authors of RFC 7278.


* extension cord, creative commons

A glass half full

by Craig Miller

This month, the Internet Society (ISOC) reports that the four major mobile carriers in the US passed the milestone of  50% IPv6 traffic to Facebook. This sounds like great news, and it is.

But looking a little deeper yields more information.  Why the US Mobile Carriers? Why is this metric highlighting Facebook?

The good news

Where is there the greatest need for expanded IP addresses since ARIN ran out of IPv4 addresses last fall (2015)? The explosion of smartphones and LTE service in the US, has led to the rapid adoption of IPv6 by even the most conservative of carriers, like AT&T. The fact is that if you need more address space as an ISP (Mobile Carriers are just wireless ISPs), you must turn to IPv6. This is good news for IPv6 advocates.

And in Europe, Sky has recently enabled IPv6 achieving 80% of its customer-base now with IPv6. BT, hopes to follow in 2017.

Finally after waiting 20 years, serious IPv6 adoption is actually happening.

The less good news

Facebook is the metric for two reasons: it is a big content provider, and it is one of the few content providers which support native IPv6 connectivity. Unfortunately other content providers have not woken up and smelled the coffee, and remain stuck in the IPv4-only world.

Hopefully everyone enjoyed the recent Olympics in Rio, which seemed to be a success. Unfortunately, CBC in Canada has zero IPv6 presence on the web. Kudos to NBC in the US which setup a separate domain nbcolypics.com which does support IPv6. Unfortunately all that streaming of events north of the border, whether it be the 100 meter sprint, or waterpolo was all over IPv4.

The reality is that content providers see few business reasons to move to IPv6. After all there are transition technologies such as dual-stack or NAT64 which allow them (and many others, CBS, ABC, Twitter, Reddit) to continue serving IPv4-only content. Sadly, even some content providers still see IPv6 as an inferior transport.

Is it half full or half empty?

Like a glass of water that is half full, it is good news that  more than half of the mobile traffic is IPv6 capable, but the glass is is still  half empty when it comes to content providers supporting IPv6. It looks like us IPv6 advocates will have to wait a little longer for the content providers to move into the future of the internet.


* Glass courtesy of creative commons

Transitions, getting from here (IPv6) to there (IPv4)

by Craig Miller

Parlez vous IPv6?

There will be no IPv6 flash-cut-over. This is not news, but the methods of transition might be. We will be living with IPv4 for some years to come, and to help us stay connected are several transition mechanisms.

Bolstered by the news (from Google and others) that IPv6 traffic on the internet was up to 10%, I set up an IPv6-only network in my house. Initially the network was only connected to the internet via IPv6. I found it is a dark world out there. Although many ISPs are moving to IPv6 with ARIN finally running out of IPv4 addresses last fall (of 2015), the content providers are still slow to enable IPv6. I was surprised and disheartened that most of my news providers (CBC, BBC, NBC, ABC, CBS, FoxNews) were all only running the legacy IP protocol, and therefore inaccessible from my IPv6-only network.

Transitions, how to get there

The easiest transition mechanism to use is dual-stack. And I have discussed this in previous posts (see Dual Stack, the good, the bad, the ugly). But there is a cost to dual-stack, specifically to network administration and maintenance. Now routers have to be configured for IPv4 and IPv6, the same with firewalls and DNS, and other networking elements.

But the good news is that once the IPv6 pipes are turned up, dual-stack just kind of works. Mostly because if there is an IPv4-only service, the host (e.g. your laptop) will just use IPv4 to connect, and the lack of IPv6 will be transparent to the end user.

Simplify the Network

We had it good after IP won the protocol wars. We didn't have to run multi-protocol routers (of the 90s) which supported not only IP but Novel/IPX, AppleTalk, Vines, and NetbEUI. We only had to support one protocol, IP(v4), and that was much easier.

Companies such as Facebook, and T-Mobile have figured out that it is easier to support just one networking protocol as well, and they have chosen IPv6. But how does one prevent seeing the dark world I did in my little IPv6-only network?

DNS64 returning false addresses

Enter NAT64/DNS64, RFC 6146. Yes, in the past I said that NAT is bad, and it is, but NAT64 is more like protocol translation, translating from IPv6 to IPv4 (and back). NAT64 relies on two things, 1) the large address space of IPv6, and 2) DNS64 resolving IPv4-only hosts into a special IPv6 address.

When the user wants to go to a IPv4-only service, DNS64 will return a special IP address starting with the prefix* 64:ff9b::/96 (e.g. 64:ff9b::c73b:9607). The connection will be opened to this address, which happens to be the NAT64 box. Since the IPv4 address is encoded in the last 32 bits of the special IPv6 address, the NAT64 opens an IPv4 connection to the legacy service acting as a protocol translation proxy service. Like IPv4 NAT, it keeps a session table, and can return packets from the legacy service to IPv6-only user's laptop.

A nice feature of this transition mechanism, besides a simpler internal IPv6 network, is that the DNS64 service does not have to be located inside your network. Google has made a public DNS64 service available at 2001:4860:4860::64

Testing NAT64 with OpenWRT

Letting Google's DNS64 do the hard work, means that one only needs setup a NAT64 service. On OpenWRT, it is possible to setup NAT64 service, although it is not a simple install and go, as the NAT64 package tayga has been removed from the most recent release repository. However the package can be found in the 12.09 release. The UCI (Universal Configuration Interface) does not work on the latest release (15.05.1), but following the quick setup instructions on the tayga website should get you going.

Although NAT64 on OpenWRT is great for a test network to give you some experience in using the transition technology of NAT64/DNS64, it is not recommended for a production network. Tayga runs in user space, and is somewhat slow.

Production quality vendors such as Cisco support NAT64 as well.

Industry moving to NAT64

Apple has made a big push in iOS 10 to have all new/updated apps in the app store support NAT64 (or IPv6-only) networks. Google with Android 6, while not making quite the commitment Apple has made, will support NAT64 (and IPv6-only) networks if the app supports it (alas there are still too many apps which are v4-only). ChromeOS works well in a NAT64/IPv6-only environment, but like Android, there are applications which are IPv4-only.

With the simplicity of only supporting one protocol on the network, and a transition mechanism the industry is behind, there is no time like the present to start gaining some experience with NAT64, and shine the light into your IPv6-only network.


*although it possible to use other prefixes for NAT64 (than 64:ff9b::/96 RFC 6052), Google's DNS64 returns addresses with this prefix, which makes life easier.

Feature Parity!

by Craig Miller

Bridging Feature Parity for all wheeled vehicles

We have solved problems for the 25 years or so that the internet has become a foundation of computer networking in our society, with many clever tricks, or even hacks. NAT (Network Address Translation) is probably the most well known. But there are others as well.

If we are going to move forward into the brave new world of IPv6, we need Parity with the features and capabilities of the legacy protocol, IPv4. That doesn't mean that we need similar tricks, but we do need similar solutions.

Wireless Ethernet Bridging

Case in point, I wanted to setup a wireless Ethernet bridge in my home to bring wired connectivity to a corner of the house where it is difficult to run wires. This seemed like a simple task of running a second router as an Ethernet bridge, acting as a wireless client of the first wireless router*.

Oops, lost the Ethernet MAC header

And that is where the fun began. Because, when one configures a second router as a wireless client, there is more going on that meets the eye. From a high level, the packet starts as Ethernet (802.3), but then changes to 802.11 (Wireless Layer 2 protocol), and then must change back to Ethernet. The last step is where the problem begins, what Ethernet MAC address to use, since it was stripped off when the 802.11 header was put on the packet?

Using Scapy notation, the packet would look like:
/Ethernet/payload (original packet)
/802.11/payload   (packet of the air)
/??/payload       (The Ethernet MAC address has been lost)

There are a couple of ways to deal with this, one could have been encapsulation of the bridged frame in 802.11 header, but instead a trick was used which only works for IPv4. Alas, no IPv6 frames will be bridged across the wireless link. Which in my home, kind of defeats the point.

WDS to the rescue, dang no standard

But wait, what about WDS (Wireless Distribution System)? After all, it was made for wireless bridging. Yes, it handles the problem of the the unknown Ethernet MAC address, and should be the solution. However, WDS was never standardized, and as such, is incompatible between different vendors and even different products (think chip sets) of the same vendor.

Still need solutions in an IPv6 world

We must demand feature IPv6 Parity from vendors and ask for the same from the open source community The networking problems that we have solved over the past 25+ years, still need solutions in an IPv6 world.


*Over the 5Ghz band, as the 2.4 Ghz band is way to crowded

Breaking the NAT frame of mind

by Craig Miller

Let's face it, we have been living with NAT (Network Address Translation) for so long, NAT could vote, drink, even have a kid. NAT has been around for 23 years (since RFC 1621 was written in 1993). An interesting concept in the RFC is that NAT would be a temporary measure:

If nothing else, this solution can serve to provide temporarily relief while other, more complex and far-reaching solutions are worked out.

Note, that far-reaching solution is IPv6, which was standardized two years later (RFC 1883).

NAT helped with Address Exhaustion, but...

NAT was the solution to the problem of IP address space exhaustion. The authors of RFC 1621 saw security issues with NAT, such as passing encrypted traffic (ESP),  and debugging problems, since IP addresses change.

But there was that address problem, and a generation of IT people have grown up with NAT, thinking it is a feature rather than breaking end-to-end connectivity, which existed before NAT.

Fast forward to Today

So fast forward to today, and although addressing should not be a problem in IPv6, there are those who struggle with it. As I have written in previous posts, some ISPs are only handing out /64 addresses. When faced with a single /64, what is a router to do? Routing by definition is connecting two or more networks (in IPv6, this means two ore more /64 networks).

Unfortunately, some have discovered that the Linux kernel can mangle IPv6 addresses as well as it can IPv4 addresses, and have written how-to's on how to implement NAT6 to solve the single /64 problem. In my mind this is the wrong thing to do. NAT whether it is IPv4 or IPv6 incur res the same set of problems: difficulty in debugging, no improved security, multiple users sharing a single address, breaking end-to-end connectivity, increased latency, overlapping address space to name a few. Using NAT6 is IPv4-thinking. We must break out of this kind of thinking, and apply better solutions to the problem.

1. Encourage our ISP to support Prefix Delegation, providing more than a /64 to the customer. (to be fair many ISPs who have a good understanding of IPv6 are already doing this)
2. Use a v6brouter approach, which bridges IPv6 with a firewall, avoiding NAT.  (see NAT-iness and the v6Brouter) And continue to push your ISP for more than a single /64

Restoring end-to-end Connectivity

There may be situations in the future where NAT6 will be a reasonable solution. Not sure what they are today, but I want to keep an open mind. But for now, I would suggest we leave our IPv4 thinking behind, and try to restore true end-to-end network connectivity. Something we haven't enjoyed for 20 years.



* Router Image