IPv6 PD in the SOHO

IPv6 has no need for NAT, however, there is a need for a Globally Unique Addresses (GUAs). Therefore your SOHO (Small Office/Home Office) will require a block of GUAs to use. You can either obtain the Block of GUAs from your RIR (Regional Internet Registry, e.g. ARIN for North America and Hawaii), known as PI (Provider Independent).

Or you can use a block of GUAs from your ISP, known as PA (Provider Addresses).

I suspect for the foreseeable future, SOHO will obtain IPv6 addresses from their ISP (or PA Space). PA space is much easier for small organizations which do not have full time IT staff.

Although PI address space has its advantages, such as no address renumbering when changing ISPs, it requires a more sophisticated setup, usually including BGP (Border Gateway Protocol) peering with an ISP.

Prefix Delegation is a method where the ISP will “loan” you some PA Space to use inside your network. Prefix Delegation RFC 3633 standardized the allocation of a block addresses back in 2003. The standard has been updated by RFC 8415 in 2018.

In this article, we’ll pose the following questions, and hopefully provide some answers:

• What are the basics of Prefix Delegation?
• What if you have more than one router in your SOHO network?
• How is IPv6 Prefixes allocated within your network?
• Why use OpenWrt in your SOHO network?
• What if your ISP asks you to power cycle your main router? What happens to the other routers?
• Can deterministic PD address blocks be created with with OpenWrt?
• Can you create redundancy (or loops) in your network with PD?

Prefix Delegation Basics

Prefix Delegation is implemented as an option within the DHCPv6 spec in RFC 8415, as Option 25 (OPTION_IA_PD). Therefore, DHCPv6 must be used between the router and the upstream device (e.g. ISP router). Once the Delegated Prefix has been allocated by the ISP, the router will apply the Prefix to the internal LAN, hosts on this LAN segment will use the Delegated Prefix to create their own IPv6 GUA (Globally Unique Addresses) using SLAAC (Stateless Address Auto Config), or by making their own DHCPv6 request. Either way, the Hosts on the LAN will have a GUA and can get onto the IPv6 Internet.

Prefix Delegation in a more complex SOHO network

What if you have more than router in your SOHO netowrk? How is IPv6 PD allocated within your network?

Let’s take the following example network with four (4) routers and six (6) netowrks:

Fig 1: Example Network

Just like above, the WAN Router made a DHCPv6-PD Request to the ISP for a block of IPv6 addresses. The ISP will usually allocate a /56* which can be subdivided into 256 /64 networks. Should be plenty of room.

In the network above, the WAN router has multiple ports, which have been divided into three (3) Networks (Net A, Net B, Net C). These networks may have different purposes, and firewall access rules (such as Production, Printer/IoT, DMZ).

In turn each of the first tier routers (Router A, Router B, Router C) will make DHCPv6-PD request to the WAN Router, and each receive a smaller chunk of the original /56 allocated, to be used downstream (Net Aa, Net Bb, Net Cc).

As you can see Prefix Delegation continues to slice and dice the original /56 in smaller and smaller chunks supplying IPv6 GUA address space downstream.

Prefix Delegation implemented in OpenWrt

Why use OpenWrt in a SOHO environment?

• Supported on over 1000 home-class routers
• Inexpensive solution with excellent IPv6 support
• Includes a consistent web-based GUI for configuration

OpenWrt Prefix Delegation address allocation has its roots in HomeNet RFC 7368. Using the basic algorithm: PD Address Space / Number of LAN Ports = block size per port.

Most home routers have 4 LAN ports, so that a /56 will be divided into /60s to be allocated to the first tier of routers (Router A, Router B, Router C). Each of the first tier routers will in-turn have 4 LAN ports, and allocate 4 x /64 out of each /60.

Fig 2: Example Network sliced and diced

Now let’s apply some addresses, assuming the ISP has delegated a /56 to our SOHO network.

Fig 3: Example Network sliced and diced with addresses

In Figure 3, the ISP Delegated Prefix is 2001:db8:aaaa:bb00::/56 which leaves the last two (2) nibbles (or hexidecimal characters) to be used inside the SOHO network. It is best practice to divide prefixes no smaller than nibble (4 bits). It will make things much easier for you going forward.

OpenWrt will create four (4) blocks of IPv6 addresses from the original /56 and allocate them to each network downstream. In our address example (Fig 3), the blocks would appear as:

2001:db8:aaaa:bb00::/60
2001:db8:aaaa:bb40::/60
2001:db8:aaaa:bb80::/60
2001:db8:aaaa:bbC0::/60

These blocks would in turn be sub-divided by each of the first tier routers (Routers A, Router B, Router C), so that Router A would create another 4 blocks:

2001:db8:aaaa:bb04::/64
2001:db8:aaaa:bb08::/64
2001:db8:aaaa:bb8C::/64
exhaused

And Router C PD blocks would be:

2001:db8:aaaa:bb84::/64
2001:db8:aaaa:b488::/64
2001:db8:aaaa:b88C::/64
exhaused

As you can see there is not enough address space in the /60 to create four (4) /64 address blocks since the Zeroth block (e.g. 2001:db8:aaaa:bb00::/64) has already been allocated.

As you can see Prefix Delegation within your SOHO using OpenWrt makes creating new networks a plug-and-play operation. However, it is not overly efficient with address space.

Prefix Delegation and Routing

