DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
This commit implements MAC cloning feature in NetworkManager. To support that,
'PermHwAddress' property is added into *.Device.Wired and *.Device.Wireless
interfaces. The permanent MAC address is obtained when creating the device, and
is used for 'locking' connections to the device. If a cloned MAC is specified
in connection to be activated, the MAC is set to the interface in stage1. While
disconecting, the permanent MAC is set back to the interface.
Use the interfaces kernel index when we can to avoid unecessary
iface->index lookups; and let callers figure out which address
family they really want to flush.
