[PATCH] ipv6: default route for link local address is not added while assigning a address

[PATCH] ipv6: default route for link local address is not added while assigning a address

[Sohny Thomas]

Resending this on netdev mailing list:
Default route for link local address is configured automatically if 
NETWORKING_IPV6=yes is in ifcfg-eth*.
When the route table for the interface is flushed and a new address is 
added to the same device with out removing linklocal addr, default route 
for link local address has to added by default.

I have found the issue to be caused by this checkin

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd

According to this change :
He removes adding a link local route if any other address is added , 
applicable across all interfaces though there's mentioned only lo interface
So below patch fixes for other devices

Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>

-----

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f62c72b..a8a4df9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1763,6 +1763,16 @@ static int addrconf_ifid_infiniband(u8 *eui, 
struct net_device *dev)
         return 0;
  }

+static void addrconf_add_lroute(struct net_device *dev)
+{
+       struct in6_addr addr;
+
+       ipv6_addr_set(&addr,  htonl(0xFE800000), 0, 0, 0);
+       addrconf_prefix_route(&addr, 64, dev, 0, 0);
+}
+
+
+
  static int __ipv6_isatap_ifid(u8 *eui, __be32 addr)
  {
         if (addr == 0)
@@ -2010,8 +2020,10 @@ static struct inet6_dev *addrconf_add_dev(struct 
net_device *dev)
                 return ERR_PTR(-EACCES);

         /* Add default multicast route */
-       if (!(dev->flags & IFF_LOOPBACK))
+       if (!(dev->flags & IFF_LOOPBACK)){
                 addrconf_add_mroute(dev);
+               addrconf_add_lroute(dev);
+       }

         return idev;
  }

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Nicolas Dichtel]

Le 29/01/2014 07:41, Sohny Thomas a écrit :
> Resending this on netdev mailing list:
> Default route for link local address is configured automatically if
> NETWORKING_IPV6=yes is in ifcfg-eth*.
> When the route table for the interface is flushed and a new address is added to
> the same device with out removing linklocal addr, default route for link local
> address has to added by default.
>
> I have found the issue to be caused by this checkin
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
>
>
> According to this change :
> He removes adding a link local route if any other address is added , applicable
> across all interfaces though there's mentioned only lo interface
> So below patch fixes for other devices
>
> Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
Your email client has corrupted the patch, it cannot be applied.
Please read Documentation/email-clients.txt

About the patch, I still think that the flush is too agressive. Link local
routes are marked as 'proto kernel', removing them without the link local
address is wrong.

With this patch, you will add a link local route even if you don't have a link
local address.

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Hannes Frederic Sowa]

Sorry for replying so late...

On Wed, Jan 29, 2014 at 11:38:47AM +0100, Nicolas Dichtel wrote:
> Le 29/01/2014 07:41, Sohny Thomas a écrit :
> >Resending this on netdev mailing list:
> >Default route for link local address is configured automatically if
> >NETWORKING_IPV6=yes is in ifcfg-eth*.
> >When the route table for the interface is flushed and a new address is 
> >added to
> >the same device with out removing linklocal addr, default route for link 
> >local
> >address has to added by default.
> >
> >I have found the issue to be caused by this checkin
> >
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
> >
> >
> >According to this change :
> >He removes adding a link local route if any other address is added , 
> >applicable
> >across all interfaces though there's mentioned only lo interface
> >So below patch fixes for other devices
> >
> >Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
> Your email client has corrupted the patch, it cannot be applied.
> Please read Documentation/email-clients.txt
> 
> About the patch, I still think that the flush is too agressive. Link local
> routes are marked as 'proto kernel', removing them without the link local
> address is wrong.

Actually I am not so sure, there is no defined semantic of flush. I would
be ok with all three solutions: leave it as is, always add link-local
address (it does not matter if we don't have a link-local address on
that interface, as a global scoped one is just fine enough) or make flush not
remove the link-local address (but this seems a bit too special cased for me).

Greetings,

  Hannes

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Sohny Thomas]

