Slaac-ing Off

IPv6 SLAAC

by Craig Miller

IPv6  Auto Magic

Slaacer is a good thing

20 years ago when IPv6 was being standardized, the IPv4 world was busy statically defining addresses on every machine. This was becoming a burden to network administrators, and it was quickly becoming a problem of scale. DHCPv4 hadn't been invented yet.

Back in 1996, the IPv6 authors created a method by which devices on the network could auto-magically create a valid global routable address using SLAAC (StateLess Address Auto Config, RFC 4862). By using SLAAC, all hosts on a network could, without network administrators help, get on the internet.

Two halves of SLAAC

Because the simplification of subnet masking in IPv6 (everything is a /64, see Simplifying Subnetting) the address can be split in half, with the left (MSB) being the network portion of the address, and the right (LSB) being the host portion. 

Host Part

Let's start with the right half, the host portion. Since on a subnet, or broadcast domain (if you thinking IPv4), all MAC addresses must be unique, the IPv6 authors use this to create the host portion of the address. First the 48 bit MAC address is converted to a 64 bit number, or EUI-64, by inserting FFFE in the middle. For example a MAC address is: 60:21:c0:e0:8f:0a, would become: 6021:c0ff:fee0:8f0a. Then the last step in this transformation is to flip the universal/local bit (bit position 7, see RFC 2373 Appendix A) which results in: 6221:c0ff:fee0:8f0a. This host portion is not only used in the global routable SLAAC address, but also in the link-local address.

Network Part

The left half, or network portion is easier. When the network is defined on the router, the router will send out a router advertisement (RA) which will include the network prefix for that subnet. There is more to the RA, such as the M & O bits, but I'll cover that in a later post. Using tcpdump, a typical RA looks like:

15:12:21.640794 fe80::2a0:a512:85:2940 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 48

    hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s

    prefix info option (3), length 32 (4): 2607:c000:8000:8b93::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s

On the Internet

The host, hears the RA, and forms a full 128 bit global routable address by prepending the advertised prefix to the host portion (lower 64 bits). And magically, the host is ready to use the internet!

OK, that was a bit simplified somewhat. There is DAD (Duplicate Address Detection, RFC 4862) which has to happen, but since as we have seen above, the IPv6 address is formed from the MAC address, it should be unique. If it isn't, DAD will figure that out, and create a unique host portion of the address, and then boom! you are on the internet.

Global Auto-configuration

As you can see a key difference from IPv4 is that a host can get a global address without user, or network administrator intervention. But you might ask, what about auto-configuration in IPv4, the 169.254.0.0/16 address (RFC 3927)? This is different in two key ways:

•  IPv6 SLAAC predates ipv4 auto-config, which was inspired by IPv6 SLAAC
• It is not a global routable address, but used more on-link communication when a DHCPv4 server is not available

The Network is in charge

Sun Microsystems (now part of Oracle) used to have a marketing phrase, "The Network is the Computer." IPv6 creators, took this to heart, and much of IPv6 is controlled by the network, specifically, the RA (Router Advertisement). This architecture creates great power in the Network Administrator's hands. If a subnet must be renumbered, it is as simple as changing the prefix in the RA, all hosts will pick up the new prefix, and generate new global addresses.

SLAAC Evolving

SLAAC continues to evolve. Privacy concerns about using the same global address (without NAT) were raised, and SLAAC temporary addresses (RFC 4941) were created to address this issue, and is widely deployed in OSs. A newer standard which has yet to see wide deployment is attempting to address the privacy issue, while creating a stable (non-changing, and not tied to the MAC) address (RFC 7217), which will make it easier for firewall (ACL, Access Control Lists) configuration.

SLAAC Auto-magical

SLAAC auto-magic continues to make getting on the internet easy, nearly 20 years later. Address auto-magic is good, making your transition to IPv6 even easier.

IPv6 RA, RA, RA

