idnits 2.17.1 draft-chuahli-mobileip-dremip-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-26) 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 14 longer pages, the longest (page 12) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 31 instances of lines with control characters in the document. ** 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 645: '... Reply MUST include a care-of addres...' RFC 2119 keyword, line 647: '...gistration Reply MAY additionally appe...' RFC 2119 keyword, line 719: '... agent, which MAY be smaller than th...' RFC 2119 keyword, line 771: '... MUST be ignored on rece...' RFC 2119 keyword, line 878: '... The extension MUST also be included...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 257 has weird spacing: '... (iii preve...' == Line 334 has weird spacing: '...advised to re...' -- 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 (30 October 1997) is 9675 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: '3' is defined on line 1675, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1688, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-04 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- No information found for draft-optim - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. C. Chuah 2 INTERNET DRAFT Lucent Technologies 3 Y. Li 4 Bay Networks, Inc. 5 30 October 1997 7 Distributed Registration Extension to Mobile IP 8 draft-chuahli-mobileip-dremip-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 document proposes an extension to the Mobile IP base protocol. 37 The features in this extension allow us to (i) reduce frequent 38 distant registrations at the mobility agents, (ii) be more scalable 39 by a separation of registration and forwarding services, (iii) ease 40 the key management problem among mobility agents, and (iv) be 41 interoperable with other mobility agents/mobile nodes running 42 standard Mobile-IP specified in RFC2002. 44 Contents 46 Abstract ............................................................ i 48 1. Introduction ..................................................... 1 49 1.1. Architectural Entities ..................................... 2 50 1.3. Terminology ................................................ 2 51 1.3. Design Goals ............................................... 4 52 1.3.1 Reduce Distant Registration Frequency ..................... 4 53 1.3.2 Ease of Key Management .................................... 5 54 1.3.3 Increase Scalability ...................................... 5 56 2. Protocol Overview ................................................ 6 57 2.1. Agent Discovery ............................................ 6 58 2.2. Local Registration ......................................... 6 59 2.3. Home Registration .......................................... 7 60 2.4. Transit Registration ....................................... 7 61 2.5. Datagram Routing ........................................... 8 62 2.6. Local/Home Service.......................................... 8 63 2.7. Foreign Server Smooth Handoffs ............................. 9 64 2.8. Optimizing Registrations ................................... 9 65 2.9. Interoperability with the Base Protocol .................... 10 67 3. Message Formats .................................................. 11 68 3.1. Agent Advertisement ........................................ 11 69 3.2. Registration Request ....................................... 11 70 3.3. Registration Reply ......................................... 12 71 3.4. Route Request .............................................. 12 72 3.5. Route Reply ................................................ 13 74 4. Newly Defined Extensions ......................................... 14 75 4.1. Registration Server Extension .............................. 14 76 4.2. Care-of Address Extension .................................. 14 77 4.3. Agent-Server Authentication Extension ...................... 16 78 4.4. Mobile-Server Authentication Extension ..................... 16 79 4.5. Server-Server Authentication Extension ..................... 17 81 5. Care-of Agent Considerations ..................................... 17 82 5.1. Receiving Route Request .................................... 17 83 5.2. Binding Route Enable/Disable................................ 18 85 6. Registration Server Considerations ............................... 18 86 6.1. Data Structure ............................................. 19 87 6.2. Receiving Registration Request as a Binding Registrar ...... 19 88 6.3. Receiving Registration Request as a Binding Relay .......... 20 89 6.4. Sending Route Request ...................................... 21 90 6.5. Receiving Route Reply ...................................... 21 91 6.6. Load Balancing ............................................. 22 93 7. Mobility Agent Considerations .................................... 22 94 7.1. Sending Agent Advertisement ................................ 22 95 7.2. Receiving Registration Request as a Foreign Agent .......... 22 96 7.3. Receiving Registration Request as a Home Agent ............. 22 97 7.4. Receiving Registration Reply ............................... 22 98 7.5. Receiving Route Request .................................... 22 100 8. Mobile Node Considerations ....................................... 23 101 8.1. Receiving Agent Advertisement .............................. 23 102 8.2. Sending Registration Request ............................... 23 103 8.3. Receiving REgistration Reply ............................... 24 104 8.4. Handoff .................................................... 24 106 Appendix A Registration Server Discovery Procedure .................. 25 107 Appendix B Care-of Agent Discovery Procedure ........................ 25 108 Appendix C Key Distribution Between Registration Servers ............ 25 109 Appendix D Example Scenarios ........................................ 26 110 Appendix D.1 Local/Home Registrations ............................... 26 111 Appendix D.2 Transit/Home Registrations ............................. 27 112 Appendix D.3 Optimizing Registrations ............................... 31 113 Appendix D.4 Interoperability with RFC2002 .......................... 32 115 Reference ........................................................... 33 117 Acknowledgement ..................................................... 34 119 Authors's Address ................................................... 34 120 1. Introduction 122 Mobile IP base protocol [1] provides an efficient, scalable mechanism 123 for node mobility within the Internet. However, the key management 124 between the home and foreign agents, and between the foreign agents 125 and the mobile node is still a problem. 127 Secondly, as Perkins [2] addresses in the hierarchical foreign agents 128 model, each time the mobile node moves, a Registration Request 129 message has to be approved by the mobile node's Home Agent. In cases 130 where the home agent is far away, it may become too expensive or even 131 impossible to complete these frequent registrations. This document 132 proposes an extension to the Mobile IP base protocol to solve these 133 problems. 135 In this internet draft, we introduce some extensions to the base 136 protocol to provide a more scalable solution to the mobility 137 management problem. Our proposed extension separates the the 138 registration and forwarding services. The registration service can 139 be provided additionally by a network entity called registration 140 server while the forwarding service can be provided by a network 141 entity called care-of agents. The introduction of registration 142 servers allow us to reduce the number of trusted entities in the 143 network and hence enable us to ease the key management problem. It 144 also allows us to do authentications such that illegal use of routing 145 services. The introduction of care-of agents allow us to do 146 load-balancing according to the dynamically changing traffic needs. 147 In addition, we define 3 types of registrations, namely local, home 148 and transit registrations. By having these different types of 149 registrations, we are able to reduce the frequency of distant 150 registrations. Our new features are introduced in such a way that the 151 mobile nodes and mobility agents supporting our new features can 152 still interoperate with mobile nodes and mobility agents supporting 153 the base protocol specified in RFC2002. 155 1.1. Architectural Entities 157 The memo introduces the following new architectural entities: 159 Registration Server (RS) 161 An entity providing registration service within a routing 162 domain. A registration server in the mobile node's home routing 163 domain is called a Home Registration Server. A registration 164 server in the routing domain that the mobile node is visiting 165 is called a Local Registration Server. Otherwise, it is called 166 a Transit Registration Server. 168 Care-of Agent (COA) 170 An entity providing forwarding service and hence care-of 171 addresses. In the base protocol, a care-of agent is the foreign 172 agent itself. However, we propose here to separate it from the 173 foreign agent. 175 1.2. Terminology 177 Care-of Address 179 The care-of address is redefined, in this memo, as an IP 180 address from which datagrams can be relayed to the mobile 181 node, whether or not through one or more intermediate nodes. 183 Mobility Binding 185 The mobility binding is redefined the same as in the base 186 protocol except that the care-of address takes the above 187 definition. 189 Registration 191 The registration is redefined as a procedure for mobile node to 192 register a mobility binding with a registration server or a 193 home agent and to obtain a care-of address closer to the home 194 agent, by exchange of Registration Request and Registration 195 Reply messages. In the base protocol, this is a registration 196 with a home agent. 198 The care-of address submitted in the Registration Request is 199 called the CHILD care-of address of the registration. The one 200 obtained by this registration is called the PARENT care-of 201 address of the registration. 203 Binding Registrar 205 A registration server or home agent, with which the mobile node 206 registers a mobility binding. In the base protocol, this is the 207 home agent, with which a mobility binding is associated. 209 Binding Relay 211 A foreign agent or registration server, through which the 212 Registration Reply for a mobility binding can be delivered to 213 the mobile node. In the base protocol, this is the foreign 214 agent. 216 A mobile node is allowed to register a mobility binding with a 217 binding registrar via a binding relay. 219 Home/Local/Transit Registration 221 A registration where the binding registrar is in the mobile 222 node's home routing domain is called a home registration. A 223 registration where the binding registrar is in the routing 224 domain that is visited by the mobile node is called a local 225 registration. Otherwise, the registration is called a transit 226 registration. 228 Complete Registration 230 The combination of one or more registrations, which allows 231 tunnels to be built such that there will be at least one 232 forwarding path from the home agent to the visiting mobile 233 node. 235 Binding Route Enabled/Disabled 237 A binding route is enabled by a care-of agent if, a datagram 238 destined for the mobile node is relayed by this care-of agent 239 from the parent care-of address of a registration to the child 240 care-of address. In the base protocol, this means to build a 241 tunnel from the home agent to the care-of address and to add a 242 routing entry to the care-of address for the mobile node. 244 A binding route is disabled by a care-of agent if, the care-of 245 agent functions as a regular router disregarding the existence 246 of a mobility binding if any. Thus, a datagram destined for the 247 mobile node will be forwarded to the mobile node's home network 248 or simply discarded with an ICMP message bounced if the 249 datagram was tunneled to the care-of agent. 251 1.3 Design Goals 253 There are 5 major design goals for this protocol, namely, 255 (i) reduce frequent distant registrations, 256 (ii) ease key management, 257 (iii prevent illegal use of routing services, 258 (iv) increase scalability, 259 (iv) interoperable with RFC2002. 261 This protocol separates the the registration and forwarding services. 262 The registration service is provided by the registration server while 263 the forwarding service is provided by the care-of agents. Since each 264 routing domain may only have one registration server and many care-of 265 agents, the number of trusted entities in mobile networks are reduced 266 and hence enable us to ease the key management problem. It also 267 allows us to do authentications such that illegal use of routing 268 services can be prevented. 270 1.3.1 Reduce Frequent Distant Registrations 272 To reduce frequent distant registrations, we define 3 types of 273 registrations, namely local, home and transit registrations. When the 274 mobile node moves from one routing domain to another, it needs to 275 perform a home registration with the home registration server (HRS) 276 to inform the HRS of the identity of the local Registration Server it 277 is currently registered. 279 When the mobile node moves within the same routing domain, even 280 though its point of attachment may change from one foreign agent to 281 another, the mobile node only needs to perform local registrations. 282 As long as the parent care-of address in the local Registration Reply 283 message matches with the one obtained previously, the mobile node 284 needs not perform any home registrations. That way, the number of 285 distant registrations with HRS can be reduced. 287 The transit registrations are used when the mobile node's home 288 registration server does not have security association with the 289 local registration server. The local server will give the mobile 290 node the identity of a registration server which can act as a 291 middleman for the home registration. The mobile node will first 292 perform a transit registration with this transit registration 293 server to get a parent care-of address. Using this allocated 294 care-of address from the transit registration, the mobile node 295 can then do a home registration via the transit registration 296 server. 298 In our proposed registration extension MobileIP protocol, we 299 assume that the home registration life time exceeds the transit 300 registration life time which exceeds the local registration life 301 time. 303 1.3.2 Ease of Key Management/Prevent Illegal Usage 305 One of the design goals in this protocol is to prevent replay attacks 306 in the mobile node's registration procedure, and to prevent an 307 illegal mobile node from stealing services from a routing domain. The 308 existing mobile IP base protocol does not require an existence of 309 security associations between the mobile node and the foreign agent, 310 and between the home agent and the foreign agent. 312 If there are already such security associations, this protocol works 313 exactly the same way as the base protocol. Otherwise, this protocol 314 provides a means to compensate for a lack of such security 315 associations. We assume that there are security associations between 316 registration servers. Since the number of registration servers are 317 much less than the number of mobility agents, we have a reduction in 318 key management problem. This makes the our enhanced Mobile-IP model 319 more scalable. 321 If there is no security association between the mobile node and the 322 foreign agent or no security association between the foreign agent 323 and the home agent, the mobile node will not be allowed to register 324 directly with its home agent, but to first register with a 325 registration server in the local routing domain. This local server 326 in turn allocates a parent care-of address and returns to the mobile 327 node via the registration reply. 329 If there is a security association between the foreign server and the 330 mobile node's home agent, the mobile node can subsequently register 331 the parent care-of address allocated by the foreign server with the 332 home agent. 334 Otherwise, the mobile node is advised to register with its home 335 registration server via the foreign server. This is feasible because 336 there are security associations between the foreign server and the 337 home server, and between the mobile node and the home server. Thus, a 338 completely secured binding is established, which allows packets to be 339 delivered to the mobile node. 341 1.3.3 Increase Scalability 343 As mentioned above, the introduction of registration servers reduces 344 the number of trusted entities and hence reduce the severity of key 345 management problem. Hence, our enhanced Mobile-IP model is more 346 scalable than the Base protocol. In addition, by separating the 347 registration service with the forwarding services and introducing 348 as many care-of agents as we need, we can perform some load-balancing 349 to cater to the dynamically changing traffic needs. 351 2. Protocol Overview 353 A mobile node should have a complete registration when it moves away 354 from its home network. A complete registration consists of local 355 registrations, home registrations and/or transit registrations. A 356 registration starts with receiving Agent Advertisements. Thus, 357 changes for this protocol will apply to both the Agent Discovery and 358 the Registration procedures. 360 2.1 Agent Discovery 362 In the base protocol, the foreign agents advertise their presence via 363 Agent Advertisement messages. The mobile node obtains a care-of 364 address (which usually is the foreign agent's address) from the 365 advertisements. The mobile node may initiate a registration using 366 this care-of address. 368 In this proposal, the care-of address obtained from the Agent 369 Advertisement and used in a registration request is referred to 370 as the child care-of address of this registration. 372 In addition to the care-of addresses in the Agent Advertisement 373 message, our proposal requires that the Agent Advertisement 374 message includes a registration server extension so that 375 prospective mobile nodes can choose a registration server for the 376 local registration. The registration extension contains one or more 377 registration server addresses. There is a priority value and a 378 lifetime associated with each registration server's address. 380 2.2 Local Registrations 382 When the mobile node detects a change in the point of attachment, it 383 performs a local registration with the local registration server via 384 a foreign agent. The mobile node sends a Registration Request 385 message to the local server. The local server replies with a 386 Registration Reply message. This message contains a parent 387 care-of address which usually is the IP address of a care-of 388 agent that has been assigned to provide forwarding service for 389 the visiting mobile node. One can consider this care-of agent as 390 the local home agent in terms of forwarding. Note that if the local 391 registration server happens to be the home agent or 392 the Home Registration Server of the mobile node, then usually the 393 care-of agent assigned will be the home agent of the mobile node. 395 The local server may request the assigned care-of agent to enable the 396 binding route via an exchange of Route Request and Route Reply 397 messages with the care-of agent. Thereafter, packets from any node 398 within the local routing domain may be able to reach the mobile node. 399 This may additionally require changes to relevant intra-domain 400 routing protocols, which is beyond the scope of this document. 402 For any registration, we require that a care-of address, called the 403 parent care-of address, be returned to the mobile node by 404 means of the registration reply. 406 2.3 Home Registrations 408 If the parent care-of address obtained via local registration is not 409 the same as the address of the mobile node's home agent, and the 410 parent care-of address is also different from that obtained 411 previously, then, the mobile node should perform home registrations. 412 The mobile node builds a new mobility binding using this parent 413 care-of address by registering this binding with its home 414 registration server, via the local server. The mobile node does so 415 via an exchange of Registration Request and Registration Reply 416 message with the home server. 418 In this home registration, the parent care-of address obtained 419 through a previous local registration becomes the child care-of 420 address. The care-of address returned from the home registration 421 server is a new parent care-of address which usually is the address 422 of the mobile node's home agent. In this manner, a complete 423 registration is performed among the mobile node, the foreign agent, 424 the local server, the home server and the home agent. 426 The home server may request the home agent to enable the binding 427 route, that is, to build a tunnel from the new parent care-of 428 address (the home agent's address) to the child care-of address 429 (a care-of agent's address at the visiting domain) via an exchange 430 of Route Request and Route Reply messages. 432 2.4 Transit Registrations 434 There are two scenarios where transit registrations may be used. 435 Type 1 Transit Registrations are used when the mobile node moves 436 from one routing domain to another and has a valid mobility binding 437 with a previous foreign server. In this case, the mobile node may 438 issue a transit registration request to that previous foreign 439 server to enable a binding route from the previous parent care-of 440 address to the current one. 442 Such a mobility binding is transitional and helps to ensure that data 443 that has been delivered to the previous parent care-of address can be 444 forwarded to the new parent care-of address. This transitional 445 binding can be removed once the mobile node has completed its 446 registration of the new parent care-of address with the home 447 registration server. 449 Type 2 Transit Registrations are used when a foreign server in the 450 visiting domain has no security association with the home server. In 451 this case, the mobile node may register, via the local server, the 452 local parent care-of address with a transit registration server, 453 which in turn allocates a new parent care-of address to the mobile 454 node. The mobile node then registers, via the transit server, this 455 new parent care-of address with the home server. It is expected 456 that the mobile node has security association with the transit 457 registration server. 459 2.5 Datagram Routing 461 Through a series of local, transit and home registrations, the mobile 462 node obtains a path from the home agent to the foreign agent. The 463 path consists of a sequence of tunnels with the starting point of the 464 first tunnel being the home agent, and the termination point of the 465 last tunnel being the foreign agent, and each of the tunnels begins 466 with a parent care-of address and ends with a child care-of address. 468 Datagrams sent to the mobile node's home address are intercepted 469 by its home agent, tunnelled from one care-of agent to another until 470 they reach the foreign agent, and finally being delivered to the 471 mobile node by the foreign agent. 473 These tunnels fall into three categories: home tunnels, transit 474 tunnels, and local tunnels. A home tunnel begins with a home agent or 475 a care-of agent allocated by a home registration server, and ends 476 with a care-of agent allocated by another registration server. A 477 transit tunnel begins with a care-of agent allocated by a transit 478 registration server and ends with a care-of agent allocated by the 479 current visiting registration server. A local tunnel begins with a 480 care-of agent allocated by the current visiting registration server 481 and ends at the foreign agent. Each of these tunnels is authorised by 482 two registration servers or by a registration server and a mobility 483 agent. 485 In the reverse direction, datagrams sent by the mobile node are 486 generally delivered to their destination using standard IP routing 487 mechanisms, not necessarily passing through the care-of agents, the 488 home or foreign agent. 490 2.6 Local/Home Service 492 In some cases, the mobile node may just be interested in 493 communicating with the hosts in its visiting domain but not 494 interested in having home traffic forwarded to its visiting 495 location. For such scenarios, if the visiting network has 496 pre-arrangement with the mobile node's home registration server 497 to provide local services to mobile nodes that belong to that 498 home registration server, then the mobile node only needs to 499 perform local registration. 501 2.7 Foreign Server Smooth Handoffs 503 When a mobile node moves and discovers that the local 504 registration server does not change, then it only needs to 505 perform a local registration. 507 When a mobile node moves and discovers that the local 508 registration server has changed, then it not only performs 509 a local registration, it also performs a home registration. 510 As in the route optimization draft [6], a Previous Foreign Server 511 Notification option can be implemented so that the new foreign 512 server can notify the old foreign server about the mobile node's 513 new mobility binding. This notification can be used by the 514 previous server to tear down existing tunnels. Such notification 515 also allows any datagrams that have been delivered to the 516 previous care-of agent to be delivered to the new care-of agent. 518 If the new foreign registration server does not have a security 519 association with the home registration server, then all 3 types 520 of registrations, namely local, transit and home registrations 521 have to be performed. 523 2.8 Optimizing Registrations 525 In earlier sections, we describe how DREMIP supports local, 526 transit and home registrations. In this section, we elaborate 527 a bit on how a mobile node can combine both the local and home 528 registrations within one Registration Request message. 530 A mobile node who wishes to make a local and home registrations 531 can send a Registration Request message with a registration 532 server extension. The binding registrar in the Registration 533 Request message will be the local server and a MN/Local Server 534 authentication extension can be appended. The Home Registration 535 Server identity is contained in the Registration 536 Server Extension. The Mobile Node can also attach the MN/Home 537 Server Extension at the back of the Registration Server 538 Extension. 540 We refer the readers to Appendix D.3 for more details on such 541 registration optimizations. 543 In addition, it is a requirement in DREMIP that the following 544 inequality holds for local, home and transit registration 545 lifetimes: 547 Local Registration LifeTimes <= Transit Registration LifeTimes 548 <= Home Registration LifeTimes 550 Note also that the lifetimes of the different tunnels: local, 551 transit and home tunnels can be set according to the local, 552 transit and home registration lifetimes respsectively. If 553 the Previous Foreign Agent Notification feature is implemented, 554 then the tunnel lifetimes can be set to infinity and the 555 deregistration message can be used to tear down the tunnel. 557 2.9 Interoperability with the Base Protocol 559 To make the this protocol compatible with the base protocol, a few 560 requirements apply to the mobile node, foreign agent and home agent. 562 Upon receipt of an Agent Advertisement message without registration 563 server extension, the mobile node should be able to register with a 564 home agent via the foreign agent as in the base protocol. In this 565 case, the mobile node should not check for the presence of any 566 care-of address extension in the Registration Reply. 567 In addition, the Registration Request should be sent as a Home 568 Registration Request. The binding registrar address field should be 569 the home registration server address or the home agent address. If 570 there is no security association between the mobile node and the home 571 agent, but there exists one between the mobile node and the home 572 server, then the Registration Request should be directed to the home 573 server. 575 A home or foreign agent should check the R-bit in the Registration 576 Request message to determine whether the mobile node is supported by 577 this protocol. A foreign agent, upon receipt of a Registration 578 Request with R-Bit cleared, should not require that there be a 579 mobile-foreign authentication extension in the request and a 580 foreign-home authentication extension in the further reply message. 582 In Appendix D.4, we give two example scenarios and explain in 583 greater details how a mobile node without DREMIP feature can use 584 the Mobile-IP service in a DREMIP network and how a mobile node 585 with DREMIP feature can use the Mobile-IP service in a 586 RFC2002-compliant foreign network. 588 3. Message Formats 590 3.1 Agent Advertisement 592 The Agent Advertisement messages additionally include a registration 593 server extension, which contains one or more registration server 594 addresses. Thus, the mobile node can be informed of the registration 595 server addresses and register its mobility binding with one of them. 597 3.2. Registration Request 599 One bit is added to the Registration Request message to indicate the 600 registration is supported by this distributed registration extension 601 protocol. The IP and UDP fields of the Registration Request message 602 is the same as described in RFC2002. The UDP header is followed by 603 the Mobile IP fields shown below: 605 0 1 2 3 606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type |S|B|D|M|G|V|R|r| Lifetime | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Home Address | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Binding Registrar | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Care-of Address | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 + Identification + 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Extensions ... 621 +-+-+-+-+-+-+-+- 623 distributed Registration extension (R): 625 The R-bit is set by a mobile node or a binding registrar to 626 indicate that the procedure is supported by this registration 627 extension protocol. This bit is for the purpose of 628 interoperability with the base protocol. 630 Reserved (r): 632 The r-bit should be set to 0. 634 Binding Registrar: 636 A home agent or a registration server. 638 3.3. Registration Reply 640 There is no change in the format of the Registration Reply message 641 except that, the "Home Agent" field is renamed to "Binding Registrar" 642 field. 644 In addition to a few authentication extensions, the Registration 645 Reply MUST include a care-of address extension so that a 646 registration server can allocate a parent care-of address to the 647 mobile node. The Registration Reply MAY additionally appends a 648 registration server extension to advise the mobile node to choose a 649 registration server address as the next binding registrar. 651 3.4. Route Request Message 653 Route Request is sent by a registration server to a care-of 654 agent to enable a binding route between the care-of agent and a 655 child care-of address of a registration. 657 IP fields: 659 Source Address Typically the interface address from which 660 the message is sent. 662 Destination Address Typically the IP address of the care-of 663 agent. 665 UDP fields: 667 Source Port 669 Destination Port 434 671 The UDP header is followed by the fields shown below: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Type | Reserved | Lifetime | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Destination Address | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Next Hop Address | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | | 683 + Identification + 684 | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Extensions ... 687 +-+-+-+-+-+-+-+- 689 Type 32 (Route Request) 691 Reserved sent as zero; ignored on reception. 693 Lifetime 694 The number of seconds remaining before the route is 695 considered expired. A value of zero indicates a request 696 for disabling. A value of 0xffff indicates infinity. 698 Destination Address 699 The home address of the mobile node. 701 Next Hop Address 702 The child care-of address of a registration 704 Identification 705 A 64-bit number, constructed by the server, used for 706 matching Route Requests with Route Replies, and for 707 protecting against replay attacks of these messages. 709 Extensions 710 The fixed portion of the Route Request is followed 711 by one or more of the Extensions. 713 3.5. Route Reply Message 715 The care-of agent returns a Route Reply message to the server which 716 has sent a Route Request (Section 3.4) message. The Reply message 717 contains the necessary codes to inform the server about the status 718 of its request, along with the lifetime granted by the care-of 719 agent, which MAY be smaller than the original Request. 721 IP fields: 723 Source Address Typically copied from the destination 724 address of the Route Request to which 725 the care-of agent is replying. 727 Destination Address Copied from the source address of the 728 Route Request to which the care-of agent 729 is replying 731 UDP fields: 733 Source Port 735 Destination Port Copied from the source port of the 736 corresponding Route Request 738 The UDP header is followed by the fields shown below: 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type | Code | Lifetime | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Destination Address | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Next Hop Address | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | | 750 + Identification + 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Extensions ... 754 +-+-+-+-+-+-+-+- 756 Type 33 (Route Reply) 758 Code A value indicating the result of the Route Request. 759 See below for a list of currently defined Code values. 761 Lifetime 762 If the Code field indicates that the care-of agent agrees 763 to add the route capability, the Lifetime field is set to 764 the number of seconds remaining before the route is 765 considered expired. A value of zero indicates that the 766 route has been disabled. A value of 0xffff indicates 767 infinity. 769 If the Code field indicates that the route was denied, 770 the contents of the Lifetime field are unspecified and 771 MUST be ignored on reception. 773 Destination Address 774 The home address of the mobile node. 776 Next Hop Address 777 The child care-of address of a registration 779 Identification 780 A 64-bit number used for matching Route Requests with 781 Route Replies, and for protecting against replay attacks 782 of tunnel messages. The value is based on the 783 Identification field from the Route Request message from 784 the client. 786 Extensions 787 The fixed portion of the Route Reply is followed by one 788 or more of the Extensions. 790 The following values are defined for use within the Code field. 792 0 route added 794 64 reason unspecified 795 65 administratively prohibited 796 67 server failed authentication 797 68 requested Lifetime too long 798 69 poorly formed message 800 Up-to-date values of the Code field are specified in the most recent 801 "Assigned Numbers" [5]. 803 4. Newly Defined Extensions 805 4.1. Registration Server Extension 807 This extension is placed in the Agent Advertisement message or 808 Registration Reply message, and is used to provide the mobile node 809 with addresses of a collection of available registration servers. 810 Note that we have included a priority level for different 811 registration servers. One can use this priority level to provide 812 hierarchical registrations or as an congestion-level indicator to 813 prevent mobile nodes from registering with an overloaded 814 registration server. 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Type | Length | Lifetime | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Registration Server Address | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Priority | Lifetime | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Registration Server Address | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Priority | Lifetime | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | . | 830 | . | 831 | . | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Type 81 836 Length 2 + 8 * number of registration server addresses 838 Lifetime 839 The number of seconds remaining before the registration 840 server is considered invalid. A value of zero indicates 841 the registration server doesn't provide service to more 842 mobile nodes. A value of 0xffff indicates infinity. 844 Priority 845 The level of authorization. 847 4.2. Care-of Address Extension 849 This extension is placed in the Registration Reply so that a 850 registration server can allocate a care-of address to the mobile 851 node. 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Type | Length | Reserved | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | care-of address | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Type 82 863 Length 6 865 Reserved 0 867 care-of address 868 parent care-of address or home agent address 869 4.3. Agent-Server Authentication Extension 871 This extension is included in the Registration Request and 872 Registration Reply messages between the foreign agent and the foreign 873 registration server, and between the home agent and the home 874 registration server. The protcol here requires that there exists a 875 security association between an agent and a registration server in 876 the same routing domain. 878 The extension MUST also be included in the Route Request and Route 879 Reply messages between a registration server and a care-of agent. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type | Length | SPI .... 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 ... SPI (cont.) | Authenticator ... 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Type 83 891 Length 4 plus the number of bytes in the Authenticator. 893 SPI Security Parameter Index (4 bytes). An opaque identifier 895 Authenticator 896 (variable length) 898 4.4. Mobile-Server Authentication Extension 900 This extension is included in the Registration Request and 901 Registration Reply messages between the mobile node and the foreign 902 registration server, and between the mobile node and the home 903 registration server. The protocol here requires that there exists a 904 security association between a mobile node and a registration server 905 whether they are in the same routing domain or not. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | SPI .... 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 ... SPI (cont.) | Authenticator ... 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Type 84 917 Length 4 plus the number of bytes in the Authenticator. 919 SPI Security Parameter Index (4 bytes). An opaque identifier 921 Authenticator 922 (variable length) 924 4.5. Server-Server Authentication Extension 926 This extension is included in the Registration Request and 927 Registration Reply messages between two registration servers, 928 especially between the foreign registration server and the home 929 registration server. The protocol here requires that there exists a 930 security association between two registration servers whether they 931 are in the same routing domain or not. 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Type | Length | SPI .... 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 ... SPI (cont.) | Authenticator ... 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Type 85 943 Length 4 plus the number of bytes in the Authenticator 945 SPI Security Parameter Index (4 bytes). An opaque identifier 947 Authenticator 948 (variable length) 950 5. Care-of Agent Considerations 952 The care-of agent could be an OSPF area border router, an autonomous 953 system border router or a backbone router. In the base Mobile-IP 954 protocol, the care-of address was originally associated with a 955 foreign agent and a foreign agent has the responsibility of 956 forwarding the traffic destined to the mobile node. In this 957 registration extension protocol, the care-of agent is designed to 958 forward traffic destined to the mobile node. 960 5.1. Receiving Route Request 962 Upon receipt of a Route Request, the care-of agent MUST check the 963 validity of the message. The request is valid if 965 - the UDP checksum is valid; AND 967 - the message MUST include an Agent-Server Authentication extension at 968 the end and the Authenticator is valid. 970 An invalid request SHOULD be discarded and an error SHOULD be logged. 972 On receipt of a valid Route Request message, the care-of agent SHOULD 973 respond with a Route Reply with the lower 32-bit identification 974 copied from the original request. 976 If the care-of agent is not able to honor the request, it SHOULD put 977 a proper code in the reply. 979 If the care-of agent denies the request and disable the binding route 980 to the child care-of address, it SHOULD set the code to a positive 981 value (0) and the lifetime to 0. 983 Otherwise, if the care-of agent agrees to enable a binding route to 984 the child care-of address, it SHOULD set the code to a positive value 985 (0) and the lifetime to a value not greater than that in the original 986 Request. The binding route is valid within the granted lifetime and 987 SHOULD be disabled upon its expiry. 989 5.2. Binding Route Enable/Disable 991 In general, a care-of agent MAY enable or disable a binding route 992 using tunneling mechanism ([4]). Within a routing domain, however, 993 the care-of agent MAY take advantage of underlying routing protocols 994 instead. This approach may be discussed elsewhere. In this document, 995 we assume a care-of agent uses the tunneling mechanism. 997 To enable a binding route, the care-of agent MAY first build a tunnel 998 to the next hop address specified in the Route Request message if 999 such a tunnel does not exist previously. The care-of agent then 1000 installs in its forwarding cache an entry with the tunnel as the 1001 outgoing circuit. To disable the registration delivery, the care-of 1002 agent can simply remove the entry from its forwarding cache. If there 1003 is no entry associated with the tunnel, the care-of agent SHOULD 1004 additionally remove this tunnel. 1006 6. Registration Server Considerations 1008 A registration server MAY not be a router. It is designed to be 1009 independent of the forwarding path for mobile traffic, and to monitor 1010 and switch the forwarding path. A registration server performs local 1011 registrations at most times but less frequently does home and transit 1012 registrations. 1014 The local registration is used to establish the local mobility 1015 binding of a mobile node, that is, the association of the mobile node 1016 with a local registration server, a foreign agent, and the lifetime 1017 of this association. The local mobility binding MAY create the mobile 1018 node's connectivity to the local routing domain. 1020 The local registration server, taking the advantage of the above 1021 local mobility binding, then establishes a home mobility binding, 1022 that is, the association of the mobile node with the home agent or 1023 the home registration server of the mobile node, the local 1024 registration server, and the lifetime of the association. 1026 The registration server MAY be configured with one or more care-of 1027 agent addresses, which are allocated to mobile nodes such that 1028 traffic load can be balanced. 1030 6.1. Data Structure 1032 For each registration server and each visiting mobile node, there are 1033 generally two registrations: one where the registration server acts 1034 as the binding registrar and the other where the registration server 1035 acts as a binding relay. Each registration creates an entry in the 1036 registration server cache. Since the mobile node may perform mutiple 1037 registrations (home and/or transit) based on an existing local 1038 registration, a registration server SHOULD NOT merge the two entries 1039 into one. The entry created by a local registration where the 1040 registration server is the binding registrar consists of 1042 - mobile node's home address 1043 - child care-of address and 1044 - parent care-of address 1045 - lifetime, and 1046 - the forwarding status over the tunnel between parent and child 1047 care-of address. 1049 Each entry created by the home or transit registration where the 1050 registration server is the binding relay should have a pointer to the 1051 above entry, and additionally includes 1053 - binding registrar, and - lifetime 1055 6.2. Receiving Registration Request as a Binding Registrar 1057 Upon receiving a valid registration request where the registration 1058 server is the binding registrar, the server should check if the 1059 mobile node is previously associated with any care-of agent. If it is 1060 not, the server should choose a parent care-of address. The server 1061 SHOULD exchange a pair of Route Request and Route Reply with the 1062 relevant care-of agent in order for the care-of agent to enable a 1063 binding route for the lifetime requested by the mobile node. The 1064 server SHOULD NOT return Registration Request to the mobile node 1065 until it receives a Route Reply from the care-of agent. 1067 After the server receives a positive Route Reply from the care-of 1068 agent, the server will verify that the tunnel lifetime is 1069 consistent with the registration life time. Then, the server SHOULD 1070 send a positive Registration Reply to the mobile node if there is a 1071 security association between itself and the mobile node. The server 1072 SHOULD deny this request by sending a negative Registration Reply to 1073 the mobile node. In this case, the server SHOULD additionally ask 1074 the care-of agent to disable the binding 1075 route by exchange of negative Route Request and Route Reply. 1077 For this case, if the registration server previously does not have 1078 a mobility binding yet with the mobile node, it SHOULD allocate a 1079 parent care-of address, put it in a care-of address extension, and 1080 append the extension to the Registration Reply. However, if the 1081 registration server has a binding with the mobile node previously, 1082 the old care-of address SHOULD be put in that extension. This 1083 ensures that the mobile node can obtain the same parent care-of 1084 address if repeatedly registering with the registration server. 1086 The registration server MAY include a registration server extension 1087 in the Registration Reply message for the mobile node to perform 1088 further transit/home registrations. 1090 The registration server SHOULD include an agent-server or server- 1091 server authentication extension in the reply if the binding relay 1092 is the foreign agent or another registration server, respectively. 1094 If there is no tunnel currently between the parent and child care-of 1095 address, the registration server SHOULD direct the care-of agent, by 1096 issuing a Route Request message, to build a tunnel from the parent 1097 care-of address to the child care-of address of the mobile node. The 1098 child care-of address is specified in the Registration Request while 1099 the parent care-of address is allocated by the binding registrar. 1101 If the registration server is a home server, the parent care-of 1102 address it allocates MAY be the home agent address. In this case, 1103 the care-of agent is the home agent. 1105 6.3. Receiving Registration Request as a Binding Relay 1107 Upon receiving a valid registration request where the registration 1108 server is the binding relay, the registration server MUST verify 1109 that there is already an entry for this mobile node where it acts as 1110 a binding registrar. If not, the Registration Request MUST deny this 1111 request. The registration server SHOULD also verify that there is a 1112 security association between itself and the binding registrar. If 1113 not, the server SHOULD deny this request. The binding lifetime SHOULD 1115 not be greater than the one with the current mobility binding where 1116 the registration server acts as a binding registrar. Otherwise, the 1117 server SHOULD deny this request. 1119 If the Registration Request message meets all the requirements above, 1120 the registration server MAY relay this request to the binding 1121 registrar in the same way as the foreign agent deals with the 1122 Registration Request in the base protocol. 1124 The registration server MAY deny the request and include a 1125 registration server extension for the mobile node to perform 1126 a transit registration with another server. The mobile node 1127 can then perform further home registration via this transit 1128 server. 1130 The registration server SHOULD include a server-server authentication 1132 extension in the request to be relayed, or a mobile-server 1133 authentication extension in the reply if the server denies the 1134 request above. 1136 6.4. Sending Route Request 1138 To ensure the care-of agent can forward traffic to the mobile node, 1139 the server SHOULD send a Route Request to the care-of agent. The 1140 server SHOULD copy lifetime from the Registration Request to the 1141 Route Request. 1143 The server SHOULD retransmit Route Request if it has not received a 1144 matched Route Reply in a reasonable time. Failure in receipt of such 1145 a Route Reply message after a maximum of retransmissions SHOULD be 1146 logged for further administrative option. The server MAY choose 1147 another care-of agent and repeat the procedure above until no 1148 care-of agent is available. In this case, the server SHOULD send a 1149 negative Registration Reply to the mobile node. 1151 The server MUST append an Agent-Server Authentication extension to 1152 the Route Request message. The SOMIP model requires that there be a 1153 security association between the server and the care-of agent. 1155 6.5. Receiving Route Reply 1157 Upon receipt of a Route Reply, the server MUST check the validity of 1158 the message. The reply is valid if 1160 - the UDP checksum is valid; 1162 - the low-order 32 bits of the Identification field in the Route 1163 Reply equals to the low-order 32 bits of the Identification field 1164 in the most recent Route Request sent to the care-of agent; AND 1166 - the reply MUST include a Agent-Server Authentication extension. 1168 If the code field is negative or the lifetime is zero, the server 1169 MUST send a Registration Reply message with a negative code or 1170 lifetime set to 0. 1172 Otherwise, the server must check for consistency between the 1173 tunnel life time and the registration lifetime. If no previous 1174 agent notification feature is implemented, then the tunnel life 1175 time should not exceed the remaining registration life time. 1176 Otherwise, it may be allowed to exceed to reduce the bandwidth 1177 overhead required in refreshing tunnel lifetimes. 1179 6.6. Load Balancing 1181 Each registration server occasionally probes their care-of agents on 1182 the traffic load that each of them is supporting. The care-of agents 1183 each return a metric that has a higher value when the traffic load is 1185 higher. Based on such replies, the server can order the list of 1186 care-of addresses with the least loaded one being at the top of the 1187 list. When the server receives a local registration request, it 1188 assigns the least loaded care-of address to that request. 1190 7. Mobility Agent Considerations 1192 7.1 Sending Agent Advertisement 1194 A mobility agent SHOULD include a registration server extension in 1195 the Agent Advertisements. This can facilitate the mobile node in 1196 finding a registration server with whom it has security association 1197 for subsequent registrations. 1199 7.2. Receiving Registration Request As a Foreign Agent 1201 Upon receiving a Registration Request, a foreign agent SHOULD verify 1202 that there is a security association between itself and the binding 1203 registrar. If there is, the agent works exactly the same as the 1204 foreign agent in the base protocol. 1206 Otherwise, the agent SHOULD deny the Registration Request. The agent 1207 MAY include a registration server extension in the Registration Reply 1209 message for the mobile node to choose another binding registrar and 1210 to perform further registrations. 1212 7.3. Receiving Registration Request as a Home Agent 1214 The home agent deals with a received Registration Request in the same 1216 way as the home agent in the base protocol. 1218 7.4. Receiving Registration Reply 1220 The mobility agent deals with a received Registration Reply in the 1221 same way as in the base protocol. 1223 7.5. Receiving Route Request 1225 The foreign agent SHOULD disregard this message. 1227 The home agent SHOULD deal with the Route Request in the same way as 1228 the care-of agent. The home agent SHOULD additionally send proxy ARP 1229 and gratuitous ARP on the home network. The procedure SHOULD be the 1230 same as in the base protocol. 1232 8. Mobile Node Considerations 1234 8.1. Receiving Agent Advertisement 1236 When a mobile node receives an agent advertisement, it SHOULD check 1237 to see if the mobility agent is its home agent. If it is, it does 1238 nothing since it is at home. Otherwise, it checks to see if there is 1239 a registration server extension in the agent advertisement. If yes, 1240 the mobile node SHOULD choose one of the registration servers whose 1241 addresses appear in the registration server extension and perform a 1242 local registration with the selected server. Note that if the 1243 mobile node is in its home domain i.e. the home registration 1244 server appears in the registration server extension, then the 1245 mobile node SHOULD choose its home registration server. 1247 8.2 Sending Registration Request 1249 The mobile node SHOULD choose a proper binding relay and a binding 1250 registrar from previously received Agent Advertisement messages. 1251 For local registrations, the binding relay is the foreign agent, and 1252 the binding registrar is one of the local registration servers whose 1253 addresses appear in the registration server extension. Note that 1254 if the mobile node is in its home domain, then the binding 1255 registrar that the mobile node chooses SHOULD be its home 1256 registration server. 1258 For the case where the mobile node is visiting a foreign network, 1259 the mobile node will use the local registration 1260 server as the binding relay and the home registration server as 1261 the binding registrar in the mobile node's home registration 1262 request. 1264 For transit registrations, the binding registrar is a registration 1265 server with whom the mobile node has previously established a 1266 mobility binding or with whom the mobile node has a security 1267 association, while the binding relay could be a foreign agent or 1268 another registration server. 1270 If the mobile node previously receives a negative Registration Reply, 1271 which includes a registration server extension, it SHOULD choose a 1272 proper binding registrar to proceed further registration. 1274 The mobile node SHOULD include a mobile-server authentication 1275 extension in the request if the binding relay is a registration 1276 server. 1278 8.3 Receiving Registration Reply 1280 Upon receiving a valid local registration reply, the mobile node 1281 SHOULD check to see if the binding registrar or the parent care-of 1282 address returned in the reply is its home agent. If yes, this is a 1283 complete registration. If it is not, however, the mobile node SHOULD 1284 check to see if it has previously established a mobility binding with 1285 its home registration server or home agent, using this parent care-of 1286 address. 1288 If it has, nothing needs to be done since the mobile node just 1289 changes its point of attachment locally. Otherwise, the mobile node 1290 SHOULD perform a home registration using this parent care-of address. 1291 In this second registration, the local server will be used as the 1292 binding relay and the binding registrar will be set to the home 1293 registration server's address. The mobile node SHOULD make sure 1294 that the home registration life time exceeds the local 1295 registration life time. 1297 If the reply includes a registration server extension, it means the 1298 the binding registrar advises the mobile node to perform further 1299 registration with one of the registration servers in the extension. 1300 In this case, the mobile node SHOULD choose one of them and proceed 1301 with a registration with the local server set to the binding relay, 1302 and the selected registration server set to the binding registrar. 1303 Again, the mobile node SHOULD make sure that the transit 1304 registration life time exceeds the local registration lifetime. 1305 Later, if the mobile node needs to perform home registration, the 1306 mobile node SHOULD make sure that the home registration lifetime 1307 exceeds the transit registration lifetime. 1309 8.4. Handoff 1311 When a mobile node moves from one foreign routing domain to another, 1312 the mobile node performs a local registration with the new local 1313 server. Then, it can first do a transit registration with its 1314 previous foreign registration server such that a tunnel can be built 1315 from the previous foreign server's care-of address to the new local 1316 server's care-of address. This tunnel is a transitional tunnel that 1317 enables the forwarding of packets that have been sent to the previous 1319 foreign server but have not been delivered to the mobile node. Later, 1321 it performs a home registration with its home registration server 1322 using the new local server's care of address. After establishing a 1323 complete binding with the home registration server, the transitional 1324 tunnel can be torn down. 1326 Appendix A Registration Server Discovery Procedures 1328 Here, we describe a procedure for mobility agents to discover the 1329 registration servers. We assume that a multicast address has been 1330 assigned to all registration servers. A mobility agent merely needs 1331 to send a Neighbor Request message to the multicast address of the 1332 registration servers. All registration servers that can hear this 1333 Neighbor Request message will respond with a unicast Neighbor Reply 1334 message. The Neighbor Reply message contains a priority level 1335 field. The mobility agent then puts the addresses of all 1336 registration servers and their associated priority levels in the 1337 Agent Advertisement messages that it broadcasts. 1338 The Neighbor Request message can be repeated periodically with 1339 a period long enough to limit the overhead bandwidth consumption. 1340 Details of this registration server discovery procedure will be 1341 provided in another upcoming internet draft. 1343 Appendix B Care-of Agent Discovery Procedures 1345 In practice, we may just manually configure care-of agents. 1346 However, when there are a lot of care-of agents available and 1347 more than one registration servers exist, we may want a more dynamic 1348 assignment of care-of agents to registration servers. 1349 Here, we describe a procedure for registration servers to discover 1350 the presence of care-of agents in its vicinity. Again, we assume 1351 that a multicast address is defined for registration server and 1352 all care-of agents in a routing domain. The registration server 1353 can send a Care-of Agent Solicit message to that multicast 1354 address. All care-of agents that can hear this Care-of Agent 1355 Solicit message will have to respond to the Registration Server 1356 with a unicast Care-of Agent Advertisement message. 1358 Appendix C Key Distribution between Registration Servers 1360 We assume that all cooperating registration servers share a public 1361 key and has a private key. We can use the same approach discussed in 1362 [6]. 1364 Appendix D Example Scenarios 1366 This section shows example Registration Requests for several common 1367 scenarios. 1369 D.1 Local/Home Registrations 1370 D.1.1 Local Registration 1371 The mobile node receives an Agent Advertisement from a foreign agent 1372 which has a registration server extension showing RS2 as the local 1373 registration server. Assume that the mobile node has a security 1374 association with RS2. The mobile node wishes to register with that 1375 agent using the advertised foreign agent care-of address. The mobile 1376 node wishes only IP-in-IP encapsulation, does not want broadcasts, 1377 does not want simultaneous mobility bindings: 1379 IP fields: 1380 Source Address = mobile node's home address 1381 Destination Address = copied from IP source address of the 1382 Agent Advertisement 1383 Time to Live = 1 (?) 1384 UDP fields: 1385 Source Port = 1386 Destination Port = 434 1387 Registration Request fields: 1388 Type = 1 1389 S=0, B=0, D=0, M=0,G=0, R=1 1390 Lifetime= the Registration Lifetime copied from the Mobility 1391 Agent Advertisement Extension of the Router Advertisement 1392 message 1393 Home Address = the mobile node's home address 1394 Binding Registrar = IP address of RS2 copied from Registration 1395 Server extension 1396 Care-of Address = the Care-of Address copied from the Mobility 1397 Agent Advertisement Extension of the Router Advertisement 1398 message 1399 Identification = Network Time Protocol timestamp or Nonce 1400 Extensions: 1401 The Mobile-Foreign(RS2) Authentication Extension 1402 The Mobile-Agent Authentication Extension (?) 1404 The foreign agent will relay the Registration Request to RS2. 1405 The mobile node upon hearing a positive registration reply from 1406 RS2 (which is relayed by the foreign agent) will copy the parent 1407 care-of address (COA1) allocated from the Care-of Address Extension 1408 in the Registration Reply. The mobile node will create an 1409 entry to record the local registration server's IP address, the 1410 parent care-of address, and the local registration life time. 1412 If we allow for local service and that the foreign network prefers a 1413 tunnel to be built between the care-of agent and the foreign agent 1414 for routing mobile node's traffic packets, then RS2 will direct the 1415 care-of agent whose IP address is the parent care-of address (COA1) to 1416 build a tunnel to the foreign agent. 1418 D.1.2 Home Registration 1419 Then, the mobile node will send another Registration Request 1420 IP fields: 1421 Source Address = mobile node's home address 1422 Destination Address = RS2's IP address 1423 Time to Live = 1 (?) 1424 UDP fields: 1425 Source Port = 1426 Destination Port = 434 1427 Registration Request fields: 1428 Type = 1 1429 S=0, B=0, D=0, M=0,G=0, R=1 1430 Lifetime= Oxffff 1431 Home Address = the mobile node's home address 1432 Binding Registrar = MN's Home Server (RS1) 's IP address 1433 Care-of Address = the allocated parent care-of address extracted 1434 from the Care-of Address extension in the Local Registration 1435 Reply. 1436 Identification = Network Time Protocol timestamp or Nonce 1437 Extensions: 1438 The Mobile-Home (RS1) Authentication Extension 1439 The Mobile-Foreign(RS2) Authentication Extension 1441 The local server, RS2, will relay the Home Registration Request to the 1442 MN's Home Server (RS1) by adding the Server (RS2)-Server (RS1) 1443 Authentication Extension. The MN's Home Server will check for the 1444 validity of the Registration Request and sends a Registration Reply 1445 via the local server to the mobile node. The Registration Reply will 1446 contain the MN/Home Server Authentication Extension and the 1447 Server/Server Authentication Extension. If the Home Server approves the 1448 home registration, then the Home Registration Reply 1449 will contain a Care-of Address extension that gives the home agent's 1450 IP address as the parent care-of address. The Home Server 1451 will direct the home agent to build a tunnel to COA1. The Home 1452 Server does so by sending a Route Request Message with Server/Agent 1453 Authentication Extension (if the Home Server does not trust the Home 1454 D.2 Transit/Home Registration 1455 D.2.1 Transit Registration 1456 Assume that RS2 does not have any server/server authentication with 1457 RS1 in Example D.1.2 above. Then, RS2 will reject the Home 1458 Registration Request and attaches a Registration Server Extension in 1459 its reply: 1461 Registration Reply from RS2 will be as follows: 1462 IP fields: 1464 Source Address = copied from destination address of the 1465 Registration Request to which RS2 is replying 1466 Destination Address = copied from the source address of the 1467 Registration Request to which RS2 is replying 1469 UDP fields: 1470 Source Port = 1471 Destination Port = 434 1473 Registration Request fields: 1474 Type = 3 1475 Code = 67 1476 Lifetime= ignored 1477 Home Address = the mobile node's home address 1478 Binding Registrar = MN's Home Server (RS1) 's IP address 1479 Identification = copied from Registration Request message 1481 Extensions: 1482 Registration Server Extension which gives RS3 as the 1483 transit registration server. 1484 The Mobile-Home (RS1) Authentication Extension 1485 The Mobile-Foreign(RS2) Authentication Extension 1486 The mobile node will then send a Registration Request with 1487 RS3 as the binding registrar. 1488 IP fields: 1489 Source Address = mobile node's home address 1490 Destination Address = RS2's IP address 1491 Time to Live = 1 (?) 1492 UDP fields: 1493 Source Port = 1494 Destination Port = 434 1495 Registration Request fields: 1496 Type = 1 1497 S=0, B=0, D=0, M=0,G=0, R=1 1498 Lifetime= Oxffff 1499 Home Address = the mobile node's home address 1500 Binding Registrar = RS3's IP address 1501 Care-of Address = the allocated parent care-of address extracted 1502 from the Care-of Address extension in the Local Registration 1503 Reply. 1504 Identification = Network Time Protocol timestamp or Nonce 1505 Extensions: 1506 The Mobile-Home (RS1) Authentication Extension 1507 The Mobile-Foreign(RS3) Authentication Extension 1508 The Mobile-Foreign(RS2) Authentication Extension 1510 The local server, RS2, will relay the Transit Registration Request to 1511 RS3. RS3 will validate the Registration Request and sends a 1512 Registration Reply to MN. If RS3 approves the transit registration, 1513 it will attach a Care-of Address extension which contains information 1514 on the new parent care-of address (COA2). 1516 D.2.2 Home Registration 1517 The mobile node then sends a Home Registration Request to its 1518 Home Server via RS3 1519 IP fields: 1520 Source Address = mobile node's home address 1521 Destination Address = RS3's IP address 1522 Time to Live = 1 (?) 1523 UDP fields: 1524 Source Port = 1525 Destination Port = 434 1526 Registration Request fields: 1527 Type = 1 1528 S=0, B=0, D=0, M=0,G=0, R=1 1529 Lifetime= Oxffff 1530 Home Address = the mobile node's home address 1531 Binding Registrar = MN's Home Server 1532 Care-of Address = the allocated parent care-of address, COA2 1533 extracted from the Care-of Address extension in the Transit 1534 Registration Reply. 1535 Identification = Network Time Protocol timestamp or Nonce 1536 Extensions: 1537 The Mobile-Home (RS1) Authentication Extension 1538 The Mobile-Foreign(RS3) Authentication Extension 1540 If the Home Server approves the registration, it will send 1541 a Registration Reply with an attached Care-of Address Registration 1542 that gives home agent address as the parent care-of address. 1543 The Home Server will also instruct the Home Agent to build a tunnel 1544 to COA2. When RS3 receives the Registration Reply, it will also 1545 instruct COA2 to build a tunnel to COA1. If local service is not 1546 provided by the local server, then we can let transit server 1547 notifies the local server upon successful home registration and the 1548 local server can then instruct COA1 to build a tunnel to the foreign 1549 agent. 1551 D.3 Optimizing Registrations 1552 Based on the examples described above, we describe in this section 1553 how the number of registrations can be reduced. 1555 D.3.1 Local/Home Registration 1556 With the requirement that the Agent Advertisement contains 1557 all registration servers' addresses that the local server has 1558 authentication with, a mobile node can decide if it can perform 1559 a home registration together with a local registration. 1560 If the mobile node finds its Home Server's address in the 1561 Agent Advertisement, it can send a Registration Request 1562 Message with an attached Registration Server Extension 1563 which contains the Home Server address and its life time. 1564 IP fields: 1565 Source Address = mobile node's home address 1566 Destination Address = foreign agent's IP address 1567 Time to Live = 1 (?) 1568 UDP fields: 1569 Source Port = 1570 Destination Port = 434 1571 Registration Request fields: 1572 Type = 1 1573 S=0, B=0, D=0, M=0,G=0, R=1 1574 Lifetime= LifeTime copied from Agent Advertisement 1575 Home Address = the mobile node's home address 1576 Binding Registrar = local server (RS2)'s IP address 1577 Care-of Address = foregin agent address 1578 Identification = Network Time Protocol timestamp or Nonce 1579 Extensions: 1580 The Registration Server Extension with Home Server 1581 information and Home Registration Lifetime 1582 The Mobile-Home (RS1) Authentication Extension 1583 The Mobile-Agent Authentication Extension(?) 1584 The Mobile-Foreign(RS2) Authentication Extension 1586 If the local server RS2 approves the registration, it will 1587 change the binding registrar to the Home Server's IP address 1588 (extracted from Registration Server Extension), replaces 1589 the Lifetime with Home Registration Lifetime, and change the care-of 1590 address to a newly allocated parent care-of address. Then, it relay 1591 this registration request message (without the registration server 1592 extension) to the Home Server. Upon receiving a reply from 1593 the Home Server, the local server formulates the following 1594 Registration Reply: 1596 IP fields: 1598 Source Address = copied from destination address of the 1599 Registration Request to which RS2 is replying 1600 Destination Address = copied from the source address of the 1601 Registration Request to which RS2 is replying 1603 UDP fields: 1604 Source Port = 1605 Destination Port = 434 1607 Registration Request fields: 1608 Type = 3 1609 Code = 1610 Lifetime= Local Registration LifeTime 1611 Home Address = the mobile node's home address 1612 Binding Registrar = RS2's IP address 1613 Identification = copied from Registration Request message 1615 Extensions: 1616 Registration Server Extension which gives Home Server's 1617 IP address as well as Home Registration LifeTime 1618 The Mobile-Home (RS1) Authentication Extension 1619 The Mobile-Foreign(RS2) Authentication Extension 1621 Similar optimizations can be done for the case of transit 1622 registrations. 1624 D.4 Interoperability with RFC2002 1626 D.4.1 Mobile Node with DREMIP feature in a RFC2002-compliant 1627 network 1629 Assume that MN1 which has DREMIP feature visits a foreign network 1630 that runs RFC2002-compliant base Mobile-IP protocol. MN1 receives 1631 an Agent Advertisement without Registration Server Extension. Hence, 1632 it issues a Registration Request Message with R bit cleared to its 1633 Home Agent/Home Registration Server via the Foreign Agent. The 1634 Registration Request Message will not have a Registration Server 1635 Extension. To the foreign agent, the binding registrar's field is 1636 like the Home Agent field in the base protocol. MN1 attaches the 1637 MN/Server or MN/Home Agent Authentication extension. If there exists 1638 authentication extension between MN1 and the Foreign Agent, 1639 MN1 will also attach that extension. The Foreign Agent will 1640 then deliver the Registration Request to the binding registrar 1641 which can either be the Home Registration Server or Home Agent. 1642 If the binding registrar is the Home Registration Server (HRS), then 1643 the HRS will issue a Registration Reply which has the MN's home 1644 address and its home agent address just like in base Mobile-IP 1645 protocol without attaching any Care-of Address extension. 1647 D.4.2 Mobile Node without DREMIP feature in a DREMIP compliant 1648 network 1650 The mobile node will ignore the registration server extension in the 1651 Agent Advertisement. The mobile node will issue a Registration 1652 Request with R bit cleared to the foreign agent. The Registration 1653 Request contains the MN's home address and MN's home agent address. 1654 The mobile node attaches the MN/Home Agent Authentication 1655 and the MN/Foreign Agent Authentication extensions. Note that here, 1656 we assume that unless there is a MN/Foreign Agent Authentication 1657 extensions, the mobile node cannot use the service in this foreign 1658 network. The foreign agent in the DREMIP network notices that the 1659 R-bit is clear and hence just relays the Registration Request message 1660 to the MN's Home Agent. The Home Agent issues a Registration Reply which 1661 doesn't contain Care-of-Address extension to the Foreign Agent. 1662 The Foreign Agent faithfully delivers the Registration Reply message 1663 to the mobile node. 1665 References 1667 [1] Charles Perkins, editor. IP mobility support. RFC 2002, Oct 1668 1996. 1670 [2] Charles Perkins. Mobile-IP Local Registration with 1671 Hierarchical Foreign Agents. Internet Draft, 1672 draft-perkins-mobileip-hierfa-00.txt, February 1996. Work in 1673 progress. 1675 [3] Charles Perkins. IP Encapsulation within IP. RFC 2003, 1676 October 1996. 1678 [4] David B. Johnson and Charles Perkins. Route Optimization in 1679 Mobile IP. Internet Draft, draft-ietf-mobileip-optim-04.txt, 1680 February 1996. Work in progress. 1682 [5] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 1683 October 1994. 1685 [6] J. Zao, etc. A Public-Key Based Secure Mobile IP, Proceedings 1686 of Mobicom97, October, 1997. 1688 [7] D. Johnson, etc. Route Optimizations in Mobile-IP networks 1689 Internet Draft. draft-optim-05.txt, October, 1997. Work in 1690 progress. 1692 Acknowledgement 1694 The authors wish to thank Week Tuck Teo from National University of 1695 Singapore for some useful comments on an earlier draft. 1697 Authors' Address 1699 Questions about this memo can also be directed to: 1701 M. C. Chuah, 1702 Performance Analysis Department, 1703 Room 3K-320, 1704 Bell Laboratories, 1705 Lucent Technologies, 1706 101, Crawfords Corner Road, 1707 Holmdel, NJ 07733, USA. 1708 Phone: 732-949-7206 1709 Fax: 732-834-5906 1710 Email: chuah@lucent.com 1712 Y. Li 1713 Protocol Development Group 1714 Engineering Department 1715 Bay Networks, Inc. 1716 BL60-304, 600 Technology Park Drive 1717 Billerica, MA 01821 1718 Phone: (508) 916-1130 1719 Fax: (508) 670-8760 1720 Email: yli@BayNetworks.COM