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”:
server$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:30:1b:82:cb:42 inet addr:192.168.1.200 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::230:1bff:fe82:cb42/64 Scope:Link inet6 addr: 2001:470:67:88:230:1bff:fe82:cb42/64 Scope:Global
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:
### Start IPV6 static configuration iface eth0 inet6 static pre-up modprobe ipv6 address 2001:470:67:88::10 netmask 64 ### END IPV6 configuration
Reset the interface and check its addresses:
server# ifup --force eth0
server# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:30:1b:82:cb:42
inet addr:192.168.1.200 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:1bff:fe82:cb42/64 Scope:Link
inet6 addr: 2001:470:67:88::10/64 Scope:Global
And now the interface has a global, static IPv6 address. You can demonstrate this with a quick SSH to the global address, from another client on the home network:
laptop$ ssh -v tep@2001:470:67:88::10 OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to 2001:470:67:88::10 [2001:470:67:88::10] port 22. debug1: Connection established. ...
And we’re done. Next, DNS AAAA records and services.
Thuktun (Message) 
#1 by Hari on March 10, 2012 - 8:04 pm
Hi,
After modifying the /etc/network/interfaces file and after restart i am getting the below output:
——————————————————————————–
[root@appsrvr ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0C:29:80:F4:CC
inet addr:192.168.237.130 Bcast:192.168.237.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe80:f4cc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27463 errors:0 dropped:0 overruns:0 frame:0
TX packets:39747 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3890795 (3.7 MiB) TX bytes:45850776 (43.7 MiB)
Interrupt:67 Base address:0x2000
———————————————————————————
I am not getting address which i gave in the /etc/network/interfaces file. Pls suggest. Thanks.
Regards,
Hari
#2 by tomperrine on March 11, 2012 - 6:51 am
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.
#3 by Hari on March 12, 2012 - 6:13 am
Hi Tom,
Thanks for your reply… Providing you the details below:
1) OS & Version:
——————————————————————————-
Oracle Enterprise Linux 5.5
——————————————————————————-
2) Contents of “/etc/network/interfaces” file:
——————————————————————————-
[root@appsrvr ~]# cat /etc/network/interfaces
### Start IPV6 static configuration
iface eth0 inet6 static
pre-up modprobe ipv6
address 2001:470:67:88::10
netmask 64
### END IPV6 configuration
——————————————————————————-
3) Permissions:
——————————————————————————-
[root@appsrvr ~]# ls -ltr /etc/network/interfaces
-rw-r–r– 1 root root 151 Mar 12 18:38 /etc/network/interfaces
——————————————————————————-
Kindly let me know for any more details.
Thanks once again.
Regards,
Hari
#4 by tomperrine on March 12, 2012 - 6:36 am
Hmmm. I think you have a few issues here.
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?
#5 by PCPKI on March 24, 2017 - 5:58 am
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?
#6 by tomperrine on March 24, 2017 - 10:54 am
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.
Specifically – look at this page: http://bgp.he.net/AS6939#_prefixes6
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”.
Let me know if this isn’t clear or you want more info.
Thanks for asking the question.
#7 by tomperrine on March 24, 2017 - 11:04 am
And the other part of your question, which I missed is “how does your router get the packets to you without having your computer’s address”.
IPv6 “kinda has” ARP – it’s called “Neighbor Discovery” and uses multcast instead of broadcast. See https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
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.
Better answer?
#8 by PCPKI on March 24, 2017 - 2:10 pm
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.
#9 by tomperrine on March 24, 2017 - 4:19 pm
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.