Networking/Addressing

Loopback (aka node-local) addresses

The loopback addresses are used for communication among processes in the local host. They are automatically assigned by the kernel to a special loopback interface with index 1 called lo.

IPv4 uses 127.0.0.1/24 address and IPv6 uses ::1/128 address. That means IPv4 allows for some magic with other addresses from the same network, while IPv6 doesn't. For that reason, the prefix length should be generally ignored and both addresses should be treated as single addresses for all use cases.

# ip address show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

The only thing userspace has to do is to activate the interface (as in ip link set lo up), ideally during the boot. Unless lo is already up, NetworkManager does that.

Link-local addresses (mostly IPv6-only)

Link-local addresses on Ethernet work without any configuration tools except that you have to activate the respective interface first.

device=eth1
ip link set $device up

Kernel automatically assigns a MAC-derived link-local address to any active Ethernet interface.

ip address show dev $device

If you know another link-local address on the network, you should be able to test it with the ping command.

ping fe80:...%$device

Oh, wait, ping doesn't work. Use ping6.

ping6 ...

Failed again. Now we're getting to the point. Link-local addresses use the same network prefix on every interface. We need to specify the local network interface to be used to contact the particular link-local address.

ping6 ...%eth0

Global addresses the static way

Adding IP addresses directly at runtime is easy. You should always include the prefix length if you want to have your device route set up.

ip address add 192.168.1.1/24 dev eth0
ip address add 2001:db8:1:2::1 dev eth0

The ip command allows you to do most of the network interface configuration. If this is all what you need, you don't need any network daemons or network configuration files. All you need is to run a script to set everything up early during the boot process.

Global addresses the dynamic way

Dynamic IPv4 configuration

IPv4 DHCP example (/etc/dhcp/dhcpd.conf):

option domain-name "example.org";
option domain-name-servers 10.0.255.1;

authoritative;

subnet 10.0.15.0 netmask 255.255.255.0 {
    range 10.0.15.100 10.0.15.120;
    option routers 10.0.15.1;
}

IPv4 static IP example:

host station {
    hardware ethernet 52:54:ab:15:02:22;
    fixed-address 10.0.15.2;
}

On the client side using NetworkManager, DHCP is the default IPv4 method. For testing without NetworkManager, you can just use the ISC DHCP client.

dhclient eth0

The easiest way to get rid of running DHCP clients is:

killall dhclient

Dynamic IPv6 configuration

SLAAC without DNS configuration (mandatory by RFC 4294)

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    prefix 2001:db8:1:2::/64 {};
};

DNS queries typically use IPv4. NetworkManager supports this configuration and it also works when device is ignored by NetworkManager.

SLAAC with RDNSS and DNSSL

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    prefix 2001:db8:1:2::/64 {};
    RDNSS 2001:db8:1:2::ab {};
    DNSSL example.net {};
};

The contents of host's /etc/resolv.conf is filled in by NetworkManager. Linux kernel currently supports RDNSS but not DNSSL. NetworkManager has problems with RDNSS but they have to be solved also on IETF level. DNSSL support cannot be tested in NetworkManager because of lack of kernel support. Kernel 3.5 will have DNSSL support.

SLAAC with DHCPv6 Information Request

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    AdvOtherConfigFlag on;
    prefix 2001:db8:1:2::/64 {};
};

/etc/dhcp/dhcpd6.conf:

subnet6 2001:db8:1:2::/64 {
    option dhcp6.name-servers 2001:db8:1:2::ab;
    option dhcp6.domain-search "example.net";
}

This is often used to supply DNS information to hosts that don't support RDNSS/DNSSL in Router Advertisements. NetworkManager works well in this scenario if DHCPv6 packets get through firewall.

There have been problems with IPv6 firewall blocking DHCPv6 exchange. Right now Fedora has two firewall configuration services. I hope to test both of them later.

DHCPv6 address-only, all other by RA

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix 2001:db8:1:2::/64 {
        AdvAutonomous off;
    };
    RDNSS 2001:abcd:1:1::ab {};
    DNSSL example.net {};
};

/etc/dhcp/dhcpd6.conf:

subnet6 2001:db8:1:2::/64 {
    range6 2001:db8:1:2::1:0000 2001:db8:1:2::1:ffff;
}

DHCPv6 is used only for address configuration, RA does everything else. NetworkManager works in this scenario except DNSSL (see above).

Note that AdvManagedFlag implies AdvOtherConfigFlag functionality too.

DHCPv6 address and DNS configuration

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix 2001:db8:1:2::/64 {
        AdvAutonomous off;
    };
};

/etc/dhcp/dhcpd6.conf:

subnet6 2001:db8:1:2::/64 {
    option dhcp6.name-servers 2001:db8:1:2::ab;
    option dhcp6.domain-search "example.net";
    range6 2001:db8:1:2::1:0000 2001:db8:1:2::1:ffff;
}

This is a typical DHCPv6 configuration. Note that routing information are stil delivered through Router Advertisements. NetworkManager may fail in this scenario.

IPv6 reconfiguration

IPv6 automatic configuration is pretty dynamic and can change very quickly. Currently NetworkManager doesn't respond well to some dynamic changes of configuration.

Note: Current version of NetworkManager (0.9.6) doesn't reflect default gateway changes in Router Advertisements.