RFC 3319 (rfc3319) - Page 2 of 7


Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers



Alternative Format: Original Text Document



RFC 3319             DHCPv6 Options for SIP Servers            July 2003


   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [4].

2.  Introduction

   The Session Initiation Protocol (SIP) [2] is an application-layer
   control protocol that can establish, modify and terminate multimedia
   sessions or calls.  A SIP system has a number of logical components:
   user agents, proxy servers, redirect servers and registrars.  User
   agents MAY contain SIP clients, proxy servers always do.

   This document specifies two DHCPv6 options [1] that allow SIP clients
   to locate a local SIP server that is to be used for all outbound SIP
   requests, a so-called outbound proxy server.  (SIP clients MAY
   contact the address identified in the SIP URL directly, without
   involving a local SIP server.  However in some circumstances, such as
   when firewalls are present, or local dialing plans, local emergency
   and other services need to be provided, SIP clients need to use a
   local server for outbound requests.)  This is one of many possible
   solutions for locating the outbound SIP server; manual configuration
   is an example of another.

3.  SIP Server DHCPv6 Option

   This document defines two DHCPv6 options that describe a local
   outbound SIP proxy: one carries a list of domain names (Section 3.1),
   the other a list of 128-bit (binary) IPv6 addresses (Section 3.2).

      Since DHCPv6 does not suffer from a shortage of option codes, we
      avoid the encoding byte found in the IPv4 DHCP option for SIP
      servers [6].  This makes the option shorter, easier to parse,
      simplifies appropriate word alignment for the numeric addresses
      and allows the client to request either numeric or domain name
      options using the "option request option".

   An implementation implementing this specification MUST support both
   options.

3.1  SIP Servers Domain Name List

   The option length is followed by a sequence of labels, encoded
   according to Section 3.1 of RFC 1035 [5], quoted below:

      "Domain names in messages are expressed in terms of a sequence of
      labels.  Each label is represented as a one octet length field
      followed by that number of octets.  Since every domain name ends



Schulzrinne & Volz          Standards Track