On Friday 10 January 2014 10:46 PM, Hannes Frederic Sowa wrote:
On Fri, Jan 10, 2014 at 05:33:08PM +0100, Nicolas Dichtel wrote:
quoted
CC: netdev
Le 10/01/2014 13:20, sohny thomas a écrit :
quoted
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 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.
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
On Monday 13 January 2014 02:19 PM, sohny thomas wrote:
On Friday 10 January 2014 10:46 PM, Hannes Frederic Sowa wrote:
quoted
On Fri, Jan 10, 2014 at 05:33:08PM +0100, Nicolas Dichtel wrote:
quoted
CC: netdev
Le 10/01/2014 13:20, sohny thomas a écrit :
quoted
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 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.
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!
On Fri, Jan 17, 2014 at 02:04:26PM +0530, sohny thomas wrote:
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
netdev@vger.kernel.org so <http://patchwork.ozlabs.org/project/netdev/list/>
picks it up.
Thanks,
Hannes