draft-ietf-hip-rfc5203-bis-09.txt   draft-ietf-hip-rfc5203-bis-10.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5203 (if approved) L. Eggert Obsoletes: 5203 (if approved) L. Eggert
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: January 1, 2016 June 30, 2015 Expires: August 3, 2016 January 31, 2016
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-09 draft-ietf-hip-rfc5203-bis-10
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. This document such as HIP rendezvous servers or middleboxes. This document
obsoletes RFC5203. obsoletes RFC5203.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 1, 2016. This Internet-Draft will expire on August 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. HIP Registration Extension Overview . . . . . . . . . . . . . 3 3. HIP Registration Extension Overview . . . . . . . . . . . . . 3
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 . 4
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 . . . . . . . . . 11 5. Establishing and Maintaining Registrations . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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) [RFC7401]. The extension provides a generic means for a host (HIP) [RFC7401]. 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-rfc5204-bis] or a middlebox rendezvous server [I-D.ietf-hip-rfc5204-bis] or a middlebox
[RFC3234]. [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 44 skipping to change at page 3, line 44
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,
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
requested. Other documents will define parameters and how they shall requested. Other documents will define parameters and how they shall
be used. The following sections describe the differences between be used.
this registration handshake and the standard HIP base exchange
[RFC7401]. The HIP base exchange, including the definition of the HIP I1, R1,
I2, and R2 packets, is defined in RFC7401 [RFC7401]. The following
sections describe the differences between this registration handshake
and the standard HIP base exchange [RFC7401].
3.1. Registrar Announcing Its Ability 3.1. Registrar Announcing Its Ability
A host that is capable and willing to act as a registrar vis-a-vis a A host that is capable and willing to act as a registrar vis-a-vis a
specific requester SHOULD include a REG_INFO parameter in the R1 specific requester SHOULD include a REG_INFO parameter in the R1
packets it sends during all base exchanges with that requester. If packets it sends during all base exchanges with that requester. If
it is currently unable to provide services due to transient it is currently unable to provide services due to transient
conditions, it SHOULD include an empty REG_INFO, i.e., one with no conditions, it SHOULD include an empty REG_INFO, i.e., one with no
services listed. If services can be provided later, it SHOULD send services listed. If services can be provided later, it SHOULD send
UPDATE packets indicating the current set of services available in a UPDATE packets indicating the current set of services available in a
skipping to change at page 6, line 36 skipping to change at page 6, line 36
| |<---------------------| | | | |<---------------------| | |
+-----+ +-----+-----+ +-----+ +-----+-----+
A requester (RQ) registers for service (S) with a registrar (R) of A requester (RQ) registers for service (S) with a registrar (R) of
services (S), with which it currently has a HIP association services (S), with which it currently has a HIP association
established. 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. The
encoding of these new parameters is conforms to the HIPv2 TLV format
described in section 5.2.1 of RFC7401 [RFC7401].
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.
values ranging from 4 ms to 178 days into an 8-bit integer field.
The lifetime exponent field used throughout this document MUST be The special value 0 (zero) of the lifetime field MUST be interpreted
interpreted as representing the lifetime value 2^((lifetime - 64)/8) as representing a special lifetime duration of 0 (zero) seconds, and
seconds. is used to request and grant cancellation of a registration.
The non-zero values of the lifetime field used throughout this
document MUST be interpreted as an exponent value representing a
lifetime duration of 2^((lifetime - 64)/8) seconds.
This allows a compact encoding of 255 different lifetime durations
(in addition to the special lifetime duration of zero seconds)
ranging from 2^(63/8) seconds (i.e., ~4 ms) to 2^(191/8) seconds
(i.e., ~178 days) into an 8-bit integer field.
4.2. REG_INFO 4.2. REG_INFO
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +
| | | |
skipping to change at page 12, line 45 skipping to change at page 12, line 45
9. Acknowledgments 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, Ari improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari
Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
Lars Eggert has received funding from the European Union's Horizon Lars Eggert has received funding from the European Union's Horizon
2020 research and innovation program 2014-2018 under grant agreement 2020 research and innovation program 2014-2018 under grant agreement
No. 644866 ("SSICLOPS"). This document reflects only the authors' No. 644866. This document reflects only the authors' views and the
views and the European Commission is not responsible for any use that European Commission is not responsible for any use that may be made
may be made of the information it contains. of the information it contains.
Ari Keranen suggested inclusion of the text specifying requester Ari Keranen suggested inclusion of the text specifying requester
authorization based on certificates as a direct adaption of text authorization based on certificates as a direct adaption of text
found in HIP native NAT traversal specification found in HIP native NAT traversal specification
[I-D.ietf-hip-native-nat-traversal]. [I-D.ietf-hip-native-nat-traversal].
Thanks to Joel M. Halpern for performing the Gen-ART review of this
document as part of the publication process.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), June 2015. in progress), December 2015.
[I-D.ietf-hip-rfc6253-bis] [I-D.ietf-hip-rfc6253-bis]
Heer, T. and S. Varjonen, "Host Identity Protocol Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-02 (work in Certificates", draft-ietf-hip-rfc6253-bis-06 (work in
progress), June 2015. progress), December 2015.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
"Host Identity Protocol Version 2 (HIPv2)", RFC 7401, Henderson, "Host Identity Protocol Version 2 (HIPv2)",
April 2015. RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-hip-native-nat-traversal] [I-D.ietf-hip-native-nat-traversal]
Keranen, A. and J. Melen, "Native NAT Traversal Mode for Keranen, A. and J. Melen, "Native NAT Traversal Mode for
the Host Identity Protocol", draft-ietf-hip-native-nat- the Host Identity Protocol", draft-ietf-hip-native-nat-
traversal-08 (work in progress), January 2015. traversal-10 (work in progress), January 2016.
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-12 (work in Architecture", draft-ietf-hip-rfc4423-bis-13 (work in
progress), June 2015. progress), December 2015.
[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, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203, April Protocol (HIP) Registration Extension", RFC 5203,
2008. DOI 10.17487/RFC5203, April 2008,
<http://www.rfc-editor.org/info/rfc5203>.
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 o Added a new registration failure type for use in case of
insufficient resources available at the HIP registrar. insufficient resources available at the HIP registrar.
o Added requester authorization based on certificates, and new o Added requester authorization based on certificates, and new
registration failure type for invalid certificate. registration failure type for invalid certificate.
 End of changes. 21 change blocks. 
34 lines changed or deleted 58 lines changed or added

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