Yes you are absolutely right. I've set this /8 mask for a test and I forgot
to set it back to /64. Sorry.
However, the behavior is exactly the same with /64 mask :
~# ip -6 addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2a10:7e40:edf6:100::32/64 scope global tentative
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe02:3cbd/64 scope link
valid_lft forever preferred_lft forever
09:18:06.731082 IP6 2a10:7e40:edf6:100::32 > ff02::1:ff00:33: ICMP6,
neighbor solicitation, who has 2a10:7e40:edf6:100::33, length 32
09:18:06.731460 IP6 2a10:7e40:edf6:100::33 > 2a10:7e40:edf6:100::32: ICMP6,
neighbor advertisement, tgt is 2a10:7e40:edf6:100::33, length 32
09:18:06.731477 IP6 2a10:7e40:edf6:100::32 > 2a10:7e40:edf6:100::33: ICMP6,
echo request, seq 1, length 64
09:18:06.731896 IP6 2a10:7e40:edf6:100::33 > 2a10:7e40:edf6:100::32: ICMP6,
echo reply, seq 1, length 64
2014-09-02 17:16 GMT+02:00 Kenyon Ralph <[email protected]>:
> On 2014-09-02T15:53:44+0200, Julien boooo <[email protected]> wrote:
> > Hello everybody
> >
> > I'm very new to lists.debian.org so please appologize if I am doing
> > something wrong by sending this email. I'm just out of idea with a
> behavior
> > in NDP and must find a solution. I didn't find anything on the internet.
> >
> > RFC4861 section 7.2.2 says that the source address in NDP neighbor
> > solicitations can be any one of the addresses assigned to the interface.
> It
> > also says that using the prompting packet's source address ensures that
> the
> > recipient installs it in its neighbor cache.
> > The latter is the behavior I can see on my boxes (a debian 6.0.9 + custom
> > kernel 3.2.14) and also on a Centos one.
> >
> > # ip -6 addr list
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
> > inet6 ::1/128 scope host
> > valid_lft forever preferred_lft forever
> > 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > inet6 2a10:7e40:edf6:100::32/8 scope global
> > valid_lft forever preferred_lft forever
> > inet6 fe80::a00:27ff:fe02:3cbd/64 scope link
> > valid_lft forever preferred_lft forever
>
>
> I would guess the problem is related to the /8 network prefix you have
> assigned to eth0. You should really only use /64 for regular host
> network segments, but /8 is definitely wrong.
>
>
> > # ping6 2a10:7e40:edf6:100::33 -c 3 &>/dev/null &
> > # tcpdump -nli eth0 icmp6
> >
> > 18:09:04.726908 IP6 2a10:7e40:edf6:100::32 > ff02::1:ff00:33: ICMP6,
> > neighbor solicitation, who has 2a10:7e40:edf6:100::33, length 32
> > 18:09:04.727373 IP6 2a10:7e40:edf6:100::33 > 2a10:7e40:edf6:100::32:
> > ICMP6, neighbor advertisement, tgt is 2a10:7e40:edf6:100::33, length
> > 32
> > 18:09:04.727391 IP6 2a10:7e40:edf6:100::32 > 2a10:7e40:edf6:100::33:
> > ICMP6, echo request, seq 1, length 64
> > 18:09:04.727738 IP6 2a10:7e40:edf6:100::33 > 2a10:7e40:edf6:100::32:
> > ICMP6, echo reply, seq 1, length 64
> >
> >
> > My question is : How can I force ndp to use the link-local address
> assigned
> > to that outgoing device ? (in the trace above, ndp would then send the
> > neighbor solicitation with fe80::a00:27ff:fe02:3cbd source address).
> >
> > This is requested by our customer for security reasons and as far as I
> can
> > see it complies with RFC4861 as well.
> >
> > If someone had a clue how to do that (maybe in sysctl ?) or if it's just
> > impossible, I would really appreciate your help.
> >
> > Thank you
> > Best resgards
> > Julien
>
> --
> Kenyon Ralph
>
