idnits 2.17.1 draft-ietf-mobileip-privaddr-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 125: '...A) has a private address, then it MUST...' RFC 2119 keyword, line 126: '...ss of a SHA, and MUST cause the tunnel...' RFC 2119 keyword, line 180: '... such agents MAY reside in a separat...' RFC 2119 keyword, line 197: '... to the mobile node, the FA MUST check...' RFC 2119 keyword, line 199: '...address. The FA MAY require that the ...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) == Outdated reference: A later version (-01) exists of draft-ietf-mobileip-calhoun-tep-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-01 ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '5') == Outdated reference: A later version (-01) exists of draft-montenegro-aatn-nar-00 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2002 (ref. '8') (Obsoleted by RFC 3220) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT G. Montenegro 3 25 June 1999 Pat R. Calhoun 4 Sun Laboratories 6 Private Addresses in Mobile IP 7 draft-ietf-mobileip-privaddr-00.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 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 Abstract 35 The use of possibly non-unique private addresses (i.e., addresses 36 that are not globally routable in the internet) for mobile nodes, 37 foreign agents, or home agents is not handled by RFC 2002. This 38 document specifies changes to enable Mobile IP to handle such 39 addresses. 41 1. Introduction 43 Full-scale deployment of Mobile IP would benefit from an ability to 44 provide mobility across differing address spaces, sometimes called 45 "realms", especially because corporate networks often use private 46 address spaces. A solution is needed to handle such addresses 47 consistently with regionalized registrations and firewall traversal. 48 The mechanisms proposed in this note aim to solve this problem. 50 We use use the following model: 52 +---------------------------+ +----------------+ 53 | Foreign Private Network | | Home Private | 54 | | +---------+ | Network | 55 | | | | | | 56 | +------+ +-------+ | | Public | | +------+ | 57 | | FA |------| GFA |-------------------------| SHA | | 58 | +--+---+ +-------+ | | Network | | +--+---+ | 59 | | | | | | | | 60 +-----|---------------------+ +---------+ | +--+---+ | 61 | | | HA | | 62 +--+---+ | +------+ | 63 | MN | | | 64 +------+ +----------------+ 66 Figure 1: Mobility with Private Networks 68 A Home Agent using a private address cannot be the destination of 69 any packets transmitted by a foreign agent in a different addressing 70 domain. Thus, such a home agent has to rely on the presence of a 71 Surrogate Home Agent (a SHA). Furthermore, every mobile node on the 72 Home Network served by such a home agent will also have a private 73 address. 75 This means that Registration Requests for the mobile node have to 76 be sent to the SHA. Then, the SHA has to know how to forward such 77 requests to the home agent. 79 In this document, the GHAA (Global Home Agent Address) is defined to 80 be either the HA, if the HA has a globally routable IP address, or 81 else the SHA, if the HA does not have a globally routable IP address. 83 Mobile IP has two distinct phases: 85 1. tunnel setup via a UDP-based (registration) protocol, and 86 2. data transfer via tunneled packets. 88 2. Data Transfer 90 Let's examine first the data transfer phase. Given that only systems 91 within the same address space have direct reachability, the packets 92 do not travel along an end-to-end tunnel. Instead, the tunnel from 93 HA to FA is a compound tunnel, used as in a previous proposal, Tunnel 94 Establishment Protocol (TEP) [2]. 96 The segments of the tunnel are always within any given address space. 97 If the home agent has a private address, there are 3 tunnel segments: 99 HA->SHA, SHA->GFA, and GFA->FA 101 Otherwise, if the home agent has a globally routable IP address, only 102 two tunnel segments are necessary: 104 HA->GFA and GFA->FA 106 It is also possible that additional tunnel segments will be needed 107 between the GFA and the FA, but setting up such additional tunnel 108 segments is outside the scope of this document. 110 The order and endpoints of the compounds tunnels are reversed when 111 packets flow in the reverse direction. Data transfer, then, proceeds 112 from the correspondent node to the home agent through the SHA along 113 to the FA in the manner to be described next. In this section, MN 114 refers to a particular mobile node which needs to receive data at a 115 particular care-of address, which may itself be a private address 116 from a separate address space than the one from which MN's IP address 117 is allocated. 119 In sections 2.3 through 2.5, the IP node sending the packet the GFA 120 is designated as the GHAA, as defined in section 1. 122 2.1. From HA to SHA 124 Say a correspondent node CN (not shown in figure 1) sends a packet 125 to MN. If the home agent (HA) has a private address, then it MUST 126 know the address of a SHA, and MUST cause the tunneled data packet to 127 the MN's care-of address to seem to originate from the SHA. The HA 128 first encapsulates the packet with an IP header that indicates that 129 origination. Then, the HA encapsulates it and sends it towards SHA 130 as illustrated in figure 2. 132 +-------------------------------+ 133 | +--------------------+| 134 | | +--------+|| 135 | HA->SHA | SHA->GFA | CN->MN ||| 136 | | +--------+|| 137 | +--------------------+| 138 +-------------------------------+ 140 Figure 2: IP-in-IP tunneled packet from HA to SHA 142 2.2. From SHA to GFA 144 +--------------------+ 145 | +--------+| 146 | SHA->GFA | CN->MN || 147 | +--------+| 148 +--------------------+ 150 Figure 3: IP-in-IP tunneled packet from SHA to GFA 152 Once the packet reaches SHA, the packet is decapsulated, exposing the 153 still encapsulated packet with SHA as the source IP address. The 154 packet from SHA to GFA is illustrated in figure 3. 156 2.3. From GFA to FA 158 When GFA decapsulates the packet, it looks for a binding for MN, 159 the inner destination. Following the discussion in [6], MN's IP 160 address does not necessarily uniquely identify the mobile node. 161 The reason is that the GFA may have another binding in place for a 162 mobile node from another private address space that is using the 163 same IP address as MN. The GFA has to identify the correct visitor 164 list entry based on a tuple (i.e., an ordered set of information) 165 which is guaranteed to be unique. One such tuple sufficient for 166 demultiplexing IP-within-IP packets [7] (protocol 4) is (MN,GHAA), 167 where: 169 - MN is the destination IP address of the innermost header, and 171 - GHAA is the source IP address of the encapsulating header. 173 The destination IP address of the innermost header is the mobile 174 node's home address. The source IP address of the encapsulating 175 header is GHAA. The ordered pair (MN,GHAA) is presumed unique among 176 all of GFA's Mobile IP clients. 178 GFA requires (MN,GHAA) to fetch the next tunnel endpoint, FA. This 179 tuple continues to be required for any foreign agent beyond GFA, as 180 such agents MAY reside in a separate address space from MN's home 181 address. Accordingly, GFA encapsulates again so that GHAA will still 182 be visible in the intermediate header. The packet that arrives at FA 183 is illustrated in figure 4. 185 +--------------------------------+ 186 | +---------------------+| 187 | | +--------+|| 188 | GFA->FA | GHAA->GFA | CN->MN ||| 189 | | +--------+|| 190 | +---------------------+| 191 +--------------------------------+ 193 Figure 4: IP-in-IP tunneled packet from GFA to FA 195 2.4. From FA to MN 197 Before delivering the packet to the mobile node, the FA MUST check 198 that the outer source IP address (GFA) matches the intermediate 199 destination IP address. The FA MAY require that the same GFA always 200 be associated with the MN, by storing this information in its routing 201 table. Note that a routing loop would result from indiscriminately 202 forwarding the decapsulated packet after the outer (GFA->FA) header 203 was removed, because the GFA would keep doing the same thing to the 204 packet. RFC 2002 includes language to prohibit this indiscriminate 205 forwarding, and the mobility agents handling private addresses 206 require at least as much care as RFC 2002 mobility agents when 207 dealing with encapsulation. 209 Like the GFA, the FA searches based on (MN,GHAA). Once the FA 210 identifies the ultimate destination of the packet, MN, it delivers 211 the packet using link-level mechanisms. 213 2.5. Using GRE tunnels 215 GRE packets with a Routing field are outside the scope of this 216 document. GRE packets [4, 5] (protocol 47) without a Key field 217 are only handled if their Protocol Type field has a value of 0x800 218 (other values are outside the scope of this document), and can be 219 demultiplexed based on the same tuple (MN,GHAA) as IP-within-IP 220 packets. GRE packets with a Key field could be demultiplexed 221 based on that field used as a tunnel identifier [2] negotiated at 222 registration time. 224 Question: how is the tunnel identifier negotiated? 226 In this case, by absorbing the cost of negotiating the tunnel 227 identifier and setting up the necessary routing for the GRE header, 228 extra encapsulation steps can be avoided by providing a single GRE 229 header, as illustrated in figure 5. 231 +---------------------+ 232 | +--------+| 233 | GHAA->GFA | CN->MN || 234 | tunnelID +--------+| 235 +---------------------+ 237 Figure 5: GRE tunneled packet from GFA to FA 239 3. Tunnel Establishment 241 Even if the HA cannot address FA directly, the HA has to send 242 tunneled packets so that they eventually arrive at the FA so that the 243 FA can deliver them to the mobile node. These packets are delivered 244 via GHAA and GFA. Configuring this tunnel is initiated by the Mobile 245 IP Registration Request message, as defined in [8]. 247 If mobile node MN is registering with home agent HA, the GFA should 248 be used as the care-of address, because the GHAA sends packets to MN 249 via GFA. 251 The mobility agents FA and GFA create the mapping (MN,GHAA) for each 252 mobile node. This information is available from the registration 253 messages. If the mobile node has acquired a co-located address, 254 any foreign agent issuing agent advertisements MUST use the 'R' bit 255 to force the mobile node's Registration Request to go through it. 256 If a mobile node using a co-located address is not receiving any 257 advertisements, then one of two things must be true: 259 - the co-located care-of address is globally routable, or 261 - the mobile node discovers the GFA; the protocol for this 262 discovery operation is not specified within this document. 264 3.1. Privately Addressed Mobile Nodes 266 Foreign agents that comply with Mobile IP as specified in RFC 2002 267 are not required to handle mobile nodes with private IP addresses. 268 Doing so requires additional mechanism, because it is possible for 269 two mobile nodes to show up with the same identical private IP 270 address. Fortunately, at least delivery from the foreign agent's 271 network interface to the mobile node will still be possible, based 272 on the MAC address of the mobile node. However, once the Foreign 273 Agent has decapsulated the packets it receives for the mobile node(s) 274 with a duplicated private IP address, it cannot determine which 275 mobile node should receive the packet based only the value of the 276 destination IP address (MN) in the inner IP header, 278 In order to handle private addresses, a Foreign Agent MUST be able 279 to identify its visitor list entry for the mobile node by using 280 (MN,GHAA) as defined in section 2.3. Pending Registration Requests 281 using private addresses MUST be able to be identified by using the 282 the Identification field along with either: 284 - the NAI [1] supplied by the mobile node, or 286 - (MN,GHAA) 288 A new `P' bit is defined, from the currently reserved field of the 289 Agent Advertisement defined in RFC 2002 [8], for use by Foreign 290 Agents that have the mechanisms specified herein. If the mobile node 291 has a private address, then it SHOULD send registration requests 292 only to a foreign agent that has advertised the ability to handle 293 private addresses by setting the `P' bit. If the mobile node has a 294 private address, then it SHOULD include the NAI extension [3] in its 295 Registration Request. 297 When a Registration Reply is determined to match a request from a 298 Mobile Node (MN) with a private address, the foreign agent MUST 299 associate GHAA with its (new) visitor list entry for MN. 301 DISCUSSION: 303 cep: I am not surewe should tie together the NAI with the 304 use of private addresses in this way. And, I think that the 305 FA has to advertise its willingness to handle such nasty, 306 unfriendly things such as private addresses. 308 cep: We could make the home agent append a Private Address 309 extension to the Registration Reply, in the range 128-255. 310 That would avoid making the mobile nodes have to be smart, 311 and it would avoid requiring the foreign agents make the 312 more difficult routing determination for mobile nodes with 313 unique IP addresses. 315 3.2. Privately Addressed Home Agents 317 Suppose the home agent has a private address. Then, the home agent 318 MUST perform the encapsulation steps specified in section 2.1. The 319 mobile node MUST be able to discover the address of its SHA. This 320 discovery MAY occur in one of the following ways: 322 1. The home agent can advertise an SHA's address in advertisements 323 received by the mobile node when the mobile node is at home. 324 This document does not specify any method by which a home agent 325 can advertise a SHA. 327 2. The SHA can be returned in the Home Agent field of the 328 Registration Reply, when the mobile node asks for dynamic 329 allocation of a Home Agent. 331 3. The mobile node can be statically configured to contain the 332 address of a SHA, at the same time that it is configured with a 333 security association with a home agent or with a home AAA server. 335 3.3. Foreign Agents with Private Addresses 337 A foreign agent with a private address SHOULD NOT advertise its 338 care-of address within its agent advertisements (beacons), because 339 the beacons are assumed to offer connectivity for mobile nodes that 340 may belong in a different addressing domain. Instead, it SHOULD 341 advertise a care-of address that is reachable by the GHAA. This 342 globally reachable care-of address is associated with a distinguished 343 foreign agent known as the Gateway Foreign Agent (GFA). 345 DISCUSSION: 346 The FA could use one of three methods to indicate to the mobile node 347 the necessary information about the foreign domain/GFA: 349 - can advertise FA@domain 351 - can advertise GFA 352 - can reject registration and send GFA 354 If the foreign agent advertises a care-of address which is not 355 associated with one of its own network interfaces, the mobile 356 node must be given some other method to detect when it moves to 357 a different foreign agent. A foreign agent advertising a GFA as 358 its care-of address SHOULD use the FA-NAI extension, specified in 359 section 4. 361 In order to advertise the GFA as a care-of address, the foreign agent 362 has to find find out what it is. This MAY be done by any of the 363 following methods: 365 1. The GFA can list its care-of address in advertisements received 366 by the foreign agent. 368 2. The GFA can be returned in the Care-of Address field of the 369 Registration Reply. This requires that the care-of address be 370 made known to the home agent, in order for the Registration Reply 371 to be properly authenticated. 373 3. The foreign agent can be statically configured to contain the 374 care-of address of a GFA. 376 [gab - does an MN need to know the GFA?. maybe not. just 377 issue the request with care-of address 0 and have the FA 378 figure it out via AAA or whatever, precisely as outlined in 379 the next section.] 381 This document does not (yet) specify any method by which the home 382 agent may obtain the GFA's globally routable care-of address. 384 3.4. Alternative GFAs 386 If a foreign agent has access to multiple GFAs, the appropriate GFA 387 for a particular mobile node MAY may be selected depending upon the 388 NAI given by the mobile node, or the home agent address given by the 389 mobile node. In this case, the foreign agent MAY advertise a care-of 390 address of zero, and include the FA-NAI extension specified in 391 section 4. When the mobile node first attempts to make a connection 392 in a particular foreign domain, it is typically unaware of any nearby 393 care-of address. When the foreign agent advertises a zero care-of 394 address, the care-of address that the mobile node uses during its 395 initial registration MUST be zero. Before the Registration Request 396 reaches the home domain, the care-of address (say, of a GFA), MUST 397 be inserted by an agent (call it AAAX) trusted and authenticated by 398 the home domain, or an associate in the foreign domain trusted and 399 verified by AAAX. The home agent, then, includes that care-of address 400 in the Registration Reply, for subsequent use by the mobile node. 402 DISCUSSION: 404 This should perhaps go into a separate document. It could 405 depend on AAA. We need to define error numbers for the 406 following cases: 408 - nonzero COA at private FA 410 - zero COA at GHAA 412 3.5. Protocol between SHA and HA 414 In this section we assume that the home agent has a private address, 415 and thus that every packet tunneled to the mobile node has the IP 416 address of the SHA as the source IP address in the tunnel header. 418 If a SHA receives a Registration Request, and it is not the home 419 agent for the initiating mobile node, the SHA has to have an entry 420 for the mobile node and a record of the associated home agent in its 421 home list. This record can be created in the following ways: 423 1. Manual configuration 425 2. The SHA can receive a Registration Request from a AAA agent in 426 the home domain (call it AAAH) during the initial registration 427 sequence for the mobile node in the foreign domain. In this 428 case, the AAAH will send the address of the appropriate home 429 agent along with the Registration Request. 431 When the home agent receives a data packet for delivery to the mobile 432 node, the home agent MUST first deliver this packet to the SHA. It 433 does this by iterated encapsulation: 435 1. Encapsulate using the care-of address as the tunnel destination 436 and the SHA as the tunnel source address, and then 438 2. Encapsulate using the SHA as the tunnel destination and the home 439 agent's private address as the tunnel source address 441 When the SHA receives this tunneled packet, it only has to remove the 442 outermost IP header from the packet and forward the (still at least 443 singly encapsulated) result to the care-of address. 445 4. Foreign Agent NAI 447 The Foreign Agent NAI Extension to the Agent Advertisement contains 448 the foreign agent's host name following the format defined in [1]. 449 The NAI is used to identify the foreign agent and can be used by 450 a mobile node to determine whether or not it has moved out of the 451 domain in which its previous foreign agent was configured to provide 452 mobility service. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | FA NAI ... 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 6: The FA NAI Extension 462 Type TDB 464 Length The length in bytes of the FA NAI field 466 FA NAI Contains the foreign agent's NAI in the format defined 467 in [1]. 469 5. Security Considerations 471 Since private addresses are typically administered to prevent access 472 to networks inside an enterprise, privately addressed mobile nodes 473 with Mobile IP must be handled with great care to avoid break-ins. 474 For instance, the mobile node should probably not offer any IP 475 forwarding services while registered at an external care-of address. 476 It is difficult to imagine how forwarding traffic between the foreign 477 and home domain could be logically consistent with the raison d'etre 478 for the private address space in the home domain. 480 The SHA and GFA offer access mechanisms into a private address space. 481 Packets sent to the SHA or GFA for further handling may, therefore, 482 require authentication and possibly encryption to maintain the 483 existing security policy which originally dictated the choice of 484 using a private address space within the enterprise. 486 6. IPv6 Considerations 488 It is hoped that IPv6 will not offer any such private addresses as 489 have been brought about by perceived unavailabilty of enough IPv4 490 addresses. 492 References 494 [1] B. Aboba and M. Beadles. RFC 2486: The network access 495 identifier, January 1999. Status: PROPOSED STANDARD. 497 [2] P. Calhoun and C. Perkins. Tunnel Establishment Protocol (TEP). 498 draft-ietf-mobileip-calhoun-tep-00.txt, December 1997. (work in 499 progress). 501 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 502 Address Identifier Extension. draft-ietf-mobileip-mn-nai-01.txt, 503 February 1999. (work in progress). 505 [4] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 506 Routing Encapsulation (GRE). RFC 1701, October 1994. 508 [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 509 Routing Encapsulation over IPv4 networks. RFC 1702, October 510 1994. 512 [6] G. Montenegro. Negotiated Address Reuse (NAR). 513 draft-montenegro-aatn-nar-00.txt, May 1998. (work in 514 progress). 516 [7] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 517 1996. 519 [8] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 520 1996. 522 Addresses 524 The working group can be contacted via the current chairs: 526 Erik Nordmark Basavaraj Patil 527 Sun Microsystems, Inc. Nortel Networks Inc. 528 17 Network Circle 2201 Lakeside Blvd. 529 Menlo Park, California 94025 Richardson, TX. 75082-4399 530 USA USA 532 Phone: +1 650 786-5166 +1 972-684-1489 533 Fax: +1 650 786-5896 534 E-mail: nordmark@sun.com bpatil@nortelnetworks.com 536 Questions about this memo can be directed to: 538 Charles E. Perkins Pat R. Calhoun 539 Sun Microsystems Laboratories Sun Microsystems Laboratories 540 15 Network Circle 15 Network Circle 541 Menlo Park, California 94025 Menlo Park, California 94025 542 USA USA 544 Phone: +1-650 786-6464 Phone: +1 650-786-7733 545 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com 546 Fax: +1 650 786-6445 548 Gabriel Montenegro 549 Sun Microsystems Laboratories 550 15 Network Circle 551 Menlo Park, California 94025 552 USA 554 Phone: +1-650-786-6288 555 EMail: gab@eng.sun.com