Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers
RFC 3361

Document Type RFC - Proposed Standard (August 2002; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3361 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note Published as RFC 3361 - a long road to a quiet end.
[note from Allison]
Responsible: Finished
Send notices to <rohan@cisco.com>
Network Working Group                                     H. Schulzrinne
Request for Comments: 3361                           Columbia University
Category: Standards Track                                    August 2002

          Dynamic Host Configuration Protocol (DHCP-for-IPv4)
          Option for Session Initiation Protocol (SIP) Servers

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 Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a Dynamic Host Configuration Protocol
   (DHCP-for-IPv4) option that contains a list of domain names or IPv4
   addresses that can be mapped to one or more Session Initiation
   Protocol (SIP) outbound proxy servers.  This is one of the many
   methods that a SIP client can use to obtain the addresses of such a
   local SIP server.

1.  Terminology

        DHCP client: A DHCP [1] client is an Internet host that uses
             DHCP to obtain configuration parameters such as a network
             address.

        DHCP server: A DHCP server is an Internet host that returns
             configuration parameters to DHCP clients.

        SIP server: As defined in RFC 3261 [2].  This server MUST be an
            outbound proxy server, as defined in [3].  In the context of
            this document, a SIP server refers to the host the SIP
            server is running on.

        SIP client: As defined in RFC 3261.  The client can be a user
            agent client or the client portion of a proxy server.  In
            the context of this document, a SIP client refers to the
            host the SIP client is running on.

Schulzrinne                 Standards Track                     [Page 1]
RFC 3361             DHCPv4 Option for SIP Servers           August 2002

   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 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 a DHCP option [1,5] that allows 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, for
   example, when firewalls are present, 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 DHCP Option

   The SIP server DHCP option carries either a 32-bit (binary) IPv4
   address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain
   name to be used by the SIP client to locate a SIP server.

   The option has two encodings, specified by the encoding byte ('enc')
   that follows the code byte.  If the encoding byte has the value 0, it
   is followed by a list of domain names, as described below (Section
   3.1).  If the encoding byte has the value 1, it is followed by one or
   more IPv4 addresses (Section 3.2).  All implementations MUST support
   both encodings.  The 'Len' field indicates the total number of octets
   in the option following the 'Len' field, including the encoding byte.

   A DHCP server MUST NOT mix the two encodings in the same DHCP
   message, even if it sends two different instances of the same option.
   Attempts to do so would result in incorrect client behavior as DHCP
   processing rules call for the concatenation of multiple instances of
   an option into a single option prior to processing the option [7].

   The code for this option is 120.

Schulzrinne                 Standards Track                     [Page 2]
RFC 3361             DHCPv4 Option for SIP Servers           August 2002

3.1 Domain Name List

   If the 'enc' byte has a value of 0, the encoding byte is followed by
   a sequence of labels, encoded according to Section 3.1 of RFC 1035
   [6], 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 with the null label of the root, a domain name is
Show full document text