Extensible Provisioning Protocol (EPP) Transport Over TCP
RFC 4934

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                      S. Hollenbeck
Request for Comments: 4934                                VeriSign, Inc.
Obsoletes: 3734                                                 May 2007
Category: Standards Track

       Extensible Provisioning Protocol (EPP) Transport over TCP

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes how an Extensible Provisioning Protocol (EPP)
   session is mapped onto a single Transmission Control Protocol (TCP)
   connection.  This mapping requires use of the Transport Layer
   Security (TLS) protocol to protect information exchanged between an
   EPP client and an EPP server.  This document obsoletes RFC 3734.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Conventions Used in This Document . . . . . . . . . . . . . 2
   2.  Session Management  . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Message Exchange  . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Data Unit Format  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Transport Considerations  . . . . . . . . . . . . . . . . . . . 5
   6.  Internationalization Considerations . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Changes from RFC 3734  . . . . . . . . . . . . . . . . 9

Hollenbeck                  Standards Track                     [Page 1]
RFC 4934                   EPP TCP Transport                    May 2007

1.  Introduction

   This document describes how the Extensible Provisioning Protocol
   (EPP) is mapped onto a single client-server TCP connection.  Security
   services beyond those defined in EPP are provided by the Transport
   Layer Security (TLS) Protocol [RFC2246].  EPP is described in
   [RFC4930].  TCP is described in [RFC0793].  This document obsoletes
   RFC 3734 [RFC3734].

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Session Management

   Mapping EPP session management facilities onto the TCP service is
   straightforward.  An EPP session first requires creation of a TCP
   connection between two peers, one that initiates the connection
   request and one that responds to the connection request.  The
   initiating peer is called the "client", and the responding peer is
   called the "server".  An EPP server MUST listen for TCP connection
   requests on a standard TCP port assigned by IANA.

   The client MUST issue an active OPEN call, specifying the TCP port
   number on which the server is listening for EPP connection attempts.
   The EPP server MUST return an EPP <greeting> to the client after the
   TCP session has been established.

   An EPP session is normally ended by the client issuing an EPP
   <logout> command.  A server receiving an EPP <logout> command MUST
   end the EPP session and close the TCP connection with a CLOSE call.
   A client MAY end an EPP session by issuing a CLOSE call.

   A server MAY limit the life span of an established TCP connection.
   EPP sessions that are inactive for more than a server-defined period
   MAY be ended by a server issuing a CLOSE call.  A server MAY also
   close TCP connections that have been open and active for longer than
   a server-defined period.

3.  Message Exchange

   With the exception of the EPP server greeting, EPP messages are
   initiated by the EPP client in the form of EPP commands.  An EPP
   server MUST return an EPP response to an EPP command on the same TCP
   connection that carried the command.  If the TCP connection is closed
   after a server receives and successfully processes a command but

Hollenbeck                  Standards Track                     [Page 2]
RFC 4934                   EPP TCP Transport                    May 2007

   before the response can be returned to the client, the server MAY
   attempt to undo the effects of the command to ensure a consistent
   state between the client and the server.  EPP commands are
   idempotent, so processing a command more than once produces the same