On Wednesday 29 January 2014 04:08 PM, Nicolas Dichtel wrote:
> Le 29/01/2014 07:41, Sohny Thomas a écrit :
>> Resending this on netdev mailing list:
>> Default route for link local address is configured automatically if
>> NETWORKING_IPV6=yes is in ifcfg-eth*.
>> When the route table for the interface is flushed and a new address is
>> added to
>> the same device with out removing linklocal addr, default route for
>> link local
>> address has to added by default.
>>
>> I have found the issue to be caused by this checkin
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
>>
>>
>>
>> According to this change :
>> He removes adding a link local route if any other address is added ,
>> applicable
>> across all interfaces though there's mentioned only lo interface
>> So below patch fixes for other devices
>>
>> Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
> Your email client has corrupted the patch, it cannot be applied.
> Please read Documentation/email-clients.txt
Sorry about that. Will resend again
>
> About the patch, I still think that the flush is too agressive. Link local
> routes are marked as 'proto kernel', removing them without the link local
> address is wrong.
>
> With this patch, you will add a link local route even if you don't have
> a link local address.
I think it wouldn't hurt to have a Link local route for NDP  in case a 
the routes become unreachable

-Regards,
Sohny
>
>
>

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Sohny Thomas]

> Actually I am not so sure, there is no defined semantic of flush. I would
> be ok with all three solutions: leave it as is, always add link-local
> address (it does not matter if we don't have a link-local address on
> that interface, as a global scoped one is just fine enough) or make flush not
> remove the link-local address (but this seems a bit too special cased for me).

1) In case if we leave it as it is, there is rfc 6724 rule 2 to be 
considered ( previously rfc 3484)

Rule 2: Prefer appropriate scope.
    If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
    otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
    Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

Test:

    Destination: fe80::2(LS)
     Candidate Source Addresses: 3ffe::1(GS) or fec0::1(SS) or LLA(LS)
     Result: LLA(LS)
     Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(fe80::2),  no, 
prefer LLA
     Scope(LLA) < Scope(3ffe::1): If Scope(LLA) < Scope(fe80::2),  no, 
prefer LLA


Now the above test fails since the route itself is not present, and the 
test assumes that the route gets added since the LLA is not removed 
during the test

2) having a LLA always helps in NDP i think

3) making flush not remove link-local address will be chnaging 
functionality of ip flush command

Regards,
Sohny

>
> Greetings,
>
>    Hannes
>
>
>

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Nicolas Dichtel]

Le 03/02/2014 08:19, Sohny Thomas a écrit :
>
>> Actually I am not so sure, there is no defined semantic of flush. I would
>> be ok with all three solutions: leave it as is, always add link-local
>> address (it does not matter if we don't have a link-local address on
It matters. This address is required.
RFC 4291
Section 2.1:
    All interfaces are required to have at least one Link-Local unicast
    address (see Section 2.8 for additional required addresses).
Section 2.8:
       o Its required Link-Local address for each interface.

>> that interface, as a global scoped one is just fine enough) or make flush not
>> remove the link-local address (but this seems a bit too special cased for me).
>
> 1) In case if we leave it as it is, there is rfc 6724 rule 2 to be considered (
> previously rfc 3484)
>
> Rule 2: Prefer appropriate scope.
>     If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
>     otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
>     Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
>
> Test:
>
>     Destination: fe80::2(LS)
>      Candidate Source Addresses: 3ffe::1(GS) or fec0::1(SS) or LLA(LS)
>      Result: LLA(LS)
>      Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(fe80::2),  no, prefer LLA
>      Scope(LLA) < Scope(3ffe::1): If Scope(LLA) < Scope(fe80::2),  no, prefer LLA
>
>
> Now the above test fails since the route itself is not present, and the test
> assumes that the route gets added since the LLA is not removed during the test
In your scenario, the link local route has been removed manually, not by the
kernel. What is your network manager?

>
> 2) having a LLA always helps in NDP i think
A link-local Address yes, it's a MUST. But having only the link local route will
not help.

