for IPv6 link local addresses.
Some hosting and VM providers route customer IPv6 prefixes to link
local addresses derived from ethernet MAC addresses (RFC 2464). This
leads to hard to debug IPv6 connectivity problems and is probably not
worth the effort.
RFC 7721 lists 4 weaknesses:
3.1. Correlation of Activities over Time & 3.2. Location Tracking
These are still possible with RFC 7217 addresses for an adversary
connected to the same layer 2 network (think conference wifi). Since
the link local prefix stays the same (fe80::/64) the link local
addresses do not change between different networks.
An adversary on the same layer 2 network can probably track ethernet
MAC addresses via different means, too.
3.3. Address Scanning & 3.4. Device-Specific Vulnerability Exploitation
These now become possible, however, as noted above a layer 2 adversary
was probably able to do this via different means.
People concerned with these weaknesses are advised to use
ifconfig lladdr random.
OK benno
input & OK kn
Benno removed code to answer ICMP queries over 4 years ago.
Aham Brahmasmi (aham.brahmasmi AT gmx.com) points out
that we still joined the group though.
OK sthen, bluhm, kn
Interface Identifiers with IPv6 Stateless Address Autoconfiguration."
"An IPv6 address configured using this method is stable within each
subnet, but the corresponding Interface Identifier changes when the
host moves from one network to another. This method is meant to be an
alternative to generating Interface Identifiers based on hardware
addresses."
OK naddy, sthen
interfaces.
When the kernel automagically configures IPv6 addresses on loopback
interfaces, start by assigning a link-local address and then try to
assign "::1".
Only the first configured loopback interface per rdomain can have the
"::1" address. But even if other loopback interfaces failed to get
this address, because it is already taken, give them a chance to have
a link-local address.
While here change in6_ifattach() to return an error value and remove
duplicated code.
Fix a regression introduced by the NOINET6 flag removal.
ok henning@, stsp@, florian@, benno@
Really change the link-local address in the unlikely event of an IFID
collision, instead of going into an infinite conf-nak loop with the peer.
To make the netinet6 code use the IPv6CP IFID in a new link-local address,
in6_ifattach_linklocal() must accept a provided IFID. Replace the unused
'altifp' parameter with a new 'ifid' parameter for this purpose.
Always use the latest suggested address in IPv6CP replies, even if
the task to update the interface's address hasn't run yet.
Also, clear the ifindex (KAME hack) in addresses sent during IPv6CP.
ok mpi
virtual MAC address is set. Among other things, this makes route6d work
correctly on systems with carp interfaces.
In order to ensure backwards compatibility, we do not include IPv6
link-local addresses in generating the HMAC, but we accept HMACs with AND
without the link-local addresses. They will be added to the HMAC in a future
release.
In short: this change should only affect backwards compatibility for
IPv6 users who are manually adding link-local addresses on carp interfaces.
testing mtu@ todd@
ok mpf@ henning@ deraadt@
behavior changes:
- two iocts used by ndp(8) are now obsolete (backward compat provided).
use sysctl path instead.
- lo0 does not get ::1 automatically. it will get ::1 when lo0 comes up.
interface (2) cleanup interface id selection.
run NUD on p2p interface (required by spec for bidir p2p interface).
add "ndp -i interface" (can tweak per-interface ND flag).
(sync with more recent kame)
replaces NRL IPv6 layer. reuses NRL pcb layer. no IPsec-on-v6 support.
see sys/netinet6/{TODO,IMPLEMENTATION} for more details.
GENERIC configuration should work fine as before. GENERIC.v6 works fine
as well, but you'll need KAME userland tools to play with IPv6 (will be
bringed into soon).
