Date: Wed, 13 Mar 2013 18:54:49 +0000 From: Schrodinger <schrodinger@konundrum.org> To: freebsd-net@freebsd.org Subject: Re: ipv6 default router Operation not permitted Message-ID: <20130313185449.GA20353@defiant.konundrum.org> In-Reply-To: <201303131812.36388.Mark.Martinec%2Bfreebsd@ijs.si> References: <20130312225018.GA13589@defiant.konundrum.org> <201303131659.04074.Mark.Martinec%2Bfreebsd@ijs.si> <20130313162700.GD18992@defiant.konundrum.org> <201303131812.36388.Mark.Martinec%2Bfreebsd@ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
--6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013/03/13 18:12, Mark Martinec wrote: > Schrodinger wrote: > > What I am confused about is that without ACCEPT_RTADV on re0, FreeBSD > > doesn't perform Neighbour Solicitation for the default gateway but with > > ACCEPT_RTADV it does ..... Why ? This is Neighbour Solicitation and not > > Router Solicitation.... > >=20 > > I understand that FreeBSD doesn't consider the defaulte gateway to be > > "on-link" so it does not perform ND for it but why does it perform ND > > when ACCEPT_RTADV is set on re0 ? "Surely" ACCEPT_RTADV only affects > > Router Advertisements / Solicitations and not ND. > >=20 > > I have done packet captures and with ACCEPT_RTADV I see the initial > > Neighbour Solicitation and the Neighbour Advertisement to and from my > > default gateway. > >=20 > > Without ACCEPT_RTADV - FreeBSD simply doesn't try to perform ND for the > > address. This is where I am uncertain if this is expected or not. >=20 > That is a good question and I'd be interested in an answer too. >=20 Great!!! It's not just me then. > Perhaps FreeBSD is implementing a predecessor to RFC 4861, > i.e. the now obsolete RFC 2461: >=20 >=20 > RFC 4861, Appendix F: Changes from RFC 2461 > o Removed the on-link assumption in Section 5.2 based on RFC 4943, > "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful". >=20 >=20 > RFC 4943, Abstract > This document describes the historical and background information > behind the removal of the "on-link assumption" from the conceptual > host sending algorithm defined in Neighbor Discovery for IP Version 6 > (IPv6). According to the algorithm as originally described, when a > host's default router list is empty, the host assumes that all > destinations are on-link. >=20 Based on what is documented in RFC 4943 is FreeBSD not working as expected ? Since it does not perform ND for the default gateway because it isn't seen as on-link and FreeBSD is not making the on-link assumption? Correct? If I understand how FreeBSD should behave if applying RFC2461 when there is no default gateway configured it should assume the detination is on-link. Correct? I removed the default gateway, but left the interface host route for the default gateway address in the routing table and I still get "Operation not permitted" when I attempt to ping the address. # netstat -rn -f inet6 | fgrep ff:ff=20 default 2001:41d0:2:e7ff:ff:ff:ff:ff UGS = re0 2001:41d0:2:e7ff:ff:ff:ff:ff e0:69:95:88:0b:27 UHS = re0 # ping6 -c 1 2001:41d0:2:e7ff:ff:ff:ff:ff PING6(56=3D40+8+8 bytes) 2001:41d0:2:e7c4::1 --> 2001:41d0:2:e7ff:ff:ff:ff:= ff ping6: sendmsg: Operation not permitted ping6: wrote 2001:41d0:2:e7ff:ff:ff:ff:ff 16 chars, ret=3D-1 --- 2001:41d0:2:e7ff:ff:ff:ff:ff ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss # route delete -inet6 default =20 delete net default # netstat -rn -f inet6 | fgrep ff:ff 2001:41d0:2:e7ff:ff:ff:ff:ff e0:69:95:88:0b:27 UHS = re0 # ndp -c 2001:41d0:2:e7c4::1 (2001:41d0:2:e7c4::1) deleted fe80::e269:95ff:fe88:b27%re0 (fe80::e269:95ff:fe88:b27%re0) deleted # ping6 -c 1 2001:41d0:2:e7ff:ff:ff:ff:ff PING6(56=3D40+8+8 bytes) 2001:41d0:2:e7c4::1 --> 2001:41d0:2:e7ff:ff:ff:ff:= ff ping6: sendmsg: Operation not permitted ping6: wrote 2001:41d0:2:e7ff:ff:ff:ff:ff 16 chars, ret=3D-1 --- 2001:41d0:2:e7ff:ff:ff:ff:ff ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss Although this still does not immediately explain to me why ACCEPT_RTADV causes it to perform ND. Cheers, C. --=20 +---------------------------------------------------------------+ Quidquid latine dictum sit, altum sonatur. MSN: schro5@hotmail.com ICQ: 112562229 GPG: http://www.konundrum.org/schro.asc --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCgAGBQJRQMt4AAoJEBBi7cjNKnTjRRYP/Rhe47oA/ufaX/bcHIyxTlnx k+TPwI106NmHBx0hdUckOlpBOmrnE+tvWH/ll2jgO48OqVxFjXxtcNYmWu7ULkCK mONs+4P4ezfCf/aNFp275REfq86tqVXETueOn5BEbMIMKIQlLY72p0aypBOm8Ra4 ZYD6KS20ZXcQjqZBUhPSt7UJuOuYPvRx3ezWkoWehDs4UuPyO9nntblXNic8JTf9 g3FN9QaxWjgOUd5kXKh8+RTiijsnlfX9tqyIFSThYhQRPlT/PSwfrwWOSlGFTG7n DcDrUmw0wS8/siKERVj+C24+LRrPzjo6SmN8xu9undIvm43u1/G3Tj/dVHU/4qGn zlS2WqnewBSC1AlSoTfRNji893KpdwNUX/UZowZY41Tcfg7pLccATC6g8JhX/u/r Wt3uN53AGqRhU+uayOnnhXQP03GFf5iZzJWYCkopLTa3aB43hCfQVQgx5dIo/95t 870pUPyJoN7xNJ9mm8vj8a3zKNLeZrwTeij9rHljAG2dXVpL0/RdgGVs34LEUjaw OtfSnU1JhAAeU46HelFNWSKMGviZP6sktufEzeGhUceIQ1rCezWxRar3QsKL6LV1 3xilpIis/6JmL8VBCm3Y5EyX27Pf+evFq8R5c+vorIeNv8nVmIykQQkc/Q2cXZql 9B6Qcn0ONinqOjjbpiy2 =zngn -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130313185449.GA20353>