idnits 2.17.1 draft-teoyli-mobileip-mvpn-00.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-04-25) 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. ** 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 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 432: '...PAID agent address. It MUST be public....' RFC 2119 keyword, line 483: '...y message, this bit SHOULD be set to 0...' RFC 2119 keyword, line 508: '... supporting MVPN MUST always include t...' RFC 2119 keyword, line 520: '... MUST include a mobile PAID extensio...' RFC 2119 keyword, line 521: '.... This extension MUST contain the priv...' (52 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 'SHOULD not' in this paragraph: When the mobile node receives a Registration Reply, it SHOULD not verify the presence of the private extension since the home agent probably does not support MVPN. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 March 1998) is 9552 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '6' on line 730 looks like a reference -- Missing reference section? '9' on line 738 looks like a reference -- Missing reference section? '4' on line 724 looks like a reference -- Missing reference section? '8' on line 735 looks like a reference -- Missing reference section? '1' on line 715 looks like a reference -- Missing reference section? '7' on line 733 looks like a reference -- Missing reference section? '3' on line 721 looks like a reference -- Missing reference section? '5' on line 727 looks like a reference -- Missing reference section? '2' on line 718 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force W. T. Teo 2 INTERNET DRAFT National Univ. of Singapore 3 Y. Li 4 Bay Networks, Inc. 5 1 March 1998 7 Mobile IP extension for Private Internets Support (MVPN) 8 draft-teoyli-mobileip-mvpn-00.txt 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 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This memo describes a scheme to enable the mobile node to move from 37 public to private domains or between private domains while it still 38 maintains internet connectivity. This extended mobility support does 39 not require that the private host have access to the global Internet. 40 This memo takes advantage of the PAID agent, a domain border agent, 41 specified in the private address identification (PAID) procotol. To 42 register a mobility binding, we introduce a mobile extension in the 43 regional registration messages with the PAID agent, and a private 44 extension to the global registration messages with the home agent. 46 1. Introduction 48 1.1 Problem 50 Mobile IP base protocol [6] provides an efficient, scalable mechanism 51 for node mobility within the public Internet. However, it does not 52 support movement between private domains and between private domain 53 and public domain. 55 Private internets are defined in [9]. They differ from the existing 56 public internet in terms of address allocation. Private internets are 57 generally used to number hosts within an enterprise, organization or 58 a community. These hosts are not meant to be accessed from public 59 internet hosts outside the private internets. The problem arises when 60 a private host providing services to other clients in the private 61 networks moves to another private or public site. 63 Besides, the uniqueness of private IP address for each host cannot 64 be assumed. Since routers generally deliver datagrams based on their 65 destination IP address, the mechanism provided by the Mobile IP will 66 not work at all between different private internet communities. 68 1.2 MVPN 70 The protocol (MVPN) specified in this memo attempts to extend the 71 Mobile IP support to private internets, that is, to enable mobility 72 between private domains and from public to private domains. 74 The private address identification protocol (PAID) [4] proposes an 75 approach which facilitates the private extension of the mobility 76 support. It proposes to bind each private address, by regional 77 registration, to a public address of another node (called PAID agent 78 or domain border agent) and thus provides an unique identification of 79 a private host. This protocol also invents a PAID Encapsulation 80 mechanism. This approach enables the global communication between 81 private domains. 83 Taking advantage of the PAID agent, the MVPN introduces a private 84 extension to the global Registration Request and Registration Reply 85 messages as specified in the Mobile IP base protocol [6]. These 86 messages will then be forwarded between the mobile node and the home 87 agent by way of a foreign PAID agent and/or a home PAID agent. 89 The idea of regional registration was introduced by Perkins [8]. It 90 was meant to reduce the frequency of distant registrations with the 91 home agent. We extend this idea to the private domains. When a mobile 92 node moves to a private domain, it has to first register its private 93 care-of address with the public PAID agent. To perform this regional 94 registration, MVPN introduces a mobile PAID extension to the PAID 95 registration messages as specified in the PAID protocol [4]. 97 1.3. Applicability 99 MVPN is intended to enable nodes to move from a public domain to a 100 private domain, or to move between private domains. MVPN does not 101 support movement from a private domain to a public one. 103 With the support of MVPN, both the mobile node and the home agent can 104 be public or private nodes. The foreign agent can be a public node 105 only if the mobile node is in the same domain as the foreign agent or 106 both the mobile node and the home agent are public nodes. In a 107 private domain, MVPN does not require the foreign agent for 108 registration, but the mobile node still uses the Agent Advertisement 109 messages from the foreign agent to detect movement, from one subnet 110 to another or from a domain to another. 112 Although the corresponding node may not be able to access the private 113 domain which the mobile node is visiting, as long as it is able to 114 communicate with the mobile node's home network, the corresponding 115 node will be able to communicate with the mobile node with help of 116 the home agent, the home PAID agent, and the foreign PAID agent. 118 MVPN is compatible with the PAID protocol [4]. When the Internet 119 supports PAID partly or completely, the MVPN will even enable the 120 mobile node to move from a private domain to a public one. 122 1.4. Terminology and Definitions 124 Identification of Private Address (PAID) 126 The identification of a private address is a 127 address pair. It is defined in [4]. We also call it as the binary 128 identification of the private address. 130 PAID Agent 132 A PAID agent is a node that provides private nodes with the public 133 portion of the binary identification. It is defined in [4]. 135 Home PAID Agent 137 This is a PAID agent of the mobile node's home agent when the home 138 agent is private. It supports MVPN in the mobile node's home 139 domain. It does not process Registrtion Request and Registration 140 Reply messages but it forwards these messages. The home PAID agent 141 tunnels packets, including the registration messages, between the 142 home agent and the foreign PAID agent or the foreign agent. 144 Foreign PAID Agent 146 This is a PAID agent of the mobile node's care-of address. It 147 supports MVPN in the mobile node's foreign domain. It processes 148 Registrtion Request and Registration Reply messages. It tunnels 149 packets between the home agent/the home PAID agent and the foreign 150 agent/the mobile node. 152 Mobile Node 154 The mobile node in MVPN is the same as that defined as in the 155 Mobile IP base protocol, except that the mobile node address can 156 be a public address, private address, or a 157 address pair. 159 Home Agent 161 The home agent in MVPN is the same as that defined as in the 162 Mobile IP base protocol. Home agent address can be private or 163 public. 165 Foreign Agent 167 The foreign agent in MVPN is the same as that defined as in the 168 Mobile IP base protocol. Foreign agent address can be private or 169 public. 171 In MVPN, the foreign agent is less important since the mobile node 172 can obtain co-located care-of address by DHCP [1]. 174 Care-of Address 176 The care-of address in MVPN is the same as that defined as in the 177 Mobile IP base protocol. It can be private or public. We refer as 178 private care-of address to the care-of address of the mobile node 179 when the care-of address is private. 181 Public Care-of Address 183 The public care-of address of the mobile node is referred to a 184 public address of the foreign PAID agent. 186 Mobility Binding 188 Similar to that in the Mobile IP base protocol, the mobility 189 binding in MVPN is the association of the binary identification 190 of the mobile node home address, the binary identification of the 191 care-of address, along with the lifetime of the association. 193 2. Protocol Overview 195 When a home agent in MVPN moves to another private domain, it will 196 identify the mobile node's location by the binary identification of 197 the mobile node's care-of address, that is, the address pair . On the other hand, the mobile node will 199 identify the home agent by the binary identification of the home 200 agent, that is, the address pair . 203 2.1 Obtaining Care-of Address 205 The mobile node, when moving to a private network in another domain, 206 may attempt to obtain a private co-located care-of address by using 207 DHCP [1]. Since there are plenty of private addresses in each 208 enterprise network, using co-located care-of addresses is not 209 expensive. 211 2.2 Discovery of Foreign PAID Agent 213 After obtaining a care-of address, the mobile node may attempt to 214 register a binary identification with a foreign PAID agent. 216 The mobile node may discover the foreign PAID agent by the PAID agent 217 discovery protocol in [4]. Alternatively, a foreign agent may include 218 a PAID agent extension in the Agent Advertisement message, and thus 219 the mobile node is able to learn the PAID agent from the foreign 220 agent. 222 2.3 Regional Registration 224 The mobile node may register a binary identification with a foraign 225 PAID agent through exchange of a pair of PAID Registration Request 226 and Reply messages as specified in the PAID registration protocol 227 (see [4]). 229 To additionally regionally register a mobility binding with the 230 foreign PAID agent, the mobile node should include a Mobile PAID 231 Extension in the PAID Registration Request message. The foreign PAID 232 agent should associates the mobility binding regionally with itself 233 and include the Mobile PAID Extension in the reply. 235 This way the mobile node may not necessarily originate a home 236 registration as in section 2.4 unless it moves to another domain. 237 This is because the mobile node can be served by the same foreign 238 PAID agent while moving inside the domain. 240 2.4 Home Registration 242 Using the binary identification of its care-of address, the mobile 243 node may register a mobility binding with its home agent, by 244 exchange of a pair of Registration Request and Reply messages, via 245 the foreign PAID agent and the home PAID agent. To register such a 246 mobility binding, both the request and the reply should contain a 247 Private Extension. 249 The private extension contains private mobile node address, and/or 250 private home agent address, and/or private care-of address. The 251 foreign agent, foreign PAID agent, or home agent will determine if 252 the Registration Request and reply messages supports MVPN by checking 253 the presence of the private extension. 255 2.5 Transit Registration 257 The mobile node may register a mobility binding with other foreign 258 PAID agents in domains it visited previously. These foreign PAID 259 agents will then redirect mobile traffic to the location where the 260 mobile node is currently visiting. Transit registration can be 261 performed in the same way as the home registration. 263 2.6 Movement Detection 265 The mobile node will take advantage of Agent Advertisement messages 266 to detect movement. In order to detect the movement from one domain 267 to another, both the home agent and foreign agent should advertise 268 all PAID agents in the domain as well as care-of addresses. 270 A mobile node should detect a change in location when it receives an 271 Agent Advertisement with a different set of care-of address. In 272 contrast, when the mobile node learns the message has a different set 273 of PAID agent addresses, it should be considered to have moved into 274 another domain. 276 2.7 Datagram Forwarding / Tunnelling 278 In general, IP Encapsulation within IP [7] or GRE [3] can be employed 279 for tunneling from the home agent to the mobile node. In the MVPN 280 case, it is difficult for a PAID agent to identify where the mobile 281 traffic is destined. 283 If the mobile node has register a binding with 'P' bit set, it means 284 all agents support PAID encapsulation [4]. In this case, the home 285 agent may tunnel packets to the private care-of address with PAID 286 encapsulation. If the mobile node is not able to register a binding 287 with the 'P' bit set, the PAID encapsulation should apply to the 288 tunnels between the mobile node and the foreign PAID agent or between 289 the home PAID agent and the home agent. Other tunnels may employ the 290 a regular tunneling mechanism other than the PAID encapsulation. 292 A private mobile node should use reverse tunnel [5] when originating 293 packets to its home domain. This is because private hosts currently 294 do not support PAID and packets are not deliverable between two 295 private domains. If the PAID can be supported between the foreign 296 domain and the destination domain, the mobile node should build two 297 levels of PAID forwarding headers for packets origination. 299 2.8 Interoperability with Mobile IP Base Protocol 301 Interoperability with the Mobile IP base protocol is unidirectional. 302 When the mobile node moves from a public domain to a private domain, 303 if the mobile node and the private domain supports MVPN while the 304 public domain supports the base protocol, the mobile node will be 305 able to register a mobility binding with the home agent successfully. 307 In this case, to register a mobility binding, the mobile node should 308 send a Registration Request to the home agent via the foreign PAID 309 agent. This request should include a private extension which contains 310 only the private care-of address. Since the Registration Reply does 311 not include the care-of address field, the home agent does not 312 neccesarily include a private extension in the reply to the mobile 313 node. 315 Supporting movement from a private domain to a public domain is 316 difficult and unnecessary. It is difficult for a foreign agent to 317 identify a private mobile node since there may be two mobile nodes 318 that have the same private address. On the other hand, the Mobile IP 319 base protocol currently supports movement between public networks or 320 between networks in the same routing domain. Since more and more 321 enterprise networks have been configured with private addresses, only 322 movement to the private domain is realistic. 324 3. Formats of Messages and Extensions 326 3.1 Registration Request Message 328 There is only one new bit 'P' in the Registration Request: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type |S|B|D|M|G|V|T|P| Lifetime | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Public Home Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Public Home Agent Address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Public Care-of Address | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 + Identification + 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 T If the 'T' bit is set, the mobile node asks its home 346 agent to accept a reverse tunnel from the care-of 347 address. Mobile nodes using a foreign agent care-of 348 address ask the foreign agent to reverse-tunnel its 349 packets. 351 P If the 'P' bit is set, the mobile node asks its home 352 agent to perform PAID encapsulation for packets destined 353 to the mobile node. 355 Public Home Address 357 The mobile node's home address if the mobile node is 358 public or otherwise the home PAID agent address. 360 Public Home Agent Address 362 The home agent address if the home agent is public 363 or otherwise the home PAID agent address. 365 Public Care-of Address 367 The care-of address if there is no foreign PAID agent 368 or otherwise the foriegn PAID agent address. 370 3.2 Registration Reply Message 372 MVPN does not introduce any new field in the Registration Reply 373 message except that it renames the home address field and the home 374 agent field as follows. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Code | Lifetime | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Public Home Address | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Public Home Agent Address | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 + Identification + 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Extensions ... 390 +-+-+-+-+-+-+-+- 392 Public Home Address 394 The mobile node's home address if the mobile node is 395 public or otherwise the home PAID agent address. 397 Public Home Agent Address 399 The home agent address if the home agent is public 400 or otherwise the home PAID agent address. 402 3.3 PAID Agent Extension 404 This extension is included in the Agent Advertisement message. The 405 mobile node can use it to detect movement and find a foreign PAID 406 agent. The presence of this extension signifies the agent supports 407 MVPN. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | Reserved | No. of Agents | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | PAID Agent Addresses | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Lifetime |B|H|F| Rsvd | Preference | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | . | 419 | . | 420 | . | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type 48 425 Reserved 0 426 No. of Agents 428 The number of agents in this extension. 430 PAID Agent Addresses 432 A PAID agent address. It MUST be public. 434 Lifetime The longest lifetime (measured in seconds) that this 435 agent is willing to accept in any PAID Request. 436 A value of 0xffff indicates infinity. 438 B Busy. The PAID agent will not accept request from 439 additional private nodes. 441 H Home PAID agent. This agent offers service as a home 442 PAID agent. 444 F Foreign PAID agent. This agent offers service as a 445 foreign PAID agent. 447 Preference 449 This is for load balancing or other purposes. 450 0 means no service can be provided. 451 infinity 0xff means unlimited services. 453 3.4 Private Extension 455 This extension is included in Registration Request and Registration 456 Reply messages. This is to extend the mobile IP to private internets. 457 The presence of this extension signifies the mobile node supports 458 MVPN. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length |M|H|F| Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | (If present) Private Home Address | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | (If present) Private Home Agent Address | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | (If present) Private Care-of Address | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 M bit 474 If set, the private home address is present. 476 H bit 478 If set, the private home agent address is present. 480 F bit 482 If set, the private care-of address is present. 483 In Registration Reply message, this bit SHOULD be set to 0 484 since the care-of address is not required. 486 3.5 Mobile PAID Extension 488 This extension is included in the PAID Registration Request and PAID 489 Registration Reply [4] messages. This is for the mobile node to 490 regionally register a mobility binding with a foreign PAID agent. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length |P| Reserved | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Public Home Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | (If present) Private Home Address | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 P bit 504 If set, the private home address is present. 506 4. Mobile Node Consideration 508 The mobile node supporting MVPN MUST always include the private 509 extension in the Registration Request messages. 511 4.1 Private Mobile Node 513 The discussion of movement from a private domain to a public domain 514 is beyond the scope of this document. Therefore, it is assumed that 515 the private mobile node moves to another private domain. 517 4.1.1 Regional Registration 519 When the private mobile node performs the regional registration, it 520 MUST include a mobile PAID extension in the PAID Registration Request 521 message. This extension MUST contain the private mobile home address. 523 When the mobile node receives a PAID Registration Reply, it SHOULD 524 verify the presence of the mobile PAID extension. This extension 525 SHOULD contain the private home address. 527 4.1.2 Home Registration 529 When the private mobile node performs the home registration, it MUST 530 include the private extension in the Registration Request and this 531 extension MUST contain the private home address, the private home 532 agent address, and the private care-of address. 534 When the mobile node receives a Registration Reply, it MUST verify 535 the presence of the private extension. The private extension MUST 536 contain the private home address and the private home agent address. 538 4.1.3 Datagram Originating and Receiving 540 The mobile node MUST employ the PAID encapsulation when it originates 541 packets to a corresponding node that is in a domain other than its 542 visiting domain. In this case, it SHOULD use reverse tunneling 543 method. 545 When receiving a packet tunneled by the foreign PAID agent, the 546 mobile node SHOULD decapsulate the packet using the relevant 547 encapsulation protocol as indicated in the packet. 549 4.2 Public Mobile Node 551 The Mobile IP base protocol supports the scenary that a public mobile 552 node moves to another public domain. In this case, a foreign PAID 553 agent can also be deployed in this foreign domain so that the mobile 554 node just keeps registering with this PAID agent regionally instead 555 of frequently performing home registration. For the convenience of 556 description as below, even if the care-of address is public, we still 557 call the care-of address as "private care-of address". 559 4.2.1 Regional Registration 561 When the public mobile node performs the regional registration, it 562 MAY include a mobile PAID extension in the PAID Registration Request. 563 This extension only contains the public mobile home address. 565 When the mobile node receives a PAID Registration Reply, it SHOULD 566 verify the presence of the mobile PAID extension. This extension 567 SHOULD contain the public home address. 569 4.2.2 Home Registration 571 When the public mobile node performs the home registration, it 572 SHOULD include the private extension in the Registration Request. 573 The extension SHOULD contain the private care-of address. 575 When the mobile node receives a Registration Reply, it SHOULD not 576 verify the presence of the private extension since the home agent 577 probably does not support MVPN. 579 4.2.3 Datagram Originating and Receiving 581 The mobile node MAY apply the PAID encapsulation when it originates 582 packets to a corresponding node that is in a domain other than its 583 visiting domain. In this case, it SHOULD use reverse tunneling 584 method. If the visiting domain is public, the mobile node MAY use 585 other encapsulation protocols to originate packets. 587 When receiving a packet tunneled by the foreign PAID agent, the 588 mobile node SHOULD decapsulate the packet using the relevant 589 encapsulation protocol as indicated in the packet. 591 5. Foreign Agent Consideration 593 The foreign agent MAY include the PAID agent extension in the Agent 594 Advertisement messages. This is to allow the mobile node to detect 595 the movement between different domains. The mobile node MAY also 596 learn from the PAID agent extension and initiate the regional 597 registration with a PAID agent. 599 In MVPN, the registration messages MAY bypass the foreign agent since 600 the mobile node MAY obtain co-located care-of address. 602 6. Foreign PAID Agent Consideration 604 6.1 Regional Registration 606 When the foreign PAID agent receives a PAID Registration Request 607 message with the mobile PAID extension included, if it can honour the 608 request, it SHOULD associate the binary identification of the mobile 609 node with the binary identification of the care-of address. It SHOULD 610 return a PAID Registration Reply message with the mobile PAID 611 extension. 613 6.2 Home Registration 615 6.2.1 Receiving Registration Request 617 When the foreign PAID agent receives a Registration Request message, 618 it SHOULD verify the reply is valid. The foreign PAID agent MUST 619 already have a regional mobility binding for the mobile node, and the 620 private extension MUST be present. 622 If the request is invalid, the PAID agent SHOULD deny the request and 623 respond with a Registration Reply message that contains a proper 624 error code. 626 If the request is valid, the PAID agent SHOULD associate the mobility 627 binding of the mobile node with the home agent or the binary 628 identification of the home agent. 630 If the home agent is private, the foreign PAID agent SHOULD tunnel 631 the request to the home PAID agent using PAID encapsulation. 632 Otherwise, the foreign PAID agent SHOULD simply forward the message 633 to the home agent. 635 6.2.2 Receiving Registration Reply 637 When the foreign PAID agent receives a Registration Reply message, 638 it SHOULD verify the reply is valid. If the mobile node is private, 639 the private extension MUST be present, and the private home address 640 and private home agent address MUST be present in the private 641 extension. 643 If the reply is invalid, the PAID agent SHOULD drop it and log a 644 message. 646 If the reply is valid, the PAID agent SHOULD activate the mobility 647 binding for subsequent datagram forwarding, and then forwards the 648 message to the mobile node. 650 6.3 Datagram Forwarding 652 When the foreign PAID agent receives a packet destined for the mobile 653 node, it MUST employ the PAID encapsulation to tunnel the packet to 654 the mobile node. 656 When the PAID agent receives a packet from the mobile node, it SHOULD 657 verify it is PAID encapsulated. If the P bit was not set in the 658 home registration for the mobility binding, the PAID agent MAY tunnel 659 the packet to the home agent using IP within IP encapsulation. 660 Otherwise, PAID encapsulation SHOULD be used. 662 7. Home PAID Agent Consideration 664 The home PAID agent SHOULD forward Registration messages, as 665 specified in PAID [4], between the home agent and the foreign PAID 666 agent. It does not have to save any mobility binding. 668 8. Home Agent Consideration 670 8.1 Home Registration 672 When the home agent receives a Registration Request message, it 673 SHOULD verify the reply is valid. If the mobile node is private, the 674 private extension MUST be present. 676 If the request is invalid, the home agent SHOULD deny the request and 677 respond with a Registration Reply message that contains a proper 678 error code. 680 If the request is valid, the home agent SHOULD associate the mobility 681 binding of the mobile node with itself. The home agent SHOULD send a 682 Registration Reply message, which SHOULD contain the original private 683 extension in the request. 685 If the home agent is private, it SHOULD tunnel the reply to the home 686 PAID agent using PAID encapsulation. Otherwise, the home agent SHOULD 687 simply forward the message to the foreign PAID agent or the foreign 688 agent. 690 8.2 Data Forwarding 692 When the home agent receives a packet destined for the mobile node, 693 if it is private, it MUST employ the PAID encapsulation to tunnel the 694 packet to the home PAID agent. Otherwise, the home agent MAY tunnel 695 the packet to the foreign PAID agent or the foreign agent using 696 IP within IP encapsulation. 698 When the home agent receives a packet originated from the mobile 699 node, it SHOULD simply forward it to the corresponding node. 701 9. Security 703 The security issue is beyond the scope of this document. 705 10. Acknowledgements 707 Many thanks to Dr. Y. C. Tay at the National University of Singapore 708 for supporting this joint work as well as for his valuable comments. 710 An implementation of MVPN is done by Wee Tuck Teo, one of the 711 authors, at the National University of Singapore. 713 References: 715 [1] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 716 1997. 718 [2] K. Egevang, and P. Francis. The IP Network Address Translator, 719 RFC 1631, May 1994. 721 [3] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 722 Encapsulation (GRE). RFC 1701, October 1994. 724 [4] Y. Li and W. T. Teo. IP Private Address Identification, Internet 725 Draft, January 1998. 727 [5] G. Montenegro. Reverse Tunneling for Mobile IP, Internet Draft, 728 March 1997. 730 [6] C. Perkins. IP Mobility Support Version 2, Internet Drafts, 731 November 1997. 733 [7] C. Perkins. IP Encapsulation within IP. RFC 2003, May 1996. 735 [8] C. Perkins. Mobile-IP Local Registration with Hierarchical 736 Foreign Agents. February 1996. 738 [9] Y. Rekhter and et. al. Address allocation for Private Internets, 739 RFC 1918, February 1996. 741 Author's Address 743 Questions about this memo can also be directed to the author: 745 W. T. Teo 746 Department of ISCS 747 National University of Singapore 748 Lower Kent Ridge Crescent 749 SINGAPORE 119260 751 E-mail: teoweetu@iscs.nus.edu.sg 753 Y. Li 754 Bay Networks, Inc. 755 BL60-304 756 600 Technology Park Drive 757 Billerica, MA 01821 759 Phone: 1-978-916-1130 760 Fax: 1-978-670-8760 761 E-mail: yli@BayNetworks.COM