Host Identity Protocol (HIP) Registration Extension
RFC 5203

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

• Versions
• 02

Network Working Group                                        J. Laganier
Request for Comments: 5203                              DoCoMo Euro-Labs
Category: Experimental                                        T. Koponen
                                                                    HIIT
                                                               L. Eggert
                                                                   Nokia
                                                              April 2008

          Host Identity Protocol (HIP) Registration Extension

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document specifies a registration mechanism for the Host
   Identity Protocol (HIP) that allows hosts to register with services,
   such as HIP rendezvous servers or middleboxes.

1.  Introduction

   This document specifies an extension to the Host Identity Protocol
   (HIP) [RFC5201].  The extension provides a generic means for a host
   to register with a service.  The service may, for example, be a HIP
   rendezvous server [RFC5204] or a middlebox [RFC3234].

   This document makes no further assumptions about the exact type of
   service.  Likewise, this document does not specify any mechanisms to
   discover the presence of specific services or means to interact with
   them after registration.  Future documents may describe those
   operations.

   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 RFC 2119 [RFC2119].

Laganier, et al.              Experimental                      [Page 1]
RFC 5203               HIP Registration Extension             April 2008

2.  Terminology

   In addition to the terminology defined in the HIP Architecture
   [RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous
   Extension [RFC5204], this document defines and uses the following
   terms:

   Requester:
      a HIP node registering with a HIP registrar to request
      registration for a service.

   Registrar:
      a HIP node offering registration for one or more services.

   Service:
      a facility that provides requesters with new capabilities or
      functionalities operating at the HIP layer.  Examples include
      firewalls that support HIP traversal or HIP rendezvous servers.

   Registration:
      shared state stored by a requester and a registrar, allowing the
      requester to benefit from one or more HIP services offered by the
      registrar.  Each registration has an associated finite lifetime.
      Requesters can extend established registrations through re-
      registration (i.e., perform a refresh).

   Registration Type:
      an identifier for a given service in the registration protocol.
      For example, the rendezvous service is identified by a specific
      registration type.

3.  HIP Registration Extension Overview

   This document does not specify the means by which a requester
   discovers the availability of a service, or how a requester locates a
   registrar.  After a requester has discovered a registrar, it either
   initiates HIP base exchange or uses an existing HIP association with
   the registrar.  In both cases, registrars use additional parameters,
   which the remainder of this document defines, to announce their
   quality and grant or refuse registration.  Requesters use
   corresponding parameters to register with the service.  Both the
   registrar and the requester MAY also include in the messages
   exchanged additional HIP parameters specific to the registration type
   implicated.  Other documents will define parameters and how they
   shall be used.  The following sections describe the differences
   between this registration handshake and the standard HIP base
   exchange [RFC5201].

Laganier, et al.              Experimental                      [Page 2]
RFC 5203               HIP Registration Extension             April 2008

3.1.  Registrar Announcing Its Ability

   A host that is capable and willing to act as a registrar SHOULD
   include a REG_INFO parameter in the R1 packets it sends during all
   base exchanges.  If it is currently unable to provide services due to
   transient conditions, it SHOULD include an empty REG_INFO, i.e., one
   with no services listed.  If services can be provided later, it
   SHOULD send UPDATE packets indicating the current set of services
   available in a new REG_INFO parameter to all hosts it is associated
   with.

3.2.  Requester Requesting Registration

   To request registration with a service, a requester constructs and
   includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
   packet it sends to the registrar.