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

Fighting FUD

by Craig Miller

FUD is Fear, Uncertainty and Doubt. There's a lot of mis-information about IPv6 circulating on the internet. Much of it is old, out-of-date, and just plain wrong.

Fear 

The fear is that since IPv6 uses global addresses, external hosts can make inbound connections to your machine.

• This is IPv4/NAT thinking. That somehow NAT is considered a security blanket that protects us from the nasty outside world. Before there was NAT (see Breaking the NAT Frame of Mind) there were firewalls to keep the bad guys out. Firewalls have improved immensely in the past 20 years. They are stateful, and do connection tracking. Modern firewalls will only allow outbound connections (by default), thus keeping the bad guys on the outside. Even your IPv6 enabled Home Router comes with an IPv6 connection tracking firewall.

Uncertainty

Another is the uncertainty that IPv6 leaks your MAC address to the internet. I find several things wrong with this:

• This applied to SLAAC (Stateless Address Auto Config) initially, where the later 64 bits of the host address are formed from an EUI-64 (a 64 bit MAC address). However since RFC 4941 and IPv6 privacy extensions, this is no longer the case. A temporary, randomized, IPv6 is used for outbound connections. The temporary address is changed every 24 hours (by default). All major OSs support IPv6 privacy extensions.
• DHCPv6 does not use the MAC address to create an IPv6 address, and therefore there is nothing to worry about in most Enterprise networks (which tend to use DHCPv6).
• So what? What is someone going to do with your MAC address on the internet? MAC address by default is locally significant. That means once the packet crosses a router, the sender's MAC address is gone, replaced by the router's MAC address. Knowing the sender's MAC address has no value to the receiver.

Doubt

Last piece of FUD I want to cover, is that we are wasting address space, and the doubt that we'll have to go to yet another version of IP in a few years.

• While it is true a /64 for every subnet seems like a lot of IP addresses per subnet, it is a change in the paradigm we have been living with in IPv4. Rather than tightly packed subnets, where an attack is easy, since there is a good chance when guessing an IPv4 address that there is a host there, the /64 creates a sparsely populated subnet, where it is hard to guess an IP address, and therefore harder to launch an attack (assuming one gets past the firewall, or it is an inside job).
• There are enough addresses to give out a /56 to everyone. Yes, the IPv6 address space is that big. RFC 7421 is a good read on IPv6 address space. With the currently allocated 2000::/3 there are over 10 trillion /48 to be allocated. And that is less than 1% of the total IPv6 address space.

IPv6 has matured, and is ready

IPv6 has matured a lot since 1995 (RFC 1883). Over 10% of internet traffic is over IPv6 today. Large deployments, such as the huge server farms at Facebook at using IPv6. Lessons have been learned, the protocol has been improved. It is time to move past the IPv4 thinking, and start learning, deploying, and using IPv6. After all, it is the future of the Internet.

systemd: Ubuntu 16.04 better, not best

by Craig Miller

Sure other Linux distributions have already released versions with systemd. But just last week, Ubuntu, one of the most popular distros released XenialXerus aka 16.04 LTS with systemd integrated. Actually Canonical has been phasing in pieces of systemd for some time. But with the release of 16.04 LTS, the networking component (systemd-networkd) has been enabled.

A quick look of the new releases reveals that Canonical has been following the evolution of systemd, and made sure they had a recent version (229). That is only one behind the current version of 230. Considering they did a code freeze two months ago, that is pretty good.

What IPv6 issues remain for this long term release of Ubuntu?

Referring to the list from systemd: oh, you wanted to run IPv6? post, the folks at Canonical have fixed:

• Temporary addresses (RFC 4941) are broken from version 224 to 228 (systemdissue#2242) this was actually fixed in v229, and I suspect this is why Ubuntu went with v229.
• Interface disable/enable IPv4 will reaquire and address, but IPv6 will not (other than link-local), and will remain address-less until restarting networkd (systemd issue #2912)
• SLAAC address does not conform to RFC 4862, using EUI-64 (fixed in version 230)

What is NOT fixed?

• IPv6 RA flood (THC flood_router6) causes network disconnection even after flood ceases (systemd issue#2977)

The behaviour of the RA flood is better than the current version 230, as Ubuntu server isn't disconnected, but the route table is flooded, and the "real" default route is lost, causing the server to lose IPv6 connectivity to anything off-net (like the internet). Even after the RA flood is stopped, and real RAs are heard from the real router, the default route is not inserted, and the server remains crippled. The only method to recover, is to reboot the server. Not the nicest thing to do, especially if the server is in production.

I haven't tested the virtualization issues, but I am hopeful that they have been improved by Canonical as well.

So where does this leave us?

I stand by my recommendation. systemd, and specifically systemd-networkd is not ready for IPv6 production systems. That said, it is certainly good enough for testing and development systems, giving you valuable experience towards your IPv6 deployment.

systemd: oh, you wanted to run IPv6?

by Craig Miller

Oh, you wanted to run IPv6?

Regardless of what you think of systemd, it is coming to a Linux computer near you. But what has systemd done for IPv6? The short answer is that it has replaced, superseded, supplanted, the mature kernel IPv6 code with new less mature, more buggy application layer code. For reasons unknown to the author, systemd has decide to take over mundane operations, such as setting up SLAAC addresses, Temporary addresses, and IPv6 routes, rather than allowing the kernel to continue these operations.

That said, since your Linux system will be (or is) running systemd, it is good to know the issues, and how to test them.

How do you get your IPv6 prefix?

Smaller organizations and home users will use PA (Provider Assigned) addressing. Depending on how much you pay your ISP, your prefix block could be changing dynamically. As a new prefix is delegated, SLAAC (Stateless Auto Address Config) will automagically renumber the hosts on your network.

Larger organizations will apply to their RIR (Regional Internet Registry) such as APNIC (Asia), RIPE (Europe), or ARIN (North America) for a PI (Provider Independent) block of addresses.

Know your environment

The first place is to understand your network environment. Large Enterprise has embarked on the road of using DHCPv6 in an attempt to limit the number of IPv6 addresses assigned to each host. In order to increase the ability to track users, and make building ACLs (Access Control Lists) more easily. DHCPv6 is also the preferred method used by IPAM (Internet Protocol Address Management) software, as it makes host discovery easier.

Smaller organizations may opt to use SLAAC since it is pretty much plug and play. Unless you have Windows machines on your network, then you will need to run DHCPv6 at a minimum for DNS server information distribution (see Dual Stack: the good, bad, and the ugly).

Write a Test Plan

What ever environment you are using for address distribution to your hosts, a test plan in a lab setup is always a good idea. A sample set of tests you may want to run:

• Basic Testing
• disable/enable interface
• Restart systemd-networkd, are IPv6 addresses restored?
• Virtual Machine (VM) and Container Testing (if you are using virtualization)
• Negative testing/network attacks, such as RA flood (THC IPv6 is an excellent tool)
• Rogue RA Testing (no, RAGuard will not stop this attack)

A few 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 (systemd version 229).

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

Upgrading to systemd distros

Be careful when upgrading your systems which may have not been running systemd before, when all the issues above worked just fine since they were implemented in the kernel*. Examples of OS changes which introduce systemd are from RHEL 6 to 7, CentOS6 to 7, Ubuntu 14.04LTS to 16.04LTS, and Debian 7 to 8 (aka Jessie). More systemd adoption info can be found on Wikipedia.

Time will improve systemd

Like fine wine, I am sure that systemd will improve IPv6 support. After all, it took years to get where we are with the Linux kernel support today. Reviewing the issues above to see if they apply, and having a test plan, will allow you to go into IPv6/systemd with your eyes wide open.

Given the number of IPv6 issues, I would not recommend putting a systemd machine into an IPv6 production environment at this time. But perhaps you can lean on your distro provider to correct the issues which apply to your network, and we will all benefit.

Update Nov 2016 (see IPv6 & Systemd another look)

*DHCPv6 has not been implemented in the kernel

Dual Stack, the good, bad, and the ugly

by Craig Miller

Dual Stack: a foot in the past and the future

There have been several transitional methods developed to help us through the transitional phase of migrating from IPv4 to IPv6. Remember that although IPv6 has the letters I and P in it, it really is a different networking protocol, and therefore requires additional expertise to really know the new Internet Protocol.

Fortunately, the common operating systems, Windows, MacOS X, Linux, and BSD have excellent support for IPv6. And can run both IPv6 and IPv4 at the same time. This is called Dual Stack.

The Good

Because OSs are bilingual (think Canada:  English and French) there is little to be done on end stations or hosts, to start communicating via IPv6. Assuming the network is correctly configured with RAs (Router Advertisements), the host will pick up and address either via SLAAC (Stateless Address Auto Config) or DHCPv6 (yet another different protocol) and off you go.

Dual Stack has been suggested as the easiest transitional mechanism, since it is already built into almost every machine out there. Of course some applications may have to be rewritten to take advantage of the IPv6 stack.

The Bad

Because hosts are now dual stack does not mean that all applications which run on the hosts are instantly dual stack. There are a lot of applications which were either written a while ago, or by someone who didn't give thought to IPv6.

For example, sshd has supported IPv6 for more than a decade. But recently when I went looking for a sftp client for my Chromebook, I was disappointed to discover that 'SFTP File System' was IPv4 only.

Dual Stack also means double the work for Network Support people. Because although the end station or host, automagically configures itself for IPv6, the routers and firewalls do not. Routers need to be configured for two protocols, which may not have a direct mapping between IPv4 and IPv6. Firewalls, must have two sets of ACLs (Access Control List) and because IPv6 is a different protocol, one can not just copy and paste the IPv4 ACL entries into the IPv6 ACL.

For this reason large service providers such as T-Mobile are dumping dual stack in favour of going IPv6 only, and using technologies like 464XLAT ( RFC 6877) to accommodate those IPv4 only applications (such as Skype and Twitter).

The Ugly

Although I said that end stations or hosts automagically get addresses, and they do, there are apparently different interpretations on how the end station receives DNS (Domain Name Service) server information. You will remember that I mentioned in a previous post, Quad Eh? that DNS was going to be even more useful with IPv6.

There are two ways for a host to receive DNS server information:

1. RA via the RDNSS field (Recursive DNS Server RFC 6106)
2. DHCPv6 via option 23 (IANA option numbers)

Unfortunately, not everyone agrees on which method to use*. Google (read: all android phones) is using the first  method and Microsoft (read: all windows machines) is using the second method. Which means that network operators must run a DHCPv6 server even if they don't want to manage addresses (think: the O-bit in the RA). Although larger networks will probably already be using (or plan to use) DHCPv6, for smaller networks, this is just additional overhead.

A Path to the Future

As you can see Dual Stack solves many problems in transitioning from IPv4 to IPv6, but it is not a panacea. As I mentioned in an earlier post Not your Grandmothers IP, there is no time like the present to start learning the new Internet Protocol, and putting a foot towards the future.


* more good info on Dual Stack https://ttlexpired.co.uk/author/richardpattersonnz/

v6Brouter Part 2: v6Bridge Firewall

by Craig Miller

In the last post (see NATiness and the v6Brouter), I introduced the concept of a v6Brouter, part bridge, and part router. Bridging IPv6 is a good way to extend already allocated IPv6 networks (e.g. a /64 already allocated by an upstream ISP) to overcome networks segmented by  IPv4 NAT. But typically bridging does not include any kind of firewall. After all, bridging is simple, just doing a MAC DA lookup, and sending the packet on its way.

But although you may want to extend the IPv6 network, you may not trust all those unknown hosts upstream. It would be nice to have a v6Bridge Firewall.

Netfilter to the rescue

Fortunately the creators of Netfilter (better known as iptables, and ip6tables on Linux) created a layer 2 filtering tool called ebtables. With ebtables, it is possible to inspect bridged packets and forward them as we saw with the v6brouter, or send them up the stack to be inspected by ip6tables.

Challenges to ip6tables when bridging

A challenge of ip6tables when bridging (IPv6) is that it thinks all packets come from the bridge interface (br-lan on OpenWRT). This makes it difficult to filter upstream packets, but allow your trusted downstream packets to pass unfiltered.

The concept of Mark

Fortunately Netfilter created the concept of mark, where a packet is marked with a number (uint32). It is possible to mark a packet (with set-mark) and later filter on that marked value. Fortunately, ebtables and ip6tables share the same mark value.

Solving ip6tables challenge

Since ip6tables can't distinguish which port a bridged packet came from, and ebtables can, it is a simple task of having ebtables mark a packet that comes from the upstream port, and then later having ip6ables filter on that marked value of the packet.

Tying it all together

Now that is is possible to mark a packet at L2 ingress port, and then read the marked value at L3, it is possible to create a v6Bridge Firewall. Here's a diagram which explains the path of a packet in a v6Bridge Firewall.

v6Brouter with v6Bridge Firewall

For example, let's say you want to filter SSH from the outside, but permit the inside network (the extended trusted network) to be able to SSH to the outside and the internet. Or to put it another way, block incoming SSH, while allowing outbound SSH.

The v6Bridge Firewall inspects the packet at ISO layers 2, 3, and 4.

• Layer 2 - Check ethertype for IPv6, check ingress port, if outside network, mark packet with the value of 16
• Layer 3 - Read marked value, if 16, go to L4
• Layer 4 - Check if the destination port = 22 (SSH), if so drop, if not forward to L2
• Back at Layer 2, Check MAC Destination Address, and send out correct port

All of this happens in the blink of an eye*. Netfilter is highly optimized code running in kernel space. Without hardware support, it would be difficult to find faster code.

v6Brouter and your Firewall too

The v6Brouter project (on github) now includes v6bridge firewall. When extending your IPv6 network across all those cascaded IPv4 NAT situations, you can now have your bridge and firewall it too.


* Running thruput tests on OpenWRT with and without firewall enabled using netcat over IPv6/TCP transferring a 100MB file  yielded no appreciable difference at 100Mbit speeds.

NAT-tiness and the v6Brouter

by Craig Miller

OpenWRT supports over 1000 routers*

IPv4 NAT (Net Address Translation) is everywhere. It has become the default small network deployment method. Want to cascade a second router on your network, use NAT. Want to create a hotspot on your phone to share your internet, use NAT.

How can IPv6 be widely deployed when there are so many niche deployments of NAT breaking end-to-end network connectivity everywhere? In large scale networks, there are plenty of IPv6 addresses. Prefixes are delegated or assigned, and standard routing is performed. But in smaller networks, where only a /64 was allocated, how do you provide connectivity to the downstream cascaded network, or the smart phone hotspot?

Brouters 101

A solution to the lack of IPv6 prefixes is to use a brouter. A brouter is a part bridge (operating at layer 2 of the OSI model) and part router (routing at layer 3).

In a traditional IPv4 network, a cascaded router would look like this:

IPv4 NAT-ed networks

Packets from the laptop must flow across double NAT to reach the internet. The green networks (dark and light) may be wired or wireless. I see this a lot.

By changing the configuration of Router B, to be a brouter, we see that the IPv6 topology no longer directly maps to the IPv4 topology.

Brouted network with a single (blue) IPv6 prefix

By using a Brouter, IPv6 traffic (including RAs, NDP, etc) is bridged on Router B, while IPv4 traffic continues to be NAT-ed, maintaining the IPv4 topology. Of course there is no reason why IPv4 needs to be NAT-ed at this point, but there are situations (think: smart phone hotspot) where maintaining the existing IPv4 topology will be desired. v6Brouting allows the maintaining of the IPv4 topology, while providing IPv6 access to the downstream networks.

Brouter Advantages

The advantage of using and IPv6 brouter is that it does not require any special protocols from the upstream router (think: prefix delegation), nor does it require the upstream ISP to provide anything more than a /64. As we saw in a previous post, Think Networks Think Big, a /64 has plenty of addresses to extend to small scale subtended networks.

OpenWRT the open source router

OpenWRT is open source software supporting over a 1000 different routers. It includes a daemon, odhcpd, which handles DHCPv6 services on the LAN side. It also has a RA and NDP relay mode which essentially bridges IPv6 traffic across the router. However this occurs at the application layer, and performance suffers because of it.

Another solution to extend the IPv6 /64, is to use the optimized linux bridge code in the kernel to bridge the IPv6 packets. This code is part of the widely deployed netfilter code (think: ip6ables on Linux). Netfilter not only has layer 3, or network layer filtering capability via iptabes and ip6tables, but also layer 2 filtering via ebtables.

v6Brouter config tool

I have written an open source script which leverages netfilter and configures a v6brouter for OpenWRT (v15.05) which can be found on github.

Bringing IPv6 to the isolated masses

In order to have ubiquitous IPv6, we must get through a nasty transition phase, which includes getting past the many, many cascaded NAT deployments. The v6Brouter can bring IPv6 to many of those isolated small networks.




* WRT54G image: By G sintornillos - User generated content., Public Domain, https://commons.wikimedia.org/w/index.php?curid=11231198

Think Networks, Think Big

by Craig Miller

Break with the Old Thinking

IPv6 is not only a different protocol than IPv4, it is a different mindset. We have been trained (in the IPv4) world to conserve address space, change subnet masks to the be the smallest amount of addresses for a given subnet, make point to point links /30, and so forth. We have become ingrained with a subconscious frugality about address space.

Grains of wheat on a chessboard

The designers of IPv6 knew the power of 2. Just like the "wheat and chessboard problem" where the number of grains of wheat (some say rice) double with each square on the chess board, the amount of wheat becomes enormous rather quickly, so does the IPv6 address space.

How big is the IPv6 address space? One of the better comparisons I have heard is that if the entire 4 billion IPv4 addresses were equal to a meter in length (think: yard stick), then then the IPv6 address space would be 35,970,651,894,390,958,082,809 light years long! it is a really, really, really big address space.

Sparsely Populated Networks

IPv6 has plenty of addresses. So many in fact, that no one living today will ever see us run out. There are 
18,446,744,073,709,551,616 per /64 subnet. I am not suggesting you try to put 18 quintilian hosts into a single subnet, but part of the transition to IPv6 is from densely packed subnets (IPv4) to sparsely populated ones.

This has an immediate advantage that port scanners, like nmap, will take weeks (or longer) to scan a single subnet. New methods of attack will be developed, but sparsely populated subnets will be the rule in IPv6, not the exception.

Think Networks, think big

We must change our mindset from conserving address space, to how many networks do we need. In a Class B network, where all subnets are /24, it is possible to have 255 subnets. When I was working for the University of Hawaii in the 1990s, they ran the entire University off of a single Class B network where even the point to point links were /24.

With IPv6, the standard subnet is /64. Change this at your peril. Many things stop working, like SLAAC when the prefix is not /64. So taking the /64 as the base line, how many /64's do you need for your office/enterprise/university campus?

It is not uncommon to get a /56 from your ISP. Shoot, I have a /56 at my house. Yes, that is 255 /64 networks. I don't currently need that many networks at my house, but it certainly gives me room to maneuver. 

When applying for a Provider Independent prefix (say from ARIN or RIPE), the RIR (Regional Internet Registry) will typically give you a /48, /40, or even a /32 if you can justify it. How big is a /48? That is 2^16, or 65,535 /64 networks.

Address Planning

So remember, that when creating your address plan for IPv6, don't just overlay it on top of your IPv4 network, laying down subnet over subnet. When creating the IPv4 network, you were in a different mindset, conserve addresses, that no longer applies. But that said, how many subnets do you have in your network today? 200, 2000, 100,000? You can use this a starting point of how many IPv6 networks to request from your RIR.

Count networks, not hosts. You won't have enough hosts to exhaust a single /64. But there are very good reasons to have multiple networks, DMZ, segregation of departmental data, internal cloud, etc.

Wasting addresses

You wouldn't waste things of value (think: dollars, or a Rembrandt). But if the item has little or no value, then it isn't considered a waste. Would you pick up a penny on the street? If so, then you are still thinking conservation of pennies (or addresses).

If you think using a /64 on a point to point link is a waste, then you haven't completed the mental transition from conservation of address space to thinking of networks. Using /64s everywhere, even on point to point links make everything simpler.

Getting back to simpler times

If you are old enough to remember running RIP (Routing Information Protocol RFC 1058) networks, you will remember that we ran /24 networks everywhere (since RIP1 didn't support variable subnet masking). It was a simpler world, and we have an opportunity with IPv6 to get back to that simplicity.