idnits 2.17.1 draft-ietf-hip-native-nat-traversal-10.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 == Line 379 has weird spacing: '...eserved reser...' == Line 381 has weird spacing: '...Address an I...' == Line 417 has weird spacing: '... Length len...' == Line 420 has weird spacing: '...eserved reser...' == Line 422 has weird spacing: '...Address an I...' == (1 more instance...) -- The document date (January 19, 2016) is 3017 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 (-11) exists of draft-ietf-hip-rfc5203-bis-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Downref: Normative reference to an Experimental RFC: RFC 5770 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft J. Melen 4 Intended status: Standards Track Ericsson 5 Expires: July 22, 2016 January 19, 2016 7 Native NAT Traversal Mode for the Host Identity Protocol 8 draft-ietf-hip-native-nat-traversal-10 10 Abstract 12 This document specifies a new Network Address Translator (NAT) 13 traversal mode for the Host Identity Protocol (HIP). The new mode is 14 based on the Interactive Connectivity Establishment (ICE) methodology 15 and UDP encapsulation of data and signaling traffic. The main 16 difference from the previously specified modes is the use of HIP 17 messages for all NAT traversal procedures. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 22, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . 3 57 3.2. Forwarding Rules and Permissions . . . . . . . . . . . . 4 58 3.3. Relaying UDP Encapsulated Data and Control Packets . . . 5 59 3.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 5 60 3.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 6 61 3.6. Native NAT Traversal Mode Negotiation . . . . . . . . . . 6 62 3.7. Connectivity Check Pacing Negotiation . . . . . . . . . . 6 63 3.8. Connectivity Checks . . . . . . . . . . . . . . . . . . . 6 64 3.9. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 7 65 3.10. Handling Conflicting SPI Values . . . . . . . . . . . . . 7 66 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 8 68 4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 9 69 4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The Host Identity Protocol (HIP) [RFC7401] is specified to run 81 directly on top of IPv4 or IPv6. However, many middleboxes found in 82 the Internet, such as NATs and firewalls, often allow only UDP or TCP 83 traffic to pass [RFC5207]. Also, especially NATs usually require the 84 host behind a NAT to create a forwarding state in the NAT before 85 other hosts outside of the NAT can contact the host behind the NAT. 86 To overcome this problem, different methods, commonly referred to as 87 NAT traversal techniques, have been developed. 89 Two NAT traversal techniques for HIP are specified in [RFC5770]. One 90 of them uses only UDP encapsulation, while the other uses also the 91 Interactive Connectivity Establishment (ICE) [RFC5245] protocol, 92 which in turn uses Session Traversal Utilities for NAT (STUN) 93 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] 94 protocols to achieve a reliable NAT traversal solution. 96 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 97 traversal infrastructure already available in the Internet, such as 98 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 99 could be able to do something "smart" when they see STUN being used 100 for NAT traversal. However, implementing a full ICE/STUN/TURN 101 protocol stack results in a considerable amount of effort and code 102 which could be avoided by re-using and extending HIP messages and 103 state machines for the same purpose. Thus, this document specifies a 104 new NAT traversal mode that uses HIP messages instead of STUN for the 105 connectivity checks, keepalives, and data relaying. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in RFC 112 2119 [RFC2119]. 114 This document uses the same terminology as [RFC5770] and the 115 following: 117 HIP data relay: 118 A host that forwards HIP data packets, such as Encapsulating 119 Security Payload (ESP) [RFC7402], between two hosts. 121 Registered host: 122 A host that has registered for a relaying service with a HIP data 123 relay. 125 3. Protocol Description 127 This section describes the normative behavior of the protocol 128 extension. Most of the procedures are similar to what is defined in 129 [RFC5770] but with different, or additional, parameter types and 130 values. In addition, a new type of relaying server, HIP data relay, 131 is specified. Also, it should be noted that HIP version 2 [RFC7401] 132 (instead of [RFC5201] used in [RFC5770]) is expected to be used with 133 this NAT traversal mode. 135 3.1. Relay Registration 137 Relay registration procedure for HIP signaling is identical to the 138 one specified in Section 4.1 of [RFC5770]. However, a host MAY also 139 register for UDP encapsulated ESP relaying using Registration Type 140 RELAY_UDP_ESP (value [TBD by IANA: 3]). 142 If the HIP relay server supports relaying of UDP encapsulated ESP, 143 the host is allowed to register for a data relaying service (see 144 Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has 145 sufficient relaying resources (free port numbers, bandwidth, etc.) 146 available, the relay opens a UDP port on one of its addresses and 147 signals the address and port to the registering host using the 148 RELAYED_ADDRESS parameter (see Section 4.1 for details). If the 149 relay would accept the data relaying request but does not currently 150 have enough resources to provide data relaying service, it MUST 151 reject the request with Failure Type "Insufficient resources" 152 [I-D.ietf-hip-rfc5203-bis]. 154 The registered host MUST maintain an active HIP association with the 155 data relay as long as it requires the data relaying service. When 156 the HIP association is closed (or times out), or the registration 157 lifetime passes without the registered host refreshing the 158 registration, the data relay MUST stop relaying packets for that host 159 and close the corresponding UDP port (unless other registered hosts 160 are still using it). 162 The data relay MAY use the same relayed address and port for multiple 163 registered hosts, but since this can cause problems with stateful 164 firewalls (see Section 5) it is NOT RECOMMENDED. 166 3.2. Forwarding Rules and Permissions 168 The HIP data relay uses a similar permission model as a TURN server: 169 before any ESP data packets sent by a peer are forwarded, a 170 permission MUST be set for the peer's address. The permissions also 171 install a forwarding rule, similar to TURN's channels, based on the 172 Security Parameter Index (SPI) values in the ESP packets. 174 Permissions are not required for the connectivity checks, but if a 175 relayed address is selected to be used for data, the registered host 176 MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION 177 parameter (see Section 4.2) with the address of the peer and the 178 outbound and inbound SPI values the host is using with this peer. 180 When a data relay receives an UPDATE with a PEER_PERMISSION 181 parameter, it MUST check if the sender of the UPDATE is registered 182 for data relaying service, and drop the UPDATE if the host was not 183 registered. If the host was registered, the relay checks if there is 184 a permission with matching information (address, protocol, port and 185 SPI values). If there is no such permission, a new permission MUST 186 be created and its lifetime MUST be set to 5 minutes. If an 187 identical permission already existed, it MUST be refreshed by setting 188 the lifetime to 5 minutes. A registered host SHOULD refresh 189 permissions 1 minute before the expiration if the permission is still 190 needed. 192 3.3. Relaying UDP Encapsulated Data and Control Packets 194 When a HIP data relay accepts to relay UDP encapsulated data, it 195 opens a UDP port (relayed address) for this purpose as described in 196 Section 3.1. If the data relay receives a UDP encapsulated HIP 197 control packet on that port, it MUST forward the packet to the 198 registered host and add a RELAY_FROM parameter to the packet as if 199 the data relay was acting as a HIP relay server [RFC5770]. 201 When a host wants to send a HIP control packet (such as a 202 connectivity check packet) to a peer via the data relay, it MUST add 203 a RELAY_TO parameter containing the peer's address to the packet and 204 send it to the data relay's address. The data relay MUST send the 205 packet to the peer's address from the relayed address. 207 If the data relay receives a UDP packet that is not a HIP control 208 packet to the relayed address, it MUST check whether there is a 209 permission set for the peer the packet is coming from (i.e., the 210 sender's address and SPI value matches to an installed permission), 211 and if there is, it MUST forward the packet to the registered host 212 that created the permission. Packets without a permission MUST be 213 dropped silently. 215 When a host wants to send a UDP encapsulated ESP packet to a peer via 216 the data relay, it MUST have an active permission at the data relay 217 for the peer with the outbound SPI value it is using. The host MUST 218 send the UDP encapsulated ESP packet to the data relay's address. 220 When the data relay receives a UDP encapsulated ESP packet from a 221 registered host, it MUST check whether there exists a permission for 222 that outbound SPI value. If such permission exists, the packet MUST 223 be forwarded to the address that was registered for the SPI value. 224 If no permission exists, the packet is dropped. 226 3.4. Candidate Gathering 228 A host needs to gather a set of address candidates before starting 229 the connectivity checks. One server reflexive candidate can be 230 discovered during the registration with the HIP relay server from the 231 REG_FROM parameter. 233 If a host has more than one network interface, additional server 234 reflexive candidates can be discovered by sending registration 235 requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by 236 IANA: 4]) from each of the interfaces to a HIP relay server. When a 237 HIP relay server receives a registration request with 238 CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, 239 containing the same information as if this was a relay registration, 240 to the response. This request type SHOULD NOT create any state at 241 the HIP relay server. 243 It is RECOMMENDED that the host also obtains a relayed candidate from 244 a HIP data relay as described in Section 3.1. 246 Gathering of candidates MAY also be performed like specified in 247 Section 4.2 of [RFC5770] if STUN and TURN servers are available, or 248 if the host has just a single interface and there are no TURN or HIP 249 data relay servers available. 251 3.5. Base Exchange via HIP Relay Server 253 The Base Exchange is performed as described in Section 4.5 of 254 [RFC5770], except that "ICE candidates" are replaced by the 255 candidates gathered using procedures described in Section 3.4 257 3.6. Native NAT Traversal Mode Negotiation 259 A host implementing this specification SHOULD signal the support for 260 the native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal 261 mode (value [TBD by IANA: 3]) in the NAT_TRAVERSAL_MODE [RFC5770] 262 parameter. If this mode is supported by both endpoints, and is the 263 most preferred mode out of the all supported modes, further NAT 264 traversal procedures are performed as specified in this document. 265 Note that the results of the previously described methods, candidate 266 gathering and HIP data relay registration with HIP messages, can be 267 used also with the ICE-STUN-UDP NAT traversal mode. 269 3.7. Connectivity Check Pacing Negotiation 271 Since the NAT traversal mode specified in this document utilizes 272 connectivity checks, the check pacing negotiation MUST be performed 273 as specified in Section 4.4 of [RFC5770]. New connectivity check 274 transactions MUST NOT be started faster than once every Ta (the value 275 negotiated with the TRANSACTION_PACING parameter). 277 3.8. Connectivity Checks 279 The connectivity checks are performed as described in Section 4.6 of 280 [RFC5770] but instead of STUN packets, the connectivity checks are 281 HIP UPDATE packets. See Section 4.3 for parameter details. 283 As defined in [RFC5770], both hosts MUST form a priority ordered 284 checklist and start check transactions every Ta milliseconds as long 285 as the checks are running and there are candidate pairs whose tests 286 have not started. The retransmission timeout (RTO) for the 287 connectivity check UPDATE packets MUST be calculated as defined in 288 Section 4.6 of [RFC5770]. 290 All connectivity check request packets MUST contain a 291 CANDIDATE_PRIORITY parameter (see Section 4.3) with the priority 292 value that would be assigned to a peer reflexive candidate if one was 293 learned from this check. The UPDATE packets that acknowledge a 294 connectivity check requests MUST be sent from the same address that 295 received the check and to the same address where the check was 296 received from. 298 The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS 299 parameter with the port, protocol, and IP address of the address 300 where the connectivity check request was received from. 302 After a working candidate pair, or pairs, have been discovered, the 303 controlling host MUST conclude the checks by nominating the highest 304 priority candidate pair for use. The pair MUST be nominated by 305 sending an ESP packet on the selected pair. If the controlling host 306 does not have any data to send, it SHOULD send an ICMP echo request 307 using the nominated pair to signal to the controlled host that it can 308 stop checks and start using the nominated pair. When the controlled 309 host receives the first ESP packet, it MUST select that pair for use 310 and send back an ESP packet to acknowledge a working candidate pair. 311 If the controlled host does not have any data to send, it SHOULD send 312 an ICMP echo request. 314 If the connectivity checks failed the hosts SHOULD notify each other 315 about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message 316 Type [RFC5770]. 318 3.9. NAT Keepalives 320 To keep the NAT bindings towards the HIP relay server and the HIP 321 data relay alive, if a registered host has not sent any data or 322 control messages to the relay for 15 seconds, it MUST send a HIP 323 NOTIFY packet to the relay. Likewise, if the host has not sent any 324 data to a host it has security association and has run connectivity 325 checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo 326 request using the same locators as the security association is using. 328 3.10. Handling Conflicting SPI Values 330 Since the HIP data relay determines from the SPI value to which peer 331 an ESP packet should be forwarded, the outbound SPI values need to be 332 unique for each relayed address registration. Thus, if a registered 333 host detects that a peer would use an SPI value that is already used 334 with another peer via the relay, it MUST NOT select the relayed 335 address for use. The host MAY restart the base exchange to avoid a 336 conflict or it MAY refrain from using the relayed candidate for the 337 connectivity checks. 339 Since the SPI space is 32 bits and the SPI values should be random, 340 the probability for a conflicting SPI value is fairly small. 341 However, a host with many peers MAY decrease the odds of a conflict 342 by registering more than one relayed address using different local 343 addresses. 345 4. Packet Formats 347 The following subsections define the parameter and packet encodings 348 for the new HIP parameters used for NAT traversal. UDP encapsulation 349 of the HIP and ESP packets and format of the other required 350 parameters is specified in Section 5 of [RFC5770]. 352 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 354 The format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters 355 (Figure 1) is identical to REG_FROM, RELAY_FROM and RELAY_TO 356 parameters. This document specifies only use of UDP relaying and 357 thus only protocol 17 is allowed. However, future documents may 358 specify support for other protocols. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Port | Protocol | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 | Address | 369 | | 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Type [TBD by IANA; 374 RELAYED_ADDRESS: 4650 375 MAPPED_ADDRESS: 4660] 376 Length 20 377 Port the UDP port number 378 Protocol IANA assigned, Internet Protocol number (17 for UDP) 379 Reserved reserved for future use; zero when sent, ignored 380 when received 381 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 382 IPv6 address" format 384 Figure 1: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 386 4.2. PEER_PERMISSION Parameter 388 The format of the PEER_PERMISSION parameter is shown in Figure 2. 389 The parameter is used for setting up and refreshing forwarding rules 390 and permissions at the data relay for data packets. The parameter 391 contains one or more sets of Port, Protocol, Address, Outbound SPI 392 (OSPI), and Inbound SPI (ISPI) values. One set defines a rule for 393 one peer address. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Port | Protocol | Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | Address | 404 | | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | OSPI | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | ISPI | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 | ... | 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Type [TBD by IANA; 4680] 417 Length length in octets, excluding Type and Length 418 Port the transport layer (UDP) port number of the peer 419 Protocol IANA assigned, Internet Protocol number (17 for UDP) 420 Reserved reserved for future use; zero when sent, ignored 421 when received 422 Address an IPv6 address, or an IPv4 address in "IPv4-Mapped 423 IPv6 address" format, of the peer 424 OSPI the outbound SPI value the registered host is using for 425 the peer with the Address and Port 426 ISPI the inbound SPI value the registered host is using for 427 the peer with the Address and Port 429 Figure 2: Format of the PEER_PERMISSION Parameter 431 4.3. HIP Connectivity Check Packets 433 The connectivity request messages are HIP UPDATE packets with a 434 CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets 435 contain a MAPPED_ADDRESS parameter (Figure 1). 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Priority | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Type [TBD by IANA; 4700] 446 Length 4 447 Priority the priority of a (potential) peer reflexive candidate 449 Figure 3: Format of the CANDIDATE_PRIORITY Parameter 451 5. Security Considerations 453 Same security considerations as with [RFC5770] apply also to this NAT 454 traversal mode. 456 If the data relay uses the same relayed address and port for multiple 457 registered hosts, it appears to all the peers, and their firewalls, 458 that all the registered hosts using the relay are at the same 459 address. Thus, a stateful firewall may allow packets pass from hosts 460 that would not normally be able to send packets to a peer behind the 461 firewall. Therefore, a HIP data relay SHOULD NOT re-use the port 462 numbers. If port numbers need to be re-used, the relay SHOULD have a 463 sufficiently large pool of port numbers and select ports from the 464 pool randomly to decrease the chances of a registered host obtaining 465 the same address that a another host behind the same firewall is 466 using. 468 6. Acknowledgements 470 This document re-uses many of the ideas proposed in various earlier 471 HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin 472 Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav 473 Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip 474 Matthews. 476 7. IANA Considerations 478 This section is to be interpreted according to [RFC5226]. 480 This document updates the IANA Registry for HIP Parameter Types 481 [RFC7401] by assigning new HIP Parameter Type values for the new HIP 482 Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Section 4.1), 483 and PEER_PERMISSION (defined in Section 4.2). 485 This document also updates the IANA Registry for HIP NAT traversal 486 modes [RFC5770] by assigning value for the NAT traversal mode ICE- 487 HIP-UDP (defined in Section 3.6). 489 This document defines additional registration types for the HIP 490 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow 491 registering with a HIP relay server for ESP relaying service: 492 RELAY_UDP_ESP (defined in Section 3.1); and performing server 493 reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in 494 Section 3.4). 496 8. References 498 8.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 506 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 507 RFC 7401, DOI 10.17487/RFC7401, April 2015, 508 . 510 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 511 Encapsulating Security Payload (ESP) Transport Format with 512 the Host Identity Protocol (HIP)", RFC 7402, 513 DOI 10.17487/RFC7402, April 2015, 514 . 516 [I-D.ietf-hip-rfc5203-bis] 517 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 518 Registration Extension", draft-ietf-hip-rfc5203-bis-09 519 (work in progress), June 2015. 521 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 522 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 523 DOI 10.17487/RFC5226, May 2008, 524 . 526 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 527 (ICE): A Protocol for Network Address Translator (NAT) 528 Traversal for Offer/Answer Protocols", RFC 5245, 529 DOI 10.17487/RFC5245, April 2010, 530 . 532 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 533 Keranen, Ed., "Basic Host Identity Protocol (HIP) 534 Extensions for Traversal of Network Address Translators", 535 RFC 5770, DOI 10.17487/RFC5770, April 2010, 536 . 538 8.2. Informative References 540 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 541 Henderson, "Host Identity Protocol", RFC 5201, 542 DOI 10.17487/RFC5201, April 2008, 543 . 545 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 546 Firewall Traversal Issues of Host Identity Protocol (HIP) 547 Communication", RFC 5207, DOI 10.17487/RFC5207, April 548 2008, . 550 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 551 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 552 DOI 10.17487/RFC5389, October 2008, 553 . 555 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 556 Relays around NAT (TURN): Relay Extensions to Session 557 Traversal Utilities for NAT (STUN)", RFC 5766, 558 DOI 10.17487/RFC5766, April 2010, 559 . 561 Authors' Addresses 563 Ari Keranen 564 Ericsson 565 Hirsalantie 11 566 02420 Jorvas 567 Finland 569 Email: ari.keranen@ericsson.com 571 Jan Melen 572 Ericsson 573 Hirsalantie 11 574 02420 Jorvas 575 Finland 577 Email: jan.melen@ericsson.com