idnits 2.17.1 draft-keranen-hip-reload-instance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-hip-bone-01 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-02 == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-08 -- No information found for draft-ietf-camarillo-hip-via - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft G. Camarillo 4 Intended status: Experimental Ericsson 5 Expires: January 7, 2010 July 6, 2009 7 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) 8 Instance Specification for REsource LOcation And Discovery (RELOAD) 9 draft-keranen-hip-reload-instance-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies the HIP BONE instance specification for 48 RELOAD. It provides the details needed to build a RELOAD-based 49 overlay that uses HIP. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Peer ID to ORCHID Transformation . . . . . . . . . . . . . . . 3 57 5. Mapping between Protocol Primitives and HIP Messages . . . . . 3 58 6. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 4 59 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 11. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The HIP BONE (Host Identify Protocol-Based Overlay Networking 69 Environment) specification [I-D.ietf-hip-bone] provides a high-level 70 framework for building HIP-based [RFC5201] overlays. The HIP BONE 71 framework leaves the specification of the details on how to combine a 72 particular peer protocol with HIP to build an overlay up to documents 73 referred to as HIP BONE instance specifications. A HIP BONE instance 74 specification needs to define, minimally: 76 o the peer protocol to be used 77 o how to transform the peer IDs used by the peer protocol into the 78 ORCHIDs (Overlay Routable Cryptographic Hash Identifiers) 79 [RFC4843] that will be used in HIP 80 o which peer protocol primitives trigger HIP messages 82 This document addresses all the previous items and provides 83 additional details needed to built RELOAD-based HIP BONEs. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Peer Protocol 93 The peer protocol to be used is RELOAD, which is specified in 94 [I-D.ietf-p2psip-base]. When used with RELOAD, HIP takes the role of 95 the RELOAD's Forwarding and Link Management Layer (described in 96 Section 5.5. of [I-D.ietf-p2psip-base]). The RELOAD HIP BONE 97 instance provides to the applications the RELOAD Messaging API. 99 4. Peer ID to ORCHID Transformation 101 RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit 102 ORCHIDs, peer's ORCHID can be used as such as the RELOAD Node-ID. 104 5. Mapping between Protocol Primitives and HIP Messages 106 The Attach procedure in RELOAD establishes a connection between two 107 peers. This procedure is performed using the AttachReq and AttachAns 108 messages. When HIP is used, the Attach procedure is performed by 109 using a HIP base exchange. That is, peers send HIP I1 messages 110 instead of RELOAD AttachReq messages. 112 The RELOAD AttachLite procedure is used for the same purpose as the 113 Attach procedure in scenarios with no NATs. When HIP is used, the 114 AttachLite procedure is also performed by using a HIP base exchange. 115 That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq 116 messages. 118 All other RELOAD messages are sent as such between the peers using 119 the paths set up by HIP. 121 6. Routing HIP Messages via the Overlay 123 If a host has no valid locator for the receiver of a new HIP packet, 124 and the receiver is part of a RELOAD HIP BONE overlay the host is 125 participating in, the host can send the HIP packet to the receiver 126 using the overlay routing. 128 When sending a HIP packet via the overlay, the host MUST add an empty 129 ROUTE_VIA parameter [I-D.ietf-camarillo-hip-via] to the packet with 130 the SYMMETRIC flag set and with an OVERLAY_ID parameter (see 131 Section 7) containing the identifier of the right overlay network. 132 Host consults the RELOAD Topology Plugin for the next hop and sends 133 the HIP packet to that host. 135 An intermediate host receiving a HIP packet with the OVERLAY_ID 136 parameter checks if it is participating in that overlay, and drops 137 packets sent to unknown overlays. If the host is not the final 138 destination of the packet (i.e., the HIP header's receiver's HIT does 139 not match to any of its HITs), it checks if the packet contains a 140 ROUTE_DST parameter. Such packets are forwarded to the next hop as 141 specified in [I-D.ietf-camarillo-hip-via]. Otherwise, the host finds 142 the next hop from the RELOAD Topology Plugin and forwards the packet 143 there. The host MUST add the HIT it uses on the HIP association with 144 the next hop host to the end of the ROUTE_VIA parameter, if present. 146 When the final destination host receives the HIP packet, the host 147 processes it as specified in [RFC5201]. If the HIP packet generates 148 a response, the response is routed back on the same path using 149 ROUTE_DST parameter as specified in [I-D.ietf-camarillo-hip-via]. 151 7. Packet Formats 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Identifier | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Type [ TBD by IANA: 980 ] 162 Length 4 163 Identifier 32 bit identifier for the overlay 165 Figure 1: Format of the OVERLAY_ID parameter 167 Figure 1 shows the format of a new HIP parameter used for identifying 168 the right overlay if a host participates in multiple overlay 169 networks. For RELOAD HIP BONE overlay networks, the identifier is 170 calculated as defined in Section 5.3.2 of [I-D.ietf-p2psip-base]. 172 8. NAT Traversal 174 RELOAD relies on the Forwarding and Link Management Layer providing 175 NAT traversal capabilities. Thus, the RELOAD HIP BONE instance 176 implementation MUST implement [I-D.ietf-hip-nat-traversal] or some 177 other reliable NAT traversal mechanism. 179 HIP relay servers are not generally needed with this HIP BONE 180 instance since the overlay network can be used for relaying the Base 181 Exchange and further HIP signaling can be done directly between the 182 peers. 184 9. Security Considerations 186 TBD. 188 10. IANA Considerations 190 This section is to be interpreted according to [RFC5226]. 192 This document updates the IANA Registry for HIP Parameter Types 193 [RFC5201] by assigning new HIP Parameter Type value for the new HIP 194 Parameter OVERLAY_ID (defined in Section 7). 196 11. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 202 for Overlay Routable Cryptographic Hash Identifiers 203 (ORCHID)", RFC 4843, April 2007. 205 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 206 "Host Identity Protocol", RFC 5201, April 2008. 208 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 209 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 210 May 2008. 212 [I-D.ietf-hip-bone] 213 Camarillo, G., Nikander, P., Hautakorpi, J., and A. 214 Johnston, "HIP BONE: Host Identity Protocol (HIP) Based 215 Overlay Networking Environment", draft-ietf-hip-bone-01 216 (work in progress), March 2009. 218 [I-D.ietf-p2psip-base] 219 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 220 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 221 Base Protocol", draft-ietf-p2psip-base-02 (work in 222 progress), March 2009. 224 [I-D.ietf-hip-nat-traversal] 225 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 226 Keraenen, "Basic HIP Extensions for Traversal of Network 227 Address Translators", draft-ietf-hip-nat-traversal-08 228 (work in progress), June 2009. 230 [I-D.ietf-camarillo-hip-via] 231 Camarillo, G. and A. Keranen, "Host Identity Protocol 232 (HIP) Multi-hop Routing Extension", 233 draft-ietf-camarillo-hip-via-00 (work in progress), 234 July 2009. 236 Authors' Addresses 238 Ari Keranen 239 Ericsson 240 Hirsalantie 11 241 02420 Jorvas 242 Finland 244 Email: ari.keranen@ericsson.com 246 Gonzalo Camarillo 247 Ericsson 248 Hirsalantie 11 249 Jorvas 02420 250 Finland 252 Email: Gonzalo.Camarillo@ericsson.com