draft-ietf-hip-registration-02.txt   rfc5203.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Request for Comments: 5203 DoCoMo Euro-Labs
Expires: December 9, 2006 T. Koponen Category: Experimental T. Koponen
HIIT HIIT
L. Eggert L. Eggert
NEC Nokia
June 7, 2006
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-registration-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). 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 Abstract
This document specifies a registration mechanism for the Host This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services, Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes. such as HIP rendezvous servers or middleboxes.
1. Introduction 1. Introduction
This document specifies an extension to the Host Identity Protocol This document specifies an extension to the Host Identity Protocol
(HIP) [RFC4423]. The extension provides a generic means for a host (HIP) [RFC5201]. The extension provides a generic means for a host
to register with a service. The service may, for example, be a HIP to register with a service. The service may, for example, be a HIP
rendezvous server [I-D.ietf-hip-rvs] or a middlebox [RFC3234]. rendezvous server [RFC5204] or a middlebox [RFC3234].
This document makes no further assumptions about the exact type of This document makes no further assumptions about the exact type of
service. Likewise, this document does not specify any mechanisms to service. Likewise, this document does not specify any mechanisms to
discover the presence of specific services or means to interact with discover the presence of specific services or means to interact with
them after registration. Future documents may describe those them after registration. Future documents may describe those
operations. operations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
This section defines terminology that is used throughout the In addition to the terminology defined in the HIP Architecture
remainder of this document. Please note that terminology shared with [RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous
other documents is defined elsewhere [RFC4423]. Extension [RFC5204], this document defines and uses the following
terms:
Requester: Requester:
a HIP node registering with a HIP registrar to request a HIP node registering with a HIP registrar to request
registration for a service. registration for a service.
Registrar: Registrar:
a HIP node offering registration for one or more services. a HIP node offering registration for one or more services.
Service: Service:
a facility that provides requesters with new capabilities or a facility that provides requesters with new capabilities or
skipping to change at page 3, line 11 skipping to change at page 2, line 42
an identifier for a given service in the registration protocol. an identifier for a given service in the registration protocol.
For example, the rendezvous service is identified by a specific For example, the rendezvous service is identified by a specific
registration type. registration type.
3. HIP Registration Extension Overview 3. HIP Registration Extension Overview
This document does not specify the means by which a requester This document does not specify the means by which a requester
discovers the availability of a service, or how a requester locates a discovers the availability of a service, or how a requester locates a
registrar. After a requester has discovered a registrar, it either registrar. After a requester has discovered a registrar, it either
initiates HIP base exchange or uses an existing HIP association with initiates HIP base exchange or uses an existing HIP association with
the registrar. In both cases, registrars use additional parameters the registrar. In both cases, registrars use additional parameters,
that the remainder of this document defines to announce their quality which the remainder of this document defines, to announce their
and grant or refuse registration. Requesters use corresponding quality and grant or refuse registration. Requesters use
parameters to register with the service. Both the registrar and the corresponding parameters to register with the service. Both the
requester MAY also include in the messages exchanged additional HIP registrar and the requester MAY also include in the messages
parameters specific to the registration type implicated. Other exchanged additional HIP parameters specific to the registration type
documents will define parameters and how they shall be used. The implicated. Other documents will define parameters and how they
following sections describe the differences between this registration shall be used. The following sections describe the differences
handshake and the standard HIP base exchange [I-D.ietf-hip-base] . between this registration handshake and the standard HIP base
exchange [RFC5201].
3.1. Registrar Announcing its Ability 3.1. Registrar Announcing Its Ability
A host that is capable and willing to act as a registrar SHOULD 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 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 base exchanges. If it is currently unable to provide services due to
transient conditions, it SHOULD include an empty REG_INFO, i.e., one transient conditions, it SHOULD include an empty REG_INFO, i.e., one
with no services listed. If services can be provided later, it with no services listed. If services can be provided later, it
SHOULD send UPDATE packets indicating the current set of services SHOULD send UPDATE packets indicating the current set of services
available in a new REG_INFO parameter to all hosts it is associated available in a new REG_INFO parameter to all hosts it is associated
with. with.
3.2. Requester Requesting Registration 3.2. Requester Requesting Registration
To request registration with a service, a requester constructs and To request registration with a service, a requester constructs and
includes a corresponding REG_REQUEST parameter in an I2 or UPDATE includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
packet it sends to the registrar. packet it sends to the registrar.
If the requester has no HIP association established with the If the requester has no HIP association established with the
registrar, it SHOULD already send the REG_REQUEST in the I2 packet. registrar, it SHOULD send the REG_REQUEST at the earliest
This minimizes the number of packets that need to be exchanged with possibility, i.e., in the I2 packet. This minimizes the number of
the registrar. A registrar MAY end a HIP association that does not packets that need to be exchanged with the registrar. A registrar
carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED MAY end a HIP association that does not carry a REG_REQUEST by
in the R2. In this case, no HIP association is created between the including a NOTIFY with the type REG_REQUIRED in the R2. In this
hosts. The REG_REQUIRED notification error type is TBD. case, no HIP association is created between the hosts. The
REG_REQUIRED notification error type is 51.
3.3. Registrar Granting or Refusing Service(s) Registration 3.3. Registrar Granting or Refusing Service(s) Registration
Once registration has been requested, the registrar is able to Once registration has been requested, the registrar is able to
authenticate the requester based on the host identity included in I2. authenticate the requester based on the host identity included in I2.
It then verifies the host identity is authorized to register with the It then verifies that the host identity is authorized to register
requested service(s), based on local policies. The details of this with the requested service(s), based on local policies. The details
authorization procedure depend on the type of requested service(s) of this authorization procedure depend on the type of requested
and on the local policies of the registrar, and are therefore not service(s) and on the local policies of the registrar, and are
further specified in this document. therefore not further specified in this document.
After authorization, the registrar includes in its response (i.e., an After authorization, the registrar includes a REG_RESPONSE parameter
R2 or an UPDATE, respectively, depending on whether the registration in its response, which contains the service type(s) for which it has
was requested during the base exchange, or using an existing authorized registration, and zero or more REG_FAILED parameters
association) a REG_RESPONSE parameter containing the service(s) containing the service type(s) for which it has not authorized
type(s) for which it has authorized registration, and zero or more registration or registration has failed for other reasons. This
REG_FAILED parameter containing the service(s) type(s) for which it response can be either an R2 or an UPDATE message, respectively,
has not authorized registration or registration has failed for other depending on whether the registration was requested during the base
reasons. In particular, REG_FAILED with a failure type of zero exchange, or using an existing association. In particular,
indicates the service(s) type(s) that require further credentials for REG_FAILED with a failure type of zero indicates the service(s)
registration. type(s) that require further credentials for registration.
If the registrar requires further authorization and the requester has If the registrar requires further authorization and the requester has
additional credentials available, the requester SHOULD try to again additional credentials available, the requester SHOULD try to
register with the service after the HIP association has been register again with the service after the HIP association has been
established. The precise means of establishing and verifying established. The precise means of establishing and verifying
credentials are beyond the scope of this document and are expected to credentials are beyond the scope of this document and are expected to
be defined in other documents. be defined in other documents.
Successful processing of a REG_RESPONSE parameter creates Successful processing of a REG_RESPONSE parameter creates
registration state at the requester. In a similar manner, successful registration state at the requester. In a similar manner, successful
processing of a REG_REQUEST parameter creates registration state at processing of a REG_REQUEST parameter creates registration state at
the registrar and possibly at the service. Both the requester and the registrar and possibly at the service. Both the requester and
registrar can cancel a registration before it expires, if the registrar can cancel a registration before it expires, if the
services afforded by a registration are no longer needed by the services afforded by a registration are no longer needed by the
skipping to change at page 5, line 4 skipping to change at page 4, line 31
+-----+ I1 +-----+-----+ +-----+ I1 +-----+-----+
| |--------------------->| | S1 | | |--------------------->| | S1 |
| |<---------------------| | | | |<---------------------| | |
| | R1(REG_INFO:S1,S2) | +-----+ | | R1(REG_INFO:S1,S2) | +-----+
| RQ | | R | S2 | | RQ | | R | S2 |
| | I2(REG_REQ:S1) | | | | | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+ | |--------------------->| +-----+
| |<---------------------| | S3 | | |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | | | | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+ +-----+ +-----+-----+
A requester (RQ) registers with a registrar (R) of services (S1) and
(S2), with which it has no current HIP association.
+-----+ +-----+-----+ +-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | | | | UPDATE(REG_INFO:S) | | |
| |<---------------------| | | | |<---------------------| | |
| RQ |--------------------->| R | S | | RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | | | | UPDATE(REG_RESP:S) | | |
| |<---------------------| | | | |<---------------------| | |
+-----+ +-----+-----+ +-----+ +-----+-----+
A requester (RQ) registers with a registrar (R) of services (S), with
which it currently has a HIP association established.
4. Parameter Formats and Processing 4. Parameter Formats and Processing
This section describes the format and processing of the new This section describes the format and processing of the new
parameters introduced by the HIP registration extension. parameters introduced by the HIP registration extension.
4.1. Encoding Registration Lifetimes with Exponents 4.1. Encoding Registration Lifetimes with Exponents
The HIP registration uses an exponential encoding of registration The HIP registration uses an exponential encoding of registration
lifetimes. This allows compact encoding of 255 different lifetime lifetimes. This allows compact encoding of 255 different lifetime
values ranging from 4 ms to 178 days into an 8-bit integer field. values ranging from 4 ms to 178 days into an 8-bit integer field.
skipping to change at page 6, line 19 skipping to change at page 5, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (930) ] Type 930
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Min Lifetime Minimum registration lifetime. Min Lifetime Minimum registration lifetime.
Max Lifetime Maximum registration lifetime. Max Lifetime Maximum registration lifetime.
Reg Type The registration types offered by the registrar. Reg Type The registration types offered by the registrar.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information.
Reg Type Service
-------- -------
0-200 Reserved by IANA
201-255 Reserved by IANA for private use
Registrars include the parameter in R1 packets in order to announce Registrars include the parameter in R1 packets in order to announce
their registration capabilities. The registrar SHOULD include the their registration capabilities. The registrar SHOULD include the
parameter in UPDATE packets when its service offering has changed. parameter in UPDATE packets when its service offering has changed.
HIP_SIGNATURE_2 protects the parameter within the R1 packets. HIP_SIGNATURE_2 protects the parameter within the R1 packets.
4.3. REG_REQUEST 4.3. REG_REQUEST
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (932) ] Type 932
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Lifetime Requested registration lifetime. Lifetime Requested registration lifetime.
Reg Type The preferred registration types in order of preference. Reg Type The preferred registration types in order of preference.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information.
Reg Type Service
-------- -------
0-200 Reserved by IANA
201-255 Reserved by IANA for private use
A requester includes the REG_REQUEST parameter in I2 or UPDATE A requester includes the REG_REQUEST parameter in I2 or UPDATE
packets to register with a registrar's service(s). If the packets to register with a registrar's service(s). If the
REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT
modify the registrations of registration types which are not listed modify the registrations of registration types that are not listed in
in the parameter. Moreover, the requester MUST NOT include the the parameter. Moreover, the requester MUST NOT include the
parameter unless the registrar's R1 packet or latest received UPDATE parameter unless the registrar's R1 packet or latest received UPDATE
packet has contained a REG_INFO parameter with the requested packet has contained a REG_INFO parameter with the requested
registration types. registration types.
The requester MUST NOT include more than one REG_REQUEST parameter in The requester MUST NOT include more than one REG_REQUEST parameter in
its I2 or UPDATE packets, while the registrar MUST be able to process its I2 or UPDATE packets, while the registrar MUST be able to process
one or more REG_REQUEST parameters in received I2 or UPDATE packets. one or more REG_REQUEST parameters in received I2 or UPDATE packets.
When the registrar is requested a registration which lifetime is When the registrar receives a registration with a lifetime that is
either smaller or greater than the minimum or maximum lifetime, either smaller or greater than the minimum or maximum lifetime,
respectively, then it SHOULD grant the registration for the minimum respectively, then it SHOULD grant the registration for the minimum
or maximum lifetime, respectively. or maximum lifetime, respectively.
HIP_SIGNATURE protects the parameter within the I2 and UPDATE HIP_SIGNATURE protects the parameter within the I2 and UPDATE
packets. packets.
4.4. REG_RESPONSE 4.4. REG_RESPONSE
0 1 2 3 0 1 2 3
skipping to change at page 8, line 19 skipping to change at page 7, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (934) ] Type 934
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Lifetime Granted registration lifetime. Lifetime Granted registration lifetime.
Reg Type The granted registration types in order of preference. Reg Type The granted registration types in order of preference.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information.
Reg Type Service
-------- -------
0-200 Reserved by IANA
201-255 Reserved by IANA for private use
The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or
UPDATE packet only if a registration has successfully completed. UPDATE packet only if a registration has successfully completed.
The registrar MUST NOT include more than one REG_RESPONSE parameter The registrar MUST NOT include more than one REG_RESPONSE parameter
in its R2 or UPDATE packets, while the requester MUST be able to in its R2 or UPDATE packets, while the requester MUST be able to
process one or more REG_RESPONSE parameters in received R2 or UPDATE process one or more REG_RESPONSE parameters in received R2 or UPDATE
packets. packets.
The requester MUST be prepared to receive any registration lifetime, The requester MUST be prepared to receive any registration lifetime,
included ones beyond the minimum and maximum lifetime indicated in including ones beyond the minimum and maximum lifetime indicated in
the REG_INFO parameter. It MUST NOT expect that the returned the REG_INFO parameter. It MUST NOT expect that the returned
lifetime will be the requested one, even in the case that the lifetime will be the requested one, even when the requested lifetime
requested lifetime falls within the announced minimum and maximum. falls within the announced minimum and maximum.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
4.5. REG_FAILED 4.5. REG_FAILED
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (936) ] Type 936
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Failure Type Reason for failure. Failure Type Reason for failure.
Reg Type The registration types that failed with the specified Reg Type The registration types that failed with the specified
reason. reason.
Other documents will define specific values for registration types.
Reg Type Service
-------- -------
0-200 Reserved by IANA
201-255 Reserved by IANA for private use
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
2-200 Reserved by IANA 2-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Other documents will define specific values for registration types.
See Section 7 for more information.
A failure type of zero means a registrar requires additional A failure type of zero means a registrar requires additional
credentials to authorize a requester to register with the credentials to authorize a requester to register with the
registration types listed in the parameter. A failure type of one registration types listed in the parameter. A failure type of one
means that the requested service type is unavailable at the means that the requested service type is unavailable at the
registrar. Other failure types than zero (0) and one (1) have not registrar. Failure types other than zero (0) and one (1) have not
been defined. been defined.
The registrar SHOULD include the REG_FAILED parameter in its R2 or The registrar SHOULD include the REG_FAILED parameter in its R2 or
UPDATE packet, if registration with the registration types listed has UPDATE packet, if registration with the registration types listed has
not completed successfully and a requester is asked to try again with not completed successfully and a requester is asked to try again with
additional credentials. additional credentials.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
skipping to change at page 10, line 18 skipping to change at page 9, line 18
information not available in the transmitted REG_REQUEST or information not available in the transmitted REG_REQUEST or
REG_RESPONSE parameters. Therefore, registration type definitions REG_RESPONSE parameters. Therefore, registration type definitions
MAY define dependencies for HIP parameters that are not defined in MAY define dependencies for HIP parameters that are not defined in
this document. Their semantics are subject to the specific this document. Their semantics are subject to the specific
registration type specifications. registration type specifications.
The minimum lifetime both registrars and requesters MUST support is The minimum lifetime both registrars and requesters MUST support is
10 seconds, while they SHOULD support a maximum lifetime of 120 10 seconds, while they SHOULD support a maximum lifetime of 120
seconds, at least. These values define a baseline for the seconds, at least. These values define a baseline for the
specification of services based on the registration system. They specification of services based on the registration system. They
were chosen to be neither to short nor too long, and to accommodate were chosen to be neither too short nor too long, and to accommodate
for existing timeouts of state established in middleboxes (e.g. NATs for existing timeouts of state established in middleboxes (e.g., NATs
and firewalls.) and firewalls.)
A zero lifetime is reserved for canceling purposes. Requesting a A zero lifetime is reserved for canceling purposes. Requesting a
zero lifetime for a registration type equals to canceling the zero lifetime for a registration type is equal to canceling the
registration of that type. A requester MAY cancel a registration registration of that type. A requester MAY cancel a registration
before it expires by sending a REG_REQ to the registrar with a zero before it expires by sending a REG_REQ to the registrar with a zero
lifetime. A registrar SHOULD respond and grant a registration with a lifetime. A registrar SHOULD respond and grant a registration with a
zero lifetime. A registrar (and an attached service) MAY cancel a zero lifetime. A registrar (and an attached service) MAY cancel a
registration before it expires, at its own discretion. However, if registration before it expires, at its own discretion. However, if
it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
registered requesters. registered requesters.
6. Security Considerations 6. Security Considerations
This section discusses the threats on the HIP registration protocol, This section discusses the threats on the HIP registration protocol,
and their implications on the overall security of HIP. In and their implications on the overall security of HIP. In
particular, it argues that the extensions described in this document particular, it argues that the extensions described in this document
do not introduce additional threats to HIP. do not introduce additional threats to HIP.
The extensions described in this document rely on the HIP base The extensions described in this document rely on the HIP base
exchange and do not modify its security characteristics, e.g., exchange and do not modify its security characteristics, e.g.,
digital signatures or HMAC. Hence, the only threat introduced by digital signatures or HMAC. Hence, the only threat introduced by
these extensions are related to the creation of soft registration these extensions is related to the creation of soft registration
state at the registrar. state at the registrar.
Registrars act on a voluntary basis and are willing to accept to be a Registrars act on a voluntary basis and are willing to accept being a
responder and to then create HIP associations with a number of responder and then to create HIP associations with a number of
previously unknown hosts. Because they have to store HIP association previously unknown hosts. Because they have to store HIP association
state anyway, adding a certain amount of time-limited HIP state anyway, adding a certain amount of time-limited HIP
registration state should not introduce and serious additional registration state should not introduce any serious additional
threats, especially because HIP registrars may cancel registrations threats, especially because HIP registrars may cancel registrations
at any time at their own discretion, e.g., because of resource at any time at their own discretion, e.g., because of resource
constraints during an attack. constraints during an attack.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to the Guidelines for
Writing an IANA Considerations Section in RFCs [RFC2434].
This document updates the IANA Registry for HIP Parameters Types by This document updates the IANA Registry for HIP Parameter Types by
assigning new HIP Parameter Types values for the new HIP Parameters assigning new HIP Parameter Types values for the new HIP Parameters
defined in this document: defined in this document:
o REG_INFO (defined in Section 4.2) o REG_INFO (defined in Section 4.2)
o REG_REQUEST (defined in Section 4.3) o REG_REQUEST (defined in Section 4.3)
o REG_RESPONSE (defined in Section 4.4) o REG_RESPONSE (defined in Section 4.4)
o REG_FAILED (defined in Section 4.5) o REG_FAILED (defined in Section 4.5)
IANA needs to open a new registry for registration types. This IANA has allocated the Notify Message Type code 51 for the
document does not define registration types but makes the following REG_REQUIRED notification error type in the Notify Message Type
registry.
IANA has opened a new registry for registration types. This document
does not define registration types but makes the following
reservations: reservations:
Reg Type Service Reg Type Service
-------- ------- -------- -------
0-200 Reserved by IANA 0-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications. Adding a new type requires new IETF specifications.
IANA needs to open a new registry for registration failure types. IANA has opened a new registry for registration failure types. This
This document makes the following failure types definitions and document makes the following failure type definitions and
reservations: reservations:
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
2-200 Reserved by IANA 2-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications. Adding a new type requires new IETF specifications.
8. Acknowledgments 8. Acknowledgments
The following people (in alphabetical order) have provided thoughtful The following people (in alphabetical order) have provided thoughtful
and helpful discussions and/or suggestions that have helped to and helpful discussions and/or suggestions that have helped to
improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa,
Pekka Nikander and Hannes Tschofenig. Pekka Nikander, and Hannes Tschofenig.
Julien Laganier and Lars Eggert are partly funded by Ambient
Networks, a research project supported by the European Commission
under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-05 (work in progress), March 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
9.2. Informative References [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[I-D.ietf-hip-rvs] 9.2. Informative References
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
progress), October 2005.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
DoCoMo Communications Laboratories Europe GmbH DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312 Landsberger Strasse 312
Munich 80687 Munich 80687
Germany Germany
Phone: +49 89 56824 231 Phone: +49 89 56824 231
Email: julien.ietf@laposte.net EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/ URI: http://www.docomolab-euro.com/
Teemu Koponen Teemu Koponen
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Advanced Research Unit (ARU) Advanced Research Unit (ARU)
P.O. Box 9800 P.O. Box 9800
Helsinki FIN-02015-HUT Helsinki FIN-02015-HUT
Finland Finland
Phone: +358 9 45 1 Phone: +358 9 45 1
Email: teemu.koponen@hiit.fi EMail: teemu.koponen@iki.fi
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 6221 90511 43 Phone: +358 50 48 24461
Fax: +49 6221 90511 55 EMail: lars.eggert@nokia.com
Email: lars.eggert@netlab.nec.de URI: http://research.nokia.com/people/lars_eggert/
URI: http://www.netlab.nec.de/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 28 skipping to change at line 544
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 54 change blocks. 
150 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/