>
> 3) making flush not remove link-local address will be chnaging functionality of
> ip flush command
You can flush by specifying the prototype:
ip -6 route flush proto static


Regards,
Nicolas

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Hannes Frederic Sowa]

Hello!

On Mon, Feb 03, 2014 at 04:23:00PM +0100, Nicolas Dichtel wrote:
> Le 03/02/2014 08:19, Sohny Thomas a écrit :
> >
> >>Actually I am not so sure, there is no defined semantic of flush. I would
> >>be ok with all three solutions: leave it as is, always add link-local
> >>address (it does not matter if we don't have a link-local address on
> It matters. This address is required.
> RFC 4291
> Section 2.1:
>    All interfaces are required to have at least one Link-Local unicast
>    address (see Section 2.8 for additional required addresses).
> Section 2.8:
>       o Its required Link-Local address for each interface.

Yes, sure, it is required. But you also can manually delete the LL address and
we don't guard against that.

> >>that interface, as a global scoped one is just fine enough) or make flush 
> >>not
> >>remove the link-local address (but this seems a bit too special cased for 
> >>me).
> >
> >1) In case if we leave it as it is, there is rfc 6724 rule 2 to be 
> >considered (
> >previously rfc 3484)
> >
> >Rule 2: Prefer appropriate scope.
> >    If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
> >    otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
> >    Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
> >
> >Test:
> >
> >    Destination: fe80::2(LS)
> >     Candidate Source Addresses: 3ffe::1(GS) or fec0::1(SS) or LLA(LS)
> >     Result: LLA(LS)
> >     Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(fe80::2),  no, 
> >     prefer LLA
> >     Scope(LLA) < Scope(3ffe::1): If Scope(LLA) < Scope(fe80::2),  no, 
> >     prefer LLA
> >
> >
> >Now the above test fails since the route itself is not present, and the 
> >test
> >assumes that the route gets added since the LLA is not removed during the 
> >test
> In your scenario, the link local route has been removed manually, not by the
> kernel. What is your network manager?

The test scenario is outlined here:
<https://bugzilla.kernel.org/show_bug.cgi?id=68511>

Basically, the command in question is this one:

	[root@localhost ~]# ip -6 -statistics -statistics route flush dev eth0

which removes the fe80::/64 route.

> >2) having a LLA always helps in NDP i think
> A link-local Address yes, it's a MUST. But having only the link local route 
> will
> not help.

Agreed, the LL address should be available, too. I currently don't know
what will break if LL address is not available. I guess MLD won't work
properly and thus even basic connectivity won't work with some switches.

> >3) making flush not remove link-local address will be chnaging 
> >functionality of
> >ip flush command
> You can flush by specifying the prototype:
> ip -6 route flush proto static

So we have four possiblities now:

1) leave it as is

	seems still acceptable to me

2) add fe80::/64 route unconditionally if any address gets added

	Sohny's patch already looks good in doing so at first look.

3) add fe80::/64 route in case LL address gets added via inet6_rtm_newaddr

	would be ok, too. I tend towards this solution somehow by now.

4) make flush not remove the fe80::/64 address

	Least favourable to me. I guess this also woud need iproute change
	and seems most difficult to do.

Any opionions?

Greetings,

  Hannes

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[Nicolas Dichtel]

