No subject

1. A distributed set of nodes
2. No central server(s)
3. Nodes can lose connectivity, and possibly change IPs
4. Reliable chat and conferencing between nodes (as reliable as the
network allows at least)

Is that correct? Is a central server completely out of the question?

Regarding your questions..

a) No XMPP spec requires, and no implementation I'm aware of makes use
of IP multicast. Conferencing is based on normal XMPP over TCP.

b) BOSH can be used for S2S, but no one does that. Have a look at
XEP-0198: Stream management, which also supports session resumption.

c) You can get away with not using DNS. Hosts files are not good
enough. They override A records, while XMPP servers try SRV records
first. The Prosody server has a plugin to allow custom SRV records
(http://code.google.com/p/prosody-modules/wiki/mod_srvinjection), and
IIRC ejabberd allowed the same in its config.

d) Conferences distributed across servers.. there are no
implementations yet, though as Peter said, work is being done towards
that. There are servers which support clustering conferences, but I
suspect none of them would handle your unreliable network use-case too
well.

You should take a good look at XEP-0198 session resumption. If your
nodes only temporarily go off the network (e.g., for a few minutes),
XEP-0198 can transparently handle that. You may be able to crank up
server timeouts to allow XEP-0198 based session resumption hours or
days after network failure. This has obvious consequences, like all
XMPP data having to be cached for resending, and servers/clients
having to deal with the flood of data on reconnect after a long delay,
but it gets pretty close to satisfying your requirements.

--
Waqas Hussain