Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Simon Schneider]

Hi,
I noticed something I don't quite understand in a very basic scenario.

Two machines connected to each other, say A and B.

Both have their automatically configured link-local IPv6 addresses on the interface, plus one global IPv6 interface address.

A pings the global address of B.

What happens:
1) Address resolution from A to B. B creates a neighbor cache entry for A's address in STALE state. Since B sends Neighbor Advertisement back to A, the entry moves to DELAY and the delay_first_probe_time timer (5s) is started.

2) After successful resolution, echo request / reply are exchanged.

3) After delay_first_probe_time at B expires, B transmits a unicast Neighbor Solicitation to A's global address (reachability check). 

All good so far.

However, although the destination address of the NS has global scope, B uses its link-local address as source.

I don't think this is correct. According to the source address selection rules in RFC3484, chapter 5, Rule 2 should match and B's global interface address should be used as source.

In this simple example, it leads to a sequence of further reachability checks for the link-local addresses of A and B. I don't think these are necessary and they could be avoided if B had used its global interface address as source in the first NS.

Observed under kernel version 3.11.

Is this a bug or do I miss something?

Comments highly appreciated.

best regards, Simon Schneider

Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Hannes Frederic Sowa]

Hi Simon!

On Wed, Mar 05, 2014 at 03:00:29PM +0100, Simon Schneider wrote:
> I noticed something I don't quite understand in a very basic scenario.
> 
> Two machines connected to each other, say A and B.
> 
> Both have their automatically configured link-local IPv6 addresses on the interface, plus one global IPv6 interface address.
> 
> A pings the global address of B.
> 
> What happens:
> 1) Address resolution from A to B. B creates a neighbor cache entry for A's address in STALE state. Since B sends Neighbor Advertisement back to A, the entry moves to DELAY and the delay_first_probe_time timer (5s) is started.
> 
> 2) After successful resolution, echo request / reply are exchanged.
> 
> 3) After delay_first_probe_time at B expires, B transmits a unicast Neighbor Solicitation to A's global address (reachability check). 
> 
> All good so far.
> 
> However, although the destination address of the NS has global scope, B uses its link-local address as source.
> 
> I don't think this is correct. According to the source address selection rules in RFC3484, chapter 5, Rule 2 should match and B's global interface address should be used as source.

Plain RFC3484 cannot be used to select source address for NS, as we
must be sure to select an IPv6 address belonging to the interface and
RFC3484 does not gurantee that (Rule 2 would filter out link-local address
in case of global scope while only Rule 5 later would prefer to select
an address belonging to the interface). It would be possible to try RFC3484
source selection, check if the address belongs to the interface and fallback
to LL address in case it does not. I'll test if it improves things.

> In this simple example, it leads to a sequence of further reachability checks for the link-local addresses of A and B. I don't think these are necessary and they could be avoided if B had used its global interface address as source in the first NS.
> 
> Observed under kernel version 3.11.
> 
> Is this a bug or do I miss something?

Always using link-local address in this scenario is in my opinion totally
valid but maybe not the best choice.

Greetings,

  Hannes

Aw: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Simon Schneider]

Hi Hannes,
thanks, checking that would be good.

Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.

The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.

best regards, Simon


> Gesendet: Donnerstag, 06. März 2014 um 08:02 Uhr
> Von: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> An: "Simon Schneider" <simon-schneider@gmx.net>
> Cc: netdev@vger.kernel.org
> Betreff: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
>
> Hi Simon!
> 
> On Wed, Mar 05, 2014 at 03:00:29PM +0100, Simon Schneider wrote:
> > I noticed something I don't quite understand in a very basic scenario.
> > 
> > Two machines connected to each other, say A and B.
> > 
> > Both have their automatically configured link-local IPv6 addresses on the interface, plus one global IPv6 interface address.
> > 
> > A pings the global address of B.
> > 
> > What happens:
> > 1) Address resolution from A to B. B creates a neighbor cache entry for A's address in STALE state. Since B sends Neighbor Advertisement back to A, the entry moves to DELAY and the delay_first_probe_time timer (5s) is started.
> > 
> > 2) After successful resolution, echo request / reply are exchanged.
> > 
> > 3) After delay_first_probe_time at B expires, B transmits a unicast Neighbor Solicitation to A's global address (reachability check). 
> > 
> > All good so far.
> > 
> > However, although the destination address of the NS has global scope, B uses its link-local address as source.
> > 
> > I don't think this is correct. According to the source address selection rules in RFC3484, chapter 5, Rule 2 should match and B's global interface address should be used as source.
> 
> Plain RFC3484 cannot be used to select source address for NS, as we
> must be sure to select an IPv6 address belonging to the interface and
> RFC3484 does not gurantee that (Rule 2 would filter out link-local address
> in case of global scope while only Rule 5 later would prefer to select
> an address belonging to the interface). It would be possible to try RFC3484
> source selection, check if the address belongs to the interface and fallback
> to LL address in case it does not. I'll test if it improves things.
> 
> > In this simple example, it leads to a sequence of further reachability checks for the link-local addresses of A and B. I don't think these are necessary and they could be avoided if B had used its global interface address as source in the first NS.
> > 
> > Observed under kernel version 3.11.
> > 
> > Is this a bug or do I miss something?
> 
> Always using link-local address in this scenario is in my opinion totally
> valid but maybe not the best choice.
> 
> Greetings,
> 
>   Hannes
> 
>

Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Hannes Frederic Sowa]

