idnits 2.17.1 draft-ruth-cdpd-networks-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-20) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 611 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 August 1996) is 10119 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) == Unused Reference: '2' is defined on line 571, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Ruth, R. Yuan 2 INTERNET DRAFT GTE Laboratories 3 6 August 1996 5 Interworking Between CDPD and Mobile IP Networks 6 draft-ruth-cdpd-networks-00.txt 8 Abstract 10 Two protocols, CDPD (Cellular Digital Packet Data) and Mobile-IP 11 have been developed by the CDPD Forum and IETF (Internet 12 Engineering Task Force) respectively to address the issue of 13 providing seamless network access to mobile data devices. In this 14 memo a scheme is proposed for the two networks to interwork 15 together and to support seamless migration of mobile data devices 16 between the networks. 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as ``work in 29 progress.'' 31 To learn the current status of any Internet-Draft, please check 32 the ``1id-abstracts.txt'' listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 35 munnari.oz.au (Pacific Rim). 37 1. Introduction 39 Two protocols, CDPD and Mobile IP, have been developed in the past 40 few years to address the issue of network layer mobility support 41 for the general purpose data network. Both protocols enable a 42 mobile terminal to migrate seamlessly from one local area network 43 to another. 45 The CDPD (Cellular Digital Packet Data) standard was developed by 46 the CDPD Forum (an industrial association of cellular carriers, 47 equipment vendors and application developers) to provide packet 48 data services through the cellular telephony network. It specifies 49 a set of mobility enabling protocols for use in the CDPD networks. 50 CDPD networks is being deployed nationwide by the cellular 51 carriers. The latest specification CDPD Specification, version 1.1 52 was published in January 1995 [1]. 54 The Mobile-IP protocol has been developed by the IETF to provide 55 mobility support in the current TCP/IP Internet. Mobile-IP is 56 designed to support transparent host migration among a variety of 57 IP subnetworks. 59 The concepts and principles for mobility management in both 60 protocols are the same and many of mobility support functions are 61 similar. However, while CDPD is designed to be a tariffed, carrier 62 operated service with uniform link layer infrastructure (it has 63 been widely deployed by many cellular carrier), Mobile IP is 64 designed to support a variety of heterogeneous subnetworks. Thus, 65 many differences exist between the two protocols. Currently, if a 66 Mobile IP host migrates into a CDPD coverage area (or vice versa), 67 its network connection will be terminated even with a CDPD 68 wireless modem. This is because the network layer protocols for 69 mobility support of the two networks cannot interoperable with 70 each other. Therefore, to enable universal network connectivity 71 for mobile hosts, it is necessary to provide methods for the two 72 networks to internetwork with each other. 74 This memo compares the mobility management functions for CDPD and 75 Mobile IP networks and suggests ways to support internetworking 76 between the two networks. 78 2. Mobility Support in CDPD Networks 80 CDPD is designed to exploit the unused capacity of the cellular 81 telephone network for packetized data delivery. It leverages the 82 existing cellular infrastructure by adding CDPD specific equipment 83 to the existing cell sites. The CDPD network architecture makes 84 use of three distinctive devices: 86 o MES: Mobile End System -- A mobile terminal with a wireless 87 modem that accesses the CDPD network through an airlink. 88 Each MES may have one or more Network Entity Identifiers 89 (NEIs) which are IP or CLNP addresses. The CDPD modem also 90 has a 48-bit CDPD equipment identifier assigned by the 91 manufacturer. 93 o MDBS: Mobile Data Base Station -- provides the mobile 94 data link relay function for the MES over the radio channel. 95 It performs part of the radio resource management function 96 to ensure that the data user doesn't interfere with the 97 regular voice users. 99 o MDIS: Mobile Data Intermediate System -- controls mobility, 100 performs registration, authentication and routing functions. 101 It also controls the MDBS for radio resource management. The 102 MDIS is a full-fledged network router. 104 Additionally, the CDPD architecture uses the term "Fixed End 105 System" (FES) to denote an ordinary hardwired network end system. 107 The logical CDPD network architecture is shown in Figure 1:. 109 +------------------+ 110 | | 111 MES....MDBS-----MDIS---| IP/CLNP Backbone |---Router--FES 112 | | 113 +------------------+ 115 Figure 1: Logical CDPD Network Architecture 117 In a CDPD network, each wireless local network (termed as AREA) 118 consists of one MDIS and up to 200 base stations (MDBSs). The 119 mobile end system (MES) uses a multiple access scheme (Digital 120 Sensing Multiple Access: DSMA) that gives packet data lower 121 priority than voice traffic to access the cellular network. 122 Because the MDBS is only involved in the data link relay function, 123 the MES can roam transparently within the AREA using the different 124 MDBSs for the data relay service, while maintaining the same data 125 link connection between the MDIS and MES. Thus the AREA can be 126 treated as a single network segment (e.g. Ethernet). Because there 127 is one and only one MDIS within one AREA, the MDIS serves as the 128 default gateway to/from the local network. It advertises the 129 reachability of this network segment to other routers in the 130 IP/CLNP backbone network. 132 The CDPD Forum has obtained several Class B IP addresses with 133 prefix 166 from IANA. Thus, all the CDPD network AREAs use 166 as 134 the network prefix. 136 If the MES roams from one AREA to another, the MES recognizes that 137 it is in a new AREA during the cell transfer by listening to the 138 channel identification message broadcasted from the base station 139 during the channel acquisition time. It then initiates a new 140 registration process using the MNRP (Mobile Network Registration 141 Protocol) with the new MDIS. The serving MDIS handles the 142 registration for the MES. It also communicate with the home MDIS 143 of the MES so that appropriate authentication can be performed, 144 and an appropriate routing entry can be set up at the home MDIS to 145 forward packets destined to the mobile end system to the new 146 foreign area. Figure 2 depicts the information flow for such an 147 inter-AREA migration 149 old serving new serving home 150 MES MDIS MDIS MDIS 152 |--cell exit decision--| | | 153 | | | | 154 |--cell selection & entry decision ------| | 155 | | | | 156 |--data link establishment---------------| | 157 | | | | 158 |--end system hello ---+---------------->| | 159 | | | | 160 | | |---redirect req-->| 161 | | | | 162 | | |<--redirect con --| 163 | | | | 164 |<--intermediate system confirm (ISC)----| | 165 | | | | 166 | |<--------redirect flush (RDF)-------| 168 Figure 2: Information Flow for Inter-AREA Migration 170 One key aspect of an MES migrating into a new area is the 171 associated authentication to verify the identity of the MES. In 172 the CDPD network, airlink security is accomplished by exchanging 173 secret keys between the serving MDIS and the visiting MES using a 174 Diffie-Hellman key exchange scheme. After the MES obtains the key 175 from the MDIS, it sends the authentication information tuple (where ARN = Authentication Sequence Number and ASN = 177 Authentication Sequence Number) to the serving MDIS in the End 178 System Hello message. This information is relayed to the home MDIS 179 for authentication in cleartext through the wired network. 181 After authenticating the MES, the home MDIS returns a success 182 message and assigns a new to the serving MDIS in the 184 Redirect Confirm message; the information is relayed to the MES 185 and can be used for authentication in the next registration. 187 The data packet forwarding from the home MDIS to the serving MDIS 188 is done by encapsulating each IP/CLNP packet into a new CLNP 189 packet. The destination address of the new CLNP packet is the 190 serving MDIS. When the serving MDIS receives the encapsulated CLNP 191 packet, it decapsulates the packet and delivers to the MES using 192 the established data link channel. This triangular routing scheme 193 (shown in Figure 3) is similar to Mobile IP triangular routing. As 194 with Mobile IP, the CDPD MES keeps its IP address at all times. 196 serving home 197 MES<...>MDBS<--->MDIS<================MDIS 198 \ /\ 199 \ | 200 \ | 201 \ | 202 ------------>host 204 === indicates an encapsulated flow 206 Figure 3: Packet Forwarding in a CDPD Network 208 3. Mobility Support in Mobile IP networks 210 Mobile IP is designed to support host mobility in the current 211 Internet Protocol (IPv4). Therefore, any internet host with an 212 arbitrary IP address can be a mobile host migrating into a foreign 213 network. In addition, a local network segment may have multiple 214 routers attached, so that the routing path to/from the local 215 network is not unique. To address these issues, the basic 216 architecture of Mobile IP defines two entities: Home Agent (HA) 217 and Foreign Agent (FA). The FA is located in the serving (foreign) 218 network and provides direct network access to the mobile host (MH) 219 when needed. The HA is responsible for intercepting IP packets 220 destined to the mobile host and forwarding them to the serving FA 221 of the mobile host. Because the mobile host may not be able to 222 detect a subnet change through the link layer protocol, the FA/HA 223 explicitly advertise their presence using Agent Advertisement 224 messages (an extension of the ICMP router advertisement message, a 225 network layer service). 227 When a mobile host migrates into a new local area it recognizes the 228 new network from the Agent Advertisement message broadcasted 229 periodically from the FA. The network layer broadcast of the agent 230 advertisement message is necessary because there may not be a data 231 link layer mechanism to detect the network segment change. The Agent 232 Advertisement message includes one or more Care-of-Addresses (COAs) 233 from the FA, encapsulation type(s) supported by the FA, registration 234 lifetime and advertisement sequence number. The MH then initiates a 235 registration process with the home agent using UDP messages with 236 destination port 434. The registration message is relayed through 237 the serving FA in the foreign network. The registration process 238 enables the HA to update its mobility binding for the migrated mobile host so that 240 packets can be forwarded to the new location (COA). 242 To address the authentication and security concerns, Mobile IP 243 defines flexible authentication extensions that can be added to 244 the registration message using keyed-MD5. Both mobile-HA and 245 mobile-FA authenticators can be attached to the registration 246 message for proper authentication. While different authentication 247 schemes can be employed by the MH, FA and HA through service 248 agreement in advance, the Mobile IP standard specifies a default 249 authentication method using the MD5 algorithm (RFC 1321). The 250 algorithm computes a one-way hash function that produces a 128-bit 251 "message digest" for an arbitrary long registration message. The 252 shared secret key is pre-configured for the MH - HA 253 authentication. For MH-FA authentication, the key can either be 254 distributed manually, or using public key. The information flow of 255 the registration messages is depicted in Figure 4. 257 MH new FA old FA HA 259 |--Registration Req-->| | | 260 | | | | 261 | |-----------Registration Req--------->| 262 | | | | 263 | |<---------Registration Reply---------| 264 | | | | 265 |<-Registration Reply-| | | 267 Figure 4: Information Flow for MobileIP Registration Messages 269 The Mobile IP protocol also defines an option for the MH to act as 270 its own FA, if the foreign network has no FA and the MH can obtain 271 a local address from the DHCP server (e.g. using anycast 272 mechanism). In this case, the Care-of-Address is the newly 273 obtained the local IP address from DHCP server. 275 It is also noted that there is no registration cancellation 276 message sent to the old FA when registration at the new FA becomes 277 active. Because IP provides best effort datagram delivery, the 278 packets in transit will simply be dropped and the old registration 279 will expire after the validation period. 281 Similar to the CDPD approach, the packet forwarding in Mobile IP 282 is carried out using encapsulation/decapsulation. The HA 283 intercepts each packet destined to the MH and then encapsulate the 284 packet using the COA in the mobility binding of the MH. Upon 285 receiving the encapsulated packet, the FA decapsulates the packet 286 and sends it directly to the MH using its own link layer protocol. 287 Figure 5 shows the packet forwarding in Mobile IP. 289 MH<----FA<=========================HA 290 \ /\ 291 \ | 292 \ | 293 \ | 294 ------------------------->host 296 === indicates an encapsulated flow 298 Figure 5: Packet Forwarding in a Mobile IP Network 300 Two encapsulation methods are defined in the Mobile IP standard: 301 Minimum encapsulation and IP within IP (IPIP). IPIP encapsulation 302 is the recommended encapsulation method. The IPIP method handles 303 packet fragmentation easily but adds more overhead to the 304 encapsulated packet. 306 4. Comparison between CDPD and Mobile IP 308 CDPD and Mobile IP are designed to support general purpose network 309 layer mobility for packet data networks. In particular, both are 310 designed to support network layer mobility in the IP network, thus 311 enabling mobile host migration in the Internet. The basic mobility 312 management functions for CDPD and Mobile IP networks are based on 313 the same concepts and principles (e.g. packet encapsulation and 314 forwarding). 316 Although many of the mobility management concepts and functions in 317 CDPD and Mobile IP are similar, the detailed message formats 318 differs from each other. In addition, there are several notable 319 difference in the protocol: 321 o In CDPD, the MES can detect the network segment change from 322 the link layer support, while in mobile IP, the explicit 323 Agent Advertisement message is necessary for the mobile host 324 to detect network change. 326 o In CDPD, the registration process is separated into two 327 stages. First, the MES registers with the serving MDIS 328 using the MNRP, where no authentication is required. 329 Second, the serving MDIS uses a separate protocol, MNLP, 330 to update the location information to the home MDIS and 331 forward the authentication information from the MES to 332 the home MDIS for authorization. In Mobile IP, the mobile 333 host registers directly with the HA, while the FA provides 334 the relay service to the registration services. 336 o In CDPD, the home MDIS informs the previous serving MDIS 337 to flush the MES's registration record, while in Mobile IP, 338 multiple simultaneous registration records with different 339 FAs for a mobile host are permitted. 341 o Because of the uniqueness of the MDIS, it is guaranteed 342 that the home MDIS can intercept the packet destined to 343 the MES, while in mobile IP, the HA needs to use the proxy 344 ARP protocol to advertise the mobile host reachability in 345 order to intercept the packet. 347 o CDPD defines a single encapsulation method between the 348 home MDIS and the serving MDIS. All the packets forwarded 349 to the serving MDIS are encapsulated using a CLNP packet 350 with minimum encapsulation header to increase efficiency. 351 In Mobile IP, two encapsulation methods are defined with 352 IP within IP as the recommended method. 354 The protocol architecture for registration in CDPD and Mobile IP 355 differ as follows. The CDPD registration procedure is separated 356 into two phases (MNRP and MNLP), different from the one phase 357 approach of Mobile IP. In addition, the CDPD's MNLP defines 358 several message to allow the MDISs to exchange location update 359 information without the involvement of MES. Furthermore, the 360 registration message contents of CDPD and Mobile IP is different. 361 The information fields contained in these messages are listed in 362 Table 1. 364 CDPD MobileIP 366 Parameter Field Name M/O Field Name M/O 368 Permanent addr. Source addr M Home addr M 369 of mobile 371 Registration Regist. seq M Registration M 372 seq. control Count identification 374 Authentication Authentication M Mobile-home M 375 (home-mobile) parameter auth. extension 377 Home agent id NR Home Agent M 379 Registration NR Lifetime M 380 lifetime 382 Forwarding Forwarding net M Care-of-Address M 383 address address 385 Multiple regist. NR Code M 386 req. 388 Authentication NR Mobile-foreign O 389 (foreign-mobile) auth. extension 391 Encapsulation NR Minimum encaps. O 392 method extension 394 Carrier identi- Location info O NR 395 fication 397 M=Mandatory, O=Optional, NR=Not Relevant 399 Table 1: Information fields in registration messages 401 In a CDPD network, no authentication is required between the MES 402 and the serving MDIS. although an encryption key is exchanged 403 between the two entities using Diffie-Hellman algorithm. The MES 404 then authenticates itself within its home MDIS using the > tuple; the serving MDIS will only issue an ISC message 406 to the MES if proper authorization from the home MDIS is obtained. 407 In a Mobile IP network, the registration message from the mobile 408 host can contain the FA-mobile host authentication extension to 409 allow the FA and the MH to authenticate each other. 411 When the mobile host/end system is roaming, the home network 412 should forward the packets to the serving/foreign network. In 413 CDPD, this task is being performed by the home MDIS. Since all 414 packets destined into the MES's home network go through the MDIS, 415 there is no need for the MDIS to make extra efforts to intercept 416 the packets. In Mobile IP, a subnet may have multiple paths for 417 packets to be routed to/from the subnet, and the mobile host's HA 418 may not be the gateway router. Thus the HA uses gratuitous ARP to 419 advertise the reachability of the mobile host once it receives the 420 mobile's registration from a foreign network (impersonating the 421 mobile host). When the MH returns to the home network and 422 deregisters from the HA, the normal packet delivery is resumed. 424 5. Internetworking between CDPD and Mobile IP 426 Due to the differences mentioned in Section 3, CDPD and Mobile IP 427 cannot interwork without any modifications. However, since many of 428 the mobility management concepts and functions are derived from 429 the same principles, CDPD and Mobile IP can support each other's 430 operation without major modification of the specification. This 431 section discusses how a CDPD network can support a Mobile IP user 432 through the use of middleware software that interfaces the CDPD 433 and Mobile IP networks. (A similar method can be used to enable 434 CDPD terminal support from a Mobile IP network.) 436 Suppose a Mobile IP host enters a CDPD domain and wants to 437 establish network access through the CDPD network. The MH can use 438 a CDPD docking station and/or a CDPD modem to access the CDPD 439 network. Following the CDPD network operation convention, the CDPD 440 modem must have a valid network address (IP address) registered 441 with the network operator. The CDPD network address uses prefix 442 166 and is different from the original IP address of the mobile 443 host. 445 To obtain network service from the CDPD network and maintain a 446 Mobile IP connection, the MH must register with both the CDPD 447 network and its HA. Following the CDPD protocol, the CDPD modem 448 performs the CDPD registration with the serving MDIS using its 449 CDPD recognized IP address with prefix 166. From the CDPD 450 network's perspective, the MH is a valid CDPD MES with a valid 451 CDPD address, thus the Mobile IP aspect of the MH is completely 452 transparent from the CDPD network. The MH can then use the 453 standard Mobile IP protocol to register with its HA, using the 454 CDPD network address as the COA. In this case, the FA and the MH 455 are collocated and MH acts as its own agent. The CDPD network 456 address (NEI) is easily accessible from the modem memory/registers 457 using the standard AT command. 459 Upon completion of the registration process, the MH can continue 460 to send out IP packets to the network using the serving MDIS as 461 its default router. The CDPD network treats the MH as a 462 conventional MES with a valid CDPD address. The packets destined 463 to the MH will be encapsulated by the HA and forwarded to the MH 464 using the CDPD network address as the COA. The scenario is the 465 same as an IP-based FES communicating with an MES. The routing 466 scenario is depicted below in Figure 6. (The CDPD network 467 encapsulation is not shown.) 469 +---------+ +--------------+ 470 MH/MES/FA<==| CDPD |<===| |<===HA 471 \ | | | | /\ 472 \ | Network | | INTERNET | | 473 ---->| |--->| |-->host 474 +---------+ +--------------+ 476 === indicates an encapsulated flow 478 Figure 6: Supporting Mobile IP host in a CDPD Network: 479 One-directional Encapsulation Approach 481 Refinement 483 The one directional encapsulation approach described above may 484 create an accounting problem for the CDPD network. As dictated by 485 some CDPD network operators, any packet originated from the CDPD 486 network must have a valid CDPD network address (with prefix 166) 487 as its source address. Such networks use the source to create 488 accounting data for billing purposes. The one way encapsulation 489 approach allows a packet originating from the MH to use its home 490 address as the source address, which cannot be properly accounted 491 by the account meter in the MDIS. Therefore, for accounting 492 purposes, every packet originating from the MH should be 493 encapsulated using the CDPD network address as the source address. 494 However, this creates another problem for the corresponding host 495 for the MH, since the corresponding host may not have the 496 capability to decapsulate the packet. 498 A bidirectional encapsulation approach is proposed to solve the 499 accounting problem and keep the corresponding host transparent at 500 the same time. The MH encapsulates outgoing packets using the HA's 501 address as the destination address and the CDPD NEI as the source 502 address. Upon receiving the encapsulated packets, the HA 503 decapsulates and forwards them to the correct destination. 504 Therefore, to support the migration of a mobile host into a CDPD 505 network, the HA must also provide a decapsulation function. This 506 is relatively simple because the HA already has the encapsulation 507 capability. The bidirectional encapsulation tunnel established 508 between the MH and HA serves as a virtual private network (VPN) 509 connection for the MH and its home network. 511 The bidirectional encapsulation method is depicted in Figure 7. 513 +---------+ +--------------+ 514 | CDPD | | | 515 MH/MES/FA<==>| Network |<==>| INTERNET |<===>HA<--->host 516 | | | | 517 +---------+ +--------------+ 519 === indicates an encapsulated flow 521 Figure 7: Supporting Mobile IP host in a CDPD Network: 522 Bi-directional Encapsulation Approach 524 Note that in the initial approach, the only interaction between 525 the Mobile IP software and the CDPD network is for the Mobile IP 526 software to retrieve the CDPD network address associated with the 527 CDPD modem. No modification on the part of CDPD network 528 infrastructure is needed. For the one directional encapsulation 529 approach, no change on the Mobile IP HA is required. On the other 530 hand, for the VPN approach, the Mobile IP software on the MH and 531 its HA should be enhanced so that a bidirectional encapsulation 532 tunnel can be established between the two entities. 534 If the MH/MES roams into a new serving MDIS, both the registration 535 and packet forwarding will be performed by the CDPD network 536 without impact on the Mobile IP protocol. 538 6. Summary 540 This memo has investigated the mobility management functions for 541 the two prominent technologies being developed and deployed in the 542 communication industry: CDPD and Mobile IP. While these two are 543 based on the same principles and concepts, they can not interwork 544 with each other due to the differences in their approaches in the 545 registration protocol, encapsulation method, and security 546 extensions. Historically, the two protocols have different design 547 goals in terms of uniformity/heterogeneity, tariff and security 548 concerns. 550 An approach was identified for interworking between CDPD and 551 Mobile IP networks while keeping the existing protocols unchanged. 552 The scheme calls for adding relative simple middleware to the 553 mobile host software to enable its usage of CDPD network as a 554 Mobile IP subnet. 556 With a large deployed base of CDPD networks and the ubiquity of 557 the IP based Internet it is important to explore schemes that 558 allow the two networks to interconnect with each other and provide 559 mobility services to the ever increasing population of mobile 560 computing devices. 562 7. Security Considerations 564 Security considerations are not discussed in this memo. 566 8. References 568 [1] CDPD Forum, "Cellular Digital Packet Data System 569 Specification", Release 1.1, January 19, 1995. 571 [2] IETF Mobile IP working group, "IP Mobility Support - Draft- 572 IETF-Mobileip-Protocol-17", May 31, 1996. 574 9. Authors' Addresses 576 Greg Ruth 577 GTE Laboratories, Inc. 578 40 Sylvan Street 579 Waltham, MA 02254 580 gruth@gte.com 581 617 466 2448 583 Ruixi Yuan 584 GTE Laboratories, Inc. 585 40 Sylvan Street 586 Waltham, MA 02254 587 ry00@gte.com 588 617 466 2050 589 Internet Draft CDPD-MobileIP Interoperability 31 July 590 1996