tag:blogger.com,1999:blog-4553852876741905542024-03-05T11:46:42.807-08:00IPv6 - The future of the InternetCraighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-455385287674190554.post-34856207792890744602019-11-18T17:05:00.001-08:002019-11-18T17:05:32.334-08:00Using IPv6 Link-Local to the Rescue<table align="right">
<tbody>
<tr><td><img align="right" alt="Rescue!" src="http://www.makikiweb.com/ipv6/_images/Scania_P280_ECFRS_Rescue_Pump_ipv6_480.jpg" height="220" width="300" />
<br />
<br />
<center>
<b>IPv6 to the Rescue</b></center>
</td>
</tr>
</tbody></table>
<h4>
by Craig Miller</h4>
<br />
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 <code>ssh</code> into see what the problem is, it has just disappeared.<br />
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 <em>may</em> fix the problem, or it could make it worse, if it was writing out to the SD Card at the time you pulled power.<br />
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?<br />
<h3>
</h3>
<h3>
IPv6 to the Rescue</h3>
<br />
But if you setup your network as a <strong>dual-stack</strong> network, then your device already has not only an <strong>IPv4</strong> address, but also an <strong>IPv6</strong> address as well. And if you put the IPv6 address into your local DNS, then you can just <code>ssh</code> to the hostname, and see what is going on with your device.<br />
But what if you <em>do</em> 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?<br />
<code>ssh</code> to the IPv6 address of the device, and Bob's your uncle.<br />
<h4>
</h4>
<h4>
Finding the IPv6 Address of your device</h4>
<br />
Unlike IPv4 network scanners, scanning IPv6 networks is <em>much</em> 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 <strong><a href="https://zmap.io/">zmap</a></strong> 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 <strong>367,719 years</strong>! (2^32 *45 min / 60 min/ 24 hours/ 365 days). And <strong>zmap</strong> doesn't support IPv6 (and you can see why)<br />
Fortunately, there are non-brute-force solutions to the problem.<br />
<h4>
</h4>
<h4>
IPv6 Basics, the all-nodes address</h4>
<br />
Although there is no <em>broadcast</em> in IPv6, there is a specific multicast address that <em>all</em> nodes must listen to. This is called the <strong>all-nodes</strong> address, or <strong>ff02::1</strong>. It is possible to send a ping to the <strong>all-nodes</strong> address, and get multiple responses back, similar to pinging the IPv4 broadcast address will (used to) return multiple responses.<br />
<pre><code>$ 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
</code></pre>
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 <strong>-I</strong> to ping.<br />
<h4>
</h4>
<h4>
OK, but how to we find the IPv6 address in my dual-stack network?</h4>
<br />
Using an open source utility, <strong><a href="https://github.com/cvmiller/v6disc">v6disc.sh</a></strong>, which uses the all-nodes technique discovers the nodes on your IPv6 network in a matter of <em>seconds</em>, rather than <em>years</em>.<br />
<pre><code>$ ./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
</code></pre>
The utility looks up the Ethernet MAC address manufacturer and prints it in the third column.<br />
As you can see it is <em>easy</em> to spot the Raspberry Pi on this network.<br />
<h4>
</h4>
<h4>
But wait, I don't have a dual-stack network, now what?</h4>
<br />
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 <strong>link-local</strong> 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 <strong>link-local</strong> address.<br />
Fortunately, <strong>v6disc.sh</strong> also can detect <strong>link-local</strong> addresses as fast as it detects IPv6 global addresses (in mere seconds).<br />
<pre><code>$ ./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
</code></pre>
Link-local addresses are <em>not</em> globally unique, and therefore an <strong>interface</strong> must be specified with the <strong>-i</strong>, and the <strong>-L</strong> tells <strong>v6disc.sh</strong> to <em>only</em> detect link-local addresses.<br />
Again, as you can see, it is easy to pick out the Raspberry Pi link-local address on this network.<br />
<h3>
</h3>
<h3>
Now I have the IPv6 address, how do I use it?</h3>
<br />
With the Global or link-local IPv6 address, all one need to do it <code>ssh</code> into the <em>lost</em> device and find out what is going on.<br />
If using the <strong>link-local</strong> address, the interface must also be specified with the <strong>%intf</strong> notation (e.g. <link-local_addr>%wlan0) :<br />
<pre><code>$ 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
$
</code></pre>
<br />
<h3>
Go forth and Rescue</h3>
<br />
And now you are logged into your wayward device, and you can troubleshoot to figure out what went wrong.<br />
<br />
<br />
<hr />
<small>
Originally published on <a href="http://www.makiki.ca//ipv6/ipv6_rescue.html" target="_blank">Makiki.ca</a></small>
<br />
<br />
<div>
<br /></div>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-76476942381945643292019-08-08T11:10:00.001-07:002019-08-08T11:10:06.926-07:00IPvFoo, Identifying IPv6 Servers<br />
<br />
<table align="right">
<tbody>
<tr><td><img align="right" alt="Traffic" src="http://www.makikiweb.com/ipv6/_images/ipvfoo_icon.png" />
<br />
<br />
<center>
<b>Firefox & Chrome Extension</b></center>
</td>
</tr>
</tbody></table>
The transition to IPv6 will be a long one. Even with <a href="https://www.google.com/intl/en/ipv6/statistics.html">Google measuring 25% utilization world-wide</a> on the IPv6 internet, many services will be running <em>dual-stack</em> for some time to come.<br />
<br />
<h3>
IPv6-only</h3>
<div>
<br /></div>
But there are those who have already moved to IPv6-only networks, most notably <a href="https://www.internetsociety.org/resources/deploy360/2014/case-study-facebook-moving-to-an-ipv6-only-internal-network/">Facebook</a>, and <a href="https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/">T-Mobile</a>. They run a variety of transition mechanisms to help external IPv4-only services connect or traverse their IPv6-only networks.<br />
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.<br />
There is an excellent extension to <a href="https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal">Chrome</a> and <a href="https://addons.mozilla.org/en-US/firefox/addon/ipvfoo-pmarks/">Firefox</a> which not only displays if the website is over IPv6, but also all the web page elements referred to on a given web page.<br />
<img alt="IPvFoo Screenshot" src="https://raw.githubusercontent.com/pmarks-net/ipvfoo/master/misc/screenshot_webstore_640x400.png" /><br />
<h3>
<br /></h3>
<h3>
Looking for the Green 6</h3>
<div>
<br /></div>
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.<br />
Clicking on the 6 or 4, will display a list of referred sites and what addresses were used will pop up.<br />
<h3>
<br /></h3>
<h3>
Looking up who <em>owns</em> that address</h3>
<div>
<br /></div>
By <strong>right-clicking</strong> an address on the right side of the pop-up list, an option of <em>Look up on bgp.he.net</em>. Click that, and Hurricane electric will not only display the AS (autonomous system) that announced that IP block, but clicking on the <em>whois</em> tab will show you who is registered for that IP block.<br />
<img alt="IPvFoo Screenshot" src="http://www.makikiweb.com/ipv6/_images/ipvfoo_bgp_lookup_menu.png" /><br />
<h3>
<br /></h3>
<h3>
Creating a IPv6-only site</h3>
<div>
<br /></div>
When creating an IPv6-only site, <strong>IPvFoo</strong> 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)<br />
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 <a href="https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=2500&timebackward=365&country=ww">projections</a>, the IPv6 Internet will be at 80% by 2025, that is <em>only</em> a little more than <strong>five</strong>years from now.<br />
<h3>
<br /></h3>
<h3>
Be Ready for the Future Now</h3>
<div>
<br /></div>
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.<br />
<div>
<br /></div>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-3607632707769621402019-03-04T11:21:00.000-08:002019-03-04T11:21:53.234-08:00Linux Containers, building virtualization for the future with IPv6<h3>
<br /></h3>
<table align="right" style="color: black;"><tbody>
<tr><td><img align="right" alt="Traffic" height="300" src="http://www.makikiweb.com/ipv6/_images/palm_of_hand_lxc.jpg" width="400" /><br /><center>
Server Farm in the Palm of your hand</center>
</td></tr>
</tbody></table>
I have recently been <a href="http://www.makikiweb.com/Pi/docker_intro.html">exploring Docker containers</a> on SBCs (Small Board Computers), including the Raspberry Pi. The Docker eco-system is impressive in the amount of preconfigured containers that are available. However, as I have written before, it falls down on networking support, specifically IPv6 support. The best one can do is NAT6 on IPv6, which just perpetuates the complexities (and evils) of NAT.<br />
The biggest problem with the Docker IPv6 implementation is that it was an after thought. Unfortunately, this is not uncommon. Think of adding security after the fact, and you will quickly discover the poorly implemented security model. Docker is limited in this kind of after-thought thinking.<br />
<br />
<h4>
Linux Containers</h4>
<br />
Another <em>container</em> technology which can also run on SBCs is Linux Containers (LXC/LXD). LXC shares the host's kernel and is lighter weight than traditional Virtual Machines. But each LXC Container is isolated via namespaces and control groups, so it appears to have its own network stack. And therefore is more flexible than Docker.<br />
<br />
<h3>
Qualifying the SBC OS for LXC/LXD</h3>
<br />
Before going too far in installing Linux Containers, it is best to ensure that the OS will support LXC. There are a couple of requirements of the Host OS:<br />
<ul>
<li>Is LXD and LXD-Client in the repo (easy to install with apt-get)</li>
<li>Does the kernel support <strong>namespaces</strong></li>
</ul>
The first is easy, search for the packages:<br />
<pre><code>$ apt-cache search lxd-client
lxd-client - Container hypervisor based on LXC - client
</code></pre>
The second involves what support was compiled into the kernel when it was built. Namespaces allow the kernel to create separate network areas, each with its own firewall rules. The easiest way to determine this is to look for namespace items in <code>/proc</code><br />
<pre><code>$ ls /proc/self/ns
ipc mnt net pid user uts
</code></pre>
<br />
Unfortunately, the raspian kernel from <a href="https://www.raspberrypi.org/">raspberrypi.org</a> doesn't support namespaces.<br />
<br />
<h4>
Getting a LXC/LXD compatible OS</h4>
<br />
Fortunately, there is an <a href="https://www.finnie.org/software/raspberrypi/ubuntu-rpi3/ubuntu-18.04-preinstalled-server-armhf+raspi3.img.xz">unofficial Ubuntu 18.04 image</a> available for the Pi which does. This image is compressed and must be decompressed before <em>flashed</em> to a SD Card. <br />
<br />
<strong>Make sure</strong> you follow the <a href="https://wiki.ubuntu.com/ARM/RaspberryPi#First_boot_.28Username.2FPassword.29">steps on the Ubuntu page</a> to set an initial password for the <code>ubuntu</code> user.<br />
<div>
<br /></div>
<div>
<strong>Additionally</strong> follow the steps to <a href="https://wiki.ubuntu.com/ARM/RaspberryPi#Booting_the_official_Pi_2_image_on_the_Pi_3B.2F3B.2B-">boot the unofficial image on the <strong>Raspberry 3B+</strong></a>. Be sure to update the <code>config.txt</code> file and update the bootloader files. The <strong>Raspsberry 3B</strong> can boot the unofficial image without these extra steps.<br />
<br />
<h3>
Preparing the LXC Host (aka the Pi)</h3>
<br />
The key networking difference between Docker and LXC is that with LXC one can attach a <em>container</em> to any bridge on the Host. This includes a bridge on the outside interface. Via <strong>transparent bridging</strong> the <em>container</em> can have unfettered access to the existing IPv6 subnet, including picking up Global Unique Addresses (GUAs) without the host having to do router-like functions, such as adding routes, auto propagation of prefixes (with DHCPv6-PD), redistribution of routes, etc. Again, things which Docker doesn't support.<br />
<br />
<h4>
Setting up an external bridge interface on the Host</h4>
<br />
Once you have the right kernel and distro, configure a bridge <strong>br0</strong> which will in-turn have the ethernet interface as a member. This is best done from the Pi itself using a keyboard and monitor, rather than <code>ssh</code>-ing to a headless device. Because when you mess up, you are still connected to the Pi (believe me, it is easy to get disconnected with all interfaces down). Logically the bridge, <strong>br0</strong> will not only be attached to the <strong>eth0</strong> interface, but later on, the LXC Containers as well.<br />
<img alt="External Bridge" src="http://www.makikiweb.com/ipv6/_images/lxc_network_br0.png" /></div>
<div>
<h3>
<br /></h3>
<h3>
Installing LXC/LXD</h3>
<br />
Once setting up the br0 interface is done, we can install <code>lxd</code> and <code>lxd-client</code>. Linux Containers has been evolving of the years, and it is now (as I write this) up to version 3.0.2.<br />
<br />
<h4>
A note about versions</h4>
<br />
There is quite a bit on the internet about older versions of Linux Containers. If you see hyphenated commands like <code>lxc-launch</code> then <strong>stop</strong> and move to another page. Hyphenated commands are the older version 1 or 2 of Linux Containers.<br />
<br />
<h4>
A quick tour of LXC/LXD</h4>
<br />
Canonical has a nice <a href="https://linuxcontainers.org/lxd/try-it/">Try It page</a>, where you can run LXC/LXD in the comfort of your web browser without installing anything on your local machine. The <em>Try It</em> sets up a VM which has IPv6 access to the outside world, where you can install and configure LXC/LXD, even create Linux Containers. It is well worth the 10 minutes to run through the hands on tutorial.<br />
<br />
<h4>
Doing the install</h4>
<br />
Installing LXD will pull in <code>lxc</code> as well. And because we are using Ubuntu 18.04LTS, it is as simple as using <code>apt-get</code><br />
<pre><code>sudo apt-get install lxd lxd-client
</code></pre>
<br />
But wait! It is already installed on this image. Although it is version 3.0.0, and the easiest way to get it to the latest version is to run:<br />
<pre><code>$ sudo apt-get update
$ sudo apt-get upgrade lxd lxd-client
</code></pre>
<br />
Add yourself to the <code>lxd</code> group so you won't have to type <code>sudo</code> all the time.<br />
<pre><code>sudo usermod -aG lxd craig
newgrp lxd
</code></pre>
<h4>
<br /></h4>
<h4>
LXD Init</h4>
<br />
The LXD init script sets up LXD on the machine with a set of interactive questions. It is safe to accept all the defaults (just press return).</div>
<div>
<pre><code>$ sudo lxd init</code></pre>
<pre>
</pre>
</div>
<div>
<h4>
Default LXD Networking</h4>
<br />
Since we took all the defaults of <code>lxd init</code> it created another bridge on the system <code>lxdbr0</code> which the YAML file would lead you to believe it is also bridged to the outside world, but <strong>it is not</strong>. The default config is similar to Docker, in that it creates a <code>lxdbr0</code> bridge which uses NAT4 and NAT6 to connect to the outside world.<br />
<br />
But we don't care, because we have created a bridge <code>br0</code> which <em>is</em> transparently bridged to the outside world. And <em>unlike</em> Docker, individual containers can be attached to any bridge (either <code>br0</code> or if you want NAT, <code>lxdbr0</code>)<br />
<h4>
Create a profile for the external transparent bridge (br0)</h4>
There is one more thing we have to do before running the first Linux Container, create a profile for the <code>br0</code> bridge. Edit the profile to match the info below:<br />
<pre><code>lxc profile create extbridge
lxc profile edit extbridge
config: {}
description: bridged networking LXD profile
devices:
eth0:
name: eth0
nictype: bridged
parent: br0
type: nic
name: extbridge
used_by:
</code></pre>
<br />
Note: if you prefer <code>vi</code> to whatever editor comes up when editing the profile, set the environment variable below, then edit the profile.<br />
<pre><code>export EDITOR=vi
</code></pre>
<br />
The Linux Container network is now ready to attach containers to the <code>br0</code> bridge like this:<br />
<img alt="container network" src="http://www.makikiweb.com/ipv6/_images/lxc_network_with_docker.png" /><br />
<br />
You may notice the bottom LXC container with Docker, more on this later.<br />
<br />
<h3>
Running the first Linux Container</h3>
<br />
So now it is time to have fun by running the first container. I suggest <strong>Alpine Linux</strong> because it is small, and quick to load. To create and start the container type the following:<br />
<pre><code>lxc launch -p default -p extbridge images:alpine/3.8 alpine
</code></pre>
<br />
LXD will automatically download the <strong>Alpine Linux</strong> image from the <a href="https://us.images.linuxcontainers.org/">Linux Containers image server</a>, and create a container with the name <code>alpine</code>. We'll use the name <code>alpine</code> to manage the container going forward.<br />
<br />
Typing <code>lxc ls</code> will list the running containers<br />
<pre><code>$ lxc ls
+---------+---------+------------------------+----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+---------+---------+------------------------+----------------------------------------------+------------+-----------+
| alpine | RUNNING | 192.168.215.104 (eth0) | fd6a:c19d:b07:2080:216:3eff:fecf:bef5 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fecf:bef5 (eth0) | | |
+---------+---------+------------------------+----------------------------------------------+------------+-----------+
</code></pre>
<br />
You will note that the container has not only a IPv4 address from my DHCP server, but it also has an IPv6 GUA (and in this case, an additional IPv6 ULA, Unique Local Address).<br />
<br />
<h4>
YAML overlaying</h4>
<br />
The <code>alpine</code> container has a GUA because we used two <code>-p</code> (profile) parameters when creating it. The first is the <code>default</code> profile which as I mentioned earlier is set up for NAT4 and NAT6. And the second is the <code>extbridge</code> profile we setup as a profile. The <code>lxc launch</code>command pulls in the YAML info from the <code>default</code> profile, and then <em>overlays</em> the <code>extbridge</code> profile, effectively overwriting the parts we want so that the <code>alpine</code> container is attached to <code>br0</code> and the outside world!<br />
<br />
<h4>
Stepping into Alpine</h4>
<br />
Of course, what good is starting a Linux Container if all you can do is start and stop it. A key difference from Docker is that Linux Containers are <strong>not</strong> read-only, but rather you can install software, configure it the way you like, and then stop the container. When you start it again, all the changes you made are still there. I'll talk about the goodness of this a little later.<br />
<br />
But in order to do that customization one needs to get inside the container. This is done with the following command:<br />
<pre><code>$ lxc exec alpine -- /bin/sh
~ #
</code></pre>
<br />
And now you are inside the running container as root. Here you can do anything you can do on a normal linux machine, install software, add users, start sshd, so you can ssh to it later, and so on. When you are done customizing the container type:<br />
<pre><code>~ # exit
craig@pai:~$
</code></pre>
<br />
And you are back on the LXC Host.<br />
<br />
<h3>
Advantages of customizing a container</h3>
<br />
A key advantage of customizing a container, is that you can create a template which then can be used to crate many instances of that customized application. For example, I started with <code>alpine</code> installed <code>nginx</code> and <code>php7</code> and created a template image, which I called <code>web_image</code>. I used the following commands on the host, after installing the webserver with PHP inside the container:<br />
<pre><code>$ lxc snapshot alpine snapshot_web # Make a back up of the container
$ lxc publish alpine/snapshot_web --alias web_image # publish the back up as an image
$ lxc image list # show the list of images
+--------------+--------------+--------+--------------------------------------+--------+----------+-----------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
+--------------+--------------+--------+--------------------------------------+--------+----------+-----------------------------+
| web_image | 84a4b1f466ad | no | | armv7l | 12.86MB | Dec 4, 2018 at 2:46am (UTC) |
+--------------+--------------+--------+--------------------------------------+--------+----------+-----------------------------+
| | 49b522955166 | no | Alpine 3.8 armhf (20181203_13:03) | armv7l | 2.26MB | Dec 3, 2018 at 5:11pm (UTC) |
+--------------+--------------+--------+--------------------------------------+--------+----------+-----------------------------+
</code></pre>
<h4>
<br /></h4>
<h4>
Scaling up the template container</h4>
<br />
And with that webserver image, I can replicate it as many times as I have disk space and memory. I tried 10, but based on how much memory it was using, I think I could have gone to twenty on the Pi.<br />
<pre><code>$ lxc ls
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| alpine | RUNNING | 192.168.215.104 (eth0) | fd6a:c19d:b07:2080:216:3eff:fecf:bef5 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fecf:bef5 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w10 | RUNNING | 192.168.215.225 (eth0) | fd6a:c19d:b07:2080:216:3eff:feb2:f03d (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:feb2:f03d (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w2 | RUNNING | 192.168.215.232 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe7f:b6a5 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe7f:b6a5 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w3 | RUNNING | 192.168.215.208 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe63:4544 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe63:4544 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w4 | RUNNING | 192.168.215.244 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe99:a784 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe99:a784 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w5 | RUNNING | 192.168.215.118 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe31:690e (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe31:690e (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w6 | RUNNING | 192.168.215.200 (eth0) | fd6a:c19d:b07:2080:216:3eff:fee2:8fc7 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fee2:8fc7 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w7 | RUNNING | 192.168.215.105 (eth0) | fd6a:c19d:b07:2080:216:3eff:feec:baf7 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:feec:baf7 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w8 | RUNNING | 192.168.215.196 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe90:10b2 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe90:10b2 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| w9 | RUNNING | 192.168.215.148 (eth0) | fd6a:c19d:b07:2080:216:3eff:fee3:e5b2 (eth0) | PERSISTENT | 0 |
| | | | 2001:db8:ebbd:2080:216:3eff:fee3:e5b2 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
| web | RUNNING | 192.168.215.110 (eth0) | fd6a:c19d:b07:2080:216:3eff:fe29:7f8 (eth0) | PERSISTENT | 1 |
| | | | 2001:db8:ebbd:2080:216:3eff:fe29:7f8 (eth0) | | |
+--------+---------+------------------------+----------------------------------------------+------------+-----------+
</code></pre>
<br />
All of the webservers have their own unique IPv6 address, and all of them are running on port 80, something that can't be done using NAT.<br />
<br /></div>
<div>
<br /></div>
<div>
<h4>
LXC plays well with DNS</h4>
<br />
Unlike Docker, <strong>LXC containers retain the same IPv6 address</strong> after being start and stopped. And if you are starting multiple containers, the order of starting doesn't change the address (as Docker does).<br />
This means that you can assign names to your LXC Containers without a lot of DNS churn. Here's a chunk from my DNS zone file:<br />
<pre><code>lxcdebian IN AAAA 2001:db8:ebbd:2080:216:3eff:feae:a30
lxcalpine IN AAAA 2001:db8:ebbd:2080:216:3eff:fe4c:4ab2
lxcweb IN AAAA 2001:db8:ebbd:2080:216:3eff:fe29:7f8
lxcw2 IN AAAA 2001:db8:ebbd:2080:216:3eff:fe7f:b6a5
lxcdocker1 IN AAAA 2001:db8:ebbd:2080:216:3eff:fe58:1ac9
</code></pre>
<br />
DNS is your friend when using IPv6. With DNS entries, I can point my web browser to the servers running on these containers. I can <em>even</em> ssh in to the container, just like any host on my network.<br />
<br /></div>
<div>
<h3>
Linux Containers + Docker</h3>
</div>
<div>
<br /></div>
<div>
While it is possible to run Docker inside a Linux Container and over come some of the IPv6 limitations of Docker, it is a heavy weight solution (read: uses more RAM and disk). If you are thinking of scaling up an application, you would be better off customizing a Linux Container with a native application, rather than using a pre-canned Dockker app.</div>
<div>
<br /></div>
<div>
<h3>
Address Stability</h3>
<br />
Because all of this is running on LXC, there is address stability. Not matter how many times you reboot the Raspberry Pi, or restart containers in different order, the addresses remain the same. This means the addresses above can be entered into your DNS server with out churn. Something Docker doesn't provide.<br />
<br />
<h3>
Running a Virtual Network</h3>
<br />
LXC is the best at container customization, and virtual networking (IPv4 and IPv6). With LXCs flexibility, it is easy to create templates to scale up multiple applications . Now you have a <strong>server farm in the palm of your hand</strong>, with <strong>excellent IPv6 support</strong>! Perhaps the Docker folks will take note.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<span style="font-size: x-small;">Article (with more detail) available on <a href="http://www.makikiweb.com/Pi/lxc_on_the_pi.html" target="_blank">www.makikiweb.com</a></span></div>
<div>
<br /></div>
<div>
<span style="font-size: x-small;"><a href="https://www.flickr.com/photos/alliekoshes/6268944281">Palm Photo</a> by Alie Koshes</span></div>
<div>
<br /></div>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-17244626694031992322018-11-23T14:14:00.000-08:002018-11-23T14:14:01.453-08:00What makes a good IPv6 implementation?<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9-bHcMxRukYhDunBhSJQl_Wc2I4QeU08NRaL0DMrX32NtQ6CperS-dqVg7rjPkUBLlHPuOpf-kqL8nnkV0dXXBaBHlWEjH9oz6Tx4J6BSdL-bSmgMNesLegfNw07CcbM6d5EpuexBWUBl/s1600/yaughts_racing_cc_mark_pilbeam.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="480" data-original-width="640" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9-bHcMxRukYhDunBhSJQl_Wc2I4QeU08NRaL0DMrX32NtQ6CperS-dqVg7rjPkUBLlHPuOpf-kqL8nnkV0dXXBaBHlWEjH9oz6Tx4J6BSdL-bSmgMNesLegfNw07CcbM6d5EpuexBWUBl/s320/yaughts_racing_cc_mark_pilbeam.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Bad IPv6 support costs Money</td></tr>
</tbody></table>
<br />
I have been working with Docker lately, and as cool as the container technology is, it was originally built without consideration for IPv6, and then IPv6 was bolted on later. Making supporting IPv6 full of expensive work-a-rounds.<br />
<br />
But that got me thinking what makes a good IPv6 implementation? Of course this is my opinion, and you are free to toss in other criteria, so think of this as a thought starter.<br />
<br />
<h3>
Why is this important?</h3>
<br />
With <strong>25%</strong> of the internet carried over IPv6 as of this writing, if you are developing a product which has a lifetime of 5 to 10 years, and you aren't giving thought as to how you will support IPv6, then your product will:<br />
<ul>
<li>A) fail, or</li>
<li>B) you will try to bolt on IPv6 on the side, or</li>
<li>C) have to be completely rewritten.</li>
</ul>
All of that costs <strong>money</strong>.<br />
<br />
<h3>
A good IPv6 device implementation</h3>
<div>
<br /></div>
There are broad areas where IPv6 should work well.<br />
<br />
<h4>
Addressing</h4>
<div>
<br /></div>
As much as I like the simplicity of SLAAC (Stateless Address Auto Config), there are certainly use cases where DHCPv6 is a better choice. A good implementation should:<br />
<ul>
<li>Support both addressing methods, SLAAC, and DHCPv6</li>
<li>Be able to reestablish IPv6 GUA (Global Unique Address) once the device comes out of sleep/suspend or link down/up (systemd suffers this problem)</li>
<li>Play well with DNS. Very few of us enjoy typing IPv6 addresses, the implementation should have a stable IPv6 address which can be entered into DNS without requiring a lot of DNS churn.</li>
</ul>
<h4>
</h4>
<h4>
Routing</h4>
<strong><br /></strong>
<strong>IPv6 is not IPv4 with colons</strong>. There are somethings which are different for good reason.<br />
<ul>
<li>Default routes are link-local addresses (Docker fails on this one big time). GUAs may change, link-locals shouldn't.</li>
<li>Supports RA (Router Advertisement) fields, RDNSS (DNS server), and DNSSL (DNS domain search list). Not much use having an address if the host can't resolve names</li>
<li>If the device is routing (such as Docker) then support DHCPv6-PD, and provide the option of prefix delegation into the container/downstream network.</li>
</ul>
<h4>
</h4>
<h4>
Resiliency</h4>
<br />
Basic protection from network misconfiguration, or out right attacks makes the IPv6 device better prepared for production use.<br />
<ul>
<li>Rational limit on the number of IPv6 addresses an interface may have. Before <code>systemd</code>, the Linux kernel defaulted to 16. This seemed like a good compromise. Back in <code>systemd</code> v232, it was possible to exhaust memory on an IPv6 host by feeding it Random RA addresses, creating a denial of service. FreeBSD v11.5 has a similar problem, where the system will add over 3000 IPv6 addresses, and the system will slow to a crawl.</li>
<li>Rational limit on the number of neighbours. IPv6 /64 networks are sparsely populated and therefore one shouldn't have to expect to support all 16 Quintilian (2^64) neighbours. Something like 1000, or even 256 should be enough.</li>
<li>Don't assume that the Linux Stack has your back. Since <code>systemd</code> has become widespread, there are many <a href="https://github.com/systemd/systemd/issues?utf8=%E2%9C%93&q=is%253Aissue+is%253Aopen+and+ipv6">IPv6 systemd bugs</a>, which weren't there in the pre-systemd kernel days. IPv6 is a different stack, be sure to test it.</li>
</ul>
<h3>
</h3>
<h3>
Summary</h3>
<br />
I am sure I missing a few, but this is a start. When developing a product, the <strong>business case for supporting IPv6 well, is that it will save you money</strong> in the long run, by not having to go back and try to bolt IPv6 on, or rewrite your network stack later.<br />
<br />
<br />
P.S I wouldn't recommend putting Docker into production because of the severe IPv6 limitations.<br />
<br />
<small>Yachts colliding: Creative Commons/ Mark Pilbeam</small>Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-36152874902430781272018-08-08T15:05:00.000-07:002018-08-08T15:05:25.431-07:00Babel: a routing protocol with wireless support<h4>
<span style="font-size: x-small;">by Craig Miller</span></h4>
<br />
<img align="right" alt="Traffic" src="http://www.makikiweb.com/ipv6/_images/babel.png" /><br />
Previously I wrote about resurrecting the old forgotten routing protocol, <a href="http://www.makikiweb.com/ipv6/ripng.html">RIPng</a>. In a small network of more than one router, you need a routing protocol to share information between the routers. I used RIPng for about six months, turned it on, and pretty much forgot that it was running. Worked like a charm in my wired network.<br />
I moved to a new (to me) house this summer, and thought it was a good opportunity to try out a routing protocol which not only handles wired networks but also wireless. Babel seemed just the thing for this environment.<br />
<br />
<h3>
Enter Babel</h3>
<br />
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. Based on the loss of <em>hellos</em> the cost of wireless links can be increased, making sketchy wireless links less preferred.<br />
<a href="https://tools.ietf.org/html/rfc6126">RFC 6126</a> standardizes the routing protocol.There are two implementations which are supported on OpenWrt routers, <code>babeld</code> and <code>bird</code><br />
<code><br /></code>
<br />
<h3>
Creating a network with redundant paths</h3>
<br />
Like anything in networking, it starts with the physical layer (wireless is a form of physical layer). I attached the wireless links of the <strong>backup link router</strong> to the <strong>production</strong> and <strong>test</strong> routers. Thus creating redundant path of connectivity within my house.<br />
<img alt="Network Diagram" src="http://www.makikiweb.com/ipv6/_images/babel_network.png" /><br />
<h3>
</h3>
<h3>
Running BIRD with Babel</h3>
<br />
I chose <code>bird6</code> (the IPv6 version of <code>bird</code> on OpenWrt) because I already had it installed on the routers for <a href="http://www.makikiweb.com/ipv6/ripng.html">RIPng</a>. It was merely a matter of commenting out the RIP section in the <code>/etc/bird6.conf</code> file, and enabling Babel.<br />
The <a href="http://bird.network.cz/?get_doc&v=16&f=bird-6.html#ss6.1">Bird Documentation</a> provides an example. Add the following to <code>/etc/bird6.conf</code> get Babel running in <code>bird6</code><br />
<pre><code>protocol babel {
interface "wlan0", "wlan1" {
type wireless;
hello interval 1;
rxcost 512;
};
interface "br-lan" {
type wired;
};
import all;
export all;
}
</code></pre>
In the example above, <code>wlan0</code> is the 2.4 Ghz radio, and <code>wlan1</code> is the 5 Ghz radio.<br />
<br />
<h3>
Checking the path of connectivity</h3>
<br />
When determining the connectivity path, <code>traceroute6</code> (the IPv6 version) is your friend. Checking between the laptop and the DNS server, the path is:<br />
<pre><code>$ traceroute6 6dns
traceroute to 6lilikoi.hoomaha.net (2001:db8:ebbd:4118::1) from 2001:db8:ebbd:bac0:d999:cd8a:cd9b:2037, port 33434, from port 49819, 30 hops max, 60 bytes packets
1 2001:db8:ebbd:bac0::1 (2001:db8:ebbd:bac0::1) 4.561 ms 0.510 ms 0.487 ms
2 2001:db8:ebbd:4118::1 (2001:db8:ebbd:4118::1) 2.562 ms 2.193 ms 1.927 ms
$
</code></pre>
The traceroute is showing the path going clockwise through the 2.4 Ghz wireless link.<br />
<br />
<h3>
Network Failure!</h3>
<br />
To test how well Babel can automatically route around failed links, I started a ping to the DNS server from the laptop and disabled the 2.4 Ghz radio, thus blocking the link the pings were using, and waited...<br />
<pre><code>$ ping6 6dns
PING 6dns(2001:db8:ebbd:4118::1) 56 data bytes
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=1 ttl=63 time=3.54 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=2 ttl=63 time=1.64 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=3 ttl=63 time=2.02 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=4 ttl=63 time=1.64 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=5 ttl=63 time=1.51 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=6 ttl=63 time=1.65 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=7 ttl=63 time=1.58 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=8 ttl=63 time=5.80 ms
From 2001:db8:ebbd:bac0::1 icmp_seq=33 Destination unreachable: No route
From 2001:db8:ebbd:bac0::1 icmp_seq=34 Destination unreachable: No route
...
From 2001:db8:ebbd:bac0::1 icmp_seq=48 Destination unreachable: No route
From 2001:db8:ebbd:bac0::1 icmp_seq=49 Destination unreachable: No route
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=101 ttl=61 time=2.12 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=102 ttl=61 time=3.42 ms
64 bytes from 2001:db8:ebbd:4118::1: icmp_seq=103 ttl=61 time=3.16 ms
</code></pre>
As you can see the outage was <strong>93 seconds</strong> (101 - 8). Not a record time, OSPF would converge much faster, but still it did <em>fix</em> itself without human intervention.<br />
Checking the connectivity path with <code>traceroute6</code>:<br />
<pre><code>$ traceroute6 6dns
traceroute to 6lilikoi.hoomaha.net (2001:db8:ebbd:4118::1) from 2001:db8:ebbd:bac0:d999:cd8a:cd9b:2037, port 33434, from port 47725, 30 hops max, 60 bytes packets
1 2001:db8:ebbd:bac0::1 (2001:db8:ebbd:bac0::1) 0.541 ms 0.445 ms 0.437 ms
2 2001:db8:ebbd:2080::1 (2001:db8:ebbd:2080::1) 1.705 ms 1.832 ms 1.817 ms
3 2001:db8:ebbd:2000::1 (2001:db8:ebbd:2000::1) 2.273 ms 1.891 ms 2.584 ms
4 2001:db8:ebbd:4118::1 (2001:db8:ebbd:4118::1) 2.348 ms 2.822 ms 2.289 ms
$
</code></pre>
The path can now be seen to be traveling counter-clockwise around the circle via the 5 Ghz link. The Babel routing protocol is routing packets around the failure.<br />
<br />
<div>
<h3>
Wireless is great, except ...</h3>
<br />
As more and more things come online using wireless there will be more interference and contention for bandwidth, especially in the 2.4 Ghz band. Babel can enables routing of packets around sketchy wireless links due to interference in a crowded wifi environment.<br />
<br />
<h3>
Your Metric may vary</h3>
<br />
Because wireless is variable, Babel applies differing metrics to routes as the wireless signal changes. An unfortunate side effect of this is that the network is continuously converging (or changing). The route that may have been used last minute to the remote host, my be invalid the next minute.<br />
I noticed this as my previously very stable IPv6-only servers were now disconnecting, or worse, not reachable.<br />
<br />
<h3>
Route Flapping!</h3>
<br />
As I looked at the OpenWrt syslog (using the <code>logread</code> command) I could see that the routes were continually changing.<br />
<pre><code>Tue Jul 24 14:46:45 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:46:45 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:46:46 2018 daemon.info odhcpd[778]: Using a RA lifetime of 1800 seconds on br-lan
Tue Jul 24 14:47:01 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:01 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:02 2018 daemon.info odhcpd[778]: Using a RA lifetime of 1800 seconds on br-lan
Tue Jul 24 14:47:33 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:33 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:34 2018 daemon.info odhcpd[778]: Using a RA lifetime of 1800 seconds on br-lan
Tue Jul 24 14:47:49 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:49 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:47:50 2018 daemon.info odhcpd[778]: Using a RA lifetime of 1800 seconds on br-lan
Tue Jul 24 14:48:53 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:48:53 2018 daemon.info odhcpd[778]: Raising SIGUSR1 due to default route change
Tue Jul 24 14:48:54 2018 daemon.info odhcpd[778]: Using a RA lifetime of 1800 seconds on br-lan
...
</code></pre>
<br />
The problem with this route flapping is that it was being propagated to the other routers which were busy adding and removing routes, causing <em>unreachable</em> to parts of my network. Not a desired behaviour.<br />
<br />
<h3>
Settling things down</h3>
<br />
To rid my network of the route churn, I changed the Babel <em>wireless</em> interfaces to <em>wired</em>, giving them a stable metric, no longer tied to the variability of the wireless signal quality (signal to noise).<br />
The <code>/etc/bird6.conf</code> now looks like:<br />
<pre><code>protocol babel {
interface "wlan0", "wlan1" {
type wired;
hello interval 5;
};
interface "br-lan" {
type wired;
};
import all;
export all;
}
</code></pre>
Restarting <code>bird6</code>, and looking at the syslog, a brief activity can be seen, then the route churn stops, and the network is stable.<br />
<br />
My ssh connection was dropped as the network did an initial reconverge, and then I was able log back in and examine the syslog.<br />
<br />
<h3>
Babel, still a work in progress</h3>
<br />
Babel is still being actively developed, and has a more modern approach to wireless links (something that was near non-existent when RIPng was being standardized back in 1997). Like RIPng, it is easy to set up without having to understand the complexities of OSPF. It is easy to setup on OpenWrt routers and provides redundancy in your network. That said the wireless functionality as implemented by Bird (v 1.63) is not quite there. Fortunately, there is Bird v2.0 out, and I look forward to giving it a try when it comes to OpenWrt.<br />
<br />
<h3>
Postscript</h3>
<br />
Although the route churn has subsided, I re-measured the convergence time for Babel, and it was quite long, <strong>317 seconds</strong>, probably due to the hello timer being set to 5 seconds.<br />
In the end, I reverted my house network to <strong>RIPng</strong>. Running the same convergence test yielded an outage of only <strong>11 seconds</strong> with no route churn.<br />
Perhaps many of the Babel issues are just Bird's implementation. And there may be tweaks to reduce network converge times. I'd happily give Babel another chance, but for now, I'll stick with good ol' RIPng.<br />
<br />
<small></small><br />
<small></small><br />
<small>** if you are running a firewall, the default on OpenWrt/LEDE, you will need to put in a rule to accept IPv6 UDP port 6696</small></div>
<br />
<small>Originally posted (with more detail) on <a href="http://www.makikiweb.com/ipv6/babel.html">www.makikiweb.com</a></small>
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-14820851488692807182018-07-09T13:17:00.001-07:002018-07-09T13:17:33.838-07:00Running an IPv6-only webserver<h4>
by Craig Miller </h4>
<img align="right" src="http://www.makikiweb.com/ipv6/_images/theatermasken_ipv6_sm.png" /><br />
There are times in the long struggle for IPv6 adoption that we forget that <em>dual-stack</em> is not the end goal, but merely a transition mechanism. If we are to get to the end goal, <strong>IPv6 Everywhere</strong> then it isn't enough to have IPv6-only clients on the internet, but also IPv6-only attached content servers.<br />
<br />
<h3>
IPv6-only webserver, easy right?</h3>
<br />
So how hard can it be? Find a hoster which offers IPv6-only attached servers, install apache, or your favourite webserver, and run, right?<br />
Works great for all 20% that are on the IPv6 internet. But for the other 80% of traffic that is on the internet your server is <strong>invisible</strong>. Great if you are running a stealth server, not so great if it represents your business and you wanted your customers to reach your website.<br />
<br />
<h3>
Oh, that legacy protocol, IPv4</h3>
<br />
So not only do you want to have the cool IPv6-ers, but also those legacy IPv4-ers to get to your IPv6-only attached webserver.<br />
One of the techniques to permit IPv4 access to your IPv6-only webserver is to us a HTTP Proxy server. The HTTP Proxy server listens to IPv4 (with a real routable IPv4 address) and then directs traffic to the correct IPv6-only server sitting behind it. Folks have been doing this kind of thing with IPv4 for nearly two decades, the proxy server is also called a <strong>load balancer</strong>.<br />
<img alt="Web Proxy Network" src="http://www.makikiweb.com/ipv6/_images/webproxy_network.png" /><br />
<h3>
Gosh, all my "hits" are from the Proxy Server</h3>
So the Proxy Server does the conversion from IPv4 to IPv6, but now all the webserver log entries are from the Proxy Server.<br />
<pre><code>rproxy46-sov-a.mythic-beasts.com - - [15/Jun/2018:01:36:17 +0000] "GET /...
rproxy46-sov-a.mythic-beasts.com - - [15/Jun/2018:01:38:28 +0000] "POST ...
rproxy46-sov-a.mythic-beasts.com - - [15/Jun/2018:01:38:32 +0000] "GET /...
rproxy46-hex-a.mythic-beasts.com - - [15/Jun/2018:01:45:15 +0000] "POST ...
rproxy46-hex-a.mythic-beasts.com - - [15/Jun/2018:01:45:19 +0000] "GET /...
rproxy46-hex-a.mythic-beasts.com - - [15/Jun/2018:01:45:24 +0000] "POST ...
rproxy46-hex-a.mythic-beasts.com - - [16/Jun/2018:03:09:30 +0000] "GET /...
</code></pre>
Not all that useful for traffic analysis<sup>1</sup>. Fortunately, there is a <strong>Proxy Protocol</strong> which allows the Proxy Server to insert a <strong>X-Forwarded-For:</strong> line into the HTTP header. This line contains the hostname, or IP address of the original requester.<br />
<br />
<h4>
The Proxy Protocol</h4>
<br />
In apache, there is a <a href="https://gitlab.cern.ch/cloud-infrastructure/mod-proxy-protocol"><code>mod-proxy-protocol</code></a> module which interprets the <code>X-Forwarded-For:</code> line as the original requester, and the logs are now restored to what one would expect.<br />
The downside of the <code>mod-proxy-protocol</code> module is that once it is enabled, the server will not respond correctly to a request <em>without</em> the <code>X-Forwarded-For:</code> line. It returns a 502 server error.<br />
Unfortunately, this means that even though the server is IPv6-only connected, it can not receive requests that <strong>do not</strong> go through the proxy. The Proxy Server must be in the data path for <em>both</em> IPv4 and IPv6. For load balancer applications, this is understandable.<br />
However, as a migration tool to enable the IPv6-only server to serve both IPv4 and IPv6 it is an unnecessary over-complication.<br />
Even the <em>improved</em> apache module, <code>mod_remoteip</code> which also implements the Proxy Protocol (as of version 2.4.30), does not permit the Proxy Server to forward only IPv4 traffic, and accept IPv6 traffic natively (e.g. without the proxy server).<br />
<br />
<h3>
Controlling access to the server</h3>
<br />
The old apache 2.2 version of Access Control, using <code>deny from ...</code>, does work in version 2.4 but not with either of modules supporting the Proxy Protocol. To be fair, apache has been stating in their documentation that the old v2.2 way would be deprecated. One must now use the <code>Require not ip ...</code> to work with the <code>mod-proxy-protocol</code> module.<br />
So, it was time to convert my Access List for my server, no time like the present, I guess.<br />
<br />
<h3>
The Downside of using a Proxy server</h3>
<br />
Other transition mechanisms, such as NAT64, are used less and less as more traffic flows over IPv6. Unfortunately, using a Proxy Server to serve IPv4 clients, requires that IPv6 traffic also <em>must</em> use the Proxy server (if proxy protocol is to be used). Which means that as IPv6 traffic increases, the Proxy Serer remains in the data path, abrogating one of the real advantages of an IPv6-only server, a <em>direct</em> connection.<br />
<br />
<h3>
Wrapping up</h3>
<br />
So the good news is that it is really easy to put content on IPv6 with an IPv6-only server. The less good news is that the content can also be served to IPv4 clients, but it is overly complicated to do so and in the 21<sup>st</sup> century, it shouldn't be this hard.<br />
<br />
<small><strong>Note 1:</strong> Sure you <em>could</em> use Google-Analytics, or something equivalently convenient, but I would rather analyze my own data. Google doesn't need to know <em>everything</em> about me.</small><br />
<small><br /></small>
<span style="font-size: x-small;">Article originally appeared on <a href="http://www.makikiweb.com/ipv6/ipv6_only_webserver.html">www.makikiweb.com</a></span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-72894365116621214452018-03-08T08:37:00.001-08:002018-03-08T08:37:12.837-08:00IPv6 Printer Support: Finally getting there<h4>
by Craig Miller</h4>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvwW2wEN1-m_fI7Kcu0ErpgSXHzuKczcmY6g2-b8g8fUFTIqcD8NbmCLRkLerVqZLeDaiPhApQGFdSfNKZFhrWwK0QmTCUJU9P6w6yYqa-r1VyII4yshaUGxWkHv2HUFolFgFiZyDdYR3I/s1600/Brother-HL-L2360DW_image.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="656" data-original-width="970" height="135" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvwW2wEN1-m_fI7Kcu0ErpgSXHzuKczcmY6g2-b8g8fUFTIqcD8NbmCLRkLerVqZLeDaiPhApQGFdSfNKZFhrWwK0QmTCUJU9P6w6yYqa-r1VyII4yshaUGxWkHv2HUFolFgFiZyDdYR3I/s200/Brother-HL-L2360DW_image.jpg" width="200" /></a></div>
I recently replaced my printer with a Brother laser printer. I was pleasantly surprised with the level of IPv6 support. Although the printer includes WLAN support, I already had an ethernet cable in place, and it was a snap to connect to the network.<br />
<br />
The UI designers of printers long ago realized that the small 20 character display is too limited to provide useful information, and instead there are options to print out full pages of info, including the Network Info. On this, I could not only see the usual IPv4 info, but also the SLAAC address that the printer had picked up.<br />
<br />
<h4>
Typing in the SLAAC address only once</h4>
<br />
Armed with the SLAAC address, I updated my local DNS server, since I really only wanted to type the IPv6 address once. Once that task was done, it was a snap to log into the printer's management web page over IPv6 using the DNS name.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3yhYkno1Xuro8Co6Q9ZfweQueyRdH8C6Rh64tIu1E_cvxAPJTAgIcWKwJ4cX2Ttelm7TcEYwWX44FfusSTAqk2u-Q_yB2wS5Mts_7FSlldIpvVeQRvXgzhg-xtQ7btZ9YW_JfRyQNlTjw/s1600/brother_printer_ip6_page.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="589" data-original-width="1067" height="352" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3yhYkno1Xuro8Co6Q9ZfweQueyRdH8C6Rh64tIu1E_cvxAPJTAgIcWKwJ4cX2Ttelm7TcEYwWX44FfusSTAqk2u-Q_yB2wS5Mts_7FSlldIpvVeQRvXgzhg-xtQ7btZ9YW_JfRyQNlTjw/s640/brother_printer_ip6_page.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv6 info</td></tr>
</tbody></table>
<br />
<br />
Of course, IPv6 support isn't perfect. There is no DHCPv6 support, and the IP Filtering feature is still IPv4-only. So the next step for Brother is feature parity, but it is a good start.<br />
<br />
<h4>
Investigating IPv6 Printer Services</h4>
<br />
Even without feature parity, a quick scan by nmap reveals that the printing services are also available over IPv6.<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-05 09:16 PST</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Nmap scan report for 6kunane.hoomaha.net (2001:470:ebbd:0:3e2a:f4ff:fe37:dac4)</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Host is up (0.010s latency).</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Not shown: 995 closed ports</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">PORT STATE SERVICE</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">80/tcp open http</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">443/tcp open https</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">515/tcp open printer</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">631/tcp open ipp</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">9100/tcp open jetdirect</span><br />
<div>
<br /></div>
<h4>
Printing from an IPv6-only network</h4>
<br />
And I was able to successfully print to the Brother printer which sits on my dual-stack network from my IPv6-only network. Kudos to Brother.<br />
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com2tag:blogger.com,1999:blog-455385287674190554.post-23142292179036389802018-01-17T08:50:00.000-08:002018-01-17T08:50:24.342-08:00Writing IPv6 Apps: Python Webserver<h4>
by Craig Miller</h4>
<div>
<br /></div>
<img align="right" src="https://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Python3-powered_hello-world.svg/320px-Python3-powered_hello-world.svg.png" />
Moving to IPv6 starts at home. Applications have to speak IPv6 as well as the network. The good news is that there is lots of software available which already supports IPv6. Unfortunately, there is much more that doesn't.<br />
<br />
For example, a Python-based webserver. Certainly not ready for a production network, but handy as a learning tool about how easy it can be to support IPv6 in your application.<br />
<br />
Why Python? Python is a wonderful programming language, and getting only better with version 3. There are libraries for most needs, including one which serves up the web. And it runs just about anywhere that Python runs (Windows, Linux, BSD, Mac, Pi, ODROID, etc)<br />
<br />
<h3>
Python module SimpleHTTPServer</h3>
<br />
The python module <code>SimpleHTTPServer</code> supports IPv4 out of the box with the simple command:<br />
<pre><code>python -m SimpleHTTPServer
</code></pre>
However it does <strong>not</strong> support IPv6. There is no one-line equivalent to support IPv6, so a small script is required.<br />
<br />
<h3>
Looking at the code</h3>
<br />
The <code><a href="https://github.com/cvmiller/ipv6-httpd">ipv6-httpd</a></code> script is a short script supporting both IPv4 and IPv6. Looking at the following sections:<br />
<ol>
<li>Initialization of the HTTPServer object (from SimpleHTTPServer library)</li>
<li>Class creation (of HTTPServerV6) to support IPv6</li>
</ol>
As with all Python scripts, the details roll backwards from the bottom. Initialization occurs in <code>main</code><br />
<pre><code>def main():
global server
server = HTTPServerV6(('::', listen_port), MyHandler)
print('Listening on port:' + str(listen_port) + '\nPress ^C to quit')
server.serve_forever()
os._exit(0)
</code></pre>
<h4>
The IPv6 part</h4>
<br />
In order to support IPv6, we use a bit of object oriented inheritance trickery to modify the default of an existing class <code>HTTPServer</code><br />
<pre><code>class HTTPServerV6(HTTPServer):
address_family = socket.AF_INET6
</code></pre>
This creates a new class (which is used in our <code>server</code> ) with the address_family set to AF_INET6 (aka IPv6). This two-line change to the script transforms an IPv4-only script into an application that also supports IPv6.<br />
<br />
<h3>
Running the code</h3>
<br />
Now that we have a server which supports both IPv4 and IPv6, all we need to do is <code>cd</code> to the directory we wish to share, and start the server<br />
<pre><code>$ cd public/
$ ~/bin/ipv6-httpd.py
Listening on port:8080
Press ^C to quit
2001:db8:ebbd:0:4d18:71cd:b814:9508 - - [09/Jul/2017 11:49:41] "GET / HTTP/1.1" 200 -
^CCaught SIGINT, dying
</code></pre>
The webserver <em>log</em> is sent to standard out (stdout), and can be redirected to a file if desired. In the above example, an IPv6 client <code>..:9508</code> requests an index, then the server is terminated with a ^C.<br />
Want to server from a different directory? Stop the server, <code>cd</code> to another directory, and restart the server, it will now serve files from the new current working directory (cwd) location.<br />
<br />
<h3>
Security (or lack there of)</h3>
<br />
This example is a <strong>personal</strong> webserver, designed to be started and stopped whenever you need it. It is <strong>NOT</strong> a production quality webserver that you should put on the internet. However it shows that supporting IPv6 doesn't have to be a hardship.<br />
<br />
<h3>
Adding IPv6 Support to your App</h3>
<br />
As you can see, it doesn't have to be difficult to add IPv6 to your apps, you just need to give it some thought when planning your App. By adding IPv6, you will future proof your App by being ready for the future of the Internet.<br />
<br />
<h4>
<br /></h4>
<ul>
<li>the <a href="https://github.com/cvmiller/ipv6-httpd">ipv6_httpd.py script</a> can be downloaded from github</li>
</ul>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-64686571309447199532017-11-19T09:50:00.001-08:002017-11-19T09:50:55.431-08:00Filtering Fragments<h4>
by Craig Miller</h4>
<div>
<br /></div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghEXweu5e0te86Ci1Ck0MG49AcOl-Zg5W2PZ1HsOi-ixkwUwZLMKl0-CWrXq05KbQZr00BK-zmMGLzDRsTHvsbtU3nnprRwkkvyX12DKVZKnsXoLaFkhJFNMXPGhDcnNMTlGVpGWf89o-w/s1600/crevasse_jump_billy_by_james_ho.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="496" data-original-width="451" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghEXweu5e0te86Ci1Ck0MG49AcOl-Zg5W2PZ1HsOi-ixkwUwZLMKl0-CWrXq05KbQZr00BK-zmMGLzDRsTHvsbtU3nnprRwkkvyX12DKVZKnsXoLaFkhJFNMXPGhDcnNMTlGVpGWf89o-w/s320/crevasse_jump_billy_by_james_ho.png" width="290" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Overcoming fragmentation</td></tr>
</tbody></table>
Fragmentation is different in IPv6, end stations perform fragmentation, not routers. That said, there are valid security concerns about exploits which hide the true contents of a packet by encapsulating it in a fragmentation extension header. (see <a href="http://ipv6-net.blogspot.com/2015/12/little-bitsy-pieces.html">Little bitsy pieces</a>) But one needs to be careful about filtering all packets with fragmentation headers.<br />
<br />
<h4>
Filtering all Fragmentation Headers can lead to DNS failures</h4>
Case in point, Google's public IPv6 DNS servers until recently (Oct 2017) were clearly <a href="https://blog.apnic.net/2017/11/13/google-fixes-public-dns-service/">filtering fragmented responses</a> (from authoritative servers). Small requests would succeed while large requests would fail.<br />
<br />
<h4>
Careful with that Axe Eugene</h4>
<div>
While is is a good idea to filter extension headers, such as the fragmentation header when the packet is on link (<span style="font-size: 1em;">Advice for IPv6 Router Advertisement Guard <a href="https://tools.ietf.org/html/rfc7113#page-4">RFC 7113</a>)</span>. One should <b>not</b> apply a blanket filter to all fragmented packets. Although PMTUD (Path MTU Discovery) is quite good at reducing fragmentation, there are valid reasons why a packet, such as a DNS response with many IPv6 addresses, could be fragmented.</div>
<br />
Be careful with filters/ACLs/Firewall Rules, and be sure you are only filtering unwanted traffic.<br />
<br />
<br />
* creative commons photo by <a href="https://www.flickr.com/photos/mankitho/4057098557/in/photostream/">James Ho</a>Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com1tag:blogger.com,1999:blog-455385287674190554.post-74789216256434774332017-09-26T10:52:00.000-07:002017-09-26T10:52:56.777-07:00Request: Less Dynamic Prefix, Mr./Ms. ISP<h4>
by Craig Miller</h4>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxqtzUd9lk9qHEw2hQ_ZUtR5p1hmPFw8qC2munEqQcgh6DDbebw_g_kKaWQIWMzF4BT5ycIjMC_o7wU7P543fZKrQiPUhIPUBOOtEN0H38Q8bQKQWNbKZr9tlGROwLYXEMCJjiWRpyq9oS/s1600/server_rack_router_ulu%252B.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="683" data-original-width="800" height="273" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxqtzUd9lk9qHEw2hQ_ZUtR5p1hmPFw8qC2munEqQcgh6DDbebw_g_kKaWQIWMzF4BT5ycIjMC_o7wU7P543fZKrQiPUhIPUBOOtEN0H38Q8bQKQWNbKZr9tlGROwLYXEMCJjiWRpyq9oS/s320/server_rack_router_ulu%252B.jpg" width="320" /></a></div>
There are two types of Global Prefixes, one that is provider independent (PI), allowing one to switch ISPs and keep the same prefix, and the other is provider aggregatable (PA), where the upstream provider allocates a prefix from their block.<br />
<br />
PIs are great, and one need only go to your local <a href="https://www.ripe.net/participate/member-support/copy_of_faqs/isp-related-questions/pa-pi">RIR</a> (Regional Internet Registry) to request/pay for a prefix block. But realistically, only larger organizations will go this route. Many smaller organizations and homes will use PA prefixes.<br />
<br />
<h4>
PA made easy</h4>
Through the magic of DHCPv6-PD (DHCPv6 with Prefix Delegation), allocating a prefix (either a /64 or less) to a small business or home is easy. Modern routers will make the PD request, and advertise the allocated prefix into the SOHO/home LAN, and IPv6 end to end connectivity is available.<br />
<br />
ISPs are used to having their customers have a dynamic DHCPv4 address. But with many ISPs, a router reboot will result in the same IPv4 address, since the router is using the same MAC address to make the request.<br />
<br />
With DHCPv6, a DUID (DHCP Unique Identifier) is used rather than a MAC address. But similar to the MAC address in DHCPv4, the DUID does not change between router reboots, and therefore DHCPv6 requests can receive the same external IPv6 address on the router.<br />
<br />
<h4>
PA Prefix disconnect</h4>
Alas, this is not the same for PA prefixes. Inside the ISP, there seems to be <i>no</i> connection between DHCPv6 address allocated and PD prefix allocated to the customer. This results in a semi-static outside IPv6 address on the router, and a <i>very dynamic</i> (changing with every connection/reboot) PD prefix in the customer's LAN.<br />
<br />
A very dynamic LAN prefix causes some challenges, such as:<br />
<br />
<ul>
<li>downstream routers, may not update to the new prefix in a timely manner causing unknown network outages which are mysteriously fixed by rebooting</li>
<li>Some DNS sserver configuration requires a Global Address, if the SOHO/home is using its own DNS server, or a DNS service other than the ISPs, this configuration may require updating with each new PD prefix</li>
<li>Network servers on the LAN will have changing IPv6 addressesj, making file sharing, and other network services difficult</li>
<li>Firewall configuration, allowing external access</li>
</ul>
<br />
Some of these issues can be mitigated by using a ULA (Unique Local Address) prefix on the LAN in addition to the ISPs <i>very dynamic</i> PA GUA prefix. But that requires more IPv6 knowledge than just plug in play.<br />
<br />
<h4>
Please, a less dynamic PA prefix</h4>
Dear Mr./Ms. ISP, I would like to have less dynamic PA addresses. As a customer, I would like to have the address prefix (assigned via PD) linked with my DUID and DHCPv6 address records. At the end of the day, we all want IPv6 to be simpler for the customer.<br />
<br />
<br />
<span style="font-size: x-small;">* note, a provider provides a PA address via DHCPv6-PD (Prefix Delegation)</span><br />
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com1tag:blogger.com,1999:blog-455385287674190554.post-14110388109010986692017-07-17T03:29:00.000-07:002017-07-17T03:29:04.688-07:00Shooting fish in a barrel<h4>
by Craig Miller</h4>
<br />
I say this often, IPv6 is not like IPv4. There are key differences which one can and should take advantage of.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6Jn8xUlzO9i3lPxjtHK9_Nsv3NvjJ4cXIqnUBu8OtGhxW243XSHyvFNFyTHss0bJueKMoGTXKNuvjqeAHeCA5fI4RpPhDAECfZDeCWxF3oJz800xhLXOT6AFtQExR_1YZ_GoBKoucNdhS/s1600/shooting_fish_in_a_barrel_duck_hunting.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="511" data-original-width="420" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6Jn8xUlzO9i3lPxjtHK9_Nsv3NvjJ4cXIqnUBu8OtGhxW243XSHyvFNFyTHss0bJueKMoGTXKNuvjqeAHeCA5fI4RpPhDAECfZDeCWxF3oJz800xhLXOT6AFtQExR_1YZ_GoBKoucNdhS/s320/shooting_fish_in_a_barrel_duck_hunting.jpg" width="263" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Like shooting "fish" in a barrel</td></tr>
</tbody></table>
Address space is one of them. Scanning an IPv4 address range takes very little time. And the return is rich, with the conservation of address space mind-set, the hosts/targets are closely packed in an IPv4 subnet. It is like shooting fish in a barrel.<br />
<br />
<h4>
Malware using the zmap scanner</h4>
A recent Linux malware <a href="https://vms.drweb.com/virus/?_is=1&i=15389228">Linux.MulDrop.14 </a>uses the scanner, <span style="font-family: "courier new" , "courier" , monospace;">zmap</span>, to search for other victims on the network. Zmap man page boasts that given a 1 Gbit connection to the internet, it can scan the entire internet in 45 minutes. Of course, it isn't the <i>entire</i> internet, since <span style="font-family: "courier new" , "courier" , monospace;">zmap</span> doesn't support IPv6 (yet). So what it is really saying is that it can scan 2^32 (or 4 billion) addresses in about 45 minutes.<br />
<br />
<h4>
The numbers of high performance scanning in IPv6</h4>
So let's work with that number for a minute. Assuming that <span style="font-family: "courier new" , "courier" , monospace;">zmap</span> and other scanners will support IPv6 in the future, how much time will it take to scan a /64 with a high performance scanner like <span style="font-family: "courier new" , "courier" , monospace;">zmap</span>. How many 2^32 chunks are in a /64? Conveniently the answer is 2^32 or 4 billion internets (of addresses) in each /64 subnet.<br />
<br />
So given that it takes 45 minutes to scan 4 billion addresses, how long would it take to scan a /64? It should be 4 billion times 45 minutes or <b>367,719 years</b>. As you can see, what looks to be a high performance IPv4 scanner, is quite impracticable for scanning IPv6 subnets.<br />
<br />
But that is based on the assumption that the IID (Interface IDs) are taking the entire /64 range. I have seen many DHCPv6 installations where the IPv6 address range is much smaller, as small as /119 or 512 addresses! Clearly, one does not need a high performance scanner to scan 512 addresses. In fact, tightly restricting the IPv6 address space (via your DHCPv6 pool) in a subnet is asking scanners to target your hosts.<br />
<br />
<h4>
Make it harder for the bad guys, don't confine your hosts to a barrel</h4>
Use the advantages of IPv6 when creating your network, including utilization of very large DHCPv6 address pools. After all, you don't want the bad guys finding your hosts, to be like shooting fish in a barrel.<br />
<br />
<br />
<span style="font-size: x-small;">* graphic from <a href="https://ralphiesportal.me/2014/11/22/like-shooting-fish-in-a-barrel-lol/">ralphiesportal.me</a></span><br />
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-20436232101265144382017-05-28T14:49:00.001-07:002017-05-28T14:49:59.013-07:00IPv6 on the Go<h4>
by Craig Miller</h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwRjD7g7Bo3IvFb_qT06OSX4447tAZlG-rbL0tyVTqVW8AVIJhcMb2SyRbAyPfXji-EhWlh_pTXBTvnf6hXCpuLx266OjlLFhgETYdPIbQrKjwJTCtIRWYp_x9hNf2qhPyzM-JRxcPM1Nh/s1600/verizon_jetpack_4g_wifi_ipv6_router%252B.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwRjD7g7Bo3IvFb_qT06OSX4447tAZlG-rbL0tyVTqVW8AVIJhcMb2SyRbAyPfXji-EhWlh_pTXBTvnf6hXCpuLx266OjlLFhgETYdPIbQrKjwJTCtIRWYp_x9hNf2qhPyzM-JRxcPM1Nh/s200/verizon_jetpack_4g_wifi_ipv6_router%252B.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv6 on the go</td></tr>
</tbody></table>
Here's another example of I<a href="http://ipv6-net.blogspot.com/2016/11/ipv6-in-palm-of-your-hand.html">Pv6 in the palm of your hand.</a> This time it is a small battery-powered wireless router, smaller than a deck of playing cards. The router has 4G on the WAN, and Wifi on the LAN side.<br />
<br />
<h4>
Wireless Hotspot</h4>
<br />
While visiting with my cousin recently, he said he needed help upgrading his wireless router. I am always happy to help when I can. He was having all sorts of trouble getting the windows software to work. Being used to not running windows apps (I mostly run Linux), I looked for the upgrade option on the web interface on the router. There is usually lots of room for improvement in web user interface design for embedded devices, and little router was no exception. It took a bit of perusing the menus to find the upgrade option, but once done, the router was upgraded and it was then that I noticed that the little 4G router not only was doing IPv4 NAT (expected), but was also providing IPv6 on the LAN (Wifi) side.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx2NaROVB08DY8sq95RgEMtEfQPWWiwTjkWLVKqFroY3hm4xd4ZNYMLoMp2CaSFJWt2iYedFD9SjMVBfweUCGKPzRb1NFZ2j6WULTKc0UUVUof0uJxPgBf5DCaJxZXzAWcEN95zyzhFwmt/s1600/verizon_jetpack_web_info%252B.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="520" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx2NaROVB08DY8sq95RgEMtEfQPWWiwTjkWLVKqFroY3hm4xd4ZNYMLoMp2CaSFJWt2iYedFD9SjMVBfweUCGKPzRb1NFZ2j6WULTKc0UUVUof0uJxPgBf5DCaJxZXzAWcEN95zyzhFwmt/s640/verizon_jetpack_web_info%252B.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Note the IPv6 Address at the bottom</td></tr>
</tbody></table>
Verizon won't sell you a Jetpack router, but they will rent/lease it to you, adding about $10 to your monthly service bill.<br />
<br />
<h4>
Looking under the covers</h4>
<br />
Digging into the router a bit more, the router has a GUA (Global Unique Address) on the LAN side, which would appear that the router is doing DHCPv6-PD on the WAN (rather than running a proxy service and extending the /64 from the Service Provider <a href="https://tools.ietf.org/html/rfc7278">RFC 7278</a>).<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">$ ./v6disc</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">-- INT:wlan0<span class="Apple-tab-span" style="white-space: pre;"> </span>prefixs: 2600:1003:b458:e277 </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">-- Detecting hosts on wlan0 link </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">-- Discovered hosts for prefix: 2600:1003:b458:e277 on wlan0 </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">2600:1003:b458:e277:216:8ff:fe00:3 <--- Jetpack </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">2600:1003:b458:e277:f203:8cff:fe3f:f041 </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">-- Pau </span><br />
<br />
Probing the Jetpack a bit more, we see that it is listening on telnet & DNS on IPv6, and the web interface is <i>only</i> available on IPv4<br />
<span style="font-family: "courier new" , "courier" , monospace;">$ nmap -6 -sT </span><span style="font-family: "courier new" , "courier" , monospace;">2600:1003:b458:e277:216:8ff:fe00:3</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-25 17:44 EDT</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Nmap scan report for 2600:1003:b458:e277:216:8ff:fe00:3</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Host is up (0.021s latency).</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Not shown: 998 closed ports</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">PORT STATE SERVICE</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">23/tcp open telnet*</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">53/tcp open domain</span><br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">$ nmap -sT </span><span style="font-family: "courier new" , "courier" , monospace;">192.168.1.1</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-25 17:46 EDT</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Nmap scan report for my.jetpack (192.168.1.1)</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Host is up (0.012s latency).</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Not shown: 997 closed ports</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">PORT STATE SERVICE</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">23/tcp open telnet</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">53/tcp open domain</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">80/tcp open http</span><br />
<br />
The Jetpack router is made for Verizon by <a href="http://franklinwireless.com/about-us/technology/mobile/hotspot/">Franklin Wireless Corporation</a> (based on the MAC address) which has their own product line of mobile hotspots, and runs for hours on the internal battery.<br />
<br />
<h4>
IPv6 Everywhere, even in Hotspots</h4>
<br />
We have grown used to firing up a hotspot on our phones to give access to laptops, etc when there is no Wifi available. IPv6 is the future internet protocol with less latency (no NAT) and t is great to see that Service Providers like Verizon are also supporting IPv6 connectivity on their portable hotspots.<br />
<br />
<br />
<span style="font-size: x-small;">* Although the telnet port is open, one can not telnet to it, as it immediately disconnects</span><br />
<span style="font-size: x-small;"><br /></span>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com1tag:blogger.com,1999:blog-455385287674190554.post-25471719622726137052017-05-08T11:29:00.000-07:002017-05-08T11:29:55.534-07:00Windows 10 now runs in SLAAC Networks<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEXq_kqVahhTwM0cZsf0OmGKYMk_tu9EKwD19Y5UVgmDkGNQnbINo1Kpi-wIiD1dPWV3j-b6skR-mzpYUEClxFLVHTrQYkmqdabIjUTX9WXJW0noE_dZ4h0hQ58Dep9aGOeVLPFX-rwStJ/s1600/windows-10-logo.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEXq_kqVahhTwM0cZsf0OmGKYMk_tu9EKwD19Y5UVgmDkGNQnbINo1Kpi-wIiD1dPWV3j-b6skR-mzpYUEClxFLVHTrQYkmqdabIjUTX9WXJW0noE_dZ4h0hQ58Dep9aGOeVLPFX-rwStJ/s200/windows-10-logo.png" width="200" /></a></div>
<h4>
by Craig Miller</h4>
<br />
Microsoft released the Creator Update last month (11 April 2017) with lots of interesting stuff. But the most interesting for IPv6 is support for the RDNSS field in the RA (Router Advertisement). The RDNSS field is the one that carries DNS server information in the RA.<br />
<br />
In order to run an IPv6-only SLAAC-based network the host must need 2 things: an address, and the address of a DNS server. Without DNS, IPv4 or IPv6 is pretty useless these days.<br />
<br />
<h4>
Windows 10 and SLAAC Requirements</h4>
<div>
<br /></div>
<div>
In order to see the new feature in action, the Windows 10 machine must:<br />
<div>
<ul>
<li>Be in a IPv6-only network (no IPv4) </li>
<li>Hear a RA (Router Advertisement) without the M-bit set (or DHCPv6 disabled). </li>
</ul>
Of course, it would be good if your router was sending RDNSS in the RA. </div>
<div>
<div>
<br /></div>
<h4>
Windows 10 SLAAC-only Details</h4>
<div>
<br /></div>
<div>
In this environment, the output of <span style="font-family: "courier new" , "courier" , monospace;">ipconfig</span> is still a little misleading:</div>
<div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">C:\Users\Craig>ipconfig /all</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;"></span><br />
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Ethernet adapter Ethernet:</span></div>
<span style="font-family: "courier new" , "courier" , monospace;">
</span>
<div>
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span></div>
<span style="font-family: "courier new" , "courier" , monospace;">
<div>
Connection-specific DNS Suffix . : lan</div>
<div>
Description . . . . . . . . . . . : Realtek PCIe GBE </div>
<div>
...<br />
DHCPv6 IAID . . . . . . . . . . . : 75761763<br />
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-A3-2E-82-80-FA-5B-96-37-56</div>
<div>
<div>
DNS Servers . . . . . . . . . . . : fdf7:56a9:b7af:1101::1</div>
</div>
<div>
<div>
Connection-specific DNS Suffix Search List :</div>
<div>
lan</div>
</div>
<div>
<br /></div>
</span></div>
<div>
The DNS Server field is now showing my RDNSS address (the ULA address of my router) and DNSSL (DNS Search List)!<br />
<br />
Another way to confirm the DNS servers that Windows 10 knows about is with a netsh command:<br />
<span style="font-family: "courier new" , "courier" , monospace;">C:\Users\Craig>netsh int ipv6 show dnsservers</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">Configuration for interface "Ethernet"</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> DNS servers configured through DHCP: fdf7:56a9:b7af:1101::1</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> Register with which suffix: Primary only</span></div>
<div>
<br /></div>
<div>
Running a quick check to see if it can actually resolve an address using only RDNSS:</div>
<div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">C:\Users\Craig>nslookup www.google.com</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Server: OpenWrt.lan</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Address: fdf7:56a9:b7af:1101::1</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Non-authoritative answer:</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Name: www.google.com</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">Addresses: 2604:470:4001:806::2004</span></div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;"> 172.217.29.164</span></div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<h4>
Now it is possible to run simplified (SLAAC) networks</h4>
<div>
<br /></div>
<div>
The fact that MS is now supporting SLAAC-only networks is a huge shift from their previous DHCPv6 only stance. Why is this important? Because there are use-cases for SLAAC-only networks, and now not only can you use your Android devices (which don’t do DHCPv6) but also your Windows 10 machines as well.<br />
<br />
Windows continues to dominate the PC market with about 85%. Now with Windows 10 Creator Update, there is no excuse to not deploy IPv6 in your network now.<br />
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
* adapted from my<a href="http://ipv6hawaii.org/?p=273"> ipv6hawaii.org</a> article<br />
** Win10 details from André Lange, author of <a href="https://github.com/AndreBL/ip6neigh">ip6neigh</a></div>
<div>
<br /></div>
</div>
</div>
</div>
</div>
Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com6tag:blogger.com,1999:blog-455385287674190554.post-19100456072851356462017-05-04T09:15:00.000-07:002017-05-08T16:32:44.130-07:00North American IPv6 Summit<h4>
by Craig Miller</h4>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKjc1dc1nwguF20_lP6v9M-u-vDllWsvkVi6tHURUxducY_Cyk5eewgQzsoW_-6Nfs6ppPHTHZcSEwFXjLA-TEsRh4SyYukkveTKDWtw0rGj5nWF0CZsofVWE1A__MVNdwfdaNmdcDQWUf/s1600/nav6tf.logo_.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKjc1dc1nwguF20_lP6v9M-u-vDllWsvkVi6tHURUxducY_Cyk5eewgQzsoW_-6Nfs6ppPHTHZcSEwFXjLA-TEsRh4SyYukkveTKDWtw0rGj5nWF0CZsofVWE1A__MVNdwfdaNmdcDQWUf/s1600/nav6tf.logo_.jpg" /></a></div>
The North American IPv6 Summit was held in Sunnyvale last week. It is always a pleasure to be in a large room with people who <b>get it</b>. There is no convincing that we need to give up our comfortable Linus-blanket of IPv4 for something new and different. No, everyone in the room is a convert, and many are outspoken advocates.<br />
<br />
The conference was organized by the regional IPv6 Task Forces: <a href="http://www.cav6tf.org/">California IPv6 Task Force</a>, <a href="http://www.rmv6tf.org/">Rocky Mountain IPv6 Task Force</a>,<a href="http://www.txv6tf.org/"> Texas IPv6 Task Force</a>, and <a href="http://www.mx.ipv6tf.org/">Mexico IPv6 Task Force</a>.<br />
<br />
<h4>
Speakers, shakers and movers</h4>
Some of the speakers were:<br />
<br />
<ul>
<li><b>Tony Scott,</b> the former CIO of the Unitied States of America</li>
<li><b>John Curran</b>, the President and CEO of ARIN (American Registry for Internet Numbers)</li>
<li><b>Kevin Jones</b>, Chair for IPv6 transition at NASA</li>
<li><b>John Brzozowski</b>, Chief Architect, IPv6 and Fellow, at Comcast</li>
</ul>
<div>
<br /></div>
<h4>
Major Points</h4>
<div>
So if everyone is a convert, there's nothing to talk about, right? Actually there are quite a few things. Some of the key points made at this year's conference were:</div>
<div>
<ul>
<li><b>Dual-stack is only half way</b>. We need to start moving to IPv6-only networks. There were presentations on how Cisco, Microsoft, and Comcast are doing just that.</li>
<li><b>IPv6 impacts on Cloud Computing, and IoT</b>. A case study of BC Hydro operating 2 million smart meters (IoT) all on IPv6.</li>
<li><b>Content is being delivered over IPv6</b>, thanks to CDN (Content Delivery Networks), like Akamai and Cloudfare, fronting IPv4-only legacy sites.</li>
<li><b>Microsoft adds SLAAC capability to Windows 10</b>, <a href="http://ipv6hawaii.org/?p=273">Creator Update</a> (11 April 2017). Now it is possible to have Windows and Android on the same SLAAC (Stateless Address Auto Config) IPv6-only network!</li>
</ul>
<div>
<br /></div>
</div>
<br />
<h4>
Missed it? Here's the presentations</h4>
Thanks to all the volunteers of the regional task forces, and Linked-in for hosting the conference. The <a href="http://www.rmv6tf.org/na-ipv6-summit/2017-north-american-ipv6-event/2017-speaker-presentations">presentations</a> are posted online, in case you didn't make it down to Sunnyvale last week. Hope to see you there next time.<br />
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-46807948988027764782017-04-14T09:11:00.000-07:002017-04-14T17:27:42.555-07:00Using ULAs for VPNs<h4>
by Craig Miller</h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-7DHyX4yaAuCuhV7Kcc19hhW0C830TAqQxPIYQXXfj7vX3HvyzNhL9HcoI5zkPvDivRqdM_4X1bGuEykbV1fBQnemJb5g8ENFmu0Hkh5icMGIU9qjlLM8BkfzNgQkQdDKJFUpAtfxGbgA/s1600/UULLAA.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="Credit: http://www.thewaroftheworlds.com/archive/games-e.aspx" border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-7DHyX4yaAuCuhV7Kcc19hhW0C830TAqQxPIYQXXfj7vX3HvyzNhL9HcoI5zkPvDivRqdM_4X1bGuEykbV1fBQnemJb5g8ENFmu0Hkh5icMGIU9qjlLM8BkfzNgQkQdDKJFUpAtfxGbgA/s200/UULLAA.jpg" title="" width="195" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">War of the Worlds</td></tr>
</tbody></table>
It has taken me some time to warm up to the idea of using ULAs (Unque Local Addresses), as it initially seemed like we were heading down the same private address problems that we have in IPv4. And I can't see ULA and not think of the sound the Martians made in H.G. Well's War of the Worlds.<br />
<br />
But I have found a few really good reasons to use ULAs:<br />
<br />
<ul>
<li><b>DNS</b> stability: ISP is constantly changing GUA (Global Unique Address) PA (Provider-aggregatable) prefixes, and you have servers on your network that you would like to use DNS (Domain Name Service) to make life easier</li>
<li><b>Security</b>: You have servers on your network which don't need internet access, but you want to access them via IPv6</li>
<li><b>VPN</b>: Creating a VPN (Virtual Private Network) across several sites, all sharing the same ULA prefix (the 48 bit prefix).</li>
</ul>
<br />
<h4>
ULAs made easy</h4>
<div>
It is this last use case, I'd like to discuss a bit more in this blog. According to <a href="https://tools.ietf.org/html/rfc4193">RFC 4193</a>, one should generate a 40 bit random hex number which is appended to FD, e.g. fd84:ac67:c214::/48. Fortunately, there are convenient tools on the internet to help with this, such as the <a href="http://unique-local-ipv6.com/#">Unique Local IPv6 Generator.</a> </div>
<div>
<br /></div>
<div>
However, if one is to create a VPN of several sites, the routing is much easier if a common ULA /48 prefix is used. With some address planning it is quite easy to give each site a /56 or 255 prefixes per site. In the following example, a hub and spoke topology is used, but with a small number of nodes, a mesh topology could be employed.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJN27xl246FQrUnuyCAbjvb2DeuKs-Bd3UYdGNjIyH_GY31IcmmnrIBULArrrA7Khoqw29DVyPWzt7dlWuUB3dnqlxzKS6UeJyjydGXFXbiy3lQUEbPFC44tEHSqyhssVBS055BEw8leE7/s1600/vpn_ula.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJN27xl246FQrUnuyCAbjvb2DeuKs-Bd3UYdGNjIyH_GY31IcmmnrIBULArrrA7Khoqw29DVyPWzt7dlWuUB3dnqlxzKS6UeJyjydGXFXbiy3lQUEbPFC44tEHSqyhssVBS055BEw8leE7/s400/vpn_ula.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">VPN using fd01:db8:9::/48 ULA prefix</td></tr>
</tbody></table>
<div>
ULAs also effectively eliminate the IPv4 Duplicate address problem. A common problem when using IPv4 is accessing a corporate RFC 1918 network, such as 192.168.0.0/16 from a hotel which is also using the 192.168.0.0 network. Routing is confused, and packets don't make it to the corporate network. Because ULAs have randomized 40 bits of the prefix, as per <a href="https://tools.ietf.org/html/rfc4193">RFC 4193</a>, the likelihood of duplicate subnets is a extremely low.<br />
<br />
Because IPv6 uses multiple addresses, each site will have different GUA prefixes, and in fact, could be different ISPs. The PA (Provider Agregatable) GUA Prefixes can even change without changing the VPN setup. This is equivalent to the old IPv4 split-tunnel, where internet access doesn't have to be back-hauled to a central site, which results in faster internet access.</div>
<br />
<br />
<div>
<br /></div>
<h4>
OpenWrt and IPv6 VPNs</h4>
<div>
<a href="https://openwrt.org/">OpenWrt</a> supports <a href="https://wiki.openwrt.org/doc/howto/vpn.openvpn">OpenVPN</a>, where the VPN links can be setup to use underlying IPv4 or IPv6 for transport. In addition, OpenWrt also supports <a href="https://github.com/AndreBL/ip6neigh">ip6neigh</a>, a DNS solution for IPv6 on home routers, with each site having a unique user-defined top domain name (typically .lan, but it is configurable).</div>
<br />
<br />
<h4>
Don't fear the ULAs</h4>
So don't fear the UUULLLAAs, ULAs are good for creating stability in a address-changing IPv6 world.<br />
<br />
<br />
<span style="font-size: x-small;">* Photo Credit: http://www.thewaroftheworlds.com/archive/games-e.aspx</span>Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-44803955195600012832017-03-19T21:48:00.000-07:002017-03-19T21:48:03.467-07:00Breath deeply, a /64 is a good thing<h4>
by Craig Miller</h4>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlwiZA0Oa99gpXP5jxIMlS686YserGmXcRCUQ0YdGTYdcdeuq8NAEqm-Y8qBlICYaGQl7Ttjjyj4dSi6RWvtsLUcDeKacKHM4ZYwxtwfen3B80nOGKMDBjFqZ33EAqRyUYA_ajBY0PTKUl/s1600/Meditation_sq.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="291" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlwiZA0Oa99gpXP5jxIMlS686YserGmXcRCUQ0YdGTYdcdeuq8NAEqm-Y8qBlICYaGQl7Ttjjyj4dSi6RWvtsLUcDeKacKHM4ZYwxtwfen3B80nOGKMDBjFqZ33EAqRyUYA_ajBY0PTKUl/s320/Meditation_sq.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Earth's atmosphere is vast</td></tr>
</tbody></table>
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.<br />
<br />
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 <b>vast</b> (see <a href="http://ipv6-net.blogspot.com/2015/10/ipv6-simplifying-subnetting.html">Simplifying Subnetting</a>).<br />
<br />
<h4>
Take a breath</h4>
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 <b>vast</b>.<br />
<br />
<h4>
A prefix longer than /64?</h4>
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 <a href="https://tools.ietf.org/html/rfc7421">RFC 7421</a> have exhaustively gone through the RFCs to examine what assumes the end user LAN is a /64.<br />
<br />
Some failure modes highlighted by RFC 7241:<br />
<ul>
<li>Routers may drop packets on interfaces /65 to /126 (inclusive)</li>
<li>Specific Multicast Addresses will fail (resulting in NDP failures)</li>
<li>The Cryptographically Generated Address format [<a href="https://tools.ietf.org/html/rfc3972">RFC3972</a>] relies on /64</li>
<li>Many Transition mechanisms, such as NAT64, XLAT464 </li>
<li>Duplicate Address risk, should SLAAC be modified to work with more than /64</li>
<li>Link-Local, defines the Interface ID (IID) as 64 bits wide</li>
<li>IP Address Management (IPAM) systems assume /64</li>
<li>Firewall look up issues (where there are not enough content addressable memory bits to include longer prefixes + L4 port numbers)</li>
</ul>
Although not specifically a failure mode, a smaller subnet space takes less time for attackers to scan.<br />
<br />
<h4>
Think Different, Think Vast</h4>
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 <b>vast</b>.<br />
<br />
<br />
<span style="font-size: x-small;">* Duplicate Address Detection (DAD) is performed, but only after a GUA has been selected.</span><br />
<span style="font-size: x-small;">** Photo licences under <a href="https://commons.wikimedia.org/wiki/File:Meditation_(6225530793).jpg">Creative Commons</a></span>Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-73665673866113159682017-01-15T20:10:00.000-08:002017-01-15T20:10:58.076-08:00Swiss Cheese, or Is that your Firewall?<h4>
by Craig Miller</h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2BdkXm1JOgpjjAtgIfuzsa2tygPekTBYD5AI0HRPAPcGg3txgd2b7njwLK2d11JBIto_U-4pKL2wAd8xUbQOnM4bToXoExQke_r5ZmfIpARj4MDsyNkoDMIn6PPgorbFh-rild7a4ZfYO/s1600/swiss_cheese_orig%252B.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="253" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2BdkXm1JOgpjjAtgIfuzsa2tygPekTBYD5AI0HRPAPcGg3txgd2b7njwLK2d11JBIto_U-4pKL2wAd8xUbQOnM4bToXoExQke_r5ZmfIpARj4MDsyNkoDMIn6PPgorbFh-rild7a4ZfYO/s320/swiss_cheese_orig%252B.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Yummy yes, but not a good firewall</td></tr>
</tbody></table>
While debugging connectivity issues a user was having with my <a href="https://github.com/cvmiller/v6brouter">v6brouter</a> 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 <a href="http://blog.iopsl.com/ipv6-behind-openwrt-router/">IPSOL</a> did it more elegantly than my clunky code.<br />
<br />
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 <a href="http://ipv6-net.blogspot.com/2016/03/v6brouter-part-2-v6bridge-firewall.html">v6Brouter Part 2: v6Bridge Firewall</a>). 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.<br />
<br />
<h4>
Creating a static bridging firewall</h4>
My first attempt at rewriting the firewall, was to block <b>all</b> external access, and only allow external in-bound SSH connections. This seemed like a better default firewall configuration.<br />
<br />
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.<br />
<br />
<h4>
A more useful, stateful firewall</h4>
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<h4>
Check for Holes</h4>
A network firewall can begin to look like Swiss cheese, after all the special user requested holes, connection-based holes (for external responses), and <a href="https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal">UPnP</a> (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.<br />
<br />
<br />
<span style="font-size: x-small;">* Swiss cheese photo - <a href="https://commons.wikimedia.org/wiki/File:Emmentaler.jpg">Creative Commons</a></span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-22310887275343142382016-12-07T17:59:00.000-08:002016-12-07T17:59:06.178-08:00Excuse me, your MAC is showing<h4>
by Craig Miller </h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1nwGxu8XWhkneN9MQAJ0ndU9Osid3sVW3KaG76ajlCz1grV8ZPUmoxPP-83mNzE9PsZhPVevRJ2mlefvWo4xz3LCOVe9t__qdjxVWyGmZrqmoG8p5xx_l6vPAY2bOdeJUjp_8ut7rIxII/s1600/honopou_mac_nut_cracking%252B.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1nwGxu8XWhkneN9MQAJ0ndU9Osid3sVW3KaG76ajlCz1grV8ZPUmoxPP-83mNzE9PsZhPVevRJ2mlefvWo4xz3LCOVe9t__qdjxVWyGmZrqmoG8p5xx_l6vPAY2bOdeJUjp_8ut7rIxII/s200/honopou_mac_nut_cracking%252B.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">MACs exposed*</td></tr>
</tbody></table>
Stateless Address AutoConfiguration (SLAAC) is an easy way to get an IPv6 network up and running quickly. But <a href="https://tools.ietf.org/html/rfc4291">RFC 4291</a> states that the the interface MAC address should be used when generating a Global Unique Address (GUA).<br />
<br />
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.<br />
<br />
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.<br />
<br />
<h4>
Exposing information</h4>
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.<br />
<br />
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 (<a href="https://tools.ietf.org/html/rfc4941">RFC 4941</a>) have all but eliminated this problem, since temporary GUAs are used for outbound connections.<br />
<br />
<h4>
When infinite is only 16 million</h4>
But in-bound connections are still received on the SLAAC MAC-based GUAs. Reading <a href="https://tools.ietf.org/html/rfc7707">RFC 7707</a> (<span style="font-size: 1em;">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, </span><span style="font-family: "courier new" , "courier" , monospace;">10:9a:dd:xx:yy:zz</span>) thus reducing the address pool to 2^24. Or in more humanly understandable numbers reducing the potential address from <b>1 in 18,446,744,073,709,551,616</b> to <b>1 in 16,777,216 </b>(or 16 million). Suddenly, the seemingly infinite address space of 2^64 is quite manageable to probe.<br />
<br />
<h4>
A Standard to the rescue</h4>
Fortunately, there's a new standard to disconnect the MAC address from the GUA. <a href="https://tools.ietf.org/html/rfc7217">RFC 7217 </a>(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.<br />
<br />
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 (<a href="https://github.com/systemd/systemd/issues/4625">#4625</a>) has been submitted to systemd for RFC 7217 support.<br />
<br />
<h4>
SLAAC, letting you slack off</h4>
Where does this leave us? IPv6 is improving, clever people are fixing the problems of the earlier implementations. With RDNSS (see <a href="http://ipv6-net.blogspot.com/2015/11/ipv6-ra-ra-ra.html">IPv6 RA, RA, RA</a>) and Semantically Opaque addresses, a SLAAC environment can be viable option to run IPv6 networks with the minimum of management hassle**.<br />
<br />
<br />
<span style="font-size: x-small;">* Macadamia Nuts in and out of the shell</span><br />
<span style="font-size: x-small;">** OK, if you have Windows machines on the network, it may not be enough (see <a href="http://ipv6-net.blogspot.com/2016/03/dual-stack-good-bad-and-ugly.html">Dual Stack, the good, bad, and ugly</a>)</span><br />
<br />
<br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-70517494530393595622016-11-21T08:43:00.000-08:002016-11-21T09:03:05.224-08:00IPv6 & Systemd, another look<h4>
by Craig Miller</h4>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFuxvjEJKRuq9JFGisVF5X9y8eZaQYtsvUac3KMvbHOMHJjnaItReF7JxC-gD8_Kz9aucJHEesaF34J2e8vI_7558_jjrT0w9UKmu-AWGCyodMEfpk7Ry-FCvSUWkTqAxyu68RgVaxD1hJ/s1600/lenmart_poetering_t_shirt.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFuxvjEJKRuq9JFGisVF5X9y8eZaQYtsvUac3KMvbHOMHJjnaItReF7JxC-gD8_Kz9aucJHEesaF34J2e8vI_7558_jjrT0w9UKmu-AWGCyodMEfpk7Ry-FCvSUWkTqAxyu68RgVaxD1hJ/s200/lenmart_poetering_t_shirt.jpg" width="192" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="background-color: whitesmoke; font-family: "tahoma" , "arial" , "helvetica" , sans-serif; font-size: 12px; text-align: left;">Lennart Poettering on systemd*</span></td></tr>
</tbody></table>
<br />
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 <a href="https://www.freedesktop.org/wiki/Software/systemd/#documentationfordevelopers">systemd</a> to include many other aspects of how your linux workstation operates.<br />
<ul>
<li>networkd - Controls the aspects of networking, including DHCPv6 Client, RA processing, SLAAC address assignment, IPv6 route insertion, etc</li>
<li>resolved - Acts like DNSMasq (but more limited) in resolving Domain Names. It gets pointed to DNS servers via networkd.</li>
<li>Other aspects of the linux host, including logind, hostnamed, locald, timedated, machined, importd to name a few.</li>
</ul>
The systemd daemons will also process IPv4 information, but that is beyond the scope of this blog.<br />
<h4>
</h4>
<h4>
Another Look at systemd</h4>
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.<br />
<h4>
</h4>
<h4>
A recap of IPv6 issues with systemd</h4>
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).<br />
<table border="1">
<thead>
<tr><th>Description</th><th style="width: 4m;"> Issue </th><th>Status</th></tr>
</thead>
<tbody>
<tr><td>IPv6 RA flood (THC flood_router6) causes network disconnection even after flood ceases</td><td><a href="https://github.com/systemd/systemd/issues/2977">#2977</a></td><td>FIXED</td></tr>
<tr><td>Temporary addresses (RFC 4941) are broken from version 224 to 228</td><td><a href="https://github.com/systemd/systemd/issues/2242">#2242</a></td><td>FIXED</td></tr>
<tr><td>nterface disable/enable IPv4 will reaquire and address, but IPv6 will not (other than link-local), and will remain address-less until restarting networkd</td><td><a href="https://github.com/systemd/systemd/issues/2912">#2912</a></td><td>Still broken</td></tr>
<tr><td>Fails to send Router Solicitation</td><td><a href="https://github.com/systemd/systemd/issues/2365">#2365</a></td><td>Still broken</td></tr>
<tr><td>Unable to view DUID (DHCPv6 Identifier) on host</td><td><a href="https://github.com/systemd/systemd/issues/2952">#2952</a></td><td>Closed but Still broken</td></tr>
<tr><td>Bridged Interfaces get IPv6 SLAAC addresses</td><td><a href="https://github.com/systemd/systemd/issues/2572">#2572</a></td><td>FIXED</td></tr>
<tr><td>Systemd in a VM failed to start due to RA parsing error</td><td><a href="https://github.com/systemd/systemd/issues/2228">#2228</a></td><td>FIXED</td></tr>
<tr><td>IPv6 incorrectly not enabled on Virtuozzo containers</td><td><a href="https://github.com/systemd/systemd/issues/2059">#2059</a></td><td>FIXED</td></tr>
<tr><td>IPv6cceptRouterAdvertisements=yes or unset accepts too many prefixes</td><td><a href="https://github.com/systemd/systemd/issues/2004">#2004</a></td><td>FIXED</td></tr>
<tr><td>Does not support DHCPV6-PD</td><td><a href="https://github.com/systemd/systemd/issues/1080">#1080</a></td><td>Still broken</td></tr>
<tr><td>Does not support SLAAC RDNSS</td><td><a href="https://github.com/systemd/systemd/issues/1079">#1079</a></td><td>FIXED</td></tr>
</tbody>
</table>
<br />
<h4>
</h4>
<h4>
A few more issues have been added in the past 6 months</h4>
<div>
<br /></div>
<table border="1" style="width: 100%;">
<colgroup>
<col span="1" style="width: 70%;"></col>
<col span="1" style="width: 15%;"></col>
<col span="1" style="width: 15%;"></col>
</colgroup>
<thead>
<tr><th>Description</th><th>Issue</th><th>Status</th></tr>
</thead>
<tbody>
<tr><td>networkd does not support DNS List option in RA</td><td><a href="https://github.com/systemd/systemd/issues/4590">#4590 </a></td><td>Open</td></tr>
<tr><td>Semantically Opaque Interface Identifiers with IPv6 SLAAC RFC 7217</td><td><a href="https://github.com/systemd/systemd/issues/4625">#4625</a></td><td>Open</td></tr>
<tr><td>networkd: handle MTU field in IPv6 RA</td><td><a href="https://github.com/systemd/systemd/issues/4464">#4464</a></td><td>Open</td></tr>
<tr><td>RFC 7084 support in networkd (automatic ipv6 prefix delegation)</td><td><a href="https://github.com/systemd/systemd/issues/4073">#4073</a></td><td>Open</td></tr>
</tbody>
</table>
<h4>
</h4>
<h4>
Time will improve systemd</h4>
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.<br />
<br />
<span style="font-size: xx-small;">*<span style="background-color: whitesmoke; font-family: "tahoma" , "arial" , "helvetica" , sans-serif;">Lennart Poettering <a href="https://www.ubuntu-user.com/Magazine/Archive/2014/21/Systemd-as-central-control-for-the-Linux-system">T Shirt</a> </span></span>Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-12220599765299452522016-11-01T03:00:00.000-07:002016-11-01T03:00:16.735-07:00IPv6 in the palm of your hand<b>by Craig Miller</b><br />
<br />
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 <a href="http://ipv6-net.blogspot.com/2016/08/a-glass-half-full.html">Glass Half Full)</a>, there is no time like the present to learn the <i>new</i> protocol, IPv6.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyi_r26icMGXDzMrUEDNzknp5xotVTiYFZ_YnN0xYmv2VGWW8v4Zqjir9EQu8aN3tkbuxGKJ3iiqWnHM51Z2LenJEYf2CrKSO7CPGIUK2F80CRmIkGJ4-jdCitjZoG4qKt0gKMCUI0lEsp/s1600/2013_rmv6tf_slide_slide_problematic_approaches_to_ipv6%252B.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="151" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyi_r26icMGXDzMrUEDNzknp5xotVTiYFZ_YnN0xYmv2VGWW8v4Zqjir9EQu8aN3tkbuxGKJ3iiqWnHM51Z2LenJEYf2CrKSO7CPGIUK2F80CRmIkGJ4-jdCitjZoG4qKt0gKMCUI0lEsp/s200/2013_rmv6tf_slide_slide_problematic_approaches_to_ipv6%252B.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">No IPv6 here</td></tr>
</tbody></table>
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.<br />
<br />
<h4>
A new IPv6 device</h4>
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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCqMNCfiFv8JfhfJMinzINg9n9YwufSHXi5V6oi7CqItrabEr0JhN1r0GA0zdzOetUovJO6Cvl8-FiqGhNLQV9CG1FTZU5OxHZztWAgiIp3LM4i1BxtjHF3v_mZjhHyLuI096Rt3MpNdoY/s1600/google_play_disable_ipv6.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="193" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCqMNCfiFv8JfhfJMinzINg9n9YwufSHXi5V6oi7CqItrabEr0JhN1r0GA0zdzOetUovJO6Cvl8-FiqGhNLQV9CG1FTZU5OxHZztWAgiIp3LM4i1BxtjHF3v_mZjhHyLuI096Rt3MpNdoY/s320/google_play_disable_ipv6.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Step into the future, rather than disable IPv6</td></tr>
</tbody></table>
<br />
<h4>
Helpful apps</h4>
But there were other apps as well, to help one learn IPv6. There is an excellent Hurricane Electric* IPv6 <b><a href="https://play.google.com/store/apps/details?id=net.he.networktools&hl=en">Network Tools</a></b>, which can tell you a lot about your network.<br />
<br />
There are even an IPv6 subnet calculators, which of course, aren't really required, since IPv6 does not have variable subnet masking (see <a href="http://ipv6-net.blogspot.com/2015/10/ipv6-simplifying-subnetting.html">Simplifying Subnetting</a>), making things much easier than IPv4.<br />
<h4>
<br />IPv6 in the palm of your hand</h4>
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.<br />
<br />
<br />
<span style="font-size: x-small;">*<a href="http://he.net/">Hurricane Electric</a> is an excellent IPv6 service provider, and offers free IPv6 <a href="http://tunnelbroker.net/">tunnels</a> for those who do not have native IPv6 service.</span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-4100119822792373432016-09-26T11:58:00.000-07:002016-09-26T11:58:43.398-07:00Extending a /64 Prefix<h4>
by Craig Miller</h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikWArnEa5PN5PYNzsB3S7-ssGPKx9PhyK97TL6iFOMK9HShI54iuzbplOKGOcr2yp__6WMTOUqVTm9eg4N585PLGC9UtrAZp9ipeqJPigmv6I_0QTJrjAQ3eZy89EcOTxC84vTS13SMD5x/s1600/Extension_cord%252B.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="236" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikWArnEa5PN5PYNzsB3S7-ssGPKx9PhyK97TL6iFOMK9HShI54iuzbplOKGOcr2yp__6WMTOUqVTm9eg4N585PLGC9UtrAZp9ipeqJPigmv6I_0QTJrjAQ3eZy89EcOTxC84vTS13SMD5x/s320/Extension_cord%252B.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Extending a /64 Prefix</td></tr>
</tbody></table>
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).<br />
<br />
<h4>
Some math, how far will a /32 go?</h4>
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.<br />
<br />
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 <a href="http://www.att.com/Common/about_us/pdf/att_btn.pdf">internet customers of AT&T</a> 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.<br />
<br />
<h4>
Wireless 3GPP and an IPv6 Hotspot</h4>
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?<br />
<br />
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 <a href="https://github.com/cvmiller/v6brouter">v6brouter</a> project which uses bridging for IPv6 while maintaining IPv4 NAT.<br />
<br />
<h4>
Standards to the Rescue</h4>
And there is <a href="https://tools.ietf.org/html/rfc7278">RFC 7278 Extending an IPv6 /64 prefix from a 3GPP mobile interface to a LAN link</a>. The RFC describes processing RA and NDP packets which sounds very similar in concept to the OpenWRT/odhcpd implementation.<br />
<br />
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 <a href="https://tools.ietf.org/html/rfc7278">RFC 7278</a>.<br />
<br />
<br />
<span style="font-size: x-small;">* <a href="https://commons.wikimedia.org/wiki/File:Extension_cord.JPG">extension cord, creative commons</a></span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-81305330778497854382016-08-23T10:03:00.000-07:002016-08-23T10:03:29.783-07:00A glass half full<h4>
by Craig Miller</h4>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiceKeEy3hsJKXhBwEkq69IBqA6xNrKqm190eWcN5mo2Z5yXTa823wyhSSUIRgqBrElBahUTVaerPY_NYLJsEQEVKtIRrYt7QhzmVCyDJMC2rzXrQx7ZCpY2RaSvOSU16rLH6xg0m6o3TzO/s1600/Glass-of-water.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiceKeEy3hsJKXhBwEkq69IBqA6xNrKqm190eWcN5mo2Z5yXTa823wyhSSUIRgqBrElBahUTVaerPY_NYLJsEQEVKtIRrYt7QhzmVCyDJMC2rzXrQx7ZCpY2RaSvOSU16rLH6xg0m6o3TzO/s200/Glass-of-water.jpg" width="136" /></a></div>
This month, the Internet Society (ISOC) reports that the <a href="http://www.internetsociety.org/deploy360/blog/2016/08/facebook-akamai-pass-major-milestone-over-50-ipv6-from-us-mobile-networks/">four major mobile carriers in the US passed the milestone of 50% IPv6</a> traffic to Facebook. This sounds like great news, and it is.<br />
<br />
But looking a little deeper yields more information. Why the US Mobile Carriers? Why is this metric highlighting Facebook?<br />
<br />
<h4>
The good news</h4>
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.<br />
<br />
And in Europe, Sky has recently enabled IPv6 <a href="http://arstechnica.co.uk/information-technology/2016/08/sky-will-push-all-subscribers-onto-ipv6-network-by-summer-2016/">achieving 80% of its customer-base now with IPv6.</a> BT, hopes to follow in 2017.<br />
<br />
Finally after waiting 20 years, serious IPv6 adoption is actually happening.<br />
<br />
<h4>
The less good news</h4>
Facebook is the metric for two reasons: it is a <i>big</i> 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.<br />
<br />
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.<br />
<br />
The reality is that content providers see few business reasons to move to IPv6. After all there are transition technologies such as <a href="http://ipv6-net.blogspot.com/2016/03/dual-stack-good-bad-and-ugly.html">dual-stack</a> or <a href="http://ipv6-net.blogspot.com/2016/07/transitions-getting-from-here-ipv6-to.html">NAT64</a> which allow them (and many others, CBS, ABC, Twitter, Reddit) to continue serving IPv4-only content. Sadly, even some content providers still <a href="http://www.circleid.com/posts/20160819_examinning_ipv6_performance_revisited/">see IPv6 as an inferior transport</a>.<br />
<br />
<h4>
Is it half full or half empty?</h4>
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.<br />
<br />
<br />
<span style="font-size: x-small;">* Glass courtesy of <a href="https://commons.wikimedia.org/wiki/File:Glass-of-water.jpg">creative commons</a></span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-81440340699824331792016-07-10T21:48:00.000-07:002016-07-10T21:48:50.797-07:00Transitions, getting from here (IPv6) to there (IPv4)<h4>
by Craig Miller</h4>
<div>
<br /></div>
<div style="text-align: right;">
</div>
<div style="text-align: right;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit6okHzIOlUULy04Hj7U4FmRDNE1A1w62_aSrLBVi2eJNye6BKZLunIZJiI0QBcNdYqRp6YakH4xBo74rV2YPLjDU01utMVyR4XypF1l9xJ_A0BLQwFvLWQIOUHxQHYZMJCUrwkYaV1SBy/s1600/Translation-icon.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit6okHzIOlUULy04Hj7U4FmRDNE1A1w62_aSrLBVi2eJNye6BKZLunIZJiI0QBcNdYqRp6YakH4xBo74rV2YPLjDU01utMVyR4XypF1l9xJ_A0BLQwFvLWQIOUHxQHYZMJCUrwkYaV1SBy/s1600/Translation-icon.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Parlez vous IPv6?</td></tr>
</tbody></table>
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.<br />
<br />
Bolstered by the news (from Google and others) that IPv6 traffic on the internet was up to <a href="http://arstechnica.com/business/2016/01/ipv6-celebrates-its-20th-birthday-by-reaching-10-percent-deployment/">10%</a>, 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 <b>dark</b> 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.<br />
<br />
<h4>
Transitions, how to get there</h4>
The easiest transition mechanism to use is <b>dual-stack</b>. And I have discussed this in previous posts (see <a href="http://ipv6-net.blogspot.ca/2016/03/dual-stack-good-bad-and-ugly.html">Dual Stack, the good, the bad, the ugly</a>). 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.<br />
<br />
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.<br />
<br />
<h4>
Simplify the Network</h4>
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.<br />
<br />
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?<br />
<br />
<h4>
DNS64 returning false addresses</h4>
Enter NAT64/DNS64, <a href="https://tools.ietf.org/html/rfc6146">RFC 6146</a>. 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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8AobRuPWz3qZxQDVkGHz-QFmW582SGmuMleWgpk-6mJdmvMSFBWnpGqJx5Rz6Ecy5H4JMM-P6U-9M2qeV8pio7g0X1NDOC5uJ0S4dHH7pLk9Rak_2dyhBpAKtG2H-fR4hwZFW6mUgADOG/s1600/dns64.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8AobRuPWz3qZxQDVkGHz-QFmW582SGmuMleWgpk-6mJdmvMSFBWnpGqJx5Rz6Ecy5H4JMM-P6U-9M2qeV8pio7g0X1NDOC5uJ0S4dHH7pLk9Rak_2dyhBpAKtG2H-fR4hwZFW6mUgADOG/s400/dns64.png" width="400" /></a></div>
<br />
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.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifsyJNMja1sSFYtGn5_x7AEeM-7vzUou3rFxLnDWXCAIKGgN6wPmzXImYxFQ4svFEMUWD4sz2SDE9_i5nt1mKiRi1EJxQQ_ymwUUlalxZqGnKpeMc0g9Pqj9RzTNCD5Tz_l79QuNcj6ZQv/s1600/nat64.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="115" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifsyJNMja1sSFYtGn5_x7AEeM-7vzUou3rFxLnDWXCAIKGgN6wPmzXImYxFQ4svFEMUWD4sz2SDE9_i5nt1mKiRi1EJxQQ_ymwUUlalxZqGnKpeMc0g9Pqj9RzTNCD5Tz_l79QuNcj6ZQv/s400/nat64.png" width="400" /></a></div>
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 <a href="https://developers.google.com/speed/public-dns/docs/dns64">public DNS64 service</a> available at 2001:4860:4860::64<br />
<br />
<h4>
Testing NAT64 with OpenWRT</h4>
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 <a href="http://www.litech.org/tayga/">tayga website</a> should get you going.<br />
<br />
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.<br />
<br />
Production quality vendors such as <a href="http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html">Cisco support NAT64</a> as well.<br />
<br />
<h4>
Industry moving to NAT64</h4>
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.<br />
<br />
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 <b>light</b> into your IPv6-only network.<br />
<br />
<br />
<span style="font-size: x-small;">*although it possible to use other prefixes for NAT64 (than 64:ff9b::/96 <a href="https://tools.ietf.org/html/rfc6052">RFC 6052</a>), Google's DNS64 returns addresses with this prefix, which makes life easier.</span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com1tag:blogger.com,1999:blog-455385287674190554.post-4908695231577058082016-06-27T08:37:00.001-07:002016-06-27T08:37:23.910-07:00Feature Parity!<h4>
by Craig Miller</h4>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCbuO4c7HL8n_Y5oJ8yu2DMrTzhuclP01ws37KQji0oe2w4Rkldwe4yf6LrwndvWCBttSuKaMvbpMef_jSrFe7JdA6fWxfs0juKc9ytaZMCRiRS94NpElKKlveoYmDCNfjZ6ScnoVzTp5M/s1600/1984_calif_golden_gate_bridge_.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="239" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCbuO4c7HL8n_Y5oJ8yu2DMrTzhuclP01ws37KQji0oe2w4Rkldwe4yf6LrwndvWCBttSuKaMvbpMef_jSrFe7JdA6fWxfs0juKc9ytaZMCRiRS94NpElKKlveoYmDCNfjZ6ScnoVzTp5M/s320/1984_calif_golden_gate_bridge_.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Bridging Feature Parity for all wheeled vehicles</td></tr>
</tbody></table>
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.<br />
<br />
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.<br />
<br />
<h4>
Wireless Ethernet Bridging</h4>
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*.<br />
<br />
<h4>
Oops, lost the Ethernet MAC header</h4>
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?<br />
<br />
Using Scapy notation, the packet would look like:<br />
<span style="font-family: Courier New, Courier, monospace;">/Ethernet/payload (original packet)</span><br />
<span style="font-family: Courier New, Courier, monospace;">/802.11/payload (packet of the air)</span><br />
<span style="font-family: Courier New, Courier, monospace;">/??/payload (The Ethernet MAC address has been lost)</span><br />
<br />
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.<br />
<br />
<h4>
WDS to the rescue, dang no standard</h4>
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.<br />
<br />
<h4>
Still need solutions in an IPv6 world</h4>
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.<br />
<br />
<br />
<span style="font-size: x-small;">*Over the 5Ghz band, as the 2.4 Ghz band is way to crowded</span><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0tag:blogger.com,1999:blog-455385287674190554.post-36052337160140219392016-06-14T10:12:00.000-07:002016-06-14T10:12:26.198-07:00Breaking the NAT frame of mind<h4>
by Craig Miller</h4>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD3lYLvIAXpwlJdbHc2FElC6BdIhPj_dXEJoou2V35-ls5ZGQI3FgBeZQf80LhRHVIHynbUDpRzbtW3oF6TWYCmq_Y8RWv-bM_XW5VNZ_G6sFLGnti_G_U9JPfhKskWX9Q_86PQd10XuqY/s1600/NAT_router.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD3lYLvIAXpwlJdbHc2FElC6BdIhPj_dXEJoou2V35-ls5ZGQI3FgBeZQf80LhRHVIHynbUDpRzbtW3oF6TWYCmq_Y8RWv-bM_XW5VNZ_G6sFLGnti_G_U9JPfhKskWX9Q_86PQd10XuqY/s320/NAT_router.jpg" width="320" /></a></div>
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 <a href="https://tools.ietf.org/html/rfc1631">RFC 1621 </a>was written in 1993). An interesting concept in the RFC is that NAT would be a temporary measure:<br />
<br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">If nothing else, this solution can serve to provide temporarily relief while other, more complex and far-reaching solutions are worked out.</span></blockquote>
Note, that f<i>ar-reaching</i> solution is IPv6, which was standardized two years later (<a href="https://tools.ietf.org/html/rfc1883">RFC 1883</a>).<br />
<br />
<h4>
NAT helped with Address Exhaustion, but...</h4>
NAT was the solution to the problem of IP address space exhaustion. The authors of <a href="https://tools.ietf.org/html/rfc1631">RFC 1621</a> saw security issues with NAT, such as passing encrypted traffic (ESP), and debugging problems, since IP addresses change.<br />
<br />
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.<br />
<br />
<h4>
Fast forward to Today</h4>
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).<br />
<br />
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.<br />
<br />
<ol>
<li>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)</li>
<li>Use a v6brouter approach, which bridges IPv6 with a firewall, avoiding NAT. (see <a href="http://ipv6-net.blogspot.ca/2016/02/nat-tiness-and-v6brouter.html">NAT-iness and the v6Brouter</a>) And continue to push your ISP for more than a single /64</li>
</ol>
<br />
<h4>
Restoring end-to-end Connectivity</h4>
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.<br />
<br />
<br />
<br />
* <a href="https://commons.wikimedia.org/wiki/File:Adsl_connections.jpg">Router Image</a><br />
<br />Craighttp://www.blogger.com/profile/15880011431496785012noreply@blogger.com0