]> Apple

f_michel@apple.com

IoTconsultancy.nl

esko.dijk@iotconsultancy.nl

Internet DNSSD SRP remove all option This document describes a new EDNS(0) option for an SRP Update to remove all previously registered services for a hostname before adding new services for that same hostname. This allows an SRP requester to replace all its previous service registrations with new ones using a single SRP Update. About This Document Status information for this document may be found at . Discussion of this document takes place on the DNSSD Working Group mailing list (), which is archived at . Subscribe at .

Introduction Some constrained devices may not afford storing the services, that they have currently registered to an SRP registrar, in persistent memory. Instead, they only store their hostname and their SRP public/private key pair. Upon a reboot, they ensure no stale service registrations remain on the SRP registrar by first sending an SRP Update to remove all their previously registered services per . Once that is done, they register their current services through another SRP Update. Since removing all services requires the lease time in the Update Lease option to be zero, and adding any service(s) requires the same option to have a nonzero lease value, SRP effectively prevents the removal of all previous services and registering new services for a same hostname in the same Update (). Therefore, this has to be done using two separate, successive SRP Updates. This document defines a new EDNS(0) option called SRP Remove All Services allowing to include the previous services removal operation in the same SRP Update that registers the new services. The option also allows an SRP requester to send a single SRP Update that removes all its registered services, while keeping its hostname registered, which is not possible currently with . This significantly reduces the amount of data transmitted over the network for doing these operations and reduces the risk of congestion caused by the operation of SRP in constrained networks.

Conventions and Definitions The key words "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 BCP 14 when, and only when, they appear in all capitals, as shown here.

The SRP Remove All Services EDNS(0) option The SRP Remove All Services Option has a length of zero and therefore has no payload. Its presence in an SRP Update for a particular hostname (as defined in the Host Description Instruction) signals to the registrar to first remove all published services for that hostname before processing the Service Discovery Instructions and Service Description Instructions contained in the Update. It is almost equivalent to first sending an SRP Update as defined by before sending this Update. The only difference is that when the SRP Remove All Services Option is used, the "Removing All Published Services" operation and the subsequent SRP Update are considered as a single atomic transaction that either entirely succeeds, or fails.

Server-side processing of the SRP Remove All Services Option An SRP registrar receiving a valid SRP Update containing the SRP Remove All Services Option first removes all service registrations for the hostname in the Host Description Instruction. This includes all SRV/TXT records for all service instance names of which the SRV record has this hostname as a target. It also includes all PTR records that point to these service instance names. Then, it processes the remaining instructions of the SRP Update as defined by . In response to an Update containing the SRP Remove All Services Option, the SRP registrar MUST include the option in its SRP Update response to indicate that it is supported. This is done regardless of whether any of the additional operations induced by the option, or the instructions contained in the SRP Update, succeed or fail.

Error cases If the "Delete All RRsets From A Name" operations induced by the SRP Remove All Services Option results in an error on the SRP registrar, it SHOULD immediately stop processing the SRP Update and MUST return the adequate response code as it would have done when processing a regular "Delete All RRsets From A Name". If all the "Delete All RRsets From A Name" operations implied by the option succeed, but the subsequent SRP Update processing fails, then all the implied "Delete All RRsets From A Name" operations are undone and the adequate error response code for the SRP Update failure is returned as defined by .

Security Considerations The SRP Remove All Services Option relies on existing security mechanisms defined in . The SRP requester MUST be properly authenticated for the hostname contained in the Host Description Instruction before the SRP registrar processes the "Delete All RRsets From A Name" operations induced by the option. Since an SRP attacker can replay any SRP Update, it can also replay the "Delete All RRsets From A Name" operations induced by the option.

IANA Considerations IANA is requested to allocate a new OPT RR option code from the DNS EDNS0 Option Codes (OPT) registry for the 'SRP Remove All Services' Option. The Name shall be 'SRP-RAS'. The value shall be allocated by IANA. The meaning shall be 'SRP Remove All Services'. Reference shall refer to this document, once published. IANA shall determine the registration date.

Normative References The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.