JEP-0174: Link-Local Messaging

This document describes how to establish XMPP-like 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.3
Last Updated: 2006-02-23
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: < Messaging (JEP-0174)>

Author Information

Peter Saint-Andre


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 <>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <> 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
2. Glossary
3. DNS Records
3.1. TXT Records
4. Discovering Other Users
5. Exchanging Presence
6. Exchanging Messages
7. Internationalization Considerations
8. Security Considerations
9. IANA Considerations
10. Jabber Registrar Considerations
11. Acknowledgements
Revision History

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 local "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks.

Such a local "mesh" 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 link-local messaging 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

Term Description
Bonjour Apple Computer's implementation of zero-configuration networking, formerly known as Rendezvous. See <>.
DNS-SD A convention for naming and structuring DNS SRV records such that a client can dynamically discover a domain for a service using only standard DNS queries. See DNS-Based Service Discovery [2]. For a full list of registered DNS-SD records, see <>.
Link-local address An IPv4 or IPv6 address that is valid for communication with other devices connected to the same physical or logical link. See RFC 3927 [3].
Multicast DNS A technology that provides the ability to perform DNS-like operations on a local link in the absence of any conventional unicast DNS server. See Multicast DNS [4].
Zero-configuration networking A set of technologies that enable the use of the Internet Protocol for local communications. See <>.

3. DNS Records

In order to advertise its availability for link-local messaging, a client MUST publish four different kinds of DNS records:

  1. An "A" record of the form:

    machine-name.local. A ip-address
  2. An "SRV" record (see RFC 2782 [5]) of the form:

    _presence._tcp <ttl> IN SRV <priority> <weight> port-number username@machine-name.local. 
  3. A "PTR" record (see RFC 2317 [6] and RFC 1886 [7]) of the form: port-number IN PTR username@machine-name.local.
  4. Various "TXT" records (see RFC 1464 [8]) of the following form (see the TXT Records section of this document for an explanation of these fields):

    <owner> IN <ttl> TXT "1st=user-first-name"
    <owner> IN <ttl> TXT "email=user-email-address"
    <owner> IN <ttl> TXT "jid=user-jabber-id"
    <owner> IN <ttl> TXT "last=user-last-name"
    <owner> IN <ttl> TXT "msg=freeform-availability-status"
    <owner> IN <ttl> TXT "phsh=sha1-hash-of-avatar"
    <owner> IN <ttl> TXT "port.p2pj=5298"
    <owner> IN <ttl> TXT "status=avail-or-dnd"
    <owner> IN <ttl> TXT "txtvers=1"
    <owner> IN <ttl> TXT "vc=CU!-or-C!"

The "machine-name" is the name of the computer, the "username" is the system username of the principal currently logged into the computer, the "port" may be any unassigned port number, the "ip-address" is the physical address of the computer on the local network, and the "reverse-ip-address" is the physical address in reverse order (as specified in RFC 2317 for IPv4 and RFC 1886 for IPv6).

So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5526", the IP address is "" (resulting in a reverse IP address of ""), and the personal information is that associated with the author of this document, the DNS records would be as follows:

roundabout.local. A

_presence._tcp IN SRV 5526 stpeter@roundabout.local. 5526 IN PTR stpeter@roundabout.local.

psa IN TXT "1st=Peter"
psa IN TXT ""
psa IN TXT ""
psa IN TXT "last=Saint-Andre"
psa IN TXT "msg=on the phone"
psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
psa IN TXT "port.p2pj=5298"
psa IN TXT "status=dnd"
psa IN TXT "txtvers=1"
psa IN TXT "vc=CU!"

The IPv4 and IPv6 addresses associated with a 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 "" but when the machine is connected to a wireless network, its physical address might change to "".

3.1 TXT Records

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 Records

Name Description
1st The first name of the user.
email The email address of the user.
jid The Jabber ID of the user.
last The last name of the user.
msg Natural-language text describing the user's state. This is equivalent to the XMPP <status/> element.
phsh The SHA-1 hash of the user's avatar icon or photo. [9]
port.p2pj The (hardcoded) port for peer-to-peer Jabber communications. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this TXT field.
status The presence availability of the user. Allowable values are "avail" and "dnd". [10]
txtvers The version of the TXT fields supported by the client. This document describes txtvers "1".
vc A flag advertising the user's ability to engage in video conferencing. Allowable values are "C!" and "CU!".

