Date: Sat, 16 Sep 2000 23:05:54 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: "Jacques A. Vidrine" <n@nectar.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: ICMP6 redirect rejected; not equal to gw-for-src Message-ID: <y7vd7i4fn3x.wl@condor.isl.rdc.toshiba.co.jp> In-Reply-To: In your message of "Thu, 14 Sep 2000 20:18:17 -0500" <20000914201817.A1041@spawn.nectar.com> References: <20000914201817.A1041@spawn.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Thu, 14 Sep 2000 20:18:17 -0500, >>>>> "Jacques A. Vidrine" <n@nectar.com> said: > Can anyone decipher the following from me (shows up on console when > pinging across a link): > ICMP6 redirect rejected; not equal to gw-for-src=0040:9633:a3e7:: (must be same): (src=fe80:0007::0240:96ff:fe33:a3e7 dst=fec0:0002::0240:96ff:fe33:a3e7 tgt=fe80:0007::0240:96ff:fe31:e63c) In any case, I'm now quite confident what happened. Since the host and the gateway shared a site-local subnet fec0:2::/64, and the host resolved the link-layer address of the gateway's site-local address, the host directly sent a packet to the gateway. The gateway received the packet, and saw its routing table to check if the packet was destined to the gateway itself. As you showed, the gateway had an entry for the destination with another gateway on the same link attached to the incoming interface. Thus, the gateway just forwarded to the packet to the (another) gateway, and sent an ICMPv6 redirect message to the host. (note that the logic to process the incoming packet is diffrent from one of IPv4. If you want to know more details about the process, please see Section 3.2 of http://www.isoc.org/inet99/proceedings/4s/4s_2.htm) When the host received the redirect message, it validated the redirect's source address; the source address MUST be same as the correct gateway for the destination of the original packet, according to the specification. In this case, however, the gateway is a link-layer address, so the validation should simply failed. Now, we have a bug here, the validation routine should check the address family of the route entry (for the original destination), but it didn't. As a consequence, the host regarded the link-layer address as an AF_INET6 gateway, and hence, it printed the odd address (0040:9633:a3e7::). We've already fixed the bug in the FreeBSD (current) repository, and the fix will soon be merged into the stable branch. Thanks for the report. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vd7i4fn3x.wl>