ipv6: default route for link local address is not added while assigning a address
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · Hannes Frederic Sowa
Quoted 10 lines · Nicolas Dichtel
CC netdevQuoted 7 lines · sohny thomas
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.Quoted 6 lines
I would say that removing the link local route but not the link local address
is a configuration problem.
If you remove a connected route but not the associated address, you will have
the same problem.
Quoted 5 lines
We have some user accessible routes that are essential for IPv6 stack to work at all. So I don't know if I can agree with that.
Maybe flush is a bit too aggressive?
Hi ,
Thank you for the inputs.
In the test for ipv6 default address selection , we are testing the rule 2 as specified in RFC 6724
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:
Check 04:
Destination: ff08::2(OS)
Candidate Source Addresses: fec0::1(SS) or LLA(LS)
Result: fec0::1(SS)
Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(ff08::2), yes, prefer fec0::1
Now in the test its flushing all the routes and adding an address , which in causes to add route into the routing table including the link local routes.
Earlier in 2.6.32 it used to work fine now due to the above mentioned check-in this is not happening
Of course we can still just delete a route and add , but even if we delete the link local route, IMHO i think it should update the LLA route when the interface is next added an address or bought up which ever is the case.
Regards,
Sohny
Hi All,
Any updates on my reply, Any more info is required. Can this be pulled into the kernel tree?
Thanks & Regards,
Sohny
Quoted 62 lines · sohny thomas
Quoted 18 lines · Hannes Frederic Sowa
Quoted 11 lines · Nicolas Dichtel
CC netdevQuoted 8 lines · sohny thomas
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.Quoted 6 lines
I would say that removing the link local route but not the link local address
is a configuration problem.
If you remove a connected route but not the associated address, you will have
the same problem.Quoted 5 lines
We have some user accessible routes that are essential for IPv6 stack to work at all. So I don't know if I can agree with that.
Maybe flush is a bit too aggressive?
Hi ,
Thank you for the inputs.
In the test for ipv6 default address selection , we are testing the rule 2 as specified in RFC 6724
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:
Check 04: Destination: ff08::2(OS) Candidate Source Addresses: fec0::1(SS) or LLA(LS) Result: fec0::1(SS) Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(ff08::2), yes,prefer fec0::1
Now in the test its flushing all the routes and adding an address , which in causes to add route into the routing table including the link local routes.
Earlier in 2.6.32 it used to work fine now due to the above mentioned check-in this is not happeningOf course we can still just delete a route and add , but even if we delete the link local route, IMHO i think it should update the LLA route when the interface is next added an address or bought up which ever is the case.
Regards,
Sohny
Hi!
Quoted 2 lines · sohny thomas
Any updates on my reply, Any more info is required. Can this be pulled into the kernel tree?
Your patch was posted to the wrong mailing list. Please repost to [email protected] so <http://patchwork.ozlabs.org/project/netdev/list/>
picks it up.
Thanks,
Hannes