idnits 2.17.1 draft-ietf-hip-nat-traversal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1502. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A rendezvous server MUST listen on UDP port number 50500 for incoming UDP encapsulated I1 packets. However, in this specific case with only initiator behind NAT, the rendezvous server MUST not relay the I1 packets at all because the UDP hole punching does not work. Instead, the rendezvous server replies to the initiator with a NOTIFY message that includes the responder's locator in VIA_RVS parameter. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 2006) is 6365 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 (-10) exists of draft-ietf-hip-base-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. 'I-D.ietf-hip-esp') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. 'I-D.ietf-hip-mm') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. 'I-D.ietf-hip-rvs') == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.nikander-esp-beet-mode' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-07 == Outdated reference: A later version (-04) exists of draft-irtf-hiprg-nat-02 == Outdated reference: A later version (-04) exists of draft-srisuresh-behave-p2p-state-03 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group V. Schmitt 3 Internet-Draft NEC 4 Expires: May 25, 2007 A. Pathak 5 IIT Kanpur 6 M. Komu 7 HIIT 8 L. Eggert 9 M. Stiemerling 10 NEC 11 November 21, 2006 13 HIP Extensions for the Traversal of Network Address Translators 14 draft-ietf-hip-nat-traversal-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 This document may not be modified, and derivative works of it may not 23 be created, except to publish it as an RFC and to translate it into 24 languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 25, 2007. 44 Copyright Notice 46 Copyright (C) The Internet Society (2006). 48 Abstract 49 This document specifies extensions to Host Identity Protocol (HIP) to 50 support traversal of Network Address Translator (NAT) middleboxes. 51 The traversal mechanism tunnels HIP control and data traffic over UDP 52 and enables HIP initiators which MAY be behind NATs to contact HIP 53 responders which MAY be behind another NAT. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 5 62 3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 5 63 3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 6 65 3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 7 66 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 7 67 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 7 68 3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 8 69 3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 8 70 3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 9 71 3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 12 72 3.3.3. Use of the Rendezvous Service when only the 73 Initiator Is Behind NAT . . . . . . . . . . . . . . . 14 74 3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 15 75 3.4.1. Rendezvous Client Registration From Behind NAT . . . . 15 76 3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 17 77 3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 19 78 3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 21 79 3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 21 80 3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 23 81 3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 25 82 3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 26 83 3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 27 84 3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 27 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 90 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 91 Appendix A. Document Revision History . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 93 Intellectual Property and Copyright Statements . . . . . . . . . . 33 95 1. Introduction 97 The Host Identity Protocol (HIP) describes a new communication 98 mechanism for Internet hosts [RFC4423]. It introduces a new 99 namespace and protocol layer between the network and transport layers 100 that decouples the identifier and locator roles to support e.g. 101 mobility and multihoming in the Internet architecture. 103 The HIP protocol [I-D.ietf-hip-base] cannot operate across Network 104 Address Translator (NAT) middleboxes, as described in 105 [I-D.irtf-hiprg-nat]. Several different flavors of NATs exist 106 [RFC2663]. This document describes HIP extensions for the traversal 107 of both Network Address Translator (NAT) and Network Address and Port 108 Translator (NAPT) middleboxes. It generally uses the term NAT to 109 refer to both types of middleboxes, unless it needs to distinguish 110 between the two types. 112 Three basic cases exist for NAT traversal. In the first case, only 113 the initiator of a HIP base exchange is located behind a NAT. In the 114 second case, only the responder of a HIP base exchange is located 115 behind a NAT. The respective peer host is assumed to be in the 116 public Internet in both cases. In the third case, both parties are 117 located behind (different) NATs. This document describes extensions 118 for the first case in Section 3.3, for the second case in Section 3.4 119 and in Section 3.5 for the third case. 121 The mechanisms described here also cover use of rendezvous server 122 from NATted environments. The use rendezvous server MUST be used 123 when the responder is behind a NAT and the rendezvous MUST be located 124 in a public network. Chaining of NAT enabled rendezvous servers is 125 not possible, altough there may be other kind of rendezvous servers 126 on the path. The limitation of the described rendezvous mechanisms 127 is that it requires NAT boxes supporting both endpoint independent 128 mapping [I-D.srisuresh-behave-p2p-state]. 130 The mechanisms described in this document are based on encapsulating 131 both the control and data traffic in UDP in order to traverse NAT(s). 132 The data traffic is assumed to be ESP. Other types of data traffic 133 are out of scope. 135 The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm], 136 allow HIP hosts to change network location during the lifetime of a 137 HIP association. Consequently, hosts need to start using the 138 proposed NAT traversal mechanisms after a mobility event relocates 139 one or both peers behind a NAT. They may also stop using the 140 proposed mechanisms if they both relocate to the public Internet. 142 Finally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 143 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 2. Detecting NATs 149 In order to know whether to use the NAT traversal mechanisms, HIP 150 hosts need to detect presence of NAT middleboxes between them. This 151 document does not describe any NAT detection mechanism but rather 152 assumes the NAT is detected using some external mechanism. Hence, no 153 special HIP parameters are required in HIP control messages to detect 154 NATs. The NAT detection MUST occur prior to base exchange, or after 155 node movement, prior to sending UPDATE messages. 157 For example, STUN [RFC3489] offers a generic mechanism using which a 158 host behind NAT can detect the presence of NAT and type of NAT 159 present. In STUN, the host contacts a STUN server which is located 160 always in public network and the STUN server replies back letting the 161 host know whether the host is behind NAT or in public network. STUN 162 can be used to detect NATs in all but one case where both of the host 163 are behind the same NAT. This is commonly referred as the Hairpin 164 translation [I-D.srisuresh-behave-p2p-state] . The hairpin 165 translation poses an unnecessary overhead in terms of UDP processing 166 of packets and routing of packets through the NAT despite the hosts 167 being located within the same network. 169 As a solution to the hairpin problem, an implementation MAY choose 170 first to send I1 packets without UDP encapsulation and wait for the 171 response for an implementation specific time. If the initiator does 172 not get a reply from the responder, it then can start retransmitting 173 I1 packets UDP encapsulated. This approach solves the hairpin 174 problem, but incurs extra latency for the HIP connection. 176 3. HIP Across NATs 178 HIP based communications between two hosts consists effectively of 179 HIP control traffic and ESP encrypted data traffic. Before ESP data 180 traffic can be sent, the hosts send HIP control messages to negotiate 181 algorithms and exchange keys. After this, the hosts can start 182 sending encrypted ESP data traffic. 184 The HIP based communications defined in [I-D.ietf-hip-base] works 185 well in public networks. However, this does not work with some 186 legacy NATs which just drop HIP control traffic and ESP data traffic. 187 As a solution for this, we propose UDP encapsulation of control and 188 data traffic using a specific scheme described in this document. The 189 scheme also allows hosts behind NATs to act as servers. 191 [RFC3948] describes UDP encapsulation of IPsec ESP transport and 192 tunnel mode. This document only describes the changes required for 193 UDP encapsulation of BEET mode [I-D.nikander-esp-beet-mode]. 195 3.1. Packet Formats 197 This section defines the UDP-encapsulation packet format for HIP base 198 exchange and control traffic, IPsec ESP BEET-mode traffic and NAT 199 keep-alive. 201 3.1.1. Control Traffic 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Source Port | Destination Port | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Length | Checksum | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 ~ HIP Header and Parameters ~ 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: Format for UDP-encapsulated HIP control traffic. 217 Figure 1 shows how HIP control packets are encapsulated within UDP. 218 A minimal UDP packet carries a complete HIP packet in its payload. 219 Contents of the UDP source and destination ports are described below. 220 The UDP length and checksum field MUST be computed as described in 221 [RFC0768]. The HIP header and parameter follow the conventions 222 [I-D.ietf-hip-base] with the exception that the HIP header checksum 223 MUST be zero. The HIP headers checksum is not used because it is 224 redundant and requires the use of inner addresses (extra complexity 225 for UDP-NAT transformations). 227 3.1.2. Control Channel Keep-Alives 229 The keep-alive for control channel are basically UDP encapsulated 230 UPDATE packets [I-D.ietf-hip-base]. The UPDATE packets MAY contain 231 HIP parameters. The NAT traversal mechanisms encapsulate these 232 UPDATE packets within the payload of UDP packets. 234 3.1.3. Data Traffic 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Source Port | Destination Port | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Length | Checksum | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 ~ ESP Header ~ 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic. 250 Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated 251 within UDP. Again, a minimal UDP packet carries the ESP packet in 252 its payload. Contents of the UDP source and destination ports are 253 described in later sections. The UDP length and checksum field MUST 254 be computed as described in [RFC0768]. 256 3.1.4. FROM_NAT Parameter 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 | Address | 265 | | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | UDP Port | Padding | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ] 272 Length 18 273 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 274 UDP Port A UDP port number 276 Figure 3: Format for FROM_NAT Parameter 278 Figure 3 shows FROM_NAT parameter. The use of this parameter is 279 described in later sections. 281 3.1.5. VIA_RVS_NAT Parameter 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type | Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 | Address | 290 | | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | UDP Port | Padding | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ] 297 Length 16 298 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 299 UDP Port A UDP port 301 Figure 4: Format for VIA_RVS_NAT Parameter 303 Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for 304 diagnostic purposes, similarly as VIA_RVS parameter in 305 [I-D.ietf-hip-rvs]. The exact use of this parameter is described in 306 later sections. 308 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP 310 [RFC3948] describes UDP encapsulation of IPsec ESP transport and 311 tunnel mode. This section describes the changes required for UDP 312 encapsulation of BEET mode. 314 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP 316 In BEET IPsec mode, any present transport-layer checksums in the 317 payload data are consequently based on the HITs. The packet MUST 318 then undergo BEET-mode ESP cryptographic processing as defined in 319 Section 5.3 of [I-D.nikander-esp-beet-mode]. 321 The resulting BEET-mode packet is then UDP encapsulated. For this 322 purpose, a UDP header MUST be inserted between the IP and ESP header. 323 The source and destination ports are filled in as defined in later 324 sections. The UDP checksum MUST be calculated based on an IP header 325 that contains the outer addresses of the SA. The other fields of the 326 UDP header are computed as described in [RFC0768]. 328 The resulting UDP packet MUST then undergo BEET IP header processing 329 as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. 331 Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a 332 TCP packet. 334 ORIGINAL TCP PACKET: 335 +------------------------------------------+ 336 | inner IPv6 hdr | ext hdrs | | | 337 | with HITs | if present | TCP | Data | 338 +------------------------------------------+ 340 PACKET AFTER BEET-MODE ESP PROCESSING: 341 +----------------------------------------------------------+ 342 | inner IPv6 hdr | ESP | dest | | | ESP | ESP | 343 | with HITs | hdr | opts.| TCP | Data | Trailer | ICV | 344 +----------------------------------------------------------+ 345 |<------- encryption -------->| 346 |<----------- integrity ----------->| 348 FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING: 349 +------------------------------------------------------------+ 350 | outer IPv4 | UDP | ESP | dest | | | ESP | ESP | 351 | hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV | 352 +------------------------------------------------------------+ 353 |<------- encryption -------->| 354 |<----------- integrity ----------->| 356 Figure 5: UDP Encapsulation of an IPsec BEET-mode ESP packet 357 containing a TCP segment. 359 3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP 361 An incoming UDP-encapsulated IPsec BEET-mode ESP packet is 362 decapsulated as follows. First, if the UDP checksum is invalid, then 363 the packet MUST be dropped. Then, the packet MUST be verified as 364 defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data 365 contained in the payload of the UDP packet MUST be decrypted as 366 described in [I-D.nikander-esp-beet-mode]. 368 The NAT traversal methods described in this section are based on 369 connection reversal and UDP hole punching similar to 370 [I-D.ietf-behave-nat-udp]. However, the methods in this section are 371 adapted for HIP purposes, especially the rendezvous server in mind. 373 3.3. Initiator Behind NAT 375 This section discusses mechanisms to reach a HIP responder located in 376 publicly addressable network by a HIP initiator that is located 377 behind a NAT. The case where the responder is using a rendezvous 378 service is also described. 380 Table 1 lists some short-hand notations used in this section. For 381 simplicity, the ports mangled by NAT are presented as example port 382 numbers (11111 and 22222) instead of symbolic ones. In the examples, 383 we assume that the NAT(s) timeout after I1-R1 exchange for 384 illustration purposes, hence there are different port numbers for 385 I2-R2 exchange. 387 +------------------+------------------------------------------------+ 388 | Notation | Explanation | 389 +------------------+------------------------------------------------+ 390 | HIT-I | Initiator's HIT | 391 | HIT-R | Responder's HIT | 392 | IP-I | Initiator's IP address | 393 | IP-R | Responder's IP address | 394 | IP-RVS | IP address of the responder's rendezvous | 395 | | server | 396 | IP-NAT-I | Public IP of the NAT of the initiator | 397 | IP-NAT-R | Public IP of the NAT of the responder | 398 | UDP(50500,11111) | UDP packet with source port 50500 and | 399 | | destination port 11111 | 400 | UDP(11111,22222) | Example port numbers mangled by a NAT | 401 | UDP(44444,22222) | Port 44444 is used throughout the examples to | 402 | | denote the NAT mangled source port of I2 as | 403 | | received by the rendezvous server during the | 404 | | registration | 405 +------------------+------------------------------------------------+ 407 Table 1: Notations Used in This Section 409 3.3.1. NAT Traversal of HIP Control Traffic 411 This section describes the details of enabling NAT traversal for HIP 412 control traffic for the base exchange [I-D.ietf-hip-base] through UDP 413 encapsulation for the case when initiator of the association is 414 located behind a NAT and responder is located in publicly addressable 415 network. UDP-encapsulated HIP control traffic MUST use the packet 416 formats described in Section 3.1. When sending UDP-encapsulated HIP 417 control traffic, a HIP implementation MUST zero the HIP header 418 checksum before calculating the UDP checksum. The receiver MUST only 419 verify the correctness of the UDP checksum and MUST NOT verify the 420 checksum of the HIP header. 422 The initiator of a UDP-encapsulated HIP base exchange MUST use the 423 UDP destination port 50500 for all control packets it sends. It is 424 RECOMMENDED to use 50500 as the source port as well, but an 425 implementation MAY use a (randomly selected) unoccupied source port. 426 If it uses a random source port, it MUST listen for and accept 427 arriving HIP control/ESP Data packets on this port until the 428 corresponding HIP association is torn down. The random source port 429 is RECOMMENDED to be in the range of the dynamic and private ports 430 (49152-65535). Using a random source port instead of a fixed one 431 makes it possible to have multiple clients behind a NAT middlebox 432 that does only address translation but no port translation. This is 433 referred to as port overloading in [I-D.ietf-behave-nat-udp]. 435 The responder of a UDP-encapsulated HIP base exchange MUST use 50500 436 as the source port for all UDP-encapsulated control packets it sends. 437 The source address for all the packets that the responder sends MUST 438 be the same as the IP address on which responder receives packets 439 from initiator. The responder MUST NOT respond to any arriving UDP- 440 encapsulated control message with an decapsulated reply. HIP 441 implementations that implement the NAT traversal mechanisms MUST 442 process UDP-encapsulated base exchange messages equivalently to 443 decapsulated messages, i.e., according to [I-D.ietf-hip-base]. 445 The remainder of this section clarifies this process through an 446 example which is illustrated in Figure 6. It shows an initiator with 447 the private IP address I behind a NAT. The NAT has the public IP 448 address as NAT. The responder is located in the public Internet at 449 the IP address R. 451 +---+ +---+ +---+ 452 | |----(1)--->| |---------------(2)-------------->| | 453 | | | N | | | 454 | |<---(4)----| A |<--------------(3)---------------| | 455 | I | | T | | R | 456 | |----(5)--->| - |---------------(6)-------------->| | 457 | | | I | | | 458 | |<---(8)----| |<--------------(7)---------------| | 459 +---+ +---+ +---+ 461 1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 462 2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R) 463 3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I) 464 4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 465 5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 466 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R) 467 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I) 468 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 470 Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator 471 behind a NAT, responder on the public Internet). 473 Before beginning the base exchange, the initiator detects that it is 474 behind a NAT. The initiator starts the base exchange by sending a 475 UDP-encapsulated I1 packet to the responder. According to the rules 476 specified above, the source IP address of this I1 packet is IP-I and 477 its source UDP port is 50500. It is addressed to IP-R on port 50500. 478 The NAT in Figure 6 forwards the I1 but substitutes the source 479 address IP-I with its own public address IP-NAT-I and the source UDP 480 port 50500 with 11111. 482 When the responder in Figure 6 receives the UDP-encapsulated I1 483 packet on UDP port 50500, it processes it according to 484 [I-D.ietf-hip-base]. The responder replies back with an R1 using the 485 addresses and port information of I1. Thus, the R1 packet is 486 destined to the source IP address and UDP port of the I1, i.e., IP 487 address IP-NAT-I and port 11111. The NAT receives the I1 and 488 substitutes the destination of this packet with the initiator address 489 (IP-I) and port information (50500). 491 The initiator receives a UDP-encapsulated R1 packet from the 492 responder and processes it according to [I-D.ietf-hip-base]. When it 493 responds with a UDP-encapsulated I2 packet, it uses the same IP 494 source and destination addresses and UDP source and destination ports 495 that it used for sending the corresponding I1 packet, i.e., the 496 packet is addressed from IP-I port 50500 to IP-R port 50500. The NAT 497 again substitutes the source information. To illustrate timeout, the 498 NAT chooses a different source port (22222) for the I2 than for the 499 I1 (11111) in this case. 501 When a responder receives a UDP-encapsulated I2 packet destined to 502 UDP port 50500, it MUST use the UDP source port contained in this 503 packet for further HIP communications with the initiator. It then 504 processes the I2 packet according to [I-D.ietf-hip-base]. When it 505 responds with an R2 message, it UDP-encapsulates the message, using 506 the UDP source port of the I2 packet as the destination UDP port, and 507 sends it to the source IP address of the I2 packet, i.e., it sends 508 the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT 509 again replaces the destination information in the R2 with IP-I port 510 50500 512 Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT 513 state to persist. This means that the NAT uses the same port for the 514 I1-R1 exchange to translate as the I2-R2 exchange. However, an 515 implementation MUST handle even the case where the NAT state times 516 out between the two exchanges and the I1 and I2 arrive from different 517 UDP source ports and/or IP addresses, as shown in Figure 6. 519 3.3.2. NAT Traversal of HIP Data Traffic 521 This section describes the details of enabling NAT traversal of HIP 522 data traffic. As described in Section 3, HIP data traffic is carried 523 in UDP-encapsulated IPsec BEET-mode ESP packets. 525 3.3.2.1. IPsec BEET-Mode Security Associations 527 During the HIP base exchange, the two peers exchange parameters that 528 enable them to define a pair of IPsec ESP security associations 529 (SAs), as described in [I-D.ietf-hip-esp]. As mentioned in 530 Section 3.3.1, when two peers perform a UDP-encapsulated base 531 exchange, they MUST define a pair of IPsec SAs that result in UDP- 532 encapsulated BEET-mode ESP data traffic. 534 The management of encryption and authentication protocols and of 535 security parameter indices (SPIs) occurs as defined in 536 [I-D.ietf-hip-esp]. Additional SA parameters, such as IP addresses 537 and UDP ports, MUST be defined according to the following 538 specification. Two SAs MUST be defined on each host for one HIP 539 association; one for outgoing data and another one for incoming data. 541 The initiator MUST use UDP destination port 50500 for all UDP- 542 encapsulated ESP packets it sends. It MAY also use port 50500 as 543 source port or it MAY use a random source port. If it uses a random 544 source port, it MUST listen for and accept arriving UDP-encapsulated 545 ESP packets on this port until the corresponding HIP association is 546 torn down. 548 The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST 549 use 50500 as the source port for all UDP-encapsulated ESP packets it 550 sends. The destination port is the port from which the responder is 551 receiving UDP encapsulated ESP data from the initiator. 553 Both initiator and responder of a HIP association that uses the NAT 554 traversal mechanism as described in this draft MUST define BEET mode 555 with UDP encapsulation as IPsec mode for SA after a successful base 556 exchange. The inner source address MUST be local HIT used during 557 base exchange and inner destination address MUST be HIT of the 558 respective peer. The other parts of the SA are described in 559 individual sections. 561 3.3.2.1.1. Security Associations at the Initiator 563 The initiator of a UDP-encapsulated base exchange defines its 564 outbound SA as shown in Table 2 565 +--------------+----------------------------------------------------+ 566 | Field | Value | 567 +--------------+----------------------------------------------------+ 568 | Outer src | Same local IP address from which the base exchange | 569 | address | packets were transmitted | 570 | Outer dst | Same peer IP address to which base exchange | 571 | address | packets were transmitted | 572 | UDP src port | Same port number as chosen for I2 packet in base | 573 | | exchange | 574 | UDP dst port | Port 50500 | 575 +--------------+----------------------------------------------------+ 577 Table 2: Outbound SA at initiator 579 The initiator of a UDP-encapsulated base exchange defines its inbound 580 SA as shown in Table 3 582 +--------------+----------------------------------------------------+ 583 | Field | Value | 584 +--------------+----------------------------------------------------+ 585 | Outer src | Same peer IP address to which base exchange | 586 | address | packets were transmitted | 587 | Outer dst | Same local IP address from which the base exchange | 588 | address | packets were transmitted | 589 | UDP src port | Port 50500 | 590 | UDP dst port | Initiator MUST use the UDP source port it uses in | 591 | | the outbound SA here | 592 +--------------+----------------------------------------------------+ 594 Table 3: Inbound SA at initiator 596 3.3.2.1.2. Security Associations at the Responder 598 The responder of a UDP-encapsulated base exchange defines its 599 outbound SA shown in Table 4. 601 +-------------+-----------------------------------------------------+ 602 | Field | Value | 603 +-------------+-----------------------------------------------------+ 604 | Outer src | Same local IP address from which the base exchange | 605 | address | packets were transmitted | 606 | Outer dst | Peer IP address of the I2 packet received during | 607 | address | the base exchange | 608 | UDP src | Port 50500 | 609 | port | | 610 | UDP dst | Source UDP port of the I2 packet received from the | 611 | port | initiator during base exchange | 612 +-------------+-----------------------------------------------------+ 613 Table 4: Outbound SA at Responder 615 Similarly, the responder of a UDP-encapsulated base exchange defines 616 its inbound SA as shown in Table 5 618 +-------------+-----------------------------------------------------+ 619 | Field | Value | 620 +-------------+-----------------------------------------------------+ 621 | Outer src | Source IP address of the I2 packet received from | 622 | address | the initiator during base exchange | 623 | Outer dst | Same local IP address from which the base exchange | 624 | address | packets were transmitted | 625 | UDP src | Source UDP port of the I2 packet received from the | 626 | port | initiator during base exchange | 627 | UDP dst | Port 50500 | 628 | port | | 629 +-------------+-----------------------------------------------------+ 631 Table 5: Inbound SA at responder 633 3.3.3. Use of the Rendezvous Service when only the Initiator Is Behind 634 NAT 636 The rendezvous extensions for HIP without NAT traversal have been 637 defined in [rvs]. This section addresses only the scenario where a 638 NATted HIP node uses rendezvous service to contact another HIP node 639 in a publicly addressable network. Figure 7 illustrates the 640 mechanism described in this section. 642 A rendezvous server MUST listen on UDP port number 50500 for incoming 643 UDP encapsulated I1 packets. However, in this specific case with 644 only initiator behind NAT, the rendezvous server MUST not relay the 645 I1 packets at all because the UDP hole punching does not work. 646 Instead, the rendezvous server replies to the initiator with a NOTIFY 647 message that includes the responder's locator in VIA_RVS parameter. 649 Upon receiving the NOTIFY with the locators of the responder through 650 the NAT, the initiator MUST send an I1 to the responder. However, it 651 MUST continue retransmissions using the RVS location. This is 652 mandatory because NOTIFY messages are not protected with signatures 653 and can be forged by a rogue host. 655 When the initiator receives an R1 through the NAT, the responder 656 verifies the integrity of the packet and replies with an I2. The 657 responder should be aware that the I2 may arrive from a different 658 port than the I1. In such a case, the responder should send the R2 659 to the source port of I2. 661 +---+ +---+ +-------+ +---+ 662 | |----(1)--->| |---------------(2)-->| | | | 663 | | | | | RVS R | | | 664 | |<---(4)----| |<--------------(3)---| | | | 665 | | | | +-------+ | | 666 | | | N | | | 667 | |----(5)--->| A |---------------(6)-------------->| | 668 | I | | T | | R | 669 | |<---(8)----| - |<--------------(7)---------------| | 670 | | | T | | | 671 | |----(9)--->| |---------------(10)------------->| | 672 | | | | | | 673 | |<---(11)---| |<--------------(12)--------------| | 674 +---+ +---+ +---+ 676 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 677 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 678 3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 679 NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R)) 680 4. IP(IP-RVS, IP-I) UDP(50500, 50500) 681 NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R)) 682 5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 683 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R) 684 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I) 685 8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 686 9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 687 10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R) 688 11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I) 689 12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 691 Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS 692 (initiator behind a NAT, responder and RVS on the public Internet). 694 3.4. Responder Behind NAT 696 This section discusses mechanisms to reach a HIP responder that is 697 located behind a NAT. This section assumes that the initiator is 698 located on publicly addressable network. The initiator contacts the 699 responder through an RVS server. 701 3.4.1. Rendezvous Client Registration From Behind NAT 703 The rendezvous client registration [rvs] describes the case when 704 rendezvous client is present in publicly addressable network. This 705 section defines an extension to the rendezvous client registration 706 for the case when the rendezvous client has detected that it is 707 behind a NAT. The process in the NAT case is identical to the case 708 without NAT, except that UDP encapsulation is used. The registration 709 is illustrated in Figure 8. 711 A node behind a NAT MUST first register to the RVS when it is going 712 to act as a responder for some other nodes. The node (i.e. 713 rendezvous client) performs a base exchange with the RVS over UDP as 714 described in Section 3.3 by sending I1 UDP encapsulated and 50500 as 715 destination port number. RVS sends REG_INFO parameter in R1 to which 716 rendezvous client replies with REG_REQ in I2. Both I1 and R1 are 717 sent using UDP. If RVS grants service to the rendezvous client, it 718 MUST store the source IP address and source port number of the I2 UDP 719 packet that it had received from the rendezvous client during base 720 exchange. The source IP address belongs to the NAT and the source 721 port number is the NAT mangled port. RVS then replies with REG_RESP 722 in R2 over UDP. If the registration process results in a successful 723 REG_RESP, the rendezvous client MUST send NAT keepalives 724 (Section 3.1.2) to keep the mapping in the NAT with the RVS open. 725 The NAT keepalives sent from rendezvous client to the RVS MUST have 726 the same source port as the I2 packet. 728 When the RVS receives an I1 packet from a HIP node to be relayed to 729 the successfully registered rendezvous client behind NAT, RVS MUST 730 relay the I1 over UDP with the destination port as the one stored 731 during registration. The RVS also zeroes the HIP header checksum of 732 the I1. This process is explained in Section 3.4.2. 734 +---+ +---+ +---+ 735 | |----(1)--->| |---------------(2)-------------->| | 736 | | | N | | | 737 | |<---(4)----| A |<--------------(3)---------------| | 738 | I | | T | | R | 739 | |----(5)--->| - |---------------(6)-------------->| | 740 | | | I | | | 741 | |<---(8)----| |<--------------(7)---------------| | 742 +---+ +---+ +---+ 744 Initiator = Rendezvous client, Responder = Rendezvous server 746 1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 747 2. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I1(HIT-I, HIT-R) 748 3. IP(IP-R, IP-NAT-I) UDP(50500, 33333) 749 R1(HIT-R, HIT-I, REG_INFO) 750 4. IP(IP-R, IP-I) UDP(50500, 50500) 751 R1(HIT-R, HIT-I, REG_INFO) 752 5. IP(IP-I, IP-R) UDP(50500, 50500) 753 I2(HIT-I, HIT-R, REG_REQ) 754 6. IP(IP-NAT-I, IP-R) UDP(44444, 50500) 755 I2(HIT-I, HIT-R, REG_REQ) 756 7. IP(IP-R, IP-NAT-I) UDP(50500, 44444) 757 R2(HIT-R, HIT-I, REG_RES) 758 8. IP(IP-R, IP-I) UDP(50500, 50500) 759 R2(HIT-R, HIT-I, REG_RES) 761 Figure 8: Rendezvous NAT Client Registration 763 3.4.2. NAT Traversal of HIP Control Traffic 765 This section describes the details of enabling NAT traversal for base 766 exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for 767 the case when the HIP initiator is on publicly addressable network 768 and the HIP responder is behind NAT. The process is illustrated in 769 Figure 9. 771 Before the HIP base exchange starts, the responder of the HIP base 772 exchange MUST have completed a successful rendezvous client 773 registration using the scheme defined in Section 3.4.1. 775 The initiator of the HIP base exchange sends a plain I1 packet 776 (without UDP encapsulation) to the RVS as described in [rvs]. The 777 RVS relays the inbound I1 packet to the registered rendezvous client. 778 In this case, the incoming I1 is not UDP encapsulated, but the 779 rendezvous client has registered using UDP. 781 To relay the I1 packet, RVS SHOULD zero the HIP header checksum from 782 the I1 packet. RVS must add a FROM parameter, as described in [rvs], 783 which contains the IP address of HIP initiator. The FROM parameter 784 is integrity protected by a RVS_HMAC as described in [rvs]. RVS 785 replaces the destination IP address in the IP header of the packet 786 with IP that it had stored during the rendezvous client registration 787 (which is the IP address of the outermost NAT behind which rendezvous 788 client is located). It MUST then encapsulate the I1 packet within 789 UDP. The source port in the UDP header MUST be 50500 and the 790 destination port MUST be the same as the source port number (44444) 791 of the I2 packet which it had stored during the registration process. 792 RVS then recomputes the IP header checksum and sends the packet. 794 +-------+ 795 | | 796 +----->| RVS +-----+ +----+ 797 +---+ | | | | | | +---+ 798 | |---(1)---+ +-------+ +----(2)--->| |---(3)--->| | 799 | | | N | | | 800 | |<------------------(5)--------------------| A |<--(4)----| | 801 | I | | T | | R | 802 | |-------------------(6)------------------->| - |---(7)--->| | 803 | | | R | | | 804 | |<------------------(9)--------------------| |<--(8)----| | 805 +---+ +----+ +---+ 807 1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R) 808 2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 809 I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) 810 3. IP(IP-RVS, IP-R) UDP(50500, 50500) 811 I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) 812 4. IP(IP-R, IP-I) 813 UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) 814 5. IP(IP-NAT-R, IP-I) 815 UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500) 816 6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R) 817 7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 818 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 819 9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I) 821 Figure 9: UDP-encapsulated HIP base exchange (initiator on public 822 Internet, responder behind a NAT). 824 The relayed I1 packet travels from RVS to the NAT. The NAT changes 825 the destination IP address of the UDP encapsulated I1 packet, and the 826 destination port number in the UDP header. The responder accepts the 827 packet from the RVS and processes it according to [rvs]. The 828 resulting R1 must be encapsulated within UDP. The responder MAY 829 append a VIA_RVS_NAT parameter to the message, which contains the IP 830 address of the rendezvous and the port the rendezvous used for 831 relaying the R1. The RECOMMENDED source port is 50500 and the 832 destination port number MUST be 50500. The destination address in 833 the IP header MUST be the same as the one specified in the FROM 834 parameter of the relayed I1 packet. 836 The initiator MUST listen on port 50500 and it receives the UDP 837 encapsulated R1. After verifying the HIP packet, it concludes that 838 the responder is behind a NAT because the packet was UDP 839 encapsulated. The initiator processes the R1 control packet 840 according to [I-D.ietf-hip-base] and replies using I2 that is UDP 841 encapsulated. The addresses and ports are derived from the received 842 R1. 844 The NAT translates and forwards the UDP encapsulated I2 packet to the 845 responder. The resulting R2 packet is also UDP encapsulated using 846 the address and port information from the received I2 packet. 848 3.4.3. NAT Traversal of HIP Data Traffic 850 After a successful base exchange, both of the HIP nodes have all the 851 parameters with them needed to establish UDP BEET mode Security 852 Association. The following section describe inbound and outbound 853 security associations at initiator and responder. 855 3.4.3.1. Security Associations at the Initiator 857 The initiator of a base exchange defines its outbound SA as shown in 858 Table 6 860 +--------------+----------------------------------------------------+ 861 | Field | Value | 862 +--------------+----------------------------------------------------+ 863 | Outer src | Same local IP address from which the base exchange | 864 | address | packets were transmitted | 865 | Outer dst | Same peer IP address from which R2 packet was | 866 | address | received during base exchange | 867 | UDP src port | Port 50500 | 868 | UDP dst port | Source port of incoming R2 packet during base | 869 | | exchange | 870 +--------------+----------------------------------------------------+ 872 Table 6: Outbound SA at initiator 874 The initiator of a base exchange defines its inbound SA as shown in 875 Table 7 876 +--------------+----------------------------------------------------+ 877 | Field | Value | 878 +--------------+----------------------------------------------------+ 879 | Outer src | Same peer IP address from which R2 packet was | 880 | address | received during base exchange | 881 | Outer dst | Same local IP address from which the base exchange | 882 | address | packets were transmitted | 883 | UDP src port | Source port of incoming R2 packet during base | 884 | | exchange | 885 | UDP dst port | Port 50500 | 886 +--------------+----------------------------------------------------+ 888 Table 7: Inbound SA at initiator 890 3.4.3.2. Security Associations at the Responder 892 The responder of a UDP-encapsulated base exchange defines its 893 outbound SA shown in Table 8. 895 +--------------+----------------------------------------------------+ 896 | Field | Value | 897 +--------------+----------------------------------------------------+ 898 | Outer src | Same local IP address from which the base exchange | 899 | address | packets were transmitted | 900 | Outer dst | Same peer IP as that used during base exchange | 901 | address | | 902 | UDP src port | Same as source port chosen during base exchange | 903 | UDP dst port | Port 50500 | 904 +--------------+----------------------------------------------------+ 906 Table 8: Outbound SA at Responder 908 Similarly, the responder of a UDP-encapsulated base exchange defines 909 its inbound SA as shown in Table 9 911 +--------------+----------------------------------------------------+ 912 | Field | Value | 913 +--------------+----------------------------------------------------+ 914 | Outer src | Source peer IP address as used in base exchange | 915 | address | | 916 | Outer dst | Same local IP address from which the base exchange | 917 | address | packets were transmitted | 918 | UDP src port | Port 50500 | 919 | UDP dst port | Same as source port chosen during base exchange | 920 +--------------+----------------------------------------------------+ 922 Table 9: Inbound SA at responder 924 3.5. Both Hosts Behind NAT 926 This section describes the details of enabling NAT traversal for HIP 927 control and ESP data traffic, such as the base exchange 928 [I-D.ietf-hip-base], through UDP encapsulation, for the case when the 929 HIP initiator and the HIP responder are both behind two separate 930 NATs. The described mechanism applies also when the hosts are behind 931 the same NAT but may result in inefficient routing paths, unless the 932 countermeasures described in section Section 2 are followed. The 933 limitation of this approach is that it requires that the NAT boxes 934 support endpoint independent mapping 935 [I-D.srisuresh-behave-p2p-state]. 937 The registration and rendezvous relay are handled similarly as 938 described in Section 3.3.3 and Section 3.4.1. Now that both hosts 939 are behind NATs, both the initiator (Section 3.3) and responder 940 (Section 3.4) mechanisms are combined here. 942 3.5.1. NAT Traversal of HIP Control Traffic 944 This section describes traversal mechanism for HIP control traffic in 945 the situation when both the initiator and the responder are behind 946 NATs. Both hosts MUST first detect using external mechanism that 947 they are located behind NAT. The RVS MUST be located on publicly 948 addressable network. Before initiator begins the base exchange, the 949 responder MUST have completed a successful rendezvous client 950 registration with the RVS using the mechanism described in 951 Section 3.4.1. 953 Initiator of the HIP base exchange starts the base exchange by 954 sending an UDP encapsulated I1 packet to RVS. The UDP packet MUST 955 have destination port number 50500 and initiator is RECOMMENDED to 956 use 50500 as source port number. RVS MUST listen on UDP port 50500. 957 RVS MUST accept the packet as described in Section 3.3.3. As there 958 has been a successful rendezvous client registration between the 959 responder and the RVS as described in Section 3.4.1, the RVS knows 960 the port number which it can use to communicate with the responder 961 through the NAT. RVS MUST add a FROM_NAT parameter to the I1 packet. 962 The FROM_NAT parameter contains the source address of the I1 packet, 963 which is effectively the address of the outermost NAT of the 964 initiator. The RVS copies the source port of the UDP encapsulated I1 965 packet into the port number field of the FROM_NAT parameter. The 966 FROM_NAT parameter is integrity protected by an RVS_HMAC as described 967 in [rvs]. It MUST replace the destination IP address of the I1 968 packet by the one it had stored earlier during rendezvous client 969 registration. It MUST replace source IP address of I1 packet with 970 its own address. UDP source port of the relayed I1 packet MUST be 971 50500 and destination port MUST be the same as one it had stored 972 during the client rendezvous registration. It MUST recompute the IP 973 header checksum. 975 In this case, in which the I1 was UDP encapsulated and the rendezvous 976 client is also behind a NAT, the rendezvous server sends two packets. 977 First, it MUST relay the I1 packet to the responder (rendezvous 978 client) using UDP. Second, it MUST send the locator and port (as 979 observed by the rendezvous) of the responder in a VIA_RVS_NAT 980 parameter in a NOTIFY packet to the inititiator. However, this will 981 actually launch two parallel base exchanges. In the first case, the 982 initiator receives the NOTIFY message, and acts on it as described in 983 section Section 3.3.3, i.e., it sends an I1 directly to the address 984 in the VIA_RVS_NAT parameter and continues to retransmit packet 985 through the RVS. In the second case, the responder will receive the 986 I1 relayed by the rendezvous. The responder acts as described in 987 section Section 3.4.2 by replying with an R1. 989 This scheme launches two parallel exchanges, one of which is phased 990 later than the other. Although this kind of operation is not usually 991 very desirable, it is essential to guarantee successful NAT hole 992 punching. The base exchange has been designed to handle simultaneous 993 base exchanges and the race between the two parallel base exchange 994 eventually terminates after initiator is in established state. 996 +---+ +----+ +-------+ +----+ +---+ 997 | |--(1)-->| |---(2)-->+ | | | | | 998 | | | | | RVS R | | | | | 999 | | | |<--(3a)--+ |---(3b)---->| | | | 1000 | | | N | +-------+ | N | | | 1001 | |<-(4a)--| A | | A |--(4b)->| | 1002 | I | | T | | T | | R | 1003 | |--(5a)->| - | | - |<-(5b)--| | 1004 | | | I |<-(6b)------------------(6a)->| R | | | 1005 | | | | | | | | 1006 .................................................................... 1007 +---+ +----+ +----+ +---+ 1009 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 1010 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 1012 3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 1013 NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 1014 3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 1015 I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC) 1017 4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500) 1018 NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 1019 4b. IP(IP-RVS, IP-R) UDP(50500, 50500) 1020 I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC) 1022 5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I1(HIT-I, HIT-R) 1023 5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111) 1024 R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) 1026 6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) I1(HIT-I, HIT-R) 1027 6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111) 1028 R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) 1030 Figure 10: UDP-encapsulated HIP base exchange (initiator and 1031 responder behind a NAT, RVS on public IP). 1033 3.5.2. NAT Traversal of HIP Data Traffic 1035 After a successful base exchange, both the HIP nodes have all the 1036 parameters with them to establish UDP BEET mode Security Association. 1037 The following section describes inbound and outbound security 1038 associations at initiator and responder. 1040 3.5.2.1. Security Associations at the Initiator 1042 The initiator of a base exchange defines its outbound SA as shown in 1043 Table 10 1044 +--------------+----------------------------------------------------+ 1045 | Field | Value | 1046 +--------------+----------------------------------------------------+ 1047 | Outer src | Same local IP address from which the base exchange | 1048 | address | packets were transmitted | 1049 | Outer dst | Same peer IP address from which R2 packet was | 1050 | address | received during base exchange | 1051 | UDP src port | Same as the port number chosen to send I2 during | 1052 | | base exchange | 1053 | UDP dst port | Source port of incoming R2 packet during base | 1054 | | exchange | 1055 +--------------+----------------------------------------------------+ 1057 Table 10: Outbound SA at initiator 1059 The initiator of a base exchange defines its inbound SA as shown in 1060 Table 11 1062 +--------------+----------------------------------------------------+ 1063 | Field | Value | 1064 +--------------+----------------------------------------------------+ 1065 | Outer src | Same peer IP address from which R2 packet was | 1066 | address | received during base exchange | 1067 | Outer dst | Same local IP address from which the base exchange | 1068 | address | packets were transmitted | 1069 | UDP src port | Source port of incoming R2 packet during base | 1070 | | exchange | 1071 | UDP dst port | Same as the port number chosen to send I2 during | 1072 | | base exchange | 1073 +--------------+----------------------------------------------------+ 1075 Table 11: Inbound SA at initiator 1077 3.5.2.2. Security Associations at the Responder 1079 The responder of a UDP-encapsulated base exchange defines its 1080 outbound SA shown in Table 12. 1082 +--------------+----------------------------------------------------+ 1083 | Field | Value | 1084 +--------------+----------------------------------------------------+ 1085 | Outer src | Same local IP address from which the base exchange | 1086 | address | packets were transmitted | 1087 | Outer dst | Same peer IP as that used during base exchange | 1088 | address | | 1089 | UDP src port | Same as source port chosen send R2 during base | 1090 | | exchange | 1091 | UDP dst port | Same as source port number of I2 packet during | 1092 | | base exchange | 1093 +--------------+----------------------------------------------------+ 1095 Table 12: Outbound SA at Responder 1097 Similarly, the responder of a UDP-encapsulated base exchange defines 1098 its inbound SA as shown in Table 13 1100 +--------------+----------------------------------------------------+ 1101 | Field | Value | 1102 +--------------+----------------------------------------------------+ 1103 | Outer src | Source peer IP address as used in base exchange | 1104 | address | | 1105 | Outer dst | Same local IP address from which the base exchange | 1106 | address | packets were transmitted | 1107 | UDP src port | Same as source Port received from I2 during base | 1108 | | exchange | 1109 | UDP dst port | Same as source port used to send R2 during base | 1110 | | exchange | 1111 +--------------+----------------------------------------------------+ 1113 Table 13: Inbound SA at responder 1115 3.6. NAT Keep-Alives 1117 Typically, NATs cache an established binding and time it out if they 1118 have not used it to relay traffic for a given period of time. This 1119 timeout is different for different NAT implementations. The BEHAVE 1120 working group is discussing recommendations for standardized timeout 1121 values. To prevent NAT bindings that support the traversal of UDP- 1122 encapsulated HIP traffic from timing out during times when there is 1123 no control or data traffic, HIP hosts SHOULD send periodic keep-alive 1124 messages. 1126 Typically, only outgoing traffic acts refreshes the NAT port state 1127 for security reasons. Consequently, both hosts SHOULD send periodic 1128 keep-alives for the UDP channel of all their established HIP 1129 associations if the channel has been idle for a specific period of 1130 time. 1132 For the UDP channel, keep-alives MUST be UDP-encapsulated HIP UPDATE 1133 packets as defined in Section 3.1.2. The packets MUST use the same 1134 source and destination ports and IP addresses as the corresponding 1135 UDP tunnel. The default keep-alive interval for control channels 1136 MUST be 20 seconds. The responder of the HIP association should just 1137 discard the keep-alives. 1139 3.7. HIP Mobility 1141 After a successful base exchange, either host can change its network 1142 location using the mechanisms defined in [I-D.ietf-hip-mm]. This 1143 section describes such mobility mechanisms in the presence of NATs. 1144 However, double jump scenario, where both hosts move simultaneously, 1145 is excluded. 1147 The mobile node can change its location as described in Table 14. 1149 +----+---------------------------+----------------------------------+ 1150 | No | From network | To network | 1151 +----+---------------------------+----------------------------------+ 1152 | 1 | Behind NAT | Publicly Addressable Network | 1153 | 2 | Publicly Addressable | Behind NAT | 1154 | | Network | | 1155 | 3 | Behind NAT-A | Stays behind NAT-A, but | 1156 | | | different IP | 1157 | 4 | Behind NAT-A | Behind NAT-B | 1158 | 5 | Publicly Addressable | Publicly Addressable Network | 1159 | | Network | | 1160 +----+---------------------------+----------------------------------+ 1162 Table 14: End host mobility scenarios 1164 The corresponding peer node can be located as follows Table 15 1166 +----+------------------------------------------+ 1167 | No | Peer Node network | 1168 +----+------------------------------------------+ 1169 | A | Publicly Addressable Network With RVS | 1170 | B | Publicly Addressable Network Without RVS | 1171 | C | Behind NAT With RVS | 1172 | D | Behind NAT Without RVS | 1173 +----+------------------------------------------+ 1175 Table 15: Peer host Network Scenarios 1177 The NAT traversal mechanisms may not work when the corresponding node 1178 is behind a NAT without RVS (case D), except when the mobile node 1179 stays behind the same cone NAT (case 3D). 1181 When a host changes its location, it SHOULD detect the presence of 1182 NATs along the new paths to its peers using some external mechanism 1183 before sending any UPDATE messages. Alternatively, it MAY use some 1184 heuristics to conclude that it is behind a NAT rather than incur the 1185 latency of running NAT detection first. 1187 The mobile node MUST send the UPDATE packet through the corresponding 1188 node's RVS if it has one, in addition to sending it to the 1189 corresponding node directly. The mobile node encapsulates the UPDATE 1190 packet within UDP only when it is behind a NAT. The corresponding 1191 node MUST reply using UDP when the packet was encapsulated within 1192 UDP, or without UDP when the UDP header was not present in the UPDATE 1193 packet. 1195 The rendezvous server UPDATE relaying process is similar to I1. The 1196 rendezvous server MUST add FROM parameter when it gets a UPDATE 1197 packet without UDP encapsulation, or a FROM_NAT parameter when the 1198 UPDATE packet it receives is UDP encapsulated and MUST protect the 1199 packet with HMACs. Upon replying to the UPDATE, the corresponding 1200 node MUST add a VIA_RVS (or VIA_RVS_NAT) parameter to the reply. 1202 When the UDP encapsulation for NAT traversal is used, private IP 1203 addresses should be filtered out from the LOCATOR parameter in the 1204 HIP control packets. Exposing private addresses may impose privacy 1205 related problems. 1207 3.8. HIP Multihoming 1209 Multiple security associations can exists between the same hosts. 1210 They may be connected through several paths, some of which may 1211 include a NAT and others may not. Implementations that support 1212 multihoming MUST support concurrent HIP associations between the same 1213 host pair in a way that allows some of them to use UDP encapsulation 1214 while others use basic HIP. Implementations MAY distinguish HIP 1215 associations based on the SPI instead of a HIT pair for this purpose. 1217 3.9. Firewall Traversal 1219 When the initiator or the responder of a HIP association is behind a 1220 firewall, additional issues arise. 1222 When the initiator is behind a firewall, the NAT traversal mechanisms 1223 described in Section 3 depend on the ability to initiate 1224 communication via UDP to destination port 50500 from arbitrary source 1225 ports and to receive UDP response traffic from that port to the 1226 chosen source port. 1228 Most firewall implementations support "UDP connection tracking", 1229 i.e., after a host behind a firewall has initiated a UDP 1230 communication to the public Internet, the firewall relays UDP 1231 response traffic in the return direction. If no such return traffic 1232 arrives for a specific period of time, the firewall stops relaying 1233 the given IP address and port pair. The mechanisms described in 1234 Section 3 already enable traversal of such firewalls, if the keep- 1235 alive interval used is less than the refresh interval of the 1236 firewall. 1238 If the initiator is behind a firewall that does not support "UDP 1239 connection tracking", the NAT traversal mechanisms described in 1240 Section 3 can still be supported, if the firewall allows permanently 1241 inbound UDP traffic from port 50500 and destined to arbitrary source 1242 IP addresses and UDP ports. 1244 When the responder is behind a firewall, the NAT traversal mechanisms 1245 described in Section 3 depend on the ability to receive UDP traffic 1246 on port 50500 from arbitrary source IP addresses and ports. 1248 The NAT traversal mechanisms described in Section 3 require that the 1249 firewall - stateful or not - allow inbound UDP traffic to port 50500 1250 and allow outbound UDP traffic to arbitrary UDP ports. If necessary 1251 for firewall traversal, ports reserved for IKE MAY be used for 1252 initiating new connections, but the implementation MUST be able to 1253 listen for UDP packets from port 50500. 1255 4. Security Considerations 1257 Section 5.1 of [RFC3948] describes a security issue for the UDP 1258 encapsulation of standard IP tunnel mode when two hosts behind 1259 different NATs have the same private IP address and initiate 1260 communication to the same responder in the public Internet. The 1261 responder cannot distinguish between the two hosts, because security 1262 associations are based on the same inner IP addresses. 1264 This issue does not exist with the UDP encapsulation of IPsec BEET 1265 mode as described in Section 3, because the responder use the HITs to 1266 distinguish between different communication instances. 1268 The rendezvous usage in this draft has been designed to follow the 1269 design of the RVS draft [I-D.ietf-hip-rvs] and only I1 relayed. 1270 However, as NAT networking presents some additional challenges, it is 1271 not possible two follow the RVS design exactly. Particularly, the 1272 mechanisms described in Figure 7 and Section 3.5.1 require that the 1273 rendezvous server replies back to the initiator with a message which 1274 includes the address and port of the responder NAT. Another design 1275 choice would have been to relay also the R1 (and I2 in case of both 1276 hosts behind NAT) through the rendezvous server to delay the exposure 1277 of the responder NAT address and port related information for 1278 additional DoS protection. However, this choice was not selected to 1279 reduce round trip time. As a consequence, the renzvous client must 1280 be accept the risk of lowered privacy protection when it registers to 1281 the RVS over UDP as defined in section Figure 8. 1283 5. IANA Considerations 1285 This section is to be interpreted according to [RFC2434]. 1287 This draft currently uses a UDP port in the "Dynamic and/or Private 1288 Port" range, i.e., 50500. Upon publication of this document, IANA is 1289 requested to register two UDP ports and the RFC editor is requested 1290 to change all occurrences of port 50500 to the port IANA has 1291 registered. 1293 6. Acknowledgements 1295 The authors would like to thank Tobias Heer, Teemu Koponen, Juhana 1296 Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, 1297 Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen and Jukka Ylitalo 1298 for their comments on this document. 1300 [I-D.nikander-hip-path] presented some initial ideas for NAT 1301 traversal of HIP communication. This document describes 1302 significantly different mechanisms that, among other differences, use 1303 external NAT discovery and do not require encapsulation servers. 1305 Lars Eggert and Martin Stiemerling are partly funded by Ambient 1306 Networks, a research project supported by the European Commission 1307 under its Sixth Framework Program. The views and conclusions 1308 contained herein are those of the authors and should not be 1309 interpreted as necessarily representing the official policies or 1310 endorsements, either expressed or implied, of the Ambient Networks 1311 project or the European Commission. 1313 Miika Komu is working for InfraHIP research group at Helsinki 1314 Institute for Information Technology (HIIT). The InfraHIP project is 1315 funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and 1316 Ericsson. 1318 7. References 1320 7.1. Normative References 1322 [I-D.ietf-hip-base] 1323 Moskowitz, R., "Host Identity Protocol", 1324 draft-ietf-hip-base-05 (work in progress), March 2006. 1326 [I-D.ietf-hip-esp] 1327 Jokela, P., "Using ESP transport format with HIP", 1328 draft-ietf-hip-esp-02 (work in progress), March 2006. 1330 [I-D.ietf-hip-mm] 1331 Nikander, P., "End-Host Mobility and Multihoming with the 1332 Host Identity Protocol", draft-ietf-hip-mm-03 (work in 1333 progress), March 2006. 1335 [I-D.ietf-hip-rvs] 1336 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1337 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 1338 progress), October 2005. 1340 [I-D.nikander-esp-beet-mode] 1341 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 1342 (BEET) mode for ESP", draft-nikander-esp-beet-mode-05 1343 (work in progress), February 2006. 1345 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1346 August 1980. 1348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1349 Requirement Levels", BCP 14, RFC 2119, March 1997. 1351 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1352 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1353 October 1998. 1355 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1356 (HIP) Architecture", RFC 4423, May 2006. 1358 [rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1359 Rendezvous Extension". 1361 7.2. Informative References 1363 [I-D.ietf-behave-nat-udp] 1364 Audet, F. and C. Jennings, "NAT Behavioral Requirements 1365 for Unicast UDP", draft-ietf-behave-nat-udp-07 (work in 1366 progress), June 2006. 1368 [I-D.irtf-hiprg-nat] 1369 Stiemerling, M., "NAT and Firewall Traversal Issues of 1370 Host Identity Protocol (HIP) Communication", 1371 draft-irtf-hiprg-nat-02 (work in progress), May 2006. 1373 [I-D.nikander-hip-path] 1374 Nikander, P., "Preferred Alternatives for Tunnelling HIP 1375 (PATH)", draft-nikander-hip-path-01 (work in progress), 1376 March 2006. 1378 [I-D.srisuresh-behave-p2p-state] 1379 Srisuresh, P., "State of Peer-to-Peer(P2P) Communication 1380 Across Network Address Translators(NATs)", 1381 draft-srisuresh-behave-p2p-state-03 (work in progress), 1382 June 2006. 1384 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1385 Translator (NAT) Terminology and Considerations", 1386 RFC 2663, August 1999. 1388 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1389 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1390 Through Network Address Translators (NATs)", RFC 3489, 1391 March 2003. 1393 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1394 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1395 RFC 3948, January 2005. 1397 Appendix A. Document Revision History 1399 To be removed upon publication 1401 +------------+------------------------------------------------------+ 1402 | Revision | Comments | 1403 +------------+------------------------------------------------------+ 1404 | schmitt-00 | Initial version. | 1405 | ietf-00 | Officially adopted as WG item. Solved issues | 1406 | | 1-9,11,12 | 1407 +------------+------------------------------------------------------+ 1409 Authors' Addresses 1411 Vivien Schmitt 1412 NEC Network Laboratories 1413 Kurfuerstenanlage 36 1414 Heidelberg 69115 1415 Germany 1417 Phone: +49 6221 90511 0 1418 Fax: +49 6221 90511 55 1419 Email: schmitt@netlab.nec.de 1420 URI: http://www.netlab.nec.de/ 1421 Abhinav Pathak 1422 IIT Kanpur 1423 B204, Hall - 1, IIT Kanpur 1424 Kanpur 208016 1425 India 1427 Phone: +91 9336 20 1002 1428 Email: abhinav.pathak@hiit.fi 1429 URI: http://www.iitk.ac.in/ 1431 Miika Komu 1432 Helsinki Institute for Information Technology 1433 Tammasaarenkatu 3 1434 Helsinki 1435 Finland 1437 Phone: +358503841531 1438 Fax: +35896949768 1439 Email: miika@iki.fi 1440 URI: http://www.hiit.fi/ 1442 Lars Eggert 1443 NEC Network Laboratories 1444 Kurfuerstenanlage 36 1445 Heidelberg 69115 1446 Germany 1448 Phone: +49 6221 90511 43 1449 Fax: +49 6221 90511 55 1450 Email: lars.eggert@netlab.nec.de 1451 URI: http://www.netlab.nec.de/ 1453 Martin Stiemerling 1454 NEC Network Laboratories 1455 Kurfuerstenanlage 36 1456 Heidelberg 69115 1457 Germany 1459 Phone: +49 6221 90511 13 1460 Fax: +49 6221 90511 55 1461 Email: stiemerling@netlab.nec.de 1462 URI: http://www.netlab.nec.de/ 1464 Full Copyright Statement 1466 Copyright (C) The Internet Society (2006). 1468 This document is subject to the rights, licenses and restrictions 1469 contained in BCP 78, and except as set forth therein, the authors 1470 retain all their rights. 1472 This document and the information contained herein are provided on an 1473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1480 Intellectual Property 1482 The IETF takes no position regarding the validity or scope of any 1483 Intellectual Property Rights or other rights that might be claimed to 1484 pertain to the implementation or use of the technology described in 1485 this document or the extent to which any license under such rights 1486 might or might not be available; nor does it represent that it has 1487 made any independent effort to identify any such rights. Information 1488 on the procedures with respect to rights in RFC documents can be 1489 found in BCP 78 and BCP 79. 1491 Copies of IPR disclosures made to the IETF Secretariat and any 1492 assurances of licenses to be made available, or the result of an 1493 attempt made to obtain a general license or permission for the use of 1494 such proprietary rights by implementers or users of this 1495 specification can be obtained from the IETF on-line IPR repository at 1496 http://www.ietf.org/ipr. 1498 The IETF invites any interested party to bring to its attention any 1499 copyrights, patents or patent applications, or other proprietary 1500 rights that may cover technology that may be required to implement 1501 this standard. Please address the information to the IETF at 1502 ietf-ipr@ietf.org. 1504 Acknowledgment 1506 Funding for the RFC Editor function is currently provided by the 1507 Internet Society.