draft-ietf-hip-rfc5204-bis-01.txt   draft-ietf-hip-rfc5204-bis-02.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Obsoletes: 5204 (if approved) L. Eggert Obsoletes: 5204 (if approved) L. Eggert
Intended status: Standards Track Nokia Intended status: Standards Track NetApp
Expires: September 15, 2011 March 14, 2011 Expires: March 26, 2013 September 22, 2012
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-01 draft-ietf-hip-rfc5204-bis-02
Abstract Abstract
This document defines a rendezvous extension for the Host Identity This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes registration extension for initiating communication between HIP nodes
via HIP rendezvous servers. Rendezvous servers improve reachability via HIP rendezvous servers. Rendezvous servers improve reachability
and operation when HIP nodes are multi-homed or mobile. and operation when HIP nodes are multi-homed or mobile.
Status of This Memo Status of This Memo
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 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. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 5 3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8 4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) Architecture [RFC4423] introduces The Host Identity Protocol (HIP) Architecture
the rendezvous mechanism to help a HIP node to contact a frequently [I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to
moving HIP node. The rendezvous mechanism involves a third party, help a HIP node to contact a frequently moving HIP node. The
the rendezvous server (RVS), which serves as an initial contact point rendezvous mechanism involves a third party, the rendezvous server
("rendezvous point") for its clients. The clients of an RVS are HIP (RVS), which serves as an initial contact point ("rendezvous point")
nodes that use the HIP Registration Extension for its clients. The clients of an RVS are HIP nodes that use the
[I-D.ietf-hip-rfc5203-bis] to register their HIT->IP address mappings HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register
with the RVS. After this registration, other HIP nodes can initiate their HIT->IP address mappings with the RVS. After this
a base exchange using the IP address of the RVS instead of the registration, other HIP nodes can initiate a base exchange using the
current IP address of the node they attempt to contact. Essentially, IP address of the RVS instead of the current IP address of the node
the clients of an RVS become reachable at the RVS's IP address. they attempt to contact. Essentially, the clients of an RVS become
Peers can initiate a HIP base exchange with the IP address of the reachable at the RVS's IP address. Peers can initiate a HIP base
RVS, which will relay this initial communication such that the base exchange with the IP address of the RVS, which will relay this
exchange may successfully complete. initial communication such that the base exchange may successfully
complete.
2. Terminology 2. Terminology
This section defines terms used throughout the remainder of this This section defines terms used throughout the remainder of this
specification. specification.
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].
skipping to change at page 4, line 29 skipping to change at page 4, line 33
Figure 1: HIP base exchange without rendezvous server. Figure 1: HIP base exchange without rendezvous server.
The End-Host Mobility and Multihoming with the Host Identity The End-Host Mobility and Multihoming with the Host Identity
Protocol specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node Protocol specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node
to notify its peers about changes in its set of IP addresses. This to notify its peers about changes in its set of IP addresses. This
specification presumes initial reachability of the two nodes with specification presumes initial reachability of the two nodes with
respect to each other. respect to each other.
However, such a HIP node MAY also want to be reachable to other However, such a HIP node MAY also want to be reachable to other
future correspondent peers that are unaware of its location change. future correspondent peers that are unaware of its location change.
The HIP Architecture [RFC4423] introduces rendezvous servers with The HIP Architecture [I-D.ietf-hip-rfc4423-bis] introduces rendezvous
whom a HIP node MAY register its host identity tags (HITs) and servers with whom a HIP node MAY register its host identity tags
current IP addresses. An RVS relays HIP packets arriving for these (HITs) and current IP addresses. An RVS relays HIP packets arriving
HITs to the node's registered IP addresses. When a HIP node has for these HITs to the node's registered IP addresses. When a HIP
registered with an RVS, it SHOULD record the IP address of its RVS in node has registered with an RVS, it SHOULD record the IP address of
its DNS record, using the HIP DNS resource record type defined in the its RVS in its DNS record, using the HIP DNS resource record type
HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. defined in the HIP DNS Extension [I-D.ietf-hip-rfc5205-bis].
+-----+ +-----+
+--I1--->| RVS |---I1--+ +--I1--->| RVS |---I1--+
| +-----+ | | +-----+ |
| v | v
+-----+ +-----+ +-----+ +-----+
| |<------R1-------| | | |<------R1-------| |
| I |-------I2------>| R | | I |-------I2------>| R |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 13, line 27 skipping to change at page 13, line 27
Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
Stiemerling, and Juergen Quittek. Stiemerling, and Juergen Quittek.
8. References 8. References
8.1. Normative References 8.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-rfc5203-bis] Laganier, J., Koponen, T., and L. Eggert, [I-D.ietf-hip-rfc5203-bis] Laganier, J., Koponen, T., and L. Eggert,
"Host Identity Protocol (HIP) "Host Identity Protocol (HIP)
Registration Extension", Registration Extension",
draft-ietf-hip-rfc5203-bis-00 (work in draft-ietf-hip-rfc5203-bis-01 (work in
progress), August 2010. progress), March 2011.
[I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol
(HIP) Domain Name System (DNS) (HIP) Domain Name System (DNS)
Extension", draft-ietf-hip-rfc5205-bis-00 Extension", draft-ietf-hip-rfc5205-bis-01
(work in progress), August 2010. (work in progress), March 2011.
[RFC1122] Braden, R., "Requirements for Internet [RFC1122] Braden, R., "Requirements for Internet
Hosts - Communication Layers", STD 3, Hosts - Communication Layers", STD 3,
RFC 1122, October 1989. RFC 1122, October 1989.
[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.
[RFC3484] Draves, R., "Default Address Selection [RFC3484] Draves, R., "Default Address Selection
for Internet Protocol version 6 (IPv6)", for Internet Protocol version 6 (IPv6)",
RFC 3484, February 2003. RFC 3484, February 2003.
8.2. Informative References 8.2. Informative References
[I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
and J. Arkko, "Host Mobility with the Architecture",
Host Identity Protocol", draft-ietf-hip-rfc4423-bis-04 (work in
draft-ietf-hip-rfc5206-bis-01 (work in progress), July 2012.
progress), October 2010.
[I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko,
"Host Mobility with the Host Identity
Protocol", draft-ietf-hip-rfc5206-bis-04
(work in progress), July 2012.
[RFC2827] Ferguson, P. and D. Senie, "Network [RFC2827] Ferguson, P. and D. Senie, "Network
Ingress Filtering: Defeating Denial of Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, Address Spoofing", BCP 38, RFC 2827,
May 2000. May 2000.
[RFC3013] Killalea, T., "Recommended Internet [RFC3013] Killalea, T., "Recommended Internet
Service Provider Security Services and Service Provider Security Services and
Procedures", BCP 46, RFC 3013, Procedures", BCP 46, RFC 3013,
November 2000. November 2000.
[RFC4423] Moskowitz, R. and P. Nikander, "Host
Identity Protocol (HIP) Architecture",
RFC 4423, May 2006.
Appendix A. Changes from RFC 5204 Appendix A. Changes from RFC 5204
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
o Added relaying of UPDATE packets to support double jump mobility
scenario.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Juniper Networks
1094 North Mathilda Avenue 1094 North Mathilda Avenue
Sunnyvale, 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
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. 15 change blocks. 
46 lines changed or deleted 50 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/