idnits 2.17.1 draft-teoyli-mobileip-mvpn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 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 142: '... node MUST used a co-located care-of...' RFC 2119 keyword, line 196: '...The public agent MUST have a public IP...' RFC 2119 keyword, line 198: '... private network MUST be able to reach...' RFC 2119 keyword, line 199: '...c IP address. The public agent MUST be...' RFC 2119 keyword, line 265: '...ion messages. It MUST maintain mobilit...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 480 has weird spacing: '...ference cost ...' == 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: During the mobile node registration process, the public agents allocate their TIDs in the TID extension of the registration request. The TID extension MUST not be included in the Mobile-Home Authentication extension. If the registration process is successful, the home agent MUST include the TID extension in the Mobile-Home Authentication extension in registration reply. == 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: '6' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1034, 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. '4') (Obsoleted by RFC 3024) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '10') Summary: 15 errors (**), 0 flaws (~~), 8 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 Bay Networks, Inc. 8 Mobile IP extension for Private Internets Support (MPN) 10 Status of This Memo 12 This document is a submission to the Mobile-IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@smallworks.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. 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 any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), 31 ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This memo specifies enhancements to Mobile IP that allow IP mobility 37 support across routing realms. The protocol allows a mobile node to 38 have the same home network connectivity, regardless of its current 39 routing realm network point of attachment. It is designed to work in 40 the presence of address collisions and network address translations. 41 Private networks connected to the public Internet can extend IP 42 mobility support to cover the public Internet and other private 43 networks. Movement from a private home network to the public foreign 44 network, from a private home network to another private foreign 45 network or from the public home network to a private foreign network 46 are possible under the MPN framework. 48 1. Introduction 50 Mobile IP [1] allows a node to move from its home network, the IP 51 subnet indicated by its home address. When away from the home 52 network, datagrams destined to the node are tunnelled to a care-of 53 address in the visited network. This assumes a node's address is 54 sufficient to identify the node's location in the Internet and IP 55 unicast datagrams can be routed solely based on the destination 56 address in the datagram header. This is only true when the node's 57 mobility is constrained within a common routing realm. For example, 58 this routing realm could be the global public Internet or a localized 59 private network. 61 These assumptions are not valid beyond the mobile node's routing 62 realm. Therefore, Mobile IP cannot ensure mobility across different 63 routing realms. MPN is an extension to the Mobile IP base protocol 64 that enables this mobility support spanning multiple routing realms. 66 1.1 MPN Framework 68 Global Public Internet 69 . ________________ . 70 . +------+ ( ) +------+ . Private 71 . |Public| ( VPN ) |Public| . Network 72 .-|Agent |--( Tunnel /==)--|Agent |-. c 73 Private. +------+ ( /======/ ) +------+ .......... 74 Network. +------+ / (______/_________) 75 A . |Public| / | 76 .-|Agent |- | 77 . +------+ +------------+ 78 ......... |Public Agent| 79 +------------+ 80 | 81 ................... 82 .Private Network B. 83 . . 85 In MPN, the central routing realm is the global public Internet. All 86 other routing realms (private routing realms) depend on this global 87 routing infrastructure for wide area mobility. 89 Unlike the central routing realm which has numerous public networks, 90 each private network constitutes an independent routing realm. 91 Examples of private networks are intranets, extranets and virtual 92 private networks. 94 These private routing realms are globally identified in the public 95 Internet by their public agents. Public agents are the private 96 networks link to the public Internet. For example, the public agent 97 may be a border router or a Internet service provider network point 98 of presence. 100 An independent private network (e.g. private network A) may have more 101 than one link to the public Internet, i.e. there are more than one 102 public agents. 104 A private routing realm may consists of multiple networks physically 105 located in separate sites. For example, private network B and private 106 network C may form a virtual private network. There will be a VPN 107 tunnel established between the two networks, to route traffic between 108 the two different physical sites. This VPN tunnel is transparent in 109 the MPN framework. For such network configurations, in the context of 110 MPN, the networks represent a single private routing realm. There is 111 no cross routing realm movement if a node moves to another physical 112 site within such a network. 114 All the public agents in a private routing realm should be advertised 115 in the public agents advertisement extension [ref Section 3.1]. In 116 MPN, public agents provide the tunnel routing required by visiting 117 mobile nodes. The public agents' addresses are also used in movement 118 detection. Mobile nodes from a private network are configured with 119 the public agents' addresses in their routing realm. These addresses 120 are used to determine the mobile node's current routing realm. 122 1.2 Addressing Concerns 124 IP addresses are topologically significant and unique only within a 125 routing realm. By enabling mobility across multiple routing realms, 126 there may be address collisions due to overlapping address space in 127 the visited routing realm. 129 MPN is designed to work in the presence address collisions and solve 130 the problem of tunneling across independent routing realms. However, 131 MPN is not intended to provide communication across routing realms. 132 The determination of the end host and the routing mechanisms for end- 133 to-end communication in the home routing realm is independent of MPN. 134 There are other protocols that provide communication across routing 135 realms such as NAT [5] and PAID [7]. Their operation is transparent 136 to MPN. 138 1.3 Mobile Node Concerns 140 When a mobile node enters a foreign routing realm and its visited 141 network link is broadcast-orientated (such as Ethernet), the mobile 142 node MUST used a co-located care-of address, instead of a local 143 foreign agent care-of address. This is to avoid address ambiguity on 144 the broadcast link due to home address collisions. 146 A private mobile node should use a co-located care-of address (if 147 possible) even when the foreign routing realm visited network link is 148 not broadcast-orientated. As the local foreign agent is not the 149 forward or reverse tunnel endpoint, end-to-end encryption can be 150 supported. 152 1.4 Mobility Support 154 The mobility support in Mobile IP allows a mobile node to be always 155 identified by its home address, when it roams from its home network. 156 The mobile node's reachability by other nodes and its accessibility 157 to other nodes is not explicit in Mobile IP. This is because a common 158 routing fabric is assumed. 160 In MPN, mobility support is more accurately defined as maintaining 161 the same home network connectivity. The mobile node should have 162 access to all nodes that is reachable within its home network, even 163 when it migrates into another routing realm. Similarly, all nodes 164 that can reach the mobile node within its home network, should be 165 able to reach the mobile node when it moves to another routing realm 166 (if MPN mobility support is available in the visited network). 168 1.5 Design Goals 170 The design goals of MPN are: 172 1. The MPN protocol shall require minimum changes and support all 173 functions of the Mobile IP base protocol. 175 2. The MPN protocol must not affect the operation of Mobile IP 176 mobile nodes and mobility agents. 178 2. The MPN protocol shall be migratory. It will enable the upgrading 179 of a private network in phases while maintaining backward 180 compatibility with a basic MPN deployment. 182 1.6 Protocol Requirements 184 No protocol enhancements are required for public agents in a basic 185 MPN deployment. However, there are security risks involved when 186 permitting unrestricted tunneling into a private network, for a basic 187 MPN deployment. The reverse tunneling is required in MPN to maintain 188 home network connectivity. 190 1.7 New Architectural Entity 191 Public Agent 193 A router or firewall that connects a private network to the 194 global public Internet [ref Section 1.1]. A public agent may be 195 located at the private network's border or at the private 196 network's ISP. The public agent MUST have a public IP address, 197 which is reachable from the global public Internet. All nodes 198 within the private network MUST be able to reach the public 199 agent using this public IP address. The public agent MUST be 200 able to route to all local home agents and care-of addresses 201 within the private network. 203 1.8 Terminology 205 Unless otherwise specified, the document adopts all the terminology 206 defined in "IP Mobility Support" [1] [2]. 208 This document introduces the following terms: 210 Private Network 212 A network separated from the global public Internet with access 213 restrictions. A private network typically assigns nodes private 214 addresses specified in RFC 1918 [8] and the addresses may not 215 be routable by the general public Internet. For this document, 216 private networks only refer to private networks connected to 217 the global public Internet and not physically isolated 218 networks. 220 Private Mobile Node 222 A mobile node whose home network is in a Private Network. 224 Public Mobile Node 226 A mobile node whose home network is in the global public 227 Internet. 229 Routing Realm 231 The global public Internet and each private network constitute 232 individual routing realms [ref Section 1.1] This document 233 operates on the paradigm that interconnecting routing realms 234 may have overlapping address space but within a routing realm, 235 all IP addresses are unique and unicast datagrams are routable 236 solely based on the destination address in the datagram header. 238 Home Routing Realm 239 A routing realm which the mobile node's home network is 240 located. 242 Foreign Routing Realm 244 Any routing realm other than the mobile node's Home Routing 245 Realm. 247 Visited Routing Realm 249 A network other than a mobile node's Home Routing Realm, to 250 which the mobile node is currently located. 252 Passive Public Agent 254 A GRE [9] router. In a basic MPN deployment, a passive public 255 agent route GRE tunnels (where IP is both the delivery and 256 payload protocol). There is no MPN protocol ehancements 257 required. A passive agent is not aware of nodes movement and it 258 need not process MPN registration messages or maintain any 259 mobility binding and security associations. This enables the 260 immediate deployment of public agents. 262 Active Public Agent 264 A GRE router. In addition, an active agent processes and relay 265 MPN registration messages. It MUST maintain mobility bindings 266 of successful registrations and may have security associations. 267 Security policies for visiting mobile nodes may be enforced for 268 the whole network at the active public agent. A active public 269 agent may provide routing optimizations and tunnel circuit 270 switching [ref Section 7]. 272 Home Public Agent 274 A public agent in the mobile node's Home Routing Realm. All 275 Private Mobile Nodes MUST be assigned one or more public home 276 agents. A public mobile node may be assigned a public home 277 agent located at its home network domain. 279 Foreign Public Agent 281 Any public agent other than the mobile node's Home Public 282 Agent. 284 Mobility Binding 286 The association of a home address with a care-of address and 287 any intermediate tunnel destinations (public home/foreign agent 288 address), along with the remaining lifetime of that 289 association. 291 Local Home Agent 293 A home agent in Mobile IP terminology. 295 Local Foreign Agent 297 A foreign agent in Mobile IP terminology. 299 Mobility Agent 301 Either a local home agent, local foreign agent or a public 302 agent. 304 2. Tunneling 306 Tunneling is a means to alter the normal IP routing for datagrams, by 307 delivering them to intermediate destinations that would otherwise not 308 be selected by the (network part of the) IP destination address in 309 the original IP header. 311 2.1 Reverse tunneling 313 A bidirectional tunnel is established when a mobile node is in a 314 foreign routing realm. In order for the mobile node to have the same 315 level of network connectivity as it does when in its home network, 316 nodes that are reachable only when the mobile node is in the home 317 routing realm or home network, should be accessible in the visited 318 network. Packets destined to a node's address in another routing 319 realm will probably not be delivered using the existing routing 320 mechanism in the visited routing realm. A reverse tunnel [4] is used 321 to deliver datagrams originating from the mobile node back to the 322 home routing realm or home network. This will allow the datagrams to 323 be routed to the correct correspondent nodes in the presence of 324 address collisions and security restrictions. The reverse tunnel exit 325 point need not be the mobile node's local home agent. 327 2.2 GRE encapsulation 329 IP in IP encapsulation [3] is the default tunneling mechanism used in 330 Mobile IP. While it is useful for re-routing a datagram from one 331 point to another, the mechanism is unsuitable when multiple 332 transitional points are required, to traverse across different 333 routing realms. To achieve such functionality, the encapsulation 334 method must support source routing or the intermediate destinations 335 must be dynamically configured to forward the datagram to the next 336 correct tunneling point. 338 MPN uses Generic Routing Encapsulation [9] as the default 339 encapsulation method to tunnel across different routing realms. GRE 340 provides a Source Route Entry (SRE) in the tunnel header. Using a SRE 341 with an Address Family indicating an IP loose source route (Strict 342 Source Route flag cleared), the intermediate destinations can be 343 specified. 345 In the case of MPN, the SRE's IP address list will include any public 346 agent along the tunnel route and the tunnel endpoint. Typically the 347 tunnel endpoint is the local home agent (for a reverse tunnel) or the 348 care-of address (for a forward tunnel). 350 2.3 Overall Encapsulated Packet 352 The diagram below provides an overview of the GRE tunnelled packet 353 layout. 355 +-------------------+ +------------------------ 356 | | | 357 | IP Delivery Header| -> | ... Protocol Type 47 358 | | | 359 +-------------------+ +------------------------ 360 | | | ... Protocol Type 0x800 361 | GRE Header | -> +------------------------ +------------- 362 | | | ... Source Route Entry -> | ... Address 363 | | | | Family 0x800 364 | | | | 365 +-------------------+ +------------------------ +------------- 366 | | | ... Original IP Header 367 | IP Payload | -> +------------------------ 368 | | | 369 --------------------+ +------------------------ 371 2.4 GRE SRE Processing 373 All the intermediate tunnel destinations (the public agents) MUST 374 process the GRE header as specified in [8]. The local home agent and 375 the mobile node MUST be able to perform GRE encapsulation and 376 decapsulation. 378 The diagram below illustrates forward GRE tunneling (from the local 379 home agent to the mobile node co-located care-of address) when the 380 mobile node moves from the private home routing realm into a private 381 visted routing realm. The same route but in reverse is typically 382 taken by the reverse GRE tunnel. 384 Private Home Routing Realm 385 -------------------------- 386 private home network: 10.0.0.0/8 387 correspondent node address: 10.10.10.10 388 MN home address: 10.0.0.10 389 MN local home agent address: 10.0.0.1 390 MN public home agent address: 192.32.174.44 392 Private Visited Routing Realm 393 ----------------------------- 394 private visited network: 10.0.0.0/8 395 advertised public foreign agent address: 200.9.2.1 396 MN co-located care-of address: 10.20.20.20 398 S1 and D1 represent the original IP header's source and destination 399 addresses respectively. S2 and D2 represent the IP delivery header's 400 source and destination addresses respectively. 402 Global Public Internet 403 ________________ 404 ( ) 405 ( ) 406 ( ) 407 ( ) 408 (________________) 409 | | 410 {S2=192.32.174.44,^ | | |{S2=192.32.174.44, 411 D2=200.9.2.1} | | | | D2=200.9.2.1} 412 {S1=10.10.10.10,| | | |{S1=10.10.10.10 413 D1=10.0.0.10} | | | v D1=10.0.0.10} 414 +------------------+ +----------------------+ 415 | Public Home Agent| | Public Foreign Agent | 416 +------------------+ +----------------------+ 417 | | 418 Private | Home Network Private | Visited Network 419 ------------------------------- ------------------------- 420 {S2=10.10.10.1, ^ | | |{S2=200.9.2.1, 421 D2=192.32.174.44}| | | | D2=10.20.20.20} 422 {S1=10.10.10.10,| | | |{S1=10.10.10.10, 423 D1=10.0.0.10} | +--+ +--+ v D1=10.0.0.10} 424 |--| |--| 425 /____\ /____\ 426 10.10.10.1 10.20.20.20 427 Local Home Agent Mobile Node 429 2.5 ICMP messages 430 The public agents should handle ICMP messages from within the GRE 431 tunnel as specified in [3], including the maintenance of tunnel "soft 432 state". 434 3. MPN Agent Advertisement 436 Mobile IP's agent advertisements allow a mobile node to detect 437 movement across IP subnets. MPN includes a public agent advertisement 438 extension to Mobile IP's agent advertisements. This allows a mobile 439 node to determine its current routing realm. 441 All MPN extension type values are selected from the range 128 to 255. 442 As specified in Mobile IP, values in this range can be silently 443 ignored by mobile nodes supporting only the Mobile IP based protocol. 445 3.1 Public Agent Extension 447 This extension MUST be included in all local home agents' and local 448 foreign agents' agent advertisements. All public agents that serve as 449 a public home agent for any mobile node in the routing realm MUST be 450 included in the list of Public Agent Entries. The presence of this 451 extension also indicates that the advertiser supports MPN. 453 The Public Agent Advertisement Extension is defined as follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length |P| Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | zero or more Public Agent Entries | 461 | ... | 463 Type 128 465 Length (2 + 8*N), where N is the number of public agent entries. 467 P Public Network. The network is accessible from the global 468 public Internet (not a private network) 470 The Public Agent Entry is defined as follows: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Preference |R|F|P|T| rsvd | Lifetime | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Public Agent Address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Preference cost indicator. 0 means the public foreign agent is busy 481 and will not tunnel datagrams for additional mobile 482 nodes. 484 Lifetime The longest lifetime (measured in seconds) that this 485 public foreign agent is willing to accept in any 486 registration request. A value of 0xffff indicates 487 infinity. 489 R Registration required. Registration with the public 490 foreign agent is required. The public foreign agent will 491 maintain the mobility binding of successful 492 registrations. If the 'R' bit is not set, the Lifetime 493 field is undefine and can be assumed to be infinite. If 494 the 'R' bit is set, the 'P' bit can be assumed to be set. 496 F Foreign Public Agent. This public agent offers service as 497 a foreign public agent in this routing realm. 499 P Registration Proxy. This public agent will relay the 500 registration message to the next mobility agent or mobile 501 node (registration reply). 503 T Tunnel Circuit Switching. This public agent supports 504 tunnel circuit switching [ref Section 7]. 506 The Public Agent Address MUST be a public IP address reachable from 507 the global public Internet. 509 A public agent MUST always be prepared to serve the mobile nodes for 510 which it is the public home agent. 512 The Public Agent Advertisement Extension MUST be before the Mobility 513 Agent Advertisement Extension. 515 3.2 Choosing a Public Agent 517 Having only one public agent for a routing realm will be a single 518 point of failure and possible bottleneck device. 520 The public agent entries [refer Section 3.1] carry with each public 521 agent address a preference identifier. To select a public agent, one 522 has to rely on heuristics approaches. The easiest may be to always 523 choose the "preferred public foreign agent" - the public agent entry 524 with the maximum preference value or alternatively chose the public 525 home/foreign agent randomly. This will spread the tunneled traffic on 526 different routes and introduce better load sharing and more 527 redundancy to the network. 529 3.3 Absent Agent Advertisment 531 Agent advertisements are needed to determine the current routing 532 realm. If there is no agent advertisement detected, a mobile node 533 should send agent solicitations, even when it acquires a co-located 534 care-of address. This is to determine if the mobile node is within 535 its home routing realm. 537 In the absence of agent advertisements, a mobile node should proceed 538 as if the current routing realm is the global public Internet. This 539 implies, a public mobile node should proceed as specified in Mobile 540 IP, and a private mobile node should proceed as specified in the 541 private home routing realm to public visited routing realm movement 542 scenario [ref Section 6.3]. 544 3.4 Movement Detection 546 To determine the current routing realm, a mobile node should check 547 the 'P' bit in the Public Agent Advertisement Extension. 549 Public Mobile Node 550 ------------------ 551 If the 'P' bit is set, the mobile node is in its home routing realm 552 and it can proceed as specified in Mobile IP. 554 If the 'P' bit is not set, the mobile node is in a private routing 555 realm and it should proceed as specified in the public home routing 556 realm to private visited routing realm movement scenario [ref Section 557 6.1] 559 Private Mobile Node 560 ------------------- 561 If the 'P' bit is set, the mobile node is in the global public 562 Internet and it should proceed as specified in the private home 563 routing realm to public visited routing realm movement scenario [ref 564 Section 6.3] 566 If the 'P' bit is not set, the mobile node MUST search all the Public 567 Agent Entries. If one of the public agent addresses advertised 568 matches the mobile node's assigned public home agent address, it is 569 in its home routing realm and can proceed as specified in Mobile IP. 570 If there is no matching public agent address, the mobile node is in a 571 private foreign routing realm and it should proceed as specified in 572 the private home routing realm to private foreign routing realm 573 movement scenario [ref Section 6.2] 574 Once the current routing realm is determined, the mobile node can 575 detect movement between IP subnets as specified in Mobile IP. 577 4. MPN Registration 579 Registration allows mobile nodes to communicate their current 580 reachability information to the mobility agents. The following 581 sections describes registration across routing realms. 583 There are two registration procedures. One via the mobility agents 584 that relays the registration to the mobile node's local home agent, 585 and one by tunneling the registration to the mobile node's local home 586 agent. By default, the registration messages are tunneled unless all 587 intermediate tunnel destinations (the public agents) support 588 registration relay ('P' bit is set in the Public Agent Entry [ref 589 Section 3.1]). 591 4.1 Public Agent Registration Extension 593 All registration request and reply MUST include the Public Agent 594 Registration extension. This extension MUST be before the Mobile-Home 595 Authentication extension. The extension is an explicit notification 596 of the source route (public agents) that SHOULD be traversed between 597 the home routing realm and visited routing realms. 599 There may be additional routing realms crossed implicity but they are 600 transparent to MPN and no additional intermediate tunnel destinations 601 are specified i.e. not included in the Public Agent Registration 602 extension. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length |H|F|R|T| Reserved | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Public Home Agent Address | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Public Foreign Agent Address | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Type 128 616 Length 10 618 H Public Home Agent Present 620 If the Public Home Agent Present bit is set to 1, then the 621 public home agent address field is valid and indicate an 622 intermediate tunnel destination requested. 624 F Public Foreign Agent Present 626 If the Foreign Home Agent Present bit is set to 1, then the 627 public 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 public agents relays 632 the registration messages. 634 T Tunnel Circuit Switching. If the 'T' bit is set, the mobile 635 node requests that the mobility agents uses tunnel circuit 636 switching. 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 public foreign agent to 651 relay its registration request (set 'R' bit in Public Agent 652 Registration extension) if its public home agent does not support 653 registration relay. 655 Public Foreign Agent 657 A public foreign agent that requires registration ('R' bit is set in 658 the Public 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 Public Agent Registration extension, with the public home agent 661 as 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 Public 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 public agent registration 673 extension (in the registration request) for all registration replies. 675 5. Security Extensions 677 There can be security associations between public agents and Mobile 678 IP 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-Public Home Authentication Extension 690 Type 35 692 Mobile-Public Foreign Authentication Extension 694 Type 36 696 Public Foreign-Public 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 public foreign agent 10.0.0.1 is selected from the public agent 713 entries ('F' bit is set) advertised. 715 Registration Request 716 -------------------- 717 IP fields: 719 Source Address MN co-located care-of address 721 Destination Address 10.0.0.1 723 Mobile IP fields: 725 The 'D' bit, 'G' bit and 'R' bit is set. 727 Public Agent Registration extension fields: 729 The 'F' bit is set. 731 Public Foreign Agent Address 10.0.0.1 733 If the public foreign agent 10.0.0.1 supports registration relay, the 734 mobile node's local home agent. 736 Registration Reply 737 ------------------ 739 Public Agent Registration extension fields: 741 If the 'R' bit is not set, the registration message must be tunneled 742 in the reverse direction. 744 Bidirectional Tunnel 745 -------------------- 747 On successful registration, a bidirectional GRE tunnel is established 748 between the mobile node and local home agent. 750 Mobile Node <--> Public Foreign Agent <--> Local Home Agent 752 Routing Optimization 753 -------------------- 755 The public foreign agent may be the reverse tunnel endpoint. This 756 should be determined by the mobile node. 758 6.2 Private Home Routing Realm to Private Visited Routing Realm 760 The scenario is similar to Section 6.1 except there is now a public 761 home agent. 763 Registration Request 764 -------------------- 765 The Public Agent Registration fields: 767 The 'H' bit and 'F' bit is set. 769 Public Foreign Agent Address 10.0.0.1 771 Public Home Agent Address MN public home agent 773 If both the public home agent and public foreign agent supports 774 registration relay, the 'R' bit set, else the registration message 775 must be tunneled to the mobile's node local home agent. 777 Bidirectional Tunnel 778 -------------------- 780 On successful registration, a bidirectional GRE tunnel is established 781 between the mobile node and local home agent. 783 Mobile Node <--> Public Foreign Agent <--> Public Home Agent 784 ^ 785 | 786 | 787 Local Home Agent 789 Routing Optimization 790 -------------------- 792 The public home agent may be the reverse tunnel endpoint. This should 793 be determined by the mobile node. 795 ,ti 0 6.3 Private Home Routing Realm to Public Visited Routing Realm 797 The scenario is similar to Section 6.2 except there is now no public 798 foreign agent. 800 Registration Request 801 -------------------- 803 IP fields: 805 Source Address MN co-located care-of address 807 Destination Address MN public home agent 809 Mobile IP fields: 811 The 'D' bit, 'G' bit and 'R' bit is set. 813 Public Agent Registration extension fields: 815 The 'H' bit is set. 817 Public Home Agent Address MN public home agent 819 If the public home agent supports registration relay, the 'R' bit is 820 set, else the registration message must be tunneled to the mobile 821 node's local home agent. 823 Bidirectional Tunnel 824 -------------------- 826 On successful registration, a bidirectional GRE tunnel is established 827 between the mobile node and local home agent. 829 Mobile Node <--> Public Home Agent <--> Local Home Agent 831 Routing Optimization 832 -------------------- 834 The public home agent may be the reverse tunnel endpoint. This should 835 be determined by the mobile node. 837 7. Tunnel Circuit Switching 839 This section describes an alternative encapsulation mechanism to 840 tunnel across multiple routing realms. 842 In MPN, bidirectional tunneling is used to deliver datagrams between 843 the mobile node and its local home agent. In tunnel circuit 844 switching, the bidirection tunnel is a virtual routing circuit with 845 the mobile node's co-located care-of address and its local home agent 846 as the circuit end points. When the mobile node and its local home 847 agent are in different routing realms, the virtual circuit must be 848 routed through public agent(s). 850 The diagram illustrates all the MPN entities in a virtual circuit 851 that crosses three separate routing realms - private home network to 852 global public internet to private visited network. 854 Mobile Node <--> Public Foreign <--> Public Home <--> Home Agent 855 Agent Agent 857 7.1 Conventional Datagram Tunneling 859 Typically, there are only two entities involved in tunneling - the 860 encapsulator and decapsulator - as the tunnel is established within a 861 common routing realm. There is generally no benefit to establishing a 862 virtual circuit since the tunnel header already stores both tunnel 863 endpoints addresses. 865 In MPN, to tunnel from the home agent to the care-of address and vice 866 versa, the IP addresses of each of the intermediate tunnel 867 destinations which routes the tunneled packet are required. 869 In the conventional approach, all these routing information are 870 recorded in the tunnel header. However, this information is 871 duplicated for every datagram tunneled. The additional information is 872 also only relevant to the public agents. Establishing a tunnel 873 circuit can reduce this overhead. 875 7.2 Tunnel Identifier 877 Tunnel identifiers (TIDs) are assigned by public agents. They are 878 used by MPN entities to correctly switch the tunnel circuits. The 879 TIDs are unique to a public agent and have no relation to the TIDs 880 assigned by other public agent. 882 IP fragmentation must not occur in a tunnel circuit switching point 883 as the TID is stored within the IP payload. Note the same requirement 884 applies to GRE tunnels. 886 The TID assigned must be authenticated to prevent modification during 887 tunnel circuit establishment. Since a Mobile-Home security 888 association MUST exist in Mobile IP, it is used for the TID 889 authenticaton. 891 During the mobile node registration process, the public agents 892 allocate their TIDs in the TID extension of the registration request. 893 The TID extension MUST not be included in the Mobile-Home 894 Authentication extension. If the registration process is successful, 895 the home agent MUST include the TID extension in the Mobile-Home 896 Authentication extension in registration reply. 898 The public agents MUST verify that the TID in the TID extension of 899 the registration reply is the original value allocated. If the value 900 is changed, the public agent MUST indicate a registration failure in 901 the code field of the registration reply. 903 7.3 Tunnel Identifier Extension 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type | Length |H|F| Reserved | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Public Home Agent TID | Public Foreign Agent TID | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Type 129 915 Length 6 917 H Public Home Agent TID Present 919 If the Public Home Agent TID Present bit is set to 1, then 920 the public home agent TID field is valid. 922 F Public Foreign Agent TID Present 924 If the Foreign Home Agent TID Present bit is set to 1, then 925 the public home agent TID field is valid. 927 7.4 Tunnel Circuit Packet 929 The tunnel circuit IP header protocol type field is 56. A circuit 930 label is inserted between the tunnel circuit IP header and the 931 encapsulated payload. 933 Circuit Label 935 0 1 2 936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 |R|D| Reserved | TID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 R Reverse Bit 942 If set, the packet is tunneled from the mobile node to its 943 local home agent (reverse tunneling). 945 D Decapsulation Bit 946 If set, the packet should be decapsulated and forwarded using 947 the existing routing mechanism. 949 7.5 Data Structures 951 A public agent MUST associate the TID with the following information. 953 Index H R Next Hop IP Address Next Hop TID 954 ----- - - ------------------- ------------ 955 TID 0 0 Care-of Address Unchanged 956 0 1 Home Public Agent Home Public Agent TID 957 1 0 Foreign Public Agent Foreign Public Agent TID 958 1 1 Home Agent Unchanged 960 H If set, the public agent is a Public Home Agent. 961 R If set, the tunnel circuit is a reverse tunnel ('R' bit is set 962 in the circuit label) 964 8. Security Considerations 966 GRE is a cleartext encapsulation mechanism and does not protect the 967 data from eavesdroppers. The mobile node and its local home agent 968 should establish an end-to-end bidirectional tunnel and encrypt it if 969 privacy is a concern. 971 Due to the current lack of trust for the Internet at large, a secure 972 channel should be established from a private mobile node to its 973 private home routing realm. Traffic between the private mobile node 974 and its public home agent's external interface should be encrypted. 976 Firewall Filter Rules 978 Access control at the public agents into the private network should 979 be provided as any node that gains access to it, can access the 980 private network as well. 982 Firewalls can deny mobile traffic on a per private routing realm 983 basis or per public network basis. To control the visitor list on a 984 per mobile node basis, the public agents MUST be active public 985 agents. It is also possible to filter traffic based on the TID. 987 Implementation Status 989 A prototype implementation of MPN by W. T. Teo, one of the authors, 990 is now undergoing testing. 992 Acknowledgements 994 Many thanks to Dr. Y. C. Tay at the National University of Singapore 995 for supporting this joint work as well as for his valuable comments. 997 This work was supported in part by National University of Singapore 998 ARF grant RP960683. 1000 References 1002 [1] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1003 1996 1005 [2] C. Perkins. "IP Mobility Support Version 2", 1006 , November 1997 1008 [3] C. Perkins, "IP Encapsulation within IP", RFC 2003, May 1996 1010 [4] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1011 1998. 1013 [5] P. Srisuresh, K. Egevang, "Traditional IP Network Address 1014 Translator (Traditional NAT)", 1015 - work in progress, November 1016 1998 1018 [6] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 1019 Terminology and Considerations", 1020 - work in progress, October 1021 1998 1023 [7] Y. Li, W. T. Teo, "IP Private Address Identification", 1024 - work in progress, November 1025 1998 1027 [8] Rekhter, Y., Moskowitz, B. Karrenberg, D., G. de Groot, and 1028 Lear, E. "Address Allocation for Private Internets", RFC 1918, 1029 February 1996 1031 [9] S. Hanks, T. Li, D. Farinacci and P. Traina, "Generic Routing 1032 Encapsulation over IPv4 networks", RFC 1702, October 1994 1034 [10] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 1035 Encapsulation (GRE)", RFC 1701, October 1994 1037 Author's Address 1039 W. T. Teo Department of ISCS National University of Singapore Lower 1040 Kent Ridge Crescent SINGAPORE 119260 1042 E-mail: teoweetu@comp.nus.edu.sg 1044 Y. Li Bay Networks, Inc. BL60-304 600 Technology Park Drive 1045 Billerica, MA 01821 1047 Phone: 1-978-916-1130 Fax: 1-978-670-8760 E-mail: 1048 yli@BayNetworks.COM