Personal A. O'Neill G. Tsirtsis BT Internet Draft S. Corson Document: draft-oneill-ema-mip-00.txt Ansible Systems Category: Informational July 2000 EMA Enhanced Mobile IPv6/IPv4 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract It is well recognised by all micro and macro-mobility routing protocols that Mobile IP (MIP) is likely to be used to support inter-domain mobility. It is also widely accepted that Mobile IP could be used as the basis for signalling between the mobile and the micro-mobility domains for simplicity of the mobile terminal and interoperability purposes. The Edge Mobility Architecture (EMA) defines a generic IP hand-over model which operates in conjunction with a Mobility Enhanced Routing (MER) protocol to provide large- scale, intra-domain, IP address mobility. The aim of this document is to describe the minimum MIP signalling requirements for EMA:MER, and to propose additional changes necessary to [MIPv6] and [MIPv4] for them to support EMA:MER. The document deals with mobiles moving inside and between EMA:MER domains as well as coming and going from/to non-EMA:MER domains, demonstrating EMA/MIP interoperability and inter-domain hand-overs. The document also demonstrates the benefits a mobile and an operator will see when a mobile host is within an EMA domain. O'Neill, Corson, Tsirtsis 1 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 INDEX Abstract 1. Introduction 2. Conventions used in this document 3. EMA and Mobile IP Architectural Considerations 4. Combined EMA:MER and Mobile IP Architecture 4.1 EMA and MIP with Co-located Care of Addresses . . . . . . 4.2 Non Co-located Care of Addresses with FA/Attendants . . . 5. Inter-domain Considerations 5.1 Non-EMA MN and/or movement between non-EMA domains . . . . 5.2 EMA MN Moves from any domain into an EMA domain. . . . . . 5.3 EMA MN Moves from an EMA to a Non EMA domain . . . . . . . 5.4 EMA MN Moves from one EMA to another EMA domain. . . . . . 5.5 Subsequent Movement. . . . . . . . . . . . . . . . . . . . 5.6 Returning to a previously visited domain . . . . . . . . . 5.7 Returning to the Home Domain . . . . . . . . . . . . . . . 6. Summary of Hand-over Processing 7. EMA enhanced MIPv6 7.1 Basic EMA Extensions to MIPv6 . . . . . . . . . . . . . . . 7.2 Hand-over Examples. . . . . . . . . . . . . . . . . . . . . 7.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . . 7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted) . . . 7.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . . 7.2.4 Moving into an EMA domain-MN Supports EMAext. . . . . 7.2.5 Moving into an EMA domain-MN does not support EMAext. 7.2.6 EMA MN has a CRCoA from a previous domain . . . . . . 7.3 Source Address Selection Rules. . . . . . . . . . . . . . . 7.4 Implications of EMA:MIPv6 Convergence on MIPv6. . . . . . . 7.5 Ongoing work. . . . . . . . . . . . . . . . . . . . . . . . 8. EMA enhanced MIPv4 8.1 Basic EMA Extensions to MIPv4 . . . . . . . . . . . . . . . 8.2 MIPv4 Hand-over Examples. . . . . . . . . . . . . . . . . . 8.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . . 8.2.2 Unplanned Reverse Hand-over (MN / NAR). . . . . . . . 8.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . . 9. MIPv6 vs MIPv4 in respect to EMA 10. Security Considerations 10.1 Authenticating users within a domain . . . . . . . . . . . 11. References O'Neill, Corson, Tsirtsis 2 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 1. Introduction Mobile IP (MIP) (versions 4 and 6) provides for the potential movement of a Home IP address throughout the Internet, from a home domain subnet, throughout foreign domain subnets equipped with MIP. It does so by providing a Mobile Node (MN) with a local and potentially short-term IP Care of Address (CoA) in a foreign domain, towards which packets can be directly or indirectly tunnelled. This CoA is reported back to a Home Agent (HA), who then tunnels packets, sent by any Correspondent Node (CN) to the Home address, towards this CoA. In addition, direct tunnelled communication, bypassing the HA, can be achieved through additional signalling between the MN and the CN. A Foreign Agent (FA) entity can also optionally exist to assist the MN in the foreign domain by terminating tunnels and acting as a proxy CoA, a CoA allocator and a proxy signalling point for MIP signalling. The Edge Mobility Architecture (EMA) provides a generic hand-over model between two Access Routers (AR) for supporting the movement of Mobile Nodes between ARs which are equipped with any Mobile Enhanced Routing (MER) Protocol (modified MANET or general intra-domain routing protocols). A MER protocol is able to rapidly adjust the routing tables so that the route pointing to the IP address of a MN can be moved in sympathy with the EMA hand-over signals to provide seamless, native IP forwarding within an EMA domain. The IP address of the MN is given to it by the first AR (called the Allocating Access Router or AAR) it visits in the domain, out of its aggregated prefix. A hand-over can be initiated either by a MN or the network, and can be rooted (i.e. initiated) at either the old or new Access Router. The Old Access Router (OAR) is used to co- ordinate a forward hand-over when the New Access Router (NAR) is known in advance as a result of either network or MN-based movement prediction and associated performance measurements. The NAR is used to co-ordinate a reverse hand-over when the NAR is not known in advance by the MN or the network, as a result of either network failure (e.g. old radio link lost), insufficient network intelligence (no inter-technology hand-over signalling) or unpredictable user behaviour (swapping PCMCIA network cards). MIP is required between domains to support the movement of a MN IP address out of the local domain (no inter-domain MER yet proposed), and is also required to support MIP hand-over in domains that are not equipped with a MER protocol. To facilitate the co-existence of MIP and EMA options, the MIP signalling capabilities with appropriate additions are obvious candidates for providing the User -AR signalling plane for EMA hand-over. MIP signalling between MN, FA/CoR, HA and CN is presently being reviewed to establish appropriate enhancements to support fast IP hand-over within 3/4G networks, and between other types of link O'Neill, Corson, Tsirtsis 3 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 layer technologies supporting ARs and MNs. This draft outlines the inter-working architecture for EMA and Mobile IPv6/v4 that provides mutual co-existence and benefits, both for the user and the operator. The draft then describes the specific additions to Mobile IPv6/v4 signalling to provide the required features, with associated issues and uncertainties that need to be raised for discussion with the MIP working group. The aim of the draft, above and beyond its specific technical content, is to raise understanding of the EMA capabilities and requirements so that fast hand-over developments in MIP are equally applicable to domains supporting routed mobility and native forwarding. Among the advantages of EMA are that when a MN is in its Home EMA Domain, as it will become apparent later, there is essentially no use of tunneling over the air interface, very little signalling over the radio link, greatly reduced signalling in the network and little need for persistent tunnels in the network. Most of the mechanisms described in this document deal with corner cases and exceptions when special signalling and tunnels are needed in order to provide seamless inter-domain services using MIP signalling. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3.1 Terminology used in this document Much of the terminology used in this document borrows from Mobile IP (versions 4 and 6) and this will be obvious to those familiar with these protocols. The following introduces new terminology as well as slight extensions to existing terminology. Access Router (AR) a combined IP router, network access server and Mobile IP agent NAR, nFA, nCoR New AR with either FA (v4) or CoR (v6) functionality OAR, oFA, oCoR Old AR with either FA (v4) or CoR (v6) functionality AA, AS/RA, RS Mobile IP v4/v6 advertisements from AR used interchangeably, O'Neill, Corson, Tsirtsis 4 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 possibly extended with EMA options Forward BU (FBU) Binding Update sent by MN (or Network) to OAR. Results in OAR generating a BU Acknowledgement (BUAck) sent 'forward' (in direction of hand-over) to NAR and then to MN. Creates temporary horizontal tunnel at OAR to MN for oCCoA Reverse BU (RBU) Binding Update sent by MN to NAR over new link and then 'reverse' (opposite direction of hand-over) to OAR Binding Update Ack (BUAck) Binding Update Acknowledgement sent by OAR to NAR and then to MN in response to FBU or RBU. If network sent FBU, then MN may receive unsolicited HAck. EMA Hand-over Request Destination Option (EHORQ) Sent by MN to O/NAR over old/new link requesting hand-over EMA Hand-over Response Destination Option (EHORP) Sent by NAR (on receipt of RUA) to MN over new link confirming hand-over AAA Request/AAA Response Destination Option Sent by NAR and OAR to enable the NAR to rapidly acquire local OAR IP configuration pertinent to the MN, such as keys, policy information, dynamic firewall state. Registration Request/Reply (RRQ/RRP) Vertical Mobile IP message to HA from MN via NAR UDU/UDU-Ack MER TORA hand-over messages for host route redirects Tau Is one of the [TORA] reference values that decrements on every handover and indicates host route freshness Some more terms are also defined in Sections 6 and 7.2 of this document. O'Neill, Corson, Tsirtsis 5 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 3. EMA and Mobile IP Architectural Considerations Firstly, the EMA envisages a rich set of hand-over capabilities that encompass a range of existing, predictive (cellular) and non- predictive (inter-technology) hand-over models and requirements. The EMA signalling requirements are a super-set of existing MIP hand- over capabilities as will be described in detail later, which indicates that some additions will be required in MIP if EMA is to solely rely on MIP signalling. Specifically, MIP does not presently support forward hand-over rooted at the OAR, nor does it provide the required information exchange between neighbouring ARs to facilitate such forward hand-over in an all-IP solution. There have, however, been drafts and discussions suggesting such additions and these are in line with the desire for MIP to take a significant role in 3G/4G cellular solutions. Secondly, the MIP architecture assumes a MN is from an arbitrary home domain, and an arbitrary HA within that domain. We therefore cannot make any assumptions in EMA as to whether or not this Home Domain is equipped with a MER protocol. Equally, we know that any visited foreign domain may be either MER or non-MER equipped, and we need to ensure that MIP continues to operate as normal as a MN moves through MER and non-MER domains. The conclusion therefore is that MIP functionality related to the Home Address as a source / destination address, covering CoA registration, HA capabilities and route optimisation/binding features, must be orthogonal to EMA. EMA is instead associated with the CCoA, MN-AR signalling, and the temporary forwarding (between CoA's on hand-over) features of MIP. The specific details change slightly between MIPv6 and MIPv4, and depend on the type of CoA (Co-located or not). Each scenario, except the use of non-co-located CoAs, is described in the following sections, followed by a description of the required MIP messages and associated extensions. Thirdly, and finally, the types of Internet access supported by MIP and MER functionality are very different and are part of the overall commercial opportunity. MIP facilitates roaming into foreign domains and links, from a Home link within a Home Domain. Associated AAA interfaces are used to control access to the foreign links where necessary, and may also be used to install policy as to how user traffic is forwarded. These forwarding options provide for IP traffic associated with a home session address to go to and from the Home Domain (forward and reverse HA tunnelling) as in the remote access model. The other options allow for direct tunnelled communication between CN and MN (HA bypass) through optimisation / binding, and in the case of Co-located Care of Addresses (CCoA) based sessions, native communication independent of the home address and MIP tunnelling features (as in local or roaming access). The MIP CCoA is however only a valid session address on a specific foreign link, and the utility of this address for native service is consequently severely limited, and it's use therefore actively O'Neill, Corson, Tsirtsis 6 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 discouraged in Mobile IP. Some movement of this CCoA address is, however, supported in MIP through the use of temporary tunnelling between ARs, with the current CCoA at the old AR being treated like a Home Address, and a new CCoA from the new AR acting as the tunnel endpoint. To aid subsequent discussions we describe temporary indirect tunnel forwarding between adjacent ARs as "Horizontal" MIP forwarding. This is to help the reader appreciate that this hand-over is likely to be between geographically adjacent AR's of equivalent configuration and status. Standard indirect tunnel forwarding via a possibly remote HA in it's home domain is termed "Vertical" MIP forwarding. This is to help the reader appreciate that this tunnel is likely to be in support of communications between non-geographically adjacent nodes of dissimilar configuration and status, where in many cases the HA is a centralised element providing HA services to a large number of AR's. Finally, the bypass of either horizontal or vertical forwarding by a CN using optimisation is known as direct tunnel forwarding as per MIP specifications. MER, unlike MIP, also enables native communication using the CCoA as a normal source (destination) session address, but with significantly increased utility, as a result of the MER ability to update the routing tables in the domain to enable the CCoA to move with the MN. The combination of MIP and MER can therefore support both native and remote access models, along with hybrid combinational models. From the perspective of a foreign ISP, a roaming MN can be offered native service and/or non-optimised / optimised remote access depending on the user's/home operator's privileges in the foreign domain, assuming appropriate AAA support features are developed. In the existing UMTS model, the benefit of the co-existence of these models is clear because the present UMTS network can only support the remote access model from the MN back through SGSN and GGSN to the external 'Home' ISP (today via GTP tunnels). This external ISP provides both the non-routable 'Home' IP address to the MN, and all associated IP services and onward connectivity to the wider Internet. Significant benefits would accrue to both the UMTS network operator and to users if, in addition, the UMTS network could support native IP services using local IP addresses, local IP service infrastructure, and direct connectivity between users on that network and out to the wider Internet. This commercial context provides additional justification for the co-existence of MIP (remote access) and EMA:MER (as an efficient means to support native forwarding) within a future all-IP 3G/4G solution. The details below will illustrate this in more detail. O'Neill, Corson, Tsirtsis 7 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 4. Combined EMA:MER and Mobile IP Architecture 4.1 EMA and MIP with Co-located Care of Addresses A MN has a Home address from a Home Domain and is allocated as per normal MIP specs (static, DHCP etc). This address is installed in any system which requires a global and reliable IP address through which to reach the MN (DNS, SIP etc). Orthogonal to this is the CCoA which is allocated on any foreign link, and which is equivalent to the EMA address for the MN. For a series of Access Routers past which a MN can move, acquiring a CCoA at each AR, the MN can continue to use its home address as a valid IP session address. This MIP tunnelling model works for intra and inter-domain movement with the appropriate AAA support. The impact of EMA, and the aim of the interworking architecture, is to enable a whole EMA domain to appear to MIP vertical tunnelling elements as if it is a single AR, in that a single CCoA can be used throughout the domain. By ensuring that a MN experiences the same environment (state / signalling) whether it is handing over between non-EMA or EMA-equipped ARs, we can provide movement through arbitrary domains in any sequence whilst preserving existing horizontal and vertical MIP functionality. When the MN first starts up, the MN gets its first CCoA in this new domain and needs to undertake normal MIP signalling to register this CCoA with its (possibly remote) HA to facilitate "indirect vertical tunnelling" between the HA and the MN. In addition, the MN may wish to also communicate its new CCoA to any CNs so that "direct tunnelling" (HA bypass) can be achieved. For the moment we will forget what has happened in any previous foreign domain, which may or may not have EMA:MER capabilities. Let us then assume that the MN is happily communicating via both direct and indirect vertical tunnelling when it detects a change of AR (link) using well- documented MIP techniques. In the case of a MN in a non-MER domain, we would require that, as per MIP specs, a new CCoA allocation on the new link be followed by updated registrations to; i. the HA and CNs to move indirect vertical and direct tunnels to the new CCoA, and optionally to ii. the old CoR/FA for horizontal MIP tunneling of packets, addressed to the old CoA, from the old CoR/FA to the new CoA. Note that the latter applies to both in-flight packets using vertical forwarding to the previous CoR, and to packets sent natively to the old CoA. The vertical and direct tunnel messages represent signalling traffic and delay which can be avoided in an MER-equipped domain, as follows. An MER protocol, however, would enable the CCoA to move with the MN as it changes ARs, by rapidly modifying the local routing tables so O'Neill, Corson, Tsirtsis 8 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 that traffic addressed to the CCoA now arrive natively via the new AR rather than via the old AR. This means that the CCoA and all MIP registrations are still valid, and hence there is no need to update the forwarding state in HA and CNs. The result is faster hand-over, reduced signalling load, and in many cases no tunnelling of IP packets between adjacent ARs. In an EMA:MER-equipped domain, the MN therefore only needs to acquire a single CCoA in that domain per IP session, and only needs to register that address once to the remote HA and CNs, as the MN moves in the domain. This constitutes a significant performance improvement to MIP hosts if the EMA:MER domain is both practical, from a routing perspective, and sufficiently large enough to justify the deployment of EMA:MER. Note that because of the clean separation between EMA:MER horizontal operations from the MIP vertical operations, and the focus of EMA:MER on optimising the horizontal plane (and as a result avoiding the side-effects on the vertical plane), each domain can independently decide on MER deployment without affecting vertical MIP operation as a user roams through foreign domains. From a MIP signalling perspective, the MN would still go through the motions of requesting/updating vertical MIP tunnelling. Also, it would install a temporary horizontal MIP forwarding tunnel as per MIP between the old AR and the MN at the new CCoA; this being an optional MIP feature. However, in an EMA:MER domain, these messages would also, in parallel with installing a temporary horizontal MIP tunnel, be used to install a new host native redirect route from the old AR to the MN at the new CCoA. In MIP, an obvious special case arises when the MN is on its home link, in that it doesn't need a separate CoA and does not therefore participate in MIP to send and receive IP packets. When the HA is located in an EMA domain, the concept of "home" may be extended to the entire domain due to the micro-mobility capability of an IP address being valid anywhere in the home domain rather than just on the home link. So, while the MN is on its home link within an EMA domain, no MIP signalling is required as is normal, and no MER host redirect routes are generated in the domain. When the mobile moves from that home link but remains in the home domain, there are two models that can be used, which offer different potential benefits to the overall system. The first model assumes a native 'roaming' service is offered to the mobile anywhere away from the home LINK. As soon as the MN moves out of the home 'link' but still remains in the same "home EMA domain", it must acquire a CCoA at the first foreign link, and can then continue to use that CCoA as a source address throughout the EMA domain as it does in the general case. The MN will then need to use MIP signalling to trigger EMA hand-overs and install MER host redirect routes to forward traffic towards each new AR. Any ongoing IP session using the home address is maintained using MIP vertical tunnelling from the home link Home agent as normal. It is worth O'Neill, Corson, Tsirtsis 9 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 noting that this model may well be necessary in UMTS if the HA is a core network function, and is generally not therefore located on an AR. In this way the MN is always "away" from its home link and is therefore always on a foreign link (possibly in a foreign domain) from which it always has to get a CoA to operate. HA + + + AR1+ AR2 AR3 |+ |+ MN <----------> Figure 1: The MN gets an address from the EMA domain (EMA CCoA) and registers it with its Home Agent. While in the same EMA domain no other registration is needed. The second model assumes a native 'roaming' service is only offered to the mobile anywhere away from the home DOMAIN. In this case, the MN would automatically use its Home Address as a CoA whilst on foreign links in the home EMA domain, since its Home Address is valid throughout this domain due to MER redirection. The HA is considered to be the automatic AAR and the first AR the MN encounters in the home domain simply AAA's the request to use the home address, and acts like a NAR by injecting a host redirect route back to the HA (the AAR). Requesting or continuing to use the Home Address as CCoA when the MN is away from its home link offers the following advantages. HA AR2 AR3 | | MN <--------------> Figure 2: The MN's Home Address is the same with the EMA CCoA and thus no tunneling to HA is required. i. CNs communicating with the MN's home address achieve direct native communication while the MN is anywhere in its home domain. ii. When the MN moves to a foreign domain and acquires a new CCoA, the MN can send vertical Binding Updates (BU) to CNs as the MN is still using the same session source address. In contrast, if the MN is using a CoA different from its home address as a source address in a session, then a vertical BU to a CN will not work, and horizontal MIP tunnelling is instead required to deliver packets to the MN. O'Neill, Corson, Tsirtsis 10 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 This use of the home address as a CCoA may have some side-effects though as MIP attaches special significance to messages in which the CoA=Home Address. This is normally used to cancel all bindings to other CoAs, and to therefore reinstate native forwarding. Curiously this is precisely what we wish to achieve in the context of the wider home domain, but the full ramifications of this when multiple simultaneous bindings are being supported, or following inter-domain movement is for further study. The other implication of using the home address as the CCoA is that the MN requires a host redirect route back to its HA when it first starts a session, which reduces the inherent scalability of EMA:MER routing. 4.2 Non Co-located Care of Addresses with Foreign Agents / Attendants This draft does not describe these options within the EMA model because of the lack of a distinct per host CoA. This prevents MER routing from preserving the CoA (and associated tunnels and bindings) in an EMA domain. There are however obvious ways to enable co-existence of MIP and EMA in this case, as illustrated by the inter-domain models of Cellular IP and HAWAII. 5. Inter-domain Considerations MIP is required in EMA between domains to support the movement of a MN IP address out of the local/home domain (no inter-domain MER yet proposed), and is also required to support MIP hand-over in domains that are not equipped with a MER protocol. To facilitate the co- existence of MIP and EMA options, the MIP signalling capabilities with appropriate additions are obvious candidates for providing the signalling plane for EMA inter-domain hand-over. 5.1 Non-EMA MN and/or movement between non-EMA domains Normal MIP mechanisms must apply to ensure we are standards compatible, irrespective of the nature of the mobility support (EMA or non-EMA) in either the previous or new domain. In addition, we must make sure that any EMA extensions to MIP can co-exist with the unmodified form of MIP so that an EMA domain can support legacy ARs and MNs. We must therefore acquire a new CCoA from the first AR in this domain and then update the HA and any CNs to re-orientate vertical tunnelling. In addition the MN can optionally register the new CCoA with the previous CoR/FA and build a temporary inter-domain MIP horizontal forwarding tunnel so that existing communications directed to the previous CCoA can be maintained. We can then iteratively build subsequent MIP horizontal and vertical forwarding tunnels in the new domain as would be required for a non- EMA domain. This means that each time the MN changes AR, a new CCoA has to be acquired by the MN that has to then be registered to the previous CoR/FA, and a new temporary horizontal forwarding tunnel built between adjacent ARs. The persistence of the horizontal and vertical tunnels depends on the requested (or agreed) lifetime as O'Neill, Corson, Tsirtsis 11 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 detailed in standard MIP signalling. It is expected that the lifetime of temporary horizontal MIP tunnels between adjacent ARs will be very short, on the order of seconds. Note that chaining of multiple horizontal tunnels through a non-EMA domain results in multiple encapsulations. These are only required though if the vertical tunnel is not re-orientated (diverting traffic from reaching the old CCoA), or a previous CCoA up the hand-over sequence was used as a session address for which packet flow is continuing to require the chain of tunnels to reach the MN. 5.2 EMA MN Moves from any domain into an EMA domain If the MN supports EMA extensions, as soon as it steps into an EMA domain it will behave as if it is booting up in the EMA domain and will be required to undergo authentication. It will optionally acquire its domain-wide hash (see section 10) which is used to efficiently confirm the identity of the MN to AR's throughout the domain. Then, the MN will be able to get a new CCoA from the AR to which it first attaches to, which it can then continue to use on subsequent hops in the new domain due to EMA:MER routing. The node will also compute a hash based on the new CCoA that can be used to authenticate packets over the air within this domain (see section 5). Additionally, the MN might chose to build a temporary MIP horizontal tunnel to the last AR in the last domain so that existing communications directed to previous CCoA's in the last domain will not have to be dropped. Note that while in the new EMA domain this temporary horizontal tunnel, and the associated HA/CN vertical tunnels, will also be moved with the MN as they terminate on the MN's mobile CCoA in this domain. Therefore, a new vertical and horizontal tunnel will not have to be set-up at each new AR, leading to vastly reduced signalling and faster hand-over. Domain Boundary HA | + Old non-EMA| + New EMA Domain Domain | + | + OAR+++++NAR+ AR AR | + | + | + | + | ++MN <------------> | Figure 3: The MN Registers a new CCoA to its HA which will be its EMA CcoA in this domain and is required. 5.3 EMA MN Moves from an EMA to a Non EMA domain When a mobile appears at an AR in a new domain, then the present CCoA used by the MN from the old domain is no longer valid. The MN O'Neill, Corson, Tsirtsis 12 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 therefore needs to acquire a new CCoA. Present communications though, are using the old CCoA which are being routed by EMA towards the OAR in the previous domain. We have at least one (and possibly two) hand-over stages to complete; In the first stage the MN can send a binding update to the previous AR, as in standard MIP, so that it can temporarily horizontally tunnel packets addressed to the old CCoA forward to the new CCoA. This however means that the old CCoA (in the previous EMA domain), and the associated routing state from the AAR to the OAR, cannot be released until either the binding at the OAR times out and/or the route timer and address timer expire. This should happen very quickly though as the horizontal tunnel is intended to be short- lived. In the second stage, if the old CCoA was allocated in a previous EMA domain, and is in use as a session address, the MN now views that CCoA session as a secondary home address, whose home agent is the AAR in the previous domain. We call this a "Co-Located Roaming CoA" (CRCoA)and is a deprecated address, i.e.: the MN MAY use it to maintain existing sessions but MUST NOT use it as source address in new sessions . T he MN therefore sends another BU to that AAR so that the AAR can AAA the request to roam with one of its CCoAs. If permitted, the AAR then provides HA and persistent horizontal tunnelling services to the MN for that CRCoA, and the MN can use BUs to CNs using that CRCoA as a session address to bypass the AAR HA. If BUs to CNs are used, the AAR HA may never need to tunnel packets to the MN. The AAR will in any case not need to act as the HA for the CRCoA and tunnel packets until the host routing state, directing packets addressed to the CRCoA towards the OAR, is eliminated on expiry of the temporary horizontal inter-domain tunnel. Domain Boundary | HA | + Old EMA | + New Non-EMA Domain Domain | + | + +++++++++++++++++++ + + | + + AAR OAR++++++ +NAR+ AR AR | + +| + | + +| + | ++MN+++ | Figure 4: The MN Registers a new CCoA to its HA and to the AAR in the old EMA domain for the CRCoA. A temp tunnel to the OAR is optional. In the non-EMA domain this registration will be done one every hop. O'Neill, Corson, Tsirtsis 13 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 The destination of the MIP temporary and persistent horizontal inter-domain tunnels, is the new CCoA in the new domain. In parallel with this, normal vertical MIP Registration of the new CCoA for the original home address should also be sent to the HA of the MN to update vertical tunnelling. This process will then be continued on subsequent hops as per normal MIP, with each new local CCoA allocation requiring both vertical and horizontal tunnelling updates for the original home address and any acquired CRCoAs in use as session addresses. An aggregated horizontal BU for the previous CoA and active CRCoAs, to the previous CoR/FA, would clearly be advantageous. Multiple CRCoAs are possible because a new CRCoA could be collected in each EMA domain encountered. This is not considered to be a significant scaling problem due to the rarity of inter- domain hand-over in the EMA model. 5.4 EMA MN Moves from one EMA to another EMA domain In this case, the MN moves from one EMA Domain to another also EMA- enabled Domain. The hand-over and interdomain tunnel requirements are exactly as with the previous section (5.3). The most important difference from 5.3 is that the MN will register all the tunnels only once since the nCCoA in the new EMA domain will be valid throughout this domain. All these tunnels at the NAR will then "follow" the MN naturally without the need for re- registration. The tunnel from the OAR will be dropped quickly, since this is the temporary horizontal one, while the others will be maintained for as long the MN is using the CRCoA. Domain Boundary | HA | + EMA | + EMA Domain 1 | + Domain 2 | + +++++++++++++++++++ + + | + + AAR OAR++++++ +NAR+ AR AR | + +| + | + +| + | ++MN+++ <----------> | Figure 5: The MN Registers a new CCoA to its HA and to the AAR in the old EMA domain for the CRCoA. A temp tunnel to the OAR is optional. In EMA Domain this registration will only be done once. O'Neill, Corson, Tsirtsis 14 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 5.5 Subsequent Movement It is clear that the use of MIP ensures that subsequent multi-domain movement, in any sequence, between EMA and non-EMA domains, can use MIP between and within any domain. When using EMA to move the CCoA within a domain we can clearly detect movement to a new AR by the absence of the advertisement of the prefix covering the existing CCoA. If that new domain is not supporting EMA we can move to normal MIP mechanisms and build the forwarding tunnel back to the previous EMA domain (first to the OAR, then the AAR). From there we know we can continue to use MIP and drop into EMA processing at any point. Any intermediate MIP or EMA state in previous domains, and in particular that associated with CRCoAs, only remains whilst data is being forwarded or whilst timers are refreshed. Any intermediate EMA state is directly equivalent to the MIP state that would have been created by a MN, acting simply to compress multiple MIP CCoA allocation phases into a single EMA CCoA allocation phase. 5.6 Returning to a previously visited domain When a MN returns to a non-EMA domain that it has previously visited, and in which it may (but probably does not) still have MIP horizontal forwarding state, the MN can potentially re-use an existing CCoA (and delete the horizontal tunnel). This is only possible if the MN is returning to the same CoR/FA that owns that CCoA. Alternatively, and after determining its new CCoA and building the incoming inter-domain tunnel from the last domain, the MN should move (via binding update) any persistent horizontal tunnels from the previous CCoA in that domain to this new CCoA. This is to avoid indirect routing, remove the outgoing inter-domain tunnel, and release resources within visited intermediate domains on the path out of, and back into, this domain wherever possible. The necessity of these sequence of BU events is however questionable as it is only required when a MN passes rapidly through intermediate domains before returning to a previous domain during the lifetime of the short-lived horizontal tunnel, and before vertical tunnelling has been updated. When a MN returns to an EMA domain that it has previously visited, the MN may still be using the CCoA that it acquired in that domain as a CRCoA. The MN must first find out if it has an active CRCoA (or home address) for that domain through NAI comparisons. An active CRCoA may or may not have a host redirect route associated with it (AAR to OAR) but will more likely have a HA at the AAR acting as a CRCoA forwarder. If it does have such an address then we would wish the MN to use that address rather than acquire an additional address from that domain, and insert additional host redirect routes into EMA. Once the MN has gained permission at the NAR (AAA) to use the existing CRCoA, the MN will then build a new incoming horizontal forwarding tunnel from the OAR in the previous domain as per normal O'Neill, Corson, Tsirtsis 15 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 MIP inter-domain hand-over. The MN can then consider additional action to avoid indirect vertical forwarding within the new domain, and release resources as for the non-EMA domain above. This should all cause the previous outgoing inter-domain horizontal forwarding tunnel to be bypassed before the tunnel lifetime expires, and any host redirect route and/or MIP state in intermediate domains to be released where possible. The first action is to instigate an EMA hand-over from the NAR at which the MN re-entered this domain. The MN has two options as this point; i. Assuming the inter-domain tunnel is at a local OAR. The MN can inject a host redirect route back to the AAR which will partially intercept the old host routing state to the OAR and redirect packets away from the OAR. The OAR inactivity timers and BU lifetime will expire if not refreshed, clearing out the old host routing state within the domain. When the old routing state is removed the host route to the AAR will then redirect all packets locally to the NAR as per standard EMA:MER mechanisms. ii. If the inter-domain tunnel is already at the AAR, we can start an unplanned hand-over back to this node and everything is as per normal EMA except that we can locally clear the persistent horizontal inter-domain tunnel at the AAR. In all cases, the MN will continue to receive in-flight packets that are still on their way to, or have passed through, the local OAR. The path includes the outgoing inter-domain tunnel to the foreign domain, subsequent intermediate domain forwarding to a foreign OAR, and then into the new inter-domain tunnel towards the new local NAR. This path difference between the new local host route and the existing inter-domain path means that the MN may need to buffer the packets from the new host redirect route whilst the inter-domain packets are delivered. This buffering is better on the host as it has application awareness. 5.7 Returning to the Home Domain When a MN which is using MIP returns home, MIP provides all the mechanisms required to return to native forwarding on the home link, or to make use of horizontal and/or vertical tunnelling as it sees fit. If the home domain is an EMA domain then any intermediate MIP or EMA state in previous domains only remains whilst data is being forwarded as described above. If the MN returns home but has not been home during this IP session then there may be some benefits in the MN automatically setting its CCoA in the domain to its Home address, rather than getting a CCoA from the NAR(AAR) in the home domain. These benefits relate to the fact that all applications then use the same address whether being tunnelled or natively forwarded within the domain. O'Neill, Corson, Tsirtsis 16 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 6. Summary of Hand-over Processing The EMA hand-over model covers both Break-Before-Make (BBM) and Make-Before-Break (MBB) planned and BBM unplanned hand-over . In planned hand-over the NAR is known in advance and so a temporary tunnel may be built from the OAR to the NAR. In unplanned hand-over (which by definition is BBM only), the NAR is not known and any tunnel must be requested from the NAR back to the OAR. The same message sequence is used for both forms of hand-over. Mandatory signalling is rooted at the NAR, but anticipatory (i.e. planned) signalling may occur in advance of hand-over, rooted at the OAR. Hand-over may be triggered either by the MN or the network. Five types of MIP tunnels that may be used during EMA-based hand-over and forwarding: i. Temporary Horizontal from OAR to MN for oCCoA via nCCoA ii. Vertical indirect from MN-HA to MN for Home Address via a nCCoA iii. Direct from CN to MN for Home Address via a nCCoA iv. Persistent horizontal from AAR-HA to MN for CRCoA via a nCCoA v. Direct from CN to MN for CRCoA via a nCCoA HA+ CN(HA) (HA)+ + + + OAR++++++NAR OAR +NAR OAR +NAR (oCCoA) + + + + + + + + + MN(nCCoA) MN(nCCoA) MN(nCCoA) i. Temp Horizontal ii. Vertical Indirect iii. Direct CN(CRCoA) D1 | D2 D1 | + D2 | | + AAR++++++NAR AAR | + NAR (CRCoA)| + (CRCoA) | + | + | + | + | + MN(nCCoA) MN(nCCoA) iv. Persistent v. Direct Horizontal Figure 6: Tunnel Types supported by EMA ++++ indicates tunnel (xx) indicates an address related to this tunnel. Which packets use it and what is the destination of the tunnel. For example on (i.) packets with Destination Address=oCCoA will be tunneled to nCCoA. O'Neill, Corson, Tsirtsis 17 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 oCCoA is the EMA CcoA ie. The address which is valide throughout the EMA domain nCCoA is a CcoA the MN gets every hop but only uses for signaling/tunnel termination or if EMA handover fails CRCoA in the previous domain this was an EMA CcoA. Since the MN moved out of that domain this becomes an CRCoA and is treated as a Home Address The temporary horizontal tunnel (i) is expected to have a lifetime on the order of seconds, whereas the others may be long-lived. Only the temporary horizontal tunnel is mandatory in that it is set up in nearly every hand-over. The tunnel may be established (i.e. initiated) by the MN or the network. It may be rooted (i.e. initiated) at the OAR if planned or at the NAR if unplanned. Planned hand-over is always optional in that failure of a planned hand-over (due to unexpected loss of the old link) can always be overcome by resorting to unplanned hand-over via the new link when necessary. If planned (i.e. a new link is sensed based on L2 measurements), a forward hand-over message is sent from either the MN (or the network) to the OAR, which then forwards it to the NAR, which then forwards it to the MN via the new link. On arrival at the OAR, the message establishes a tunnel from the OAR to the NAR for the MN CCoA and any active CRCoA's. The other end of the tunnel is established on arrival at the NAR. Finally, the MN is informed of the success of planned hand-over when it receives the forward message via the new link. Using forward hand-over signals, it is possible to establish multiple tunnels to one or more potential NARs to which the MN may be hand-over. If, on arrival at a NAR, the MN has not received a forward hand-over message, it generates a reverse hand-over message that is sent from the MN to the OAR to the NAR. On arrival at the NAR, a tunnel (if not already present) is established as before. A reverse hand-over acknowledgement (now equivalent to the forward message sent earlier) is sent from the OAR to the NAR (completing tunnel establishment) and on to the MN. Once the MN (now at the NAR) is assured that the horizontal tunnel is in place, it then updates its vertical tunnel binding for its home address and any persistent horizontal tunnel bindings for CRCoA's as necessary. Depending on the MN's location (within an EMA domain or not), its configuration and current state (e.g. the nature and number of its session address(es)), etc., some, all or none of the aforementioned tunnels may need to be created or updated. Additionally, if in an EMA domain, additional signalling to locally redirect native host routing will occur simultaneously, in parallel with the binding updates (if any). O'Neill, Corson, Tsirtsis 18 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 7. EMA enhanced MIPv6 On boot up or at arrival at a new AR, the MN must listen for Routing Adverts (RA) from the nearest Access Router (AR) and auto-generate a new CCoA from one of the prefixes advertised as per normal IPv6 Stateless Address Autoconfiguration (or DHCPv6). The first such AR becomes the Allocating Access Router (AAR) as far as EMA is concerned for the duration of the active IP session. In the special case of a home EMA domain, the MN may request to use it's home address as the CCoA. The EMA domain is a fully mobile enhanced routed (MER) network so the CCoA is now valid throughout the domain by using IP hand-over to control host redirect routes. This offers a number of significant advantages. - Reduced HA signalling: Normally, on each hop the new CCoA would have to be registered/bound to the HA of the MN as per normal MIPv6. With EMA-enhanced MIP, the CCoA is registered once in the HA at the AAR. After that no more registration of the CCoA is needed. - Reduced CN signalling: For the same reasons as above after the initial CCoA allocation, the MN does not need to send re-bindings to the CNs whilst in a single domain (and in session) which is a big improvement. Note that this also impacts the performance of CNs that otherwise might not be able to cope with the repeated BUs due to continuous CCoA re-bindings. 7.1 Basic EMA Extensions to MIPv6 NAI Extension to Routing Advertisements: Each time the MN detects a new AR, it will have to determine if it is in the same or different domain as the AAR. This can be accomplished by adding an NAI extension to the RAs of the ARs. This capability has already been proposed but the MN needs to be able to store the NAI's of the AAR, OAR and NAR to appreciate the nature of the required hand-over processing. MR Flag Extension to Routing Advertisement: To gain the above benefits we need to inform the MN that the AR is EMA enabled and the EMA CCoA is valid at the new AR (while in the same domain). A single bit "Mobile Routing" (MR) flag in the Routing Advertisement could inform an EMA MN that it can reuse it's current CCoA if the AAR, OAR and NAR share the same NAI realm, and the MN satisfies EMA hand-over AAA requirements. Note that this flag can also be re-used by HAWAII, Cellular IP and other micro-mobility protocols if they meet the requirements of this draft. O'Neill, Corson, Tsirtsis 19 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Destination Options In the following Hand-over and signalling descriptions we are assuming a conservative 'ships in the night' model for the Destination Options in the EMA and MIP horizontal signalling messages. This minimises for now the interactions between MIP and EMA options but does enable minimal integration by enabling both sets of options to reside, where possible, in the same packet for increased efficiency. For simplicity, the following packet formats assume this is possible with no side-effects. The MIP Options therefore still go end to end as normal (located after the routing header in the IP packet). In contrast, the EMA related Options go via the NAR, under the control of the Routing Header, and are therefore before the routing options. It is expected that significant benefits can be gained by closer integration of the options in terms of hand-over timing, correctness and message efficiency. However, the security implications, option processing and forwarding rules, and status of both the MIPv6 draft and the EMA work in the MIP working group, make further consideration of closer integration inappropriate at this time. The Message processing and forwarding rules for the key MIPv6 destination Options are summarised below. Option Message Processing and Forwarding BU Cannot change on route, discard if unrecognised Buack Cannot change on route, skip over if unrecognised Must be covered by IPSEC AH BUnack must contain no payload HA Cannot change on route, discard if unrecognised Must be covered by IPSEC AH if AH applied to packet One per packet and mandatory for a BU 7.2 Hand-over Examples In this section we demonstrate the use of MIP messages in an EMA:MER domain. Draft [EMA] describes the main MER messages that enable host route creation/deletion in an EMA domain. Figure 7 below reminds the reader of the these basic MER messages. O'Neill, Corson, Tsirtsis 20 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 |>>>>>>>>>>>>> 5.RUA/RUN >>>>>>>>>>>>>| | | | |<<<<<<<<<<<<<< 4.RU <<<<<<<<<<<<<| | | | | | |_| |_| | | -----------> 3.HI/HD -------> | | NTIN-----|OAR| <----------- 2.HR <---------- |NAR| |___| -----------> 1.TIN ---------> |___| \ / \ / HTIN HHR \ / \ / '-------- MN--------' Figure 7: Basic EMA:MER Hand-over Messaging Tunnel INitiation (TIN) Advanced warning of possible hand-over from OAR to NAR, also indicates that temporary tunnel is set at OAR Host TIN (HTIN) Message from MN to OAR indicating that possible hand-over to a NAR is requested Network TIN (NTIN) Message from network controller element to OAR indicating that hand-over to a NAR is requested Host Hand-over Request (HHR) Message from MN to NAR requesting hand-over, contains MN's credentials Hand-over Request (HR) Message from NAR to OAR which could contain MH credentials and privileges. Hand-over Initiation (HI) OAR's response to a HR if hand-over is permissible. Contains MN creditials, policy information, etc. Hand-over Denial (HD) OAR's response to an HR if hand-over is not permissible . O'Neill, Corson, Tsirtsis 21 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Routing Update (RU) On receipt of the HI or HHR, the NAR also initiates routing redirection by sending a RU towards the OAR. This is sent reliably hop-by-hop and may be resent multiple times RU Acknowledgement (RUA) OAR's response to a RU confirming hand-over and transfer of MN from OAR to NAR. RU Negative Acknowledgement (RUN) OAR's response to a RU denying hand-over 7.2.1 Unplanned Reverse Hand-over (MN not trusted) Unplanned hand-over occurs as a result of a lack of, or failure of, planned hand-over processing. This may itself be a result of the unplanned loss of the old link at the OAR, a lack of inter- technology hand-over communications, or unpredictable user activity such as removing / swapping a PCMCIA card. The MN and network can therefore only proceed with a hand-over rooted at the NAR with the aim of setting up MIP forwarding and a MER host route, from the OAR which is known by the MN. The MN arrives unannounced at the NAR and receives a Router Advertisement containing the NAI of the NAR and with the MR bit set. It may optionally send a Router Solicitation to stimulate this RA. The MN forms a new CCoA at the NAR which it can use temporarily and as a source address for MIP signalling and forwarding (Home Address Option = EMA CCoA), and for receiving horizontally forwarded packets from the OAR and directly forwarded packets from CN's. The MN then sends a Reverse Binding Update to the OAR via the NAR using a packet containing a Routing Header and an EMA Hand-over Request (EHORQ) Destination Option. This option is equivalent to the HHR message in the EMA draft [EMA]. The EMA EHORQ is authenticated and processed by the NAR. The NAR inserts an AAA Request Option into the packet to request AAA information from the OAR. At this point this Option is equivalent to the Hand-over Request (HR) message in the EMA draft [EMA]. The Reverse Binding Update (RBU) packet containing the EHORQ and AAA options is then sent to the OAR as per normal MIP horizontal processing to install temporary forwarding from the EMA-CCoA to the MN via the nCCoA at the NAR. The OAR checks the hand-over request and installs the horizontal forwarding state with a suitably short life-time. The OAR also checks the TORA Tau information for correctness and modifies it if necessary. A BUAck containing the MN nCCoA and the EMA CCoA is then sent from the OAR to the MN via the NAR using a Routing Header. The Bu-ack packet also contains an EMA Hand-over Response (EHORP) Destination Option and an AAA Response O'Neill, Corson, Tsirtsis 22 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Destination Option. The EMA Hand-over Response Option is equivalent to the Tunnel Initiation (TIN) message in EMA draft whilst the AAA Response Option is equivalent to its Hand-over Initiation/Deny (HI /HD) messages. This packet reports the status of the EMA hand-over to the NAR and the MN, and to provide IP session information (policy) to the NAR. The AAA Response Option and EMA EHORP Option are processed by the NAR which for example can be used to open the ingress filter for the EMA CCoA. The NAR then forwards the BUAck to MN with the updated status of the hand-over. At the NAR, the Tau value and OAR address are copied from the EHORP Option, compared to the locally stored values, and supercede them if necessary to form the TORA UDU. Note that the Unicast-Directed Update (UDU) and the UDU-Ack (UDUA) messages are MER TORA-specific host route redirection messages equivalent to the RU/RUA messages of the general EMA:MER hand-over model [EMA]. The remainder of this document assumes TORA is the EMA:MER algorithm. This is sent to the OAR and on the way installs the host route for the EMA CCoA into intermediate routers. The UDU reaches the OAR which informs the OAR of the successful installation of the host route. The OAR returns a UDU-ack directly to the NAR to confirm TORA hand-over. This results in the BU-Ack with associated EHORP information being sent to the MN. The UDU might in contrast indicate a routing failure, or the OAR may for local reasons need to cancel the hand-over, which causes the OAR to return a UDU-Nack to the NAR. UDU-Nack, signalling time-out(s) or policy failures result in either retries or host route clear-out and a suitable BU / EMA EHORP being returned to the MN via the NAR. A horizontal tunnel installation failure is intended to be orthogonal to TORA hand-over failure and it is only the latter which should cause the MN to abandon the EMA CCoA. In this case, the MN resorts to normal MIP processing and moves to the nCCoA before sending a Vertical BU to the HA to install the new CCoA binding. In all other cases, the MN can start sending natively using the EMA CCoA as a source address when it receives a successful EMA EHORP Option. The MN can track the progress of any hand-over by the type of packets being received via the NAR. Packets destined for the MN will be received encapsulated to the local CCoA until the MER routed hand-over is completed, at which point they will be received natively to the EMA CCoA. The MN can use the EMA CCoA as a source address as soon as the EMA EHORP Option opens the NAR ingress filter for the EMA CCoA which should occur before the MN receives the EMA EHORP. The EHORP may contain modified MER information that supercedes that in the MN. O'Neill, Corson, Tsirtsis 23 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 MN NAR OAR | | | |<---RA(NAI,MR)-------| | MN moves to NAR | | | |-----RBU/EHORQ)----->| | Routing Header sends | |---RBU/EHORQ/AAA)-->| BU to NAR and OAR. | |<-RBUAck/EHORP/AAA--| Horizontal tunnel set. |<--RBUAck/EHORP------| | MN can send packets. | |-------UDU--------->| Install host route. | |<------UDUA---------| Confirm host route. **Overview of Packet Structures - Illustrative only** The MN Sends to NAR: Source Address = MN CCoA at NAR Destination Address = NAR Destination Options: EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd Routing Option = OAR Destination Options: Binding Update = H, A, bits set Home Address = EMA CCoA The NAR Sends to OAR: Source Address = MN CCoA at NAR Destination Address = OAR Destination Options: EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd AAA Request = tbd Routing Option = NAR Destination Options: Binding Update = H, A, bits set Home Address = EMA CCoA The OAR Sends to NAR: Source Address = OAR Destination Address = NAR Destination Options: EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd AAA Response = tbd Routing Option = IP1: MN CCoA at NAR IP2: MN EMA CcoA Destination Options: Binding Ack = ok The NAR Sends MN: Source Address = OAR Destination Address = MN CCoA at NAR Destination Options: EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd Routing Option = IP1: NAR IP2: MN EMA CCoA Destination Options: O'Neill, Corson, Tsirtsis 24 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Binding Ack = ok The MN Sends MN: Source Address = OAR Destination Address = MN EMA CCoA Destination Options: EMA hand-over response = tau, OAR, EMA CCoA, NAI's, status, tbd Routing Option = IP1: NAR IP2: MN CCoA at NAR Destination Options: Binding Ack = ok 7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted) In this case, the MN is trusted a priori to identify the OAR, track the number of hand-overs for its EMA CCoA session address, and then securely provide that number and the OAR to the NAR. The number is converted at the NAR into the TORA hand-over routing parameter (Tau Height) which is required for the TORA UDU message to install the host redirect route back to the identified OAR. The NAR immediately and simultaneously sends the RBU and UDU towards the OAR. The OAR may still undertake local checks to confirm the validity of the Tau value from a semantic and policy perspective. This sequence of actions avoids the round trip to the OAR to acquire the last Tau and for the OAR to check the validity of the hand-over. The reverse BU is still sent to the OAR to fetch any additional 'policy' configuration for the mobile, and optionally to validate the hand- over in parallel with the injection of the host route. In detail, the MN arrives unannounced at the NAR and receives a Router Advertisement containing the NAI of the NAR and with the MR bit set. It may optionally send a Router Solicitation to stimulate this RA. The MN forms a new CCoA at the NAR which it can use temporarily and as a source address for MIP signalling and forwarding (Home Address Option = EMA CCoA), and for receiving horizontally forwarded packets from the OAR and directly forwarded packets from CN's. The MN then sends a Reverse Binding Update to the OAR via the NAR using a packet containing a Routing Header and an EMA EHORQ Destination Option. The EMA hand-over Request is authenticated and processed by the NAR and the OAR and Tau information is locally checked (are valid and allowed from policy perspective). The Tau value and OAR address are then copied from the RBU packet and used to form the TORA UDU. This is sent to the OAR and on the way installs the host route for the EMA CCoA into intermediate routers. In parallel, the RBU packet is sent to the OAR as per normal MIP horizontal processing to install temporary forwarding from the EMA- CCoA to the MN via the nCCoA at the NAR. The OAR checks the hand- over request and installs the horizontal forwarding state with a suitably short life-time. A BUAck is then sent from the OAR to the MN via the NAR using a Routing Header containing the MN nCCoA and the EMA CCoA. The Bu-ack packet also contains an EMA Hand-over O'Neill, Corson, Tsirtsis 25 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Response Destination Option and an AAA Response Destination Option. This packet acts to report the status of the EMA hand-over to the NAR and the MN, and to provide IP session information (policy) to the NAR. The AAA Response Option and EMA Hand-over Response Option are processed by the NAR and then the NAR forwards the BUAck to MN with the updated status of the hand-over. In parallel, the UDU reaches the OAR which informs the OAR of the installation of the host route. The OAR returns a UDU-ack directly to the NAR to formalise completion of the TORA hand-over. The UDU might in contrast indicate a routing failure, or the OAR may for local reasons need to cancel the hand-over, which causes the OAR to return a UDU-Nack to the NAR. For example, an OAR check of the tau value may be incompatible with its tau value (e.g. not fresh enough due to some error). Then the OAR sends a UDU-Nack erasing the injected route and informing the NAR of injection failure and providing the NAR with a feasible Tau value. Such a UDU-Nack, signalling time-out(s) or policy failures result in either retries or host route clear-out and a suitable BU / EMA hand-over response being returned to the MN via the NAR. A horizontal tunnel installation failure is intended to be orthogonal to TORA hand-over failure and it is only the latter which should cause the MN to abandon the EMA CCoA. In this case, the MN resorts to normal MIP processing and moves to the nCCoA before sending a Vertical BU to the HA to install the new CCoA binding. In all other cases, the MN can start sending natively using the EMA CCoA as a source address when it receives a successful EMA Hand-over Option. MN NAR OAR | | | |<-RA(NAI,MR)------- | | MN moves to NAR | | | |----RBU/EHORQ)------>| | Routing Header sends | |---RBU/EHORQ/AAA)-->| BU to NAR and OAR. | |-------UDU--------->| Install host route. | |<-RBUAck/EHORP/AAA)-| BU contains AAA info. | |<------UDUA---------| Confirm host route. |<--RBUAck/EHORP------| | MN can send packets. **Overview of Packet Structures - Illustrative only** Packet structures are the same as for the unassisted case, as only local processing in the NAR and the timing of the UDU changes. 7.2.3 Planned Forward Hand-over (MBB or BBM) Planned hand-over occurs as a result of predictive (or explicit forward hand-over) processing which enables the MN (or a network controller element) to know in advance to which NAR a MN MAY hand- O'Neill, Corson, Tsirtsis 26 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 over in case of MN assist (or MUST hand-over in case of network control). In the case of MN assisted hand-over, the MN needs to have either (1) concurrent connectivity in the IP signalling plane to both the OAR and the NAR (this ensures the MN knows its nCCoA) to achieve a planned hand-over or possibly (2) connectivity in the IP signalling plane to the OAR and link layer connectivity to the NAR from which the MAC address of the NAR can be obtained. In the latter case the MN can signal the MAC address to the OAR. From previous hand-over activity, the OAR may know the IP prefix (or CoA) of this NAR from which it can derive the MN's future nCCoA at the NAR. The MN hand- over tunnel is now rooted (i.e. initiated) at the OAR with the aim of setting up optional MIP forwarding to the NAR. MER host route redirection is still rooted at the NAR. Failure of the forward processes during hand-over still enables the MN to recover cleanly through an unplanned hand-over completely rooted at the NAR. The MN now arrives unannounced at the NAR. If the IP signalling plane is UP, the MN receives a Router Advertisement containing the NAI of the NAR and with the MR bit set. It may optionally send a Router Solicitation to stimulate this RA. The MN forms a new CCoA at the NAR which it can use temporarily and as a source address for MIP signalling and forwarding (Home Address Option = EMA CCoA), and for receiving horizontally forwarded packets from the OAR and directly forwarded packets from CN's. The MN then sends a Forward Binding Update to the OAR directly over it's old link, using a packet containing an EMA Hand-over Request (EHORQ) Destination Option. The FBU contains an alternate CCoA suboption which contains the nCCoA at the NAR which was determined by the MN from the Router Advertisment over the new link. This message is equivalent to the HTIN message of the EMA draft. If the IP signalling plane is not UP, the MN receives a link layer advertisement containing the MAC address of the NAR. It may optionally send a link layer message to stimulate this advertisement. The MN then sends this address to the OAR directly over its old link, using a nearly FBU-equivalent packet containing an EMA EHORQ Destination Option. Note that the MN could in fact present multiple NAR options to the OAR concurrently from which the OAR could select based on local or remote information. Alternatively the MN could instruct the OAR to build multiple tunnels if it is unsure of the ultimate NAR to which it will hand-over. The EHORQ is authenticated and processed by the OAR. The NAR and Tau information is locally checked (are valid and allowed from policy perspective). If only the NAR's MAC address is known, the OAR checks to see if it has a cached IP address prefix for that MAC address. If so, packets O'Neill, Corson, Tsirtsis 27 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 sent with that MAC address can now be considered as fully FBU- equivalent. Otherwise, the packet is dropped and the forward process terminates. The FBU (or its equivalent) is used to install temporary MIP horizontal forwarding from the EMA-CCoA at the OAR to the MN via the nCCoA at the NAR. A BUAck is then sent from the OAR to the MN via the NAR using a Routing Header containing the MN nCCoA and the EMA CCoA. The Bu-ack packet also contains an EMA Hand-over Response (EHORP) Destination Option and an AAA Response Destination Option. This packet acts to report the status of the EMA hand-over to the NAR and the MN, and to provide IP session information (policy) to the NAR. The AAA Response Option and EMA EHORP Option are processed by the NAR and then the NAR forwards the BUAck and the EMA Hand-over Response to MN with the updated status of the hand-over. Absent receipt of the EMA EHORP via the NAR and the new link, the MN can send an RBU packet back to the OAR via the NAR as per unplanned hand-over, and the remaining processing is per unplanned hand-over. If FBU state is already present on receipt of the RBU at the NAR (as the NAR would have processed this packet because to the routing header), then the NAR need not forward RBU to the OAR. In MBB, the OAR to NAR tunnel is only used if the old link goes down before the UDU is received which itself is triggered by the layer 3 Make at the NAR (MN-RBU). In BBM, the RA and the EMA Hand-over Option must be advertised over a new link signalling channel (as the data channel does not yet exist). The OAR to NAR tunnel is used when the old data link goes down, and until the new IP data link is installed by sending the EMA Hand-over Request over the new link and the host route is successfully installed. In the case of network-controlled hand-over, it is the controller that sends the FBU to the OAR on behalf of the MN. This is a network-generated message somewhat equivalent to the HTIN of the EMA draft, only that its generated by the network and not the MN. Processing then continues as above with the additional step being that an acknowledgement is sent to the Controller from the OAR when the BU packet is successfully processed by that OAR. The methods by which the controller identifies the best target NAR, or set of NARs, is outside the scope of this draft but movement prediction, radio channel measurements and cell / channel occupancies are obvious contributors. O'Neill, Corson, Tsirtsis 28 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 MN OAR NAR | | | |<-RA(NAI,MR)------------------------------| MN senses NAR | | | |------FBU/EHORQ----->| | FBU to OAR on old link. | | | Compared to stored | | | state | |---FBU/EHORP/AAA--->| Horizontal tunnel set. |<--------------FBUAck/EHORP---------------| Offer hand-over to MN | | | over new link | | | |-----------------RBU/EHORQ--------------->| MN requests hand-over | | | over new link. | |<-------UDU---------| Install host route. | |-------UDUA-------->| Confirm host route. |<--------------RBUAck/EHORP---------------| MN can send packets. **Overview of Packet Structures - Illustrative only** The MN Sends to OAR: Source Address = MN CCoA at OAR Destination Address = OAR Destination Options: EMA hand-over Request = Tau, NAR, EMA CCoA, NAI's, tbd Binding Update = H, A, bits set Alternate CCoA suboption = MN CCoA at NAR Home Address Option = EMA CCoA The OAR Sends to NAR: Source Address = OAR Destination Address = NAR Destination Options: EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd AAA Response = Routing Option = IP1: MN CCoA at NAR IP2: EMA CcoA Destination Options: Binding Ack = Ok The NAR Sends MN: Source Address = OAR Destination Address = MN CCoA at NAR Destination Options: EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd Routing Option = IP1: NAR IP2: EMA CcoA Destination Options: Binding Ack = ok The MN Sends to MN: Source Address = MN CCoA at NAR O'Neill, Corson, Tsirtsis 29 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Destination Address = EMA CCoA Destination Options: EMA hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd Routing Option = IP1: NAR IP2: MN CCoA at NAR Destination Options: Binding Ack Option = ok Start of reverse phase - as per unplanned hand-over (MN trusted) The MN Sends to NAR: Source Address = MN CCoA at NAR Destination Address = NAR Destination Options: EMA Hand-over Request = Tau, OAR, EMA CCoA, NAI's, tbd Routing Option = OAR Destination Options: Binding Update = H, A, bits set Home Address = EMA CCoA Matched to forward state in NAR and UDU triggered etc. 7.2.4 Moving into an EMA domain - MN Supports EMA extensions This means that the MN understands the single bit EMA flag indicating that no additional CCoA should be acquired as the MN moves through the domain. We can therefore use EMA to move the CCoA throughout the domain so that the inter-domain tunnel (to the non- EMA domain) moves with the address. MN AR2(d2) AR1(d2) AR(d1) HA |<-RA(NAI,MR)--------------| | | New domain, get CCoA | | | | | |----BU(horizontal)--------------->| | Inter-domain MIP |<--------BAck---------------------| | | | | | | |----BU(HA-CCoA)-------------------------->| Vertical BU for CoA |<---BAck----------------------------------| | | | | | | | | | | |<-RA(NAI,MR)-----| | | | MN moves to AR2(d2) | | | | | |-----------RBU/EHORQ----->| | | Intra-domain h/over | | | | | Horizontal tunnel set |<------RBUAck/EHORP-------| | | TORA h/over request | |--UDU-->| | | Install host route | |<-UDUA--| | | Confirm host route No vertical BU is required on movement to AR2 as CoA is still valid through MER host route. O'Neill, Corson, Tsirtsis 30 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 7.2.5 Moving into an EMA domain -MN does not support EMA extensions We can build new MIPv6 forwarding tunnels in the new domain as for a non-EMA domain. The MN will act as per normal MIPv6 and will not recognise the single bit EMA flag in the RAs. This means that each time the MN changes AR a new CCoA will be created and a new forwarding tunnel must be built between adjacent CoRs. The originator and terminator of the inter-domain tunnel remains the same and can only be removed when traffic and/or bindings cease. The MN must also send BU's and registrations to the HA and CN's so that indirect vertical and direct MIP forwarding can be maintained and the forwarding tunnel can be dropped. This, of course, throws away the benefits of EMA routing. The resultant signalling sequence is precisely the same as above except that the MN does not request EMA:MER hand-over so the OAR and NAR do not produce the TIN, UDU or UDUAck. 7.2.6 EMA MN has a CRCoA from a previous domain In this case the inter-domain hand-over is from an EMA domain to any type of domain. The MN undertakes the horizontal inter-domain hand- over for packets addressed to the CCoA in the previous domain to be sent to the new CCoA in this domain. In parallel, the MN sends a BU to the AAR in the previous domain requesting the conversion of the CCoA in the previous domain into a CRCoA and the associated provision of HA-like services. If accepted, a persistent horizontal tunnel will be built between the AAR and the MN and the host route in the previous domain can be cleared out. Movement to another AR in the new domain requires a temporary horizontal BU to be installed for both the oCCoA and the CRCoA at the previous AR, to forward packets to the nCCoA at the new AR. In parallel, the MN will need to update the binding for the persistent horizontal tunnel for the CRCoA. MN AR2(d2) AR1(d2) OAR(d1) AAR(d1) |<-RA(NAI,MR)--------------| | | New domain, get CCoA | | | | | |----BU(horizontal for new CCoA--->| | Inter-domain MIP |<--------BAck---------------------| | | | | | | |----BU(CRCoA-CCoA)----------------------->| Persistent BU for CRCoA |<---BAck----------------------------------| VBU for HA not shown | | | |<----->| Clear out host route |<-------------------------------->| | HBU removed by OAR |<-RA(NAI,MR)-----| | | | MN moves to AR2(d2) | | | | | |--BU(CCoA/CRCoA)--------->| | | Dual CoA Horizontal BU |<---BUAck-----------------| | | Horizontal tunnel set O'Neill, Corson, Tsirtsis 31 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 7.3 Source Address Selection Rules We have already seen that a MN will always have a globally unique Home Address while it will also have a new CCoA in every foreign EMA domain it visits, at least for as long as it is using them. It might also have a number of other CCoAs from non-EMA domains as it moves around. The obvious question that arises is how does the MN know which address to use and when. Here are the simple "policy rules" that the MN MUST follow. Note that these are superseding the "Source Address Selection" rules as defined in [SEL]. i. CCoAs from non-EMA domain SHOULD NOT be used as source address, as defined by [MIPv6] ii. A CCoA from an EMA domain (EMA CCoA) SHOULD be used as source address. iii. The Home Address of the MN MUST be used as source address when the MN is in a non-EMA domain but it SHOULD NOT be used as source address when the MN is in an EMA domain; the EMA CCoA SHOULD be used instead as defined in (ii). iv. Once a CCoA becomes a CRCoA, by the MN moving out of an EMA- Domain, this address SHOULD be regarded by the MN as a deprecated address, i.e.: the MN MAY use it to maintain existing sessions but MUST NOT use it as source address in new sessions. This will ensure that the persistent horizontal tunnel will be as short lived as possible. The new CCoA in the new domain should be used instead as defined in (ii) for EMA domains, or else the Home Address MUST be used if the new domain is a non- EMA domain as defined in (iii) The above rule-set ensures that a MN always takes advantage of the functionality of EMA-Domains and thus, mostly communicates natively and with minimum use of tunnels whilst communications are maintained, and as the MN moves between different EMA and non-EMA domains. 7.4 Implications of EMA:MIPv6 Convergence on MIPv6 The implications of EMA:MIP convergence as outlined in this draft can be summarised as follows; i. We need the MIPv6 RA to advertise the EMA capability of each AR to MN's. ii. We need the AR to advertise its NAI so that a MN can determine the nature of it's last hop (intra or inter-domain) and the applicability of its present EMA CCoA and any other CCoA or CRCoA's. O'Neill, Corson, Tsirtsis 32 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 iii. The IPv6 stack needs to be able to track and distinguish CRCoAs as well as CCoAs and HAs, and deprecate them on leaving an EMA domain. In addition, it needs to recognise opportunities to re-use these addresses on returning to a previously visited domain. iv. The IPv6 stack needs to be able to apply appropriate source address selection rules so that the EMA CCoA is preferred to either the HA or local CCoA for data traffic in an EMA domain. v. Packets containing EMA signalling options need to be processed by the NAR in either direction (MN<-> OAR over new link). MIPv6 signalling options will likely also be in these packets and opportunities for potential convergence could be explored. A routing header is used to control NAR visitation. vi. MIPv6 temporary horizontal forwarding needs to be extended to enable an additional persistent tunnel to be installed to the AAR when leaving an EMA domain. HA's on AR's must be prepared to support horizontal tunnels to support 'loss-less' intra and inter-domain hand-over. vii. The ability of the MN to automatically use its HA as the EMA CCoA session address whilst in its home domain requires the BU to support such messaging without confusing this with an instruction to cancel ALL bindings. viii. MIPv6 Destination Options have specific processing and security rules which will affect the degree of integration and piggy-backing that can be achieved with EMA Options. ix. The Forward BU via the old link appears to be permissible from the base MIPv6 specification but this draft details this option in the EMA context. x. The policy controls required to manage the multiple Internet Service options that are possible with EMA:MIP have not been fully explored but contain a super-position of well established models. 7.5 Ongoing work We are presently assessing the type, structure and ordering of the Destination Options to provide the required functionality and secure data exchange for EMA, whilst ensuring backwards compatibility with standard MIPv6. In addition, to speed up generation of the vertical BU to the HA, we are examining a model (as in MIPv4 with R bit set) in which the vertical BU automatically triggers the horizontal BU at the NAR which may yield additional benefits. O'Neill, Corson, Tsirtsis 33 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 We need a MN to report it's AAA information, height, optional EMA hand-over Request, amongst other parameters, in parallel with the Binding Updates. We need a MN to be able to store and use CRCoA's when leaving an EMA domain when using an EMA CCoA as an active session address, and co- existence of this within the overall model needs additional investigation. We also need to further consider the use of the Home Address as a CCoA when in the home domain, and the interactions with multiple concurrent CCoA's. We need to further consider the various failure modes in the unplanned and planned message sequences. 8. EMA enhanced MIPv4 On boot up the MN must acquire a CCoA from DHCP and register the CCoA in its HA as normal. The CCoA belongs to the subnet of the AR the MN is connected to during boot up. This AR therefore becomes the Allocating Access Router (AAR) as far as EMA is concerned for the duration of the active IP session. In the special case of a home EMA domain, the MN may request to use it's home address as the CCoA. The EMA domain is a fully mobile enhanced routed (MER) network so the CCoA is now valid throughout the domain by using IP hand-over to control host redirect routes. This offers a number of significant advantages. - Fast hand-over: Avoids the need for the MN to get a new CCoA at each new AR. This is very important since CCoA in MIPv4 are allocated by DHCP, which introduces potentially significant delays in the hand-over process. - Less HA signalling: Normally, on each hop the CCoA would have to be registered to the HA of the MN as per normal MIPv4. With EMA- enhanced MIP the CCoA is registered once on the first AR. After that no more registration of the CCoA is needed. - Less CN Signalling: For the same reasons as above after the initial CCoA allocation, the MN does not need to forward bindings to HA and CNs whilst in a single domain (and in session) which is also a big win. Note that this also impacts the performance of CNs that otherwise might not be able to cope with the repeated BUs due to continues CCoA change. - Address Utilisation: As a configurable utilisation feature of EMA, a CCoA is only valid for as long as the MN is in a session. If the MN becomes inactive, the CCoA is returned and the host redirect state associated with it is removed. This makes sure that the limited IPv4 address space is highly utilised. When the MN wants to O'Neill, Corson, Tsirtsis 34 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 initiate a new session, it will have to get a new CCoA from DHCP and re-register it in the HA. Firstly, to gain the above benefits we need to prevent MIPv4 changing CCoA at each new AR (while in the same domain). Two mechanisms could be used: MIP based: MIPv4 could be extended to support the following behaviour. The ARs would need to run MIPv4 but the Agent Advertisements would include an EMA specific extension: This would (a) cause the MN to look for a CCoA (b) instruct the MN not to change its CCoA if it already has one from this domain. (c) indicate the AR's NAI in the form (ARx@realm) to inform the MN when it changes domains. In fact the NAI may actually be advertised in the AA. DHCP based: In this case the ARs of the EMA domain do not send Agent Adverts (AAs). As per normal MIPv4 the MN will attempt to get a CCoA from DHCP. DHCP normal behaviour causes the client to try to re-use its existing address anyway. Note that the AAA/DHCP mechanisms could be used hop by hop to determine when/if the MN changes domain and thus have to change CCoA.. It is clear that, although conceivable, none of the above solutions are as optimal as the one based on MIPv6. 8.1. Basic EMA Extensions to MIPv4 MR Flag Extension to Routing Advertisement: To gain the above benefits we need to prevent MIPv4 changing CCoA at each new AR (while in the same domain). With MIPv4 signalling a single bit flag in the Agent Advertisement could indicate to the mobile to send the Binding Update message to its HA as normal but using its current CCoA rather than creating a new one. We will call this the "Mobile Routing-MR" flag . Note that this can also be re-used by HAWAII, Cellular IP and other micro-mobility protocols NAI Extension to Routing Advertisements: The MN every time it detects a NAR, it will have to determine if it is in the same or different domain with the previous AR. This can be accomplished by an NAI extension to the Agent Advertisements of the Access Router. 8.2 MIPv4 Hand-over Examples Firstly, the following overview of MIPv4 hand-over represents our present view of how we believe this might work, rather than how it should work with present/future MIPv4 specifications. It is therefore very likely that significant changes may be required to O'Neill, Corson, Tsirtsis 35 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 meet the need for backwards compatibility, security, evolution to MIPv6 and optimised performance. Secondly, the lack of efficient and feature-rich header extension processing in MIPv4 requires us to mandate the setting of the R bit in Agent Advertisements to force all registrations to go via the NAR. Horizontal Binding updates in MIPv4 are then triggered by vertical registrations in the NAR, with TORA hand-over failures causing the Vertical registration to progress to the HA, and successes causing the vertical registration to be answered by the NAR. Thirdly, the following examples assume that the MN must acquire a CCoA from the NAR. It may be possible to avoid this if we terminate the temporary horizontal tunnel on the NAR in EMA domains resulting in a hybrid CoA / EMA CCoA model. The MN instead uses the CoA of the NAR in signalling messages where necessary, and uses it's EMA CCoA as the source address in registrations over the old and new links. This approach, if clean, will delay and limit CCoA DHCP allocations to those situations in which the EMA hand-over fails and a new CCoA is required at the NAR/MN for a long term vertical binding. We would expect the NAR to undertake this address allocation on behalf on the MN and populate the necessary fields in the vertical registration messages. These various issues need significant further study and indicate our preference for MIPv6 based hand-over and optimisations. 8.2.1 Unplanned Reverse Hand-over (MN not trusted) The MN arrives at the NAR unannounced as in the MIPv6 case and sees the MR bit and R bit set. The MN sends a Registration Request (RRQ) to the new FA (nFA) with source address of the nFA CCoA, requesting EMA hand-over of the existing EMA CCoA. The RRQ is authenticated by the nFA and hand-over parameters checked. The RRQ then Triggers Reverse BU containing PFANE to the old FA (oFA), with EMA HO extension to request height and AAA config which is returned in the BUack packet. The BUack packet contents confirms/denies EMA hand- over and the status of the horizontal tunnel. Confirmed EMA hand- over triggers the UDU to the OAR using the height information from the OAR, and Registration Reply (RRP) to the MN. Denied EMA hand- over triggers the RRQ to progress, somewhat delayed, to the HA to update binding. UDU-ack, completes routing hand-over. UDU-Nack, time-out or policy failure results in retries or host route clear- out and RRQ to HA for new CCoA binding at the nFA. 8.2.2 Unplanned Reverse Hand-over (MN / NAR) O'Neill, Corson, Tsirtsis 36 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 In this case, we progress as above but because the NAR trusts the MN it can use the height and OAR information in the RRQ to immediately trigger the UDU in parallel to the Reverse BU. 8.2.3 Planned Forward Hand-over (MBB or BBM) As in the case of MIPv6, the MN detects the new link and uses nFA MAC information or agent advertisement information to send a Forward BU to the OAR over the old link requesting an EMA hand-over to the nFA CCoA allocated to the MN. Note that this forward BU and EMA hand-over request are different from the messages suggested in the pro-active draft although we plan to revisit this issue later given the need for network triggered hand-over. The OAR then sends the FBUack to the NAR as in MIPv6 and includes the height and AAA information in the forward message. The NAR processes this data as before and forwards an EMA Hand-over response to the MN over the new link. The MN responds by sending a RRQ to nFA with source address of nFA CCoA, requesting EMA hand-over of existing EMA CCoA. The RRQ is authenticated by the nFA and matched to the FBUack state which triggers the UDU and RRP as in 8.2.2. Unmatched state causes the nFA to resort to unplanned reverse handover. Subsequent failure results in the progression of the RRQ, somewhat delayed, to the HA. 9. MIPv6 vs MIPv4 in respect to EMA MIPv6 provides EMA with a number of significant advantages over MIPv4 that have been highlighted throughout this document. Here we summarise and highlight the most important benefits. Fast start-up: IPv6 Routing Advertisements (RAs) provide the MN with much faster IPv6 address configuration than in IPv4 that needs DHCP. Easy EMA extension: IPv6 Routing Advertisements (RAs) provide EMA with an ideal signal for the "single bit EMA flag" needed to indicate to the MN that should not try to change its CoA while in the EMA domain. Simpler interoperability: the fact that MIPv6 does not rely on FAs and CoAs simplifies the design and the interoperability with non-EMA domains Abundance of addresses: EMA requires address allocation to be done from within the prefix range of the AAR . IPv6's abundance of addresses makes it so much easier compared to its IPv4 equivalent. O'Neill, Corson, Tsirtsis 37 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 10. Security Considerations The mechanisms described above can re-use mobile IP and AAA mechanisms as proposed in [AAAMIP] and [CIP] since the requirements and level of security required are similar. It is expected that the EMA Hand-over and AAA options will need to be protected within the network and over the air interface to prevent a range of attacks, and IPSEC AH and ESP are to be investigated for this purpose. 10.1 Authenticating users within a domain Associated with each mobile node (MN) is a unique identifier known as its Mobile ID (MID). This is taken here to be an IPv6 address (which may or may not be associated with an interface), but which may also be a Network Access Identifier (NAI). On arrival at a NAR, a MN must first either furnish proof of prior authentication within the domain, or be initially authenticated before it may send or receive any form of control or data traffic. Proof of prior authentication may be readily available in the form of a pre-paid SIM card or from a MN's private authentication key (as described subsequently). To perform an authentication check, the MN must present its credentials (including its MID) to the NAR. The method to conceal these items over the air interface is not addressed here. This transmission also advertises its current CCoA (if any) which it may have auto-generated on arrival at this NAR. Consequently, this authentication information may be passed to the NAR with a CCoA (IPv6), or with a NULL source address (IPv4) as is commonly done with DHCP. In the latter case the NAR (acting as a proxy for the MN) substitutes its address for the NULL address. The NAR then forwards the information to the local authentication server with which it already has a Security Association (SA). The local authentication server may then contact other servers as necessary to perform the authentication check. The outcome of the check (along with the MN's public key) is returned to the NAR. If successful, the NAR computes a Private Authentication Key (PAK) for the MN as an MD5 hash of the MN's MID and the domain's private "network key" known to all domain ARs. The computation of PAK and PIK herein are based on the PID scheme of [CIP]. The PAK forms a shared secret known only to the MN and the network, and serves as proof of MN authentication to other NARs in the domain. Unsuccessful authentication results in service denial. After a successful authentication, the NAR checks the MN's CCoA and, if NULL (IPv4), allocates a new CCoA for the MN. Using the resultant CCoA, the NAR computes a Private Identification Key (PIK) for the MN as an MD5 hash of the MN's CCoA and the domain's private "network key" known to all domain ARs, encrypts the PIK and PAK with the MN's O'Neill, Corson, Tsirtsis 38 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 public key, and sends these to the MN along with the network's public key and the MN's CCoA. Being keyed to the MN's CCoA, the PIK is valid as long as the MN uses this CCoA. The PIK can be used to authenticate (and optionally to encrypt) IP control packets over the air interface. Authentication is performed by creating a short hash from the (PIK, timestamp, packet content) triple that is placed into the transmitted packets. The validity of each packet can be easily checked by any NAR even immediately after a handoff and without prior communication with the MN or with the OAR. In addition to authenticating control packets, the PIK can optionally also be used to provide security for data packets transmitted over the wireless link. To this avail, any known, shared secret-based security mechanism can be used where the PIK serves as the shared secret. 11. References [AAAMIP] S. Glass, et al., "Mobile IP Authentication, Authorization, and Accounting Requirements", Internet-Draft, draft-ietf-mobileip- aaa-reqs-04.txt (work in progress), June, 2000. [CIP] A. Campbell, et al., "Cellular IP", Internet-Draft, draft- ietf-mobileip-cellularip-00.txt (work in progress), January, 2000. [EMA] A. O'Neill, G. Tsirtsis, S. Corson, "Edge Mobility Architecture", Internet-Draft, draft-oneill-ema-02.txt (work in progress), July 2000. [SEL] R. Draves, "Default Address Selection for IPv6", , work in progress, October 1999. [MIPv4] C.E. Perkins, Ed., "IP Mobility Support," Internet RFC 2002, Oct 1996. [MIPv6] D. Johnson, C. Perkins, "Mobility Support in IPv6", Internet-Draft, draft-ietf-mobileip-ipv6-12.txt (work in progress), April, 2000. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [TORA] V. Park, M. S. Corson, "Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification", Internet-Draft, draft- ietf-manet-tora-spec-02.txt (work in progress), October 1999. O'Neill, Corson, Tsirtsis 39 Author's Addresses Alan O'Neill BT Phone: +44-20-88260073 Email: alan.w.oneill@bt.com M. Scott Corson University of Maryland Ansible Systems Phone: +1 301-405-6630 Email: corson@isr.umd.edu George Tsirtsis BT Phone: +44-20-88260073 Email: george.tsirtsis@bt.com Alternative: gtsirt@hotmail.com O'Neill, Corson, Tsirtsis 40 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into O'Neill, Corson, Tsirtsis 41 Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000 O'Neill, Corson, Tsirtsis 42