XEP-0174: Link-Local Messaging

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


NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.


Document Information

Series: XEP
Number: 0174
Publisher: XMPP Standards Foundation
Status: Proposed
Type: Standards Track
Version: 0.9
Last Updated: 2006-12-22
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, 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 (XEP-0174)>

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/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 discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the XSF-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 XMPP Standards 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 document 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 following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents


1. Introduction
2. Glossary
3. DNS Records
    3.1. TXT Records
4. Discovering Other Users
5. Exchanging Presence
6. Establishing XML Streams
7. Exchanging Messages
8. Ending a Chat
9. Going Offline
10. Implementation Notes
    10.1. Multiple Network Interfaces
    10.2. Buddy Icons
11. Internationalization Considerations
12. Security Considerations
    12.1. Authentication and Encryption
    12.2. Stanza Injection
    12.3. Private Information
13. IANA Considerations
14. XMPP Registrar Considerations
15. Acknowledgements
Notes
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 authenticated with a server, and the server must not grant access if authentication fails for any reason. If an unauthenticated client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through one or more servers 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 communication 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 (though see the Security Considerations regarding the ability to "forward" messages from a local mesh to an XMPP network or vice-versa).

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 a feature of 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 link-local communication.

2. Glossary

Table 1: Terminology

Term Description
Bonjour Apple Computer's implementation of zero-configuration networking, formerly known as Rendezvous. See <http://www.apple.com/macosx/features/bonjour/>.
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 <http://www.dns-sd.org/ServiceTypes.html>.
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 (mDNS) 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 <http://www.zeroconf.org/>.

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 address ("A") record of the following form:

    machine-name.local. A ip-address
          
  2. An "SRV" record (see RFC 2782 [5]) of the following 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 following form:

    _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.local.
          
  4. Optionally, various "TXT" records (see RFC 1464 [8]) of the following form, as further described in to the TXT Records section of this document:

    <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-away-or-dnd"
    <owner> IN <ttl> TXT "txtvers=1"
    <owner> IN <ttl> TXT "vc=capabilities-string"
          

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, and the "ip-address" is the physical address of the computer on the local network.

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

roundabout.local. A 10.2.1.187

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

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

psa IN TXT "1st=Peter"
psa IN TXT "email=stpeter@jabber.org"
psa IN TXT "jid=stpeter@jabber.org"
psa IN TXT "last=Saint-Andre"
psa IN TXT "msg=IETF 66 Montreal"
psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
psa IN TXT "port.p2pj=5298"
psa IN TXT "status=avail"
psa IN TXT "txtvers=1"
psa IN TXT "vc=CA!"
  

The IPv4 and IPv6 addresses associated with a machine may vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "10.2.1.187" but when the machine is connected to a wireless network, its physical address might change to "10.10.1.179".

In the unlikely event that the "presence name" (username@machine-name) asserted by a client is already taken by another entity on the network, the client MUST choose a different presence name, which SHOULD be formed by adding the digit "1" to the end of the username string, adding the digit "2" if the resulting presence name is already taken, and incrementing the digit until a unique presence name is constructed.

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 given or first name of the user.
email The email address of the user.
jid The Jabber ID of the user.
last The family or 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] This SHOULD be requested using mDNS in unicast mode by sending a DNS query to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
port.p2pj The (hardcoded) port for link-local communications. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this TXT field, which is included only for backwards-compatibility with some older, existing implementations.
status The presence availability of the user. Allowable values are "avail", "away", and "dnd", which map to mere XMPP presence (the user is available) and the XMPP <show/> values of "away" and "dnd", respectively.
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 audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial.

It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also the Security Considerations section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "email", and "jid" keys).

4. Discovering Other Users

In order to discover other users, a client sends an mDNS request for PTR records that match "_presence_tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging. [10] The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "username@machine-name._presence._tcp.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a link-local "roster" MUST be obtained from the <Instance> portion of the received PTR record for each user; the client MAY display a name or nickname derived from the TXT records if available.

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 Multicast DNS.

6. Establishing XML Streams

In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.

First, the initating party opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient with no 'to' or 'from' address:

Example 1. Opening a Stream

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
  

The recipient then responds with a stream header as well:

Example 2. Stream Header Response

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
  

The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. See the Security Considerations section of this document regarding methods for authenticating and encrypting the stream.

7. Exchanging Messages

Once the streams are established, either entity then can send XMPP message or IQ stanzas 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>
</message>
  

8. Ending a Chat

To end the chat, either party closes the XML stream:

Example 4. Ending the Chat

</stream:stream>
  

The other party then closes the stream in the other direction as well:

Example 5. Closing the Stream

</stream:stream>
  

Both parties then MUST close the TCP connection between them.

9. Going Offline

In order to go offline, a client MUST send a Multicast DNS "Goodbye" packet for the user's PTR record. As a result, all other entities on the local network will receive a Multicast DNS "Remove" event, at which point they MUST cancel any outstanding TXT, SRV, or NULL record queries for the offline user.