What is not obvious, so far, is that not only does Prefix Delegation allocate address blocks down stream, but the router must also insert a route for each PD block allocated. With OpenWrt, this is done automagically for the user. Each tier 1 router will have a default router pointing upstream (toward the WAN Router) and a specific route for the PD block downstream. When the DHCPv6 lease is allowed to expire (e.g. the downstream router was removed), the downstream specific route will be removed.

Power Cycling your Main Router

But what if your ISP suggests you turn your router off and on again (a common refrain of the IT crowd). Since DHCPv6-PD is stateful, all memory of that state will be lost.

Should the WAN Router be power cycled, it will no longer know about the DHCPv6-PD arrangements previous made, and no longer have the PD specific downstream routes. In other words, this will be a bad thing. If you are running a network like Fig. 3, it is best to power cycle routers A, B, and C as well, so they will initiate a new DHCPv6-PD request from the WAN Router, and re-establish the PD address blocks, and specific downstream routes to the tier 1 routers.

Oh, and your address prefix delegations may change

You dutifully power cycled your WAN Router, and tier 1 routers, only to discover that your DNS queries (you are running DNS, right) are replied with the wrong addresses.

There is no guarantee that the LAN ports on the OpenWrt router will come up in the same order as they did before the power cycle, and your /60 may have moved from one port to another (e.g. Router C now has prefix 2001:db8:aaaa:bb40::/60 instead of 2001:db8:aaaa:bb80::/60. This is not only irritating, but can turn a simple action into a bad day

Leveraging PD but with more deterministic address blocks

Fortunately, the devs of OpenWrt create an easy solution to the non-deterministic PD blocks assigned to the downstream ports in the form of a ip6hint. On the WAN Router, enter the ip6hint via the web-based GUI, navigate to Network->Interface->Your interface->Edit->IP6hint

Save and Apply, and that interface (in Fig 3, connected to Router B) will always use 2001:db8:aaaa:bb40::/60 for prefix delegation. No change needs to be made on Router B itself, since it is receiving the PD from the WAN Router.

Of course, like any linux system, ip6hint can be configured in the /etc/config/network file as well with lines like:

config interface 'DMZ'
    ...
    option ifname 'eth0.3'
    option ip6assign '60'
    option ip6hint '40'
    option mtu '1452'

Then restart the network to apply the change of the configuration file

/etc/init.d/network restart

Networks with loops/redundancy

What if you wanted redundancy in your network? What if Router B went down, or you wanted to upgrade it to the latest OpenWrt? You would want some resiliency or redundancy to your network.

For example by adding yet another router (Router D) to the network, both Network Aa and Bb would have an alternate path should Router A or Router B run into a problem.

Unfortunately, DHCPv6-PD will not help you here. You will need to run a routing protocol such as RIPng. There are better routing protocols, but none so simple to configure. Just turn it on, and forget it, perfect for the SOHO environment.

Fortunately, OpenWrt supports RIPng via the bird routing daemon. To see how to configure it in OpenWrt please refer to RIPng the forgotten routing protocol

Summary: DHCPv6-PD is pretty much plug-and-play

As you can see Prefix Delegation is how each of your hosts in your SOHO network can use a GUA without the complications of NAT. DHCPv6-PD in its simplest form is plug-and-play. But your network may be a bit more complicated, as your business grows more complicated, and knowing how to stabilize PD address allocations will go a long way to keeping your network running smoothly while you concentrate on the more important parts of your business.

* ISPs can delegate blocks as large as a /48, and as small as a /64. /56 seems to be the most common allocation size.

* Originally posted on makiki.ca.

DNS makes it easy

The Modern Internet requires only two things of the internet user:

• IP address

• DNS (Domain Name Service)

What is DNS? A globally distributed and resilient database of names to IP addresses (both v4 & v6).

Why do we need it? Because the sheer number of websites and other services on the internet is too large for humans to memorize. It is much easier to name, than an IP address (this is especially true for IPv6).

In this article, we’ll pose questions, and provide answers to the following:

• How does a host get DNS? DHCP/RA

• What is DNS Search List, and how does it help?

• Captive Portals, redirecting DNS requests, how IPv4 and IPv6 are different

• Where is DNS resolved? Problems with DoH

• Using DNS on SOHO rather than IP addresses

• How to use local DNS and DoH?

Where does the address(es) for DNS server(s) come from?

We’ll assume you have an internet address (v4 and/or v6), but where does DNS come from?

Of course there is nothing stopping you from manually entering in an IP address for a DNS service. But in a larger environment, entering DNS manually gets to be about as much fun as entering IP addresses manually.

DHCPv4

Since the late 1990’s there has been an easier way than manual entry of not only IP addresses, but also the addresses of DNS servers, using DHCP (Dynamic Host Configuration Protocol). Not only will the DHCPv4 server provide good IP address info, but via the DHCP options, a plethera of other info can be conveyed to the requesting client, including the address of a DNS server.

DHCPv6

In 2003, DHCPv6 was patterned from DHCPv4. Naturally somethings had to be changed (e.g. the default gateway does not come from DHCPv6) because IPv6 made improvements over the old IPv4. But the concept of options remained, although the option numbers are different from DHCPv4. So it is possible for a DHCPv6 client to receive the IPv6 address of a DNS server via DHCPv6 options.

Router Advertisements (RAs)

Although getting an IPv6 address via SLAAC (Stateless Auto Address Coniguration) has been with IPv6 from the beginning (1998), the ability to convey a DNS server address was added later to the RA (2007). It became a standard in 2010, and was again revised in 2017 with wider deployment.

As part of the RA, the RDNSS option is transmitted, which has one or more IPv6 addresses of DNS servers the SLAAC client can use.

What if your host gets multiple DNS servers from different methods?

So it is possible to get a DNS server address from three different sources, DHCPv4, DHCPv6, SLAAC/RA. What if the DNS servers in each are different? How does a host determine which DNS server to use?

RFC 6731 mentions that the client must create a list of DNS resolvers, and consider trust in prioritizing them. And RFC 8106 states that DHCP should be preferred over RAs for DNS information. But how do Operating Systems (implementations of this standard) really behave?

And of course, it is good practice to announce (via DHCP or RA) the same DNS service. But what happens if your Pi-Hole announces itself (over DHCPv4) as the DNS server, but your router announces itself (over DHCPv6) as the DNS service? You ad-blocking service may seem flakey or not working at all. It is important to know how your OS will respond to different DNS services being announced to your host.

PvDs (Provisioning Domains) architecture (RFC 7556) is designed to help, in creating a single network-based configuration mechanism.

DNS Search List (DNSSL)

DNS Search List is a shortcut, or a method to save on typing long FQDNs (Fully Qualified Domain Names). For example, if I have servers in my house which have DNS names: nas.example.com, router.example.com, and music.example.com, without search lists I would have to type in the FQDN each time I wanted to access each server.

But with a search list of example.com, the DNS client will automatically append example.com to each of my queries. With this, I only have to type nas and the DNS client will do a query for nas.example.com

Getting a DNSSL

Like the address of the DNS service, DNSSL is distributed by similar methods, using DHCPv4, DHCPv6, and RA DNSSL option (RFC 8106 Sect 5.2 ).

Unlike the RDNSS option, having different search lists (from different sources) is less of an issues, since the DNS client will merely do multiple searches, appending the separate search list names looking for a response.

Unfortunately, not all hosts support DNSSL in the RA at this time. For example, ChromeOS ignores RA DNSSL option, and FQDNs must be typed.

Captive Portals and DNS

Captive portals are used in Airports, and coffee shops to ensure users accept the terms of the service before proceeding.

Have you ever given thought to how your device is redirected to a Captive Portal page, no mater what hostname you have entered? Again, it comes down to DNS. The Captive Portal advertises itself as the DNS server. Any request is replied to by one answer, the website of the captive portal.

Once the agree button has been tapped, then and only then will DNS answer requests with the real IP address of the requested host.

But what if you had a manually entered DNS server? Would you be able to bypass the Captive Portal? No, Captive Portals also have a forwarding table, and it isn’t populated until you “agree” to the terms.

DNS Redirection using IPv4 & man-in-the-middle-attack

Captive portals not only give one DNS answer in response to any DNS request, but they often also use Firewall rules and NAT to forward your DNS requests to their DNS server, regardless to what you have manually set your DNS server to be. It does this by creating a NAT rule, which is a man-in-the-middle attack on your DNS request. It allows the Captive Portal to pretend to be your preferred DNS server. This is part of the evil of NAT.

DNS Blocking using IPv6

Because NAT is Evil and is not used in IPv6, we can’t use the man-in-the-middle attack method of IPv4. But we can create firewall filters which block all DNS requests except to our IPv6 DNS server. In the IPv6 network, we distribute our DNS server address via DHCPv6 or RA RDNSS. If the end user attempts to use their own DNS server, the request will be blocked.

This is a simpler solution which does not require spoofing the users DNS server.

Getting around DNS redirection/blocking with DoH

DoH (DNS over HTTPS, RFC 8484) is a recent addition to the DNS landscape. Why would you want to use DoH? From RFC 8484

These use cases are preventing on-path devices from interfering with DNS operations

However DNS involves a certain amount of trust. Trust that you will receive an unbiased and correct response to a DNS query. As you have seen DNS Redirection breaks that trust by masquerading the Captive Portal DNS server as the one you thought you were using.

By using a DoH service, such as Cloudflare or Google, you are trusting that that corporation will always provide an unbiased and correct answer. Since they are private corporations, this may not always be the case (imagine Google providing you a better website for the info you are seeking than the one you requested)

DoH and local DNS

The difficulty with DoH is that it is a direct connection to the service and bypasses any opportunity to have your local names resolved. This means you can’t get to your NAS by name, which is a step backwards.

This can cause confusion as to the exact nature of the problem, since many confuse the lack of a DNS response with broken network connectivity.

SOHO: Using local DNS names rather than IP addresses

With the addition of more devices on the local network, and the addition of IPv6, it is time to start thinking about using DNS in the SOHO (Small Office, Home Office). As mentioned earlier, humans remember names more readily than numbers. Therefore assign names to your devices, and reference them by name rather than by number.

There are a couple of methods to creating DNS in the SOHO.

• The old fashioned way, manual entry into a DNS Zone file

• Automatic Dynamic DNS record creation (preferred)

Most modern SOHO routers have a DNS server built in. Using OpenWrt, DNS names will be created when the device does a DHCP request (with the name option). For those hosts which support DHCPv6, Dynamic DNS names will also be created.

There is even software which runs on OpenWrt which will automatically assign names to your SLAAC-only (think: Android/IoT) devices.

With local DNS, you can now access your network storage by name nas or your printer printer. When you upgrade your printer, you only need update the DNS entry, and all your computers will be able to print to it.

Local DNS + DoH = OpenWrt

What happens if you are concerned about DNS privacy, and want to run DoH and have the convenience of Local DNS? If you run OpenWrt on your SOHO router, you can do both!

OpenWrt can serve as your local DNS server, and will make any external DNS requests via DoH to your preferred provider (e.g. Cloudflare, Google, etc).

DNS, it is a good thing

DNS is an abstraction layer that was created in the 1980s to allow the internet to grow and expand beyond our limited memory of IP addresses. Much has changed in how a host gets the address of a DNS server, but the usefulness of DNS, even on the local network (including IPv6) has made the internet easy.

Orignally posted on makiki.ca

Distributed to Centralized

How has IPv4 been able to continue to carry the majority of Internet Traffic (about 69% as measured by Google)? The quick answer is NAT (Network Address Translation), but there is more to it than that. Now we see multiple layers of NAT (e.g. at the home router, ISP, etc).

Fundamental shift of how the Internet works

Because of the limitations of reverse traffic of NAT, there has been a fundamental shift in how we use the internet. Rather than anyone putting up their own webserver and doing peer-to-peer connectivity, servers and services have become centralized in the Cloud, and we access them via a browser (as a client) behind several layers of NAT.

Old becomes New

Computing has, of course, been through this centralized stage before. In the early days, machines were expensive, and terminals were relatively cheap. So a big computer (mainframe, Unix machine, etc) would have many terminals, a client/server centralized architecture. Computers were the scarce resource, so we conserved the few, and hung many terminals off of them.

Fast forward to today

Since it was stated in 1994 that we were going to run out of IPv4 addresses (RFC 1631), the Internet has been slowly shifting to conserve the scarce resource, IPv4 Addresses. And with that the internet shifted to the few services with real IPv4 addresses, and lots of clients behind layers of NAT.

But won’t we run out of IPv4 some day?

Yes, but it is going to take much longer than anyone thought. Because NAT uses the TCP/UDP port numbers as an extension to the address space. By including the TCP/UDP source port (16 bits) + the IP source address (32 bits), it creates a virtual 48 bit address. In a NAT-ed world, we aren’t limited to 32 bits (4 billion) addresses any longer.

With the current Centralized model of the Internet, there is no rush to move off of IPv4.

Cyclical Centralized/Decentralized Fashions

But just like in the 1980s, when the PC was appearing on everyone’s desktop, the Centralized model of computer changed to a decentralized model. It didn’t change because the Big computer manufacturers sold little computers, it changed because people found they could do things with their desktop computers that they couldn’t do (or was too expensive to do) with a Terminal connected to a Big Computer.

IPv6 can also support a decentralized Internet model

IPv4 with TCP/UDP port bits, will give IPv4 a long life, but from now on, it will always be a centralized (in the cloud) model.

IPv6 can also run in the centralized (cloud) model as well. But it can also support true peer-to-peer, or decentralized, networking model as well.

I expect there will be a transition back to a decentralized Internet, because what was old becomes new again, and people will find it better for some application. A current peer-to-peer example app is BitTorrent which is used among other things, to distribute Linux distros. It works best on a peer-to-peer internet.

Once developers realize that a peer-to-peer model might work better for their application, we will see a shift to the technology which supports it, IPv6.

* Animated GIF visualizations
originally appeared on makiki.ca

EdgeRouter X and IPv6

The year is 2020, IPv6 has been a standard for over 22 years. And amazingly enough, there are still networking products which aimed solidly at the IPv4 customer, such Ubiquity.

I bought the Ubiquity EdgeRouter X, thinking it would be a nice addition to my IPv6 Test network. Basically it is a five (5) port GigE router (with eth0-eth4). It had a wonderful specifications list, supporting many features I recognized, and some I even planned on using, like RIPng.

Basic Specs of the EdgerRouter X

The Ubiquity Spec sheet is impressive, including five GigE ports, and a 4 core MIPS CPU with 256 MB of RAM. Here’s some of the following of what the EdgeRouter X supports right out of the box.

Lots of protocols to keep an old Bay Networks person, like myself, busy for some time.

EdgeRouter X and IPv6 Support

The EdgeRouter X is the bottom of the product line for Ubiquity. After all, it only costs $60 USD on Amazon. And it does have impressive IPv6 support. But the catch is that one must use the CLI to configure IPv6. The web interface is nearly totally devoid of IPv6 configuration and operational status.

Having worked in product development, including software development, and CLI design, I can see many of the challenges the designers had with creating a cohesive interface. For example, do you add a router protocol (such as RIPng or OSPFv3) to a port, or do you add ports to the routing protocol? Ubiquity decided to split the difference, and add some config to the ports and other parts of the config to the routing protocol.

Little IPv6 seen in the GUI

Unfortunately, the Web Interface is lacking in IPv6 support. For example, here is the Routing tab. And this router has RIPng running (configured via CLI) with plenty of IPv6 routes.

To be fair to the Web GUI, there is a Configuration Tree in the GUI, that basically maps the CLI into a tree, where IPv6 protocols can be configured:

DHCPv6-PD

Although the CLI looks like it will support DHCPv6-PD, I was unable to find success attempting to configure a /60. I repeatedly got an unhelpful error “64 + 4 + 64 prefix too long” (which of course exceeds 128 bits of IPv6).

OpenWrt to the rescue

Although the dazzling list of supported protocols was enough for me to purchase the EdgeRouter X, the really nice part, is that the little capable router is also supported by OpenWrt, which does have excellent IPv6 support.

Typically the steps to upgrade a OpenWrt supported router is:

1. Download the “factory” install image from the OpenWrt website to your laptop
2. Log into the router, and find the software upgrade section (different for every router manufacturer)
3. Upload/Upgrade the router with the OpenWrt software
4. Log into the router, and enjoy OpenWrt

Upgrading the EdgeRouter X to OpenWrt was not quite as simple as other routers. Unfortunately Step 3 fails. The EdgeOS upgrade screen will not accept the latest OpenWrt “factory” install image.

Fortunately, the open source community has not only created steps, but an OpenWrt image which will be accepted by EdgeOS.

The Steps to upgrade the EdgeRouter X becomes:

1. Download the interim tar file image from open source community to your laptop.
2. Log into the router, and find the software upgrade section (Under System->Upgrade System Image)
3. Upload/Upgrade the router with the interim OpenWrt software

Half way there

The router will reboot, and have a default address of 192.168.1.1 with no password (the default for OpenWrt), and no GUI. There is also a default ULA address, if you only have IPv6. The router will send an RA with a ULA* prefix, such as fd45:1373:e6bd::/48 The router will have the ::1 address. In my example, router address was fd45:1373:e6bd::1, which you can ssh to.

But that only gets a minimal OpenWrt snapshot running on the EdgeRouter X. In order to finish the upgrade, one has to download the v19.07 Upgrade image from OpenWrt to your laptop, then connect to one of the ethernet LAN ports (eth1-4), and scp it over to the router’s /tmp directory.

scp openwrt-19.07.2-ramips-mt7621-ubnt-erx-squashfs-sysupgrade.bin 'root@[fd45:1373:e6bd::1]/tmp/'

Log into the router via ssh using the IPv4 or IPv6 default address.

ssh root@fd45:1373:e6bd::1  #use your own ULA prefix here
cd /tmp
sysupgrade openwrt-19.07.2-ramips-mt7621-ubnt-erx-squashfs-sysupgrade.bin

As part of the sysupgrade, the ssh session will disconnect, and the router will reboot.

Log into the OpenWrt Web GUI

After the reboot, you should be able to log into the OpenWrt Web Interface. In my case, I put the IPv6 ULA into the location bar in the browser (yes, the square brackets are required for a raw IPv6 address).

http://[fd45:1373:e6bd::1]/

And you will see that OpenWrt reports that the hardware is a UBNT-ERX (short for Ubiquity EdgeRouter X)

Tthe first port of the router is the WAN port (eth0), and if connected to an upstream Dual-Stack network, you will see that the EdgeRouter X has picked up an IPv6 GUA, and automatically requested DHCPv6-PD, and allocated a /64 to the downstream LAN ports (four right-hand ports eth1-4).

Performance

The EdgeRouter X has NAT forwarding hardware acceleration. This is an IPv4-only feature, but certainly useful in Dual-Stack networks. Using OpenWrt and HW NAT Acceleration enabled, it has been measured to have a blazing forwarding capacity of 846 Mbit/sec average, faster than the original Ubiquity software.

The software-only throughput is a respectable 643 Mbit/sec with all four cores pulling hard.

If you have a high speed Internet connection, this little high performance router is for you.

Summary

OpenWrt has excellent IPv6 support in its Web GUI, with reasonable defaults for obtaining an IPv6 address, delegating a Prefix, and IPv6 firewall rules.

The EdgeRouter X is a high performance home router for a low price. And fortunately, there is a choice to have excellent IPv6 support via OpenWrt.

* ULA (IPv6 Unique Local Addresses) begins with ‘FD’ followed by randomized 40 bits. OpenWrt follows RFC 4193 and automatically creates a ULA at install time.

Article originally appeared on Makiki.ca

Jitsi: IPv6 Enabled

In these times of Social Distancing, or more correctly physical distancing, the use of Video Conferencing has taken a big upturn. Unfortunately most of the commonly known solutions are still stuck in the past century by only supporting IPv4. Some apps like Zoom, don’t even work on an IPv6-only network.

But fortunately, there is a nice IPv6 enabled alternative called Jitsi. Some of the advantages are:

• Service is free with no time limit (unlike Zoom)
• No software download required, runs in a browser like Chrome/Chromium without plugins
• iOS & Android apps are available
• No login/account is required
• Works on IPv6 & IPv4
• Encrypted Streams using DTLS-SRTP
• Dial-in number available (NOT toll-free)
• Runs on Open Source Software (install on your own server if you like)

Jitsi also works quite well on an IPv6-only network, when using NAT64 to talk to an IPv4-only peer.

Jitsi Meeting in Tile-mode *

IPv6 Done Right

This is the way all applications should operate. The use of IPv6 or IPv4 is transparent to the users. If one user is on IPv4-only, then a peer-to-peer conversation will happen over IPv4.

Jitsi is also NAT64-friendly, still working when one peer is IPv4-only and the other IPv6-only. Unlike Zoom, which breaks NAT64 with hidden IPv4 addresses hardcoded built into the application.

Security

The video streams are encrypted using DTLS-SRTP. Jitsi operates in peer-to-peer mode when there are only two participants and automatically switches to using the Video Bridge when there are more than two.

In peer-to-peer, the entire video/audio stream is end-to-end encrypted. When using more than two, the streams are encrypted to the video bridge, decrypted and mixed, and then sent out encrypted (again) to the individual participants. And a new feature is in the works to use end-to-end encryption, even when going through the video bridge.

And unlike Zoom, Jitsi does not collect your personal data, or suffer the many other security issues of Zoom.

Securing the Video Conference

Of course, it is also possible to password protect the conference.

The Moderator (generally the person who starts the Conference) also has options to mute all, and even kick out unwanted participants.

Good Geeky Stats

And if you are interested in Statistics on how each participant is doing, there’s a handy cell-phone-strength meter in the upper left corner of each persons video window.

The information includes simple colour coding (green = good, red = bad), but also the bandwidth each peer is using, and frame loss. Pretty cool stuff.

Go Forth and Video Conference over IPv6

Jitsi is a full featured Video Conferencing Tool which has excellent support for IPv6 (and IPv4). Go forth and Video Conference using the free, IPv6-enabled, with no time limits, solution.

* Video Conferencing Photo and dialogues: from Jitsi Blog

*  Originally appeared  on www.makiki.ca

Google IPv6 Stats

Like many of us IPv6 advocates, I regularly visit Google IPv6 Statistics Page. Some have noted that over time, the increase of IPv6 users have tapered off, and others have predicted that IPv6 usage will not increase beyond 30%.

One can attempt to infer much from Google’s statistics, not always correctly. When I look at the graph, I see a little bump around the Christmas Holiday period. I’d like to think that is because people are at home more (taking time off the during holidays), and using their home IPv6-enabled connection, rather than their work/enterprise-ipv4-only connection to access Google. But even if my reason for the bump is wrong, it is clearly there, and one can see it for each of the years going back as far as 2013.

Size of the Internet is still growing

But just looking at Google’s stats doesn’t tell the entire story. It doesn’t show how the internet is continuing to grow. Another statistics site, Statistica.com, estimates the number of world wide users, where it can be seen that the size of the internet continues to increase.

Looking at the graph above, one can see a rather linear growth to the number of internet users in the world.

What is 30% of 4 Billion?

Because IPv4 Address space is limited to 4 bilion (2^32=4 billion), the growth in the internet will have to use IPv6 address space.

So what does the growth of IPv6 enabled users look like? What if we combine the data, looking at the Google Data for % of IPv6 Users, with number of Internet users.

Is IPv6 running out of steam (reaching an asymptotic line), or does it continue to grow?

As you can see from my simple graphing abilities (thanks to LibreOffice) that although the Google data appears to show the rate of IPv6 adoption is decreasing, the combined data shows that the number of people using IPv6 in the last 4 years have doubled!

IPv6 Users exceed the entire 2007 Internet

As John Curran, CEO of ARIN, said back in 2017, IPv6 will not take over overnight, in fact, there will be a “long tail” of IPv4 usage. But as you can see from the combined data, the millions of IPv6 users continues to grow, as the Internet grows. In fact, the number of IPv6-enabled users today exceeds the entire Internet population in 2007.

IPv4-only means slower delivery of data/services

If you are IPv4-only today, you will have to rely on someone else’s translation mechanism (NAT64/DNS64, XLAT464, etc) for those millions of IPv6-enabled users to reach your website. Translations services you have no control over. This means it will take longer for your pages to load, when compared to your IPv6-enabled competitors. Google, Amazon, and CDNs have shown that longer load time translates directly to reduced revenue (how long will your customers wait for your page to load?).

IPv6 is the future, it is 2020, the future is now

It is 2020, the beginning of the IPv6 decade. It is not too late. But it is time to get connected to the IPv6 Internet and reach those 1.2 Billion users out there who are already using IPv6 today!

Notes:

• Google IPv6 Data
• Statistica World-wide Internet Users Data
• *4150 million for 2019 is extrapolated

Originally published on www.makiki.ca

Christmas has come and gone, but the Christmas tree in the corner still has a few days left before we take it down.

On the IPv6 Internet (the “other” internet that the IPv4-only folks can’t see) there is an IPv6 Christmas Tree that can be decorated with your IPv6 pings.

By assigning 16 million IPv6 addresses to a single Christmas Tree, one can adjust the colours of the lights on the tree. According to the website:

2a05:9b81:2020::AA:BB:CC for HTML Color #AABBCC

There are many resources to convert colours to hex, but to light the lights red, one would ping:

ping -6 2a05:9b81:2020::FF:00:00

Because the tree doesn’t really have 16 million addresses assigned to the IPv6 stack, it will not reply, but you can watch a video of the tree and see the results of your pings.

So enjoy the last few days of 2019, and light the IPv6 Christmas Tree in your favourite colour.

IPv6 to the Rescue

Your embedded device has been running great for the past few weeks, and now all the sudden, it can’t be found on the network. You can’t ssh into see what the problem is, it has just disappeared.

Lots of reasons why this may have happened, perhaps the program hit a bug and crashed, or more likely, it has forgotten its IPv4 address. Sure you can just “turn it off and on again” and that may fix the problem, or it could make it worse, if it was writing out to the SD Card at the time you pulled power.

The real answer is to log in and find out what is really going on, but as I said, for some reason your Pi, router, or device isn’t responding. So what do you do?

IPv6 to the Rescue

But if you setup your network as a dual-stack network, then your device already has not only an IPv4 address, but also an IPv6 address as well. And if you put the IPv6 address into your local DNS, then you can just ssh to the hostname, and see what is going on with your device.

But what if you do have a dual-stack network (your ISP is providing IPv6) but you haven’t really done anything with IPv6. How can you use it to rescue your device?

ssh to the IPv6 address of the device, and Bob’s your uncle.

Finding the IPv6 Address of your device

Unlike IPv4 network scanners, scanning IPv6 networks is much more challenging. After all, instead of looking at 254 addresses, you are now looking to scan 18,446,744,073,709,551,616 or 18 quintillion addresses. Assuming that you use the fastest scanner zmap which claims to be able to scan the entire IPv4 internet (all 4 billion addresses) in 45 minutes. With 18 quintillion possible addresses, it is still going to take 367,719 years! (2^32 *45 min / 60 min/ 24 hours/ 365 days). And zmap doesn’t support IPv6 (and you can see why)

Fortunately, there are non-brute-force solutions to the problem.

IPv6 Basics, the all-nodes address

Although there is no broadcast in IPv6, there is a specific multicast address that all nodes must listen to. This is called the all-nodes address, or ff02::1. It is possible to send a ping to the all-nodes address, and get multiple responses back, similar to pinging the IPv4 broadcast address will (used to) return multiple responses.

$ ping6 -c 2 -I wlan0 ff02::1
PING ff02::1(ff02::1) from fe80::f203:8cff:fe3f:f041%wlan0 wlan0: 56 data bytes
64 bytes from fe80::f203:8cff:fe3f:f041%wlan0: icmp_seq=1 ttl=64 time=0.140 ms
64 bytes from fe80::2ac6:8eff:fe16:19d7%wlan0: icmp_seq=1 ttl=64 time=7.32 ms (DUP!)
64 bytes from fe80::21e:6ff:fe33:e990%wlan0: icmp_seq=1 ttl=64 time=7.66 ms (DUP!)
64 bytes from fe80::216:3eff:fea2:94e8%wlan0: icmp_seq=1 ttl=64 time=8.67 ms (DUP!)
64 bytes from fe80::ba27:ebff:fe89:bc51%wlan0: icmp_seq=1 ttl=64 time=9.60 ms (DUP!)
64 bytes from fe80::4aa2:12ff:fec2:16df%wlan0: icmp_seq=1 ttl=64 time=9.73 ms (DUP!)
64 bytes from fe80::216:3eff:feff:2f9d%wlan0: icmp_seq=1 ttl=64 time=10.6 ms (DUP!)
64 bytes from fe80::f203:8cff:fe3f:f041%wlan0: icmp_seq=2 ttl=64 time=0.686 ms

--- ff02::1 ping statistics ---
2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.140/6.814/10.696/3.840 ms

In IPv6, multicast addresses are associated with multiple interfaces (there is an all-nodes address on each interface), therefore it is necessary to specify an interface -I to ping.

OK, but how to we find the IPv6 address in my dual-stack network?

Using an open source utility, v6disc.sh, which uses the all-nodes technique discovers the nodes on your IPv6 network in a matter of seconds, rather than years.

$ ./v6disc.sh 
WARN: avahi utis not found, skipping mDNS check 
-- Searching for interface(s) 
-- Found interface(s):  eth0 
-- INT:eth0 prefixs: 2001:470:db8:101 
-- Detecting hosts on eth0 link 

-- Discovered hosts for prefix: 2001:470:db8:101 on eth0 
2001:470:db8:101::1                      00:24:a5:f1:07:ca    Buffalo
2001:470:db8:101:203:93ff:fe67:4362      00:03:93:67:43:62    Apple
2001:470:db8:101:211:24ff:fece:f1a       00:11:24:ce:0f:1a    Apple
2001:470:db8:101:211:24ff:fee1:dbc8      00:11:24:e1:db:c8    Apple
2001:470:db8:101:226:bbff:fe1e:7e15      00:26:bb:1e:7e:15    Apple
2001:470:db8:101::303                    d4:9a:20:01:e0:a4    Apple
2001:470:db8:101:3e2a:f4ff:fe37:dac4     3c:2a:f4:37:da:c4    BrotherI
2001:470:db8:101:6a1:51ff:fea0:9339      04:a1:51:a0:93:38    Netgear
2001:470:db8:101:b41f:18a3:a97c:4a0c     10:9a:dd:54:b6:34    Apple
2001:470:db8:101::9c5                    b8:27:eb:89:bc:51    Raspberr

The utility looks up the Ethernet MAC address manufacturer and prints it in the third column.

As you can see it is easy to spot the Raspberry Pi on this network.

But wait, I don’t have a dual-stack network, now what?

So you have Shaw for an ISP, and they can’t spell IPv6, now what? Another IPv6 fact is that every device which has an IPv6 stack, must have a link-local address. The link-local address is used for all sorts of things, including Neighbour Discovery Protocol (NDP), the IPv6 equivalent of ARP. Therefore, even if your network doesn’t have an IPv6 connection to the internet, your IPv6-enabled device will have a link-local address.

Fortunately, v6disc.sh also can detect link-local addresses as fast as it detects IPv6 global addresses (in mere seconds).

$ ./v6disc.sh -i wlan0 -L
WARN: avahi utis not found, skipping mDNS check 
-- INT:wlan0    prefixs:  
-- Detecting hosts on wlan0 link 
-- Discovered hosts for prefix: fe80: on wlan0 
fe80::216:3eff:fea2:94e8                 00:16:3e:a2:94:e8    Xensourc
fe80::216:3eff:feff:2f9d                 00:16:3e:ff:2f:9d    Xensourc
fe80::21e:6ff:fe33:e990                  00:1e:06:33:e9:90    Wibrain
fe80::2ac6:8eff:fe16:19d7                28:c6:8e:16:19:d7    Netgear
fe80::4aa2:12ff:fec2:16df                48:a2:12:c2:16:df    
fe80::ba27:ebff:fe89:bc51                b8:27:eb:89:bc:51    Raspberr
fe80::f203:8cff:fe3f:f041                f0:03:8c:3f:f0:41    Azurewav
-- Pau 

Link-local addresses are not globally unique, and therefore an interface must be specified with the -i, and the -L tells v6disc.sh to only detect link-local addresses.

Again, as you can see, it is easy to pick out the Raspberry Pi link-local address on this network.

Now I have the IPv6 address, how do I use it?

With the Global or link-local IPv6 address, all one need to do it ssh into the lost device and find out what is going on.

If using the link-local address, the interface must also be specified with the %intf notation (e.g. <link-local_addr>%wlan0) :

$ ssh cvmiller@fe80::ba27:ebff:fe79:bc51%wlan0
cvmiller@fe80::ba27:ebff:fe79:bc51%wlan0's password: 
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-1030-raspi2 armv7l)

