idnits 2.17.1 draft-teoyli-mobileip-mvpn-02.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances 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. ** 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 139: '... node MUST use a co-located care-of ...' RFC 2119 keyword, line 193: '... The realm agent MUST have a public IP...' RFC 2119 keyword, line 195: '... private network MUST be able to reach...' RFC 2119 keyword, line 196: '...ic IP address. The realm agent MUST be...' RFC 2119 keyword, line 262: '...ion messages. It MUST maintain mobilit...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 477 has weird spacing: '...ference cost ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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) == Unused Reference: '7' is defined on line 1067, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2344 (ref. '5') (Obsoleted by RFC 3024) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '11') Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. T. Teo 3 INTERNET DRAFT National University 4 of Singapore 5 Y. Li 6 Nortel Networks, Inc. 8 Mobile IP extension for Private Internets Support (MPN) 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo specifies enhancements to Mobile IP that allow IP mobility 33 support across routing realms. The protocol allows a mobile node to 34 have the same home network connectivity, regardless of its current 35 routing realm network point of attachment. It is designed to work in 36 the presence of address collisions and network address translations. 37 Private networks connected to the public Internet can extend IP 38 mobility support to cover the public Internet and other private 39 networks. Movement from a private home network to the public foreign 40 network, from a private home network to another private foreign 41 network or from the public home network to a private foreign network 42 are possible under the MPN framework. 44 1. Introduction 46 Mobile IP [1] allows a node to move from its home network, the IP 47 subnet indicated by its home address. When away from the home 48 network, datagrams destined to the node are tunnelled to a care-of 49 address in the visited network. This assumes a node's address is 50 sufficient to identify the node's location in the Internet and IP 51 unicast datagrams can be routed solely based on the destination 52 address in the datagram header. This is only true when the node's 53 mobility is constrained within a common routing realm. For example, 54 this routing realm could be the global public Internet or a localized 55 private network. 57 These assumptions are not valid beyond the mobile node's routing 58 realm. Therefore, Mobile IP cannot ensure mobility across different 59 routing realms. MPN is an extension to the Mobile IP base protocol 60 that enables this mobility support spanning multiple routing realms. 62 1.1 MPN Framework 64 Global Public Internet 65 . ________________ . 66 . +-----+ ( ) +-----+ . Private 67 . |Realm| ( VPN ) |Realm| . Network 68 .-|Agent|--( Tunnel /==)--|Agent|-. c 69 Private. +-----+ ( /======/ ) +-----+ .......... 70 Network. +-----+ / (______/_________) 71 A . |Realm| / | 72 .-|Agent|- | 73 . +-----+ +-----------+ 74 ......... |Realm Agent| 75 +-----------+ 76 | 77 ................... 78 .Private Network B. 79 . . 81 In MPN, the central routing realm is the global public Internet. All 82 other routing realms (private routing realms) depend on this global 83 routing infrastructure for wide area mobility. 85 Unlike the central routing realm which has numerous public networks, 86 each private network constitutes an independent routing realm. 87 Examples of private networks are intranets, extranets and virtual 88 private networks. 90 These private routing realms are globally identified in the public 91 Internet by their public agents. Realm agents are the private 92 networks link to the public Internet. For example, the public agent 93 may be a border router or an Internet service provider network point 94 of presence. 96 An independent private network (e.g. private network A) may have more 97 than one link to the public Internet, i.e. there are more than one 98 public agents. 100 A private routing realm may consists of multiple networks physically 101 located in separate sites. For example, private network B and private 102 network C may form a virtual private network. There will be a VPN 103 tunnel established between the two networks, to route traffic between 104 the two different physical sites. This VPN tunnel is transparent in 105 the MPN framework. For such network configurations, in the context of 106 MPN, the networks represent a single private routing realm. There is 107 no cross routing realm movement if a node moves to another physical 108 site within such a network. 110 All the realm agents in a private routing realm should be advertised 111 in the realm agents advertisement extension [ref Section 3.1]. In 112 MPN, realm agents provide the tunnel routing required by visiting 113 mobile nodes. The realm agents' addresses are also used in the 114 identification of routing realms. Mobile nodes from a private network 115 are configured with the realm agents' addresses in their routing 116 realm. These addresses are used to determine the mobile node's 117 current routing realm. 119 1.2 Addressing Concerns 121 IP addresses are topologically significant and unique only within a 122 routing realm. By enabling mobility across multiple routing realms, 123 there may be address collisions due to overlapping address space in 124 the visited routing realm. 126 MPN is designed to work in the presence address collisions and solve 127 the problem of tunneling across independent routing realms. However, 128 MPN is not intended to provide communication across routing realms 129 [ref Section 1.4]. The determination of the end host and the routing 130 mechanisms for end-to-end communication in the home routing realm is 131 independent of MPN. There are other protocols that provide 132 communication across routing realms such as NAT [6] and PAID [8]. 133 Their operation is transparent to MPN. 135 1.3 Mobile Node Concerns 137 When a mobile node enters a foreign routing realm and its visited 138 network link is broadcast-oriented (such as Ethernet), the mobile 139 node MUST use a co-located care-of address, instead of a local 140 foreign agent care-of address, for reverse GRE tunnels [ref Section 141 2.2]. This is to avoid address ambiguity on the broadcast link due to 142 home address collisions. 144 A private mobile node should use a co-located care-of address (if 145 possible) even when the foreign routing realm visited network link is 146 not broadcast-oriented. As the local foreign agent is not the forward 147 or reverse tunnel endpoint, end-to-end encryption can be supported. 149 1.4 Mobility Support 151 The mobility support in Mobile IP allows a mobile node to be always 152 identified by its home address, when it roams from its home network. 153 The mobile node's reachability by other nodes and its accessibility 154 to other nodes is not explicit in Mobile IP. This is because a common 155 routing fabric is assumed. 157 In MPN, mobility support is more accurately defined as maintaining 158 the same home network connectivity. The mobile node should have 159 access to all nodes that is reachable within its home network, even 160 when it migrates into another routing realm. Similarly, all nodes 161 that can reach the mobile node within its home network, should be 162 able to reach the mobile node when it moves to another routing realm 163 (if MPN mobility support is available in the visited network). 165 1.5 Design Goals 167 The design goals of MPN are: 169 1. The MPN protocol shall require minimum changes and support all 170 functions of the Mobile IP base protocol. 172 2. The MPN protocol must not affect the operation of Mobile IP mobile 173 nodes and mobility agents. 175 2. The MPN protocol shall be migratory. It will enable the upgrading 176 of a private network in phases while maintaining backward 177 compatibility with a basic MPN deployment. 179 1.6 Protocol Requirements 181 No protocol enhancements are required for realm agents in a basic MPN 182 deployment. However, there are security risks involved when 183 permitting unrestricted tunneling into a private network, for a basic 184 MPN deployment. The reverse tunneling is required in MPN to maintain 185 home network connectivity. 187 1.7 New Architectural Entity 188 Realm Agent 190 A router or firewall that connects a private network to the 191 global public Internet [ref Section 1.1]. A realm agent may be 192 located at the private network's border or at the private 193 network's ISP. The realm agent MUST have a public IP address, 194 which is reachable from the global public Internet. All nodes 195 within the private network MUST be able to reach the realm 196 agent using this public IP address. The realm agent MUST be 197 able to route to all local home agents and care-of addresses 198 within the private network. 200 1.8 Terminology 202 Unless otherwise specified, the document adopts all the terminology 203 defined in "IP Mobility Support" [1] [2]. 205 This document introduces the following terms: 207 Private Network 209 A network separated from the global public Internet with access 210 restrictions. A private network typically assigns nodes private 211 addresses specified in RFC 1918 [9] and the addresses may not 212 be routable by the general public Internet. For this document, 213 private networks only refer to private networks connected to 214 the global public Internet and not physically isolated 215 networks. 217 Private Mobile Node 219 A mobile node whose home network is in a Private Network. 221 Public Mobile Node 223 A mobile node whose home network is in the global public 224 Internet. 226 Routing Realm 228 The global public Internet and each private network constitute 229 individual routing realms [ref Section 1.1] This document 230 operates on the paradigm that interconnecting routing realms 231 may have overlapping address space but within a routing realm, 232 all IP addresses are unique and unicast datagrams are routable 233 solely based on the destination address in the datagram header. 235 Home Routing Realm 236 A routing realm which the mobile node's home network is 237 located. 239 Foreign Routing Realm 241 Any routing realm other than the mobile node's Home Routing 242 Realm. 244 Visited Routing Realm 246 A network other than the mobile node's Home Routing Realm, 247 which the mobile node is currently located. 249 Passive Realm Agent 251 A GRE [10] router. In a basic MPN deployment, a passive realm 252 agent route GRE tunnels (where IP is both the delivery and 253 payload protocol). A passive agent is not aware of nodes 254 movement and it need not process MPN registration messages or 255 maintain any mobility binding and security associations. This 256 enables the immediate deployment of realm agents since there 257 are no specific MPN protocol enhancements required. 259 Active Realm Agent 261 A GRE router. In addition, an active agent processes and relay 262 MPN registration messages. It MUST maintain mobility bindings 263 of successful registrations and may have security associations. 264 Security policies for visiting mobile nodes may be enforced for 265 the whole network at the active realm agent. An active realm 266 agent may provide routing optimizations and tunnel circuit 267 switching [ref Section 7]. 269 Home Realm Agent 271 A realm agent in the mobile node's Home Routing Realm. All 272 Private Mobile Nodes MUST be assigned one or more realm home 273 agents. A realm mobile node may be assigned a realm home agent 274 located at its home network domain. 276 Foreign Realm Agent 278 Any realm agent other than the mobile node's Home Realm Agent. 280 Mobility Binding 282 The association of a home address with a care-of address and 283 any intermediate tunnel destinations (realm home/foreign agent 284 address), along with the remaining lifetime of that 285 association. 287 Local Home Agent 289 A home agent in Mobile IP terminology. 291 Local Foreign Agent 293 A foreign agent in Mobile IP terminology. 295 Mobility Agent 297 Either a local home agent, local foreign agent or a realm 298 agent. 300 2. Tunneling 302 Tunneling is a means to alter the normal IP routing for datagrams, by 303 delivering them to intermediate destinations that would otherwise not 304 be selected by the (network part of the) IP destination address in 305 the original IP header. 307 2.1 Reverse tunneling 309 A bidirectional tunnel is established when a mobile node is in a 310 foreign routing realm. In order for the mobile node to have the same 311 level of network connectivity as it does when in its home network, 312 nodes that are reachable only when the mobile node is in the home 313 routing realm or home network, should be accessible in the visited 314 network. Packets destined to a node's address in another routing 315 realm will probably not be delivered using the existing routing 316 mechanism in the visited routing realm. A reverse tunnel [5] is used 317 to deliver datagrams originating from the mobile node back to the 318 home routing realm or home network. This will allow the datagrams to 319 be routed to the correct correspondent nodes in the presence of 320 address collisions and security restrictions. The reverse tunnel exit 321 point need not be the mobile node's local home agent. 323 2.2 GRE encapsulation 325 IP in IP encapsulation [3] is the default tunneling mechanism used in 326 Mobile IP. While it is useful for re-routing a datagram from one 327 point to another, the mechanism is unsuitable when multiple 328 transitional points are required, to traverse across different 329 routing realms. To achieve such functionality, the encapsulation 330 method must support source routing or the intermediate destinations 331 must be dynamically configured to forward the datagram to the next 332 correct tunneling point. 334 MPN uses Generic Routing Encapsulation [10] as the default 335 encapsulation method to tunnel across different routing realms. GRE 336 provides a Source Route Entry (SRE) in the tunnel header. Using a SRE 337 with an Address Family indicating an IP loose source route (Strict 338 Source Route flag cleared), the intermediate destinations can be 339 specified. 341 In the case of MPN, the SRE's IP address list will include any realm 342 agent along the tunnel route and the tunnel endpoint. Typically the 343 tunnel endpoint is the local home agent (for a reverse tunnel) or the 344 care-of address (for a forward tunnel). 346 2.3 Overall Encapsulated Packet 348 The diagram below provides an overview of the GRE tunnelled packet 349 layout. 351 +-------------------+ +------------------------ 352 | | | 353 | IP Delivery Header| -> | ... Protocol Type 47 354 | | | 355 +-------------------+ +------------------------ 356 | | | ... Protocol Type 0x800 357 | GRE Header | -> +------------------------ +------------- 358 | | | ... Source Route Entry -> | ... Address 359 | | | | Family 0x800 360 | | | | 361 +-------------------+ +------------------------ +------------- 362 | | | ... Original IP Header 363 | IP Payload | -> +------------------------ 364 | | | 365 --------------------+ +------------------------ 367 2.4 GRE SRE Processing 369 All the intermediate tunnel destinations (the realm agents) MUST 370 process the GRE header as specified in [10, 11]. The local home agent 371 and the mobile node MUST be able to perform GRE encapsulation and 372 decapsulation. 374 The diagram below illustrates forward GRE tunneling (from the local 375 home agent to the mobile node co-located care-of address) when the 376 mobile node moves from the private home routing realm into a private 377 visted routing realm with overlapping address space. The same route 378 but in reverse is typically taken by the reverse GRE tunnel. 380 Private Home Routing Realm 381 -------------------------- 382 private home network: 10.0.0.0/8 383 correspondent node address: 10.10.10.10 384 MN home address: 10.0.0.10 385 MN local home agent address: 10.0.0.1 386 MN realm home agent address: 192.32.174.44 388 Private Visited Routing Realm 389 ----------------------------- 390 private visited network: 10.0.0.0/16 391 advertised realm foreign agent address: 200.9.2.1 392 MN co-located care-of address: 10.0.20.20 394 S1 and D1 represent the original IP header's source and destination 395 addresses respectively. S2 and D2 represent the IP delivery header's 396 source and destination addresses respectively. 398 Global Public Internet 399 ________________ 400 ( ) 401 ( ) 402 ( ) 403 ( ) 404 (________________) 405 | | 406 {S2=192.32.174.44,^ | | |{S2=192.32.174.44, 407 D2=200.9.2.1} | | | | D2=200.9.2.1} 408 {S1=10.10.10.10,| | | |{S1=10.10.10.10 409 D1=10.0.0.10} | | | | D1=10.0.0.10} 410 | | | v 411 192.32.174.44 | | | 200.9.2.1 412 +------------------+ +---------------------+ 413 | Realm Home Agent | | Realm Foreign Agent | 414 +------------------+ +---------------------+ 415 | | 416 Private | Home Network Private | Visited Network 417 ------------------------------- ------------------------- 418 {S2=10.0.0.1, ^ | | |{S2=200.9.2.1, 419 D2=192.32.174.44}| | | | D2=10.0.20.20} 420 {S1=10.10.10.10,| | | |{S1=10.10.10.10, 421 D1=10.0.0.10} | +--+ +--+ v D1=10.0.0.10} 422 |--| |--| 423 /____ /____ 424 10.0.0.1 10.0.20.20 425 Local Home Agent Mobile Node 427 2.5 ICMP messages 428 The realm agents should handle ICMP messages from within the GRE 429 tunnel as specified in [3], including the maintenance of tunnel "soft 430 state". 432 3. MPN Agent Advertisement 434 Mobile IP's agent advertisements allow a mobile node to detect 435 movement across IP subnets. MPN includes a realm agent advertisement 436 extension to Mobile IP's agent advertisements. This allows a mobile 437 node to determine its current routing realm. 439 All MPN extension type values are selected from the range 128 to 255. 440 As specified in Mobile IP, values in this range can be silently 441 ignored by mobile nodes supporting only the Mobile IP based protocol. 443 3.1 Realm Agent Extension 445 This extension MUST be included in all local home agents' and local 446 foreign agents' agent advertisements. All realm agents that serve as 447 a realm home agent for any mobile node in the routing realm MUST be 448 included in the list of Realm Agent Entries. The presence of this 449 extension also indicates that the advertiser supports MPN. 451 The Realm Agent Advertisement Extension is defined as follows: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type | Length |P| Reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | zero or more Realm Agent Entries | 459 | ... | 461 Type 128 463 Length (2 + 8*N), where N is the number of realm agent entries. 465 P Public Network. The network is accessible from the global 466 public Internet (not a private network) 468 The Realm Agent Entry is defined as follows: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Preference |R|F|P|T| rsvd | Lifetime | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Realm Agent Address | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Preference cost indicator. 0 means the realm foreign agent is busy 478 and will not tunnel datagrams for additional mobile 479 nodes. 481 Lifetime The longest lifetime (measured in seconds) that this 482 realm foreign agent is willing to accept in any 483 registration request. A value of 0xffff indicates 484 infinity. 486 R Registration required. Registration with the realm 487 foreign agent is required. The realm foreign agent will 488 maintain the mobility binding of successful 489 registrations. If the 'R' bit is not set, the Lifetime 490 field is undefined and can be assumed to be infinite. If 491 the 'R' bit is set, the 'P' bit can be assumed to be set. 493 F Foreign Realm Agent. This realm agent offers service as a 494 foreign realm agent in this routing realm. 496 P Registration Proxy. This realm agent will relay the 497 registration message to the next mobility agent or mobile 498 node (registration reply). 500 T Tunnel Circuit Switching. This realm agent supports 501 tunnel circuit switching [ref Section 7]. 503 The Realm Agent Address MUST be a public IP address reachable from 504 the global public Internet. 506 A realm agent MUST always be prepared to serve the mobile nodes for 507 which it is the realm home agent. 509 The Realm Agent Advertisement Extension MUST be before the Mobility 510 Agent Advertisement Extension [1]. 512 3.2 Choosing a Realm Agent 514 Having only one realm agent for a routing realm will be a single 515 point of failure and possible bottleneck device. 517 The realm agent entries [refer Section 3.1] carry with each realm 518 agent address a preference identifier. To select a realm agent, one 519 has to rely on heuristics approaches. The easiest may be to always 520 choose the "preferred realm foreign agent" - the realm agent entry 521 with the maximum preference value or alternatively chose the realm 522 home/foreign agent randomly. This will spread the tunneled traffic on 523 different routes and introduce better load sharing and more 524 redundancy to the network. 526 3.3 Absent Agent Advertisment 528 Agent advertisements are needed to determine the current routing 529 realm. If there is no agent advertisement detected, a mobile node 530 should send agent solicitations, even when it acquires a co-located 531 care-of address. This is to determine if the mobile node is within 532 its home routing realm. 534 In the absence of agent advertisements, a mobile node should proceed 535 as if the current routing realm is the global public Internet. This 536 implies, a public mobile node should proceed as specified in Mobile 537 IP, and a private mobile node should proceed as specified in the 538 private home routing realm to public visited routing realm movement 539 scenario [ref Section 6.3]. 541 3.4 Movement Detection 543 To determine the current routing realm, a mobile node should check 544 the 'P' bit in the Realm Agent Advertisement Extension. 546 Public Mobile Node 547 ------------------ 548 If the 'P' bit is set, the mobile node is in its home routing realm 549 (the global public Internet) and it can proceed as specified in 550 Mobile IP. 552 If the 'P' bit is not set, the mobile node is in a private routing 553 realm and it should proceed as specified in the public home routing 554 realm to private visited routing realm movement scenario [ref Section 555 6.1] 557 Private Mobile Node 558 ------------------- 559 If the 'P' bit is set, the mobile node is in the global public 560 Internet and it should proceed as specified in the private home 561 routing realm to public visited routing realm movement scenario [ref 562 Section 6.3] 564 If the 'P' bit is not set, the mobile node MUST search all the Realm 565 Agent Entries. If one of the realm agent addresses advertised matches 566 the mobile node's assigned realm home agent address, it is in its 567 home routing realm and can proceed as specified in Mobile IP. If 568 there is no matching realm agent address, the mobile node is in a 569 private foreign routing realm and it should proceed as specified in 570 the private home routing realm to private foreign routing realm 571 movement scenario [ref Section 6.2] 573 Once the current routing realm is determined, the mobile node can 574 detect movement between IP subnets as specified in Mobile IP. 576 4. MPN Registration 578 Registration allows mobile nodes to communicate their current 579 reachability information to the mobility agents. The following 580 sections describes registration across routing realms. 582 There are two registration procedures. One via the mobility agents 583 that relay the registration to the mobile node's local home agent, 584 and another by tunneling the registration to the mobile node's local 585 home agent. By default, the registration messages are tunneled unless 586 all intermediate tunnel destinations (the realm agents) support 587 registration relay ('P' bit is set in the Realm Agent Entry [ref 588 Section 3.1]). 590 4.1 Realm Agent Registration Extension 592 All registration request and reply MUST include the Realm Agent 593 Registration extension. This extension MUST be before the Mobile-Home 594 Authentication extension. The extension is an explicit notification 595 of the source route (realm agents) that SHOULD be traversed between 596 the home routing realm and visited routing realms. 598 There may be additional routing realms crossed implicity but they are 599 transparent to MPN and no additional intermediate tunnel destinations 600 are specified i.e. not included in the Realm Agent Registration 601 extension. 603 The Realm Agent Registration extension is defined as follows: 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length |H|F|R|T| Reserved | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Realm Home Agent Address | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Realm Foreign Agent Address | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Type 128 617 Length 10 618 H Realm Home Agent Present 620 If the Realm Home Agent Present bit is set to 1, then the 621 realm home agent address field is valid and indicate an 622 intermediate tunnel destination requested. 624 F Realm Foreign Agent Present 626 If the Foreign Home Agent Present bit is set to 1, then the 627 realm home agent address field is valid and represent an 628 intermediate tunnel destination requested. 630 R Registration Relay. If the 'R' bit is set, the mobile node 631 or local home agent requests that the realm agents relay 632 the registration messages. 634 T Tunnel Circuit Switching. If the 'T' bit is set, the mobile 635 node requests that the mobility agents use tunnel circuit 636 switching [ref Section 7]. 638 4.2 Registration Considerations 640 Tunneling of Registration Messages 642 All mobility agents except the local foreign agent MUST be able to 643 process GRE tunneled packets. This enables the mobile node to reverse 644 tunnel the registration request to its local home agent and for the 645 local home agent to forward tunnel the registration reply in a basic 646 MPN deployment. 648 Registration Relay 650 A private mobile node MUST NOT request a realm foreign agent to relay 651 its registration request (set 'R' bit in Realm Agent Registration 652 extension) if its realm home agent does not support registration 653 relay. 655 Realm Foreign Agent 657 A realm foreign agent that requires registration ('R' bit is set in 658 the Realm Agent Entry) MUST tunnel the registration message to the 659 local home agent if the 'H' bit is set but the 'R' bit is not set in 660 the Realm Agent Registration extension, with the realm home agent as 661 the intermediate tunnel destination. 663 Local Foreign Agent 665 A local foreign agent that requires registration ('R' bit is set in 666 the Mobility Agent Extension) MUST process the Realm Agent 667 Registration Extension and relay the registration message to the next 668 mobility agent. 670 Local Home Agent 672 The local home agent MUST return the same realm agent registration 673 extension (in the registration request) for all registration replies. 675 5. Security Extensions 677 There can be security associations between realm agents and Mobile IP 678 mobility agents. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | SPI .... 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 ... SPI (cont.) | Authenticator ... 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Mobile-Realm Home Authentication Extension 690 Type 35 692 Mobile-Realm Foreign Authentication Extension 694 Type 36 696 Realm Foreign-Realm Home Authentication Extension 698 Type 37 700 6. Movement Scenarios 702 Only movement across routing realms need to be considered. Mobility 703 support within the home routing realm is provided by the Mobile IP 704 base protocol. Only the differences from Mobile IP is illustrated. 706 The movement detection algorithm is specified in Section 3.4 In all 707 the scenarios, the mobile node will typically establish a 708 bidirectional tunnel with its local home agent. 710 6.1 Public Home Routing Realm to Private Visited Routing Realm 712 A realm foreign agent 200.9.2.1 is selected from the realm agent 713 entries ('F' bit is set) advertised. 715 Registration Request 716 -------------------- 718 IP fields: 720 Source Address MN co-located care-of address 722 Destination Address MN local home agent address 724 Mobile IP fields: 726 The 'D' bit, 'G' bit and 'R' bit are set. 728 Realm Agent Registration extension fields: 730 The 'F' bit is set. 732 Realm Foreign Agent Address 200.9.2.1 734 If the realm foreign agent 200.9.2.1 supports registration relay, the 735 the mobile node's local home agent. 737 Registration Reply 738 ------------------ 740 Realm Agent Registration extension fields: 742 If the 'R' bit is not set, the registration message must be GRE 743 tunneled in the reverse direction. 745 Bidirectional Tunnel 746 -------------------- 748 On successful registration, a bidirectional GRE tunnel is established 749 between the mobile node and local home agent. 751 Mobile Node <--> Realm Foreign Agent <--> Local Home Agent 753 Routing Optimization 754 -------------------- 756 The realm foreign agent may be the reverse tunnel endpoint. This 757 should be determined by the mobile node. 759 6.2 Private Home Routing Realm to Private Visited Routing Realm 761 The scenario is similar to Section 6.1 except there is now a realm 762 home agent. Using the same example in Section 2.4: 764 Registration Request 765 -------------------- 767 The Realm Agent Registration fields: 769 The 'H' bit and 'F' bit are set. 771 Realm Foreign Agent Address 200.9.2.1 773 Realm Home Agent Address 192.32.174.44 775 If both the realm home agent and realm foreign agent support 776 registration relay, the 'R' bit set, else the registration message 777 must be GRE tunneled to the mobile's node local home agent. 779 Bidirectional Tunnel 780 -------------------- 782 On successful registration, a bidirectional GRE tunnel is established 783 between the mobile node and local home agent. 785 Mobile Node <--> Realm Foreign Agent <--> Realm Home Agent 786 ^ 787 | 788 Local Home Agent 790 Routing Optimization 791 -------------------- 793 The realm home agent may be the reverse tunnel endpoint. This should 794 be determined by the mobile node. 796 6.3 Private Home Routing Realm to Public Visited Routing Realm 798 The scenario is similar to Section 6.2 except there is now no realm 799 foreign agent. 801 Registration Request 802 -------------------- 804 IP fields: 806 Source Address MN co-located care-of address 808 Destination Address 192.32.174.44 810 Mobile IP fields: 812 The 'D' bit, 'G' bit and 'R' bit are set. 814 Realm Agent Registration extension fields: 816 The 'H' bit is set. 818 Realm Home Agent Address MN realm home agent 820 If the realm home agent supports registration relay, the 'R' bit is 821 set, else the registration message must be tunneled to the mobile 822 node's local home agent. 824 Bidirectional Tunnel 825 -------------------- 827 On successful registration, a bidirectional GRE tunnel is established 828 between the mobile node and local home agent. 830 Mobile Node <--> Realm Home Agent <--> Local Home Agent 832 Routing Optimization 833 -------------------- 835 The realm home agent may be the reverse tunnel endpoint. This should 836 be determined by the mobile node. 838 7. Tunnel Circuit Switching 840 This section describes an alternative encapsulation mechanism to 841 tunnel across multiple routing realms. Tunnel circuit switching is an 842 extension of Minimal Encapsulation for IP [4]. 844 In MPN, bidirectional tunneling is used to deliver datagrams between 845 the mobile node and its local home agent. In tunnel circuit 846 switching, the bidirection tunnel is a virtual routing circuit with 847 the mobile node and its local home agent as the circuit end points. 848 When the mobile node and its local home agent are in different 849 routing realms, the virtual circuit must be routed through realm 850 agent(s). 852 The diagram illustrates all the MPN entities in a virtual circuit 853 that crosses three separate routing realms - private home network to 854 global public internet to private visited network. 856 Mobile node with co-located care-of address 857 ------------------------------------------- 859 Mobile Node <--> Realm Foreign <--> Realm Home <--> Home Agent 860 Agent Agent 862 For the reverse tunnel, the mobile node encapsulates the original 863 datagram with the care-of address as the source address of the 864 modified IP header. 866 Mobile node with local foreign agent as care-of address 867 ------------------------------------------------------- 869 Mobile <--> Foreign <--> Realm Foreign <--> Realm Home <--> Home 870 Node Agent Agent Agent Agent 872 For the reverse tunnel, the mobile node encapsulates the original 873 datagram with the home address as the source address and the local 874 foreign agent or the realm foreign agent as the destination address 875 of the modified IP header. 877 For the forward tunnel, the local foreign agent or the mobile node 878 may be the tunnel endpoint. The local foreign agent MUST forward the 879 datagram with the mobile node's link layer address (learnt from the 880 mobile node registration request) as the destination link layer 881 address. 883 7.1 Conventional Datagram Tunneling 885 Typically, there are only two entities involved in tunneling - the 886 encapsulator and decapsulator - as the tunnel is established within a 887 common routing realm. There is generally no benefit to establishing a 888 virtual circuit since the tunnel header already stores both tunnel 889 endpoints addresses. 891 In MPN, to tunnel from the home agent to the care-of address and vice 892 versa, the IP addresses of each of the intermediate tunnel 893 destinations which routes the tunneled packet are required. 895 In the conventional approach, all these routing information are 896 recorded in the tunnel header. However, this information is 897 duplicated for every datagram tunneled. The additional information is 898 also only relevant to the realm agents. Establishing a tunnel circuit 899 can reduce this overhead. 901 7.2 Tunnel Identifier 903 Tunnel identifiers (TIDs) are assigned by realm agents. They are used 904 by MPN entities to correctly switch the tunnel circuits. The TIDs are 905 unique to a realm agent and have no relation to the TIDs assigned by 906 other realm agent. 908 IP fragmentation must not occur at a tunnel circuit switching point 909 as the TID is stored within the IP payload. The same requirement 910 applies to GRE tunnels. 912 The TID assigned must be authenticated to prevent modification during 913 tunnel circuit establishment. Since a Mobile-Home security 914 association MUST exist in Mobile IP, it can be used for the TID 915 authenticaton. 917 During the mobile node registration process, the realm agents 918 allocate their TIDs in the TID extension [ref to Section 7.3] of the 919 registration request. The TID extension MUST NOT be included in the 920 Mobile-Home Authentication extension. If the registration process is 921 successful, the home agent MUST include the TID extension in the 922 Mobile-Home Authentication extension of the registration reply. 924 The realm agents MUST verify that the TID in the TID extension of the 925 registration reply is the original value allocated. If the value is 926 changed, the realm agent MUST indicate a registration failure in the 927 code field of the registration reply. 929 7.3 Tunnel Identifier Extension 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Type | Length |H|F| Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Realm Home Agent TID | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Realm Foreign Agent TID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Type 129 943 Length 10 945 H Realm Home Agent TID Present 947 If the Realm Home Agent TID Present bit is set to 1, then 948 the realm home agent TID field is valid. 950 F Realm Foreign Agent TID Present 952 If the Foreign Home Agent TID Present bit is set to 1, then 953 the realm home agent TID field is valid. 955 7.4 Minimal Forwarding Header 957 The minimal forwarding header is inserted into a datagram as 958 specified by [4]. 960 The format of the extended minimal forwarding header is as follows: 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Protocol |S|T|R|D| rsv | Header Checksum | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Original Destination Address | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 : (if present) Original Source Address : 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 : (if present) Tunnel Identifier : 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 The new extensions are defined as follows: 976 T TID Bit 977 If set, the Tunnel Identifier field is present. 979 R Reverse Bit 980 If set, the packet is tunneled from the mobile node to its 981 local home agent (reverse tunneling). 983 D Decapsulation Bit 984 If set, the packet SHOULD be decapsulated and forwarded using 985 the existing routing mechanism. 987 7.5 Data Structures 989 A realm agent MUST associate the TID with the following information: 991 Index H R Next Hop IP Address Next Hop TID 992 ----- - - ------------------- ------------ 993 TID 0 0 Care-of Address Unchanged 994 0 1 Realm Home Agent Realm Home Agent TID 995 1 0 Realm Foreign Agent Realm Foreign Agent TID 996 1 1 Home Agent Unchanged 998 H If set, the realm agent is a Realm Home Agent. R If set, 999 the tunnel circuit is a reverse tunnel ('R' bit is set 1000 in the extended minimal forwarding header). 1002 A local home agent MUST associate the mobile node's home address with 1003 the TID assigned by the (forward tunnel) next hop realm agent in the 1004 registration request. 1006 A local foreign agent MUST associate the TID assigned by the (reverse 1007 tunnel) next hop realm agent in the registration reply with the 1008 mobile node's link layer address. 1010 8. Security Considerations 1012 GRE is a cleartext encapsulation mechanism and does not protect the 1013 data from eavesdroppers. The mobile node and its local home agent 1014 should establish an end-to-end bidirectional tunnel and encrypt it if 1015 privacy is a concern. 1017 Due to the current lack of trust for the Internet at large, a secure 1018 channel should be established from a private mobile node to its 1019 private home routing realm. Traffic between the private mobile node 1020 and its realm home agent's external interface should be encrypted. 1022 Firewall Filter Rules 1024 Access control at the realm agents into the private network should be 1025 provided as any node that gains access to it, can access the private 1026 network as well. 1028 Firewalls can deny mobile traffic on a per private routing realm 1029 basis or per public network basis. To control the visitor list on a 1030 per mobile node basis, the realm agents MUST be active realm agents. 1031 It is also possible to filter traffic based on the TID. 1033 Implementation Status 1035 A prototype implementation of MPN by W. T. Teo, one of the authors, 1036 is now undergoing testing. 1038 Acknowledgements 1040 Many thanks to Y. C. Tay at the National University of Singapore for 1041 supporting this joint work as well as for his valuable comments. 1043 This work was supported in part by National University of Singapore 1044 ARF grant RP960683. 1046 References 1048 [1] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1049 1996 1051 [2] C. Perkins. "IP Mobility Support Version 2", 1052 , November 1997 1054 [3] C. Perkins, "IP Encapsulation within IP", RFC 2003, May 1996 1056 [4] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, October 1057 1996 1059 [5] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1060 1998. 1062 [6] P. Srisuresh, K. Egevang, "Traditional IP Network Address 1063 Translator (Traditional NAT)", 1064 - work in progress, November 1065 1998 1067 [7] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 1068 Terminology and Considerations", 1069 - work in progress, October 1070 1998 1072 [8] Y. Li, W. T. Teo, "IP Private Address Identification", 1073 - work in progress, November 1074 1998 1076 [9] Rekhter, Y., Moskowitz, B. Karrenberg, D., G. de Groot, and 1077 Lear, E. "Address Allocation for Private Internets", RFC 1918, 1078 February 1996 1080 [10] S. Hanks, T. Li, D. Farinacci and P. Traina, "Generic Routing 1081 Encapsulation over IPv4 networks", RFC 1702, October 1994 1083 [11] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 1084 Encapsulation (GRE)", RFC 1701, October 1994 1086 Author's Address 1088 W. T. Teo 1089 School of Computing 1090 National University of Singapore 1091 Lower Kent Ridge Crescent 1092 SINGAPORE 119260 1094 E-mail: teoweetu@comp.nus.edu.sg 1095 Y. Li 1096 Nortel Networks 1097 BL60-304 1098 600 Technology Park Drive 1099 Billerica, MA 01821 1101 Phone: 1-978-916-1130 1102 Fax: 1-978-670-8760 1103 E-mail: yunli@NortelNetworks.COM