Le 03/02/2014 17:08, Hannes Frederic Sowa a écrit :
> Hello!
>
> On Mon, Feb 03, 2014 at 04:23:00PM +0100, Nicolas Dichtel wrote:
>> Le 03/02/2014 08:19, Sohny Thomas a écrit :
>>>
>>>> Actually I am not so sure, there is no defined semantic of flush. I would
>>>> be ok with all three solutions: leave it as is, always add link-local
>>>> address (it does not matter if we don't have a link-local address on
>> It matters. This address is required.
>> RFC 4291
>> Section 2.1:
>>     All interfaces are required to have at least one Link-Local unicast
>>     address (see Section 2.8 for additional required addresses).
>> Section 2.8:
>>        o Its required Link-Local address for each interface.
>
> Yes, sure, it is required. But you also can manually delete the LL address and
> we don't guard against that.
Sure. It's why I don't like this patch, it fix a user error.

>
>>>> that interface, as a global scoped one is just fine enough) or make flush
>>>> not
>>>> remove the link-local address (but this seems a bit too special cased for
>>>> me).
>>>
>>> 1) In case if we leave it as it is, there is rfc 6724 rule 2 to be
>>> considered (
>>> previously rfc 3484)
>>>
>>> Rule 2: Prefer appropriate scope.
>>>     If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
>>>     otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
>>>     Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
>>>
>>> Test:
>>>
>>>     Destination: fe80::2(LS)
>>>      Candidate Source Addresses: 3ffe::1(GS) or fec0::1(SS) or LLA(LS)
>>>      Result: LLA(LS)
>>>      Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(fe80::2),  no,
>>>      prefer LLA
>>>      Scope(LLA) < Scope(3ffe::1): If Scope(LLA) < Scope(fe80::2),  no,
>>>      prefer LLA
>>>
>>>
>>> Now the above test fails since the route itself is not present, and the
>>> test
>>> assumes that the route gets added since the LLA is not removed during the
>>> test
>> In your scenario, the link local route has been removed manually, not by the
>> kernel. What is your network manager?
>
> The test scenario is outlined here:
> <https://bugzilla.kernel.org/show_bug.cgi?id=68511>
>
> Basically, the command in question is this one:
>
> 	[root@localhost ~]# ip -6 -statistics -statistics route flush dev eth0
>
> which removes the fe80::/64 route.
>
>>> 2) having a LLA always helps in NDP i think
>> A link-local Address yes, it's a MUST. But having only the link local route
>> will
>> not help.
>
> Agreed, the LL address should be available, too. I currently don't know
> what will break if LL address is not available. I guess MLD won't work
> properly and thus even basic connectivity won't work with some switches.
>
>>> 3) making flush not remove link-local address will be chnaging
>>> functionality of
>>> ip flush command
>> You can flush by specifying the prototype:
>> ip -6 route flush proto static
>
> So we have four possiblities now:
>
> 1) leave it as is
>
> 	seems still acceptable to me
>
> 2) add fe80::/64 route unconditionally if any address gets added
>
> 	Sohny's patch already looks good in doing so at first look.
I don't like this solution, because it's a kernel patch to fix a configuration
problem.

>
> 3) add fe80::/64 route in case LL address gets added via inet6_rtm_newaddr
>
> 	would be ok, too. I tend towards this solution somehow by now.
This seems right also, but I'm not sure that this will fix Sohny's pb.

>
> 4) make flush not remove the fe80::/64 address
>
> 	Least favourable to me. I guess this also woud need iproute change
> 	and seems most difficult to do.
Why using this command 'ip -6 route flush proto static' isn't possible?
I think that we know what kind of route is added for these TAHI tests, hence
it's better to remove only routes added manually (or by a routing daemon if
it's the case).
Removing kernel routes may hide bugs: imagine the kernel adds a wrong route,
TAHI will not detect it.


Regards,
Nicolas

Re: [PATCH] ipv6: default route for link local address is not added while assigning a address

[sohny thomas]

On Monday 03 February 2014 09:56 PM, Nicolas Dichtel wrote:
>> 4) make flush not remove the fe80::/64 address
>>
>>     Least favourable to me. I guess this also woud need iproute change
>>     and seems most difficult to do.
> Why using this command 'ip -6 route flush proto static' isn't possible?
Ok I tried this and it works fine ( i.e, leaves out removing Link Local 
route), but I think this is a workaround to a problem that occurs if 
anyone actually deletes a Link local route

> I think that we know what kind of route is added for these TAHI tests,
> hence
> it's better to remove only routes added manually (or by a routing daemon if
> it's the case).
> Removing kernel routes may hide bugs: imagine the kernel adds a wrong
> route,
> TAHI will not detect it.