IPv6 Router Advertisements

by Craig Miller

IPv6  The Network is in control

Router Advertisement

The authors of IPv6 wanted to learn from the IPv4 mistakes, and one key issue (at the time) was statically assigned addresses (DHCP hadn't been invented yet). As I have written in a previous post, SLAAC (Stateless Address AutoConfig) was a huge step forward in end nodes being able to get an address auto-magically.

End station (host, nodes, machines, etc) addressing is controlled by the Router Advertisements (RAs). In this article, I will delve into RAs a bit more, and explain how one can configure RAs to give you the result you are looking for.

RA Bits

Not surprisingly, RAs are sent by routers. The RA is a Type 134 ICMPv6 message (IANA ICMPv6 assign numbers). The individual interfaces on your router must be configured to send RAs when IPv6 is enabled. The RA has several flags (bit fields) which can be set or unset. The important ones for addressing are the A, M, and O bits. These control how the end station will get an address. Jeff Carrell summarized it well in a 2012 presentation.

I had this slide up on my cube wall for years, and gave a copy to anyone who seemed remotely interested in IPv6.

Simplifying the RA Bits

L bit

Let's start with the easy one. The L bit (or link bit) as you can see it is always on, and has no bearing on how an end station gets an address. 'Nuff said.

A bit

The next one to tackle is the A bit, this is the one that controls whether SLAAC is used by the end station.

M bit

The M bit is the Managed bit, which tells the end station to initiate DHCPv6 client request (RFC 3315). Unlike DHCPv4, IPv6 clients should NOT initiate a DHCPv6 request unless the M bit is set (not all clients respect this).

O bit

The Other bit, is a combination bit of sorts. The ideas is that SLAAC or manual may not provide all the information and end station may need, such as location of DNS and NTP servers. By setting the O bit, the network administrator is asking the end station to do a DHCPv6 for the options, but NOT for an address.

As you can see from Jeff's slide (above) the O bit is used with either the A bit (SLAAC provides the address) or the M bit (where DHCPv6  provides the address)

But wait, there's more 

RAs also advertise one or more prefixes for the link. Remember in What's with all those IPv6 Addresses end stations can have many IPv6 addresses. They can also have addresses in different subnets (on the same link). This would be useful for an address transition (from one address to another).

Since DNS is so useful (you were memorizing all those IPv6 addresses, right?), Recursive Domain Name Server Serivce (RDNSS) is useful (RFC 6106).

Lastly, for now, when the end station hear's the RA, and it assigns the default route next hop, as the link-local address of the router. By looking at the route table of the end station, you can see the default route:

$ ip -6 route
...
default via fe80::224:95ff:fef1:8ca dev mlan0  proto ra  metric 1024  expires 1608sec

There are other things in the RA, router lifetime, reachability, etc, which I may cover in a later post. But these are the important addressing bits.

RA Implementation Isues

This how it is supposed to work. The RFC's specify the ideal. But then it falls upon the developers to implement the ideal, and sometimes they fall short. When non-obvious combinations of RA bits (or flags) are set, non-obvious behaviours occur. Although the following RFC memo (it was only a draft, and has no number) is now expired, it still contains some good info about implementations of Windows 7, MacOS X 10.7 (aka Lion), and Ubuntu 12.04. It is well worth a read if you want to see how the OSs have really been implemented.

You can find the memo at: https://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem-00

RA Troubleshooting

Want to see what your router is advertising?  You could fire up wireshark (or tcpdump) and wait, and wait, and wait for the router to send an RA (the configurable time is usually from every few minutes to much longer). Or you could issue a RS (Router Solicitation) and see the look at the RA that comes back.

The easiest way to do this is to use the linux utility rdisc6 (on Ubuntu, part of the ndisc6 package). This will do all the work, and show the results in a fairly human readable form.

$ rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No   <--- M bit
Stateful other conf.      :           No   <--- O bit
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Source link-layer address: 00:24:95:F1:08:CA
 MTU                      :         1280 bytes (valid)
 Prefix                   : 2001:470:1d:584::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Prefix                   : 2607:c000:815e:c400::/64
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         1800 (0x00000708) seconds
 Route                    : 2607:c000:815e:c400::/56
  Route preference        :       medium
  Route lifetime          :         7200 (0x00001c20) seconds
 Recursive DNS server     : 2001:470:1d:584::1
  DNS server lifetime     :         1800 (0x00000708) seconds
 from fe80::224:95ff:fef1:8ca

As you can see this router is advertising two prefixes into my network, and each of my hosts have five (5) IPv6 addresses (link-local, prefix 1 SLAAC, prefix 1 SLAAC/Temporary, prefix 2 SLAAC, prefix 2 SLAAC/Temporary).

Do not adjust your TV set, the RAs are in control

Knowing the RA bits, A, M, and O will help you control addressing on your IPv6 network. I have focused on the addressing components of the RA, but there is more  (home agent, reachability time, MTU size, etc), which can help you solve more challenging problems in your network. The RA is a useful tool to simplify your IPv6 network, hip-hip-hooRA for the RA.

*Jeff Carrell's 2012 presentation 

Windows 10 now runs in SLAAC Networks

by Craig Miller

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.

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.

Windows 10 and SLAAC Requirements

In order to see the new feature in action, the Windows 10 machine must:

• Be in a IPv6-only network (no IPv4) 
• Hear a RA (Router Advertisement) without the M-bit set (or DHCPv6 disabled). 

Of course, it would be good if your router was sending RDNSS in the RA. 

Windows 10 SLAAC-only Details

In this environment, the output of ipconfig is still a little misleading:

C:\Users\Craig>ipconfig /all

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan

   Description . . . . . . . . . . . : Realtek PCIe GBE 

   ...
   DHCPv6 IAID . . . . . . . . . . . : 75761763
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-A3-2E-82-80-FA-5B-96-37-56

   DNS Servers . . . . . . . . . . . : fdf7:56a9:b7af:1101::1

   Connection-specific DNS Suffix Search List :

                                       lan

The DNS Server field is now showing my RDNSS address (the ULA address of my router) and DNSSL (DNS Search List)!

Another way to confirm the DNS servers that Windows 10 knows about is with a netsh command:
C:\Users\Craig>netsh int ipv6 show dnsservers

Configuration for interface "Ethernet"
    DNS servers configured through DHCP:  fdf7:56a9:b7af:1101::1
    Register with which suffix:           Primary only

Running a quick check to see if it can actually resolve an address using only RDNSS:

C:\Users\Craig>nslookup www.google.com

Server:  OpenWrt.lan

Address:  fdf7:56a9:b7af:1101::1

Non-authoritative answer:

Name:    www.google.com

Addresses:  2604:470:4001:806::2004

          172.217.29.164

Now it is possible to run simplified (SLAAC) networks

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.

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.

* adapted from my ipv6hawaii.org article
** Win10 details from André Lange, author of ip6neigh

What's with all those IPv6 Addresses

by Craig Miller

No longer tied to one address

A key difference of IPv6 is multiple addresses. An interface will have at least two IPv6 addresses, a link-local, and a global address, but there can be more, several more.

All those addresses can mean more complexity, but it can also mean simplicity. Other than a Global address, and a link-local address there is no requirement to have more.

But remember there is usually at least two ways to look at something, and IPv6 is no different. Vase, or Faces?

Address fundamentals

By now you know that an IPv6 address is 128 bits long. And hopefully you know that IPv6 does not have a variable length subnet mask. It is always, always 64 bits long. This simplifies things a lot.

An IPv6 address looks like the following:
 2001:4860:4860:0000:0000:0000:000:8888

An IPv6 address is made up of 8 quartets of 4 hexadecimal digits separated by colons. That is a lot of typing. fortunately RFC 4291 says we can shorten one long string of zeros with a double colon. And the address becomes:

 2001:4860:4860::8888

In the above example¹, the network number (the part on the left 64 bits) would be 2001:4860:4860 and the host number (the part on the right 64 bits) would be 8888

The double colons don't have to align with the 64 bit mask, but it is convenient when it does.

Special Addresses

There are special addresses, which are required for IPv6 to work properly. The first is the link-local address, which always starts with FE80:, in fact it is officially (in RFC 4291)

FE80::/10

Because there is no ARP (Address Resolution Protocol) in IPv6, another method had to be utilized to resolve MAC addresses for a given IPv6 address. By having every node create a link-local address, which is only significant on that link, ICMPv6 can be used to resolve MAC addresses through neighbour discovery.

Another set of special addresses are the multicast addresses, which start with FF. (again defined in RFC 4291). One we learned from a previous post was the all nodes address. There is no broadcast in IPv6, but multicasting to all-nodes has a similar result. The all nodes address is:

FF02::1

How to get a Global Address, let me count the ways

Before sending your packets on to the big IPv6 enabled internet, you will first need to get a global IPv6 address. Fortunately, there are several methods to get a global address:

• SLAAC (Stateless Address Auto-Configuration)
• DHCPv6
• Statically defined

The first thing to remember about IPv6, is that the network, not the client controls addressing. There are key advantages to doing it this way. If you have a subnet (in IPv6 it is called a prefix) defined, and 100 host machines on it, you don't want to go to each machine and change the prefix. Using SLAAC, you would just change the advertised prefix on the router, and all of the 100 hosts on the line would acquire a new valid Global Addresses.

But how do the hosts know to select a unique Global address for each host? Because the original standard for SLAAC was to take the ethenet MAC address and modify it a bit (into EUI-64 format) and make that the lower 64 bits (or host part) of the address, and prepend the advertised prefix from the router.

Privacy concerns with SLAAC

However, this caused an unforeseen problem. The host always had the same address, day in and day out. This led to privacy concerns, and via RFC 4941, another global address is created called a Temporary Address. The temporary address is a randomized lower 64 bits, which is re-randomized every day (24 hours). Since this Temporary global address is changed every day, it harder for places outside the local network to track the host.

But there are those who don't like every changing addresses. They are the security people. When analyzing the logs, they want to see a consistent address used day in and day out. After all, this is how IPv4 works.

DHCPv6

Another method used to get a global address is DHCPv6. Again it is controlled by the network, not the client, as defined in RFC 3315. The Router Advertisements (RAs) also include the M & O bits (for managed and other). If either or both of these are set, then the DHCPv6 client should make a multicast request to a DHCPv6 server, and request an address (if the M bit is set) or request other options (such as DNS server settings) if the O bit is set. However the M & O bits are not mutually exclusive to the A bit (which controls SLAAC). So it possible to have a DHCPv6 address, a SLAAC address, Temporary address, and a link-local address all on the same interface.

And if that isn't enough addresses, you can always manually assign an address (statically defined) to an interface.

sudo ip addr add 2001:470:1c:583::1 dev eth0

All those addresses which one is used?

Fortunately, there is RFC 6724, Source Address Selection standard to determine which source address is used when connecting to the internet. This standard supercedes the old RFC 3484, which stated that an IPv6 address is always preferred over an IPv4 address. In this time of transition to IPv6, the user (or IT folks) may want to change this preference, as per RFC 6724 rather than just turning off IPv6. See my previous post, IPv6, not your grandma's IP, for more info on how to adjust your preference.

The rules governing Source address selection are a bit complex. To understand them best, one should refer to section 5 of RFC 6724. Here are the rules (as specified in the RFC) to give you a overview:
   Rule 1: Prefer same address.
   Rule 2: Prefer appropriate scope.
   Rule 3: Avoid deprecated addresses.
   Rule 4: Prefer home addresses.
   Rule 5: Prefer outgoing interface.
   Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
   Rule 6: Prefer matching label.
   Rule 7: Prefer temporary addresses.
   Rule 8: Use longest matching prefix.

Old Protocol, still evolving

As I write this there is a new RFC on the books, Distributing Address Selection Policy Using DHCPv6    (RFC 7078). Again, the idea is make it easier to roll out changes to your hosts (whether it is changing the prefix, or how host select addresses). IPv6 continues to evolve. Learning IPv6 now will help you for the rest of your career.

1) Just like Google has IPv4 DNS servers at 8.8.8.8, and 8.8.4.4, Google also has IPv6 accessible DNS servers at 2001:4860:4860::8888 and 2001:4860:4860::8844

