If you can't or don't want to configure routers to forward multicast traffic or otherwise handle a third party protocol, you'll need to tunnel multicast traffic over a unicast link. UFTP is capable of multicast tunneling via the use of a UFTP proxy server.
From the man page:
The proxy can run in one of three modes: a server proxy, a client
proxy, or response proxy.
A server proxy is typically local to a server and acts as the upstream
end of a multicast tunnel. It listens on the public multicast address
(and private multicast address when specified) and forwards downstream
packets to a specific address downstream. Upstream packets are
forwarded back where the announcement originated from.
A client proxy is typically local to one or more clients and forms the
downstream end of a multicast tunnel. It receives unicast data from
one or more server proxies and forwards downstream traffic to the
multicast address specified in the packet header. Upstream traffic
from clients is gathered and forwarded back where the announcement
came from as an aggregated response.
Below is a diagram of a typical configuration where a server sends multicast messages to the local network, and one or more server proxies unicast the messages to a corresponding client proxy, which in turn multicasts the messages to its local network.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x Network A x
x ---------- x
x | Server | x
x ---------- x
x | x
x | multicast x
x | x
x |----------------------------------------- x
x | | | x
x v v v x
x ---------------- ---------------- ---------- x
x | Server Proxy | | Server Proxy | | Client | x
x ---------------- ---------------- ---------- x
x | | x
x | unicast | unicast x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| |
| ------------
| |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x | Network B x x | Network C x
x v x x v x
x ---------------- x x ---------------- x
x | Client Proxy | x x | Client Proxy | x
x ---------------- x x ---------------- x
x | x x | x
x | multicast x x | multicast x
x | x x | x
x |------------- x x |------------ x
x | | x x | | x
x v v x x v v x
x ---------- ---------- x x ---------- ---------- x
x | Client | | Client | x x | Client | | Client | x
x ---------- ---------- x x ---------- ---------- x
x x x x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx
These proxies are also capable of working in a NATed environment:
If a client proxy is behind a firewall, the proxy can send a heartbeat
message to the upstream proxy to make a pinhole in the firewall that
the upstream server proxy can connect to. If the client proxy is also
NATed, the upstream server proxy may not know the IP/port of the
client proxy, so the server proxy can be configured to wait for a
heartbeat message, and use the IP/port the heartbeat came from as its
downstream address. If the server proxy is also behind a firewall or
NAT, a second server proxy on a machine with a publicly accessible IP
can be inserted between the first server proxy and the client proxy.
In this case, the first server proxy is set up to use the second as
its downstream address, and the second server proxy is set up to use
the first heartbeat it receives from a client proxy as its downstream
address.
I'm the author of this software, so if you need pointers regarding how to set this up, send me an email via the link at the bottom of the UFTP page and we'll see what we can do.
Update:
In the case of PGM, it can be configured to run at either the application layer (i.e. on top of UDP) or at the transport layer (i.e. directly on top of IP). If PGM is run at the transport layer, that's where you might need to worry about the router having special support for it. Conversely, UFTP runs strictly at the application layer.