Last login: Mon Sep 30 19:57:11 2019 from fe80::2ac6:8eff:fe16:19d7%br0
$

Log in and fix it

And now you are logged into your wayward device, and you can troubleshoot to figure out what went wrong.

IPv6 Fun

Everyone knows (by now) that IPv6 is an 128 bit address. And most know that the least significant 64 bits is the Interface ID (IID). That is 2^64 or 18,446,744,073,709,551,616 hosts per /64 prefix (think: subnet). But no one expects we will fill networks with that many hosts per prefix. IPv6 prefixes are part of the mind-change from IPv4, where subnets are tightly packed with hosts, to sparsely populated prefixes.

Consuming IPv6 Address space

But what if a host occupied all of the addresses in a /64 prefix? We all know that IPv6 hosts typically have more than one IPv6 address per interface. But can an interface have 2^64 addresses?

Well, probably your OS won’t allow anywhere near that number of addresses. But with a relatively simple Python program, a lowly Raspberry Pi can listen on all of those addresses simultaneously.

Fun with 2^64 Addresses

This summer I discovered ipv6board, a project run out of Sweden running on a Raspberry Pi streaming a short SMS style message that anyone can write to. You can view the Raspberry Pi display at ipv6board.best-practice.se (unfortunately, the author is having a problem the streaming video part, and may be off-line)

