I have recently installed Jaguar on my iBook, and I am impressed with where Apple is going with networking. The Rendezvous component of iChat, for example, makes it easy to find other iChat users on the local network, without having to log into AOL’s central chat server.
I’ve just been poking around with tcpdump and the iChat client. It appears that it’s using multicast UDP port 5353 for its transport.
When taking rendezvous offline:
10:42:59.246820 10.1.31.19.5353 > 224.0.0.251.5353: udp 56 10:43:00.090607 10.1.31.19.5353 > 224.0.0.251.5353: udp 58 10:43:00.232728 10.1.31.19.5353 > 224.0.0.251.5353: udp 58
When coming back online:
10:43:14.740378 10.1.31.19.5353 > 224.0.0.251.5353: udp 181 10:43:14.797714 10.1.19.49925 > 224.0.0.251.5353: udp 48 [ttl 1] 10:43:14.798237 10.1.31.19.5353 > 224.0.0.251.5353: udp 1427 10:43:14.798355 10.1.31.19.5353 > 224.0.0.251.5353: udp 95 10:43:14.798653 10.1.31.75.5353 > 10.1.31.19.49925: udp 426 10:43:14.800206 10.1.31.19.49925 > 224.0.0.251.5353: udp 48 [ttl 1]
…etc, for several hundred more lines, all coming from other rendezvous users (as we negotiate names, status, and those almost too cute user photos.)
A couple of us at ORA were kicking around what would be involved in getting rendezvous to find users not only on our network, but on a private network at another office. Obviously, if it’s using multicast, we’re missing each other as we’re separated by a router hop (we’re using 10.1/16 in one office, and 10.2/16 in the other.)
What about setting up multicast routing between the two networks? I’ve never done it, but it sounds like running DVMRP under Zebra on a machine on each side might do the trick.
Has anybody done this? It’d make a nifty hack to be able to get Rendezvous traffic bridged between arbitrary networks… Having multicast routed across the already forming GRE network that carries community wireless traffic cross-country would be pretty spiffy. (Think true peer-to-peer chat and file sharing, without a centralized server to login to, available at any free public wireless node…)
Has anyone found a better source of information on Multicast and Linux than the HOWTO?
Have you ever set up multicast traffic to cross a router hop? Is there an easier way to make rendezvous traffic flow between networks?
Re: Multicast routing and Rendezvous
You can find info about Zeroconf (aka Rendezvous) at these url's:
http://www.zeroconf.org/
http://www.ietf.org/html.charters/zeroconf-charter.html
Concerning your question, the initial implementation of Rendezvous appears to be link-local only (I did a bit investigating with my iMac and a protocol Sniffer). At the first link above, they describe taking zeroconf beyond local links using multicast and dynamic DNS.
So, I believe that (initially) if you want the ability to run e.g. iChat over one or more router hops, you'll have to figure out a way to tunnel at the mac layer e.g. L2PT or EtherIP or some such.
A router MUST not forward packets addressed to 224.0.0.X, and I notice that Apple is sending UDP/RPC packets to 224.0.0.251 with a TTL of 255. I'm sure they decided on a TTL > 1 for a reason, but these packets will not be forwarded by any routers that I'm aware of, so will remain on the local subnet.
regards,
Allen
Re: Multicast routing and Rendezvous
I said:
>I'm sure they decided on a TTL > 1 for a reason
Reading through the zeroconf specs it becomes evident they are using TTL=255 for the same reason I've seen it used in a few other specs, i.e. security. From http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-07.txt
"Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 255. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix.
This allows hosts to guard against misconfigured routers, which may allow packets to leak in from outside the local link. Since even the most dysfunctional router will decrement the TTL in the IP header, a host can know with reasonable certainty that any packet received with a TTL of 255 did come from another host on the local link."
---
Although, I'd take issue with their assumption that "even the most dysfunctional router will decrement the TTL in the IP header." Methinks they doth assume too much :-)
regards,
Allen
Re: Multicast routing and Rendezvous
I set up multicast on a cisco between 2 subnets here at work according to:
http://www.cisco.com/en/US/tech/tk828/tk363/technologies_tech_note09186a0080094821.shtml
and had no luck getting zeroconf to cross.
I really hope they come up with something or Apple's goal of getting rid of Appletalk will never happen (at least not where I work).
Jim
Any luck??
I was just wondering the same thing... (one year later)
I will write a little program for this....
I have a friend who asked me today how to see rendezvous entries on a network attached to a xserve router from another network on the xserve's second ethernet card.
Searching the web did not reveal any usefull info, but as I know how to write scripts, ipfw rules and c-programs, I think I will write a little program which uses ipdivert rules to put packets for 224.0.0.251:5353 from one card onto the other card and vice versa. Effective a rendezvous proxy server.
Does that sound ok?
--
Stephan (you can mail me at jvc dot nl)
Re: Multicast routing and Rendezvous
Actually, my traces (between two Macs running Panther) show that the MDNS request goes out with TTL=1 and the response comes back with TTL=255.
Both values make sense from a security standpoint. The TTL=1 on the request ensures that it won't be routed off the local network even by a misconfigured router. In much the same way, the TTL=255 on the response lets the requester know that it came from a local host and is not an attempt by some remote host to poison your DNS cache.