I set up a small network in which an OpenBSD machine serves as a
router for a collection of IPv6-only clients. Many thanks to previous
responders to my questions on tunneling with gif(4). This rudimentary
setup is working well: a client machine acquires an address via SLAAC
and can access the IPv6 Internet. I am curious, however, about the
addresses and routes that get installed on the client machine.
The setup straightforward. The router is connected to an IPv6 tunnel
on the Internet-facing side (using a gif(4) interface), it has IPv6
forwarding enabled, and is running rtadvd on the inward-facing
interface. Note that rtadvd is using its internal defaults; I didn't
create a configuration file for it because the man page
The interface info and routing table is at the end of this mail and
I've annotated lines of interest with numbers in brackets so that
referencing these entries in questions would be clearer. The questions
are:
1.) In addition to the self-assigned link-local address, the client's
interface has two other addresses, both having the network prefix
supplied by the router (annotation [1]). One has the same suffix as
that of the link-local address. The other, marked "autoconfprivacy",
is different and changes periodically (certainly on every reboot). I
assume this address is formed with the rules defined in RFC 4941. As I
interpret it, the RFC suggests a scheme that employs different
addresses for server-oriented tasks and client-oriented tasks. The
idea is that a predicable address is suitable for the former, while a
randomized one is for the latter. Is that what's happening here?
According to netstat(1), this seems to be the case. While surfing the
web, the local address always seems to be the one with the
autoconfprivacy attribute. Is rtsol(8) in charge of implementing this
policy?
2.) A corollary to the above question is how the "privacy" address
gets used for outbound connections. My assumption of how interfaces
with multiple addresses behave is this: the interface will accept
connections for any address it has been assigned, but will use the
"canonical" one for connections that are initiated through that
interface. Is this correct? Does IPv6 have the notion of "aliases" at
all? If it does, how do you know which one is the "canonical"
address. If not, how do outbound connection end up with the "correct",
i.e. private, local address?
3.) The default route (annotation [2]) mystified me at first, before I
realized that the gateway address was the link-local address of the
router. I was aware of link-local addresses in IPv6, but I was unsure
of their application and didn't expect them to come into play here. I
expected the gateway to be the IPv6 address I assigned to the router's
inward facing interface. It seems logical that the router's link-local
address works, but why was it chosen?
4.) The /64 network route for my network has the gateway specified as
"link#1" (annotation [3]). What are the "link" family of interfaces?
These must be different than routes that specify one of the link-layer
addresses, but how?
Thanks,
Chuck
Output of ifconfig em0 and netstat -nrf inet6, with [annotations]:
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr f0:de:f1:78:d5:4c
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet6 fe80::f2de:f1ff:fe78:d54c%em0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f05:204:f2de:f1ff:fe78:d54c prefixlen 64 autoconf
pltime 604280 vltime 2591480 [1]
inet6 2001:470:1f05:204:1039:d2fd:9b56:709 prefixlen 64 autoconf
autoconfprivacy pltime 77124 vltime 595610 [1]
Internet6:
Destination Gateway Flags Refs
Use Mtu Prio Iface
::/104 ::1 UGRS 0
0 - 8 lo0
::/96 ::1 UGRS 0
0 - 8 lo0
default fe80::92e2:baff:fe2b:b008%em0 UG 0
156 - 56 em0 [2]
::1 ::1 UH 14
0 33144 4 lo0
::127.0.0.0/104 ::1 UGRS 0
0 - 8 lo0
::224.0.0.0/100 ::1 UGRS 0
0 - 8 lo0
::255.0.0.0/104 ::1 UGRS 0
0 - 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0
0 - 8 lo0
2001:470:1f05:204::/64 link#1 UC 1
0 - 4 em0 [3]
2001:470:1f05:204::1 90:e2:ba:2b:b0:08 UHLc 0
30 - 4 em0
2001:470:1f05:204:24c5:ec52:ca52:a9e7 f0:de:f1:78:d5:4c UHL
0 0 - 4 lo0
2001:470:1f05:204:f2de:f1ff:fe78:d54c f0:de:f1:78:d5:4c UHL
0 0 - 4 lo0
2002::/24 ::1 UGRS 0
0 - 8 lo0
2002:7f00::/24 ::1 UGRS 0
0 - 8 lo0
2002:e000::/20 ::1 UGRS 0
0 - 8 lo0
2002:ff00::/24 ::1 UGRS 0
0 - 8 lo0
fe80::/10 ::1 UGRS 0
0 - 8 lo0
fe80::%em0/64 link#1 UC 1
0 - 4 em0
fe80::92e2:baff:fe2b:b008%em0 90:e2:ba:2b:b0:08 UHLc 1
34 - 4 em0
fe80::f2de:f1ff:fe78:d54c%em0 f0:de:f1:78:d5:4c UHL 0
0 - 4 lo0
fe80::%lo0/64 fe80::1%lo0 U 0
0 - 4 lo0
fe80::1%lo0 link#4 UHL 0
0 - 4 lo0
fec0::/10 ::1 UGRS 0
0 - 8 lo0
ff01::/16 ::1 UGRS 0
0 - 8 lo0
ff01::%em0/32 link#1 UC 0
0 - 4 em0
ff01::%lo0/32 fe80::1%lo0 UC 0
0 - 4 lo0
ff02::/16 ::1 UGRS 0
0 - 8 lo0
ff02::%em0/32 link#1 UC 0
0 - 4 em0
ff02::%lo0/32 fe80::1%lo0 UC 0
0 - 4 lo0
