Broadband Tech > IPv6 > Question regarding uTorrent and link Local multicast?

Question regarding uTorrent and link Local multicast?

The tunnel might be down but what about the RA daemon?

Does your PC still think it has a global v6 address? Check ipconfig...

I've completely disabled IPv6 on the router, so running an ifconfig shows only the IPv4 interfaces and none of those have IPv6 bound to them. Also radvd is not running.

The PC only has a link local address

PS C:\> ipconfig /all
 
Windows IP Configuration
 
   Host Name . . . . . . . . . . . . : Enterprise
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
 
Ethernet adapter Local Area Connection:
 
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 00-1D-7D-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::6d26:e8e8:e078:3014%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.200(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, March 01, 2011 12:20:59 PM
   Lease Expires . . . . . . . . . . : Wednesday, March 02, 2011 12:20:58 PM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 234888573
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-F0-BF-63-00-1D-7D-xx-xx-xx
   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
PS C:\>
 
br0       Link encap:Ethernet  HWaddr E0:CB:4E:xx:xx:xx  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9209585 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7579369 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:834213116 (795.5 MiB)  TX bytes:350551202 (334.3 MiB)
 
eth0      Link encap:Ethernet  HWaddr E0:CB:4E:xx:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16771706 errors:1358 dropped:0 overruns:204 frame:204
          TX packets:16786811 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1723279578 (1.6 GiB)  TX bytes:1580314071 (1.4 GiB)
          Interrupt:4 Base address:0x1000 
 
eth1      Link encap:Ethernet  HWaddr E0:CB:4E:xx:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:786 errors:0 dropped:0 overruns:0 frame:1061692
          TX packets:5247 errors:509 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:109785 (107.2 KiB)  TX bytes:1037613 (1013.2 KiB)
          Interrupt:13 Base address:0x5000 
 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1374 (1.3 KiB)  TX bytes:1374 (1.3 KiB)
 
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:109.xxx.xxx.xxx  P-t-P:109.xxx.xxx.xxx Mask:255.255.255.255
          UP POINTOPOINT RUNNING MULTICAST  MTU:1460  Metric:1
          RX packets:5484735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5518046 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:121975543 (116.3 MiB)  TX bytes:17520223 (16.7 MiB)
 
vlan0     Link encap:Ethernet  HWaddr E0:CB:4E:xx:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9209109 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7578914 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:871020752 (830.6 MiB)  TX bytes:380533519 (362.9 MiB)
 
vlan1     Link encap:Ethernet  HWaddr E0:CB:4E:xx:xx:xx  
          inet addr:172.xxx.xxx.xxx  Bcast:172.xxx.xxx.xxx  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7562599 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9207906 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:550368230 (524.8 MiB)  TX bytes:1199789744 (1.1 GiB)
 
 

Internet Protocol Version 6, Src: fe80::6d26:e8e8:e078:3014 (fe80::6d26:e8e8:e078:3014), Dst: ff02::1:ffd8:2bd5 (ff02::1:ffd8:2bd5)
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 32
    Next header: ICMPv6 (0x3a)
    Hop limit: 255
    Source: fe80::6d26:e8e8:e078:3014 (fe80::6d26:e8e8:e078:3014)
    Destination: ff02::1:ffd8:2bd5 (ff02::1:ffd8:2bd5)
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0xcafd [correct]
    Reserved: 0 (Should always be zero)
    Target: fe80::21b:fcff:fed8:2bd5 (fe80::21b:fcff:fed8:2bd5)
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:1d:7d:xx:xx:xx
 

The IPv6 packet you captured is a Neighbor Solicitation packet. It's the IPv6 equivalent of ARP.

Your computer (fe80::6d26:e8e8:e078:3014) is looking for a reply from fe80::21b:fcff:fed8:2bd5 containing that computer's MAC address.

Indeed, but the the address in the capture and the many other different destinations are not local.

As far as I'm aware NS, like arp will only capture local packets and the scope ID of the IPv6 frame is link local?

It's the NS multicasts I'm referring to. When I start uTorrent, I get a great many ff02::1 multicasts, to around 15 different multicast addresses. For example:

ff02::1:ff3d:3d60
ff02::1:ff12:3da0
ff02::1:ffff:fffe
ff02::1:ff78:3014
ff02::1:ff24:e7b0  
ff02::1:ffd8:2bd5
 

FF02::1:FF00:0000/104 is the solicited-node multicast address space.

When A wants to talk to B, and A doesn't know B's MAC address (but knows it's IPv6 address), the process works as follows:

1. Take the low-order 24 bits of B's IPv6 address.
2. Append that to FF02::1:FF00:0000/104 to create a solicited-node multicast address.
3. Perform Neighbor Solicitation with the multicast address to find B's MAC address.

So, your uTorrent client is wanting to contact several hosts, probably trackers or other endpoints.

Since you don't have IPv6 up and running on your router, I surmise that your local workstation doesn't have an IPv6 default gateway. Thus, when your uTorrent client attempts to contact these hosts, the IPv6 stack thinks these addresses must be local, so it's proceeding to try to find them on the local network. Even though the addresses it's trying to contact aren't actually local, when the low-order 24 bits gets copied into the solicited-multicast address, the NS packet then looks like it's trying to find a local address. If your workstation had an IPv6 default gateway, there wouldn't be any NS going on for these hosts, the uTorrent client would simply try to contact that host through your router/default gateway.

Thank you for that, I really appreciate the time spent helping me. I think it's now starting to make a lot more sense

reply to Dapper
Just a wild guess here...anycast DNS or something like that? How about, since it's BT, it's trying to ummmm what's the phrase? join a swarm, on v6 first? Or as another poster said, it's possibly reporting to a tracker, to inform others you have pieces of the files of possible interest.
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules.


Jeopardy! replies and randomcaps REALLY suck!

Thanks for the reply rchandra I'm still investigating these multicasts...

If I may, I have a follow-up question.

I'm now seeing inbound multicasts to:

ff02::2 (All routers multicast)
ff02::16 (All MLD2 routers multicast)

Both of these have a local scope and they are coming in from:

fe80::f1ee:afbe:1e85:9b1d

Which is an unknown link local address. As I said earlier, there is only one IPv6 enabled device on my network. that's this PC and it's link local address is:

fe80::6d26:e8e8:e078:3014

I also have one entry, which is:

[From] :: [to] ff02::1:ff85:9b1d

Which is the equivalent of 0.0.0.0 (ipv4) to the All nodes multicast. I understand the destination but the origin is a little odd for something non-local.

Any ideas?

Thanks for the help

sorry, at this point, I'm about as baffled as you. Wish I had more of a clue on those.

good observation though, about the functional equivalence of 0.0.0.0 and ::

Ok, quick question, Can ICMPv6 traffic pass through a NAT4 router with a stateful IPv4 firewall?

Any host could be dual stack. For example in the case of Ethernet, the frame type field indicates (or can indicate, among other things) whether the frame is IPv4 or IPv6. Your question kinda doesn't make sense. Whether your said system has NAT4 (assuming you mean ability to NAT IPv4 packets) or stateful IPv4 firewalling has nothing to do with ICMPv6, or IPv6 in general. When the frame comes through with a frame type of 0x0800, the software (should) say(s) to itself, "hey, I got an IPv4 frame!" and then do something with it. Likewise, if the number is 0x86DD, any IPv6 code picks that up and processes it. So right off the bat, the IPv4 code SHOULD theoretically be bypassed.

So in strict, direct answer to your question, no. Having NAT4 or stateful IPv4 firewalling is insufficient. This does not however preclude you from having IPv6 software on the same device.
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules.


Jeopardy! replies and randomcaps REALLY suck!

I guess the question was poorly phrased but thanks for the reply

Basically, I'm still trying to find out where these multicasts are coming from. They don't appear to be originating on my network, so they must be coming in from outside. The only device between my LAN and the Internet is my router.

By default, the router is a standard NAT4 device running custom firmware and supports stateful iptables. The router can also be configured to support IPv6. Unfortunately, it's still running a 2.4 kernel and whilst it supports ip6tables, they don't yet support state.

So I was just trying to ascertain whether or not, when the router is operating in 'ipv4' mode it would simply allow ICMPv6 frames to pass through unchecked.

I appreciate a NAT4 router is no barrier to tunnelled IPv6 packets, but this traffic is not tunnelled.

I hope that makes more sense

nope. IPv4 still says nothing about IPv6 or bridging. "IPv6 disabled" can also mean a lot of things: it will not inspect v6, it will not consume v6, it will not pass v6. Bridges on the other hand mostly don't care; frames in one port get retransmitted to all other ports, and if it's all designed right, an exception would be made for either loops detected by STP, or something else (like ip6tables) which makes a decision not to pass packets through. Also, if the bridge learns MAC addresses, unicast frames are only transmitted on ports where that MAC addr has been seen before.

A lot of these routers' software creates bridges to join Ethernet ports with wireless radios. However, it's not common (but possible) to bridge WAN to LAN.

I'd also say unless you can trace packets on all devices (tcpdump for example), or have some means of segregating each, I'm not so sure you can rule out a device as being the source of what you're seeing. It's certainly possible for lots of controllers to transmit frames with any MAC addr it wants as the source (aka address spoofing), but close to all of the time, the src MAC addr will be genuine. Most of these sniffing tools (e.g. Wireshark) will show you the link level details. Then you can go about matching up frames with MAC addresses and therefore devices (assuming each is discoverable somehow--stamped on a sticker on the unit, some status page, some command like ip -0 link list you can run, etc.). Maybe that will be illuminating.
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules.


Jeopardy! replies and randomcaps REALLY suck!

On the router I use, the custom firmware allows for IPv6 to be used in a variety of ways, native, tunnelled etc. It also allows me to turn it off entirely. As I mentions earlier, when ipv6 is disabled none of the interfaces receive an ipv6 address (see earlier ifconfig) and radvd is not loaded.

When running with ipv6 disabled ip -0 link list produces:

1: lo: <LOOPBACK,MULTICAST,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether e0:cb:4e:a8:6e:f3 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether e0:cb:4e:a8:6e:f3 brd ff:ff:ff:ff:ff:ff
5: vlan0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue 
    link/ether e0:cb:4e:a8:6e:f3 brd ff:ff:ff:ff:ff:ff
6: vlan1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc noqueue 
    link/ether e0:cb:4e:a8:6e:f3 brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc noqueue 
    link/ether e0:cb:4e:a8:6e:f3 brd ff:ff:ff:ff:ff:ff
8: ppp0: <POINTOPOINT,MULTICAST,UP> mtu 1460 qdisc pfifo_fast qlen 3
    link/ppp 
 

9: six0@NONE: <POINTOPOINT,NOARP,UP> mtu 1280 qdisc noqueue 
    link/sit ***.***.26.204 peer 216.66.80.30
 

What's the MAC address of the packet that seems to be coming from link-local addr ff02::1:ff85:9b1d?

I now feel like a complete chump! I believe the mystery is had been solved.

Unbeknownst to me, one of my daughters had installed virtualbox on my old laptop, I seldom use it, and was running suse!

I'm still not sure about the utorrent multicasts, but perhaps their connected.

Thanks for all your help and patience.

The explanation for the last part of your mystery is something I've noticed, and a bit of a pet peeve for me:

Bittorrent supports a feature called "peer exchange", to aid in trackerless operation, where clients will tell each other of other addresses that are participating in the swarm.

There are broken clients out there that see their own link-local IPv6 address and try to share that with others, failing to observe that it's LINK LOCAL and unroutable and a completely useless address to share.

And uTorrent isn't smart enough to just automatically toss out these addresses, so it will persistently try to connect to them each time it (re-)receives them in peer exchange, leading to the scenario more or less described in SomeJoe7777's post.