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