idnits 2.17.1 draft-oneill-ema-mip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2490 lines 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. ** The abstract seems to contain references ([MIPv4], [MIPv6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 374 has weird spacing: '...use its home ...' == Line 435 has weird spacing: '...izontal plane...' == Line 622 has weird spacing: '...ain and is...' == Line 873 has weird spacing: '...izontal ii. ...' == Line 991 has weird spacing: '...t could infor...' == (2 more instances...) -- 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 (July 2000) is 8684 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2002 (ref. 'MIPv4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 == Outdated reference: A later version (-04) exists of draft-ietf-manet-tora-spec-02 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 G. Tsirtsis 3 BT 4 Internet Draft S. Corson 5 Document: draft-oneill-ema-mip-00.txt Ansible Systems 6 Category: Informational July 2000 8 EMA Enhanced Mobile IPv6/IPv4 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 It is well recognised by all micro and macro-mobility routing 32 protocols that Mobile IP (MIP) is likely to be used to support 33 inter-domain mobility. It is also widely accepted that Mobile IP 34 could be used as the basis for signalling between the mobile and the 35 micro-mobility domains for simplicity of the mobile terminal and 36 interoperability purposes. The Edge Mobility Architecture (EMA) 37 defines a generic IP hand-over model which operates in conjunction 38 with a Mobility Enhanced Routing (MER) protocol to provide large- 39 scale, intra-domain, IP address mobility. The aim of this document 40 is to describe the minimum MIP signalling requirements for EMA:MER, 41 and to propose additional changes necessary to [MIPv6] and [MIPv4] 42 for them to support EMA:MER. The document deals with mobiles moving 43 inside and between EMA:MER domains as well as coming and going 44 from/to non-EMA:MER domains, demonstrating EMA/MIP interoperability 45 and inter-domain hand-overs. The document also demonstrates the 46 benefits a mobile and an operator will see when a mobile host is 47 within an EMA domain. 49 O'Neill, Corson, Tsirtsis 1 50 INDEX 52 Abstract 54 1. Introduction 56 2. Conventions used in this document 58 3. EMA and Mobile IP Architectural Considerations 60 4. Combined EMA:MER and Mobile IP Architecture 61 4.1 EMA and MIP with Co-located Care of Addresses . . . . . . 62 4.2 Non Co-located Care of Addresses with FA/Attendants . . . 64 5. Inter-domain Considerations 65 5.1 Non-EMA MN and/or movement between non-EMA domains . . . . 66 5.2 EMA MN Moves from any domain into an EMA domain. . . . . . 67 5.3 EMA MN Moves from an EMA to a Non EMA domain . . . . . . . 68 5.4 EMA MN Moves from one EMA to another EMA domain. . . . . . 69 5.5 Subsequent Movement. . . . . . . . . . . . . . . . . . . . 70 5.6 Returning to a previously visited domain . . . . . . . . . 71 5.7 Returning to the Home Domain . . . . . . . . . . . . . . . 73 6. Summary of Hand-over Processing 75 7. EMA enhanced MIPv6 76 7.1 Basic EMA Extensions to MIPv6 . . . . . . . . . . . . . . . 77 7.2 Hand-over Examples. . . . . . . . . . . . . . . . . . . . . 78 7.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . . 79 7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted) . . . 80 7.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . . 81 7.2.4 Moving into an EMA domain-MN Supports EMAext. . . . . 82 7.2.5 Moving into an EMA domain-MN does not support EMAext. 83 7.2.6 EMA MN has a CRCoA from a previous domain . . . . . . 84 7.3 Source Address Selection Rules. . . . . . . . . . . . . . . 85 7.4 Implications of EMA:MIPv6 Convergence on MIPv6. . . . . . . 86 7.5 Ongoing work. . . . . . . . . . . . . . . . . . . . . . . . 88 8. EMA enhanced MIPv4 89 8.1 Basic EMA Extensions to MIPv4 . . . . . . . . . . . . . . . 90 8.2 MIPv4 Hand-over Examples. . . . . . . . . . . . . . . . . . 91 8.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . . 92 8.2.2 Unplanned Reverse Hand-over (MN / NAR). . . . . . . . 93 8.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . . 95 9. MIPv6 vs MIPv4 in respect to EMA 97 10. Security Considerations 98 10.1 Authenticating users within a domain . . . . . . . . . . . 100 11. References 102 O'Neill, Corson, Tsirtsis 2 103 1. Introduction 105 Mobile IP (MIP) (versions 4 and 6) provides for the potential 106 movement of a Home IP address throughout the Internet, from a home 107 domain subnet, throughout foreign domain subnets equipped with MIP. 108 It does so by providing a Mobile Node (MN) with a local and 109 potentially short-term IP Care of Address (CoA) in a foreign domain, 110 towards which packets can be directly or indirectly tunnelled. This 111 CoA is reported back to a Home Agent (HA), who then tunnels packets, 112 sent by any Correspondent Node (CN) to the Home address, towards 113 this CoA. In addition, direct tunnelled communication, bypassing the 114 HA, can be achieved through additional signalling between the MN and 115 the CN. A Foreign Agent (FA) entity can also optionally exist to 116 assist the MN in the foreign domain by terminating tunnels and 117 acting as a proxy CoA, a CoA allocator and a proxy signalling point 118 for MIP signalling. 120 The Edge Mobility Architecture (EMA) provides a generic hand-over 121 model between two Access Routers (AR) for supporting the movement of 122 Mobile Nodes between ARs which are equipped with any Mobile Enhanced 123 Routing (MER) Protocol (modified MANET or general intra-domain 124 routing protocols). A MER protocol is able to rapidly adjust the 125 routing tables so that the route pointing to the IP address of a MN 126 can be moved in sympathy with the EMA hand-over signals to provide 127 seamless, native IP forwarding within an EMA domain. 129 The IP address of the MN is given to it by the first AR (called the 130 Allocating Access Router or AAR) it visits in the domain, out of its 131 aggregated prefix. A hand-over can be initiated either by a MN or 132 the network, and can be rooted (i.e. initiated) at either the old or 133 new Access Router. The Old Access Router (OAR) is used to co- 134 ordinate a forward hand-over when the New Access Router (NAR) is 135 known in advance as a result of either network or MN-based movement 136 prediction and associated performance measurements. The NAR is used 137 to co-ordinate a reverse hand-over when the NAR is not known in 138 advance by the MN or the network, as a result of either network 139 failure (e.g. old radio link lost), insufficient network 140 intelligence (no inter-technology hand-over signalling) or 141 unpredictable user behaviour (swapping PCMCIA network cards). 143 MIP is required between domains to support the movement of a MN IP 144 address out of the local domain (no inter-domain MER yet proposed), 145 and is also required to support MIP hand-over in domains that are 146 not equipped with a MER protocol. To facilitate the co-existence of 147 MIP and EMA options, the MIP signalling capabilities with 148 appropriate additions are obvious candidates for providing the User 149 -AR signalling plane for EMA hand-over. 151 MIP signalling between MN, FA/CoR, HA and CN is presently being 152 reviewed to establish appropriate enhancements to support fast IP 153 hand-over within 3/4G networks, and between other types of link 155 O'Neill, Corson, Tsirtsis 3 156 layer technologies supporting ARs and MNs. This draft outlines the 157 inter-working architecture for EMA and Mobile IPv6/v4 that provides 158 mutual co-existence and benefits, both for the user and the 159 operator. The draft then describes the specific additions to Mobile 160 IPv6/v4 signalling to provide the required features, with associated 161 issues and uncertainties that need to be raised for discussion with 162 the MIP working group. The aim of the draft, above and beyond its 163 specific technical content, is to raise understanding of the EMA 164 capabilities and requirements so that fast hand-over developments in 165 MIP are equally applicable to domains supporting routed mobility and 166 native forwarding. 168 Among the advantages of EMA are that when a MN is in its Home EMA 169 Domain, as it will become apparent later, there is essentially no 170 use of tunneling over the air interface, very little signalling over 171 the radio link, greatly reduced signalling in the network and little 172 need for persistent tunnels in the network. Most of the mechanisms 173 described in this document deal with corner cases and exceptions 174 when special signalling and tunnels are needed in order to provide 175 seamless inter-domain services using MIP signalling. 177 2. Conventions used in this document 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 181 this document are to be interpreted as described in RFC-2119 182 [RFC2119]. 184 3.1 Terminology used in this document 186 Much of the terminology used in this document borrows from Mobile IP 187 (versions 4 and 6) and this will be obvious to those familiar with 188 these protocols. The following introduces new terminology as well 189 as slight extensions to existing terminology. 191 Access Router (AR) 193 a combined IP router, network access server and Mobile IP 194 agent 196 NAR, nFA, nCoR 198 New AR with either FA (v4) or CoR (v6) functionality 200 OAR, oFA, oCoR 202 Old AR with either FA (v4) or CoR (v6) functionality 204 AA, AS/RA, RS 206 Mobile IP v4/v6 advertisements from AR used interchangeably, 208 O'Neill, Corson, Tsirtsis 4 209 possibly extended with EMA options 211 Forward BU (FBU) 213 Binding Update sent by MN (or Network) to OAR. Results in 214 OAR generating a BU Acknowledgement (BUAck) sent 215 'forward' (in direction of hand-over) to NAR and then to MN. 216 Creates temporary horizontal tunnel at OAR to MN for oCCoA 218 Reverse BU (RBU) 220 Binding Update sent by MN to NAR over new link and then 221 'reverse' (opposite direction of hand-over) to OAR 223 Binding Update Ack (BUAck) 225 Binding Update Acknowledgement sent by OAR to NAR and then to 226 MN in response to FBU or RBU. If network sent FBU, then MN 227 may receive unsolicited HAck. 229 EMA Hand-over Request Destination Option (EHORQ) 231 Sent by MN to O/NAR over old/new link requesting hand-over 233 EMA Hand-over Response Destination Option (EHORP) 235 Sent by NAR (on receipt of RUA) to MN over new link 236 confirming hand-over 238 AAA Request/AAA Response Destination Option 240 Sent by NAR and OAR to enable the NAR to rapidly acquire 241 local OAR IP configuration pertinent to the MN, such as keys, 242 policy information, dynamic firewall state. 244 Registration Request/Reply (RRQ/RRP) 246 Vertical Mobile IP message to HA from MN via NAR 248 UDU/UDU-Ack 250 MER TORA hand-over messages for host route redirects 252 Tau 254 Is one of the [TORA] reference values that decrements on 255 every handover and indicates host route freshness 257 Some more terms are also defined in Sections 6 and 7.2 of this 258 document. 260 O'Neill, Corson, Tsirtsis 5 261 3. EMA and Mobile IP Architectural Considerations 263 Firstly, the EMA envisages a rich set of hand-over capabilities that 264 encompass a range of existing, predictive (cellular) and non- 265 predictive (inter-technology) hand-over models and requirements. The 266 EMA signalling requirements are a super-set of existing MIP hand- 267 over capabilities as will be described in detail later, which 268 indicates that some additions will be required in MIP if EMA is to 269 solely rely on MIP signalling. Specifically, MIP does not presently 270 support forward hand-over rooted at the OAR, nor does it provide the 271 required information exchange between neighbouring ARs to facilitate 272 such forward hand-over in an all-IP solution. There have, however, 273 been drafts and discussions suggesting such additions and these are 274 in line with the desire for MIP to take a significant role in 3G/4G 275 cellular solutions. 277 Secondly, the MIP architecture assumes a MN is from an arbitrary 278 home domain, and an arbitrary HA within that domain. We therefore 279 cannot make any assumptions in EMA as to whether or not this Home 280 Domain is equipped with a MER protocol. Equally, we know that any 281 visited foreign domain may be either MER or non-MER equipped, and we 282 need to ensure that MIP continues to operate as normal as a MN moves 283 through MER and non-MER domains. The conclusion therefore is that 284 MIP functionality related to the Home Address as a source / 285 destination address, covering CoA registration, HA capabilities and 286 route optimisation/binding features, must be orthogonal to EMA. EMA 287 is instead associated with the CCoA, MN-AR signalling, and the 288 temporary forwarding (between CoA's on hand-over) features of MIP. 289 The specific details change slightly between MIPv6 and MIPv4, and 290 depend on the type of CoA (Co-located or not). Each scenario, except 291 the use of non-co-located CoAs, is described in the following 292 sections, followed by a description of the required MIP messages and 293 associated extensions. 295 Thirdly, and finally, the types of Internet access supported by MIP 296 and MER functionality are very different and are part of the overall 297 commercial opportunity. MIP facilitates roaming into foreign domains 298 and links, from a Home link within a Home Domain. Associated AAA 299 interfaces are used to control access to the foreign links where 300 necessary, and may also be used to install policy as to how user 301 traffic is forwarded. These forwarding options provide for IP 302 traffic associated with a home session address to go to and from the 303 Home Domain (forward and reverse HA tunnelling) as in the remote 304 access model. The other options allow for direct tunnelled 305 communication between CN and MN (HA bypass) through optimisation / 306 binding, and in the case of Co-located Care of Addresses (CCoA) 307 based sessions, native communication independent of the home address 308 and MIP tunnelling features (as in local or roaming access). The MIP 309 CCoA is however only a valid session address on a specific foreign 310 link, and the utility of this address for native service is 311 consequently severely limited, and it's use therefore actively 313 O'Neill, Corson, Tsirtsis 6 314 discouraged in Mobile IP. Some movement of this CCoA address is, 315 however, supported in MIP through the use of temporary tunnelling 316 between ARs, with the current CCoA at the old AR being treated like 317 a Home Address, and a new CCoA from the new AR acting as the tunnel 318 endpoint. 320 To aid subsequent discussions we describe temporary indirect tunnel 321 forwarding between adjacent ARs as "Horizontal" MIP forwarding. This 322 is to help the reader appreciate that this hand-over is likely to be 323 between geographically adjacent AR's of equivalent configuration and 324 status. Standard indirect tunnel forwarding via a possibly remote HA 325 in it's home domain is termed "Vertical" MIP forwarding. This is to 326 help the reader appreciate that this tunnel is likely to be in 327 support of communications between non-geographically adjacent nodes 328 of dissimilar configuration and status, where in many cases the HA 329 is a centralised element providing HA services to a large number of 330 AR's. Finally, the bypass of either horizontal or vertical 331 forwarding by a CN using optimisation is known as direct tunnel 332 forwarding as per MIP specifications. 334 MER, unlike MIP, also enables native communication using the CCoA as 335 a normal source (destination) session address, but with 336 significantly increased utility, as a result of the MER ability to 337 update the routing tables in the domain to enable the CCoA to move 338 with the MN. The combination of MIP and MER can therefore support 339 both native and remote access models, along with hybrid 340 combinational models. From the perspective of a foreign ISP, a 341 roaming MN can be offered native service and/or non-optimised / 342 optimised remote access depending on the user's/home operator's 343 privileges in the foreign domain, assuming appropriate AAA support 344 features are developed. 346 In the existing UMTS model, the benefit of the co-existence of these 347 models is clear because the present UMTS network can only support 348 the remote access model from the MN back through SGSN and GGSN to 349 the external 'Home' ISP (today via GTP tunnels). This external ISP 350 provides both the non-routable 'Home' IP address to the MN, and all 351 associated IP services and onward connectivity to the wider 352 Internet. Significant benefits would accrue to both the UMTS network 353 operator and to users if, in addition, the UMTS network could 354 support native IP services using local IP addresses, local IP 355 service infrastructure, and direct connectivity between users on 356 that network and out to the wider Internet. This commercial context 357 provides additional justification for the co-existence of MIP 358 (remote access) and EMA:MER (as an efficient means to support native 359 forwarding) within a future all-IP 3G/4G solution. The details below 360 will illustrate this in more detail. 362 O'Neill, Corson, Tsirtsis 7 363 4. Combined EMA:MER and Mobile IP Architecture 365 4.1 EMA and MIP with Co-located Care of Addresses 367 A MN has a Home address from a Home Domain and is allocated as per 368 normal MIP specs (static, DHCP etc). This address is installed in 369 any system which requires a global and reliable IP address through 370 which to reach the MN (DNS, SIP etc). Orthogonal to this is the CCoA 371 which is allocated on any foreign link, and which is equivalent to 372 the EMA address for the MN. For a series of Access Routers past 373 which a MN can move, acquiring a CCoA at each AR, the MN can 374 continue to use its home address as a valid IP session address. 375 This MIP tunnelling model works for intra and inter-domain movement 376 with the appropriate AAA support. The impact of EMA, and the aim of 377 the interworking architecture, is to enable a whole EMA domain to 378 appear to MIP vertical tunnelling elements as if it is a single AR, 379 in that a single CCoA can be used throughout the domain. By ensuring 380 that a MN experiences the same environment (state / signalling) 381 whether it is handing over between non-EMA or EMA-equipped ARs, we 382 can provide movement through arbitrary domains in any sequence 383 whilst preserving existing horizontal and vertical MIP 384 functionality. 386 When the MN first starts up, the MN gets its first CCoA in this new 387 domain and needs to undertake normal MIP signalling to register this 388 CCoA with its (possibly remote) HA to facilitate "indirect vertical 389 tunnelling" between the HA and the MN. In addition, the MN may wish 390 to also communicate its new CCoA to any CNs so that "direct 391 tunnelling" (HA bypass) can be achieved. For the moment we will 392 forget what has happened in any previous foreign domain, which may 393 or may not have EMA:MER capabilities. Let us then assume that the MN 394 is happily communicating via both direct and indirect vertical 395 tunnelling when it detects a change of AR (link) using well- 396 documented MIP techniques. 398 In the case of a MN in a non-MER domain, we would require that, as 399 per MIP specs, a new CCoA allocation on the new link be followed by 400 updated registrations to; 402 i. the HA and CNs to move indirect vertical and direct tunnels to 403 the new CCoA, and optionally to 405 ii. the old CoR/FA for horizontal MIP tunneling of packets, 406 addressed to the old CoA, from the old CoR/FA to the new CoA. 408 Note that the latter applies to both in-flight packets using 409 vertical forwarding to the previous CoR, and to packets sent 410 natively to the old CoA. The vertical and direct tunnel messages 411 represent signalling traffic and delay which can be avoided in an 412 MER-equipped domain, as follows. 414 An MER protocol, however, would enable the CCoA to move with the MN 415 as it changes ARs, by rapidly modifying the local routing tables so 417 O'Neill, Corson, Tsirtsis 8 418 that traffic addressed to the CCoA now arrive natively via the new 419 AR rather than via the old AR. This means that the CCoA and all MIP 420 registrations are still valid, and hence there is no need to update 421 the forwarding state in HA and CNs. 423 The result is faster hand-over, reduced signalling load, and in many 424 cases no tunnelling of IP packets between adjacent ARs. In an 425 EMA:MER-equipped domain, the MN therefore only needs to acquire a 426 single CCoA in that domain per IP session, and only needs to 427 register that address once to the remote HA and CNs, as the MN moves 428 in the domain. This constitutes a significant performance 429 improvement to MIP hosts if the EMA:MER domain is both practical, 430 from a routing perspective, and sufficiently large enough to justify 431 the deployment of EMA:MER. 433 Note that because of the clean separation between EMA:MER horizontal 434 operations from the MIP vertical operations, and the focus of 435 EMA:MER on optimising the horizontal plane (and as a result 436 avoiding the side-effects on the vertical plane), each domain can 437 independently decide on MER deployment without affecting vertical 438 MIP operation as a user roams through foreign domains. From a MIP 439 signalling perspective, the MN would still go through the motions of 440 requesting/updating vertical MIP tunnelling. Also, it would install 441 a temporary horizontal MIP forwarding tunnel as per MIP between the 442 old AR and the MN at the new CCoA; this being an optional MIP 443 feature. However, in an EMA:MER domain, these messages would also, 444 in parallel with installing a temporary horizontal MIP tunnel, be 445 used to install a new host native redirect route from the old AR to 446 the MN at the new CCoA. 448 In MIP, an obvious special case arises when the MN is on its home 449 link, in that it doesn't need a separate CoA and does not therefore 450 participate in MIP to send and receive IP packets. When the HA is 451 located in an EMA domain, the concept of "home" may be extended to 452 the entire domain due to the micro-mobility capability of an IP 453 address being valid anywhere in the home domain rather than just on 454 the home link. So, while the MN is on its home link within an EMA 455 domain, no MIP signalling is required as is normal, and no MER host 456 redirect routes are generated in the domain. When the mobile moves 457 from that home link but remains in the home domain, there are two 458 models that can be used, which offer different potential benefits to 459 the overall system. 461 The first model assumes a native 'roaming' service is offered to the 462 mobile anywhere away from the home LINK. As soon as the MN moves out 463 of the home 'link' but still remains in the same "home EMA domain", 464 it must acquire a CCoA at the first foreign link, and can then 465 continue to use that CCoA as a source address throughout the EMA 466 domain as it does in the general case. The MN will then need to use 467 MIP signalling to trigger EMA hand-overs and install MER host 468 redirect routes to forward traffic towards each new AR. Any ongoing 469 IP session using the home address is maintained using MIP vertical 470 tunnelling from the home link Home agent as normal. It is worth 472 O'Neill, Corson, Tsirtsis 9 473 noting that this model may well be necessary in UMTS if the HA is a 474 core network function, and is generally not therefore located on an 475 AR. In this way the MN is always "away" from its home link and is 476 therefore always on a foreign link (possibly in a foreign domain) 477 from which it always has to get a CoA to operate. 479 HA 480 + 481 + 482 + 483 AR1+ AR2 AR3 484 |+ 485 |+ 486 MN <----------> 487 Figure 1: The MN gets an address from the EMA 488 domain (EMA CCoA) and registers it with its Home 489 Agent. While in the same EMA domain no other 490 registration is needed. 492 The second model assumes a native 'roaming' service is only offered 493 to the mobile anywhere away from the home DOMAIN. In this case, the 494 MN would automatically use its Home Address as a CoA whilst on 495 foreign links in the home EMA domain, since its Home Address is 496 valid throughout this domain due to MER redirection. The HA is 497 considered to be the automatic AAR and the first AR the MN 498 encounters in the home domain simply AAA's the request to use the 499 home address, and acts like a NAR by injecting a host redirect route 500 back to the HA (the AAR). Requesting or continuing to use the Home 501 Address as CCoA when the MN is away from its home link offers the 502 following advantages. 504 HA AR2 AR3 505 | 506 | 507 MN <--------------> 508 Figure 2: The MN's Home Address is the same with 509 the EMA CCoA and thus no tunneling to HA is 510 required. 512 i. CNs communicating with the MN's home address achieve direct 513 native communication while the MN is anywhere in its home domain. 515 ii. When the MN moves to a foreign domain and acquires a new CCoA, 516 the MN can send vertical Binding Updates (BU) to CNs as the MN is 517 still using the same session source address. In contrast, if the MN 518 is using a CoA different from its home address as a source address 519 in a session, then a vertical BU to a CN will not work, and 520 horizontal MIP tunnelling is instead required to deliver packets to 521 the MN. 523 O'Neill, Corson, Tsirtsis 10 524 This use of the home address as a CCoA may have some side-effects 525 though as MIP attaches special significance to messages in which the 526 CoA=Home Address. This is normally used to cancel all bindings to 527 other CoAs, and to therefore reinstate native forwarding. Curiously 528 this is precisely what we wish to achieve in the context of the 529 wider home domain, but the full ramifications of this when multiple 530 simultaneous bindings are being supported, or following inter-domain 531 movement is for further study. The other implication of using the 532 home address as the CCoA is that the MN requires a host redirect 533 route back to its HA when it first starts a session, which reduces 534 the inherent scalability of EMA:MER routing. 536 4.2 Non Co-located Care of Addresses with Foreign Agents / Attendants 538 This draft does not describe these options within the EMA model 539 because of the lack of a distinct per host CoA. This prevents MER 540 routing from preserving the CoA (and associated tunnels and 541 bindings) in an EMA domain. There are however obvious ways to enable 542 co-existence of MIP and EMA in this case, as illustrated by the 543 inter-domain models of Cellular IP and HAWAII. 545 5. Inter-domain Considerations 547 MIP is required in EMA between domains to support the movement of a 548 MN IP address out of the local/home domain (no inter-domain MER yet 549 proposed), and is also required to support MIP hand-over in domains 550 that are not equipped with a MER protocol. To facilitate the co- 551 existence of MIP and EMA options, the MIP signalling capabilities 552 with appropriate additions are obvious candidates for providing the 553 signalling plane for EMA inter-domain hand-over. 555 5.1 Non-EMA MN and/or movement between non-EMA domains 557 Normal MIP mechanisms must apply to ensure we are standards 558 compatible, irrespective of the nature of the mobility support (EMA 559 or non-EMA) in either the previous or new domain. In addition, we 560 must make sure that any EMA extensions to MIP can co-exist with the 561 unmodified form of MIP so that an EMA domain can support legacy ARs 562 and MNs. We must therefore acquire a new CCoA from the first AR in 563 this domain and then update the HA and any CNs to re-orientate 564 vertical tunnelling. In addition the MN can optionally register the 565 new CCoA with the previous CoR/FA and build a temporary inter-domain 566 MIP horizontal forwarding tunnel so that existing communications 567 directed to the previous CCoA can be maintained. 569 We can then iteratively build subsequent MIP horizontal and vertical 570 forwarding tunnels in the new domain as would be required for a non- 571 EMA domain. This means that each time the MN changes AR, a new CCoA 572 has to be acquired by the MN that has to then be registered to the 573 previous CoR/FA, and a new temporary horizontal forwarding tunnel 574 built between adjacent ARs. The persistence of the horizontal and 575 vertical tunnels depends on the requested (or agreed) lifetime as 577 O'Neill, Corson, Tsirtsis 11 578 detailed in standard MIP signalling. It is expected that the 579 lifetime of temporary horizontal MIP tunnels between adjacent ARs 580 will be very short, on the order of seconds. Note that chaining of 581 multiple horizontal tunnels through a non-EMA domain results in 582 multiple encapsulations. These are only required though if the 583 vertical tunnel is not re-orientated (diverting traffic from 584 reaching the old CCoA), or a previous CCoA up the hand-over sequence 585 was used as a session address for which packet flow is continuing to 586 require the chain of tunnels to reach the MN. 588 5.2 EMA MN Moves from any domain into an EMA domain 590 If the MN supports EMA extensions, as soon as it steps into an EMA 591 domain it will behave as if it is booting up in the EMA domain and 592 will be required to undergo authentication. It will optionally 593 acquire its domain-wide hash (see section 10) which is used to 594 efficiently confirm the identity of the MN to AR's throughout the 595 domain. Then, the MN will be able to get a new CCoA from the AR to 596 which it first attaches to, which it can then continue to use on 597 subsequent hops in the new domain due to EMA:MER routing. The node 598 will also compute a hash based on the new CCoA that can be used to 599 authenticate packets over the air within this domain (see section 600 5). Additionally, the MN might chose to build a temporary MIP 601 horizontal tunnel to the last AR in the last domain so that existing 602 communications directed to previous CCoA's in the last domain will 603 not have to be dropped. Note that while in the new EMA domain this 604 temporary horizontal tunnel, and the associated HA/CN vertical 605 tunnels, will also be moved with the MN as they terminate on the 606 MN's mobile CCoA in this domain. Therefore, a new vertical and 607 horizontal tunnel will not have to be set-up at each new AR, leading 608 to vastly reduced signalling and faster hand-over. 610 Domain 611 Boundary HA 612 | + 613 Old non-EMA| + New EMA Domain 614 Domain | + 615 | + 616 OAR+++++NAR+ AR AR 617 | + | + 618 | + | + 619 | ++MN <------------> 620 | 621 Figure 3: The MN Registers a new CCoA to its HA 622 which will be its EMA CcoA in this domain and is 623 required. 625 5.3 EMA MN Moves from an EMA to a Non EMA domain 627 When a mobile appears at an AR in a new domain, then the present 628 CCoA used by the MN from the old domain is no longer valid. The MN 630 O'Neill, Corson, Tsirtsis 12 631 therefore needs to acquire a new CCoA. Present communications 632 though, are using the old CCoA which are being routed by EMA towards 633 the OAR in the previous domain. We have at least one (and possibly 634 two) hand-over stages to complete; 636 In the first stage the MN can send a binding update to the previous 637 AR, as in standard MIP, so that it can temporarily horizontally 638 tunnel packets addressed to the old CCoA forward to the new CCoA. 639 This however means that the old CCoA (in the previous EMA domain), 640 and the associated routing state from the AAR to the OAR, cannot be 641 released until either the binding at the OAR times out and/or the 642 route timer and address timer expire. This should happen very 643 quickly though as the horizontal tunnel is intended to be short- 644 lived. 646 In the second stage, if the old CCoA was allocated in a previous EMA 647 domain, and is in use as a session address, the MN now views that 648 CCoA session as a secondary home address, whose home agent is the 649 AAR in the previous domain. We call this a "Co-Located Roaming CoA" 650 (CRCoA)and is a deprecated address, i.e.: the MN MAY use it to 651 maintain existing sessions but MUST NOT use it as source address in 652 new sessions 653 . 655 T 656 he MN therefore sends another BU to that AAR so that 657 the AAR can AAA the request to roam with one of its CCoAs. If 658 permitted, the AAR then provides HA and persistent horizontal 659 tunnelling services to the MN for that CRCoA, and the MN can use BUs 660 to CNs using that CRCoA as a session address to bypass the AAR HA. 661 If BUs to CNs are used, the AAR HA may never need to tunnel packets 662 to the MN. The AAR will in any case not need to act as the HA for 663 the CRCoA and tunnel packets until the host routing state, directing 664 packets addressed to the CRCoA towards the OAR, is eliminated on 665 expiry of the temporary horizontal inter-domain tunnel. 667 Domain 668 Boundary 669 | HA 670 | + 671 Old EMA | + New Non-EMA Domain 672 Domain | + 673 | + 674 +++++++++++++++++++ + 675 + | + + 676 AAR OAR++++++ +NAR+ AR AR 677 | + +| + 678 | + +| + 679 | ++MN+++ 680 | 681 Figure 4: The MN Registers a new CCoA to its HA 682 and to the AAR in the old EMA domain for the 683 CRCoA. A temp tunnel to the OAR is optional. In 684 the non-EMA domain this registration will be done 685 one every hop. 687 O'Neill, Corson, Tsirtsis 13 688 The destination of the MIP temporary and persistent horizontal 689 inter-domain tunnels, is the new CCoA in the new domain. In parallel 690 with this, normal vertical MIP Registration of the new CCoA for the 691 original home address should also be sent to the HA of the MN to 692 update vertical tunnelling. This process will then be continued on 693 subsequent hops as per normal MIP, with each new local CCoA 694 allocation requiring both vertical and horizontal tunnelling updates 695 for the original home address and any acquired CRCoAs in use as 696 session addresses. An aggregated horizontal BU for the previous CoA 697 and active CRCoAs, to the previous CoR/FA, would clearly be 698 advantageous. Multiple CRCoAs are possible because a new CRCoA could 699 be collected in each EMA domain encountered. This is not considered 700 to be a significant scaling problem due to the rarity of inter- 701 domain hand-over in the EMA model. 703 5.4 EMA MN Moves from one EMA to another EMA domain 705 In this case, the MN moves from one EMA Domain to another also EMA- 706 enabled Domain. The hand-over and interdomain tunnel requirements 707 are exactly as with the previous section (5.3). 709 The most important difference from 5.3 is that the MN will register 710 all the tunnels only once since the nCCoA in the new EMA domain will 711 be valid throughout this domain. All these tunnels at the NAR 712 will then "follow" the MN naturally without the need for re- 713 registration. The tunnel from the OAR will be dropped quickly, 714 since this is the temporary horizontal one, while the others will be 715 maintained for as long the MN is using the CRCoA. 717 Domain 718 Boundary 719 | HA 720 | + 721 EMA | + EMA 722 Domain 1 | + Domain 2 723 | + 724 +++++++++++++++++++ + 725 + | + + 726 AAR OAR++++++ +NAR+ AR AR 727 | + +| + 728 | + +| + 729 | ++MN+++ <----------> 730 | 731 Figure 5: The MN Registers a new CCoA to its HA 732 and to the AAR in the old EMA domain for the 733 CRCoA. A temp tunnel to the OAR is optional. In 734 EMA Domain this registration will only be done 735 once. 737 O'Neill, Corson, Tsirtsis 14 738 5.5 Subsequent Movement 740 It is clear that the use of MIP ensures that subsequent multi-domain 741 movement, in any sequence, between EMA and non-EMA domains, can use 742 MIP between and within any domain. When using EMA to move the CCoA 743 within a domain we can clearly detect movement to a new AR by the 744 absence of the advertisement of the prefix covering the existing 745 CCoA. If that new domain is not supporting EMA we can move to normal 746 MIP mechanisms and build the forwarding tunnel back to the previous 747 EMA domain (first to the OAR, then the AAR). From there we know we 748 can continue to use MIP and drop into EMA processing at any point. 749 Any intermediate MIP or EMA state in previous domains, and in 750 particular that associated with CRCoAs, only remains whilst data is 751 being forwarded or whilst timers are refreshed. Any intermediate EMA 752 state is directly equivalent to the MIP state that would have been 753 created by a MN, acting simply to compress multiple MIP CCoA 754 allocation phases into a single EMA CCoA allocation phase. 756 5.6 Returning to a previously visited domain 758 When a MN returns to a non-EMA domain that it has previously 759 visited, and in which it may (but probably does not) still have MIP 760 horizontal forwarding state, the MN can potentially re-use an 761 existing CCoA (and delete the horizontal tunnel). This is only 762 possible if the MN is returning to the same CoR/FA that owns that 763 CCoA. Alternatively, and after determining its new CCoA and building 764 the incoming inter-domain tunnel from the last domain, the MN should 765 move (via binding update) any persistent horizontal tunnels from the 766 previous CCoA in that domain to this new CCoA. This is to avoid 767 indirect routing, remove the outgoing inter-domain tunnel, and 768 release resources within visited intermediate domains on the path 769 out of, and back into, this domain wherever possible. The necessity 770 of these sequence of BU events is however questionable as it is only 771 required when a MN passes rapidly through intermediate domains 772 before returning to a previous domain during the lifetime of the 773 short-lived horizontal tunnel, and before vertical tunnelling has 774 been updated. 776 When a MN returns to an EMA domain that it has previously visited, 777 the MN may still be using the CCoA that it acquired in that domain 778 as a CRCoA. The MN must first find out if it has an active CRCoA (or 779 home address) for that domain through NAI comparisons. An active 780 CRCoA may or may not have a host redirect route associated with it 781 (AAR to OAR) but will more likely have a HA at the AAR acting as a 782 CRCoA forwarder. If it does have such an address then we would wish 783 the MN to use that address rather than acquire an additional address 784 from that domain, and insert additional host redirect routes into 785 EMA. 787 Once the MN has gained permission at the NAR (AAA) to use the 788 existing CRCoA, the MN will then build a new incoming horizontal 789 forwarding tunnel from the OAR in the previous domain as per normal 791 O'Neill, Corson, Tsirtsis 15 792 MIP inter-domain hand-over. The MN can then consider additional 793 action to avoid indirect vertical forwarding within the new domain, 794 and release resources as for the non-EMA domain above. This should 795 all cause the previous outgoing inter-domain horizontal forwarding 796 tunnel to be bypassed before the tunnel lifetime expires, and any 797 host redirect route and/or MIP state in intermediate domains to be 798 released where possible. The first action is to instigate an EMA 799 hand-over from the NAR at which the MN re-entered this domain. The 800 MN has two options as this point; 802 i. Assuming the inter-domain tunnel is at a local OAR. The MN can 803 inject a host redirect route back to the AAR which will partially 804 intercept the old host routing state to the OAR and redirect 805 packets away from the OAR. The OAR inactivity timers and BU 806 lifetime will expire if not refreshed, clearing out the old host 807 routing state within the domain. When the old routing state is 808 removed the host route to the AAR will then redirect all packets 809 locally to the NAR as per standard EMA:MER mechanisms. 811 ii. If the inter-domain tunnel is already at the AAR, we can start 812 an unplanned hand-over back to this node and everything is as per 813 normal EMA except that we can locally clear the persistent 814 horizontal inter-domain tunnel at the AAR. 816 In all cases, the MN will continue to receive in-flight packets that 817 are still on their way to, or have passed through, the local OAR. 818 The path includes the outgoing inter-domain tunnel to the foreign 819 domain, subsequent intermediate domain forwarding to a foreign OAR, 820 and then into the new inter-domain tunnel towards the new local NAR. 821 This path difference between the new local host route and the 822 existing inter-domain path means that the MN may need to buffer the 823 packets from the new host redirect route whilst the inter-domain 824 packets are delivered. This buffering is better on the host as it 825 has application awareness. 827 5.7 Returning to the Home Domain 829 When a MN which is using MIP returns home, MIP provides all the 830 mechanisms required to return to native forwarding on the home link, 831 or to make use of horizontal and/or vertical tunnelling as it sees 832 fit. If the home domain is an EMA domain then any intermediate MIP 833 or EMA state in previous domains only remains whilst data is being 834 forwarded as described above. If the MN returns home but has not 835 been home during this IP session then there may be some benefits in 836 the MN automatically setting its CCoA in the domain to its Home 837 address, rather than getting a CCoA from the NAR(AAR) in the home 838 domain. These benefits relate to the fact that all applications then 839 use the same address whether being tunnelled or natively forwarded 840 within the domain. 842 O'Neill, Corson, Tsirtsis 16 843 6. Summary of Hand-over Processing 845 The EMA hand-over model covers both Break-Before-Make (BBM) and 846 Make-Before-Break (MBB) planned and BBM unplanned hand-over . In 847 planned hand-over the NAR is known in advance and so a temporary 848 tunnel may be built from the OAR to the NAR. In unplanned hand-over 849 (which by definition is BBM only), the NAR is not known and any 850 tunnel must be requested from the NAR back to the OAR. The same 851 message sequence is used for both forms of hand-over. Mandatory 852 signalling is rooted at the NAR, but anticipatory (i.e. planned) 853 signalling may occur in advance of hand-over, rooted at the OAR. 854 Hand-over may be triggered either by the MN or the network. Five 855 types of MIP tunnels that may be used during EMA-based hand-over and 856 forwarding: 858 i. Temporary Horizontal from OAR to MN for oCCoA via nCCoA 859 ii. Vertical indirect from MN-HA to MN for Home Address via a nCCoA 860 iii. Direct from CN to MN for Home Address via a nCCoA 861 iv. Persistent horizontal from AAR-HA to MN for CRCoA via a nCCoA 862 v. Direct from CN to MN for CRCoA via a nCCoA 864 HA+ CN(HA) 865 (HA)+ + 866 + + 867 OAR++++++NAR OAR +NAR OAR +NAR 868 (oCCoA) + + + 869 + + + 870 + + + 871 MN(nCCoA) MN(nCCoA) MN(nCCoA) 873 i. Temp Horizontal ii. Vertical Indirect iii. Direct 875 CN(CRCoA) 876 D1 | D2 D1 | + D2 877 | | + 878 AAR++++++NAR AAR | + NAR 879 (CRCoA)| + (CRCoA) | + 880 | + | + 881 | + | + 882 MN(nCCoA) MN(nCCoA) 884 iv. Persistent v. Direct 885 Horizontal 887 Figure 6: Tunnel Types supported by EMA 889 ++++ indicates tunnel 891 (xx) indicates an address related to this tunnel. Which 892 packets use it and what is the destination of the 893 tunnel. For example on (i.) packets with Destination 894 Address=oCCoA will be tunneled to nCCoA. 896 O'Neill, Corson, Tsirtsis 17 897 oCCoA is the EMA CcoA ie. The address which is valide 898 throughout the EMA domain 900 nCCoA is a CcoA the MN gets every hop but only uses for 901 signaling/tunnel termination or if EMA handover fails 903 CRCoA in the previous domain this was an EMA CcoA. Since the 904 MN moved out of that domain this becomes an CRCoA and 905 is treated as a Home Address 907 The temporary horizontal tunnel (i) is expected to have a lifetime 908 on the order of seconds, whereas the others may be long-lived. 910 Only the temporary horizontal tunnel is mandatory in that it is set 911 up in nearly every hand-over. The tunnel may be established (i.e. 912 initiated) by the MN or the network. It may be rooted (i.e. 913 initiated) at the OAR if planned or at the NAR if unplanned. 914 Planned hand-over is always optional in that failure of a planned 915 hand-over (due to unexpected loss of the old link) can always be 916 overcome by resorting to unplanned hand-over via the new link when 917 necessary. If planned (i.e. a new link is sensed based on L2 918 measurements), a forward hand-over message is sent from either the 919 MN (or the network) to the OAR, which then forwards it to the NAR, 920 which then forwards it to the MN via the new link. 922 On arrival at the OAR, the message establishes a tunnel from the OAR 923 to the NAR for the MN CCoA and any active CRCoA's. The other end of 924 the tunnel is established on arrival at the NAR. Finally, the MN is 925 informed of the success of planned hand-over when it receives the 926 forward message via the new link. Using forward hand-over signals, 927 it is possible to establish multiple tunnels to one or more 928 potential NARs to which the MN may be hand-over. If, on arrival at a 929 NAR, the MN has not received a forward hand-over message, it 930 generates a reverse hand-over message that is sent from the MN to 931 the OAR to the NAR. On arrival at the NAR, a tunnel (if not already 932 present) is established as before. A reverse hand-over 933 acknowledgement (now equivalent to the forward message sent earlier) 934 is sent from the OAR to the NAR (completing tunnel establishment) 935 and on to the MN. 937 Once the MN (now at the NAR) is assured that the horizontal tunnel 938 is in place, it then updates its vertical tunnel binding for its 939 home address and any persistent horizontal tunnel bindings for 940 CRCoA's as necessary. Depending on the MN's location (within an EMA 941 domain or not), its configuration and current state (e.g. the nature 942 and number of its session address(es)), etc., some, all or none of 943 the aforementioned tunnels may need to be created or updated. 944 Additionally, if in an EMA domain, additional signalling to locally 945 redirect native host routing will occur simultaneously, in parallel 946 with the binding updates (if any). 948 O'Neill, Corson, Tsirtsis 18 949 7. EMA enhanced MIPv6 951 On boot up or at arrival at a new AR, the MN must listen for Routing 952 Adverts (RA) from the nearest Access Router (AR) and auto-generate a 953 new CCoA from one of the prefixes advertised as per normal IPv6 954 Stateless Address Autoconfiguration (or DHCPv6). The first such AR 955 becomes the Allocating Access Router (AAR) as far as EMA is 956 concerned for the duration of the active IP session. In the special 957 case of a home EMA domain, the MN may request to use it's home 958 address as the CCoA. The EMA domain is a fully mobile enhanced 959 routed (MER) network so the CCoA is now valid throughout the domain 960 by using IP hand-over to control host redirect routes. This offers a 961 number of significant advantages. 963 - Reduced HA signalling: Normally, on each hop the new CCoA would 964 have to be registered/bound to the HA of the MN as per normal MIPv6. 965 With EMA-enhanced MIP, the CCoA is registered once in the HA at the 966 AAR. After that no more registration of the CCoA is needed. 968 - Reduced CN signalling: For the same reasons as above after the 969 initial CCoA allocation, the MN does not need to send re-bindings to 970 the CNs whilst in a single domain (and in session) which is a big 971 improvement. Note that this also impacts the performance of CNs that 972 otherwise might not be able to cope with the repeated BUs due to 973 continuous CCoA re-bindings. 975 7.1 Basic EMA Extensions to MIPv6 977 NAI Extension to Routing Advertisements: 979 Each time the MN detects a new AR, it will have to determine if 980 it is in the same or different domain as the AAR. This can be 981 accomplished by adding an NAI extension to the RAs of the ARs. 982 This capability has already been proposed but the MN needs to be 983 able to store the NAI's of the AAR, OAR and NAR to appreciate the 984 nature of the required hand-over processing. 986 MR Flag Extension to Routing Advertisement: 988 To gain the above benefits we need to inform the MN that the AR 989 is EMA enabled and the EMA CCoA is valid at the new AR (while in 990 the same domain). A single bit "Mobile Routing" (MR) flag in the 991 Routing Advertisement could inform an EMA MN that it can reuse 992 it's current CCoA if the AAR, OAR and NAR share the same NAI 993 realm, and the MN satisfies EMA hand-over AAA requirements. Note 994 that this flag can also be re-used by HAWAII, Cellular IP and 995 other micro-mobility protocols if they meet the requirements of 996 this draft. 998 O'Neill, Corson, Tsirtsis 19 999 Destination Options 1001 In the following Hand-over and signalling descriptions we are 1002 assuming a conservative 'ships in the night' model for the 1003 Destination Options in the EMA and MIP horizontal signalling 1004 messages. This minimises for now the interactions between MIP 1005 and EMA options but does enable minimal integration by enabling 1006 both sets of options to reside, where possible, in the same 1007 packet for increased efficiency. For simplicity, the following 1008 packet formats assume this is possible with no side-effects. The 1009 MIP Options therefore still go end to end as normal (located 1010 after the routing header in the IP packet). In contrast, the EMA 1011 related Options go via the NAR, under the control of the Routing 1012 Header, and are therefore before the routing options. It is 1013 expected that significant benefits can be gained by closer 1014 integration of the options in terms of hand-over timing, 1015 correctness and message efficiency. However, the security 1016 implications, option processing and forwarding rules, and status 1017 of both the MIPv6 draft and the EMA work in the MIP working 1018 group, make further consideration of closer integration 1019 inappropriate at this time. The Message processing and 1020 forwarding rules for the key MIPv6 destination Options are 1021 summarised below. 1023 Option Message Processing and Forwarding 1025 BU Cannot change on route, discard if unrecognised 1027 Buack Cannot change on route, skip over if unrecognised 1028 Must be covered by IPSEC AH 1029 BUnack must contain no payload 1031 HA Cannot change on route, discard if unrecognised 1032 Must be covered by IPSEC AH if AH applied to packet 1033 One per packet and mandatory for a BU 1035 7.2 Hand-over Examples 1037 In this section we demonstrate the use of MIP messages in an EMA:MER 1038 domain. Draft [EMA] describes the main MER messages that enable host 1039 route creation/deletion in an EMA domain. Figure 7 below reminds the 1040 reader of the these basic MER messages. 1042 O'Neill, Corson, Tsirtsis 20 1043 |>>>>>>>>>>>>> 5.RUA/RUN >>>>>>>>>>>>>| 1044 | | 1045 | |<<<<<<<<<<<<<< 4.RU <<<<<<<<<<<<<| | 1046 | | | | 1047 |_| |_| 1048 | | -----------> 3.HI/HD -------> | | 1049 NTIN-----|OAR| <----------- 2.HR <---------- |NAR| 1050 |___| -----------> 1.TIN ---------> |___| 1051 \ / 1052 \ / 1053 HTIN HHR 1054 \ / 1055 \ / 1056 '-------- MN--------' 1057 Figure 7: Basic EMA:MER Hand-over Messaging 1059 Tunnel INitiation (TIN) 1061 Advanced warning of possible hand-over from OAR to NAR, also 1062 indicates that temporary tunnel is set at OAR 1064 Host TIN (HTIN) 1066 Message from MN to OAR indicating that possible hand-over to 1067 a NAR is requested 1069 Network TIN (NTIN) 1071 Message from network controller element to OAR indicating 1072 that hand-over to a NAR is requested 1074 Host Hand-over Request (HHR) 1076 Message from MN to NAR requesting hand-over, contains MN's 1077 credentials 1079 Hand-over Request (HR) 1081 Message from NAR to OAR which could contain MH credentials 1082 and privileges. 1084 Hand-over Initiation (HI) 1086 OAR's response to a HR if hand-over is permissible. Contains 1087 MN creditials, policy information, etc. 1089 Hand-over Denial (HD) 1091 OAR's response to an HR if hand-over is not permissible . 1093 O'Neill, Corson, Tsirtsis 21 1094 Routing Update (RU) 1096 On receipt of the HI or HHR, the NAR also initiates routing 1097 redirection by sending a RU towards the OAR. This is sent 1098 reliably hop-by-hop and may be resent multiple times 1100 RU Acknowledgement (RUA) 1102 OAR's response to a RU confirming hand-over and transfer of 1103 MN from OAR to NAR. 1105 RU Negative Acknowledgement (RUN) 1107 OAR's response to a RU denying hand-over 1109 7.2.1 Unplanned Reverse Hand-over (MN not trusted) 1111 Unplanned hand-over occurs as a result of a lack of, or failure of, 1112 planned hand-over processing. This may itself be a result of the 1113 unplanned loss of the old link at the OAR, a lack of inter- 1114 technology hand-over communications, or unpredictable user activity 1115 such as removing / swapping a PCMCIA card. The MN and network can 1116 therefore only proceed with a hand-over rooted at the NAR with the 1117 aim of setting up MIP forwarding and a MER host route, from the OAR 1118 which is known by the MN. 1120 The MN arrives unannounced at the NAR and receives a Router 1121 Advertisement containing the NAI of the NAR and with the MR bit set. 1122 It may optionally send a Router Solicitation to stimulate this RA. 1123 The MN forms a new CCoA at the NAR which it can use temporarily and 1124 as a source address for MIP signalling and forwarding (Home Address 1125 Option = EMA CCoA), and for receiving horizontally forwarded packets 1126 from the OAR and directly forwarded packets from CN's. The MN then 1127 sends a Reverse Binding Update to the OAR via the NAR using a packet 1128 containing a Routing Header and an EMA Hand-over Request (EHORQ) 1129 Destination Option. This option is equivalent to the HHR message in 1130 the EMA draft [EMA]. The EMA EHORQ is authenticated and processed 1131 by the NAR. The NAR inserts an AAA Request Option into the packet to 1132 request AAA information from the OAR. At this point this Option is 1133 equivalent to the Hand-over Request (HR) message in the EMA draft 1134 [EMA]. 1136 The Reverse Binding Update (RBU) packet containing the EHORQ and AAA 1137 options is then sent to the OAR as per normal MIP horizontal 1138 processing to install temporary forwarding from the EMA-CCoA to the 1139 MN via the nCCoA at the NAR. The OAR checks the hand-over request 1140 and installs the horizontal forwarding state with a suitably short 1141 life-time. The OAR also checks the TORA Tau information for 1142 correctness and modifies it if necessary. A BUAck containing the MN 1143 nCCoA and the EMA CCoA is then sent from the OAR to the MN via the 1144 NAR using a Routing Header. The Bu-ack packet also contains an EMA 1145 Hand-over Response (EHORP) Destination Option and an AAA Response 1147 O'Neill, Corson, Tsirtsis 22 1148 Destination Option. The EMA Hand-over Response Option is equivalent 1149 to the Tunnel Initiation (TIN) message in EMA draft whilst the AAA 1150 Response Option is equivalent to its Hand-over Initiation/Deny (HI 1151 /HD) messages. This packet reports the status of the EMA hand-over 1152 to the NAR and the MN, and to provide IP session information 1153 (policy) to the NAR. The AAA Response Option and EMA EHORP Option 1154 are processed by the NAR which for example can be used to open the 1155 ingress filter for the EMA CCoA. The NAR then forwards the BUAck to 1156 MN with the updated status of the hand-over. 1158 At the NAR, the Tau value and OAR address are copied from the EHORP 1159 Option, compared to the locally stored values, and supercede them if 1160 necessary to form the TORA UDU. Note that the Unicast-Directed 1161 Update (UDU) and the UDU-Ack (UDUA) messages are MER TORA-specific 1162 host route redirection messages equivalent to the RU/RUA messages of 1163 the general EMA:MER hand-over model [EMA]. The remainder of this 1164 document assumes TORA is the EMA:MER algorithm. This is sent to the 1165 OAR and on the way installs the host route for the EMA CCoA into 1166 intermediate routers. The UDU reaches the OAR which informs the OAR 1167 of the successful installation of the host route. The OAR returns a 1168 UDU-ack directly to the NAR to confirm TORA hand-over. This results 1169 in the BU-Ack with associated EHORP information being sent to the 1170 MN. 1172 The UDU might in contrast indicate a routing failure, or the OAR may 1173 for local reasons need to cancel the hand-over, which causes the OAR 1174 to return a UDU-Nack to the NAR. UDU-Nack, signalling time-out(s) or 1175 policy failures result in either retries or host route clear-out and 1176 a suitable BU / EMA EHORP being returned to the MN via the NAR. A 1177 horizontal tunnel installation failure is intended to be orthogonal 1178 to TORA hand-over failure and it is only the latter which should 1179 cause the MN to abandon the EMA CCoA. In this case, the MN resorts 1180 to normal MIP processing and moves to the nCCoA before sending a 1181 Vertical BU to the HA to install the new CCoA binding. In all other 1182 cases, the MN can start sending natively using the EMA CCoA as a 1183 source address when it receives a successful EMA EHORP Option. 1185 The MN can track the progress of any hand-over by the type of 1186 packets being received via the NAR. Packets destined for the MN will 1187 be received encapsulated to the local CCoA until the MER routed 1188 hand-over is completed, at which point they will be received 1189 natively to the EMA CCoA. The MN can use the EMA CCoA as a source 1190 address as soon as the EMA EHORP Option opens the NAR ingress filter 1191 for the EMA CCoA which should occur before the MN receives the EMA 1192 EHORP. The EHORP may contain modified MER information that 1193 supercedes that in the MN. 1195 O'Neill, Corson, Tsirtsis 23 1196 MN NAR OAR 1197 | | | 1198 |<---RA(NAI,MR)-------| | MN moves to NAR 1199 | | | 1200 |-----RBU/EHORQ)----->| | Routing Header sends 1201 | |---RBU/EHORQ/AAA)-->| BU to NAR and OAR. 1202 | |<-RBUAck/EHORP/AAA--| Horizontal tunnel set. 1203 |<--RBUAck/EHORP------| | MN can send packets. 1204 | |-------UDU--------->| Install host route. 1205 | |<------UDUA---------| Confirm host route. 1207 **Overview of Packet Structures - Illustrative only** 1209 The MN Sends to NAR: 1210 Source Address = MN CCoA at NAR 1211 Destination Address = NAR 1212 Destination Options: 1213 EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd 1214 Routing Option = OAR 1215 Destination Options: 1216 Binding Update = H, A, bits set 1217 Home Address = EMA CCoA 1219 The NAR Sends to OAR: 1220 Source Address = MN CCoA at NAR 1221 Destination Address = OAR 1222 Destination Options: 1223 EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd 1224 AAA Request = tbd 1225 Routing Option = NAR 1226 Destination Options: 1227 Binding Update = H, A, bits set 1228 Home Address = EMA CCoA 1230 The OAR Sends to NAR: 1231 Source Address = OAR 1232 Destination Address = NAR 1233 Destination Options: 1234 EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd 1235 AAA Response = tbd 1236 Routing Option = IP1: MN CCoA at NAR 1237 IP2: MN EMA CcoA 1238 Destination Options: 1239 Binding Ack = ok 1241 The NAR Sends MN: 1242 Source Address = OAR 1243 Destination Address = MN CCoA at NAR 1244 Destination Options: 1245 EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd 1246 Routing Option = IP1: NAR 1247 IP2: MN EMA CCoA 1248 Destination Options: 1250 O'Neill, Corson, Tsirtsis 24 1251 Binding Ack = ok 1253 The MN Sends MN: 1254 Source Address = OAR 1255 Destination Address = MN EMA CCoA 1256 Destination Options: 1257 EMA hand-over response = tau, OAR, EMA CCoA, NAI's, status, tbd 1258 Routing Option = IP1: NAR 1259 IP2: MN CCoA at NAR 1260 Destination Options: 1261 Binding Ack = ok 1263 7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted) 1265 In this case, the MN is trusted a priori to identify the OAR, track 1266 the number of hand-overs for its EMA CCoA session address, and then 1267 securely provide that number and the OAR to the NAR. The number is 1268 converted at the NAR into the TORA hand-over routing parameter (Tau 1269 Height) which is required for the TORA UDU message to install the 1270 host redirect route back to the identified OAR. The NAR immediately 1271 and simultaneously sends the RBU and UDU towards the OAR. The OAR 1272 may still undertake local checks to confirm the validity of the Tau 1273 value from a semantic and policy perspective. This sequence of 1274 actions avoids the round trip to the OAR to acquire the last Tau and 1275 for the OAR to check the validity of the hand-over. The reverse BU 1276 is still sent to the OAR to fetch any additional 'policy' 1277 configuration for the mobile, and optionally to validate the hand- 1278 over in parallel with the injection of the host route. 1280 In detail, the MN arrives unannounced at the NAR and receives a 1281 Router Advertisement containing the NAI of the NAR and with the MR 1282 bit set. It may optionally send a Router Solicitation to stimulate 1283 this RA. The MN forms a new CCoA at the NAR which it can use 1284 temporarily and as a source address for MIP signalling and 1285 forwarding (Home Address Option = EMA CCoA), and for receiving 1286 horizontally forwarded packets from the OAR and directly forwarded 1287 packets from CN's. The MN then sends a Reverse Binding Update to the 1288 OAR via the NAR using a packet containing a Routing Header and an 1289 EMA EHORQ Destination Option. The EMA hand-over Request is 1290 authenticated and processed by the NAR and the OAR and Tau 1291 information is locally checked (are valid and allowed from policy 1292 perspective). The Tau value and OAR address are then copied from the 1293 RBU packet and used to form the TORA UDU. This is sent to the OAR 1294 and on the way installs the host route for the EMA CCoA into 1295 intermediate routers. 1297 In parallel, the RBU packet is sent to the OAR as per normal MIP 1298 horizontal processing to install temporary forwarding from the EMA- 1299 CCoA to the MN via the nCCoA at the NAR. The OAR checks the hand- 1300 over request and installs the horizontal forwarding state with a 1301 suitably short life-time. A BUAck is then sent from the OAR to the 1302 MN via the NAR using a Routing Header containing the MN nCCoA and 1303 the EMA CCoA. The Bu-ack packet also contains an EMA Hand-over 1305 O'Neill, Corson, Tsirtsis 25 1306 Response Destination Option and an AAA Response Destination Option. 1307 This packet acts to report the status of the EMA hand-over to the 1308 NAR and the MN, and to provide IP session information (policy) to 1309 the NAR. The AAA Response Option and EMA Hand-over Response Option 1310 are processed by the NAR and then the NAR forwards the BUAck to MN 1311 with the updated status of the hand-over. 1313 In parallel, the UDU reaches the OAR which informs the OAR of the 1314 installation of the host route. The OAR returns a UDU-ack directly 1315 to the NAR to formalise completion of the TORA hand-over. The UDU 1316 might in contrast indicate a routing failure, or the OAR may for 1317 local reasons need to cancel the hand-over, which causes the OAR to 1318 return a UDU-Nack to the NAR. For example, an OAR check of the tau 1319 value may be incompatible with its tau value (e.g. not fresh enough 1320 due to some error). Then the OAR sends a UDU-Nack erasing the 1321 injected route and informing the NAR of injection failure and 1322 providing the NAR with a feasible Tau value. Such a UDU-Nack, 1323 signalling time-out(s) or policy failures result in either retries 1324 or host route clear-out and a suitable BU / EMA hand-over response 1325 being returned to the MN via the NAR. A horizontal tunnel 1326 installation failure is intended to be orthogonal to TORA hand-over 1327 failure and it is only the latter which should cause the MN to 1328 abandon the EMA CCoA. In this case, the MN resorts to normal MIP 1329 processing and moves to the nCCoA before sending a Vertical BU to 1330 the HA to install the new CCoA binding. In all other cases, the MN 1331 can start sending natively using the EMA CCoA as a source address 1332 when it receives a successful EMA Hand-over Option. 1334 MN NAR OAR 1335 | | | 1336 |<-RA(NAI,MR)------- | | MN moves to NAR 1337 | | | 1338 |----RBU/EHORQ)------>| | Routing Header sends 1339 | |---RBU/EHORQ/AAA)-->| BU to NAR and OAR. 1340 | |-------UDU--------->| Install host route. 1341 | |<-RBUAck/EHORP/AAA)-| BU contains AAA info. 1342 | |<------UDUA---------| Confirm host route. 1343 |<--RBUAck/EHORP------| | MN can send packets. 1345 **Overview of Packet Structures - Illustrative only** 1347 Packet structures are the same as for the unassisted case, as only 1348 local processing in the NAR and the timing of the UDU changes. 1350 7.2.3 Planned Forward Hand-over (MBB or BBM) 1352 Planned hand-over occurs as a result of predictive (or explicit 1353 forward hand-over) processing which enables the MN (or a network 1354 controller element) to know in advance to which NAR a MN MAY hand- 1356 O'Neill, Corson, Tsirtsis 26 1357 over in case of MN assist (or MUST hand-over in case of network 1358 control). 1360 In the case of MN assisted hand-over, the MN needs to have either 1361 (1) concurrent connectivity in the IP signalling plane to both the 1362 OAR and the NAR (this ensures the MN knows its nCCoA) to achieve a 1363 planned hand-over or possibly (2) connectivity in the IP signalling 1364 plane to the OAR and link layer connectivity to the NAR from which 1365 the MAC address of the NAR can be obtained. In the latter case the 1366 MN can signal the MAC address to the OAR. From previous hand-over 1367 activity, the OAR may know the IP prefix (or CoA) of this NAR from 1368 which it can derive the MN's future nCCoA at the NAR. The MN hand- 1369 over tunnel is now rooted (i.e. initiated) at the OAR with the aim 1370 of setting up optional MIP forwarding to the NAR. MER host route 1371 redirection is still rooted at the NAR. Failure of the forward 1372 processes during hand-over still enables the MN to recover cleanly 1373 through an unplanned hand-over completely rooted at the NAR. 1375 The MN now arrives unannounced at the NAR. 1377 If the IP signalling plane is UP, the MN receives a Router 1378 Advertisement containing the NAI of the NAR and with the MR bit set. 1379 It may optionally send a Router Solicitation to stimulate this RA. 1380 The MN forms a new CCoA at the NAR which it can use temporarily and 1381 as a source address for MIP signalling and forwarding (Home Address 1382 Option = EMA CCoA), and for receiving horizontally forwarded packets 1383 from the OAR and directly forwarded packets from CN's. The MN then 1384 sends a Forward Binding Update to the OAR directly over it's old 1385 link, using a packet containing an EMA Hand-over Request (EHORQ) 1386 Destination Option. The FBU contains an alternate CCoA suboption 1387 which contains the nCCoA at the NAR which was determined by the MN 1388 from the Router Advertisment over the new link. This message is 1389 equivalent to the HTIN message of the EMA draft. 1391 If the IP signalling plane is not UP, the MN receives a link layer 1392 advertisement containing the MAC address of the NAR. It may 1393 optionally send a link layer message to stimulate this 1394 advertisement. The MN then sends this address to the OAR directly 1395 over its old link, using a nearly FBU-equivalent packet containing 1396 an EMA EHORQ Destination Option. 1398 Note that the MN could in fact present multiple NAR options to the 1399 OAR concurrently from which the OAR could select based on local or 1400 remote information. Alternatively the MN could instruct the OAR to 1401 build multiple tunnels if it is unsure of the ultimate NAR to which 1402 it will hand-over. 1404 The EHORQ is authenticated and processed by the OAR. The NAR and Tau 1405 information is locally checked (are valid and allowed from policy 1406 perspective). 1408 If only the NAR's MAC address is known, the OAR checks to see if it 1409 has a cached IP address prefix for that MAC address. If so, packets 1411 O'Neill, Corson, Tsirtsis 27 1412 sent with that MAC address can now be considered as fully FBU- 1413 equivalent. Otherwise, the packet is dropped and the forward 1414 process terminates. 1416 The FBU (or its equivalent) is used to install temporary MIP 1417 horizontal forwarding from the EMA-CCoA at the OAR to the MN via the 1418 nCCoA at the NAR. A BUAck is then sent from the OAR to the MN via 1419 the NAR using a Routing Header containing the MN nCCoA and the EMA 1420 CCoA. The Bu-ack packet also contains an EMA Hand-over Response 1421 (EHORP) Destination Option and an AAA Response Destination Option. 1422 This packet acts to report the status of the EMA hand-over to the 1423 NAR and the MN, and to provide IP session information (policy) to 1424 the NAR. The AAA Response Option and EMA EHORP Option are processed 1425 by the NAR and then the NAR forwards the BUAck and the EMA Hand-over 1426 Response to MN with the updated status of the hand-over. 1428 Absent receipt of the EMA EHORP via the NAR and the new link, the MN 1429 can send an RBU packet back to the OAR via the NAR as per unplanned 1430 hand-over, and the remaining processing is per unplanned hand-over. 1431 If FBU state is already present on receipt of the RBU at the NAR (as 1432 the NAR would have processed this packet because to the routing 1433 header), then the NAR need not forward RBU to the OAR. 1435 In MBB, the OAR to NAR tunnel is only used if the old link goes down 1436 before the UDU is received which itself is triggered by the layer 3 1437 Make at the NAR (MN-RBU). In BBM, the RA and the EMA Hand-over 1438 Option must be advertised over a new link signalling channel (as the 1439 data channel does not yet exist). The OAR to NAR tunnel is used when 1440 the old data link goes down, and until the new IP data link is 1441 installed by sending the EMA Hand-over Request over the new link and 1442 the host route is successfully installed. 1444 In the case of network-controlled hand-over, it is the controller 1445 that sends the FBU to the OAR on behalf of the MN. This is a 1446 network-generated message somewhat equivalent to the HTIN of the EMA 1447 draft, only that its generated by the network and not the MN. 1448 Processing then continues as above with the additional step being 1449 that an acknowledgement is sent to the Controller from the OAR when 1450 the BU packet is successfully processed by that OAR. The methods by 1451 which the controller identifies the best target NAR, or set of NARs, 1452 is outside the scope of this draft but movement prediction, radio 1453 channel measurements and cell / channel occupancies are obvious 1454 contributors. 1456 O'Neill, Corson, Tsirtsis 28 1457 MN OAR NAR 1458 | | | 1459 |<-RA(NAI,MR)------------------------------| MN senses NAR 1460 | | | 1461 |------FBU/EHORQ----->| | FBU to OAR on old link. 1462 | | | Compared to stored 1463 | | | state 1464 | |---FBU/EHORP/AAA--->| Horizontal tunnel set. 1465 |<--------------FBUAck/EHORP---------------| Offer hand-over to MN 1466 | | | over new link 1467 | | | 1468 |-----------------RBU/EHORQ--------------->| MN requests hand-over 1469 | | | over new link. 1470 | |<-------UDU---------| Install host route. 1471 | |-------UDUA-------->| Confirm host route. 1472 |<--------------RBUAck/EHORP---------------| MN can send packets. 1474 **Overview of Packet Structures - Illustrative only** 1476 The MN Sends to OAR: 1477 Source Address = MN CCoA at OAR 1478 Destination Address = OAR 1479 Destination Options: 1480 EMA hand-over Request = Tau, NAR, EMA CCoA, NAI's, tbd 1481 Binding Update = H, A, bits set 1482 Alternate CCoA suboption = MN CCoA at NAR 1483 Home Address Option = EMA CCoA 1485 The OAR Sends to NAR: 1486 Source Address = OAR 1487 Destination Address = NAR 1488 Destination Options: 1489 EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd 1490 AAA Response = 1491 Routing Option = IP1: MN CCoA at NAR 1492 IP2: EMA CcoA 1493 Destination Options: 1494 Binding Ack = Ok 1496 The NAR Sends MN: 1497 Source Address = OAR 1498 Destination Address = MN CCoA at NAR 1499 Destination Options: 1500 EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd 1501 Routing Option = IP1: NAR 1502 IP2: EMA CcoA 1503 Destination Options: 1504 Binding Ack = ok 1506 The MN Sends to MN: 1507 Source Address = MN CCoA at NAR 1509 O'Neill, Corson, Tsirtsis 29 1510 Destination Address = EMA CCoA 1511 Destination Options: 1512 EMA hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd 1513 Routing Option = IP1: NAR 1514 IP2: MN CCoA at NAR 1515 Destination Options: 1516 Binding Ack Option = ok 1518 Start of reverse phase - as per unplanned hand-over (MN trusted) 1520 The MN Sends to NAR: 1521 Source Address = MN CCoA at NAR 1522 Destination Address = NAR 1523 Destination Options: 1524 EMA Hand-over Request = Tau, OAR, EMA CCoA, NAI's, tbd 1525 Routing Option = OAR 1526 Destination Options: 1527 Binding Update = H, A, bits set 1528 Home Address = EMA CCoA 1530 Matched to forward state in NAR and UDU triggered etc. 1532 7.2.4 Moving into an EMA domain - MN Supports EMA extensions 1534 This means that the MN understands the single bit EMA flag 1535 indicating that no additional CCoA should be acquired as the MN 1536 moves through the domain. We can therefore use EMA to move the CCoA 1537 throughout the domain so that the inter-domain tunnel (to the non- 1538 EMA domain) moves with the address. 1540 MN AR2(d2) AR1(d2) AR(d1) HA 1541 |<-RA(NAI,MR)--------------| | | New domain, get CCoA 1542 | | | | | 1543 |----BU(horizontal)--------------->| | Inter-domain MIP 1544 |<--------BAck---------------------| | 1545 | | | | | 1546 |----BU(HA-CCoA)-------------------------->| Vertical BU for CoA 1547 |<---BAck----------------------------------| 1548 | | | | | 1549 | | | | | 1550 |<-RA(NAI,MR)-----| | | | MN moves to AR2(d2) 1551 | | | | | 1552 |-----------RBU/EHORQ----->| | | Intra-domain h/over 1553 | | | | | Horizontal tunnel set 1554 |<------RBUAck/EHORP-------| | | TORA h/over request 1555 | |--UDU-->| | | Install host route 1556 | |<-UDUA--| | | Confirm host route 1558 No vertical BU is required on movement to AR2 as CoA is still valid 1559 through MER host route. 1561 O'Neill, Corson, Tsirtsis 30 1562 7.2.5 Moving into an EMA domain -MN does not support EMA extensions 1564 We can build new MIPv6 forwarding tunnels in the new domain as for a 1565 non-EMA domain. The MN will act as per normal MIPv6 and will not 1566 recognise the single bit EMA flag in the RAs. This means that each 1567 time the MN changes AR a new CCoA will be created and a new 1568 forwarding tunnel must be built between adjacent CoRs. The 1569 originator and terminator of the inter-domain tunnel remains the 1570 same and can only be removed when traffic and/or bindings cease. The 1571 MN must also send BU's and registrations to the HA and CN's so that 1572 indirect vertical and direct MIP forwarding can be maintained and 1573 the forwarding tunnel can be dropped. This, of course, throws away 1574 the benefits of EMA routing. The resultant signalling sequence is 1575 precisely the same as above except that the MN does not request 1576 EMA:MER hand-over so the OAR and NAR do not produce the TIN, UDU or 1577 UDUAck. 1579 7.2.6 EMA MN has a CRCoA from a previous domain 1581 In this case the inter-domain hand-over is from an EMA domain to any 1582 type of domain. The MN undertakes the horizontal inter-domain hand- 1583 over for packets addressed to the CCoA in the previous domain to be 1584 sent to the new CCoA in this domain. In parallel, the MN sends a BU 1585 to the AAR in the previous domain requesting the conversion of the 1586 CCoA in the previous domain into a CRCoA and the associated 1587 provision of HA-like services. If accepted, a persistent horizontal 1588 tunnel will be built between the AAR and the MN and the host route 1589 in the previous domain can be cleared out. Movement to another AR in 1590 the new domain requires a temporary horizontal BU to be installed 1591 for both the oCCoA and the CRCoA at the previous AR, to forward 1592 packets to the nCCoA at the new AR. In parallel, the MN will need to 1593 update the binding for the persistent horizontal tunnel for the 1594 CRCoA. 1596 MN AR2(d2) AR1(d2) OAR(d1) AAR(d1) 1597 |<-RA(NAI,MR)--------------| | | New domain, get CCoA 1598 | | | | | 1599 |----BU(horizontal for new CCoA--->| | Inter-domain MIP 1600 |<--------BAck---------------------| | 1601 | | | | | 1602 |----BU(CRCoA-CCoA)----------------------->| Persistent BU for CRCoA 1603 |<---BAck----------------------------------| VBU for HA not shown 1604 | | | |<----->| Clear out host route 1605 |<-------------------------------->| | HBU removed by OAR 1606 |<-RA(NAI,MR)-----| | | | MN moves to AR2(d2) 1607 | | | | | 1608 |--BU(CCoA/CRCoA)--------->| | | Dual CoA Horizontal BU 1609 |<---BUAck-----------------| | | Horizontal tunnel set 1611 O'Neill, Corson, Tsirtsis 31 1612 7.3 Source Address Selection Rules 1614 We have already seen that a MN will always have a globally unique 1615 Home Address while it will also have a new CCoA in every foreign EMA 1616 domain it visits, at least for as long as it is using them. It might 1617 also have a number of other CCoAs from non-EMA domains as it moves 1618 around. The obvious question that arises is how does the MN know 1619 which address to use and when. 1621 Here are the simple "policy rules" that the MN MUST follow. Note 1622 that these are superseding the "Source Address Selection" rules as 1623 defined in [SEL]. 1625 i. CCoAs from non-EMA domain SHOULD NOT be used as source address, 1626 as defined by [MIPv6] 1628 ii. A CCoA from an EMA domain (EMA CCoA) SHOULD be used as source 1629 address. 1631 iii. The Home Address of the MN MUST be used as source address when 1632 the MN is in a non-EMA domain but it SHOULD NOT be used as 1633 source address when the MN is in an EMA domain; the EMA CCoA 1634 SHOULD be used instead as defined in (ii). 1636 iv. Once a CCoA becomes a CRCoA, by the MN moving out of an EMA- 1637 Domain, this address SHOULD be regarded by the MN as a 1638 deprecated address, i.e.: the MN MAY use it to maintain existing 1639 sessions but MUST NOT use it as source address in new sessions. 1640 This will ensure that the persistent horizontal tunnel will be 1641 as short lived as possible. The new CCoA in the new domain 1642 should be used instead as defined in (ii) for EMA domains, or 1643 else the Home Address MUST be used if the new domain is a non- 1644 EMA domain as defined in (iii) 1646 The above rule-set ensures that a MN always takes advantage of the 1647 functionality of EMA-Domains and thus, mostly communicates natively 1648 and with minimum use of tunnels whilst communications are 1649 maintained, and as the MN moves between different EMA and non-EMA 1650 domains. 1652 7.4 Implications of EMA:MIPv6 Convergence on MIPv6 1654 The implications of EMA:MIP convergence as outlined in this draft 1655 can be summarised as follows; 1657 i. We need the MIPv6 RA to advertise the EMA capability of each AR 1658 to MN's. 1660 ii. We need the AR to advertise its NAI so that a MN can determine 1661 the nature of it's last hop (intra or inter-domain) and the 1662 applicability of its present EMA CCoA and any other CCoA or CRCoA's. 1664 O'Neill, Corson, Tsirtsis 32 1665 iii. The IPv6 stack needs to be able to track and distinguish CRCoAs 1666 as well as CCoAs and HAs, and deprecate them on leaving an EMA 1667 domain. In addition, it needs to recognise opportunities to re-use 1668 these addresses on returning to a previously visited domain. 1670 iv. The IPv6 stack needs to be able to apply appropriate source 1671 address selection rules so that the EMA CCoA is preferred to either 1672 the HA or local CCoA for data traffic in an EMA domain. 1674 v. Packets containing EMA signalling options need to be processed by 1675 the NAR in either direction (MN<-> OAR over new link). MIPv6 1676 signalling options will likely also be in these packets and 1677 opportunities for potential convergence could be explored. A routing 1678 header is used to control NAR visitation. 1680 vi. MIPv6 temporary horizontal forwarding needs to be extended to 1681 enable an additional persistent tunnel to be installed to the AAR 1682 when leaving an EMA domain. HA's on AR's must be prepared to support 1683 horizontal tunnels to support 'loss-less' intra and inter-domain 1684 hand-over. 1686 vii. The ability of the MN to automatically use its HA as the EMA 1687 CCoA session address whilst in its home domain requires the BU to 1688 support such messaging without confusing this with an instruction to 1689 cancel ALL bindings. 1691 viii. MIPv6 Destination Options have specific processing and 1692 security rules which will affect the degree of integration and 1693 piggy-backing that can be achieved with EMA Options. 1695 ix. The Forward BU via the old link appears to be permissible from 1696 the base MIPv6 specification but this draft details this option in 1697 the EMA context. 1699 x. The policy controls required to manage the multiple Internet 1700 Service options that are possible with EMA:MIP have not been fully 1701 explored but contain a super-position of well established models. 1703 7.5 Ongoing work 1705 We are presently assessing the type, structure and ordering of the 1706 Destination Options to provide the required functionality and secure 1707 data exchange for EMA, whilst ensuring backwards compatibility with 1708 standard MIPv6. 1710 In addition, to speed up generation of the vertical BU to the HA, we 1711 are examining a model (as in MIPv4 with R bit set) in which the 1712 vertical BU automatically triggers the horizontal BU at the NAR 1713 which may yield additional benefits. 1715 O'Neill, Corson, Tsirtsis 33 1716 We need a MN to report it's AAA information, height, optional EMA 1717 hand-over Request, amongst other parameters, in parallel with the 1718 Binding Updates. 1720 We need a MN to be able to store and use CRCoA's when leaving an EMA 1721 domain when using an EMA CCoA as an active session address, and co- 1722 existence of this within the overall model needs additional 1723 investigation. 1725 We also need to further consider the use of the Home Address as a 1726 CCoA when in the home domain, and the interactions with multiple 1727 concurrent CCoA's. 1729 We need to further consider the various failure modes in the 1730 unplanned and planned message sequences. 1732 8. EMA enhanced MIPv4 1734 On boot up the MN must acquire a CCoA from DHCP and register the 1735 CCoA in its HA as normal. The CCoA belongs to the subnet of the AR 1736 the MN is connected to during boot up. This AR therefore becomes the 1737 Allocating Access Router (AAR) as far as EMA is concerned for the 1738 duration of the active IP session. In the special case of a home EMA 1739 domain, the MN may request to use it's home address as the CCoA. The 1740 EMA domain is a fully mobile enhanced routed (MER) network so the 1741 CCoA is now valid throughout the domain by using IP hand-over to 1742 control host redirect routes. This offers a number of significant 1743 advantages. 1745 - Fast hand-over: Avoids the need for the MN to get a new CCoA at 1746 each new AR. This is very important since CCoA in MIPv4 are 1747 allocated by DHCP, which introduces potentially significant delays 1748 in the hand-over process. 1750 - Less HA signalling: Normally, on each hop the CCoA would have to 1751 be registered to the HA of the MN as per normal MIPv4. With EMA- 1752 enhanced MIP the CCoA is registered once on the first AR. After that 1753 no more registration of the CCoA is needed. 1755 - Less CN Signalling: For the same reasons as above after the 1756 initial CCoA allocation, the MN does not need to forward bindings to 1757 HA and CNs whilst in a single domain (and in session) which is also 1758 a big win. Note that this also impacts the performance of CNs that 1759 otherwise might not be able to cope with the repeated BUs due to 1760 continues CCoA change. 1762 - Address Utilisation: As a configurable utilisation feature of EMA, 1763 a CCoA is only valid for as long as the MN is in a session. If the 1764 MN becomes inactive, the CCoA is returned and the host redirect 1765 state associated with it is removed. This makes sure that the 1766 limited IPv4 address space is highly utilised. When the MN wants to 1768 O'Neill, Corson, Tsirtsis 34 1769 initiate a new session, it will have to get a new CCoA from DHCP and 1770 re-register it in the HA. 1772 Firstly, to gain the above benefits we need to prevent MIPv4 1773 changing CCoA at each new AR (while in the same domain). Two 1774 mechanisms could be used: 1776 MIP based: MIPv4 could be extended to support the following 1777 behaviour. The ARs would need to run MIPv4 but the Agent 1778 Advertisements would include an EMA specific extension: This would 1779 (a) cause the MN to look for a CCoA (b) instruct the MN not to 1780 change its CCoA if it already has one from this domain. (c) indicate 1781 the AR's NAI in the form (ARx@realm) to inform the MN when it 1782 changes domains. In fact the NAI may actually be advertised in the 1783 AA. 1785 DHCP based: In this case the ARs of the EMA domain do not send Agent 1786 Adverts (AAs). As per normal MIPv4 the MN will attempt to get a CCoA 1787 from DHCP. DHCP normal behaviour causes the client to try to re-use 1788 its existing address anyway. Note that the AAA/DHCP mechanisms could 1789 be used hop by hop to determine when/if the MN changes domain and 1790 thus have to change CCoA.. 1792 It is clear that, although conceivable, none of the above solutions 1793 are as optimal as the one based on MIPv6. 1795 8.1. Basic EMA Extensions to MIPv4 1797 MR Flag Extension to Routing Advertisement: 1799 To gain the above benefits we need to prevent MIPv4 changing CCoA 1800 at each new AR (while in the same domain). With MIPv4 signalling 1801 a single bit flag in the Agent Advertisement could indicate to 1802 the mobile to send the Binding Update message to its HA as normal 1803 but using its current CCoA rather than creating a new one. We 1804 will call this the "Mobile Routing-MR" flag . Note that this can 1805 also be re-used by HAWAII, Cellular IP and other micro-mobility 1806 protocols 1808 NAI Extension to Routing Advertisements: 1810 The MN every time it detects a NAR, it will have to determine if 1811 it is in the same or different domain with the previous AR. This 1812 can be accomplished by an NAI extension to the Agent 1813 Advertisements of the Access Router. 1815 8.2 MIPv4 Hand-over Examples 1817 Firstly, the following overview of MIPv4 hand-over represents our 1818 present view of how we believe this might work, rather than how it 1819 should work with present/future MIPv4 specifications. It is 1820 therefore very likely that significant changes may be required to 1822 O'Neill, Corson, Tsirtsis 35 1823 meet the need for backwards compatibility, security, evolution to 1824 MIPv6 and optimised performance. 1826 Secondly, the lack of efficient and feature-rich header extension 1827 processing in MIPv4 requires us to mandate the setting of the R bit 1828 in Agent Advertisements to force all registrations to go via the 1829 NAR. Horizontal Binding updates in MIPv4 are then triggered by 1830 vertical registrations in the NAR, with TORA hand-over failures 1831 causing the Vertical registration to progress to the HA, and 1832 successes causing the vertical registration to be answered by the 1833 NAR. 1835 Thirdly, the following examples assume that the MN must acquire a 1836 CCoA from the NAR. It may be possible to avoid this if we terminate 1837 the temporary horizontal tunnel on the NAR in EMA domains resulting 1838 in a hybrid CoA / EMA CCoA model. The MN instead uses the CoA of the 1839 NAR in signalling messages where necessary, and uses it's EMA CCoA 1840 as the source address in registrations over the old and new links. 1841 This approach, if clean, will delay and limit CCoA DHCP allocations 1842 to those situations in which the EMA hand-over fails and a new CCoA 1843 is required at the NAR/MN for a long term vertical binding. We would 1844 expect the NAR to undertake this address allocation on behalf on the 1845 MN and populate the necessary fields in the vertical registration 1846 messages. 1848 These various issues need significant further study and indicate our 1849 preference for MIPv6 based hand-over and optimisations. 1851 8.2.1 Unplanned Reverse Hand-over (MN not trusted) 1853 The MN arrives at the NAR unannounced as in the MIPv6 case and sees 1854 the MR bit and R bit set. The MN sends a Registration Request (RRQ) 1855 to the new FA (nFA) with source address of the nFA CCoA, requesting 1856 EMA hand-over of the existing EMA CCoA. The RRQ is authenticated by 1857 the nFA and hand-over parameters checked. The RRQ then Triggers 1858 Reverse BU containing PFANE to the old FA (oFA), with EMA HO 1859 extension to request height and AAA config which is returned in the 1860 BUack packet. The BUack packet contents confirms/denies EMA hand- 1861 over and the status of the horizontal tunnel. Confirmed EMA hand- 1862 over triggers the UDU to the OAR using the height information from 1863 the OAR, and Registration Reply (RRP) to the MN. Denied EMA hand- 1864 over triggers the RRQ to progress, somewhat delayed, to the HA to 1865 update binding. UDU-ack, completes routing hand-over. UDU-Nack, 1866 time-out or policy failure results in retries or host route clear- 1867 out and RRQ to HA for new CCoA binding at the nFA. 1869 8.2.2 Unplanned Reverse Hand-over (MN / NAR) 1871 O'Neill, Corson, Tsirtsis 36 1872 In this case, we progress as above but because the NAR trusts the MN 1873 it can use the height and OAR information in the RRQ to immediately 1874 trigger the UDU in parallel to the Reverse BU. 1876 8.2.3 Planned Forward Hand-over (MBB or BBM) 1878 As in the case of MIPv6, the MN detects the new link and uses nFA 1879 MAC information or agent advertisement information to send a Forward 1880 BU to the OAR over the old link requesting an EMA hand-over to the 1881 nFA CCoA allocated to the MN. Note that this forward BU and EMA 1882 hand-over request are different from the messages suggested in the 1883 pro-active draft although we plan to revisit this issue later given 1884 the need for network triggered hand-over. The OAR then sends the 1885 FBUack to the NAR as in MIPv6 and includes the height and AAA 1886 information in the forward message. The NAR processes this data as 1887 before and forwards an EMA Hand-over response to the MN over the new 1888 link. 1890 The MN responds by sending a RRQ to nFA with source address of nFA 1891 CCoA, requesting EMA hand-over of existing EMA CCoA. The RRQ is 1892 authenticated by the nFA and matched to the FBUack state which 1893 triggers the UDU and RRP as in 8.2.2. Unmatched state causes the nFA 1894 to resort to unplanned reverse handover. Subsequent failure results 1895 in the progression of the RRQ, somewhat delayed, to the HA. 1897 9. MIPv6 vs MIPv4 in respect to EMA 1899 MIPv6 provides EMA with a number of significant advantages over 1900 MIPv4 that have been highlighted throughout this document. Here we 1901 summarise and highlight the most important benefits. 1903 Fast start-up: IPv6 Routing Advertisements (RAs) provide the MN with 1904 much faster IPv6 address configuration than in IPv4 that needs DHCP. 1906 Easy EMA extension: IPv6 Routing Advertisements (RAs) provide EMA 1907 with an ideal signal for the "single bit EMA flag" needed to 1908 indicate to the MN that should not try to change its CoA while in 1909 the EMA domain. 1911 Simpler interoperability: the fact that MIPv6 does not rely on FAs 1912 and CoAs simplifies the design and the interoperability with non-EMA 1913 domains 1915 Abundance of addresses: EMA requires address allocation to be done 1916 from within the prefix range of the AAR . IPv6's abundance of 1917 addresses makes it so much easier compared to its IPv4 equivalent. 1919 O'Neill, Corson, Tsirtsis 37 1920 10. Security Considerations 1922 The mechanisms described above can re-use mobile IP and AAA 1923 mechanisms as proposed in [AAAMIP] and [CIP] since the requirements 1924 and level of security required are similar. It is expected that the 1925 EMA Hand-over and AAA options will need to be protected within the 1926 network and over the air interface to prevent a range of attacks, 1927 and IPSEC AH and ESP are to be investigated for this purpose. 1929 10.1 Authenticating users within a domain 1931 Associated with each mobile node (MN) is a unique identifier known 1932 as its Mobile ID (MID). This is taken here to be an IPv6 address 1933 (which may or may not be associated with an interface), but which 1934 may also be a Network Access Identifier (NAI). 1936 On arrival at a NAR, a MN must first either furnish proof of prior 1937 authentication within the domain, or be initially authenticated 1938 before it may send or receive any form of control or data traffic. 1939 Proof of prior authentication may be readily available in the form 1940 of a pre-paid SIM card or from a MN's private authentication key (as 1941 described subsequently). 1943 To perform an authentication check, the MN must present its 1944 credentials (including its MID) to the NAR. The method to conceal 1945 these items over the air interface is not addressed here. 1947 This transmission also advertises its current CCoA (if any) which it 1948 may have auto-generated on arrival at this NAR. Consequently, this 1949 authentication information may be passed to the NAR with a CCoA 1950 (IPv6), or with a NULL source address (IPv4) as is commonly done 1951 with DHCP. In the latter case the NAR (acting as a proxy for the 1952 MN) substitutes its address for the NULL address. The NAR then 1953 forwards the information to the local authentication server with 1954 which it already has a Security Association (SA). 1956 The local authentication server may then contact other servers as 1957 necessary to perform the authentication check. The outcome of the 1958 check (along with the MN's public key) is returned to the NAR. If 1959 successful, the NAR computes a Private Authentication Key (PAK) for 1960 the MN as an MD5 hash of the MN's MID and the domain's private 1961 "network key" known to all domain ARs. The computation of PAK and 1962 PIK herein are based on the PID scheme of [CIP]. The PAK forms a 1963 shared secret known only to the MN and the network, and serves as 1964 proof of MN authentication to other NARs in the domain. 1965 Unsuccessful authentication results in service denial. 1967 After a successful authentication, the NAR checks the MN's CCoA and, 1968 if NULL (IPv4), allocates a new CCoA for the MN. Using the resultant 1969 CCoA, the NAR computes a Private Identification Key (PIK) for the MN 1970 as an MD5 hash of the MN's CCoA and the domain's private "network 1971 key" known to all domain ARs, encrypts the PIK and PAK with the MN's 1973 O'Neill, Corson, Tsirtsis 38 1974 public key, and sends these to the MN along with the network's 1975 public key and the MN's CCoA. Being keyed to the MN's CCoA, the PIK 1976 is valid as long as the MN uses this CCoA. The PIK can be used to 1977 authenticate (and optionally to encrypt) IP control packets over the 1978 air interface. Authentication is performed by creating a short hash 1979 from the (PIK, timestamp, packet content) triple that is placed into 1980 the transmitted packets. The validity of each packet can be easily 1981 checked by any NAR even immediately after a handoff and without 1982 prior communication with the MN or with the OAR. 1984 In addition to authenticating control packets, the PIK can 1985 optionally also be used to provide security for data packets 1986 transmitted over the wireless link. To this avail, any known, 1987 shared secret-based security mechanism can be used where the PIK 1988 serves as the shared secret. 1990 11. References 1992 [AAAMIP] S. Glass, et al., "Mobile IP Authentication, Authorization, 1993 and Accounting Requirements", Internet-Draft, draft-ietf-mobileip- 1994 aaa-reqs-04.txt (work in progress), June, 2000. 1996 [CIP] A. Campbell, et al., "Cellular IP", Internet-Draft, draft- 1997 ietf-mobileip-cellularip-00.txt (work in progress), January, 2000. 1999 [EMA] A. O'Neill, G. Tsirtsis, S. Corson, "Edge Mobility 2000 Architecture", Internet-Draft, draft-oneill-ema-02.txt (work in 2001 progress), July 2000. 2003 [SEL] R. Draves, "Default Address Selection for IPv6", , work in progress, October 1999. 2006 [MIPv4] C.E. Perkins, Ed., "IP Mobility Support," Internet RFC 2007 2002, Oct 1996. 2009 [MIPv6] D. Johnson, C. Perkins, "Mobility Support in IPv6", 2010 Internet-Draft, draft-ietf-mobileip-ipv6-12.txt (work in progress), 2011 April, 2000. 2013 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2014 3", BCP 9, RFC 2026, October 1996. 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2017 Requirement Levels", BCP 14, RFC 2119, March 1997 2019 [TORA] V. Park, M. S. Corson, "Temporally-Ordered Routing Algorithm 2020 (TORA) Version 1 Functional Specification", Internet-Draft, draft- 2021 ietf-manet-tora-spec-02.txt (work in progress), October 1999. 2023 O'Neill, Corson, Tsirtsis 39 2025 Author's Addresses 2027 Alan O'Neill 2028 BT 2029 Phone: +44-20-88260073 2030 Email: alan.w.oneill@bt.com 2032 M. Scott Corson 2033 University of Maryland 2034 Ansible Systems 2035 Phone: +1 301-405-6630 2036 Email: corson@isr.umd.edu 2038 George Tsirtsis 2039 BT 2040 Phone: +44-20-88260073 2041 Email: george.tsirtsis@bt.com 2042 Alternative: gtsirt@hotmail.com 2044 O'Neill, Corson, Tsirtsis 40 2045 Copyright Statement 2047 "Copyright (C) The Internet Society (date). All Rights Reserved. 2048 This document and translations of it may be copied and furnished to 2049 others, and derivative works that comment on or otherwise explain it 2050 or assist in its implementation may be prepared, copied, published 2051 and distributed, in whole or in part, without restriction of any 2052 kind, provided that the above copyright notice and this paragraph 2053 are included on all such copies and derivative works. However, this 2054 document itself may not be modified in any way, such as by removing 2055 the copyright notice or references to the Internet Society or other 2056 Internet organizations, except as needed for the purpose of 2057 developing Internet standards in which case the procedures for 2058 copyrights defined in the Internet Standards process must be 2059 followed, or as required to translate it into 2061 O'Neill, Corson, Tsirtsis 41 2062 O'Neill, Corson, Tsirtsis 42