10. Implementation Notes

10.1 Multiple Network Interfaces

Devices that use link-local messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the local roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communications when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.

10.2 Buddy Icons

If an entity has an associated icon (e.g., a user avatar or photo), its client SHOULD publish the raw binary data for that image via a DNS NULL record of the following form:

_presence._tcp.local. IN NULL raw-binary-data-here
    

Note: In accordance with RFC 1035 [13], the data MUST be 65535 octets or less.

After retrieving the "phsh" value from a Buddy's TXT record, a client SHOULD search its local picture database to learn the last recorded picture hash value for an entity and then compare it to the "phsh" value in the TXT record. If the values are equal, the client SHOULD use the local copy of the icon. If the picture hash values are not equal, the client SHOULD issue a Multicast DNS NULL record query to retrieve the new icon. After retrieving the NULL record, the client SHOULD replace the old "phsh" value in the picture database with the new "phsh" value and save the icon to disk. If the client needs to send a Multicast DNS query in order to retrieve the icon, it MUST cancel the NULL record query immediately after receiving a response containing the new picture data.

If a user changes their picture, the user's client MUST update the NULL record with the contents of the new picture, calculate a new picture hash, and then update the "phsh" value in the TXT record with the new hash value. Since all users logged into local presence are monitoring for TXT record changes, they will see that the "phsh" value was changed; if they wish to view the new icon, their clients SHOULD issue a new Multicast DNS query to retrieve the updated picture.

11. Internationalization Considerations

RFC 1035 does not allow characters outside the US-ASCII [14] character range in DNS A records. Therefore the "machine-name" portion of an A record as used for link-local messaging MUST NOT contain characters outside the US-ASCII character range.

Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in link-local messaging is the "username@machine-name" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine-name" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

12. Security Considerations

12.1 Authentication and Encryption

XMPP networks use TLS (RFC 2246 [15]) for channel encryption, SASL (RFC 4422 [16]) for authentication, and the Domain Name System (RFC 1034 [17]) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, link-local messaging 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.

There are two potential solutions to this problem:

  1. Negotiate the use of TLS and SASL for the XML stream as described in RFC 3920.
  2. Negotiate encryption with identity checking for the message exchange using Encrypted Session Negotiation [18].

It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client MUST warn the human user that the channel is unauthenticated and unencrypted.

12.2 Stanza Injection

Because of fundamental differences between a true XMPP network and a localized XMPP 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 in accordance with the rules defined in RFC 3920. 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).

12.3 Private Information

The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).

13. 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.

14. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [21].

15. Acknowledgements

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


Notes

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. DNS-Based Service Discovery <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Work in progress.

3. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses <http://tools.ietf.org/html/rfc3927>.

4. Multicast DNS <http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>. Work in progress.

5. RFC 2782: A DNS RR for specifying the location of services (DNS SRV) <http://tools.ietf.org/html/rfc2782>.

6. RFC 2317: Classless IN-ADDR.ARPA delegation <http://tools.ietf.org/html/rfc2317>.

7. RFC 1886: DNS Extensions to support IP version 6 <http://tools.ietf.org/html/rfc1886>.

8. RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes <http://tools.ietf.org/html/rfc1464>.

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. The replies will include a record corresponding the client itself; the client MUST filter out this result.

11. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

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. RFC 1035: Domain Names - Implementation and Specification <http://tools.ietf.org/html/rfc1035>.

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

15. RFC 2246: The TLS Protocol Version 1.0 <http://tools.ietf.org/html/rfc2246>.

16. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.

17. RFC 1034: Domain Names - Concepts and Facilities <http://tools.ietf.org/html/rfc1034>.

18. XEP-0116: Encrypted Session Negotiation <http://www.xmpp.org/extensions/xep-0116.html>.

19. IANA registry of port numbers <http://www.iana.org/assignments/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 <http://www.iana.org/>.

21. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.


Revision History

Version 0.9 (2006-12-22)

Updated the security considerations to recommend either TLS+SASL at the stream layer or encrypted sessions at the messaging layer.

(psa)

Version 0.8 (2006-07-31)

Recommended use of TLS and SASL for stream security.

(psa)

Version 0.7 (2006-06-06)

Further clarified internationalization considerations.

(psa)

Version 0.6 (2006-06-05)

Clarified internationalization considerations and use of mDNS in unicast mode for avatar retrieval.

(psa)

Version 0.5 (2006-04-14)

Specified presence name conflict resolution procedure, offline procedure, use of DNS NULL record for icons, and handling of multiple network interfaces.

(psa)

Version 0.4 (2006-03-16)

Corrected PTR format and client discovery process.

(psa)

Version 0.3 (2006-02-23)

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

(psa)

Version 0.2 (2006-02-22)

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

(psa)

Version 0.1 (2006-02-09)

Initial version; changed title to Link-Local Messaging.

(psa)

Version 0.0.1 (2006-02-07)

First draft.

(psa)

END