4. Discovering Other Users

In order to discover other users, a client sends out a broadcast request for PTR records. The client then queries each entity by sending PTR, SRV, and TXT requests to those entities.

(Details to follow.)

5. Exchanging Presence

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

6. Exchanging Messages

In order to exchange Jabber communications, the sender opens a TCP connection on the discovered port and opens a stream to the recipient with no 'to' or 'from' address:

Example 1. Opening a Stream

<stream:stream xmlns='jabber:client' xmlns:stream=''>

The recipient then responds with a stream header as well:

Example 2. Stream Header Response

<stream:stream xmlns='jabber:client' xmlns:stream=''>

The sender then can send messages (or IQs) by specifying 'to' and 'from' addresses using the logical local addresses: [12]

Example 3. Sending a Message

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

To end the chat, close the stream:

Example 4. Ending the Chat


7. Internationalization Considerations

The DNS does not allow characters outside of the US-ASCII [13] character set in A, SRV, PTR, or TXT records. This can pose problems when using the DNS in conjunction with XMPP-like systems, since XMPP allows virtually the full range of Unicode [14] characters in usernames and availability status messages. If any non-US-ASCII characters are to be included, they MUST be converted to percent-encoded octets following the rules specified in Section 2.6 of RFC 4395 [15].

8. Security Considerations

XMPP networks depend on TLS (RFC 2246 [16]) for channel encryption, SASL (RFC 2222 [17]) for authentication, and the Domain Name System (RFC 1034 [18]) 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. Therefore, zero-configuration networking does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities. (TLS could be negotiated on the local streams, but is out of scope for this specification.)

Because of the extremely different nature of a true XMPP network and a localized client "mesh", 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 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).

9. IANA Considerations

The p2pj port number 5298 is not included in the IANA Port Numbers Registry [19] maintained by the Internet Assigned Numbers Authority (IANA) [20]. The author will investigate whether that port number (or some other port number) needs to be registered.

10. Jabber Registrar Considerations

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

11. Acknowledgements

Thanks to Jens Alfke, Marc Krochmal, and Justin Karneges for their input.


1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <>.

2. DNS-Based Service Discovery <>. Work in progress.

3. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses <>.

4. Multicast DNS <>. Work in progress.

5. RFC 2782: A DNS RR for specifying the location of services (DNS SRV) <>.

6. RFC 2317: Classless IN-ADDR.ARPA delegation <>.

7. RFC 1886: DNS Extensions to support IP version 6 <>.

8. RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes <>.

9. The client should keep a local cache of icons keyed by hash. If the phsh value is not in the cache, the client should fetch the unknown icon and then cache it. Implementations should also include logic for expiring avatar icons.

10. These values effectively map to mere XMPP presence (the user is online or available) and the XMPP <show/> value of "away".

11. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <>.

12. The "JIDs" MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

13. Coded Character Set - 7-bit American Standard Code for Information Interchange (American National Standards Institute X3.4, 1986).

14. The Unicode Standard, Version 3.2.0 (The Unicode Consortium, 2000).

15. RFC 4395: Guidelines and Registration Procedures for New URI Schemes <>.

16. RFC 2246: The TLS Protocol Version 1.0 <>.

17. RFC 2222: Simple Authentication and Security Layer (SASL) <>.

18. RFC 1034: Domain Names - Concepts and Facilities <>.

19. IANA registry of port numbers <>.

20. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <>.

21. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <>.

Revision History

Version 0.3 (2006-02-23)

Added more details about DNS setup and stream initiation; specified internationalization considerations.


Version 0.2 (2006-02-22)

Corrected information about Service Instance Name format, p2pj port, and presence discovery process.


Version 0.1 (2006-02-09)

Initial JEP version; changed title to Link-Local Messaging.


Version 0.0.1 (2006-02-07)

First draft.