idnits 2.17.1 draft-ietf-hip-rfc5203-bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (December 11, 2013) is 3788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-14 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-06 -- Obsolete informational reference (is this intentional?): RFC 5203 (Obsoleted by RFC 8003) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Luminate Wireless, Inc. 4 Obsoletes: 5203 (if approved) L. Eggert 5 Intended status: Standards Track NetApp 6 Expires: June 14, 2014 December 11, 2013 8 Host Identity Protocol (HIP) Registration Extension 9 draft-ietf-hip-rfc5203-bis-03 11 Abstract 13 This document specifies a registration mechanism for the Host 14 Identity Protocol (HIP) that allows hosts to register with services, 15 such as HIP rendezvous servers or middleboxes. This document 16 obsoletes RFC5203. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 14, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. HIP Registration Extension Overview . . . . . . . . . . . . . 3 55 3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4 56 3.2. Requester Requesting Registration . . . . . . . . . . . . 4 57 3.3. Registrar Granting or Refusing Service(s) Registration . 4 58 4. Parameter Formats and Processing . . . . . . . . . . . . . . 6 59 4.1. Encoding Registration Lifetimes with Exponents . . . . . 6 60 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 7 63 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Establishing and Maintaining Registrations . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 10.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 12 74 1. Introduction 76 This document specifies an extension to the Host Identity Protocol 77 (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic 78 means for a host to register with a service. The service may, for 79 example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a 80 middlebox [RFC3234]. 82 This document makes no further assumptions about the exact type of 83 service. Likewise, this document does not specify any mechanisms to 84 discover the presence of specific services or means to interact with 85 them after registration. Future documents may describe those 86 operations. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Terminology 93 In addition to the terminology defined in the HIP Architecture 94 [I-D.ietf-hip-rfc4423-bis], the HIP specification 95 [I-D.ietf-hip-rfc5201-bis], and the HIP Rendezvous Extension 96 [I-D.ietf-hip-rfc5204-bis], this document defines and uses the 97 following terms: 99 Requester: 100 a HIP node registering with a HIP registrar to request 101 registration for a service. 103 Registrar: 104 a HIP node offering registration for one or more services. 106 Service: 107 a facility that provides requesters with new capabilities or 108 functionalities operating at the HIP layer. Examples include 109 firewalls that support HIP traversal or HIP rendezvous servers. 111 Registration: 112 shared state stored by a requester and a registrar, allowing the 113 requester to benefit from one or more HIP services offered by the 114 registrar. Each registration has an associated finite lifetime. 115 Requesters can extend established registrations through re- 116 registration (i.e., perform a refresh). 118 Registration Type: 119 an identifier for a given service in the registration protocol. 120 For example, the rendezvous service is identified by a specific 121 registration type. 123 3. HIP Registration Extension Overview 125 This document does not specify the means by which a requester 126 discovers the availability of a service, or how a requester locates a 127 registrar. After a requester has discovered a registrar, it either 128 initiates HIP base exchange or uses an existing HIP association with 129 the registrar. In both cases, registrars use additional parameters, 130 which the remainder of this document defines, to announce their 131 quality and grant or refuse registration. Requesters use 132 corresponding parameters to register with the service. Both the 133 registrar and the requester MAY also include in the messages 134 exchanged additional HIP parameters specific to the registration type 135 implicated. Other documents will define parameters and how they 136 shall be used. The following sections describe the differences 137 between this registration handshake and the standard HIP base 138 exchange [I-D.ietf-hip-rfc5201-bis]. 140 3.1. Registrar Announcing Its Ability 142 A host that is capable and willing to act as a registrar SHOULD 143 include a REG_INFO parameter in the R1 packets it sends during all 144 base exchanges. If it is currently unable to provide services due to 145 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 146 with no services listed. If services can be provided later, it 147 SHOULD send UPDATE packets indicating the current set of services 148 available in a new REG_INFO parameter to all hosts it is associated 149 with. 151 3.2. Requester Requesting Registration 153 To request registration with a service, a requester constructs and 154 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 155 packet it sends to the registrar. 157 If the requester has no HIP association established with the 158 registrar, it SHOULD send the REG_REQUEST at the earliest 159 possibility, i.e., in the I2 packet. This minimizes the number of 160 packets that need to be exchanged with the registrar. A registrar 161 MAY end a HIP association that does not carry a REG_REQUEST by 162 including a NOTIFY with the type REG_REQUIRED in the R2. In this 163 case, no HIP association is created between the hosts. The 164 REG_REQUIRED notification error type is 51. 166 3.3. Registrar Granting or Refusing Service(s) Registration 168 Once registration has been requested, the registrar is able to 169 authenticate the requester based on the host identity included in I2. 170 It then verifies that the host identity is authorized to register 171 with the requested service(s), based on local policies. The details 172 of this authorization procedure depend on the type of requested 173 service(s) and on the local policies of the registrar, and are 174 therefore not further specified in this document. 176 After authorization, the registrar includes a REG_RESPONSE parameter 177 in its response, which contains the service type(s) for which it has 178 authorized registration, and zero or more REG_FAILED parameters 179 containing the service type(s) for which it has not authorized 180 registration or registration has failed for other reasons. This 181 response can be either an R2 or an UPDATE message, respectively, 182 depending on whether the registration was requested during the base 183 exchange, or using an existing association. In particular, 184 REG_FAILED with a failure type of zero indicates the service(s) 185 type(s) that require further credentials for registration. 187 If the registrar requires further authorization and the requester has 188 additional credentials available, the requester SHOULD try to 189 register again with the service after the HIP association has been 190 established. The precise means of establishing and verifying 191 credentials are beyond the scope of this document and are expected to 192 be defined in other documents. 194 Successful processing of a REG_RESPONSE parameter creates 195 registration state at the requester. In a similar manner, successful 196 processing of a REG_REQUEST parameter creates registration state at 197 the registrar and possibly at the service. Both the requester and 198 registrar can cancel a registration before it expires, if the 199 services afforded by a registration are no longer needed by the 200 requester, or cannot be provided any longer by the registrar (for 201 instance, because its configuration has changed). 203 +-----+ I1 +-----+-----+ 204 | |--------------------->| | S1 | 205 | |<---------------------| | | 206 | | R1(REG_INFO:S1,S2) | +-----+ 207 | RQ | | R | S2 | 208 | | I2(REG_REQ:S1) | | | 209 | |--------------------->| +-----+ 210 | |<---------------------| | S3 | 211 | | R2(REG_RESP:S1) | | | 212 +-----+ +-----+-----+ 214 A requester (RQ) registers with a registrar (R) of services (S1) and 215 (S2), with which it has no current HIP association. 217 +-----+ +-----+-----+ 218 | | UPDATE(REG_INFO:S) | | | 219 | |<---------------------| | | 220 | RQ |--------------------->| R | S | 221 | | UPDATE(REG_REQ:S) | | | 222 | | UPDATE(REG_RESP:S) | | | 223 | |<---------------------| | | 224 +-----+ +-----+-----+ 226 A requester (RQ) registers with a registrar (R) of services (S), with 227 which it currently has a HIP association established. 229 4. Parameter Formats and Processing 231 This section describes the format and processing of the new 232 parameters introduced by the HIP registration extension. 234 4.1. Encoding Registration Lifetimes with Exponents 236 The HIP registration uses an exponential encoding of registration 237 lifetimes. This allows compact encoding of 255 different lifetime 238 values ranging from 4 ms to 178 days into an 8-bit integer field. 239 The lifetime exponent field used throughout this document MUST be 240 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 241 seconds. 243 4.2. REG_INFO 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ... | ... | Reg Type #n | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Type 930 258 Length Length in octets, excluding Type, Length, and Padding. 259 Min Lifetime Minimum registration lifetime. 260 Max Lifetime Maximum registration lifetime. 261 Reg Type The registration types offered by the registrar. 263 Other documents will define specific values for registration types. 264 See Section 7 for more information. 266 Registrars include the parameter in R1 packets in order to announce 267 their registration capabilities. The registrar SHOULD include the 268 parameter in UPDATE packets when its service offering has changed. 269 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 271 4.3. REG_REQUEST 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | ... | ... | Reg Type #n | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type 932 285 Length Length in octets, excluding Type, Length, and Padding. 286 Lifetime Requested registration lifetime. 287 Reg Type The preferred registration types in order of preference. 289 Other documents will define specific values for registration types. 290 See Section 7 for more information. 292 A requester includes the REG_REQUEST parameter in I2 or UPDATE 293 packets to register with a registrar's service(s). If the 294 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 295 modify the registrations of registration types that are not listed in 296 the parameter. Moreover, the requester MUST NOT include the 297 parameter unless the registrar's R1 packet or latest received UPDATE 298 packet has contained a REG_INFO parameter with the requested 299 registration types. 301 The requester MUST NOT include more than one REG_REQUEST parameter in 302 its I2 or UPDATE packets, while the registrar MUST be able to process 303 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 305 When the registrar receives a registration with a lifetime that is 306 either smaller or greater than the minimum or maximum lifetime, 307 respectively, then it SHOULD grant the registration for the minimum 308 or maximum lifetime, respectively. 310 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 311 packets. 313 4.4. REG_RESPONSE 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | ... | ... | Reg Type #n | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Type 934 327 Length Length in octets, excluding Type, Length, and Padding. 328 Lifetime Granted registration lifetime. 329 Reg Type The granted registration types in order of preference. 331 Other documents will define specific values for registration types. 332 See Section 7 for more information. 334 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 335 UPDATE packet only if a registration has successfully completed. 337 The registrar MUST NOT include more than one REG_RESPONSE parameter 338 in its R2 or UPDATE packets, while the requester MUST be able to 339 process one or more REG_RESPONSE parameters in received R2 or UPDATE 340 packets. 342 The requester MUST be prepared to receive any registration lifetime, 343 including ones beyond the minimum and maximum lifetime indicated in 344 the REG_INFO parameter. It MUST NOT expect that the returned 345 lifetime will be the requested one, even when the requested lifetime 346 falls within the announced minimum and maximum. 348 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 349 packets. 351 4.5. REG_FAILED 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | ... | ... | Reg Type #n | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Type 936 365 Length Length in octets, excluding Type, Length, and Padding. 366 Failure Type Reason for failure. 367 Reg Type The registration types that failed with the specified 368 reason. 370 Failure Type Reason 371 ------------ -------------------------------------------- 372 0 Registration requires additional credentials 373 1 Registration type unavailable 374 3 Insufficient resources 375 3-200 Unassigned 376 201-255 Reserved by IANA for private use 378 Other documents will define specific values for registration types. 379 See Section 7 for more information. 381 A failure type of zero means a registrar requires additional 382 credentials to authorize a requester to register with the 383 registration types listed in the parameter. A failure type of one 384 means that the requested service type is unavailable at the 385 registrar. Failure types other than zero (0) and one (1) have not 386 been defined. 388 The registrar SHOULD include the REG_FAILED parameter in its R2 or 389 UPDATE packet, if registration with the registration types listed has 390 not completed successfully and a requester is asked to try again with 391 additional credentials. 393 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 394 packets. 396 5. Establishing and Maintaining Registrations 398 Establishing and/or maintaining a registration may require additional 399 information not available in the transmitted REG_REQUEST or 400 REG_RESPONSE parameters. Therefore, registration type definitions 401 MAY define dependencies for HIP parameters that are not defined in 402 this document. Their semantics are subject to the specific 403 registration type specifications. 405 The minimum lifetime both registrars and requesters MUST support is 406 10 seconds, while they SHOULD support a maximum lifetime of 120 407 seconds, at least. These values define a baseline for the 408 specification of services based on the registration system. They 409 were chosen to be neither too short nor too long, and to accommodate 410 for existing timeouts of state established in middleboxes (e.g., NATs 411 and firewalls.) 413 A zero lifetime is reserved for canceling purposes. Requesting a 414 zero lifetime for a registration type is equal to canceling the 415 registration of that type. A requester MAY cancel a registration 416 before it expires by sending a REG_REQ to the registrar with a zero 417 lifetime. A registrar SHOULD respond and grant a registration with a 418 zero lifetime. A registrar (and an attached service) MAY cancel a 419 registration before it expires, at its own discretion. However, if 420 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 421 registered requesters. 423 6. Security Considerations 425 This section discusses the threats on the HIP registration protocol, 426 and their implications on the overall security of HIP. In 427 particular, it argues that the extensions described in this document 428 do not introduce additional threats to HIP. 430 The extensions described in this document rely on the HIP base 431 exchange and do not modify its security characteristics, e.g., 432 digital signatures or HMAC. Hence, the only threat introduced by 433 these extensions is related to the creation of soft registration 434 state at the registrar. 436 Registrars act on a voluntary basis and are willing to accept being a 437 responder and then to create HIP associations with a number of 438 previously unknown hosts. Because they have to store HIP association 439 state anyway, adding a certain amount of time-limited HIP 440 registration state should not introduce any serious additional 441 threats, especially because HIP registrars may cancel registrations 442 at any time at their own discretion, e.g., because of resource 443 constraints during an attack. 445 7. IANA Considerations 446 This section is to be interpreted according to the Guidelines for 447 Writing an IANA Considerations Section in RFCs [RFC5226]. 449 This document updates the IANA Registry for HIP Parameter Types by 450 assigning new HIP Parameter Types values for the new HIP Parameters 451 defined in this document: 453 o REG_INFO (defined in Section 4.2) 455 o REG_REQUEST (defined in Section 4.3) 457 o REG_RESPONSE (defined in Section 4.4) 459 o REG_FAILED (defined in Section 4.5) 461 IANA has allocated the Notify Message Type code 51 for the 462 REG_REQUIRED notification error type in the Notify Message Type 463 registry. 465 IANA has opened a new registry for registration types. This document 466 does not define registration types but makes the following 467 reservations: 469 Reg Type Service 470 -------- ------- 471 0-200 Unassigned 472 201-255 Reserved by IANA for private use 474 Adding a new type requires new IETF specifications. 476 IANA has opened a new registry for registration failure types. This 477 document makes the following failure type definitions and 478 reservations: 480 Failure Type Reason 481 ------------ -------------------------------------------- 482 0 Registration requires additional credentials 483 1 Registration type unavailable 484 3 Insufficient resources 485 2-200 Unassigned 486 201-255 Reserved by IANA for private use 488 Adding a new type requires new IETF specifications. 490 8. Contributors 492 Teemu Koponen co-authored an earlier, experimental version of this 493 specification [RFC5203]. 495 9. Acknowledgments 497 The following people (in alphabetical order) have provided thoughtful 498 and helpful discussions and/or suggestions that have helped to 499 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari 500 Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. 502 10. References 504 10.1. Normative References 506 [I-D.ietf-hip-rfc5201-bis] 507 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 508 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 509 hip-rfc5201-bis-14 (work in progress), October 2013. 511 [I-D.ietf-hip-rfc5204-bis] 512 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 513 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 514 in progress), September 2012. 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 520 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 521 May 2008. 523 10.2. Informative References 525 [I-D.ietf-hip-rfc4423-bis] 526 Moskowitz, R. and M. Komu, "Host Identity Protocol 527 Architecture", draft-ietf-hip-rfc4423-bis-06 (work in 528 progress), November 2013. 530 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 531 Issues", RFC 3234, February 2002. 533 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 534 Protocol (HIP) Registration Extension", RFC 5203, April 535 2008. 537 Appendix A. Changes from RFC 5203 539 o Updated references to revised HIP specifications. 541 o Added a new registration failure type for use in case of 542 insufficient resources available at the HIP registrar. 544 Authors' Addresses 546 Julien Laganier 547 Luminate Wireless, Inc. 548 Cupertino, CA 549 USA 551 EMail: julien.ietf@gmail.com 553 Lars Eggert 554 NetApp 555 Sonnenallee 1 556 Kirchheim 85551 557 Germany 559 Phone: +49 151 12055791 560 EMail: lars@netapp.com 561 URI: http://eggert.org