JEP-0174: Link-Local Messaging

This document describes how to establish Jabber communications over local networks using zero-configuration networking.

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Standards Track
Number: 0174
Version: 0.2
Last Updated: 2006-02-22
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 3927, draft-cheshire-dnsext-dns-sd, draft-cheshire-dnsext-multicastdns
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Link-Local Messaging (JEP-0174)>

Author Information

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction

XMPP as defined in RFC 3920 [1] does not support direct client-to-client interactions, since it requires authentication with a server: an XMPP client is allowed access to the network only once it has authentication with a server, and the client is not granted access to the network if authentication fails for any reason. If a client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through a server and a client cannot inject messages onto the network without first authenticating with a server.

However, it is possible to establish an XMPP-like communications system on a local network using zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish link-local communiation using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP <message/> and <iq/> stanzas. Note well that such communications are restricted to the local network because of how zero-configuration networking works. It is impossible for clients that communicate via link-local addresses to insert messages into an XMPP network, which is why this kind of "client mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks.

Such local, peer-to-peer Jabber meshes can be quite valuable in certain circumstances. For instance, participants in a trade show or conference, users of the same WiFi hotspot, or employees on the same local area network can communicate without the need for a pre-configured server. For this reason, support for local Jabber communication has been built into Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode. Because it is desirable for other Jabber clients to support such functionality, this document describes how to use zero-configuration networking as the basis for local Jabber communication.

2. Glossary

Table 1: Terminology

3. Addresses

In order to advertise its availability on a local network, a client MUST advertise a DNS-SD service of "machine-name._presence._tcp.local." (where "machine-name" is the <Instance> portion of the Service Instance Name, "_presence._tcp" is the <Service> portion, and "local." is the <Domain> portion). For example, if the machine is "roundabout", the advertised service would be "roundabout._presence._tcp.local.". The IPv4 and IPv6 addresses associated with that machine will vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be as follows:

10.2.1.187:7363
[fe80:20d:93ff:fe2c:5c18]:7363
  

However, when the machine is connected to a wireless network at a conference, its physical address might change to the following:

10.10.1.179:7363
[fe80::20d:93ff:fe89:4eba]:7363
  

A client MUST also advertise an appropriate DNS PTR record, such as:

187.1.2.10.in-addr.arpa 7363 IN PTR 
  

In order to determine the port to use for link-local messaging, a client MUST use the port as discovered via DNS SRV lookup as validated via the PTR record.

The JID shown to other entities on the network SHOULD be of the form "user@machine-name". For instance, in the foregoing examples, the user's address would be shown as "stpeter@roundabout".

4. Exchanging Presence

When the _presence._tcp service is used, presence is exchanged via the format described in the TXT Keys section of this document. In particular, presence information is not pushed as in XMPP (see RFC 3921 [8]). Instead, clients listen for presence announcements from other local entities. Recommended rates for sending updates can be found in draft-cheshire-dnsext-multicastdns.

5. Exchanging Jabber Communications

In order to exchange Jabber communications, the sender specifies 'to' and 'from' addresses using the logical local addresses:

Example 1. Sending a Message

<message to='hildjj@wolfram' from='stpeter@roundabout'>
  <body>hey, testing out link-local communications</body>
</message>
  

6. TXT Keys

DNS-SD enables service definitions to include various TXT keys that specify parameters to be used in the context of the service type. The TXT keys defined for the _presence._tcp service are as follows:

Table 2: TXT Keys

7. Security Considerations

XMPP networks depend on TLS (RFC 2246 [10]) for channel encryption, SASL (RFC 2222 [11]) for authentication, and the Domain Name System (RFC 1034 [12]) for validation of server hostnames; these technologies help to ensure the identity of sending entities. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Because of the extremely different nature of full XMPP networks and localized client meshes, local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated. However, a client on a local peer-to-peer mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).

8. IANA Considerations

The p2pj port of 5298 is not included in the IANA Port Numbers Registry [13] maintained by the Internet Assigned Numbers Authority (IANA) [14]. The author will investigate whether the port needs to be registered.

9. Jabber Registrar Considerations

This JEP requires no interaction with the Jabber Registrar [15].

10. Acknowledgements

Thanks to Jens Alfke and Marc Krochmal for their input.

Notes

Revision History

END