On Mon, Jun 26, 2017 at 01:34:37PM +0200, Martin Pieuchot wrote:
> On 26/06/17(Mon) 12:39, Marc Peters wrote:
> > Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> > > [...]
> > > Could you set net.inet6.icmp6.nd6_debug to 1 and redo this?
> > >
> > > Do you see anything in the log?
> >
> > Rebooting the box with the sysctl active show following /var/log/messages:
> >
> > Jun 26 12:25:35 arafel /bsd: nd6_na_input: ND packet from non-neighbor
>
> Indeed.
>
> Your machine is asking with the following address:
>
> 2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: icmp6: neighbor sol: who has
> fe80::1
>
> Your provider is answering with an address that doesn't match your
> subnet:
>
> 2a01:4f8::a:21:b > 2a01:4f8:212:216c::1:443: icmp6: neighbor adv: tgt is
> fe80::1 [class 0xc0]
>
> It'd be nice if somebody could tell us what the RFCs say about this
> case. Florian do you have an idea? Should we fix something or should
> Marc tell his provider to fix his setup?
this was introduced by claudio@ in rev. 1.53 of nd6_nbr.c:
If a neighbor solictation isn't from the unspecified address, make sure
that the source address matches one of the interfaces address prefixes.
From NetBSD, tested by todd@ and naddy@
netbsd added this in their rev 1.89 and 1.90:
If a neighbor solictation isn't from the unspecified address, make sure
that the source address matches one of the interfaces address prefixes.
and:
Generalize previous fix so that both NS and NA packets are checked.
However, I don't get why. Other than being extra paranoia defending
against a misbehaving router maybe?. We already check a hop limit of
255, so the packet had to be generated on-link and not forwarded by a
router.
RFC4861 defines a "valid advertisement":
7.1.2. Validation of Neighbor Advertisements
A node MUST silently discard any received Neighbor Advertisement
messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- Target Address is not a multicast address.
- If the IP Destination Address is a multicast address the
Solicited flag is zero.
- All included options have a length that is greater than zero.
The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values.
The contents of any defined options that are not specified to be used
with Neighbor Advertisement messages MUST be ignored and the packet
processed as normal. The only defined option that may appear is the
Target Link-Layer Address option.
A Neighbor Advertisements that passes the validity checks is called a
"valid advertisement".
( https://tools.ietf.org/html/rfc4861#section-7.1.2 )
So I think we should remove the check by reverting claudio's commit.
I can cook a diff if we we agree to move in that direction.
The router might however still be misbehaving. The RFC does not
clearly state from where the respons must be send, it only has this:
7.2.4. Sending Solicited Neighbor Advertisements
[...]
The Target Address of the advertisement is copied from the Target Address
of the solicitation.
I think we would accept the adv if the router responded from fe80::1
--
I'm not entirely sure you are real.
