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

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 <redacted>

-----

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;
  }

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 <redacted>

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.

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 :

quoted

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 <redacted>

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

On Wednesday 29 January 2014 04:08 PM, Nicolas Dichtel wrote:

Le 29/01/2014 07:41, Sohny Thomas a écrit :

quoted

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 <redacted>

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

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

Le 03/02/2014 08:19, Sohny Thomas a écrit :

quoted

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.

quoted

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

Hello!

On Mon, Feb 03, 2014 at 04:23:00PM +0100, Nicolas Dichtel wrote:

Le 03/02/2014 08:19, Sohny Thomas a écrit :

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

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

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:

quoted

Le 03/02/2014 08:19, Sohny Thomas a écrit :

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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

On Monday 03 February 2014 09:56 PM, Nicolas Dichtel wrote:

quoted

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.