lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 26 Oct 2010 11:17:27 -0700
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	brian.haley@...com, shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
 losing link

On Tue, Oct 26, 2010 at 10:47 AM, David Miller <davem@...emloft.net> wrote:
> Why would you do this when there are link layer indications that
> we are attached to a different network?

Thinking about this some more, I don't think it's necessarily better.

The only thing that really knows the state of the network is the
network itself. IPv6 provides a mechanism that hosts can use to find
out what they should be doing: send an RA and process the resulting
RS. I think this is much cleaner than keeping local state, performing
layering violations (looking at MAC addresses) and getting information
from other systems in order to second-guess information that the host
can get simply by sending another RS.

If you think about it, this is what we do today in IPv4: when link is
lost, networkmanager *deletes IP addresses and routes* from the
interfaces, and then starts DHCP again when link comes back. That is,
asks the network for configuration information.

This works pretty well. Why not do the same for IPv6? The only
difference in IPv6 is that the kernel is the one doing
autoconfiguration, so it's the kernel that should be doing the asking.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