Host Identity Protocol (HIP) Registration Extension
RFC 5203
|
| Document |
Type |
|
RFC - Experimental
(April 2008; 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 5203 (Experimental)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Mark Townsley
|
|
Send notices to |
|
(None)
|
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
Show full document text