systemd: oh, you wanted to run IPv6?

by Craig Miller

Oh, you wanted to run IPv6?

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

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

How do you get your IPv6 prefix?

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

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

Know your environment

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

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

Write a Test Plan

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

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

A few IPv6 issues with systemd

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

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

Upgrading to systemd distros

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

Time will improve systemd

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

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

Update Nov 2016 (see IPv6 & Systemd another look)

*DHCPv6 has not been implemented in the kernel

IPv6 & Systemd, another look

by Craig Miller

Lennart Poettering on systemd*

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

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

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

Another Look at systemd

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

A recap of IPv6 issues with systemd

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

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

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

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

Time will improve systemd

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

*Lennart Poettering T Shirt 

Excuse me, your MAC is showing

by Craig Miller 

MACs exposed*

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

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

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

Exposing information

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

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

When infinite is only 16 million

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

A Standard to the rescue

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

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

SLAAC, letting you slack off

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


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

IPv6 Printer Support: Finally getting there

by Craig Miller

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.

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.

Typing in the SLAAC address only once

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.

IPv6 info

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.

Investigating IPv6 Printer Services

Even without feature parity, a quick scan by nmap reveals that the printing services are also available over IPv6.

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-05 09:16 PST
Nmap scan report for 6kunane.hoomaha.net (2001:470:ebbd:0:3e2a:f4ff:fe37:dac4)
Host is up (0.010s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
515/tcp  open  printer
631/tcp  open  ipp
9100/tcp open  jetdirect

Printing from an IPv6-only network

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.

IPv6 Simplifying Subnetting

by Craig Miller

Simplifying Subnetting

Network prefix always /64

Another key difference of IPv6 is no more variable length subnetting. There has been an entire industry build up around what address boundaries does a /26 have. Be prepared to file that info away, because IPv6 has a fixed length subnet (or prefix). It is always /64, end of story.

Wasting address space?

The biggest complaint I hear from experienced IPv4-ers is that a /64 is a waste of address space. And in a way it is, but who cares? Part of the mind-shift that needs to happen when working with IPv6 is to shake off the shackles of conserving address space. Allocating 2⁶⁴ addresses per subnet is a lot of addresses. More than the entire IPv4 address space, in each subnet. But remember there are also  2⁶⁴ networks available.

How Big is it?

The best example I have heard to explain just how big the IPv6 address space is, is this:
If the entire IPv4 address is equal to 1 meter (a little longer than a yard), then the entire address space of IPv6 is 18 trillion light-years.

That is a lot of address space. There may come a day when we earthlings will have to move to a different addressing scheme, but it won't be in your life time.

Simplifying with /64

The key advantage of using a /64 everywhere (even point to point links) is that it greatly simplifies your network planning. If everything is a /64, then SLAAC works everywhere! This means everything can acquire a global routable address auto-magically.

Trying to conserve address space, by using something other than a /64, will break SLAAC, and you will find that your network is still complex, and you have missed a golden opportunity to simplify your network. Remember, a simpler network is easier to troubleshoot, which translates to faster resolution times, and at the end of the day, saving money.

Another advantage of using /64 is that it prevents some of the attacks from the IPv4 days. Try running nmap on your /64 subnet. You will never find all, or even 10% of the hosts on the subnet. You can't just scan every address in the subnet. It will take months, and with Temporary Addresses (RFC 4941) hosts will change addresses before you even scan them.

Land of Plenty

Go ahead and plan your next generation network with /64s. It may seem decadent at first, but it will pay real dividends for the rest of your life.

Breath deeply, a /64 is a good thing

by Craig Miller

Earth's atmosphere is vast

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

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

Take a breath

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

A prefix longer than /64?

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

Some failure modes highlighted by RFC 7241:

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

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

Think Different, Think Vast

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


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

IPv6, Not your grandma's IP

by Craig Miller

IPv6 is a different networking protocol

The first thing to learn about IPv6, is that it isn't just like your old friend IP(v4). It is a different network protocol which happens to reuse the same layer 4 (UDP and TCP). The two network protocols (IPv4 and IPv6) are not compatible. There is no magic interoperability between them. To access a IPv6 server on the internet from IPv4, there must be a proxy somewhere on the internet which will do the conversion for you. Most implementations, windows, linux, mac, android, use what is called dual stack, this enabling your computer to speak both protocols (kind of like speaking both French and English in Canada).

The separateness of IPv6 is a double edge sword, you can take advantage of it, but so can others. I'll cover this aspect in more detail in a later post.

Quick look at the differences

The obvious and not-so-obvious differences between IPv4 and IPv6 are:

IPv4	IPv6
32 bit long address	128 bit long address (see Quibbling in IPv6)
thinking: must conserve host addresses	thinking: define the networks needed for the job. It is OK to waste a /64 on a point to point link because it will make the entire network simpler.
Variable Subnet Length Mask, subnettting is hard	No VSLM, all user subnets are /64, results in simplified subnetting (see Simplifying Subnetting)
Single IP address	Always uses multiple IP addresses: one or more global, a temporary (RFC 3041), and a link-local (see What's with all those IPv6 Addresses)
n/a	Non-routable address, FE80/10, aka Link-local
Uses Broadcast	No Broadcast, uses Multicast (see Goodbye Broadcast)
Pseudo auto-config (169.254.0.0/16)	Stateless Autoconfig (SLAAC)  (RFC 4862) provides a method to automatically obtain a globally routable address (see SLAAC-ing Off)
Client initiates DHCP	Network controls (via M & O bits in RA) DHCPv6 (RFC 3315)
Net Address Translation, keeping IPv4 alive since 1994 (RFC 1631) as a short-term solution	No NAT. Restores true any address to any address connectivity.
Uses ARP to resolve MAC addresses	Uses ICMP to resolve MAC addresses. Blocking ICMP on the firewall, will disconnectyour network (see IPv6 using ICMP)
Private address space (RFC 1918) aka 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Unique Local Address (ULA) FC00::/7 (RFC 4193). Don't use. This is IPv4 thinking, use Global addresses everywhere, keep the network simple
OSPFv2 routing	OSPFv3 routing

Don't turn off IPv6 and miss the opportunity to learn

And that is just the tip of the iceberg. So what is one to do? Stick your head in the sand, and turn off IPv6? I would suggest, no. Start playing with IPv6, either with an extra machine (we all have extra machines laying around, right?), or in a VM, and start learning.

Set up your computer to prefer IPv4, if needed

But what if you don't have an IPv6 connection to the internet, and things are slow

If you are running linux, add this to your /etc/gai.conf file, and restart your web browser. IPv4 (as per RFC 6724) will now be preferred:
precedence ::ffff:0:0/96 100

If you are using Windows, use netsh to raise the IPv4 preference.
netsh int ipv6 set prefix ::ffff:0:0/96 100 4

If you are using a Mac, let me know. I haven't found how to adjust the IPv4/IPv6 preference.

Future Growth of the Internet will be on IPv6

IPv6 isn't going away, and ignoring it won't make it go away either. Your organization may be happy using private IPv4 address space, but your customers will be using IPv6, and if they can't get to your IPv4-only website, you will be losing customers. Now that ARIN has run out of IPv4 addresses, there is no time like the present to learn how the next phase of the Internet will work.

And hopefully, once you learn the benefits of IPv6, you wil take the time to simplify your next generation network. (see IPv6 is not coming, it is here)

North American IPv6 Summit

by Craig Miller

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 get it. 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.

The conference was organized by the regional IPv6 Task Forces: California IPv6 Task Force, Rocky Mountain IPv6 Task Force, Texas IPv6 Task Force, and Mexico IPv6 Task Force.

Speakers, shakers and movers

Some of the speakers were:

• Tony Scott, the former CIO of the Unitied States of America
• John Curran, the President and CEO of ARIN (American Registry for Internet Numbers)
• Kevin Jones, Chair for IPv6 transition at NASA
• John Brzozowski, Chief Architect, IPv6 and Fellow,  at Comcast

Major Points

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:

• Dual-stack is only half way. We need to start moving to IPv6-only networks. There were presentations on how Cisco, Microsoft, and Comcast are doing just that.
• IPv6 impacts on Cloud Computing, and IoT. A case study of BC Hydro operating 2 million smart meters (IoT) all on IPv6.
• Content is being delivered over IPv6, thanks to CDN (Content Delivery Networks), like Akamai and Cloudfare, fronting IPv4-only legacy sites.
• Microsoft adds SLAAC capability to Windows 10, Creator Update (11 April 2017). Now it is possible to have Windows and Android on the same SLAAC (Stateless Address Auto Config) IPv6-only network!

Missed it? Here's the presentations

Thanks to all the volunteers of the regional task forces, and Linked-in for hosting the conference. The presentations are posted online, in case you didn't make it down to Sunnyvale last week. Hope to see you there next time.

What makes a good IPv6 implementation?

Bad IPv6 support costs Money

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.

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.

Why is this important?

With 25% 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:

• A) fail, or
• B) you will try to bolt on IPv6 on the side, or
• C) have to be completely rewritten.

