draft-ietf-hip-rfc5203-bis-00.txt   draft-ietf-hip-rfc5203-bis-01.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft QUALCOMM Inc. Internet-Draft Juniper Networks
Obsoletes: 5203 (if approved) T. Koponen Obsoletes: 5203 (if approved) T. Koponen
Intended status: Standards Track HIIT Intended status: Standards Track HIIT
Expires: February 21, 2011 L. Eggert Expires: September 15, 2011 L. Eggert
Nokia Nokia
August 20, 2010 March 14, 2011
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-00 draft-ietf-hip-rfc5203-bis-01
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 21, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HIP Registration Extension Overview . . . . . . . . . . . . . 4
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . . 6
4.1. Encoding Registration Lifetimes with Exponents . . . . . . 6
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Establishing and Maintaining Registrations . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . . 12
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) [RFC5201]. The extension provides a generic means for a host (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic
to register with a service. The service may, for example, be a HIP means for a host to register with a service. The service may, for
rendezvous server [RFC5204] or a middlebox [RFC3234]. example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
In addition to the terminology defined in the HIP Architecture In addition to the terminology defined in the HIP Architecture
[RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous [RFC4423], the HIP specification [I-D.ietf-hip-rfc5201-bis], and the
Extension [RFC5204], this document defines and uses the following HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document
terms: 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 25 skipping to change at page 4, line 20
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,
which the remainder of this document defines, to announce their which the remainder of this document defines, to announce their
quality and grant or refuse registration. Requesters use quality and grant or refuse registration. Requesters use
corresponding parameters to register with the service. Both the corresponding parameters to register with the service. Both the
registrar and the requester MAY also include in the messages registrar and the requester MAY also include in the messages
exchanged additional HIP parameters specific to the registration type exchanged additional HIP parameters specific to the registration type
implicated. Other documents will define parameters and how they implicated. Other documents will define parameters and how they
shall be used. The following sections describe the differences shall be used. The following sections describe the differences
between this registration handshake and the standard HIP base between this registration handshake and the standard HIP base
exchange [RFC5201]. exchange [I-D.ietf-hip-rfc5201-bis].
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
skipping to change at page 11, line 25 skipping to change at page 12, line 16
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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
Requirement Levels", BCP 14, RFC 2119, March 1997. T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in
progress), March 2011.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Identity Protocol (HIP) Rendezvous
October 1998. Extension", draft-ietf-hip-rfc5204-bis-00
(work in progress), August 2010.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC2119] Bradner, S., "Key words for use in RFCs
Henderson, "Host Identity Protocol", RFC 5201, April 2008. to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines
for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 2434,
October 1998.
9.2. Informative References 9.2. Informative References
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes:
Issues", RFC 3234, February 2002. Taxonomy and Issues", RFC 3234,
February 2002.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host
(HIP) Architecture", RFC 4423, May 2006. Identity Protocol (HIP) Architecture",
RFC 4423, May 2006.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Appendix A. Changes from RFC 5203
Rendezvous Extension", RFC 5204, April 2008.
o Updated references to revised HIP specifications.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
QUALCOMM Incorporated Juniper Networks
5775 Morehouse Drive 1094 North Mathilda Avenue
San Diego, CA 92121 San Diego, CA 94089
USA USA
Phone: +1 858 858 3538 Phone: +1 408 936 0385
EMail: julienl@qualcomm.com EMail: julien.ietf@gmail.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@iki.fi EMail: teemu.koponen@iki.fi
 End of changes. 18 change blocks. 
31 lines changed or deleted 68 lines changed or added

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