cannot delete IPv6 default gateway

Question

The commands below should be pretty self-explanatory. Please note that the route for which i get failure is obtained by RA and has very less expiry ( e Flag in UDAe).

 @vm:~$ ip -6 route 
 2001:4860:4001:800::1002 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:800::1003 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:800::1005 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:803::100e via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 fd00:ffff:ffff:fff1::/64 dev eth1  proto kernel  metric 256  expires 2592300sec
 fe80::/64 dev eth1  proto kernel  metric 256
 default via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1
 default via fe80::20c:29ff:fe87:f9e7 dev eth1  proto kernel  metric 1024  expires 1776sec
 @vm:~$
 @vm:~$
 @vm:~$
 @vm:~$ sudo route -6 delete default gw fe80::20c:29ff:fe87:f9e7
 @vm:~$ ip -6 route
 2001:4860:4001:800::1002 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:800::1003 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:800::1005 via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 2001:4860:4001:803::100e via fe80::20c:29ff:fe87:f9e7 dev eth1  proto static  metric 1024
 fd00:ffff:ffff:fff1::/64 dev eth1  proto kernel  metric 256  expires 2592279sec
 fe80::/64 dev eth1  proto kernel  metric 256
 default via fe80::20c:29ff:fe87:f9e7 dev eth1  proto kernel  metric 1024  expires 1755sec
 @vm:~$
 @vm:~$
 @vm:~$ sudo route -6 delete ::/0 gw fe80::20c:29ff:fe87:f9e7 dev eth1
 SIOCDELRT: No such process
 @vm:~$
 @vm:~$
 @vm:~$ route -n6
 Kernel IPv6 routing table
 Destination                    Next Hop                   Flag Met Ref Use If
 2001:4860:4001:800::1002/128   fe80::20c:29ff:fe87:f9e7   UG   1024 0     0 eth1
 2001:4860:4001:800::1003/128   fe80::20c:29ff:fe87:f9e7   UG   1024 0     0 eth1
 2001:4860:4001:800::1005/128   fe80::20c:29ff:fe87:f9e7   UG   1024 0     0 eth1
 2001:4860:4001:803::100e/128   fe80::20c:29ff:fe87:f9e7   UG   1024 0     0 eth1
 fd00:ffff:ffff:fff1::/64       ::                         UAe  256 0     0 eth1
 fe80::/64                      ::                         U    256 0     0 eth1
 ::/0                           fe80::20c:29ff:fe87:f9e7   UGDAe 1024 0     0 eth1
 ::/0                           ::                         !n   -1  1   349 lo
 ::1/128                        ::                         Un   0   1     3 lo
 fd00:ffff:ffff:fff1:a00:27ff:fe7f:7245/128 ::                         Un   0   1     0 lo
 fd00:ffff:ffff:fff1:fce8:ce07:b9ea:389f/128 ::                         Un   0   1     0 lo
 fe80::a00:27ff:fe7f:7245/128   ::                         Un   0   1     0 lo
 ff00::/8                       ::                         U    256 0     0 eth1
 ::/0                           ::                         !n   -1  1   349 lo
 @vm:~$

UPDATE: Another question is whats the use of link local address as the default route?

Solution

The route you are trying to delete looks like a route that was automatically added by the kernel in response to a router advertisement (RA). Be aware that if you delete it then it will probably come back on its own within 5 minutes when the router sends out another advertisement, as it will normally do periodically. If you don't want your machine to listen to router advertisements then what you probably want is to do this:

echo 0 >/proc/sys/net/ipv6/conf/eth1/accept_ra

If you do that, you don't even have to bother removing it manually: it will disappear within a few minutes when it expires naturally.

Nevertheless, if you want to, you can remove it manually. It's just that it looks like the route command isn't able to do it. Use the ip command instead:

ip route del ::/0 via fe80::20c:29ff:fe87:f9e7 dev eth1

In fact, if you are working only under Linux then I recommend that you always use the ip command as a modern replacement for all of the following commands: route, ifconfig, and netstat. Its syntax is much easier to handle that any of those other commands, it unifies them all together, and there are functions (like ip rule and ip tunnel) that are only available through it.

Comments

[Reza Zamani]

@MartyFried No... if that were true then it would be impossible to not have a default route!

[Deepak Verma]

@Celada: Well, yes, but I didn't know that was undesirable; usually, that's the whole purpose of a default, so that you don't always have to specify which one to use. Why else would there be a default? If not, there should be a way to turn off the default setting, so nothing is the default.

[Reza Zamani]

@MartyFried I'm sorry, I don't under stand your reply. There is no "default setting", and a default route doesn't have anything to do with "specify[ing] which [route] to use". A default route is simply a route with prefix length /0 so that it covers every possible destination. As the least specific route, every other route in the routing table overrides it.

[Deepak Verma]

@Celada: Well, I didn't understand your reply, either, so that makes us even. As I said, I didn't know about routing tables (which is why it was a comment, not an answer). I commented in case it was helpful, which it wasn't. Neither was your reply.

[PnotNP]

Whats the use of this route ? And yes I am aware of ip, slowly drifting towards it. too many years with old utilties :)

[Reza Zamani]

It's a default route... like every default route it tells the system where to send packets to reach destinations on the entire Internet (that are not covered by any other more specific route). Am I misunderstanding your question?

[PnotNP]

Next Hop for this default route is link local address fe80 and that means that router is not going to forward it. So how will i get global addresses routed outside my network?

[Sander Steffann]

Link-local addresses are often used for determining the next hop. Next hop IP addresses are only used to find the layer-2 (usually ethernet these days) address where to send the packet to, and link local addresses are fine for that.

[PnotNP]

@SanderSteffann you are right, for some reason i compared fe80::/64 address with 169.254.0.0 address in IPV4, while actually link-local actually compares to 172.16.0.0/12 or 192.168.0.0 IPV4 addresses

[Reza Zamani]

@NulledPointer fe80::/10 is indeed comparable to 169.254.0.0/16. @SanderSteffann is correct in saying that if a route's next hop is in this block it doesn't prevent the route from being used to reach off-link destinations. RFC 1918 blocks like 172.16.0.0/12 and 192.168.0.0/16 are not related to this topic and are in fact akin to IPv6 ULAs which are in the range fc00::/7.

[PnotNP]

@Celada +1 for Link. So in IPV4 I dont know of the case where the network device chooses 169.254.0.0/16 psueodrandomly and starts communicating with immediate network router, what i have seen is that device is assigned 192.168.0.10 (say) IPv4 address and router is usually 192.168.0.1 (something like that), but it seems pretty common in IPV6?

[Reza Zamani]

In IPv4 link-local addresses were an afterthought, so they're not implemented universally, and, furthermore, you only get one of them when as a last resort (e.g. no static address configured and DHCP fails). In IPv6 link-local addresses were part of the protocol from the start and they are always present on every interface, even if the interface ALSO has other non-link-local addresses. That's why you see so much more use of link locals in v6. BTW: You'll see 169.254.0.0/16 automatically assigned in at least modern MacOS and Linux systems with avahi-autoipd running, so they do get some use.