76

How should I choose an IPv4 multicast address for my application's use? I may need more than one (a whole range perhaps ultimately) but just want to avoid conflicts with other applications.

  • Packets will be entirely contained within an administrative domain, probably a LAN
  • If several independent instances of my application are in use on the same network, they could each use their own multicast address - but if they don't, they will be able to coexist anyway, they'll just have a small amount of overhead ignoring each others' packets.
  • My packets already contain a "magic number" to avoid problems
  • I will be checking the originator address (which I know can be spoofed of course), TTL and other things to try to prevent unexpected packets mucking things up.

Ideas please :)

Currently I've just allocated an arbitrary one from the "local use" space, 239.255.42.99

MarkR
  • 62,604
  • 14
  • 116
  • 151

5 Answers5

39

It seems you've already found http://www.iana.org/assignments/multicast-addresses, so you've done the right thing by picking an address from the 239.255/16 range.

As those ranges are entirely for site-local use it's no ones else's business which particular address you pick, but you may need to coordinate with the network manager (assuming that's not you) to pick an alternate address pool.

As others have suggested, just make sure there's an easy way to change the address just in case it does conflict with another address on the local LAN.

If the multiple applications issue becomes a problem, provide a (locally) well-known multicast address which the applications can talk to which will issue unique local-scope IP addresses for clients' use.

Alnitak
  • 334,560
  • 70
  • 407
  • 495
  • 1
    The "Organization-Local Scope" [239.0.0.0-239.255.255.255], isnt that 239.0.0.0/8 ? Also, is there a recommendation about what Multicast TTL we should use? – athspk Jul 11 '11 at 00:41
  • 13
    239.0.0.0/8 is Administratively Scoped IPv4 Multicast Space. 239.255.0.0/16 is one of it's subsets (IPv4 Local Scope) in RFC 2365. Subset that might be even closer to what is needed here is 239.192.0.0/14 (The IPv4 Organization Local Scope). – Josip Medved Feb 08 '12 at 19:26
6

As already suggested, allow the range to be configured. But taking that further, don't require configuration. You pick the range and allow configuration to override if necessary.

You should have some logic in your application to handle foreign packets, to alert the user, through logs, or some other mechanism, that your application has detected multicast packets from another app, with instructions on how to change the configuration.

If it turns out that there is a conflict, play those numbers in the lottery!

Corey Trager
  • 22,649
  • 18
  • 83
  • 121
3

Have you seen this ?

MADCAP

Malkocoglu
  • 2,522
  • 2
  • 26
  • 32
1

If it is just for internal use then why not just externalize the address range as configuration and continue to use internal use.

The Internet Assigned Numbers Authority is responsible for assigning IP addresses. They do not allocate to ISPs or individuals but on they have information where to get numbers allocated depending on your region.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Brian Matthews
  • 8,506
  • 7
  • 46
  • 68
-1

ZMAAP is a zero-configuration alternative to MADCAP. I doubt there are any public source implementations of it. If you find one, then I'd like to know about it.

Community
  • 1
  • 1
james woodyatt
  • 2,170
  • 17
  • 17