From the ipv6board website, one encodes ASCII into the last 8 bytes (the IID) of an addresses, and pings the ipv6board. The ASCII encoded message will show up on the Raspberry Pi’s 8×3 display. Pinging 2001:6b0:1001:105:4177:6573:6f6d:6521 will print “Awesome!” to the board.

Encoding ASCII

This is all fun, but converting text to ASCII by hand becomes tiresome fairly quickly. I thought, why not have a computer do the ASCII conversion, and pop those 8 bytes into an IPv6 address and send it off to the IPv6Board.

I decided to write a conversion program in shell script, because I wanted it to run everywhere (even on my OpenWrt router). The script takes a message argument, converts it to ASCII, and then pings the ipv6board.

$ ./ipv6board.sh "IPv6 Bd"
PING 2001:6b0:1001:105:4950:7636:2042:6420(2001:6b0:1001:105:4950:7636:2042:6420) 56 data bytes

--- 2001:6b0:1001:105:4950:7636:2042:6420 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

pau

Run it multiple times (with different messages) to fill the screen of IPv6board. ipv6board.sh is open source and hosted on github.com/cvmiller/ipv6board.sh.

How much address space do we need?

Clearly, 8 bytes is too small to write tweets. Perhaps the version of IP after IPv6 will have even more bytes so we can write a haiku poem. But for now, enjoy the Summer Fun with IPv6 today.

