draft-ietf-hip-rfc5203-bis-01.txt   draft-ietf-hip-rfc5203-bis-02.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Obsoletes: 5203 (if approved) T. Koponen Obsoletes: 5203 (if approved) L. Eggert
Intended status: Standards Track HIIT Intended status: Standards Track NetApp
Expires: September 15, 2011 L. Eggert Expires: March 26, 2013 September 22, 2012
Nokia
March 14, 2011
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-01 draft-ietf-hip-rfc5203-bis-02
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 33
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 September 15, 2011. This Internet-Draft will expire on March 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HIP Registration Extension Overview . . . . . . . . . . . . . 4 3. HIP Registration Extension Overview . . . . . . . . . . . . . 4
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . . 4 3.1. Registrar Announcing Its Ability . . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4 3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . . 4 3.3. Registrar Granting or Refusing Service(s) Registration . . 5
4. Parameter Formats and Processing . . . . . . . . . . . . . . . 6 4. Parameter Formats and Processing . . . . . . . . . . . . . . . 6
4.1. Encoding Registration Lifetimes with Exponents . . . . . . 6 4.1. Encoding Registration Lifetimes with Exponents . . . . . . 6
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Establishing and Maintaining Registrations . . . . . . . . . . 10 5. Establishing and Maintaining Registrations . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . . 13
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) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic
means for a host to register with a service. The service may, for means for a host to register with a service. The service may, for
example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a
middlebox [RFC3234]. middlebox [RFC3234].
This document makes no further assumptions about the exact type of This document makes no further assumptions about the exact type of
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 [I-D.ietf-hip-rfc5201-bis], and the [I-D.ietf-hip-rfc4423-bis], the HIP specification
HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document [I-D.ietf-hip-rfc5201-bis], and the HIP Rendezvous Extension
defines and uses the following terms: [I-D.ietf-hip-rfc5204-bis], 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 9, line 29 skipping to change at page 9, line 43
Type 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.
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 Unassigned 3 Insufficient resources
3-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. Other documents will define specific values for registration types.
See Section 7 for more information. 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. Failure types other than zero (0) and one (1) have not registrar. Failure types other than zero (0) and one (1) have not
skipping to change at page 11, line 45 skipping to change at page 12, line 9
Adding a new type requires new IETF specifications. Adding a new type requires new IETF specifications.
IANA has opened a new registry for registration failure types. This IANA has opened a new registry for registration failure types. This
document makes the following failure type 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
3 Insufficient resources
2-200 Unassigned 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. Contributors
Teemu Koponen co-authored an earlier, experimental version of this
specification [RFC5203].
9. 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, Ari
Pekka Nikander, and Hannes Tschofenig. Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
T. Henderson, "Host Identity Protocol T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)", Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in draft-ietf-hip-rfc5201-bis-09 (work in
progress), March 2011. progress), July 2012.
[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
Identity Protocol (HIP) Rendezvous Identity Protocol (HIP) Rendezvous
Extension", draft-ietf-hip-rfc5204-bis-00 Extension", draft-ietf-hip-rfc5204-bis-01
(work in progress), August 2010. (work in progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines [RFC2434] Narten, T. and H. Alvestrand, "Guidelines
for Writing an IANA Considerations for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 2434, Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
9.2. Informative References 10.2. Informative References
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Architecture",
draft-ietf-hip-rfc4423-bis-04 (work in
progress), July 2012.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: [RFC3234] Carpenter, B. and S. Brim, "Middleboxes:
Taxonomy and Issues", RFC 3234, Taxonomy and Issues", RFC 3234,
February 2002. February 2002.
[RFC4423] Moskowitz, R. and P. Nikander, "Host [RFC5203] Laganier, J., Koponen, T., and L. Eggert,
Identity Protocol (HIP) Architecture", "Host Identity Protocol (HIP)
RFC 4423, May 2006. Registration Extension", RFC 5203,
April 2008.
Appendix A. Changes from RFC 5203 Appendix A. Changes from RFC 5203
o Updated references to revised HIP specifications. o Updated references to revised HIP specifications.
o Added a new registration failure type for use in case of
insufficient resources available at the HIP registrar.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Juniper Networks
1094 North Mathilda Avenue 1094 North Mathilda Avenue
San Diego, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385 Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Teemu Koponen
Helsinki Institute for Information Technology
Advanced Research Unit (ARU)
P.O. Box 9800
Helsinki FIN-02015-HUT
Finland
Phone: +358 9 45 1
EMail: teemu.koponen@iki.fi
URI: http://www.hiit.fi/
Lars Eggert Lars Eggert
Nokia Research Center NetApp
P.O. Box 407 Sonnenallee 1
Nokia Group 00045 Kirchheim 85551
Finland Germany
Phone: +358 50 48 24461 Phone: +49 151 12055791
EMail: lars.eggert@nokia.com EMail: lars@netapp.com
URI: http://research.nokia.com/people/lars_eggert/ URI: http://eggert.org
 End of changes. 23 change blocks. 
48 lines changed or deleted 53 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/