HIP Working Group A. Keranen
Internet-Draft G. Camarillo
Intended status: Experimental Ericsson
Expires: January 7, 2010 July 6, 2009
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD)
draft-keranen-hip-reload-instance-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies the HIP BONE instance specification for
RELOAD. It provides the details needed to build a RELOAD-based
Keranen & Camarillo Expires January 7, 2010 [Page 1]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
overlay that uses HIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Peer ID to ORCHID Transformation . . . . . . . . . . . . . . . 3
5. Mapping between Protocol Primitives and HIP Messages . . . . . 3
6. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 4
7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
11. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Keranen & Camarillo Expires January 7, 2010 [Page 2]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
1. Introduction
The HIP BONE (Host Identify Protocol-Based Overlay Networking
Environment) specification [I-D.ietf-hip-bone] provides a high-level
framework for building HIP-based [RFC5201] overlays. The HIP BONE
framework leaves the specification of the details on how to combine a
particular peer protocol with HIP to build an overlay up to documents
referred to as HIP BONE instance specifications. A HIP BONE instance
specification needs to define, minimally:
o the peer protocol to be used
o how to transform the peer IDs used by the peer protocol into the
ORCHIDs (Overlay Routable Cryptographic Hash Identifiers)
[RFC4843] that will be used in HIP
o which peer protocol primitives trigger HIP messages
This document addresses all the previous items and provides
additional details needed to built RELOAD-based HIP BONEs.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Peer Protocol
The peer protocol to be used is RELOAD, which is specified in
[I-D.ietf-p2psip-base]. When used with RELOAD, HIP takes the role of
the RELOAD's Forwarding and Link Management Layer (described in
Section 5.5. of [I-D.ietf-p2psip-base]). The RELOAD HIP BONE
instance provides to the applications the RELOAD Messaging API.
4. Peer ID to ORCHID Transformation
RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit
ORCHIDs, peer's ORCHID can be used as such as the RELOAD Node-ID.
5. Mapping between Protocol Primitives and HIP Messages
The Attach procedure in RELOAD establishes a connection between two
peers. This procedure is performed using the AttachReq and AttachAns
messages. When HIP is used, the Attach procedure is performed by
using a HIP base exchange. That is, peers send HIP I1 messages
Keranen & Camarillo Expires January 7, 2010 [Page 3]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
instead of RELOAD AttachReq messages.
The RELOAD AttachLite procedure is used for the same purpose as the
Attach procedure in scenarios with no NATs. When HIP is used, the
AttachLite procedure is also performed by using a HIP base exchange.
That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq
messages.
All other RELOAD messages are sent as such between the peers using
the paths set up by HIP.
6. Routing HIP Messages via the Overlay
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
participating in, the host can send the HIP packet to the receiver
using the overlay routing.
When sending a HIP packet via the overlay, the host MUST add an empty
ROUTE_VIA parameter [I-D.ietf-camarillo-hip-via] to the packet with
the SYMMETRIC flag set and with an OVERLAY_ID parameter (see
Section 7) containing the identifier of the right overlay network.
Host consults the RELOAD Topology Plugin for the next hop and sends
the HIP packet to that host.
An intermediate host receiving a HIP packet with the OVERLAY_ID
parameter checks if it is participating in that overlay, and drops
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
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
specified in [I-D.ietf-camarillo-hip-via]. Otherwise, the host finds
the next hop from the RELOAD Topology Plugin and forwards the packet
there. The host MUST add the HIT it uses on the HIP association with
the next hop host to the end of the ROUTE_VIA parameter, if present.
When the final destination host receives the HIP packet, the host
processes it as specified in [RFC5201]. If the HIP packet generates
a response, the response is routed back on the same path using
ROUTE_DST parameter as specified in [I-D.ietf-camarillo-hip-via].
Keranen & Camarillo Expires January 7, 2010 [Page 4]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
7. Packet Formats
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: 980 ]
Length 4
Identifier 32 bit identifier for the overlay
Figure 1: Format of the OVERLAY_ID parameter
Figure 1 shows the format of a new HIP parameter used for identifying
the right overlay if a host participates in multiple overlay
networks. For RELOAD HIP BONE overlay networks, the identifier is
calculated as defined in Section 5.3.2 of [I-D.ietf-p2psip-base].
8. NAT Traversal
RELOAD relies on the Forwarding and Link Management Layer providing
NAT traversal capabilities. Thus, the RELOAD HIP BONE instance
implementation MUST implement [I-D.ietf-hip-nat-traversal] or some
other reliable NAT traversal mechanism.
HIP relay servers are not generally needed with this HIP BONE
instance since the overlay network can be used for relaying the Base
Exchange and further HIP signaling can be done directly between the
peers.
9. Security Considerations
TBD.
10. IANA Considerations
This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type value for the new HIP
Parameter OVERLAY_ID (defined in Section 7).
Keranen & Camarillo Expires January 7, 2010 [Page 5]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[I-D.ietf-hip-bone]
Camarillo, G., Nikander, P., Hautakorpi, J., and A.
Johnston, "HIP BONE: Host Identity Protocol (HIP) Based
Overlay Networking Environment", draft-ietf-hip-bone-01
(work in progress), March 2009.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-02 (work in
progress), March 2009.
[I-D.ietf-hip-nat-traversal]
Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keraenen, "Basic HIP Extensions for Traversal of Network
Address Translators", draft-ietf-hip-nat-traversal-08
(work in progress), June 2009.
[I-D.ietf-camarillo-hip-via]
Camarillo, G. and A. Keranen, "Host Identity Protocol
(HIP) Multi-hop Routing Extension",
draft-ietf-camarillo-hip-via-00 (work in progress),
July 2009.
Keranen & Camarillo Expires January 7, 2010 [Page 6]
Internet-Draft HIP BONE Instance Spec for RELOAD July 2009
Authors' Addresses
Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
Email: ari.keranen@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Keranen & Camarillo Expires January 7, 2010 [Page 7]