*Fun, Createive Commons

Firefox & Chrome Extension

The transition to IPv6 will be a long one. Even with Google measuring 25% utilization world-wideon the IPv6 internet, many services will be running dual-stack for some time to come.

IPv6-only

But there are those who have already moved to IPv6-only networks, most notably Facebook, and T-Mobile. They run a variety of transition mechanisms to help external IPv4-only services connect or traverse their IPv6-only networks.

But what if you just wanted to check your own servers to ensure they are ready for IPv6-only? Modern applications pull in javascript from many sources, and those external sources may not be available on IPv6, thus breaking your IPv6-only deployment.

There is an excellent extension to Chrome and Firefox which not only displays if the website is over IPv6, but also all the web page elements referred to on a given web page.

Looking for the Green 6

IPvFoo will put a green 6 or red 4 in the upper right corner of the browser indicating which network transport (IPv6 or IPv4 respectively) was used. In addition, a smaller 4 and/or 6 will be displayed to the right of the large 4/6 indicating referenced sites by the webpage.

Clicking on the 6 or 4, will display a list of referred sites and what addresses were used will pop up.

Looking up who owns that address

By right-clicking an address on the right side of the pop-up list, an option of Look up on bgp.he.net. Click that, and Hurricane electric will not only display the AS (autonomous system) that announced that IP block, but clicking on the whois tab will show you who is registered for that IP block.

Creating a IPv6-only site

When creating an IPv6-only site, IPvFoo can quickly tell you if not only your server is running IPv6, but also the references that your web application might be using. In a IPv6-only network, the IPv4 references will not connect (unless you are using a transition mechanism like NAT64)

But why should you create an IPv6-only site. Frankly it is easier and faster, with only one protocol and firewall/ACLs to manage, and no transition mechanisms to traverse. If you believe the projections, the IPv6 Internet will be at 80% by 2025, that is only a little more than five years from now.

Be Ready for the Future Now

IPvFoo not only displays if you are IPv6-only ready, but is interesting to see how the rest of the world is building web sites as well.

Originally posted at www.makikiweb.com