Re: IPv6 neighbor solicitations to use link-local source address
On Thu, 4 Sep 2014 13:12:38 +0200
Julien boooo <jumboooh@gmail.com> wrote:
> 2014-09-04 12:32 GMT+02:00 mett <mett@pmars.jp>:
>
> > On Thu, 4 Sep 2014 18:50:01 +0900
> > mett <mett@pmars.jp> wrote:
> >
> > > On Thu, 4 Sep 2014 09:12:46 +0200
> > > Julien boooo <jumboooh@gmail.com> wrote:
> > >
> > > > Hi mett, thank you for your answer. I hope that I'm not
> > > > top-posting too ping6 -I doesn't change anything, the box is
> > > > still using the global scope address.
> > > >
> > > > Best regards
> > > > Julien
> > > >
> > > >
> > > >
> > > > 2014-09-04 2:32 GMT+02:00 mett <mett@pmars.jp>:
> > > >
> > > > > On Thu, 4 Sep 2014 09:04:00 +0900
> > > > > mett <mett@pmars.jp> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > When pinging link-local addresses, u need to specify the
> > > > > > exit interface. So maybe if u specify the exit interface
> > > > > > and another link-local as destination, you might be able to
> > > > > > do it:
> > > > > >
> > > > > >
> > > > > > ----------------------
> > > > > > mett@asus:~$ ip -6 add show
> > > > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
> > > > > > inet6 ::1/128 scope host
> > > > > > valid_lft forever preferred_lft forever
> > > > > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen
> > > > > > 1000 inet6 fe80::20c:6eff:fef8:7d1c/64 scope link
> > > > > > valid_lft forever preferred_lft forever
> > > > > > mett@asus:
> > > > > > ----------------------
> > > > > > root@tamirrsso:/var/log# ip -6 add show
> > > > > > ....
> > > > > > 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen
> > > > > > 1000 inet6 fe80::207:95ff:fed5:2fda/64 scope link
> > > > > > valid_lft forever preferred_lft forever
> > > > > > root@tamirrsso:/var/log#
> > > > > > ----------------------
> > > > > > mett@asus:~$ ping6 -I eth0 fe80::207:95ff:fed5:2fda
> > > > > > PING fe80::207:95ff:fed5:2fda(fe80::207:95ff:fed5:2fda) from
> > > > > > fe80::20c:6eff:fef8:7d1c eth0: 56 data bytes 64 bytes from
> > > > > > fe80::207:95ff:fed5:2fda: icmp_seq=1 ttl=64 time=0.433 ms 64
> > > > > > bytes from fe80::207:95ff:fed5:2fda: icmp_seq=2 ttl=64
> > > > > > time=0.205 ms 64 bytes from fe80::207:95ff:fed5:2fda:
> > > > > > icmp_seq=3 ttl=64 time=0.201 ms 64 bytes from
> > > > > > fe80::207:95ff:fed5:2fda: icmp_seq=4 ttl=64 time=0.256 ms 64
> > > > > > bytes from fe80::207:95ff:fed5:2fda: icmp_seq=5 ttl=64
> > > > > > time=0.199 ms
> > > > > >
> > > > > >
> > > > > >
> > > > > > HTH!
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 3 Sep 2014 15:55:38 +0200
> > > > > > Julien boooo <jumboooh@gmail.com> 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/64 scope global
> > > > > > > valid_lft forever preferred_lft forever
> > > > > > > inet6 fe80::a00:27ff:fe02:3cbd/64 scope link
> > > > > > > valid_lft forever preferred_lft forever
> > > > > > >
> > > > > > > # 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 or if it's just
> > > > > > > impossible, I would really appreciate your help.
> > > > > > >
> > > > > > > Thank you
> > > > > > > Best resgards
> > > > > > > Julien
> > > > > >
> > > > > >
> > > > >
> > > > > By the way, sorry for top-posting...
> > > > >
> > > > >
> > > > > --
> > > > > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> > > > > with a subject of "unsubscribe". Trouble? Contact
> > > > > listmaster@lists.debian.org
> > > > > Archive:
> > > > > [🔎] 20140904093203.696b0eff@asus.tamerr">https://lists.debian.org/[🔎] 20140904093203.696b0eff@asus.tamerr
> > > > >
> > > > >
> > >
> > > Hey,
> > >
> > > U cannot ping a global address with a link-local address.
> > > If you want to use your link-local address as source, u need to
> > > ping the link-local address of your destination
> > > (and need to specify exit interface).
> > >
> > > Global IP addresses(Layer 3) and Link-local addresses(not Layer
> > > 3) are on different scopes or spans(or layer).
> > > Because of that, they cannot interact.
> > >
> > > Also, not really related but better to reply to the Debian-list
> > > than sending a personal mail. Other readers might benefit of this
> > > exchange.
> > >
> > > Finally, better to write your answer down, at the end of the msg;
> > > easier to follow the whole story at a glance.
> > >
> > > HTH.
> > >
> >
> >
> > Sorry, might be better to say that link-local addresses are Layer 3
> > but they perform only on a single layer 2 domain, they cannot leave
> > their layer 2 domain and it's not possible to route them.
> > => you can ping only same prefix/prefix-length, ie. fe80::/64 from
> > same prefix.
> >
> > HTH.
> >
> >
> >
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > listmaster@lists.debian.org
> > Archive:
> > [🔎] 20140904193248.41b9663e@asus.tamerr">https://lists.debian.org/[🔎] 20140904193248.41b9663e@asus.tamerr
> >
> >
> Hi Mett, thank you for your answers.
>
> Well, after reading a lot it appears that ndp neighbor sollicitations
> could be done either with the global scope and the link-local scope
> addresses (which are both layer 3). Implementations in linux and bsd
> are to use the global scope address because the target box will then
> register the sender's global address and won't have to initiate
> another neighbor sollicitation to send the answer. This is a network
> optimisation.
>
> However, the idea to use the link-local scope address is not stupid
> because NDP is a link-local protocol. So forcing the use of
> link-local addresses could prevent the ndp messages from being
> injected into the network infrastructure from beyond a directly
> connected layer-2 access network. I suppose this method could be
> another level of proctection against spoofing for example.
>
> bests
> Julien
Hi Julien,
I am not sure if it's what you re looking for, but what about setting
up only a default route to your gateway's link local-address, on your
hosts?
I didn't do extensive tests but saw from wireshark that in this case,
your hosts' gateway will use its link-local address to NS(Neighbor
Solicitation) to both your hosts.
Then those hosts will answer with their Global IP to the link
local-address of your GTW.
Finally, your hosts will request/reply(with NS to each other before)
with both their Global IP.
HTH.
Reply to: