idnits 2.17.1 draft-ietf-mobileip-nat-traversal-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 4, 2002) is 7841 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) == Unused Reference: '4' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1500, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 1768 (ref. '4') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (ref. '11') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 1826 (ref. '12') (Obsoleted by RFC 2402) == Outdated reference: A later version (-02) exists of draft-iab-unsaf-considerations-01 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Levkowetz 3 Internet-Draft ipUnplugged 4 Expires: May 5, 2003 S. Vaarala 5 Netseal 6 November 4, 2002 8 Mobile IP NAT/NAPT Traversal using UDP Tunnelling 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 5, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 Mobile IP's datagram tunnelling is incompatible with Network Address 41 Translation (NAT). This document presents extensions to the Mobile 42 IP protocol and a tunnelling method which permits mobile nodes using 43 Mobile IP to operate in private address networks which are separated 44 from the public internet by NAT devices. The NAT traversal is based 45 on using the Mobile IP Home Agent UDP port for encapsulated data 46 traffic. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2 Problem description . . . . . . . . . . . . . . . . . . . . 5 53 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2. NAT Traversal Overview . . . . . . . . . . . . . . . . . . . 6 56 2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 7 58 3. New Message Formats . . . . . . . . . . . . . . . . . . . . 8 59 3.1 UDP Tunnel Request Extension . . . . . . . . . . . . . . . . 8 60 3.1.1 F (Force) Flag . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1.2 R (Registration through FA Required) flag . . . . . . . . . 10 62 3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 10 63 3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.1.5 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 10 65 3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 11 66 3.2.1 Reply Code . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . . . 12 68 3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . . . 13 69 3.5 New Registration Reply Codes . . . . . . . . . . . . . . . . 14 71 4. Protocol Behaviour . . . . . . . . . . . . . . . . . . . . . 14 72 4.1 Relation to standard MIP tunnelling . . . . . . . . . . . . 14 73 4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . . . 15 74 4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.4 Mobile Node Considerations . . . . . . . . . . . . . . . . . 16 76 4.5 Foreign Agent Considerations . . . . . . . . . . . . . . . . 18 77 4.6 Home Agent Considerations . . . . . . . . . . . . . . . . . 19 78 4.6.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 20 79 4.7 MIP signalling versus tunnelling . . . . . . . . . . . . . . 22 80 4.8 Packet fragmentation . . . . . . . . . . . . . . . . . . . . 22 81 4.9 Tunnel Keepalive . . . . . . . . . . . . . . . . . . . . . . 23 82 4.10 Detecting and compensating for loss of NAT mapping . . . . . 24 83 4.11 Co-located registration through FA . . . . . . . . . . . . . 25 85 5. Implementation Issues . . . . . . . . . . . . . . . . . . . 26 86 5.1 Movement Detection and Private Address Aliasing . . . . . . 26 87 5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . . . 27 89 6. Security Considerations . . . . . . . . . . . . . . . . . . 27 90 6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . . . 28 91 6.1.1 Manipulation of the Registration Request Message . . . . . . 28 92 6.1.2 Sending a Bogus Keepalive Message . . . . . . . . . . . . . 28 93 6.2 Use of IPsec . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.3 Firewall Considerations . . . . . . . . . . . . . . . . . . 29 95 7. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . 30 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 99 9. Intellectual property rights . . . . . . . . . . . . . . . . 32 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 102 Normative References . . . . . . . . . . . . . . . . . . . . 33 103 Informative References . . . . . . . . . . . . . . . . . . . 33 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 105 Full Copyright Statement . . . . . . . . . . . . . . . . . . 35 107 1. Introduction 109 1.1 Terminology 111 The Mobile IP related terminology described in RFC 3344 [11] is used 112 in this document. In addition, the following terms are used: 114 Forward Tunnel 115 A tunnel that forwards packets towards the mobile node. It 116 starts at the home agent, and ends at the mobile node's care-of 117 address. 119 Reverse Tunnel 120 A tunnel that starts at the mobile node's care-of address and 121 terminates at the home agent. 123 NAT 124 Network Address Translation. "Traditional NAT would allow 125 hosts within a private network to transparently access hosts in 126 the external network, in most cases. In a traditional NAT, 127 sessions are uni-directional, outbound from the private 128 network." -- RFC 2663 [13]. Basic NAT and NAPT are two 129 varieties of NAT. 131 Basic NAT 132 "With Basic NAT, a block of external addresses are set aside 133 for translating addresses of hosts in a private domain as they 134 originate sessions to the external domain. For packets 135 outbound from the private network, the source IP address and 136 related fields such as IP, TCP, UDP and ICMP header checksums 137 are translated. For inbound packets, the destination IP 138 address and the checksums as listed above are translated." -- 139 RFC 2663 [13] 141 NAPT 142 Network Address Port Translation. "NAPT extends the notion of 143 translation one step further by also translating transport 144 identifier (e.g., TCP and UDP port numbers, ICMP query 145 identifiers). This allows the transport identifiers of a 146 number of private hosts to be multiplexed into the transport 147 identifiers of a single external address. NAPT allows a set of 148 hosts to share a single external address. Note that NAPT can 149 be combined with Basic NAT so that a pool of external addresses 150 are used in conjunction with port translation." -- RFC 2663 151 [13] 153 In this document, the more general term NAT is used to cover both 154 NATs and NAPTs. In most deployment cases today, we believe that the 155 NATs used are of the NAPT variety. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [7]. 161 1.2 Problem description 163 A basic assumption that Mobile IP [11] makes is that mobile nodes and 164 foreign agents are uniquely identifiable by a globally routable IP 165 address. This assumption breaks down when a mobile node attempts to 166 communicate from behind a NAT. 168 Mobile IP relies on sending traffic from the home network to the 169 mobile node or foreign agent through IP-in-IP tunnelling. IP nodes 170 which communicate from behind a NAT are reachable only through the 171 NAT's public address(es). IP-in-IP tunnelling does not generally 172 contain enough information to permit unique translation from the 173 common public address(es) to the particular care-of address of a 174 mobile node or foreign agent which resides behind the NAT; in 175 particular there are no TCP/UDP port numbers available for a NAT to 176 work with. For this reason, IP-in-IP tunnels cannot in general pass 177 through a NAT, and Mobile IP will not work across a NAT. 179 Mobile IP's Registration Request and Reply will on the other hand be 180 able to pass through NATs and NAPTs on the mobile node or foreign 181 agent side, as they are UDP datagrams originated from the inside of 182 the NAT or NAPT. When passing out, they make the NAT set up an 183 address/port mapping through which the Registration Reply will be 184 able to pass in to the correct recipient. The current Mobile IP 185 protocol does however not permit a registration where the mobile 186 node's IP source address is not either the CoA, the Home Address, or 187 0.0.0.0. 189 What is needed is an alternative data tunnelling mechanism for Mobile 190 IP which will provide the means needed for NAT devices to do unique 191 mappings so that address translation will work, and a registration 192 mechanism which will permit such an alternative tunnelling mechanism 193 to be set up when appropriate. 195 This mechanism will address 3 different scenarios: 197 - A mobile node with co-located address behind a NAT; no FA 199 - A mobile node registered with an FA where both the mobile node 200 and the FA are behind the same NAT 202 - A mobile node with co-located address using an FA which demands 203 that registrations pass through the FA (sets the "R" bit) where 204 both the mobile node and the FA are behind the same NAT 206 1.3 Assumptions 208 The primary assumption in this document is that the network allows 209 communication between an UDP port chosen by the mobile node and the 210 home agent UDP port 434. If this assumption does not hold, neither 211 Mobile IP registration nor data tunnelling will work. 213 This document does NOT assume that mobility is constrained to a 214 common IP address space. On the contrary, the routing fabric between 215 the mobile node and the home agent may be partitioned into a 216 "private" and a "public" network, and the assumption is that some 217 mechanism is needed in addition to vanilla Mobile IP according to RFC 218 3344 [11] in order to achieve mobility within disparate IP address 219 spaces. 221 For a more extensive discussion of the problems with disparate 222 address spaces, and how they may be solved, see RFC 3024 [10]. 224 The reverse tunnels considered here are symmetric, that is, they use 225 the same configuration (encapsulation method, IP address endpoints) 226 as the forward tunnel. 228 2. NAT Traversal Overview 230 This section gives a brief overview of the MIP UDP tunnelling 231 mechanism which may be used to achieve NAT traversal for Mobile IP. 233 In MIP UDP tunnelling, the mobile node may use an extension 234 (described below) in its Registration Request to indicate that it is 235 able to use Mobile IP UDP tunnelling instead of standard Mobile IP 236 tunnelling if the home agent sees that the Registration Request seems 237 to have passed through a NAT. The home agent may then send a 238 registration reply with an extension indicating acceptance (or 239 denial). After assent from the home agent, MIP UDP tunnelling will 240 be available for use for both forward and reverse tunnelling. UDP 241 tunnelled packets sent by the mobile node use the same ports as the 242 registration request message. In particular, the source port may 243 vary between new registrations, but remains the same for all 244 tunnelled data and re-registrations. The destination port is always 245 434. UDP tunnelled packets sent by the home agent uses the same 246 ports, but in reverse. 248 2.1 Basic Message Sequence 250 The message sequence diagram below exemplifies setting up and using a 251 Mobile IP UDP tunnel as described in this document. The tunnel is 252 set up by the use of specific extensions in the initial Mobile IP 253 Registration Request and Reply exchange. Thereafter, any traffic 254 from the home agent to the mobile node is sent through the UDP 255 tunnel. The mobile node may at its discretion use the UDP tunnel for 256 reverse tunnelling or not, although in most cases where MIP UDP 257 tunnelling is needed, reverse tunnelling will also be needed. 259 mobile node NAT home agent 260 | | | 261 | | | 262 | Registration | | 263 | Request with | | 264 |-----------------///--------------->>| 265 |UDP Tunnel Request| | 266 | | + 267 | | || IP Source and 268 | | || CCoA address 269 | | || discrepancy 270 | | || seen 271 | | Registration + 272 | | Reply with | 273 |<<---------------///-----------------| 274 | | UDP Tunnel Reply.| 275 | | | 276 | UDP tunnelled pkg| | 277 |=================///===============>>| 278 | | UDP tunnelled pkg| 279 |<<===============///=================| 280 | | ||absence of 281 | | ||traffic for 282 | | ||UDP keepalive 283 | UDP keepalive | ||period 284 |-----------------///--------------->>+ 285 . . + 286 . . . 287 . . . 289 3. New Message Formats 291 3.1 UDP Tunnel Request Extension 293 This extension is a skippable Extension. It signifies that the 294 sender is capable of handling MIP UDP tunnelling, and optionally that 295 a particular encapsulation format is requested in the MIP UDP tunnel. 296 The format of this extension is as shown below. It adheres to the 297 short extension format described in [11]. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | Sub-Type | Reserved 1 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |F|R| Reserved 2| Encapsulation | Reserved 3 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Type (to be assigned by IANA) (skippable). 308 Length 6. Length in bytes of this extension, not 309 including the Type and Length bytes. 311 Sub-Type 0 313 Reserved 1 Reserved for future use. MUST be set to 0 on 314 sending, MUST be ignored on reception. 316 F F (Force) flag. Indicates that the mobile 317 node wants to force MIP UDP tunnelling to be 318 established. 320 R R (Registration through FA Required) flag. 321 Indicates that the R bit was set in the FA's 322 Agent Advertisement. Registration is being 323 made using a co-located care-of address, but 324 through the FA. 326 Reserved 2 Reserved for future use. MUST be set to 0 on 327 sending, MUST be ignored on reception. 329 Encapsulation Indicates the type of tunnelled data, using 330 the same numbering as the IP Header Protocol 331 Field. 333 Reserved 3 Reserved for future use. MUST be set to 0 on 334 sending, MUST be verified as 0 on receipt; 335 otherwise the extension must be handled as not 336 understood and silently skipped. 338 3.1.1 F (Force) Flag 340 Indicates that the mobile node wants to use traversal regardless of 341 the outcome of NAT detection performed by the home agent. This is 342 useful if the route between the mobile node and the home agent works 343 for Mobile IP signalling packets, but not for generic data packets 344 (e.g. because of firewall filtering rules). If the home agent 345 supports this protocol, it SHOULD either accept the traversal and 346 reply with a UDP Tunnel Reply Extension or reject the Registration 347 Request. In case of the registration failing, the Home Agent SHOULD 348 send a Registration Reply with Code field set to 129 349 ("administratively prohibited"). 351 If the HA does not understand the UDP Tunnel Request Extension, it 352 will silently discard it, and if everything else is fine, it will 353 reply with a registration reply with reply code 0 (registration 354 accepted), but without any UDP Tunnel Reply Extension. In this case, 355 the mobile node MUST NOT use MIP UDP tunnelling. 357 3.1.2 R (Registration through FA Required) flag 359 This flag MUST be set by the mobile node when it is using a co- 360 located address, but registering through an FA because it has 361 received an Agent Advertisement with the 'R' bit set. 363 3.1.3 Reserved Fields 365 The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, 366 while the 'Reserved 3' field must be 0 on receipt, otherwise this 367 extension MUST be handled as not understood and silently skipped. 368 This permits future additions to this extension to be made which 369 either can co-exist with old implementations, or will force a 370 rejection of the extension from an old implementation. 372 3.1.4 Encapsulation 374 The 'Encapsulation' field defines the mode of encapsulation requested 375 if MIP UDP tunnelling is accepted by the home agent. This field uses 376 the same values as the IP header Protocol field: 378 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 380 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [9] 382 55 Minimal IP encapsulation header RFC 2004 [6] 384 If the home agent finds that UDP tunnelling is not needed, the 385 encapsulation will be determined by the 'M' and 'G' flags of the 386 registration request; but if the home agent finds that MIP UDP 387 tunnelling should be done, the encapsulation is determined from the 388 value of the Encapsulation field. If the value of this field is 389 zero, it defaults to the value of 'M' and 'G' fields in the 390 Registration Request message, but if it is non-zero, it indicates 391 that a particular encapsulation is desired. 393 3.1.5 Mobile IP Registration Bits 395 The Mobile IP registration bits S, B, D, M, G and T retain their 396 meaning as described in RFC 3344 [11] and RFC 3024 [10] (except that 397 the significance of the M and G bits may be modified by the 398 Encapsulation field when MIP UDP tunnelling is used, as described 399 above). The use of the M and G bits together with MIP UDP tunnelling 400 is also touched upon in Section 4.1. 402 When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation 403 by the mobile node) MUST be set, otherwise UDP tunnelling would not 404 be meaningful. 406 Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP 407 tunnelling, even if not all traffic will be reverse tunnelled. This 408 ensures that a HA which is not prepared to accept reverse tunnelling 409 will not accept a registration which may later turn out to be 410 unusable. Also see the discussion of use of the 'T' bit in Foreign 411 Agent Considerations (Section 4.5). 413 3.2 UDP Tunnel Reply Extension 415 This extension is a non-skippable extension. It is sent in reply to 416 a UDP Tunnel Request extension, and indicates whether or not the HA 417 will use MIP UDP tunnelling for the current mobility binding. The 418 format of this extension is as shown below. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Length | Sub-Type | Reply Code | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |F| Reserved | Keepalive Interval | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Type (to be assigned by IANA) (non-skippable) 430 Length 6. Length in bytes of this extension, not 431 including the Type and Length bytes. 433 Sub-Type 0 435 Reply Code Indicates whether the HA assents or declines 436 to use UDP tunnelling for the current mobility 437 binding. See Section 3.2.1 below. 439 F F (Forced) flag. Indicates that tunnelling is 440 being forced because the F flag was set in the 441 tunnelling request, irrespective of the 442 detection of a NAT or not. 444 Keepalive Interval Specifies the NAT keepalive interval that the 445 mobile node SHOULD use. A keepalive packet 446 SHOULD be sent if Keepalive Interval seconds 447 have elapsed without any signalling or data 448 traffic being sent. If this field is set to 449 0, the mobile node MUST use its default 450 configured keepalive interval. 452 Reserved Reserved for future use. MUST be set to 0 on 453 sending, MUST be ignored on reception. 455 3.2.1 Reply Code 457 The Reply Code field of the UDP Tunnel Reply Extension indicates if 458 UDP tunnelling have been accepted and will be used by the HA. Values 459 in the range 0 .. 63 indicate assent, i.e. that tunnelling will be 460 done, while values in the range 64 .. 255 indicate that tunnelling 461 should not be done. More information may be given by the value of 462 the response code. 464 The following response codes are defined for use in the code field of 465 the UDP Tunnel Reply Extension: 467 0 Will do tunnelling 469 64 Tunnelling declined, reason unspecified 471 3.3 MIP Tunnel Data Message 473 This MIP message header serves to differentiate traffic tunnelled 474 through the well-known port 434 from other Mobile IP messages, e.g. 475 Registration Requests and Registration Replies. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type | Next Header | Reserved | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Type (to be assigned by IANA) 485 Next Header Indicates the type of tunnelled data, using 486 the same numbering as the IP Header Protocol 487 Field. 489 Reserved Reserved for future use. MUST be set to 0 on 490 sending, MUST be ignored on reception. 492 The Next Header field uses the same values as the IP header Protocol 493 field. Immediately relevant for use with Mobile IP are the following 494 values: 496 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 498 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [9] 500 55 Minimal IP encapsulation header RFC 2004 [6] 502 The receiver of a tunnelled packet MUST check that the Next Header 503 value matches the tunnelling mode established for the mobility 504 binding with which the packet was sent. If a discrepancy is 505 detected, the packet MUST be dropped. A log entry MAY be written, 506 but in this case the receiver SHOULD ensure that the amount of log 507 entries written is not excessive. 509 In addition to the encapsulation forms listed above, the MIP UDP 510 tunnelling can potentially support other encapsulations, by use of 511 the Next Header field in the MIP Tunnel Data Header and the 512 Encapsulation Header field of the UDP Tunnel Request Extension 513 (Section 3.1). 515 3.4 UDP Tunnelling Flag in Agent Advertisements 517 The only change to the Mobility Agent Advertisement Extension defined 518 in RFC 3344 [11] is a flag indicating that the foreign agent 519 generating the Agent Advertisement supports MIP UDP Tunnelling. The 520 flag is inserted after the flags defined in [11]. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | Sequence Number | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Lifetime |R|B|H|F|M|G|r|T|U| reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | zero or more Care-of Addresses | 530 | ... | 532 The flag is defined as follows: 534 U UDP Tunnelling support. This Agent supports MIP UDP 535 Tunnelling as specified in this document. This flag SHOULD 536 be set in advertisements sent by a foreign agent which 537 supports MIP UDP tunnelling and is situated behind a NAT. 538 It MUST NOT be set in advertisements from foreign agents 539 which are not situated behind a NAT, and thus has no need to 540 advertise the capability. 542 3.5 New Registration Reply Codes 544 One new registration reply code is defined: 546 ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation 547 unavailable 549 This is used by the HA to distinguish the registration denial caused 550 by an unavailable UDP tunnel encapsulation mode from a denial caused 551 by unavailable standard tunnel encapsulation requested by use of the 552 'T' bit together with either 'M' or 'G' bit. 554 4. Protocol Behaviour 556 4.1 Relation to standard MIP tunnelling 558 The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP 559 encapsulation. The mobile node MAY request alternative forms of 560 encapsulation to be used with UDP tunnelling by setting the 'M' bit 561 and/or the 'G' bit of a Mobile IP registration request, or by 562 explicitly requesting a particular encapsulation for the MIP UDP 563 tunnel by using the Encapsulation field. The M and G bits retain the 564 meaning as described in RFC 3344 [11] within the context of MIP UDP 565 tunnelling. The UDP tunnelling version of the classic MIP 566 encapsulation methods can be summarised as: 568 IP in UDP. When Mobile IP UDP tunnelling is used, this is the 569 default encapsulation type. Any home agent and mobile node 570 that implements Mobile IP UDP tunnelling MUST implement this 571 encapsulation type. 573 GRE in UDP. If the 'G' bit is set in a registration request and 574 the Encapsulation field is zero, the mobile node requests that 575 its home agent use GRE encapsulation [3] for datagrams 576 tunnelled to the mobile node. If MIP UDP tunnelling is also 577 requested and accepted, GRE-in-UDP encapsulation SHALL be used 578 in the same cases as GRE in IP encapsulation would be used if 579 the MIP UDP tunnelling had not been requested. 581 Minimal encapsulation in UDP. If the 'M' bit is set and the 582 Encapsulation field is zero, the mobile node requests that its 583 home agent use minimal encapsulation [6] for datagrams 584 tunnelled to the mobile node. If MIP UDP tunnelling is also 585 used, minimal encapsulation in UDP SHALL be used in the same 586 cases as minimal encapsulation according to RFC 2004 [6] would 587 be used if the MIP UDP tunnelling had not been requested. 589 When the Encapsulation field is non-zero, a particular encapsulation 590 format is requested for the MIP UDP tunnel. If tunnelling is 591 indicated, the request MUST either be accepted using the requested 592 encapsulation, or rejected with the error code 593 ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation 594 unavailable" defined in Section 3.5. On receipt of this error, the 595 mobile node MAY choose to send a new Registration Request with 596 different requirements on MIP UDP tunnelling encapsulation. 598 4.2 Encapsulating IP Headers in UDP 600 MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a 601 manner analogous to that described for IP-in-IP tunnelling in RFC 602 2003 [5], with the exception of the addition of an UDP header [1] and 603 MIP Message header [11] between the outer and inner IP header. 605 Mobile IP Registration Requests and Registration Replies are already 606 in the form of UDP messages, and SHALL NOT be tunnelled even when MIP 607 IP-in-UDP tunnelling is in force. 609 To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an 610 outer IP header [2], UDP header [1] and MIP Message header [11] is 611 inserted before the datagram's existing IP header, as follows: 613 +---------------------------+ 614 | | 615 | Outer IP Header | 616 +---------------------------+ 617 | | 618 | UDP Header | 619 +---------------------------+ 620 | MIP Tunnel Data | 621 | Message Header | 622 +---------------------------+ +---------------------------+ 623 | | | | 624 | IP Header | | IP Header | 625 +---------------------------+ ====> +---------------------------+ 626 | | | | 627 | IP Payload | | IP Payload | 628 | | | | 629 | | | | 630 +---------------------------+ +---------------------------+ 632 The outer IP header Source Address and Destination Address, together 633 with the UDP header Source Port and Destination Port, identify the 634 "endpoints" of the tunnel. The inner IP header Source Address and 635 Destination Addresses identify the original sender and the recipient 636 of the datagram, respectively. The inner IP header is not changed by 637 the encapsulator, except to decrement the TTL by one if the 638 tunnelling is being done as part of forwarding the datagram as noted 639 in RFC 2003 [5], and remains unchanged during its delivery to the 640 tunnel exit point. No change to IP options in the inner header 641 occurs during delivery of the encapsulated datagram through the 642 tunnel. Note that the security options of the inner IP header MAY 643 affect the choice of security options for the encapsulating (outer) 644 IP header. 646 Minimal Encapsulation and GRE encapsulation is done in an analogous 647 manner, following RFC 2004 [6] for Minimal Encapsulation and RFC 2784 648 [9] for GRE Encapsulation, but using outer IP, UDP and MIP headers in 649 place of the outer IP header. 651 All other provisions and requirements of RFC 2003 [5] and RFC 3024 652 [10] are in force, except in one respect, as covered in Packet 653 Fragmentation (Section 4.8). 655 4.3 Decapsulation 657 Before decapsulation is actually done, the decapsulating node MUST 658 verify that the outer IP addresses and UDP port numbers exactly match 659 the values used for the tunnel, with the exception of tunnels that 660 are "half bound" (as described in Section 4.11) where the source UDP 661 port can change. 663 IP-in-UDP encapsulated traffic is decapsulated simply by stripping 664 off the outer IP, UDP and MIP header, which leaves the original IP 665 packet which is forwarded as is. 667 Minimal IP encapsulation is processed by the receiver conceptually as 668 follows. First, the UDP and the Mobile IP headers are removed from 669 the packet, and the Protocol field of the IP header replaced with the 670 Next Header field in the MIP Tunnel Data header. Second, the 671 remaining IP header total length and checksum are adjusted to match 672 the stripped packet. Third, ordinary minimal IP encapsulation 673 processing is done. 675 GRE encapsulated traffic is processed according to RFC 2784 [9] and 676 RFC 1701 [3], with the delivery header consisting of the outer IP, 677 UDP and MIP headers. 679 4.4 Mobile Node Considerations 681 The UDP Tunnel Request Extension MAY be used in a Mobile IP 682 Registration Request from the mobile node to the home agent when the 683 mobile node uses a co-located care-of address. It SHALL NOT be used 684 by the mobile node when it is registering with a foreign agent care- 685 of address. 687 The purpose of this extension is to indicate to the home agent that 688 the mobile node is able to accept MIP UDP tunnelling if the home 689 agent has an indication that the mobile node resides behind a NAT or 690 NAPT. It thus functions as a conditional solicitation for the use of 691 MIP UDP tunnelling. 693 As per Section 3.2 and 3.6.1.3 of RFC 3344 [11], the mobile node MUST 694 place this Extension before the Mobile-Home Authentication Extension 695 in registration messages, so that it is covered by the Mobile-Home 696 Authentication Extension. 698 If the mobile node includes the UDP Tunnel Request extension in a 699 registration request, but receives a registration reply without a UDP 700 Tunnel Reply extension, it MUST assume that the HA does not 701 understand this extension, and it MUST NOT use UDP tunnelling. If 702 the mobile node is in fact behind a NAT, the registration may then 703 succeed, but traffic will not be able to traverse the NAT. 705 When the mobile node sends MIP UDP tunnelled data, it MUST use the 706 same UDP source port as was used for the most recent registration 707 request. 709 When the mobile node re-registers without having moved, it SHOULD 710 take care to use the same source port as was used for the original 711 registration of the current mobility binding. Otherwise, while the 712 home agent would change destination port on acceptance of the new 713 registration, and the mobile node would presumably start listening on 714 the new port, the packets in flight from the home agent at the time 715 of change will be dropped when arriving at the mobile node's old 716 port. (This does not mean that the home agent should refuse a 717 registration request using MIP UDP tunnelling where a new port have 718 been used, as this might be the result of the NAT dropping state, the 719 mobile node re-booting, changing interface, etc.) 721 If a mobile node is registering through a foreign agent but using a 722 co-located care-of address, and the agent advertisement from the 723 foreign agent had the 'U' bit set, the mobile node MUST set the 'R' 724 flag in its UDP Tunnel Request Extension, in order to make the HA use 725 MIP UDP tunnelling. In this case, the mobile node also MUST send a 726 keepalive as soon as its registration has been accepted. 728 If a mobile node is registering through a foreign agent but using a 729 co-located care-of address, and the agent advertisement from the 730 foreign agent does not have the 'U' bit set, the mobile node MUST NOT 731 include a UDP Tunnel Request Extension in the registration request. 733 4.5 Foreign Agent Considerations 735 The UDP Tunnel Request Extension MAY be used by a foreign agent when 736 it is forwarding a Mobile IP Registration Request to a home agent, 737 when the foreign agent is situated behind a NAT or has some other 738 compelling reason to require MIP UDP tunnelling. 740 The purpose of this extension is to indicate to the home agent that 741 the foreign agent is able to accept MIP UDP tunnelling if the home 742 agent has an indication that the foreign agent resides behind a NAT 743 or NAPT. It thus functions as a conditional solicitation for the use 744 of MIP UDP tunnelling. 746 A foreign agent which requires the mobile node to register through a 747 foreign agent by setting the 'R' bit in the agent advertisement, MUST 748 NOT add the UDP Tunnel Request Extension when forwarding a 749 registration request which uses a co-located care-of address, as this 750 will lead to a UDP tunnel being set up from the home agent to the 751 foreign agent instead of to the mobile node. 753 As per Section 3.2 and 3.7.2.2 of RFC 3344 [11], the foreign agent 754 when using this extension MUST place it after the Mobile-Home 755 Authentication Extension in registration messages. If the foreign 756 agent shares a mobility security association with the home agent and 757 therefore appends a Foreign-Home Authentication Extension, the UDP 758 Tunnel Request Extension MUST be placed before the Foreign-Home 759 Authentication Extension. 761 As the home agent detects the presence of a NAT in the path between 762 the sender and itself by seeing a mismatch between the IP source 763 address and the care-of address given in the registration request, it 764 is REQUIRED that the foreign agent, when using this extension, sends 765 the registration request with an IP source address matching the care- 766 of address. 768 A foreign agent using MIP UDP tunnelling to a home agent because the 769 FA is situated behind a NAT may be configured to encourage reverse 770 tunnelling, or be neutral about it, depending on the characteristics 771 of the NAT. If the NAT translates all source addresses of outgoing 772 packets to its own public address, it will not be possible to 773 maintain sessions when moving away from this network if the mobile 774 node has used triangular routing instead of reverse tunnelling. On 775 the other hand, if it is known that the NAT is smart enough to not 776 translate publicly routable source addresses, AND does not do ingress 777 filtering, triangular routing may succeed. The leg from the home 778 agent to the foreign agent will still use MIP UDP tunnelling to pass 779 through the NAT. 781 Therefore, if it is known when configuring a foreign agent behind a 782 NAT that the NAT will translate public as well as private addresses, 783 or it is known that ingress filtering is being done between the 784 private and public networks, the foreign agent SHOULD reply to 785 registration requests which don't have the 'T' bit set with a reply 786 code 75, "reverse tunnel is mandatory and 'T' bit not set". 788 Conversely, if it is known that the NAT is smart about not 789 translating public addresses, and no ingress filtering is done, so it 790 is reasonable to believe that a mobile node with a publicly routable 791 address may be able to keep up sessions when moving to or from this 792 network, the foreign agent MAY be configured to forward registration 793 requests even if they don't have the 'T' bit set. 795 If the behaviour of the NAT is unknown in this respect, it SHOULD be 796 assumed that it will translate all addresses, thus the foreign agent 797 SHOULD be configured to reply to registration requests which don't 798 have the 'T' bit set with a reply code 75, "reverse tunnel is 799 mandatory and 'T' bit not set". 801 4.6 Home Agent Considerations 803 The purpose of the MIP UDP Tunnel Reply Extension is to indicate 804 whether or not the home agent accepts the use of MIP UDP tunnelling 805 for this mobility binding, and to inform the mobile node or foreign 806 agent of the suggested tunnel keepalive interval to be used. 808 The UDP Tunnel Reply Extension MUST be used in a Mobile IP 809 Registration Reply from the home agent to the mobile node when it has 810 received and accepted a UDP Tunnel Request (Section 3.1) from a 811 mobile node. 813 The home agent MUST use a mismatch between source IP address and 814 care-of address in the Mobile IP Registration Request message as the 815 indication that a mobile node may reside behind a NAT. If the 816 Registration Request also contains the UDP Tunnel Request extension 817 without the 'R' flag set, and the home agent is capable of, and 818 permits MIP UDP tunnelling, the home agent SHALL respond with a 819 registration reply containing an assenting UDP Tunnel Reply Extension 820 as described in Section 3.2. If the 'R' flag is set, special 821 considerations apply, as described below. 823 If the home agent receives a Registration Request with matching 824 source IP address and co-located care-of address which contains a MIP 825 UDP Tunnel Request Extension, the home agent SHOULD respond with a 826 Registration Reply containing a declining UDP Tunnel Reply - unless 827 tunnelling has been explicitly requested by the mobile node using the 828 'F' flag as described in Section 3.1. 830 If the home agent assents to UDP tunnelling, it MUST use the source 831 address of the registration request as the effective care-of address, 832 rather than the care-of address given in the registration request, 833 except in the case where the 'R' flag is set in the UDP Tunnel 834 Request Extension. 836 If the home agent receives a Registration Request with the 'R' flag 837 set in the UDP Tunnel Request Extension, it SHOULD reply with an 838 assenting UDP Tunnel Reply Extension if it is capable of, and permits 839 MIP UDP tunnelling. In this case, however, the source address and 840 port of the registration request may be a NAT'ed version of the 841 foreign agent source address and port. In order to direct tunnelled 842 traffic correctly to the mobile node, the home agent MUST wait for 843 the first keepalive packet from the mobile node to arrive, before it 844 can send traffic back to the correct NAT port (the one which is 845 mapped to the MN). In this case, the home agent MUST check that the 846 outer source address (but not the port) of this keepalive packet is 847 identical with the source address of the corresponding registration 848 request. The inner source address (that of the encapsulated ICMP 849 echo request) MUST be the home address of the mobile node, and the 850 inner destination address MUST be that of the home agent. If all 851 this holds, the outer source address and port of this keepalive 852 packet SHALL be used by the HA as the outer destination address and 853 port of the MIP UDP tunnel when forwarding traffic to the mobile 854 node. 856 The home agent SHOULD be consistent in acknowledging support for UDP 857 tunnelling or not. A home agent which understands the UDP Tunnel 858 Request Extension and is prepared to respond positively to such a 859 request SHOULD also respond with a UDP Tunnel Reply Extension 860 containing a declining reply code if use of MIP UDP tunnelling is not 861 indicated for a session. The mobile node MUST NOT assume such 862 behaviour from the home agent, since the home agent may undergo a 863 software change with reboot, a policy change or a replacement; and 864 consequently a change of behaviour. 866 4.6.1 Error Handling 868 The following actions take place when things go wrong. 870 The HA does not support the UDP Tunnel Request extension: 872 The home agent ignores the extension and proceeds normally, 873 which would be to refuse the registration if the IP source 874 address does not match the care-of address, the home address or 875 0.0.0.0. Even if the HA mistakenly does accept the 876 registration, the mobile node will not be able to receive 877 forward tunnelled data if it is behind a NAT. 879 (It would be beneficial to have the mobile node de-register in 880 this case. The mobile node, however, normally has no way of 881 telling that it is behind a NAT if it does not receive a UDP 882 Tunnelling Reply.) 884 NAT detected by home agent, but traversal not allowed: 886 In some cases the home agent may disable NAT traversal even 887 though it supports the UDP Tunnel Request extension and a NAT 888 is detected. In this case, the home agent SHOULD send a 889 Registration Reply with the Code field set to 129, 890 "administratively prohibited". 892 NAT not detected, 'F' flag set, but home agent does not allow forced 893 use of MIP UDP tunnelling: 895 The home agent SHOULD send a Registration Reply with the Code 896 field set to 129, "administratively prohibited". 898 UDP Tunnel Request extension sent by the mobile node (placed before 899 the MN-HA authentication extension), but 'D' bit in registration 900 request header not set: 902 The home agent SHOULD send a Registration Reply with the Code 903 field set to 134, "poorly formed Request". 905 UDP Tunnel Request extension sent by the foreign agent (placed after 906 the MN-HA authentication extension), but 'D' bit is set: 908 The home agent SHOULD send a Registration Reply with the Code 909 field set to 134, "poorly formed Request". 911 Reserved 3 field of UDP Tunnel Request extension is nonzero: 913 The home agent SHOULD send a Registration Reply with the Code 914 field set to 134, "poorly formed Request". 916 Encapsulation type requested in UDP Tunnel Request extension is 917 unsupported: 919 The home agent SHOULD send a Registration Reply with the Code 920 field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel 921 encapsulation unavailable" defined in Section 3.5. 923 4.7 MIP signalling versus tunnelling 925 UDP tunnelling SHALL be used only for data packets, and only when the 926 mobility binding used for sending was established using the UDP 927 Tunnel Request, and accepted by an UDP Tunnel Reply from the home 928 agent. After MIP UDP tunnelling has been established for a mobility 929 binding, data packets that are forward or reverse tunnelled using 930 this mobility binding MUST be tunnelled using MIP UDP tunnelling, not 931 IP-in-IP tunnelling or some other tunnelling method. 933 As a consequence: 935 - Mobile IP signalling is never tunnelled. 937 - When using simultaneous bindings, each binding may have a 938 different type (i.e. UDP tunnelling bindings may be mixed with 939 non-UDP tunnelling bindings). 941 - Tunnelling is only allowed for the duration of the binding 942 lifetime. 944 4.8 Packet fragmentation 946 From RFC 3022 [14]: 948 "Translation of outbound TCP/UDP fragments (i.e., those originating 949 from private hosts) in NAPT set-up are doomed to fail. The reason is 950 as follows. Only the first fragment contains the TCP/UDP header that 951 would be necessary to associate the packet to a session for 952 translation purposes. Subsequent fragments do not contain TCP/UDP 953 port information, but simply carry the same fragmentation identifier 954 specified in the first fragment. Say, two private hosts originated 955 fragmented TCP/UDP packets to the same destination host. And, they 956 happened to use the same fragmentation identifier. When the target 957 host receives the two unrelated datagrams, carrying same 958 fragmentation id, and from the same assigned host address, it is 959 unable to determine which of the two sessions the datagrams belong 960 to. Consequently, both sessions will be corrupted." 962 Because of this, if the mobile node or foreign agent for any reason 963 needs to send fragmented packets, the fragmentation MUST be done 964 prior to the encapsulation. This differs from the case for IP-in-IP 965 tunnelling, where fragmentation may be done before or after 966 encapsulation, although RFC 2003 [5] recommends doing it before 967 encapsulation. 969 A similar issue exists with some firewalls, which may have rules that 970 only permit traffic on certain TCP and UDP ports, and not arbitrary 971 outbound (or inbound) IP traffic. If this is the case and the 972 firewall is not set to do packet reassembly, a home agent behind a 973 firewall will also have to do packet fragmentation before MIP UDP 974 encapsulation. Otherwise, only the first fragment (which contains 975 the UDP header) will be allowed to pass from the home agent out 976 through the firewall. 978 For this reason, the home agent SHOULD do packet fragmentation before 979 it does MIP UDP encapsulation. 981 4.9 Tunnel Keepalive 983 As the existence of the bi-directional UDP tunnel through the NAT is 984 dependent on the NAT keeping state information associated with a 985 session, as described in RFC 2663 [13], and as the NAT may decide 986 that the session has terminated after a certain time, keepalive 987 messages may be needed to keep the tunnel open. The keepalives 988 should be sent more often than the timeout value used by the NAT. 989 This timeout may be assumed to be a couple of minutes, according to 990 RFC 2663 [13], but it is conceivable that shorter timeouts may exist 991 in some NATs. 993 For this reason the extension used to set up the UDP tunnel has the 994 option of setting the keepalive message interval to another value 995 than the default value, see Section 3.2. 997 The keepalive message sent MUST consist of a properly UDP 998 encapsulated ICMP echo request directed to the home agent. 1000 For each mobility binding which has UDP tunnelling established, the 1001 non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive 1002 packet if no other packet to the HA has been sent in K seconds. Here 1003 K is a parameter with a default value of 110 seconds. K may be set 1004 to another value by the HA as described in the UDP tunnelling reply 1005 extension (Section 3.2). 1007 Except for the case where the mobile node registers with a co-located 1008 address through an FA (see Section 4.11) MIP UDP tunnelling is done 1009 using the same ports that have already been used for the registration 1010 request / reply exchange. The MN or FA will send its first keepalive 1011 message at the earliest K seconds after the registration request was 1012 sent. The same UDP source port MUST be used for the keepalive 1013 messages as was used for the original Registration Messages and for 1014 data messages. 1016 The remote UDP tunnel endpoint MUST use two-way keepalives consisting 1017 of UDP encapsulated ICMP Echo Request/Reply messages. The rationale 1018 for using two-way keepalives is two-fold: 1020 1. Two-way keepalives allow the mobile node to detect loss of a 1021 NAT mapping. Detection of NAT mapping loss in turn allows the 1022 MN to compensate by re-registering and using a shorter 1023 keepalive to avoid loss of NAT mappings in the future. 1025 2. One-way keepalives actually cause more keepalive traffic 1026 overhead; the keepalive messages have to be sent more 1027 frequently to compensate for occasional loss of keepalive 1028 messages. In contrast, two-way keepalives are acknowledged, 1029 and retransmissions occur only when a response is not received 1030 for a keepalive request within a reasonable time. 1032 4.10 Detecting and compensating for loss of NAT mapping 1034 When a mobile node is using UDP encapsulated ICMP Echo Request/Reply 1035 messages as keepalives, it will have to deal with the possibility 1036 that a NAT mapping is lost by a NAT device. The crucial thing here 1037 is of course not the loss of the NAT mapping in itself; but rather 1038 that the home agent, in the absence of a Registration Request through 1039 the new mapping, will continue to send traffic to the NAT port 1040 associated with the old mapping. 1042 If the mobile node does not get a reply to its UDP encapsulated ICMP 1043 Echo Request even after a number of retransmissions, and is still 1044 connected to the same router that was used to establish the current 1045 mobility binding, the mobile node SHOULD re-register with the home 1046 agent by sending an Registration Request. This lets the HA know 1047 about the new NAT mapping and restores connectivity between mobile 1048 node and home agent. 1050 Having established a new mobility binding, the mobile node MAY use a 1051 shorter keepalive interval than before the NAT mapping was lost; in 1052 particular, the mobile node MAY deviate from the keepalive interval 1053 assigned by the home agent. If the binding loss continues to occur, 1054 the mobile node may shorten the keepalive interval each time it re- 1055 registers, in order to end up with a keepalive interval that is 1056 sufficient to keep the NAT mapping alive. The strategy used to 1057 arrive at a keepalive interval when a NAT mapping is lost is 1058 implementation dependent. However, the mobile node MUST NOT use a 1059 keepalive less than 10 seconds. 1061 Note that the above discussion only applies when the mobile node is 1062 re-registering through the same router, and thus presumably through 1063 the same NAT device that lost a NAT mapping earlier. If the MN moves 1064 and still finds itself behind a NAT, it SHOULD return to its original 1065 keepalive interval (the default value, or as assigned by the home 1066 agent) and it SHOULD NOT do any keepalive interval compensation 1067 unless it discovers a loss of NAT mapping in the new environment. 1069 The home agent MUST NOT attempt to detect or compensate for NAT 1070 binding loss by dynamically changing the keepalive interval assigned 1071 in the Registration Reply; the home agent does not have enough 1072 information to do this reliably and should thus not do it at all. 1073 The mobile node is in a much better position to determine when a NAT 1074 mapping has actually been lost. Note also that a MN is allowed to 1075 let a NAT mapping expire if the MN no longer needs connectivity. 1077 The discussion above does only in a limited sense apply to a foreign 1078 agent which is situated behind a NAT and using MIP UDP tunnelling. 1079 In this case, it is a matter of permanently configuring the FA to use 1080 a keepalive interval which is lower than the NAT mapping lifetime, 1081 rather than trying to dynamically adapt to the binding lifetimes of 1082 different NATs. 1084 4.11 Co-located registration through FA 1086 This section summarizes the protocol details which have been 1087 necessary in order to handle and support the case when a mobile node 1088 registers with a co-located address through a foreign agent, due to 1089 the FA advertisements having the 'R' bit set. It gives background 1090 information, but lists no new requirements. 1092 When a mobile registers a co-located care-of address through an FA, 1093 the registration request which reaches the HA will have a different 1094 care-of address in the registration request compared to the source 1095 address in the registration request IP-header. If the registration 1096 request also contains a UDP Tunnel Request Extension, the HA will 1097 erroneously set up a UDP tunnel, which will go to the FA instead of 1098 the MN. For this reason, as mentioned in Section 4.4, the mobile 1099 node must not include a UDP Tunnel Request Extension in the 1100 registration if it is registering a co-located address through an FA 1101 which does not have the 'U' bit set in its advertisements. 1103 In order to still be able to use MIP UDP tunnelling in this case, 1104 foreign agents which are situated behind a NAT are encouraged to send 1105 advertisements which have the 'U' bit set, as described in Section 1106 3.4. 1108 If the FA advertisement has the 'U' bit set, indicating that it is 1109 behind a NAT, and also the 'R' bit set, and the mobile node wishes to 1110 use a co-located care-of address, it MUST set the 'R' flag in the UDP 1111 Tunnel Request Extension, in order to inform the HA of the situation 1112 so that it may act appropriately, as described in Section 4.4. 1114 Because the UDP tunnel is now taking another path than the 1115 registration requests, the home agent, when handling registrations of 1116 this type, must wait till the arrival of the first keepalive packet 1117 before it can set up the tunnel to the correct address and port. To 1118 reduce the possibility of tunnel hijacking by sending a keepalive 1119 with a phony source address, it is required that only the port of the 1120 keepalive packet may be different from that of the registration 1121 request; the source address must be the same. This means that if the 1122 FA and MN are communicating with the HA through different NATs, the 1123 connection will fail. 1125 5. Implementation Issues 1127 5.1 Movement Detection and Private Address Aliasing 1129 In providing a mobile node with a mechanism for NAT traversal of 1130 Mobile IP traffic, we expand the address space where a mobile node 1131 may function and acquire care-of addresses. With this comes a new 1132 problem of movement detection and address aliasing. We here have a 1133 case which may not occur frequently, but is mentioned for 1134 completeness: 1136 Since private networks use overlapping address spaces, they may be 1137 mistaken for one another in some situations; this is referred to as 1138 private address aliasing in this document. For this reason, it may 1139 be necessary for mobile nodes implementing this specification to 1140 monitor the link layer address(es) of the gateway(s) used for sending 1141 packets. A change in the link layer address indicates probable 1142 movement to a new network, even if the IP address remains reachable 1143 using the new link layer address. 1145 For instance, a mobile node may obtain the co-located care-of address 1146 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP 1147 from network #1. It then moves to network #2, which uses an 1148 identical addressing scheme. The only difference for the mobile node 1149 is the gateway's link layer address. The mobile node should store 1150 the link layer address it initially obtains for the gateway (using 1151 ARP, for instance). The mobile node may then detect changes in the 1152 link layer address in successive ARP exchanges as part of its 1153 ordinary movement detection mechanism. 1155 In rare cases the mobile nodes may not be able to monitor the link 1156 layer address of the gateway(s) it is using, and may thus confuse one 1157 point of attachment with another. This specification does not 1158 explicitly address this issue. The potential traffic blackout caused 1159 by this situation may be limited by ensuring that the mobility 1160 binding lifetime is short enough; the re-registration caused by 1161 expiration of the mobility binding fixes the problem (see Section 1162 5.2). 1164 5.2 Mobility Binding Lifetime 1166 When responding to a registration request with a registration reply, 1167 the home agent is allowed to decrease the lifetime indicated in the 1168 registration request, as covered in RFC 3344 [11]. When using UDP 1169 tunnelling, there are some cases where a short lifetime is 1170 beneficial. 1172 First, if the NAT mapping maintained by the NAT device is dropped, a 1173 connection blackout will arise. New packets sent by the mobile node 1174 (or the foreign agent) will establish a new NAT mapping, which the 1175 home agent will not recognize until a new mobility binding is 1176 established by a new registration request. 1178 A second case where a short lifetime is useful is related to the 1179 aliasing of private network addresses. In case the mobile node is 1180 not able to detect mobility and ends up behind a new NAT device (as 1181 described in Section 5.1), a short lifetime will ensure that the 1182 traffic blackout will not be exceedingly long, and is terminated by a 1183 re-registration. 1185 The definition of "short lifetime" in this context is dependent on 1186 the requirements of the usage scenario. Suggested maximum lifetime 1187 returned by the home agent is 60 seconds, but in case the 1188 abovementioned scenarios are not considered a problem, longer 1189 lifetimes may of course be used. 1191 6. Security Considerations 1193 The ordinary Mobile IP security mechanisms are also used with the NAT 1194 traversal mechanism described in this document. However, there is 1195 one noticeable change: the NAT traversal mechanism requires that the 1196 HA trust unauthenticated address (and port) fields possibly modified 1197 by NATs. 1199 Relying on unauthenticated address information when forming or 1200 updating a mobility binding leads to several redirection attack 1201 vulnerabilities. In essence, an attacker may do what NATs do, i.e. 1202 modify addresses and ports and thus cause traffic to be redirected to 1203 a chosen address. The same vulnerabilities apply to both MN-HA and 1204 FA-HA NAT traversal. 1206 In more detail: without a NAT, the care-of address in the 1207 registration request will be directly used by the HA to send traffic 1208 back to the MN (or the FA), and the care-of address is protected by 1209 the MN-HA (or FA-HA) authentication extension. When communicating 1210 across a NAT, the effective care-of address from the HA point of view 1211 is that of the NAT, which is not protected by any authentication 1212 extension, but inferred from the apparent IP source address of 1213 received packets. This means that by using the mobile IP 1214 registration extensions described in this document to enable 1215 traversal of NATs, one is opening oneself up to having the care-of 1216 address of a MN (or a FA) maliciously changed by an attacker. 1218 Some, but not all, of the attacks could be alleviated to some extent 1219 by using a simple routability check. However, this document does not 1220 specify such a mechanism for simplicity reasons and because the 1221 mechanism would not protect against all redirection attacks. To 1222 limit the duration of such redirection attacks, it is RECOMMENDED to 1223 use a conservative (that is, short) mobility binding lifetime when 1224 using the NAT traversal mechanism specified in this document. 1226 The known security issues are described in the sections that follow. 1228 6.1 Traffic Redirection Vulnerabilities 1230 6.1.1 Manipulation of the Registration Request Message 1232 An attacker on the route between the mobile node (or foreign agent) 1233 and the home agent may redirect mobility bindings to a desired 1234 address simply by modifying the IP and UDP headers of the 1235 Registration Request message. Having modified the binding, the 1236 attacker no longer needs to listen to (or manipulate) the traffic. 1237 The redirection is in force until the mobility binding expires or the 1238 mobile node re-registers. 1240 This vulnerability may be used by an attacker to read traffic 1241 destined to a mobile node, and to send traffic impersonating the 1242 mobile node. The vulnerability may also be used to redirect traffic 1243 to a victim host in order to cause denial-of-service on the victim. 1245 The only defence against this vulnerability is to have a short time 1246 between re-registrations, which limits the duration of the 1247 redirection attack after the attacker has stopped modifying 1248 registration messages. 1250 6.1.2 Sending a Bogus Keepalive Message 1252 When registering through an FA using a co-located care-of address, 1253 another redirection vulnerability opens up. Having exchanged 1254 Registration Request/Reply messages with the HA through the FA, the 1255 MN is expected to send the first keepalive message to the HA, thus 1256 finalizing the mobility binding (the binding will remain in a "half 1257 bound" state until the keepalive is received). 1259 Having observed a Registration Request/Reply exchange, an attacker 1260 may send a bogus keepalive message assuming that the mobility binding 1261 is in the "half bound" state. This opens up a similar redirection 1262 attack as discussed in Section 6.1.1. Note, however, that the 1263 attacker does not need to be able to modify packets in flight; simply 1264 being able to observe the Registration Request/Reply message exchange 1265 is sufficient to mount the attack. 1267 With this in mind, the home agent MUST NOT accept a keepalive message 1268 from a different source IP address than where the Registration 1269 Request came from, as specified in Section 4.6. This requirement 1270 limits the extent of the attack to redirecting the traffic to a bogus 1271 UDP port, while the IP address must remain the same as in the initial 1272 Registration Request. 1274 The only defences against this vulnerability are: (1) to have a short 1275 time between re-registrations, which limits the duration of the 1276 redirection attack after the attacker has stopped sending bogus 1277 keepalive messages, and (2) to minimize the time the binding is in a 1278 "half bound" state by having the mobile node send the first keepalive 1279 message immediately after receiving an affirmative registration 1280 reply. 1282 6.2 Use of IPsec 1284 If the intermediate network is considered insecure, it is recommended 1285 that IPsec be used to protect user data traffic. However, IPsec does 1286 not protect against the redirection attacks described previously, 1287 other than to protect confidentiality of hijacked user data traffic. 1289 The NAT traversal mechanism described in this document allows all 1290 IPsec-related traffic to go through NATs without any modifications to 1291 IPsec. In addition, the IPsec security associations do not need to 1292 be re-established when the mobile node moves. 1294 6.3 Firewall Considerations 1296 This document does not specify a general firewall traversal 1297 mechanism. However, the mechanism makes it possible to use only a 1298 single address and a port for all MN-HA (or FA-HA) communication. 1299 Furthermore, using the same port for the MIP UDP tunnelled traffic as 1300 for control messages makes it quite probable that if a MIP 1301 registration can reach the home agent, MIP tunnelling and reverse 1302 tunnelling using the described mechanism will also work. 1304 7. UNSAF Considerations 1306 The mechanism described in this document is not an "UNilateral Self- 1307 Address Fixing" (UNSAF) mechanism. Although the mobile node makes no 1308 attempt to determine or use the NAT translated address, the mobile 1309 node through the registration process does attempt to keep the NAT 1310 mapping alive through refresh messages. This section attempts to 1311 address issues that may be raised through this usage through the 1312 framework of the unsaf considerations IAB document [15]. 1314 1. Precise definition. 1315 This proposal extends the Mobile IP v4 registration process to 1316 work across intervening NATs. The Home Agent detects the 1317 presence of the NAT by examining the source address in the 1318 packet header and comparing it with the address contained in 1319 the registration message. 1321 The NAT address and port detected by the home agent are not 1322 exported or communicated to any other node anywhere. 1324 2. Exit strategy. 1325 This mechanism will go out of use as IPv6 and Mobile IP v6 is 1326 deployed, obviating the need for MIPv4 NAT traversal. 1328 It can also be noted that this mechanism makes no changes to 1329 the base MIPv4 protocol which makes it dependent on the 1330 presence of NATs or the current extensions - i.e. no 1331 additional protocol changes would be needed if NATs were to go 1332 away. 1334 3. Issues making systems more brittle. 1335 The specific issue which is relevant here is that the 1336 effective care-of address (being the source address in the IP 1337 header received by the HA) is not protected by the Mobile IP 1338 authentication extension, and therefore may be spoofed. This 1339 is discussed in some detail in Section 6, Security 1340 Considerations. 1342 4. Requirements for longer term solutions. 1343 The trivial long term solution is a transition to an 1344 environment where NATs are not required. The most obvious 1345 such environment would be an IPv6 based internet. 1347 In the presence of NATs, an improved solution would require 1349 * the ability to discover the translations done by each 1350 NAT along the route 1352 * the ability to validate the authority of each NAT to do 1353 those translations 1355 * communicating as part of the signed registration request 1356 the address of the NAT closest to the HA, for use as the 1357 effective care-of address from the viewpoint of the HA. 1359 * configuration of all intermediate NATs to accept only 1360 packets from the neighbour NATs. 1362 5. Impact on existing, deployed NATs. 1363 One precursor of the mechanism described here has been used 1364 successfully across deployed NATs in Sweden, Germany, England, 1365 Japan and the USA, without necessitating neither adjustments 1366 of the NATs in question, nor adjustment of any protocol 1367 parameters. At the time of writing, little experience exist 1368 with the exact implementation proposed in this document, but 1369 effort has been put into making this mechanism even more 1370 robust and adaptive than its precursors. 1372 With respect to the base Mobile IP specification, the impact 1373 of this document is that an increased frequency of 1374 registration requests is recommended from a security 1375 perspective when the NAT traversal mechanism is used. 1377 8. IANA Considerations 1379 The numbers for the extensions defined in this I-D should be taken 1380 from the numbering space defined for Mobile IP messages, registration 1381 extensions and error codes defined in RFC 3344 [11]. This draft 1382 proposes one new message, two new extensions and a new error code 1383 that require type numbers and error code value to be assigned by 1384 IANA. The two new extensions also introduce two new sub-type 1385 numbering spaces to be managed by IANA. 1387 Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request 1388 Extension. The type number for this extension should be of type 1389 skippable. This extension introduces a new sub-type numbering space 1390 where the value 0 has been assigned to this extension. Approval of 1391 new Tunnel Request Extension sub-type numbers is subject to Expert 1392 Review, and a specification is required [8]. 1394 Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply 1395 Extension . The type value for this extension should be of type non- 1396 skippable. This extension introduces a new sub-type numbering space 1397 where the value 0 has been assigned to this extension. Approval of 1398 new Tunnel Reply Extension sub-type numbers is subject to Expert 1399 Review, and a specification is required [8]. 1401 Section 3.3 defines a new Mobile IP message, the Tunnel Data message. 1402 The type value for this message should be taken from the numbering 1403 space defined for Mobile IP messages. 1405 Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: 1406 "Requested UDP tunnel encapsulation unavailable", from the numbering 1407 space for values defined for use with the Code field of Mobile IP 1408 Registration Reply Messages. This code should be taken from the 1409 subset "Error Codes from the Home Agent". 1411 The values for the Next Header field in the MIP Tunnel Data Message 1412 (Section 3.3) shall be the same as those used for the Protocol field 1413 of the IP header[2], and requires no new number assignment. 1415 9. Intellectual property rights 1417 The IETF has been notified of intellectual property rights claimed in 1418 regard to some or all of the specification contained in this 1419 document. For more information consult the online list of claimed 1420 rights. 1422 10. Acknowledgements 1424 Much of the text in Section 4.2 has been taken almost verbatim from 1425 RFC 2003, IP Encapsulation within IP [5]. 1427 Adding support for the FA case was suggested by George Tsirtsis and 1428 Frode B. Nilsen. Roy Jose pointed out a problem with binding 1429 updates, and Frode, Roy and George pointed out that there are cases 1430 where triangular routes may work, and suggested that reverse 1431 tunnelling need not be mandatory. Roy and Qiang Zhang drew attention 1432 to a number of sections which needed to be corrected or stated more 1433 clearly. 1435 Phil Roberts helped remove a number of rough edges. Farid Adrangi 1436 pointed out the DoS issue now covered in Security Considerations 1437 (Section 6). Francis Dupont's helpful comments made us extend the 1438 Security Considerations section to make it more comprehensive and 1439 clear. Milind Kulkarni and Madhavi Chandra pointed out the required 1440 match between the FA source and care-of addresses when the mechanism 1441 is used by an FA, and also contributed a number of clarifications to 1442 the text. 1444 Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and 1445 Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik 1446 Liden at ipUnplugged. They have read and re-read the text, and 1447 contributed many valuable corrections and insights. 1449 Normative References 1451 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1452 1980. 1454 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1455 1981. 1457 [3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 1458 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1460 [4] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1461 1768, March 1995. 1463 [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1464 1996. 1466 [6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1467 October 1996. 1469 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1470 Levels", BCP 14, RFC 2119, March 1997. 1472 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1473 Considerations Section in RFCs", BCP 26, RFC 2434, October 1474 1998. 1476 [9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 1477 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 1479 [10] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 1480 3024, January 2001. 1482 [11] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 1483 2002. 1485 Informative References 1487 [12] Atkinson, R., "IP Authentication Header", RFC 1826, August 1488 1995. 1490 [13] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1491 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1493 [14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1494 Translator (Traditional NAT)", RFC 3022, January 2001. 1496 [15] Daigle, L., "IAB Considerations for UNilateral Self-Address 1497 Fixing (UNSAF)", draft-iab-unsaf-considerations-01 (work in 1498 progress), February 2002. 1500 [16] Levkowetz, H., "NAT Traversal for Mobile IP using UDP 1501 Tunnelling", draft-levkowetz-mobileip-nat-tunnel-00 (work in 1502 progress), July 201. 1504 Authors' Addresses 1506 O. Henrik Levkowetz 1507 ipUnplugged AB 1508 Arenavagen 33 1509 Stockholm S-121 28 1510 SWEDEN 1512 Phone: +46 8 725 9513 1513 EMail: henrik@levkowetz.com 1515 Sami Vaarala 1516 Netseal 1517 Niittykatu 6 1518 Espoo 02201 1519 FINLAND 1521 Phone: +358 9 435 310 1522 EMail: sami.vaarala@iki.fi 1524 Full Copyright Statement 1526 Copyright (C) The Internet Society (2002). All Rights Reserved. 1528 This document and translations of it may be copied and furnished to 1529 others, and derivative works that comment on or otherwise explain it 1530 or assist in its implementation may be prepared, copied, published 1531 and distributed, in whole or in part, without restriction of any 1532 kind, provided that the above copyright notice and this paragraph are 1533 included on all such copies and derivative works. However, this 1534 document itself may not be modified in any way, such as by removing 1535 the copyright notice or references to the Internet Society or other 1536 Internet organizations, except as needed for the purpose of 1537 developing Internet standards in which case the procedures for 1538 copyrights defined in the Internet Standards process must be 1539 followed, or as required to translate it into languages other than 1540 English. 1542 The limited permissions granted above are perpetual and will not be 1543 revoked by the Internet Society or its successors or assigns. 1545 This document and the information contained herein is provided on an 1546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1552 Acknowledgement 1554 Funding for the RFC Editor function is currently provided by the 1555 Internet Society.