From owner-freebsd-net@freebsd.org Tue Mar 16 21:58:32 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E485056FA05 for ; Tue, 16 Mar 2021 21:58:32 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.sermon-archive.info (sermon-archive.info [47.181.130.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0Rxg5dPPz3lhY for ; Tue, 16 Mar 2021 21:58:31 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 4F0Rxf3yZ8z2fjRk for ; Tue, 16 Mar 2021 14:58:30 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: IPv6 Startup Date: Tue, 16 Mar 2021 14:58:30 -0700 References: <06A12556-0C24-48AD-9D1C-C04491AADAF6@sermon-archive.info> <5EDD7B95-A25C-4414-B0CA-8A245A8FA920@sermon-archive.info> <20210316105444.GA15531@belenus.iks-jena.de> To: freebsd-net@freebsd.org In-Reply-To: <20210316105444.GA15531@belenus.iks-jena.de> Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Virus-Scanned: clamav-milter 0.103.0 at mail X-Virus-Status: Clean X-Rspamd-Queue-Id: 4F0Rxg5dPPz3lhY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bc979@lafn.org designates 47.181.130.121 as permitted sender) smtp.mailfrom=bc979@lafn.org X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.181.130.121:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.181.130.121:from:127.0.2.255]; DMARC_NA(0.00)[lafn.org: no valid DMARC record]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5650, ipnet:47.181.128.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 21:58:33 -0000 -- Doug > On 16 March 2021, at 03:54, Lutz Donnerhacke = wrote: >=20 > On Mon, Mar 15, 2021 at 05:29:55PM -0700, Doug Hardie wrote: >> I reduced the configuration to the host settings: >> ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" >>=20 >> The router to: >> ifconfig_ue0_ipv6=3D"up" >>=20 >> Ran tcpdump on the router (obviously not acting as a router) and = restarted the host. Got the following: >>=20 >> tcpdump: listening on ue0, link-type EN10MB (Ethernet), capture size = 262144 bytes >=20 > 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. >=20 > 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. >=20 >> 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)] >=20 > 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. >=20 >> 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 >=20 > 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. >=20 >> 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 >=20 > 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. >=20 >> 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 >=20 > No router answered, maybe the packet was lost. So the device ask again = for a > router in order to complete SLAAC.