All of that costs money.

A good IPv6 device implementation

There are broad areas where IPv6 should work well.

Addressing

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:

• Support both addressing methods, SLAAC, and DHCPv6
• 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)
• 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.

Routing

IPv6 is not IPv4 with colons. There are somethings which are different for good reason.

• Default routes are link-local addresses (Docker fails on this one big time). GUAs may change, link-locals shouldn't.
• 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
• If the device is routing (such as Docker) then support DHCPv6-PD, and provide the option of prefix delegation into the container/downstream network.

Resiliency

Basic protection from network misconfiguration, or out right attacks makes the IPv6 device better prepared for production use.

• Rational limit on the number of IPv6 addresses an interface may have. Before systemd, the Linux kernel defaulted to 16. This seemed like a good compromise. Back in systemd 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.
• 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.
• Don't assume that the Linux Stack has your back. Since systemd has become widespread, there are many IPv6 systemd bugs, which weren't there in the pre-systemd kernel days. IPv6 is a different stack, be sure to test it.

Summary

I am sure I missing a few, but this is a start. When developing a product, the business case for supporting IPv6 well, is that it will save you money in the long run, by not having to go back and try to bolt IPv6 on, or rewrite your network stack later.


P.S I wouldn't recommend putting Docker into production because of the severe IPv6 limitations.

Yachts colliding: Creative Commons/ Mark Pilbeam

Dual Stack, the good, bad, and the ugly

by Craig Miller

Dual Stack: a foot in the past and the future

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

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

The Good

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

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

The Bad

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

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

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

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

The Ugly

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

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

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

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

A Path to the Future

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


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