IPv6 – assigning a global static address for a server

In this installment, we assign a global, static IPv6 address to an interface on the home Linux Server. This is the first step to go from “my first ping” to a (mostly) fully functional IPv6 home Linux server with SSH, HTTP and other services.

To get from the all-client network to a functioning server, we need to get a persistent static IPv6 address on at least one of the server’s interfaces and get that address into DNS. Then we need the service daemons to bind to that IPv6 address.

In addition to being much larger than IPv4 addresses, IPv6 addresses are also more complicated. Like IPv4, IPv6 has unicast, multicast and anycast addresses, but there are no broadcast addresses. You’ll use either anycast or multicast instead. IPv6 addresses also have scope. The two scopes that we need to be concerned with for this setup are link-local and global.

A big change in IPv6 is that you need to think in terms of “interfaces” instead of “hosts” having IPv6 addresses, and every interface will have multiple IPv6 addresses as a matter of course.

IPv6 has “auto configuration” built in, which will give you two addresses: a link-local unicast address and a global EIU-64 unicast address. Both are created by using the interface’s hardware (MAC) address as the lower 64 bits of the full IPv6 address.

At this point in my project, all the home systems are using “link local” and modified EIU-64 IPv6 addresses. You can see this on the Linux server via “ifconfig”:

This interface has three IP addresses: an RFC-1918 IPv4 address, a link-local address (the fe80:: address) and a global EIU-64 auto configured address that is made by concatenating the /64 IPv6 prefix (2001:470:67:88) and the interface hardware address (230:1bff:fe82:cb42).

At this point, we could put the EIU-64 address into DNS, but that is not a good practice. Changing the interface’s hardware (or the whole server) would change the address, requiring a DNS change. DNS names should be tied to services, not hardware…

Getting an IPv6 address onto the eth0 interface is relatively easy; just edit /etc/network/interfaces to add something like this:

We’ll need a little more info here: what OS (distribution if Linux) and version, and the contents of your interfaces file.I would also look to make sure you didn’t change the permissions or ownership of the interfaces file.

1. You used *my* IPv6 addresses in your file. You need your own IPv6 addresses, assigned by your ISP or an IPv6 tunnel broker. See the earlier postings.

2. I don’t know if Oracle Enterprise Linux uses the /etc/network/interfaces file. There should have been other (IPv4) related lines in that file before you put in the IPv6 info. Does Oracle Linux use that file for configuration?

I know this is an old thread, but one thing genuinely puzzles me. You assign yourself a static IP address 2001:470:67:88::10. How does that address get to be globally routable?The network/subnet number gets it as far as your local router, but how does the router get it to you without your EIU-64 address and without ARP?

Your subnet (or a superset of it) has to be “announced” by your ISP, typically via BGP. The route is then passed to other ISPs, sometimes aggregated into larger and larger address blocks, and eventually gets to “all” of the ISPs.

Working the other way:
1. Registrar assigns large block of addresses to an ISP, probalby (for IPv6) a /30 or /32.
2. The ISP “announces” this block to their neighbors – “send any traffic for ANY of these addresses to us”
3. ISP splits up the big block into smaller chunks, and assigns them to regions within their networks, such as “California area”, and perhaps down to “our San Diego customers”
4. The ISP assigns you some addresses, perhaps a /60 or /64 subnet from that local set.
5. Either you (via static assignments), or your router (via DHCPv6 or SLAAC) assigns an address from “your” subnet to your specific device.

Step 2 tells the rest of the Internet to send the traffic (route) to the ISP, the ISP’s internal routing is responsible for getting the packets from their boundary (peering point), through their intenral network, to you. And vice versa.

This shows the main “routes” that HE is announcing to the rest of the Internet.

From this you can see that 2001:470::/32 is assigned to Hurricane Electric, who was my ISP. They announce pieces of this as separate more specific routes, but this announcement pretty tells all the other ISPs – “send all traffic for anything in 2001:470:: to us, and we’ll get it to the right place”.

The router will multicast “Neighbor Solicitation” messages, asking for the MAC (link address) of a specific IPv6 address. The owner of that IPv6 address will respond with a “Neighbor Advertisement” containing the IPv6 address and MAC address.

It’s starting to make sense. But when you say it will multicast Neighbour Solicitation messages, I assume it has to use FF02::1 (all nodes in link-local scope) which is indistinguishable from a LAN broadcast. In which case, we can still get cache poisoning and MITM attacks. I’ve now read the security section of RFC4861 and it seems that is unavoidable.

My assumption that the point of SLAAC with EUI-64 was to get rid of ARP-type threats seems to have been untrue. Maybe it was never true (due to static addressing) or maybe it became untrue when privacy extensions were introduced.

Thanks for your answers. It all helps me work out the change of mindset you need when migrating from v4 to v6.

Correct, IPv6 has the same cache poisoning issues as IPv4 and ARP. In a single LAN (broadcast or multicast domain), the FF02::1 all nodes multicast is effectively the same as IPv4 (usually Ethernet) broadcast.

The purpose of SLAAC and EUI-64 was not a security measure, it was an easy way to generate a “guaranteed unique” IPv6 address with no need for additional services, such as DHCPv6 (or static assignment). Part of Neighbor discovery includes “Duplicate Address Detection” (DAD) which helps ensure that the address you’ve chosen is not already in use. This is especially important, as it makes the “Privacy extensions” (random MAC addresses) possible in a baseline IPv6 network with no other features required. Pick a random address, do DAD, and go.

If by “privacy extensions” you mean the MAC address randomization, they help in two ways.

First, by assigning random MAC addresses to the same host over time, they make tracking your use of (for example) public or other wifi more difficult. The network operator can log MAC addresses, but they are nothing more than carefully chosen random numbers, and aren’t a permanent identifier for your phone, tablet or computer. You also can’t correlate logs from multiple networks (such as your local Starbucks and the airport WiFi) to track an individual device.

Second, in networks where the IPv6 address is based on the MAC address, this has the additional feature of giving you a randomly changing IPv6 address, which will show up in web and other logs.

SLAAC vs DHCPv6 is an ongoing debate in the IPv6 community. For enterprises, DHCPv6 has many compelling arguments over SLAAC. For consumers and many others, SLAAC is convenient because there are no additional services needed, if you don’t need the additional features.