"Andrey V. Elsukov" <a...@freebsd.org> wrote in <c5400b5d-a391-c688-f569-d2f129925...@freebsd.org>,<c5400b5d-a391-c688-f569-d2f129925...@freebsd.org>:
ae> On 16.12.2016 03:24, Anderson Soares Ferreira wrote: ae> > I have a freebsd 11 box running as my network gateway and I’m having ae> > some trouble trying to route ipv6 packets through an interface with ae> > only linklocal address. In short, what I’m doing is: ae> > ae> > My freebsd gateway has one global scope address on lo0 interface, ae> > each other interface has only a link local address fe80::1. Static ae> > routes for the global scope subnets have been created, Each route was ae> > created using the command: ae> > ae> > # route -6 add -net <net address>/64 -interface <dev> ae> > ae> > The clients on each subnet have a global scope address and fe80::1 as ae> > default gateway. ae> > ae> > What is happening with this approach is that my gateway can’t reach ae> > the clients on the subnets. Ping tests from the gateway to the client ae> > return the error "ping6: sendmsg: No buffer space available”. On the ae> ae> Hi, ae> ae> this ENOBUFS error is returned from ND6 code. Due to the lack of ae> prefixes, layer2 doesn't consider that destination address is a ae> neighbor. ae> ae> > other hand, when I try to do a ping from client to gateway, the ae> > packets from the client are received by the gateway but no response ae> > is sent. In my tests using a linux gateway with the same approach, ae> > everything worked fine . ae> ae> I'm not sure how this should be fixed. A FreeBSD router box must have an IPv6 address on each interface if you want to reach the router from a client (and vice versa). Currently FreeBSD does not properly support an IPv6 GUA on an interface and a route of the GUA's prefix on another interface without an GUA at the same time, which is often seen on a dedicated router box like Cisco. This is partly because FreeBSD's NDP and routing table assume that an on-link prefix is interface-local, not node-local across multiple interfaces. A practical workaround is using an LLA (i.e. fe80::1 or something) for communication between the router and the clients. -- Hiroki
pgp8H9B4StVPQ.pgp
Description: PGP signature
