-- Doug
> On 16 March 2021, at 03:54, Lutz Donnerhacke <l...@donnerhacke.de> wrote: > > On Mon, Mar 15, 2021 at 05:29:55PM -0700, Doug Hardie wrote: >> I reduced the configuration to the host settings: >> ifconfig_bge0_ipv6="inet6 accept_rtadv" >> >> The router to: >> ifconfig_ue0_ipv6="up" >> >> Ran tcpdump on the router (obviously not acting as a router) and restarted >> the host. Got the following: >> >> tcpdump: listening on ue0, link-type EN10MB (Ethernet), capture size 262144 >> bytes > > The device is using a EUI-64 link local address, which is unique by > definition. Therefore no DAD is necessary, the address can be used > immediatly. If you use a manually generated address, even if it has a > EUI-64 form, DAD is required. DAD consists of Neighbour Solication > messages. > > I understand your point, questioning if DAD should be done in any case or > not. That's a complicated topic, which requires a lot of RFC exegesis, > studying interop tests results from the IETF and IPv6 certificate > organisations, and practical market dominance. I think there is more to that than is immediately obvious. Many of the cable internet providers in CA control the number of devices you can connect by tracking the MAC addresses. Some of them will force you to wait a time period if you change the modem. Others require you to call in and get it changed. People have a tendency to just go ahead and change the MAC on the new device to match the old to avoid those problems. Windows used to have the software to change the MAC addresses. I haven't used Windows in quite a few years so I don't know if it still does. If I want to mess with you, there is a very easy way to create a denial of service issue for you. Your MAC addresses are easily found from the IP EUI value. I simply build a small device that uses that MAC address and mail it to you requesting you "evaluate" a new product. Since most people will be using link-local addresses, it will effectively cause problems on their computers. Granted, that is probably not a very common occurance, until it happens to you. > >> 19:05:00.048637 IP6 (hlim 1, next-header Options (0) payload length: 56) >> fe80::aa60:b6ff:fe1d:8dbc > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 >> sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr >> ff02::2:ec7d:574c to_ex, 0 source(s)] [gaddr ff02::2:ffec:7d57 to_ex, 0 >> source(s)] > > Because IPv6 uses unicast and multicast only, the device registers itself > for the necessary link local multicast groups. Interesting. That must be registering with the router. All the routers except for one are quite old and I doubt they have that functionality. It will be interesting to see how that works in practice. > >> 19:05:00.171029 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) >> fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router >> solicitation, length 16 >> source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc > > The device will use SLAAC for address configuration, but do not want to wait > for the next Router Advertisement, so it asks for an immediate response from > the router. But it uses the link-local address that has not been checked. Thats not in accordance with at least one of the RFCs. Unless, there is a replacement section in some other RFC. Right now, the RFC situation is a colossal mess. The "requirements" are distributed through numerous RFCs, notes, etc. They contradict each other often, and they claim to replace sections of others. It is quite difficult to keep up with the current thinking. > >> 19:05:04.198640 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) >> fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router >> solicitation, length 16 >> source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc > > No router answered, maybe the packet was lost. So the device ask again for a > router in order to complete SLAAC. Then that probably was not a DAD packet. There was no "router" on the network. Both devices were configured as hosts. > >> 19:05:08.449844 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) >> fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router >> solicitation, length 16 >> source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc > > No router answered, maybe the packet was lost. So the device ask again for a > router in order to complete SLAAC. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
