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

PATCH In review Sohny Thomas 4 participants 9 messages Jan 29, 2014 – Feb 4, 2014

Subsystems (3)

Networking Network drivers IPv4/IPv6

lore

Share & tools

lore

Sohny Thomas

author

2014-01-29 06:41 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

-----

net/ipv6/addrconf.c +13 -1

index f62c72b..a8a4df9 100644
@@ -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;
 }

Nicolas Dichtel

2014-01-29 10:38 UTC #1 lore raw

Quoted 12 lines · 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

Quoted 6 lines

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 <[email protected]>

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.

Hannes Frederic Sowa

2014-01-30 23:29 UTC #2 lore raw

Sorry for replying so late...

Quoted 21 lines · Nicolas Dichtel

Quoted 20 lines · 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

Quoted 7 lines

Quoted 1 line
Signed-off-by Sohny THomas <[email protected]>
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

Sohny Thomas

author

2014-02-03 07:02 UTC #8 lore raw

In reply to Nicolas Dichtel

Quoted 22 lines · Nicolas Dichtel

Quoted 21 lines · 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

Quoted 3 lines

Quoted 1 line
Signed-off-by Sohny THomas <[email protected]>
Your email client has corrupted the patch, it cannot be applied. Please read Documentation/email-clients.txt

Sorry about that. Will resend again

Quoted 7 lines

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

Quoted 3 lines

Sohny Thomas

author

2014-02-03 07:19 UTC #3 lore raw

In reply to Hannes Frederic Sowa

Quoted 6 lines

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

Quoted 7 lines

Greetings,
Hannes

Nicolas Dichtel

2014-02-03 15:23 UTC #4 lore raw

Quoted 4 lines · Sohny Thomas

Quoted 4 lines
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 20 lines

Quoted 2 lines
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

Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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

Hannes Frederic Sowa

2014-02-03 16:08 UTC #5 lore raw

Hello!

Quoted 5 lines · Nicolas Dichtel

Quoted 4 lines · Sohny Thomas
Quoted 4 lines
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

Quoted 7 lines

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 25 lines

Quoted 25 lines
Quoted 4 lines
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

Quoted 6 lines

Quoted 4 lines
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 4 lines

Quoted 1 line
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 5 lines

Quoted 3 lines
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

Nicolas Dichtel

2014-02-03 16:26 UTC #6 lore raw

Quoted 16 lines · Hannes Frederic Sowa

Hello!
Quoted 5 lines · Nicolas Dichtel
Quoted 4 lines · Sohny Thomas
Quoted 4 lines
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
Quoted 7 lines
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 2 lines

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 59 lines

Quoted 26 lines
Quoted 26 lines
Quoted 5 lines
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
Quoted 6 lines
Quoted 4 lines
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 4 lines
Quoted 1 line
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 5 lines
Quoted 3 lines
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:

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

sohny thomas

2014-02-04 18:37 UTC #7 lore raw

Quoted 5 lines · Nicolas Dichtel

Quoted 4 lines
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

Quoted 7 lines

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.