Hi Simon!

On Thu, Mar 06, 2014 at 10:18:23AM +0100, Simon Schneider wrote:
> thanks, checking that would be good.
> 
> Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.
> 
> The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.

Yep, that's the case. IMHO undefined behaviour so it is ok but could
be improved.

This would be the patch, should improve your initial observation and would
also "fix" the situation you noted above. Could you give it a test drive?

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 09a22f4..43c66f6 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -553,7 +553,17 @@ void ndisc_send_ns(struct net_device *dev, struct neighbour *neigh,
 	struct nd_msg *msg;
 
 	if (saddr == NULL) {
-		if (ipv6_get_lladdr(dev, &addr_buf,
+		if (!ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
+				       inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
+				       &addr_buf) &&
+		    ipv6_chk_addr(dev_net(dev), &addr_buf, dev, 1)) {
+			struct inet6_ifaddr *ifp = ipv6_get_ifaddr(dev_net(dev), &addr_buf, dev, 1);
+			if (ifp && !(ifp->flags & IFA_F_OPTIMISTIC))
+				saddr = &addr_buf;
+			in6_ifa_put(ifp);
+		}
+
+		if (!saddr && ipv6_get_lladdr(dev, &addr_buf,
 				   (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
 			return;
 		saddr = &addr_buf;


Thanks,

  Hannes

Aw: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Simon Schneider]

Hi Hannes,
thanks a lot.

We'll integrate and test the patch.

best regards,Simon


> Gesendet: Montag, 10. März 2014 um 03:44 Uhr
> Von: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> An: "Simon Schneider" <simon-schneider@gmx.net>
> Cc: netdev@vger.kernel.org
> Betreff: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
>
> Hi Simon!
> 
> On Thu, Mar 06, 2014 at 10:18:23AM +0100, Simon Schneider wrote:
> > thanks, checking that would be good.
> > 
> > Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.
> > 
> > The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.
> 
> Yep, that's the case. IMHO undefined behaviour so it is ok but could
> be improved.
> 
> This would be the patch, should improve your initial observation and would
> also "fix" the situation you noted above. Could you give it a test drive?
> 
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 09a22f4..43c66f6 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -553,7 +553,17 @@ void ndisc_send_ns(struct net_device *dev, struct neighbour *neigh,
>  	struct nd_msg *msg;
>  
>  	if (saddr == NULL) {
> -		if (ipv6_get_lladdr(dev, &addr_buf,
> +		if (!ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> +				       inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
> +				       &addr_buf) &&
> +		    ipv6_chk_addr(dev_net(dev), &addr_buf, dev, 1)) {
> +			struct inet6_ifaddr *ifp = ipv6_get_ifaddr(dev_net(dev), &addr_buf, dev, 1);
> +			if (ifp && !(ifp->flags & IFA_F_OPTIMISTIC))
> +				saddr = &addr_buf;
> +			in6_ifa_put(ifp);
> +		}
> +
> +		if (!saddr && ipv6_get_lladdr(dev, &addr_buf,
>  				   (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
>  			return;
>  		saddr = &addr_buf;
> 
> 
> Thanks,
> 
>   Hannes
> 
>

Re: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Hannes Frederic Sowa]

Hi Simon,

On Tue, Mar 11, 2014 at 01:15:17PM +0100, Simon Schneider wrote:
> Hi Hannes,
> thanks a lot.
> 
> We'll integrate and test the patch.

Did the patch improve the situation for you? I wonder because I would like to
submit it for net-next then.

Thanks,

  Hannes

> > Gesendet: Montag, 10. März 2014 um 03:44 Uhr
> > Von: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> > An: "Simon Schneider" <simon-schneider@gmx.net>
> > Cc: netdev@vger.kernel.org
> > Betreff: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
> >
> > Hi Simon!
> > 
> > On Thu, Mar 06, 2014 at 10:18:23AM +0100, Simon Schneider wrote:
> > > thanks, checking that would be good.
> > > 
> > > Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.
> > > 
> > > The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.
> > 
> > Yep, that's the case. IMHO undefined behaviour so it is ok but could
> > be improved.
> > 
> > This would be the patch, should improve your initial observation and would
> > also "fix" the situation you noted above. Could you give it a test drive?
> > 
> > diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> > index 09a22f4..43c66f6 100644
> > --- a/net/ipv6/ndisc.c
> > +++ b/net/ipv6/ndisc.c
> > @@ -553,7 +553,17 @@ void ndisc_send_ns(struct net_device *dev, struct neighbour *neigh,
> >  	struct nd_msg *msg;
> >  
> >  	if (saddr == NULL) {
> > -		if (ipv6_get_lladdr(dev, &addr_buf,
> > +		if (!ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> > +				       inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
> > +				       &addr_buf) &&
> > +		    ipv6_chk_addr(dev_net(dev), &addr_buf, dev, 1)) {
> > +			struct inet6_ifaddr *ifp = ipv6_get_ifaddr(dev_net(dev), &addr_buf, dev, 1);
> > +			if (ifp && !(ifp->flags & IFA_F_OPTIMISTIC))
> > +				saddr = &addr_buf;
> > +			in6_ifa_put(ifp);
> > +		}
> > +
> > +		if (!saddr && ipv6_get_lladdr(dev, &addr_buf,
> >  				   (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
> >  			return;
> >  		saddr = &addr_buf;
> > 
> > 
> > Thanks,
> > 
> >   Hannes
> > 
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
gruss,

  Hannes

Aw: Re: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

[Simon Schneider]

Hello Hannes,
sorry, no news yet.

Will update you once we have been able to test.

best regards, Simon

> Gesendet: Dienstag, 25. März 2014 um 21:13 Uhr
> Von: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> An: "Simon Schneider" <simon-schneider@gmx.net>
> Cc: netdev@vger.kernel.org
> Betreff: Re: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
>
> Hi Simon,
> 
> On Tue, Mar 11, 2014 at 01:15:17PM +0100, Simon Schneider wrote:
> > Hi Hannes,
> > thanks a lot.
> > 
> > We'll integrate and test the patch.
> 
> Did the patch improve the situation for you? I wonder because I would like to
> submit it for net-next then.
> 
> Thanks,
> 
>   Hannes
> 
> > > Gesendet: Montag, 10. März 2014 um 03:44 Uhr
> > > Von: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> > > An: "Simon Schneider" <simon-schneider@gmx.net>
> > > Cc: netdev@vger.kernel.org
> > > Betreff: Re: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
> > >
> > > Hi Simon!
> > > 
> > > On Thu, Mar 06, 2014 at 10:18:23AM +0100, Simon Schneider wrote:
> > > > thanks, checking that would be good.
> > > > 
> > > > Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.
> > > > 
> > > > The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.
> > > 
> > > Yep, that's the case. IMHO undefined behaviour so it is ok but could
> > > be improved.
> > > 
> > > This would be the patch, should improve your initial observation and would
> > > also "fix" the situation you noted above. Could you give it a test drive?
> > > 
> > > diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> > > index 09a22f4..43c66f6 100644
> > > --- a/net/ipv6/ndisc.c
> > > +++ b/net/ipv6/ndisc.c
> > > @@ -553,7 +553,17 @@ void ndisc_send_ns(struct net_device *dev, struct neighbour *neigh,
> > >  	struct nd_msg *msg;
> > >  
> > >  	if (saddr == NULL) {
> > > -		if (ipv6_get_lladdr(dev, &addr_buf,
> > > +		if (!ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> > > +				       inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
> > > +				       &addr_buf) &&
> > > +		    ipv6_chk_addr(dev_net(dev), &addr_buf, dev, 1)) {
> > > +			struct inet6_ifaddr *ifp = ipv6_get_ifaddr(dev_net(dev), &addr_buf, dev, 1);
> > > +			if (ifp && !(ifp->flags & IFA_F_OPTIMISTIC))
> > > +				saddr = &addr_buf;
> > > +			in6_ifa_put(ifp);
> > > +		}
> > > +
> > > +		if (!saddr && ipv6_get_lladdr(dev, &addr_buf,
> > >  				   (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
> > >  			return;
> > >  		saddr = &addr_buf;
> > > 
> > > 
> > > Thanks,
> > > 
> > >   Hannes
> > > 
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> -- 
> gruss,
> 
>   Hannes
> 
>