draft-ietf-hip-rfc5203-bis-06.txt   draft-ietf-hip-rfc5203-bis-07.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: March 5, 2015 September 1, 2014 Expires: October 20, 2015 April 18, 2015
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-06 draft-ietf-hip-rfc5203-bis-07
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 March 5, 2015. This Internet-Draft will expire on October 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
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
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 9, line 40 skipping to change at page 9, line 40
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 Insufficient resources [TBD-IANA] Insufficient resources
[TBD-IANA] Invalid certificate [TBD-IANA] Invalid certificate
3-200 Unassigned [TBD-IANA]-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.
Failure type zero (0) indicates that the registrar requires Failure type zero (0) indicates that the registrar requires
additional credentials to authorize a requester to register with the additional credentials to authorize a requester to register with the
registration types listed in the parameter. Failure type one (1) registration types listed in the parameter. Failure type one (1)
indicates that the requested service type is unavailable at the indicates that the requested service type is unavailable at the
registrar. Failure type (2) indicates that the registrar does not registrar. Failure type ([TBD-IANA-Insufficient-resources])
currently have enough resources to register the requester for the indicates that the registrar does not currently have enough resources
service(s); when that is the case the requester MUST NOT reattempt to register the requester for the service(s); when that is the case
immediately to register for the same service(s), and MAY attempt to the requester MUST NOT reattempt immediately to register for the same
contact another registrar to register for these service(s). service(s), and MAY attempt to contact another registrar to register
for these service(s). Failure type ([TBD-IANA-Invalid-Certificates])
indicates that the registrar could not validate the certificate
provided by the requester to register for the service(s); when that
is the case the requester MUST NOT reattempt to register for the same
set of services while providing the same certificate, and MAY attempt
to register for the same set of service(s) with a different
certificate, or with a different set of service(s) with the same
certificate.
The registrar SHOULD include a REG_FAILED parameter in its R2 or The registrar SHOULD include a 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.
5. Establishing and Maintaining Registrations 5. Establishing and Maintaining Registrations
skipping to change at page 12, line 13 skipping to change at page 12, line 20
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 [TBD-IANA] Insufficient resources
2-200 Unassigned [TBD-IANA] Invalid certificate
[TBD-IANA]-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. Contributors 8. Contributors
Teemu Koponen co-authored an earlier, experimental version of this Teemu Koponen co-authored an earlier, experimental version of this
specification [RFC5203]. specification [RFC5203].
9. Acknowledgments 9. Acknowledgments
skipping to change at page 12, line 43 skipping to change at page 12, line 51
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] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-16 (work in progress), August 2014. 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-04 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work
in progress), June 2014. in progress), December 2014.
[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-01 (work in
progress), October 2013. progress), October 2013.
[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.
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-07 (work in progress), June 2014. 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-08 (work in Architecture", draft-ietf-hip-rfc4423-bis-11 (work in
progress), April 2014. progress), April 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. 13 change blocks. 
21 lines changed or deleted 31 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/