IPv6 Multicast Address

[svdo]

Hi,

Question: Is Syncthing using a proper address for IPv6 mulitcast?

Background:
I'm working with @dapperstout on the Swift implementation of syncthing. Because I'm having trouble getting IPv6 multicast to work, I posted a question about it on stack overflow: http://stackoverflow.com/questions/31574247/gcdasyncudpsocket-cannot-get-udp-multicast-over-ipv6-to-work?noredirect=1#comment51108878_31574247. I don't know too much about IPv6 yet, but on stack overflow it is claimed that the Syncthing multicast address (ff32::5222), as specified in https://github.com/syncthing/specs/blob/master/DISCOVERYv2.md, is reserved for future use (referring to http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#unicast-multicast-group-ids).

Could someone with enough knowledge on this have a look at it? If this is a bug in the specification, it would be good to fix it.

[calmh]

I admit I don't really know and find the available documentation somewhat confusing. I think I made that choice based RFC 3307 (Allocation Guidelines for IPv6 Multicast Addresses, https://tools.ietf.org/html/rfc3307#section-4.3). If there's someone more knowledgeable who can interpret things and make a recommendation it's not a problem to change the spec and code in the next minor beta release.

[calmh]

Looks like I misread the documentation and made an invalid assumption. We should use something in FF3X::8000:0 to FF3X::FFFF:FFFF instead. This will be changed in the spec and the v0.12 release of Syncthing.

[calmh]

Lacking any real reasons to choose otherwise I suggest ff32::8384:8384 (link local, temporary, 8384 being ST in ASCII). It also matches the default GUI/API port and so may have some default association to Syncthing by those who see it.

[svdo]

I think an important question is whether we want any-source multicast or source-specific multicast (https://en.wikipedia.org/wiki/Source-specific_multicast). The FF3X::8000:0 to FF3X::FFFF:FFFF is under the heading "Unicast-based (Including SSM) Multicast Group IDs". I'm not sure if that's what you want, the alternatives are under the heading "Link-Local Scope Multicast Addresses". I see things like SSDP, UPnP and mDNSv6 are all link-local multicast addresses. Since synching is using this for discovery, I got a strong suspicion that it should also use that type of multicast addresses.

I just read this IPv6 quick start, it helped me a bit in understanding some of the terminology: https://4sysops.com/archives/ipv6-part-1-get-started-now/

[dcarosone]

There is a strong case for doing both. Link local can work even when no explicit addressing has been configured. Just plug in a cable. Source specific is very useful for discovery across multiple hops, in a network set up to support multicast routing. This is sadly not so common on the general internet, but more common in campus and corporate networks. Even in home and SOHO type networks it's valuable, for example between a wired and wireless segment, or across a VPN hop. For comparison, btsync uses multicast discovery with a TTL (hop count) of 3. That's in ipv4, I don't recall them supporting v6 at all. This let discovery work in exactly the above cases; one of the very few aspects of that program I still miss.

[calmh]

Myeah, so ff32:: in this case is link-local, transient, based on network prefix. The first two are correct, the latter isn't. So I guess ff12:: may be the prefix we're looking for (link-local, transient). "Transient" in this case meaning "not assigned by IANA". http://tools.ietf.org/html/rfc4291#section-2.7

I don't think SSM or not is encoded in the address here, other than by some guidelines on how to select SSM addresses. If we wanted a wider scope than link-local I guess that would be admin-local or possibly site-local...