netdev - Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

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]

Message-ID: <20130318185808.GB2740@order.stressinduktion.org>
Date:	Mon, 18 Mar 2013 19:58:08 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	Dan Williams <dcbw@...hat.com>,
	Sylvain Munaut <s.munaut@...tever-company.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Who/What is supposed to remove IPv6 address from interface when moving from one network to another ?

On Mon, Mar 18, 2013 at 11:39:02AM -0700, Lorenzo Colitti wrote:
> On Mon, Mar 18, 2013 at 11:34 AM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
> >> Actually, it *does* trigger events on carrier change: it creates the
> >> addresses when you connect. It just doesn't delete them when you
> >> disconnect. So you can get addresses without a userspace daemon, but
> >> you can never delete them without a userspace daemon.
> >
> > Not directly related, but I wonder if we should treat the change of the
> > mac address as a carrier change in ipv6 to create a new ll address. I
> > did not find any satisfying answer yet.
> 
> Yes, we should - because if we're attaching to a new link, there might
> be someone with a duplicate IPv6 address on it, so we'd need to
> perform DAD.

I think there is a misunderstanding:

I was thinking just about the case where we change the mac address of
some interface without changing anything else (not changing link status):

# ip l a type dummy
# ip l s up dev dummy0
# ip l l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
|	    link/ether ca:eb:dd:14:ad:15 brd ff:ff:ff:ff:ff:ff
# ip -6 a l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 
|	    inet6 fe80::c8eb:ddff:fe14:ad15/64 scope link 
|	       valid_lft forever preferred_lft forever
# ip l s a ca:eb:dd:14:ad:16 dev dummy0
# ip l l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
|	    link/ether ca:eb:dd:14:ad:16 brd ff:ff:ff:ff:ff:ff
# ip -6 a l dev dummy0
|	14: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 
|	    inet6 fe80::c8eb:ddff:fe14:ad15/64 scope link 
|	       valid_lft forever preferred_lft forever

Currently we don't generate any new ll address. I wondered if this is
correct.  This e.g. happens if creating bridges with libvirt. It could
also be just a acceptable circumstance, I currently don't know. If people
depend on the mapping from mac address to ipv6 ll address perhaps this
is something that should be addressed.

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