idnits 2.17.00 (12 Aug 2021) /tmp/idnits55684/draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this draft.' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '...nd specifies requirements that MUST be...' RFC 2119 keyword, line 253: '... network MUST run inside an IPs...' RFC 2119 keyword, line 404: '... the VPN gateway MUST protect the IP t...' RFC 2119 keyword, line 406: '...A, the tunnel SA MUST be refreshed aft...' RFC 2119 keyword, line 415: '... network MUST establish an IPse...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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: - The solution MUST not require any configuration or software changes to exiting NAT gateways. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: MIPv4 route optimization is not widely supported, as it requires changes to both MN's home agent and the correspondent node. Hence, The solution MAY or MAY NOT support MIPv4 Route Optimization [ROUTE-OPT]. -- 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 (January 2002) is 7431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2663' on line 578 looks like a reference -- Missing reference section? 'DHCP' on line 580 looks like a reference -- Missing reference section? 'RFC2004' on line 569 looks like a reference -- Missing reference section? 'RFC1701' on line 570 looks like a reference -- Missing reference section? 'MIP-NAT' on line 448 looks like a reference -- Missing reference section? 'ROUTE-OPT' on line 586 looks like a reference -- Missing reference section? 'RFC3220' on line 567 looks like a reference -- Missing reference section? 'RFC3024' on line 568 looks like a reference -- Missing reference section? 'RFC2119' on line 575 looks like a reference -- Missing reference section? 'RFC1918' on line 577 looks like a reference -- Missing reference section? 'MIPv4-SEC-GUIDE' on line 581 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Farid Adrangi 2 INTERNET DRAFT Prakash Iyer 3 Category: Informational Intel Corp. 5 6 Date: January 2002 8 Problem Statement and Requirements for Mobile IPv4 Traversal 9 Across VPN or 'NAT and VPN' Gateways 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To view the entire list of current Internet-Drafts, please 34 check the "1id-abstracts.txt" listing contained in the 35 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 36 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 37 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 38 Coast), or ftp.isi.edu (US West Coast). 40 Abstract 42 This draft describes the problem statement and specifies the 43 solution requirements for MIPv4 traversal across VPN or 'NAT 44 and VPN' gateways. The 'NAT and VPN' case refers to a network 45 topology in which the MIPv4 traffic has to traverse one or more 46 NAT gateway(s) followed by a VPN gateway in the path to its 47 final destination. Requirements and problems associated with 48 MIPv4 traversal through NAT gateways NOT involving VPNs is 49 outside the scope of this draft. 51 Table of Contents 53 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 54 January 2002 56 1. Introduction....................................................2 57 2. Terminology.....................................................3 58 3. Acronyms........................................................3 59 4.0. Roaming Scenarios.............................................4 60 4.1. Roaming Inside the Home Network...............................5 61 4.2. Roaming Outside the Home Network..............................5 62 4.2.1. Roaming Outside the Home Network in a Routable Address Space 63 (where, FA-assisted routing is not used)...........................6 64 4.2.2 Roaming Outside the Home Network in Routable Address Space 65 (where, FA-assisted routing is used)...............................6 66 4.2.3 Roaming Outside the Home Network in a non-Routable Address 67 Space..............................................................7 68 5. Problem Statement...............................................8 69 5.1. MIPv4 Incompatibilities with VPN Gateways.....................8 70 5.2. MIPv4 Incompatibilities with NAT Gateways.....................9 71 6. The Requirements................................................9 72 6.1. Implications of Intervening NAT Gateways......................9 73 6.2. Implications of Cascaded NAT.................................10 74 6.3. MIPv4 Protocol...............................................10 75 6.5. Functional Entities..........................................10 76 6.6. Multi-vendor Interoperability................................10 77 6.7. Fast MIPv4 Handoffs..........................................10 78 6.8. Preservation of Existing VPN Infrastructure..................11 79 6.9. Preserve Existing DMZ Traversal Policies.....................11 80 6.10 Support For Route Optimization...............................11 81 6.11 MIPv4 Registration SA Management.............................11 82 6.12 Security Implications........................................11 83 7. References.....................................................11 85 1. Introduction 87 Multi-subnetted IEEE 802.11 WLAN networks are being widely 88 deployed in Enterprise Intranets - in many cases requiring a 89 VPN tunnel to connect back and access Intranet resources, and 90 public areas such as airports, coffee shops, convention centers 91 and shopping malls. Many of these WLAN networks also employ NAT 92 to translate between non-routable and routable IPv4 care-of 93 (point of attachment) addresses. WWAN networks such as those 94 based on GPRS and eventually EDGE and UMTS are also starting to 95 see deployment. These deployments are paving the way for 96 applications and usage scenarios requiring TCP/IP session 97 persistence and constant reachability while connecting back to 98 a secured (VPN protected), target 'home' network. This in turn 99 drives the need for a mobile VPN solution that is multi-vendor 100 interoperable, providing seamless access with persistent VPN 101 sessions and through NAT gateways when needed. This draft 102 identifies example usage scenarios, defines a problem statement 103 based on the scenarios and specifies requirements that MUST be 104 met to ensure broad deployment of multi-vendor interoperable 105 solutions. 107 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 108 January 2002 110 The important sections of this draft are organized as follows: 112 Section 4: Describe roaming scenarios to motivate the 113 problem statement 115 Section 5: Describes a problem statement for MIPv4 116 traversal across VPN and NAT gateways. 118 Section 6: Specifies the requirements for a solution to 119 support multi-vendor seamless IPv4 mobility 120 across VPN or the 'NAT VPN' gateways. 122 2. Terminology 124 Traditional NAT: 125 Network Address Translation. "Traditional NAT would allow 126 hosts within a private network to transparently access hosts in 127 the external network, in most cases. In a traditional NAT, 128 sessions are uni-directional, outbound from the private 129 network." ' [RFC2663]. Traditional NAT' are of two types: 130 Basic NAT and NAPT. 132 Basic NAT: 133 "With Basic NAT, a block of external addresses are set aside 134 for translating addresses of hosts in a private domain as they 135 originate sessions to the external domain. For packets 136 outbound from the private network, the source IP address and 137 related fields such as IP, TCP, UDP and ICMP header checksums 138 are translated. For inbound packets, the destination IP 139 address and the checksums as listed above are translated." û 140 [RFC2663] 142 NAPT: 143 Network Address Port Translation. "NAPT extends the notion of 144 translation one step further by also translating transport 145 identifier (e.g., TCP and UDP port numbers, ICMP query 146 identifiers). This allows the transport identifiers of a 147 number of private hosts to be multiplexed into the transport 148 identifiers of a single external address. NAPT allows a set of 149 hosts to share a single external address. Note that NAPT can 150 be combined with Basic NAT so that a pool of external addresses 151 are used in conjunction with port translation." û [RFC2663] 153 3. Acronyms 154 ACL: Access Control List 155 GRE: Generic Routing Encapsulation 156 MIPv4: Mobile IP for IPv4 157 MIPv6: Mobile IP for IPv6 158 VPN: Virtual Private Network 160 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 161 January 2002 163 MN-Perm: Permanent home address of the MN 164 MN-COA: Co-located care-of address of the MN 165 WLAN: IEEE 802.11 Wireless Local Area Network 167 4.0. Roaming Scenarios 169 This section describes roaming scenarios, wherein MIPv4 traffic 170 has to traverse VPN or the 'NAT and VPN' gateways. The 171 scenarios are constructed based on a multi-subnetted MIPv4 172 enabled Intranet (hereafter, referred by Home Network or VPN 173 domain) protected by an IPsec-based VPN gateway as depicted in 174 Figure 4.0a. 176 +---------+ +------+ +---------------------------+ 177 | | | | |Home network / VPN Domain | 178 | | |IPsec-| | +----+ +-----+ +----+ | 179 |Internet | |based |<->| |HA-1 | HA-2| |HA-n| | 180 | | | | | +----+ +-----+ +----+ | 181 | | | VPN | | | 182 +---------+ +------+ | +----+ +-----+ +----+ | 183 | |FA-1| | FA-2| |FA-n| | 184 | +----+ +-----+ +----+ | 185 | | 186 | +----+ +-----+ +-----+ | 187 | |MN-1| | MN-2| | MN-n| | 188 | +----+ +-----+ +-----+ | 189 +---------------------------+ 191 Figure 4.0a Home Network protected by a VPN Gateway 193 The home network, depicted in Figure 4.0a, may include both 194 wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. 195 However, it is also possible to see IEEE 802.11 deployments 196 outside the home network due to perceived lack of 802.1x 197 security, as depicted in Figure 4.0b. 199 +---------+ +------+ +---------------------------+ 200 | | | | |Home network / VPN Domain | 201 | | |IPsec-| | +----+ +-----+ +----+ | 202 |Internet | |-->|based |<->| |HA-1| | HA-2| |HA-n| | 203 | | | | | | +----+ +-----+ +----+ | 204 | | | | VPN | | | 205 +---------+ | +------+ | +----+ +-----+ +----+ | 206 | | |FA-1| | FA-2| |FA-n| | 207 | | +----+ +-----+ +----+ | 208 +-----------------+ | | 209 | | | +----+ +-----+ +-----+ | 210 | 802.11 Wireless | | |MN-1| | MN-2| | MN-n| | 211 | Network | | +----+ +-----+ +-----+ | 212 | | +---------------------------+ 213 +-----------------+ 215 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 216 January 2002 218 Figure 4.0b' IEEE 802.11 Wireless deployment outside the home 219 network 221 To help describe scenarios in the following sections, we have 222 used the aid of an imaginary nomadic user, called Dr. Joe. 223 Dr. Joe is a chief surgeon in a hospital, and always on the 224 move. He leverages his wireless MIPv4 enabled hand-held device 225 to access his patient' records, communicate with his 226 colleagues and staff, and stay reachable in case of any 227 emergencies. For clarity, we assume that Dr. Joe' hospital 228 employs a network similar to the one showed in Figure 4.0a 229 (MIPv4 enabled network protected by a VPN, and includes both 230 wired and IEEE 802.11 wireless deployments). 232 4.1. Roaming Inside the Home Network 234 Dr. Joe' needs for constant reachablity and maintaining his 235 current transport connections as he roams from one network link 236 to another are met by standard MIPv4 deployment inside the home 237 network. Please note that NATÆed networks might be seen inside 238 the home network, however, draft-mobileip-nat-traversal-00.txt 239 solves the problem, as the mobile node's home agent will most 240 likely be directly reachable by the mobile node. 242 4.2. Roaming Outside the Home Network 244 Dr. Joe frequently visits other clinics and hospitals, in which 245 a multi-subnetted IEEE 802.11 hot spot network is utilized to 246 provide Internet access for visitors. Dr. Joe leverages the 247 hot spot network to connect to his home network, and he would 248 also like to maintain his transport connections to the home 249 network as he roams from one network link to another in the hot 250 spot network. 252 This implies that the MIPv4 traffic destined to the home 253 network MUST run inside an IPsec tunnel (i.e, MIP/IP/ESP/IP) 254 established between the mobile node and the home networkÆs VPN 255 gateway. Moreover, the IPsecÆed MIPv4 traffic may also have to 256 traverse a NAT gateway or a foreign agent in the path to the 257 VPN gateway. The following sub-sections illustrate these 258 possibilities. 260 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 261 January 2002 263 4.2.1. Roaming Outside the Home Network in a Routable Address Space 264 (where, FA-assisted routing is not used) 266 +---------+ +------+ +---------------------------+ 267 |Internet | | | |Home network /VPN Domain | 268 | |--------------|IPsec-| | +----+ +-----+ +----+ | 269 | | |-----------|based |<->| |HA-1 | HA-2| |HA-n| | 270 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 271 | | +------+ | | 272 | | | +----+ +-----+ +----+ | 273 | |<-- IPsec Tunnel | |FA-1| | FA-2| |FA-n| | 274 | | | +----+ +-----+ +----+ | 275 | | | | 276 +---|--|---+ | +----+ +-----+ +-----+ | 277 | | | | | |MN-1| |MN-2 | |MN-n | | 278 | +-|--|-+ | | +----+ +-----+ +-----+ | 279 | | MN | | | | 280 | +------+ | +---------------------------+ 281 | Multi- | 282 | Subnetted| 283 | Hot Spot | 284 | | 285 +----------+ 287 4.2.2 Roaming Outside the Home Network in Routable Address Space 288 (where, FA-assisted routing is used) 290 There is a notion of trusted FA, where there is a SA 291 established between the FA and home VPN gateway. In this 292 case, IPsec tunnel end-points are the FA and home VPN gateway. 293 Furthermore, It is also possible for the MN in a trusted FA 294 region to have end-to-end security with its home VPN gateway. 295 This implies that there will be two pairs of IPsec tunnels, 296 one between the FA and home VPN gateway, and the other between 297 the MN and its home VPN gateway. Figure 4.3.2a shows the MN in 298 a trusted FA region, where there is only an IPsec tunnel 299 between the FA and home VPN gateway. 301 In a non-trusted FA region, where there is no SA established 302 between the FA and home gateway, there will always be a single 303 IPsec tunnel established between the MN and its home VPN 304 gateway, as depicted in Figure 4.3.2b. 306 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 307 January 2002 309 +---------+ +------+ +---------------------------+ 310 |Internet | | | |Home network /VPN Domain | 311 | |--------------|IPsec-| | +----+ +-----+ +----+ | 312 | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | 313 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 314 | | +------+ | | 315 +--|--|----+ | +----+ +-----+ +----+ | 316 | +|--|+ | | |FA-1| | FA-2| |FA-n| | 317 | | FA | | | +----+ +-----+ +----+ | 318 | +----+ | | | 319 | | | +----+ +-----+ +-----+ | 320 | +----+ | | |MN-1| |MN-2 | |MN-n | | 321 | |MN | | | +----+ +-----+ +-----+ | 322 | +----+ | | | 323 | Multi- | +---------------------------+ 324 | Subnetted| 325 | Hot Spot | 326 +----------+ 328 Figure 4.3.2a - the MN in trusted FA region 330 +---------+ +------+ +---------------------------+ 331 |Internet | | | |Home network /VPN Domain | 332 | |--------------|IPsec-| | +----+ +-----+ +----+ | 333 | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | 334 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 335 | | +------+ | | 336 +--|--|----+ | +----+ +-----+ +----+ | 337 | +|--|+ | | |FA-1| | FA-2| |FA-n| | 338 | ||FA|| | | +----+ +-----+ +----+ | 339 | +|--|+ | | | 340 | | |<------- IPsec Tunnel | +----+ +-----+ +-----+ | 341 | +|--|+ | | |MN-1| |MN-2 | |MN-n | | 342 | |MN | | | +----+ +-----+ +-----+ | 343 | +----+ | | | 344 | Multi- | +---------------------------+ 345 | Subnetted| 346 | Hot Spot | 347 +----------+ 349 Figure 4.3.2b - the MN in non-trusted FA region 351 4.2.3 Roaming Outside the Home Network in a non-Routable Address 352 Space 354 Note that the MN's home agent is not directly reachable in 355 this case. Therefore, draft-mobileip-nat-traversal-00.txt 356 cannot be directly applied. Furthermore, cascaded NAT gateway 358 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 359 January 2002 361 deployment is also a possibility, but not shown in the 362 diagram. 364 +---------+ +------+ +---------------------------+ 365 | Internet| | | |Home network /VPN Domain | 366 | ---------------|IPsec-| | +----+ +-----+ +----+ | 367 | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | 368 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 369 | | +------+ | | 370 +--|--|+ | +----+ +-----+ +----+ | 371 | NAT || | |FA-1| | FA-2| |FA-n| | 372 +--|--|+ | +----+ +-----+ +----+ | 373 | |<------ IPsec Tunnel | | 374 +--|--|----+ | +----+ +-----+ +-----+ | 375 | +----+ | | |MN-1| |MN-2 | |MN-n | | 376 | | MN | | | +----+ +-----+ +-----+ | 377 | +----+ | | | 378 | Multi- | +---------------------------+ 379 | Subnetted| 380 | Hot Spot | 381 +----------+ 383 5. Problem Statement 385 This section describes MIPv4 incompatibilities with IPsec-based 386 VPN and NAT gateways, in the context of the roaming scenarios 387 outlined in section 4. 389 5.1. MIPv4 Incompatibilities with VPN Gateways 391 There are two problems associated with MIPv4 and VPN 392 incompatibilities. 394 Problem 1: The MN could roam into a foreign subnet with a FA. 395 If the MN were to associate a VPN tunnel with its CoA, the FA 396 (which is likely in a different administrative domain) cannot 397 parse the IPsec tunnel SA and will not be able to setup SAs 398 with the MN's VPN gateway and will consequently be not able to 399 relay MIPv4 packets between the MN and the VPN gateway. 400 ` 401 Problem 2: The MN could roam into a foreign subnet without a FA 402 and obtain a CoA at its point of attachment (via [DHCP] or some 403 other means). In an end-to-end security model, an IPsec tunnel 404 that terminates at the VPN gateway MUST protect the IP traffic 405 originating at the MN. If the IPsec tunnel is associated with 406 the CoA, the tunnel SA MUST be refreshed after each IP subnet 407 handoff which could have some performance implications on real- 408 time applications. 410 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 411 January 2002 413 It is important to note that only IPsec tunnel mode is 414 applicable here, as the mobile node connecting to the home 415 network MUST establish an IPsec tunnel SA to the VPN gateway. 417 5.2. MIPv4 Incompatibilities with NAT Gateways 419 There are also two problems associated with MIPv4 and NAT 420 incompatibilities: 422 Problem 1: When an MN roams from its 'home' network (which may 423 or may not be in a routable IP address space) protected by a 424 VPN to a foreign network behind a NAT gateway, it acquires a 425 non-routable care-of address (most likely through [DHCP]). The 426 acquired non-routable care-of address is passed to the HA 427 through a registration request. This causes the MN to lose its 428 connectivity to its home network, since the HA will not be able 429 to forward the MN's packets to the non-routable care-of 430 address. 432 Problem 2: Even if we solve the first problem, an intervening 433 NAT gateway in a foreign network will not always be able to 434 demultiplex inbound IP-in-IP reverse tunneled MIPv4 data 435 packets. Because, NAPT gateways will simply not be able to 436 route the inbound IP-in-IP packets, as they rely on IP address 437 and transport identifier to route the packets from routable to 438 non-routable address space or vice a versa. And, in the case of 439 Basic NAT, consider two MNs that are registered with the same 440 Home Agent (HA). The inbound packets destined to the two MNs 441 from the HA will have the same source and destination IP 442 addresses ' making it difficult for the NAT to route the 443 packets inside. 445 The implications on Minimal IP [RFC2004] and GRE encapsulation 446 [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling. 448 Draft [MIP-NAT] describes a solution to the NAT traversal 449 problem when VPNs are not involved. In this draft, we only 450 discuss NAT traversal requirements where the HA is behind a VPN 451 gateway and hence not directly reachable by the MN. 453 6. The Requirements 455 This section describes the requirements that are intended to 456 establish a framework where in a solution can be developed to 457 support MIPv4 traversal across VPN or 'NAT and VPN' gateways. 459 6.1. Implications of Intervening NAT Gateways 461 - The solution MUST work with both Basic NAT and NAPT. 463 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 464 January 2002 466 - The solution MUST not require any configuration or software 467 changes to exiting NAT gateways. 469 The reason for the above constraints is to not limit the 470 solution to network topologies that employ certain types of NAT 471 gateways and to enable deployment of MIPv4 in networks that 472 have currently deployed non-modifiable NAT gateways. 474 6.2. Implications of Cascaded NAT 476 Cascaded NAT deployment is seen in some network topologies 477 (case in point, a residential NAT gateway connected to a NATÆed 478 ISP network). Therefore, the solution MUST support cascaded 479 NAT. 481 6.3. MIPv4 Protocol 483 - The solution MUST be compliant with MIPv4 protocol [RFC 484 3220]. 485 - The solution MAY introduce new extensions to MIPv4 protocol 486 per guidelines specified in the MIPv4 RFCs. However, it is 487 highly desirable to avoid any changes to MIPv4 mobility agents 488 such as the FA and HA in order to overcome barriers to 489 deployment. 491 6.5. Functional Entities 493 The solution MAY introduce a MIPv4 compliant functional entity 494 that helps MIPv4 traversal across VPN or the ôNAT and VPNö 495 gateways. However, scalability, manageability and availability 496 implications introduced by that functional entity MUST be well 497 understood. The functional entity MAY be implemented as a 498 standalone entity or combined with another device such as a VPN 499 gateway. 501 6.6. Multi-vendor Interoperability 503 Multi-vendor interoperability is a key requirement. In most 504 Enterprises, MIPv4 mobility agents are likely to be deployed in 505 existing routers from vendor X while VPN client/server 506 solutions may come from vendor Y and mobility clients (MN) may 507 come from yet another vendor. Medium and large Enterprises that 508 typically purchase and deploy best-of-breed multi-vendor 509 solutions for IP routing, VPNs, firewalls etc. are unlikely to 510 revamp their infrastructure in favor of single-vendor end-to- 511 end integrated solutions, preferring instead to reuse as much 512 of their deployed infrastructure as possible. The solution 513 proposed MUST enable such scenarios to be easily accommodated. 515 6.7. Fast MIPv4 Handoffs 517 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 518 January 2002 520 It is imperative to keep the key management overhead down to a 521 minimum, in order to support fast handoffs across IP subnets. 522 Hence, the solution MUST propose a mechanism whereby the IPsec 523 tunnel SA can be bound to the invariant home IP address of the 524 MN and applicable to static and dynamic home address 525 assignment. 527 6.8. Preservation of Existing VPN Infrastructure 529 This implies the following: 531 - The solution MUST preserve the investment in existing VPN 532 gateways 533 - The solution MAY require software upgrades to VPN gateways to 534 explicitly support MIPv4 users 536 - The solution MUST preserves VPN security requirements that 537 are not inferior to what is already provided to existing 538 "nomadic computing" remote access users, i.e. for 539 confidentiality, primary and secondary authentication, message 540 integrity, protection against replay attacks and related 541 security services. 543 6.9. Preserve Existing DMZ Traversal Policies 545 The solution MUST be compatible with existing DMZ policies with 546 respect to ACLs. 548 6.10 Support For Route Optimization 550 MIPv4 route optimization is not widely supported, as it 551 requires changes to both MN's home agent and the correspondent 552 node. Hence, The solution MAY or MAY NOT support MIPv4 Route 553 Optimization [ROUTE-OPT]. 555 6.11 MIPv4 Registration SA Management 557 Mechanisms to manage MIPv4 Registration SAs are outside the 558 scope of this draft. 560 6.12 Security Implications 562 The solution MUST NOT introduce any new vulnerabilities to the 563 MIPv4 protocol as specified in related RFCs. 565 7. References 567 [RFC3220] RFC 3220 ' IP mobility support for IPv4 568 [RFC3024] RFC 3024 ' Reverse tunneling for mobile IP 569 [RFC2004] RFC 2004 ' Minimal encapsulation within IP 570 [RFC1701] RFC 1701 ' Generic Routing encapsulation 572 Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 573 January 2002 575 [RFC2119] RFC 2119 - Key words for use in RFCs to Indicate 576 Requirement Levels 577 [RFC1918] RFC 1918 ' Address Allocation for Private Internets 578 [RFC2663] RFC 2663 - IP Network Address Translator (NAT) Terminology 579 and Considerations 580 [DHCP] RFC 2131 ' Dynamic Host Configuration Protocol 581 [MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt - 582 Requirements / Implementation Guidelines for Mobile IP using IP 583 Security 584 [[LOCAL-LINK] ' Dynamic Configuration of Iv4 Link-Local Addresses, 585 586 [ROUTE-OPT] ' Route Optimization in Mobile IP, 588 [MIP-NAT]' Mobile IP NAT/NAPT Traversal using UDP Tunneling, 589 591 Authors: 593 Farid Adrangi 594 Intel Corporation 595 2111 N.E. 25th Avenue 596 Hillsboro, OR 597 USA 599 Phone: 503-712-1791 600 Email: farid.adrangi@intel.com 602 Prakash Iyer 603 Intel Corporation 604 2111 N.E. 25th Avenue 605 Hillsboro, OR 606 USA 608 Phone: 503-264-1815 609 Email: prakash.iyer@intel.com