ipv6 default router Operation not permitted

[Schrodinger]

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....
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> 
> That is a good question and I'd be interested in an answer too.
> 

Great!!! It's not just me then.

> Perhaps FreeBSD is implementing a predecessor to RFC 4861,
> i.e. the now obsolete RFC 2461:
> 
> 
> 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".
> 
> 
> 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.
> 

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 
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=40+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=-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                          
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=40+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=-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.
-- 
+---------------------------------------------------------------+
Quidquid latine dictum sit, altum sonatur.
MSN: schro5 at hotmail.com
ICQ: 112562229
GPG: http://www.konundrum.org/schro.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20130313/0705d56c/attachment.sig>