* IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets?
@ 2010-04-21 0:52 Sam Cannell
2010-04-21 1:03 ` Sam Cannell
0 siblings, 1 reply; 2+ messages in thread
From: Sam Cannell @ 2010-04-21 0:52 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]
Hi,
I've been having some trouble with ip6 duplicate address detection in a
Linux VM (under XVM on OpenSolaris). It seems that the ethernet bridge
in XVM sends a host's own multicast packets back to it, which the
duplicate address detection code in linux decide that another host on
the network is using the same address.
For instance, running:
router4:~ # ip addr add fe80::216:36ff:fe4e:461c/64 dev eth0
I get the following output in tcpdump:
router4:~ # tcpdump -nevpi eth0 ip6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
12:33:03.755897 00:16:36:4e:46:1c > 33:33:00:00:00:16, ethertype IPv6
(0x86dd), length 90: (hlim 1, next-header Options (0) payload length:
36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6,
multicast listener report v2, length 28, 1 group record(s) [gaddr
ff02::1:ff4e:461c to_ex, 0 source(s)]
12:33:04.551772 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
12:33:04.551998 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
And dmesg says:
router4:~ # dmesg
[ 371.024287] eth0: IPv6 duplicate address fe80::216:36ff:fe4e:461c
detected!
And the address sits in 'tentative' mode:
router4:~ # ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 00:16:36:4e:46:1c brd ff:ff:ff:ff:ff:ff
inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
inet6 fe80::216:36ff:fe4e:461c/64 scope link tentative flags 08
valid_lft forever preferred_lft forever
This happens for link-local and global scope address, both when they try
to auto-configure and when set by hand:
[ 463.500328] eth0: IPv6 duplicate address
2404:130:0:1000:216:36ff:fe4e:461c detected!
[ 732.428312] eth0: IPv6 duplicate address
2404:130:0:1000:216:36ff:fe4e:461c detected!
[ 883.812328] eth0: IPv6 duplicate address 2404:130::3:2:1 detected!
I'd happily put this down to a failing in XVM, however the stateless
autoconfiguration RFC (4862) states that the stack shouldn't decide an
address is duplicate based on receipt of a neighbor solicitation message
that it sent itself:
5.4.3. Receiving Neighbor Solicitation Messages
[...]
If the source address of the Neighbor Solicitation is the unspecified
address, the solicitation is from a node performing Duplicate Address
Detection. If the solicitation is from another node, the tentative
address is a duplicate and should not be used (by either node). If
the solicitation is from the node itself (because the node loops back
multicast packets), the solicitation does not indicate the presence
of a duplicate address.
Assuming my understanding of the RFC is correct, this suggests to me that duplicate address detection in Linux is being a little too hasty to mark the address as invalid. Thoughts?
Thanks,
Sam Cannell
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets?
2010-04-21 0:52 IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets? Sam Cannell
@ 2010-04-21 1:03 ` Sam Cannell
0 siblings, 0 replies; 2+ messages in thread
From: Sam Cannell @ 2010-04-21 1:03 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]
Sorry, just realised I forgot to note that this behaviour occurs in
2.6.33.
On Wed, 2010-04-21 at 12:52 +1200, Sam Cannell wrote:
> Hi,
>
> I've been having some trouble with ip6 duplicate address detection in a
> Linux VM (under XVM on OpenSolaris). It seems that the ethernet bridge
> in XVM sends a host's own multicast packets back to it, which the
> duplicate address detection code in linux decide that another host on
> the network is using the same address.
>
> For instance, running:
>
> router4:~ # ip addr add fe80::216:36ff:fe4e:461c/64 dev eth0
>
>
> I get the following output in tcpdump:
>
> router4:~ # tcpdump -nevpi eth0 ip6
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 12:33:03.755897 00:16:36:4e:46:1c > 33:33:00:00:00:16, ethertype IPv6
> (0x86dd), length 90: (hlim 1, next-header Options (0) payload length:
> 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6,
> multicast listener report v2, length 28, 1 group record(s) [gaddr
> ff02::1:ff4e:461c to_ex, 0 source(s)]
> 12:33:04.551772 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
> (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
> 24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
> length 24, who has fe80::216:36ff:fe4e:461c
> 12:33:04.551998 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
> (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
> 24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
> length 24, who has fe80::216:36ff:fe4e:461c
> ^C
> 3 packets captured
> 3 packets received by filter
> 0 packets dropped by kernel
>
>
> And dmesg says:
>
> router4:~ # dmesg
> [ 371.024287] eth0: IPv6 duplicate address fe80::216:36ff:fe4e:461c
> detected!
>
>
> And the address sits in 'tentative' mode:
>
> router4:~ # ip addr show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 00:16:36:4e:46:1c brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
> inet6 fe80::216:36ff:fe4e:461c/64 scope link tentative flags 08
> valid_lft forever preferred_lft forever
>
>
> This happens for link-local and global scope address, both when they try
> to auto-configure and when set by hand:
>
> [ 463.500328] eth0: IPv6 duplicate address
> 2404:130:0:1000:216:36ff:fe4e:461c detected!
> [ 732.428312] eth0: IPv6 duplicate address
> 2404:130:0:1000:216:36ff:fe4e:461c detected!
> [ 883.812328] eth0: IPv6 duplicate address 2404:130::3:2:1 detected!
>
>
> I'd happily put this down to a failing in XVM, however the stateless
> autoconfiguration RFC (4862) states that the stack shouldn't decide an
> address is duplicate based on receipt of a neighbor solicitation message
> that it sent itself:
>
> 5.4.3. Receiving Neighbor Solicitation Messages
> [...]
> If the source address of the Neighbor Solicitation is the unspecified
> address, the solicitation is from a node performing Duplicate Address
> Detection. If the solicitation is from another node, the tentative
> address is a duplicate and should not be used (by either node). If
> the solicitation is from the node itself (because the node loops back
> multicast packets), the solicitation does not indicate the presence
> of a duplicate address.
>
>
> Assuming my understanding of the RFC is correct, this suggests to me that duplicate address detection in Linux is being a little too hasty to mark the address as invalid. Thoughts?
>
>
> Thanks,
>
> Sam Cannell
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-04-21 1:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-21 0:52 IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets? Sam Cannell
2010-04-21 1:03 ` Sam Cannell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox