draft-ietf-hip-reload-instance-02.txt   draft-ietf-hip-reload-instance-03.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Experimental J. Maenpaa Intended status: Experimental J. Maenpaa
Expires: January 13, 2011 Ericsson Expires: July 15, 2011 Ericsson
July 12, 2010 January 11, 2011
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD) Instance Specification for REsource LOcation And Discovery (RELOAD)
draft-ietf-hip-reload-instance-02.txt draft-ietf-hip-reload-instance-03.txt
Abstract Abstract
This document is the Host Identity Protocol-Based Overlay Networking This document is the Host Identity Protocol-Based Overlay Networking
Environment (HIP BONE) instance specification for the REsource Environment (HIP BONE) instance specification for the REsource
LOcation And Discovery (RELOAD) protocol. The document provides the LOcation And Discovery (RELOAD) protocol. The document provides the
details needed to build a RELOAD-based overlay that uses HIP. details needed to build a RELOAD-based overlay that uses HIP.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 28 skipping to change at page 2, line 28
5. Mapping between Protocol Primitives and HIP Messages . . . . . 4 5. Mapping between Protocol Primitives and HIP Messages . . . . . 4
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5
6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5 6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5
7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6
8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 8 10. RELOAD Overlay Configuration Document Extension . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9
14.2. Informational References . . . . . . . . . . . . . . . . . 10 14.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The HIP BONE (Host Identify Protocol-Based Overlay Networking The HIP BONE (Host Identify Protocol-Based Overlay Networking
Environment) specification [I-D.ietf-hip-bone] provides a high-level Environment) specification [I-D.ietf-hip-bone] provides a high-level
skipping to change at page 3, line 33 skipping to change at page 3, line 33
details on how different RELOAD modules would be integrated to a HIP details on how different RELOAD modules would be integrated to a HIP
implementation and what kind of APIs are used between them are left implementation and what kind of APIs are used between them are left
as implementation details or to be defined by other documents. as implementation details or to be defined by other documents.
2. Terminology 2. Terminology
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].
In addition, this document uses the terms defined in [RFC5201], In addition, this document uses the terms defined in [RFC5201],
[I-D.ietf-hip-bone], [I-D.ietf-hip-via], and [I-D.ietf-p2psip-base]. [I-D.ietf-hip-bone], [RFC6028], and [I-D.ietf-p2psip-base].
3. Peer Protocol 3. Peer Protocol
The peer protocol to be used is RELOAD, which is specified in The peer protocol to be used is RELOAD, which is specified in
[I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the
RELOAD's Forwarding and Link Management Layer (described in Section RELOAD's Forwarding and Link Management Layer (described in Section
5.5. of [I-D.ietf-p2psip-base]). 5.5. of [I-D.ietf-p2psip-base]).
4. Node ID Generation 4. Node ID Generation
skipping to change at page 4, line 28 skipping to change at page 4, line 28
in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT
traversal functionality, is replaced by HIP and the extensions traversal functionality, is replaced by HIP and the extensions
defined in this document. defined in this document.
The standard RELOAD messages consist of three parts: Forwarding The standard RELOAD messages consist of three parts: Forwarding
Header, Message Contents and the Security Block. When RELOAD Header, Message Contents and the Security Block. When RELOAD
messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message
Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups] Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups]
messages, but the functionality of the Forwarding Header and Security messages, but the functionality of the Forwarding Header and Security
Block are replaced with HIP header, HIP Destination and Via lists Block are replaced with HIP header, HIP Destination and Via lists
[I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID [RFC6028], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID
[I-D.ietf-hip-hiccups], OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-hiccups], OVERLAY_ID and OVERLAY_TTL
[I-D.ietf-hip-bone] parameters. [I-D.ietf-hip-bone] parameters.
5.1. Forwarding Header 5.1. Forwarding Header
The RELOAD Forwarding Header is used for forwarding messages between The RELOAD Forwarding Header is used for forwarding messages between
peers and to their final destination. The Forwarding Header's peers and to their final destination. The Forwarding Header's
overlay field's value MUST be used as such in an OVERLAY_ID parameter overlay field's value MUST be used as such in an OVERLAY_ID parameter
and the transaction_id field in a TRANSACTION_ID parameter. That is, and the transaction_id field in a TRANSACTION_ID parameter. That is,
all RELOAD HIP BONE messages MUST contain these parameters and the all RELOAD HIP BONE messages MUST contain these parameters and the
skipping to change at page 6, line 28 skipping to change at page 6, line 28
CERT parameter. CERT parameter.
7. Routing HIP Messages via the Overlay 7. Routing HIP Messages via the Overlay
If a host has no valid locator for the receiver of a new HIP packet, If a host has no valid locator for the receiver of a new HIP packet,
and the receiver is part of a RELOAD HIP BONE overlay the host is and the receiver is part of a RELOAD HIP BONE overlay the host is
participating in, the host can send the HIP packet to the receiver participating in, the host can send the HIP packet to the receiver
using the overlay routing. using the overlay routing.
When sending a HIP packet via the overlay, the host MUST add an empty When sending a HIP packet via the overlay, the host MUST add an empty
ROUTE_VIA parameter [I-D.ietf-hip-via] to the packet with the ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and
SYMMETRIC and MUST_FOLLOW flags set and an OVERLAY_ID parameter MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the
containing the identifier of the right overlay network. The host identifier of the right overlay network. The host consults the
consults the RELOAD Topology Plugin for the next hop and sends the RELOAD Topology Plugin for the next hop and sends the HIP packet to
HIP packet to that host. that host.
An intermediate host receiving a HIP packet with the OVERLAY_ID An intermediate host receiving a HIP packet with the OVERLAY_ID
parameter checks if it is participating in that overlay, and SHOULD parameter checks if it is participating in that overlay, and SHOULD
drop packets sent to unknown overlays. If the host is not the final drop packets sent to unknown overlays. If the host is not the final
destination of the packet (i.e., the HIP header's receiver's HIT does destination of the packet (i.e., the HIP header's receiver's HIT does
not match to any of its HITs), it checks if the packet contains a not match to any of its HITs), it checks if the packet contains a
ROUTE_DST parameter. Such packets are forwarded to the next hop as ROUTE_DST parameter. Such packets are forwarded to the next hop as
specified in [I-D.ietf-hip-via]. If the packet does not contain a specified in [RFC6028]. If the packet does not contain a ROUTE_DST
ROUTE_DST parameter, the host finds the next hop from the RELOAD parameter, the host finds the next hop from the RELOAD Topology
Topology Plugin and forwards the packet there. As specified in Plugin and forwards the packet there. As specified in [RFC6028], the
[I-D.ietf-hip-via], the host adds the HIT it uses on the HIP host adds the HIT it uses on the HIP association with the next hop
association with the next hop host to the end of the ROUTE_VIA host to the end of the ROUTE_VIA parameter, if present.
parameter, if present.
When the final destination host receives the HIP packet, the host When the final destination host receives the HIP packet, the host
processes it as specified in [RFC5201] and in case of HIP DATA processes it as specified in [RFC5201] and in case of HIP DATA
packet, the contents are processed as specified in packet, the contents are processed as specified in
[I-D.ietf-p2psip-base]. If the HIP packet generates a response, the [I-D.ietf-p2psip-base]. If the HIP packet generates a response, the
response is routed back on the same path using the ROUTE_DST response is routed back on the same path using the ROUTE_DST
parameter as specified in [I-D.ietf-hip-via]. parameter as specified in [RFC6028].
8. Enrollment and Bootstrapping 8. Enrollment and Bootstrapping
The RELOAD HIP BONE instance uses the enrollment and bootstrap The RELOAD HIP BONE instance uses the enrollment and bootstrap
procedure defined by RELOAD [I-D.ietf-p2psip-base] with the procedure defined by RELOAD [I-D.ietf-p2psip-base] with the
exceptions listed below. exceptions listed below.
o In RELOAD, a node wishing to enroll in an overlay starts with a o In RELOAD, a node wishing to enroll in an overlay starts with a
discovery process to find an enrollment server as explained in discovery process to find an enrollment server as explained in
[I-D.ietf-p2psip-base]. The URL of the enrollment server may be [I-D.ietf-p2psip-base]. The URL of the enrollment server may be
skipping to change at page 9, line 36 skipping to change at page 9, line 32
[I-D.ietf-hip-bone] [I-D.ietf-hip-bone]
Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment", Based Overlay Networking Environment",
draft-ietf-hip-bone-07 (work in progress), June 2010. draft-ietf-hip-bone-07 (work in progress), June 2010.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-08 (work in Base Protocol", draft-ietf-p2psip-base-12 (work in
progress), March 2010. progress), November 2010.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[I-D.ietf-hip-via] [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol
Camarillo, G. and A. Keranen, "Host Identity Protocol (HIP) Multi-Hop Routing Extension", RFC 6028,
(HIP) Multi-hop Routing Extension", draft-ietf-hip-via-03 October 2010.
(work in progress), June 2010.
[I-D.ietf-hip-hiccups] [I-D.ietf-hip-hiccups]
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
Immediate Carriage and Conveyance of Upper- layer Protocol Immediate Carriage and Conveyance of Upper- layer Protocol
Signaling (HICCUPS)", draft-ietf-hip-hiccups-03 (work in Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in
progress), July 2010. progress), July 2010.
[I-D.ietf-hip-cert] [I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "HIP Certificates", Heer, T. and S. Varjonen, "Host Identity Protocol
draft-ietf-hip-cert-03 (work in progress), April 2010. Certificates", draft-ietf-hip-cert-06 (work in progress),
November 2010.
14.2. Informational References 14.2. Informational References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 14 change blocks. 
29 lines changed or deleted 28 lines changed or added

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