draft-ietf-hip-rfc5203-bis-08.txt   draft-ietf-hip-rfc5203-bis-09.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: December 12, 2015 June 10, 2015 Expires: January 1, 2016 June 30, 2015
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-08 draft-ietf-hip-rfc5203-bis-09
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 December 12, 2015. This Internet-Draft will expire on January 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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) [RFC7401]. The extension provides a generic means for a host
means for a host to register with a service. The service may, for to register with a service. The service may, for example, be a HIP
example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a rendezvous server [I-D.ietf-hip-rfc5204-bis] or a middlebox
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
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
[I-D.ietf-hip-rfc4423-bis], the HIP specification [I-D.ietf-hip-rfc4423-bis], the HIP specification [RFC7401], and the
[I-D.ietf-hip-rfc5201-bis], and the HIP Rendezvous Extension HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document
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 3, line 47 skipping to change at page 3, line 46
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. The following sections describe the differences between
this registration handshake and the standard HIP base exchange this registration handshake and the standard HIP base exchange
[I-D.ietf-hip-rfc5201-bis]. [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 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. This document reflects only the authors' views and the No. 644866 ("SSICLOPS"). This document reflects only the authors'
European Commission is not responsible for any use that may be made views and the European Commission is not responsible for any use that
of the information it contains. may be made 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].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-20 (work in progress), October 2014.
[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-05 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work
in progress), December 2014. in progress), June 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-01 (work in Certificates", draft-ietf-hip-rfc6253-bis-02 (work in
progress), October 2013. progress), June 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, March 1997.
[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. May 2008.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", RFC 7401,
April 2015.
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-08 (work in progress), January 2015.
[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-11 (work in Architecture", draft-ietf-hip-rfc4423-bis-12 (work in
progress), April 2015. progress), June 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, February 2002.
[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, April
2008. 2008.
Appendix A. Changes from RFC 5203 Appendix A. Changes from RFC 5203
 End of changes. 12 change blocks. 
27 lines changed or deleted 24 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/