IETF NETLMM Working Group Anand Bedekar Internet Draft Ajoy Singh Vinod Kumar Suresh Kalyanasundaram Motorola draft-singh-netlmm-protocol-02.txt Expires: September 05, 2007 March 05, 2007 A Protocol for Network-based Localized Mobility Management Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document suggests a localized mobility solution controlled by the network within a local mobility domain. The proposed solution is based on Proxy Mobile IPv6 (PMIP) technique and employs a PMIP client that generates a Proxy Binding Update message. The solution allows for a clean separation between the bearer and signaling paths, and reuse of MIPv6 home agent as the local mobility anchor. The security association between the Singh et. al Expires September 5, 2007 [Page 1] Internet-Draft A Protocol for NETLMM March 5, 2007 network elements for executing the local mobility is also discussed. TABLE OF CONTENTS 1.0 INTRODUCTION...............................................3 2.0 TERMINOLOGY................................................3 3.0 BRIEF DESCRIPTION OF SOLUTION..............................5 4.0 PROTOCOL DETAILS...........................................7 4.1 INITIAL ATTACHMENT........................................7 4.2 INTRA-LMD MOBILITY........................................9 4.3 SECURITY ASSOCIATION BETWEEN PMIP CLIENT AND LMA..........11 4.4 INTER-LMA MOBILITY.......................................12 4.5 RELOCATION OF PMIP CLIENT.................................12 4.6 HANDLING OF MIPv6 CAPABLE MNs IN THE LMD..................12 4.7 PMIP CLIENT CONSIDERATIONS................................13 4.8 LMA CONSIDERATIONS........................................13 4.9 MAG - PMIP CLIENT INTERACTION.............................14 4.9.1 TRIGGER MESSAGE.........................................14 4.9.2 NOTIFICATION MESSAGE....................................15 4.9.3. MAG-PMIP client Transport..............................16 4.9.4. MAG-PMIP client Security...............................17 5.0 IANA CONSIDERATIONS........................................17 6.0 SECURITY CONSIDERATIONS....................................17 7.0 NORMATIVE REFERENCES.......................................18 8.0 INFORMATIVE REFERENCES.....................................18 9.0 AUTHORS' ADDRESSES.........................................19 APPENDIX A. pHoA ASSIGNMENT BY LMA UNDER STATEFUL ADDRESS CONFIGURATION ............................................................20 APPENDIX B. STATELESS ADDRESS AUTO-CONFIGURATION AND DUPLICATE ADDRESS DETECTION......................................................20 APPENDIX C. AAA-BASED MECHANISM FOR ESTABLISHING PER-MN SA.....21 APPENDIX D. CONTEXT TRANSFER AND DATA FORWARDING between MAGs 22 APPENDIX E. FUTURE EXTENSIONS..................................23 E.1 PMIP CLIENT RELOCATION.....................................23 E.2 IPV4 DATA TUNNELING INSIDE IPV6 E.3 USAGE OF PER-MN PREFIXES Singh et. al. Expires Septemeber 5, 2007 [Page 2] Internet-Draft A Protocol for NETLMM March 5, 2007 IPR STATEMENTS................................................25 Disclaimer of Validity........................................25 COPYRIGHT NOTICE..............................................25 Acknowledgment.............................................. 26 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documents are to be interpreted as described in RFC-2119 [1]. 1.0 INTRODUCTION In this draft, we describe a localized mobility management solution that is network controlled and does not involve change in IP address of the mobile node (MN) as it moves within a local mobility domain (LMD). The IP address of the MN may be its Home IP address (HoA) or a care-of-address (CoA) that has been obtained by the MN for global mobility management. As long as the MN is within one LMD, it is reachable on the same IP address, be it its HoA or its CoA. We propose a localized mobility management solution that employs a Mobile IPv6 home agent (HA), compliant with RFC 3775 [2], acting as the local mobility anchor (LMA). The proposed mechanism allows a clean separation of the signaling function of generating binding updates (BU) from the data plane function of terminating the local mobility tunnel, while retaining RFC compliance of MIPv6 HA. The entity generating BUs for a given mobile node is fixed within the LMD and this allows for efficient management of state information during mobility within the LMD. 2.0 TERMINOLOGY 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 [1]. The following terminology and abbreviations are used Mobile Node (MN) An IPv6 host that may or may not be capable of Mobile IPv6. Singh et. al. Expires September 5, 2007 [Page 3] Internet-Draft A Protocol for NETLMM March 5, 2007 Mobile Access Gateway (MAG) A functional IPv6 entity that terminates a specific edge link towards the MN. The MAG also terminates host routed data traffic from the Local Mobility Anchor for MNs currently located within the edge link under the MAG's control, and forwards traffic from MNs on the edge link under its control to the Local Mobility Anchor. Global Mobility Anchor (GMA) A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775 [2], capable of RADIUS [8] and can fetch MN-AAA keys from the AAA server [9]. Local Mobility Anchor (LMA) A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775 [2] responsible for receiving Proxy Binding Updates (PBU) from the PMIP client within a local mobility domain (LMD). Local Mobility Domain (LMD) An administrative network that contains several MAGs within which an MN can maintain its IP address. Proxy Binding Update (PBU) A standard Mobile IPv6 Binding Update (BU) message, as described in RFC 3775 [2], sent by the PMIP client whenever the MNs move across MAGs within a local mobility domain (LMD). Proxy Binding Acknowledgment (PBAck) A standard Mobile IPv6 Binding Acknowledgment (BAck), as described in RFC 3775 [2], message sent by the local mobility agent (LMA) in response to a PBU message. PMIP Client A functional entity responsible for sending Proxy Binding Update (PBU) message to the local mobility anchor (LMA) on behalf of the MN whenever the MN moves across MAGs within a local mobility domain (LMD). Singh et. al. Expires September 5, 2007 [Page 4] Internet-Draft A Protocol for NETLMM March 5, 2007 Local AAA Server A standard AAA server located within a local mobility domain (LMD), responsible for generating security keys required by the PMIP client and local mobility anchor (LMA) for performing IKE. Local AAA Client A standard AAA client function located at the local mobility anchor (LMA) and PMIP client, used for fetching the keys from the local AAA server. Proxy Home Address (pHoA) An IP address acquired by the MN when it enters the LMD. This IP address does not change as long as the MN remains within the LMD. Proxy Care-of-Address (pCoA) Refers to the IP address of the MAG to which the MN is currently attached. Traffic destined for the MN's pHoA is tunneled to pCoA by the LMA. 3.0 BRIEF DESCRIPTION OF SOLUTION The proposed solution is based on a proxy Mobile IP (PMIP) Technique, wherein a PMIP client sends binding update messages to a local mobility anchor (LMA) to establish a mapping between the MN's IP address and the IP address of the current MAG through which the MN is reachable. A given LMA has several MAGs under it, and these MAGs may or may not be co-located with base stations or access points that terminate the layer 2 protocol with the MN. The MN may be Mobile IP capable and may send BU messages for inter-LMD mobility, i.e., global mobility. For local mobility, the MAGs within an LMD make the MN believe that it is still within the same subnet, and thus prevent the MN from initiating Mobile IP messages. The MAGs in an LMD advertise the same prefix to the MN in their router advertisement messages as the MN moves across different MAGs. The figure 1 describes a local mobility domain with standalone PMIP client. Singh et. al. Expires September 5, 2007 [Page 5] Internet-Draft A Protocol for NETLMM March 5, 2007 +-------+ | GMA | +-------+ / \ / \ / \ / \ / \ / \ +-------+ +-------+ | LMA1 | | LMA2 | +-------+ +-------+ / \ | / \ | +-------+ / \ | | PMIP | / \ | | client| / \ | +-------+ / \ | +-----+ +-----+ +-----+ | MAG1| | MAG2| | MAG | +-----+ +-----+ +-----+ +--+ +--+ |MN|------------->|MN| +--+ +--+ Figure 1) Local Mobility Domain with a stand alone PMIP client This draft proposes a solution where the LMA is a Mobile IPv6 Home Agent[2]. This allows reuse of existing standard IETF components and avoids additional work of standardizing a new mobility anchor. When an MAG realizes that an MN has made an L2 handoff to a cell that it serves, the MAG triggers the PMIP client to initiate and send a PBU to the LMA, which will establish a mapping between the MN's current IP address and the MAG's IP address. In general, the PMIP client may or may not be co-located with the MAG. However, to avoid the security keys associated with the MN from being transferred from one MAG to the other as the MN hands off from one cell to another, this draft requires the PMIP client to be fixed for a given MN for the duration that the MN is within Singh et. al. Expires September 5, 2007 [Page 6] Internet-Draft A Protocol for NETLMM March 5, 2007 that LMD. The sections that follow explain in detail the procedures used in localized mobility management. 4.0 PROTOCOL DETAILS The protocol consists of two parts: Procedures used during initial attachment of an MN to the LMD, and procedures used during intra-LMD mobility. 4.1 INITIAL ATTACHMENT When the MN first connects to a MAG in the LMD, it is assumed to have acquired an IP address from the GMA called its Home Address (HoA). The process of obtaining HoA from the GMA is beyond the scope of this document. This HoA may be required for the MN for global mobility management using MIPv6. Note that the MN need not be MIPv6 capable for localized mobility management to operate within the LMD. We consider the general case where the MN is MIPv6-capable, and the GMA and the LMA are different. Figure 2 shows the set of procedures involved when the MN first connects to a MAG, say MAG1, in the LMD. 1. The MN performs L2 attachment with an access point under MAG1. The MAG1 obtains the MN identifier [3] based on this L2 attachment procedure. The exact means by which MAG1 obtains the MN identifier is outside the scope of this document. 2. After receiving the prefix as part of the router advertisement from MAG1, the MN attempts to acquire another IP address, called the Proxy Home Address (pHoA) associated with the advertised prefix. The MN issues a DHCP request and a DHCP server assigns a pHoA consistent with the advertised prefix. The MAG can act as DHCP relay and learn the IP address assigned to the MN by observing the response from the DHCP server. Another address assignment mechanism where the pHoA is assigned by the LMA can also be used as outlined in Appendix A. Alternatively, the pHoA may instead be acquired through stateless auto-configuration as described in Appendix B. 3. The MAG1 sends a trigger message to the PMIP client to send a PBU message to the LMA. The trigger message contains the MN identifier and the pHoA acquired by the MN. When there are Singh et. al. Expires September 5, 2007 [Page 7] Internet-Draft A Protocol for NETLMM March 5, 2007 multiple PMIP clients in the LMD, the PMIP client for an MN can be assigned statically (e.g. based on the MN identifier) or dynamically chosen by MAG1 by means outside the scope of this draft. 4. The PMIP client constructs a PBU message to bind the MN's acquired pHoA with the MAG1's IP address (pCoA). The PBU message also contains the MN identifier option as specified in [3]. This assumes that the PMIP client has established the required security association (SA) with the LMA after suitably acquiring the keys required for such an association. The PMIP client sends the PBU message directly to the LMA and sets the Alternate CoA field to the MAG1's IP address (pCoA), and the source address will be the PMIP client's address After the reception of PBU, the LMA processes the message according to RFC 3775. After successful validation, the LMA creates a binding to tunnel all packets destined for MN's pHoA to the MAG1's IP address (pCoA), and also generates an appropriate PBAck message destined to the PMIP client. 6. The PMIP client sends the PBAck Verification Status message to the MAG1 after verifying the status of the PBack message sent by the LMA within a suitably encapsulated container message. The information in the PBAck message enables the MAG1 to start de- tunneling any tunneled packets received from the LMA and forwarding them to the MN. 7. A MIPv6 capable MN can then send a MIPv6 binding update (BU) to the GMA for global mobility, thus establishing a binding between the MN's HoA and the pHoA acquired by the MN in the LMD. The MIPv6-capable MN subsequently receives a binding acknowledgment(BAck) from the GMA. Singh et. al. Expires September 5, 2007 [Page 8] Internet-Draft A Protocol for NETLMM March 5, 2007 MN MAG1 PMIP LMA GMA client | | | | | | | | | | 1.MN performs | | | | L2 attachment | | | | | | | | | |<-2.Router Adv-| | | | | | | | | | 2.pHoA | | | | |<=============>| | | | | acquisition | | | | | | | | | | |--3.Trigger-->| | | | | (MN ID, pHoA)| | | | | |----4.PBU---->| | | | |(MN ID,pHoA,pCoA) | | | | | | | | |<---5.PBAck---| | | | | | | | |<---6.PBAck---| | | | | verification | | | | | status | | | | | | | | |-------------------------7.BU----------------------------->| | | | | | |<-----------------------7.BAck-----------------------------| | | | | | | | forward packets | | |<==============|<============================|<============| | | | | | Figure 2) Procedure for MN's initial attachment to LMD 4.2 INTRA-LMD MOBILITY Figure 3 shows the procedures involved when the MN moves across MAGs within the LMD. 1. When the MN hands off from MAG1 to MAG2, the MAG2 also advertises the same prefix to the MN as was sent by MAG1 in its router advertisement to that MN. Due to this, the MN does not try to acquire a new address or invoke global mobility procedures. The MAG1 transfers the MN's context and potentially data packets to MAG2. For example, context transfer can be performed using Context Transfer Protocol (CXTP) [10]. The MN's context will contain the MN identifier, the pHoA that was configured by the MN during its initial attachment to the LMD, and the location of the PMIP client Singh et. al. Expires September 5, 2007 [Page 9] Internet-Draft A Protocol for NETLMM March 5, 2007 for the MN. The location of the PMIP client need not be transferred if there is only one PMIP client in the LMD or if the PMIP client can be determined based on the MN identifier. 2. The MAG2 triggers the PMIP client to send a PBU. The trigger to the PMIP client, as before, contains the MN identifier and the pHoA. The PMIP client will check whether the same MN identifier - pHoA combination exists in its cache. In the intra-LMD mobility case, the cache entry will be found. If the cache entry is found, the PMIP client will use this trigger to send a new PBU. 3. The PMIP client constructs and sends a PBU message to the LMA for binding the pHoA to the MAG2's IP address (new pCoA). The MN identifier need not be sent as part of this PBU message. 4. The LMA now binds the MN's pHoA to MAG2's IP address (new pCoA) and responds with a PBAck message. Henceforth, the packets destined to MN's pHoA will be tunneled to the MAG2's address. 5. The PBAck verification status is sent to MAG2 as a response to the trigger message. The PMIP client can be a separate entity as shown in Figure 1 having a centralized control of the security keys involved in sending the PBU messages. Alternatively, the PMIP client can be co-located at one of the MAGs. This MAG, for example can be the one where the MN first acquired its IP address in the LMD. Even in this case the security keys involved in the Mobile IP signaling shall be anchored at a single MAG. During handoffs, only the tunnel end-point (i.e. the data plane) will be migrated to the new MAG, whereas the PBU message (i.e. the control-plane signaling) will still be generated at the anchored MAG. In addition, the security keys associated with the signaling shall not be transferred across MAGs during the handoff. Because the PBUs for a given MN always originate from the same PMIP client as long as the MN is within the LMD, the sequence numbers in the PBU messages as defined in RFC3775 [2] are sufficient to ensure ordering of messages. Thus there is no need to add extensions to the MIPv6 BU or BAck messages, such as timestamp extensions, to resolve any potential race conditions that might arise if multiple entities send BUs for a given MN. Singh et. al. Expires September 5, 2007 [Page 10] Internet-Draft A Protocol for NETLMM March 5, 2007 MN MAG1 MAG2 PMIP LMA client | | | | | |----------1.L2 Handoff------->| | | | | | | | | | 1.MN context | | | | |<====&data===>| | | | | transfer | | | | | |---2.Trigger-->| | | | | (MN ID, pHoA) | | | | | | | | | | |---3.PBU--->| | | | |(pHoA, pCoA)| | | | | | | | | |<--4.PBAck--| | | | | | | | |<---5.PBAck----| | | | | verification | | | | | status | | | | | | | | | forward packets | | |<=============================|<===========================| | | | | | Figure 3) Intra-LMD handoff procedure 4.3 SECURITY ASSOCIATION BETWEEN PMIP CLIENT AND LMA Security is provided for the PBU messages by having the LMA maintain a separate SA for each MN. The method by which the PMIP client obtains the security credentials of the MN is outside the scope of this document. However, one mechanism that depends on AAA infrastructure is shown in Appendix C. It is possible that the LMA can be accessed through different PMIP clients, for example, if the PMIP client is co-located at the MAG. For these cases, the mechanism described in Appendix C is well suited as it is scalable with the number of PMIP clients in the LMD. The fact that the PMIP client obtained the security keys corresponding to the MN automatically implies that the PMIP client is authorized to send PBUs on behalf of the MN. Alternatively, instead of using per-MN SAs, security associations between every PMIP client and the LMA can be established. While using per-MN SA is fully compliant with RFC 3775 and hence allows complete reuse of MIPv6 HA as the LMA, using per-PMIP client SA may reduce the number of SAs required but will require modifications to the MIPv6 HA before it can be used as the LMA. Singh et. al. Expires September 5, 2007 [Page 11] Internet-Draft A Protocol for NETLMM March 5, 2007 4.4 INTER-LMA MOBILITY We assume a general situation where a given MAG may be able to have tunnels with multiple LMAs, so that LMD can be overlapping. When it is desired to change the anchor point of the mobile to a new LMA (either when a mobile hands over to a different MAG, or even when the mobile remains under the same MAG), the presence of the new LMA is made known to the MN by advertising a different prefix to the MN. Such a change of LMAs can be carried out for routing efficiency reason. The PMIP client used to establish a proxy binding to the new LMA may be the same as with the old LMA, or a new PMIP client may be invoked. In either case, a new MN- specific SA may need to be established between the appropriate PMIP client and the new LMA for securing PBU messages when per-MN SA is used. The MN also needs to acquire a new pHoA consistent with the new link prefix advertised by the MAG. As an alternative, the same AAA based mechanism as described in Appendix B can be used. 4.5 RELOCATION OF PMIP CLIENT The mobility management solution proposed in this document allows multiple PMIP clients to be present in the LMD. But the PMIP client for a given MN is fixed within the LMD for the lifetime of the MN. This ensures that the security keys for that MN is anchored at a single node and not transferred between PMIP clients when per-MN SA is used to secure PBU messages. The data plane, however, is migrated to a different MAG when the MN moves across MAGs. In addition, data forwarding is supported from source MAG to target MAG during handoff and hence no packet losses are expected due to the signaling exchange between the current MAG and the PMIP client. The MN continues to receive the packets forwarded from the source to target MAG while the LMA is being updated. In case relocation of PMIP client is required for other reasons, a mechanism as described in Appendix E.1 may be used. 4.6 HANDLING OF MIPv6 CAPABLE MNs IN THE LMD In the solution proposed above, all the MAGs in the LMD advertise the same link prefix to a given MN. All MNs, irrespective of whether or not they are MIPv6 capable, are managed by PMIP-based localized mobility management solution as long as they remain Singh et. al. Expires September 5, 2007 [Page 12] Internet-Draft A Protocol for NETLMM March 5, 2007 within the LMD. The MIPv6 capability of an MN is used only when it moves across LMDs, in order to update the binding with the GMA. 4.7 PMIP CLIENT CONSIDERATIONS The PMIP client functional entity is responsible for sending PBU messages to the LMA for binding the pHoA of the MN with the IP address of the MAG (pCoA) to which the MN is currently connected. The PMIP client sends the PBU message after receiving the trigger from the MAG. The trigger can be for an MN that is performing initial attachment or for an MN that has moved to a different MAG within the LMD. The trigger provides the MN identifier (and the pHoA of the MN, if acquired by DHCP). The PMIP client first checks if it has already sent a PBU for the MN with the received MN identifier. This can be done, for example, by maintaining a binding cache that contains the MN identifier, pHoA, and the MAG's IP address (pCoA) for those MNs for whom PBUs have been sent and by checking if the MN identifier received as part of the trigger already exists in the cache. If no entry exists in the cache for the received MN identifier, the PMIP client considers this MN as performing initial attachment to the LMD. It then forms a PBU message and sends it to the LMA. In case an entry exists in its cache for the received MN identifier, the PMIP client further checks if the pHoA in the received trigger matches with the pHoA against this MN identifier in the cache. If it does not, this is considered as an error and an error status is reported to the MAG. In case the right combination of MN identifier and pHoA exists, the MN is considered to have moved to a different MAG within the LMD. Consequently, an appropriate PBU message is sent to the LMA. After receiving the PBAck message from the LMA, the PMIP client needs to process it and respond to the MAG with appropriate status information. 4.8 LMA CONSIDERATIONS The mobility management solution described in this document allows reusing MIPv6 HA as the LMA without any additional modifications. Some of the mechanisms described in the appendices may require modifications to the MIPv6 HA behaviour, as indicated in the relevant appendices. Singh et. al. Expires September 5, 2007 [Page 13] Internet-Draft A Protocol for NETLMM March 5, 2007 4.9 MAG - PMIP CLIENT INTERACTION This document describes clean separation between PMIP client that generates the PBU signaling and the MAG that acts as the tunnel end-point. It also suggests that PMIP client for a given MN must be anchored at a single entity while the MN moves from one MAG to other. A light-weight protocol is defined between PMIP client and MAG to enable interaction between them. The protocol between PMIP client and MAG defines two messages, namely Trigger and Notification. Trigger Message is used by MAG to inform PMIP client that an MN has associated with it, either during initial network entry or after inter-MAG handoff. Notification Message is used by PMIP client to inform MAG that the Binding Update procedure with LMA has been completed. As part of Notification message, PMIP client encapsulates the Binding Ack / Error message received from the LMA and delivers it to MAG. After receiving the Binding Ack through the Notification Message, the MAG creates the appropriate tunnel state required for tunneling and de-tunneling of bearer packets between MAG and LMA. A Transaction Number is used to correlate Trigger and Notification messages. The format of Trigger and Notification messages are defined the in following sections 4.9.1 TRIGGER MESSAGE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Ver| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Fields: Type : 0x1 Length of message in units of octets Version: 3 bit versions. For this specification ver. is set to 1. Singh et. al. Expires September 5, 2007 [Page 14] Internet-Draft A Protocol for NETLMM March 5, 2007 Reserved: Initialized to zero and ignored on receipt Transaction number: Allows the notification message to be matched with the trigger message 4.9.2 NOTIFICATION MESSAGE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Ver| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Fields: Type : 0x2 Length of message in units of octets Version: 3 bit versions. For this specification ver. is set to 1. Reserved: Initialized to zero and ignored on receipt Transaction number: Allows the notification message to be matched with the trigger message 4.9.3. Options Format All options are of the following form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type| Option Len | Option Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: 8-bit identifier of the type of option. The options defined in this document are L2-ID option, IP address option and container option. L2-ID option is used to encode MN Identifier, IP Singh et. al. Expires September 5, 2007 [Page 15] Internet-Draft A Protocol for NETLMM March 5, 2007 address option is used to encode MN home address, and container sub-option is used to encapsulate PBAck messages from PMIP client to MAG. 4.9.3. MAG-PMIP client Transport This document suggests that implementation of PMIP client MAG protocol SHOULD use the Stream Control Transport Protocol (SCTP) [5] as the transport protocol. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. The SCTP Payload Data Chunk carries the Trigger and Notification messages. User Data part of each SCTP message contains the Trigger and Notification messages as described above. A single stream is used for PMIP-MAG protocol with in- sequence delivery of SCTP messages. Each message, unless fragmented, corresponds to a single Trigger or Notification message. A single stream provides simplicity. The Payload Protocol Identifier in the SCTP header is 'PMIP-MAG'. PMIP-MAG interface uses a PMIP- MAG SCTP port to be identified by IANA. The format of Payload Data Chunk taken from SCTP RFC is shown in the following diagram. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'U' bit The Unordered bit. MUST be set to 0 (zero). 'B' bit The Beginning fragment bit. See [5]. 'E' bit The Ending fragment bit. See [5]. TSN Transmission Sequence Number. See [5]. Singh et. al. Expires September 5, 2007 [Page 16] Internet-Draft A Protocol for NETLMM March 5, 2007 Stream Identifier S Identifies the SCTP stream. Stream Sequence Number n Sequence number. See [5]. Payload Protocol Identifier Set to 'PMIP-MAG'. User Data Contains the PMIP message. 4.9.4. MAG-PMIP client Security To prevent the information from being compromised, the Trigger and Notification messages between PMIP client and MAG MUST be authenticated. The messages MAY also be encrypted for privacy of the information, if required. The PMIP client and the MAG engaging in the PMIP-MAG protocol MUST use IKE [7] to negotiate an IPsec ESP [6] security association for message authentication. If confidentiality is desired, the PMIP client and the MAG MUST additionally negotiate an ESP security association for encryption. Replay protection SHOULD also be enabled with IKE. To protect PMIP client-MAG protocol messages between PMIP client and MAG, IPsec ESP MUST be used with a non-null integrity protection and origin authentication algorithm and SHOULD be used with a non-null encryption algorithm for protecting the confidentiality of the Trigger and Notify message. 5.0 IANA CONSIDERATIONS This document defines a transport protocol that runs over SCTP between PMIP client and MAG. So, the PMIP client and MAG would need a well known SCTP port to communicate with each other. The port number for the SCTP port for PMIP client-MAG protocol use should be defined by IANA. 6.0 SECURITY CONSIDERATIONS To avoid security vulnerabilities, the security keys and the IPSec SA are anchored at a single node, i.e., PMIP client, for handoffs. Even when the PMIP client is at a MAG, there is an Singh et. al. Expires September 5, 2007 [Page 17] Internet-Draft A Protocol for NETLMM March 5, 2007 anchored MAG that holds the MN's security keys, which may be different for different MNs. There is a separate IPSec SA for each MN, even though several MNs may use the same LMA and PMIP client. Alternatively, a single IPSec SA between a PMIP client and an LMA may be used to protect the signaling for all the MNs being handled by the PMIP client. IPSEC ESP is used to protect PMIP client to MAG protocol as defined in section 4.9.4. 7.0 NORMATIVE REFERENCES [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] D. Johnson et al., "Mobility Support in IPv6", RFC 3775, June 2004 [3] A. Patel et al., "Mobile Node Identifier Option for Mobile IPv6 (MIPv6) ", RFC 4283, November 2005 [4] J. Arkko et al., "Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004 [5]Stewart, R. et al. "Stream Control Transmission Protocol", RFC 2960, October 2000. [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [7] D. Harkins et al., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 8.0 INFORMATIVE REFERENCES [8] C. Rigney et al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000 [9] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August 2000 [10] J. Loughney et al., "Context Transfer Protocol", RFC 4067, July 2005 Singh et. al. Expires Sepetember 5, 2007 [Page 18] Internet-Draft A Protocol for NETLMM March 5, 2007 [11] S. Thomson et al., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998 [12] P. Calhoun et al., "Diameter Base Protocol", RFC 3588,September 9.0 AUTHORS' ADDRESSES Anand Bedekar Motorola Inc 1501 West Shure Dr, Arlington Heights 60004 USA Phone: +1 847-632-3046 Email: anand.bedekar@motorola.com Ajoy Singh Motorola Inc 1501 West Shure Dr, Arlington Heights 60004 USA Phone: +1 847-632-6941 Email: asingh1@email.mot.com Vinod Kumar Motorola India Electronics Limited 66/1, Plot No. 5, Bagmane Tech Park CV Raman Nagar Post Bangalore 560093 India Phone: +91-80-26012308 Email: vinodkumar@motorola.com Suresh Kalyanasundaram Motorola India Electronics Limited 66/1, Plot No. 5, Bagmane Tech Park CV Raman Nagar Post Bangalore 560093 India Phone: +91-80-26012308 Singh et. al. Expires Sepetember 5, 2007 [Page 19] Internet-Draft A Protocol for NETLMM March 5, 2007 Email: Suresh.Kalyanasundaram@motorola.com APPENDIX A. pHoA ASSIGNMENT BY LMA UNDER STATEFUL ADDRESS CONFIGURATION Under stateful pHoA address configuration, the MN issues a DHCP request. The MAG to which the MN is currently attached acts as a proxy DHCP server. That is, it receives the DHCP request and will send a DHCP reply to the MN, but it will obtain the address to assign to the MN in the following manner. The MAG sends a Trigger message to the PMIP client to send a PBU on behalf of the MN. This Trigger message contains the MN identifier that may be obtained when the MN makes L2 attachment. The PBU sent to the LMA contains the MN identifier but pHoA field remains ALL-ZEROS. The LMA, as part of the PBAck message, assigns a pHoA for the MN. This address is communicated by the PMIP client to the MAG in the Notification message. The MAG, sends this address as part of the DHCP reply to the MN. This method of LMA assigning IP addresses for the MN requires that the MIPv6 HA support dynamic home address assignment, a capability not present in [2]. APPENDIX B. STATELESS ADDRESS AUTO-CONFIGURATION AND DUPLICATE ADDRESS DETECTION Instead of the DHCP-based procedure, the pHoA can be acquired by an MN during initial attachment using stateless address auto- configuration. In stateless configuration, the MN configures its own pHoA based on the prefix advertised by the MAG and sends a Neighbor Solicitation (NS) message as specified in [11]. The MAG to which the MN is currently attached triggers the PMIP client to send a PBU. The trigger contains a flag indicating to the PMIP client whether the address is acquired through stateful or stateless configuration and hence determines the need for DAD. The PMIP client verifies if the pHoA configured by the MN is unique by checking its cache and determining if any MN with a different MN identifier has already acquired the same address. If no conflicting address is found, and if there are multiple PMIP clients in the LMD, the PMIP client sends a "conflict detection request" to other PMIP clients in the LMD to check for uniqueness. This request can also be sent immediately after receiving the trigger from the MAG. The request contains the MN identifier and the pHoA configured by the MN. Singh et. al. Expires September 5, 2007 [Page 20] Internet-Draft A Protocol for NETLMM March 5, 2007 The other PMIP clients in the LMD check for uniqueness in a similar fashion as above and respond with "conflict detected" or "no conflict" message to the original PMIP client. In case the address is not unique, the PMIP client informs the MAG with PBAck verification status message that has "address conflict detected" as the reason. Otherwise, the PMIP client sends PBU for the MN. Thus address conflicts are detected by the PMIP client (if there is only one in the LMD), or by inter-PMIP client interaction (if there are multiple PMIP clients in the LMD). Note that when the LMA receives the PBU, it will perform DAD as described in RFC 3775 to ensure that no other MN for whom the LMA is acting as MIPv6 HA is using the same address. If the prefixes advertised to the MNs are such that a particular prefix is routable only to a single LMA, then the PMIP client can depend on the DAD performed by the LMA itself, and no further action by the PMIP client is required. The execution of DAD by the PMIP client (or by interaction of multiple PMIP clients) is required only if any particular prefix may be routable to more than one LMA. If the MAGs in the LMD advertise the LMA's prefix, the addresses acquired using stateless auto-configuration will be suitable for point-to-point links between the MN and MAG. Another alternative is for the MAG to send a separate prefix for each MN and the MN can acquire pHoA consistent with this per-MN prefix. A prefix of length 128 bits eliminates the need for DAD and does not invoke any shared-link procedures while a shorter prefix will lead to wastage of address space. APPENDIX C. AAA-BASED MECHANISM FOR ESTABLISHING PER-MN SA The following mechanism can be used to dynamically establish per-MN SA between the PMIP client and the LMA. For carrying out this mechanism the LMA and the PMIP client shall have local AAA client function. This scheme can be used when the PMIP client is either a stand-alone entity or co-located with the MAG. This scheme uses a separate key for a separate IPSec SA for each MN as in [4], even when they use the same PMIP client and LMA. Note that we assume that the PMIP client for a given MN remains fixed after the binding is established for that MN at the LMA. The AAA client colocated with the PMIP client can fetch the key required for establishing the SA with the LMA from the local AAA Singh et. al. Expires September 5, 2007 [Page 21] Internet-Draft A Protocol for NETLMM March 5, 2007 server. The key fetch transaction may be triggered by other events related to the MN's attempt to access the MAG, for example the authentication of the MN for access to the domain. In cases where the local AAA server is either the home AAA server of the MN or a AAA proxy server in the MN's authentication, further synchronization of the key fetching with the MN's authentication process may be possible. After getting the key from the local AAA server, the PMIP client should initiate Internet Key Exchange (IKE) [7] with the LMA. The LMA in turn, using its associated AAA client, queries the local AAA server and fetches the key required for the IKE processing. The local AAA server should remember the key that has been sent to the PMIP client until the LMA asks for it. Following IKE, the PMIP client can send the PBU message. The IPSec endpoint corresponding to the MN's pHoA for the SA is at the PMIP client instead of the MN. For the interaction between the local AAA server, PMIP client, and LMA, standard AAA protocols, such as, RADIUS [8] or DIAMETER [12] can be used. When the MN-specific SA is used, the key for this SA is provided to the PMIP client by the AAA server only after verifying that the PMIP client is authorized to send PBUs for that MN (e.g., at the time the MN is authenticated in to the domain for link-layer access). The fact that the AAA server provides the MN-specific key for that PMIP client to the LMA during IKE procedure also serves as validation that the PMIP client is authorized to send BUs for that MN. In this model of PMIP client anchored for a given MN, the LMA will have to contact the AAA server once per MN. In the alternative model where there is a single SA between a PMIP client and an LMA to protect the BUs for all MNs, this AAA procedure can be used to bootstrap the IPSec security association between the PMIP client and the LMA. This mainly helps in simplifying network configuration, by avoiding the need to pre-distribute shared keys for every pair of PMIP client and LMA. In this model, if there are multiple PMIP clients in the domain (e.g. if each MAG is collocated with a PMIP client), the HA may additionally need to contact the AAA server once per MN in order to obtain a list of PMIP clients that are authorized to send BUs for that MN. APPENDIX D. CONTEXT TRANSFER AND DATA FORWARDING between MAGs Singh et. al. Expires September 5, 2007 [Page 22] Internet-Draft A Protocol for NETLMM March 5, 2007 As noted in section 4.2, when an MN hands over from MAG1 to MAG2, MAG2 will send a trigger message to the PMIP client for that MN to send a PBU to the LMA. MAG2 minimally needs the MN identifier in order to send the trigger message to the PMIP client. This may be obtained by MAG2 directly from the MN through L2 attachment procedures. However, in terms of handover latency, it would be beneficial if MAG2 could obtain the MN Identifier prior to the completion of the L2 attach procedure. Additionally, if there are multiple PMIP clients in the domain (e.g. if each MAG is collocated with a PMIP client), then MAG2 needs to know the address of the PMIP client for that MN in order to send the PMIP Furthermore, it would be useful for the MAG2 to provide the pHoA of the MN in the trigger message to aid the PMIP client in performing some error checks. Since all these information elements are available at MAG1, MAG1 should forward such context information for the MN to MAG2. The Context Transfer Protocol (CXTP) [10] can be used to accomplish this, using suitably defined feature profile types for CXTP. In addition to context transfer, it is also useful to have data forwarding from MAG1 to MAG2 during the MN's handover. In the absence of such data forwarding, the MN would not receive any data through MAG2 until the PBU message was processed at the LMA, resulting in increased handover latency. In order to eliminate this latency, MAG1 should forward data for the MN to MAG2 during the handover. This data forwarding should include data buffered at MAG1 at the time of initiation of the handover, plus any subsequent data that arrived at the MAG1. Thus data flow for the MN can be resumed immediately on completion of the L2 attachment procedures, without waiting for completion of the PBU signaling to the LMA. APPENDIX E. FUTURE EXTENSIONS E.1 PMIP CLIENT RELOCATION If there are multiple PMIP clients in the domain, and if PMIP client relocation for a given MN is required, the MAG can choose a new PMIP client to serve the MN. The PMIP client has to establish a new MN-specific SA with the LMA if per-MN SA is employed. The new PMIP client can use the AAA-based solution as specified in Appendix C for establishing this SA. This will again require modifications to the behavior of a MIPv6 HA in order to function Singh et. al. Expires September 5, 2007 [Page 23] Internet-Draft A Protocol for NETLMM March 5, 2007 as an LMA, since the LMA will now receive PBUs for the same MN through different SAs. E.2 IPV4 DATA TUNNELING INSIDE IPV6 While the situation considered in the draft assumes only IPv6 capability at all the elements, it may be of interest to support IPv4-capable mobiles with IPv6-enabled network elements. For example, it may be of interest to support access to the IPv4 Internet for an IPv4-capable mobile, even when all the network elements in the LMD are IPv6-capable. One possible solution for this scenario is to use a dual-stack LMA that acts as a gateway to the IPv4 Internet while providing network localized mobility using IPv6 inside the LMD. For example, the PBU sent by the PMIP client to the LMA can include extensions to carry the IPv4 address of the MN for which IPv4 access is desired. The LMA would then tunnel all IPv4 packets destined to this IPv4 address to the pCoA of the PBU (i.e. the address of the MAG). The MAG would de-tunnel the IPv6 packets received from the LMA to recover the IPv4 packet, and forward the IPv4 packet to the MN. Note that in order to provide this functionality, extensions need to be defined to Mobile IPv6 messages and modifications to the behavior of a MIPv6 HA are required in order to provide such capabilities. E.3 USAGE OF PER-MN PREFIXES In some situations it may be of interest to allocate each MN a unique prefix, instead of advertising a single prefix (e.g. the LMA's prefix) to multiple MNs. This would be useful, for example, when the MN itself is a router for a moving subnet, or when the MN may have multiple interfaces on the same link, etc. Another reason to use per-MN prefixes is to avoid the need for DAD and NS in situations where the physical link is shared by multiple MNs (rather than a point-to-point link between the MN and the MAG). This can create the illusion of non-overlapping links for individual MNs even when the physical link is shared between multiple MNs. The allocation of per-MN prefixes can be accommodated by the model of this draft. One way to handle tunneling for multiple addresses configured by the MN from the per-MN prefix is to include the entire prefix Singh et. al. Expires September 5, 2007 [Page 24] Internet-Draft A Protocol for NETLMM March 5, 2007 (rather than just a single pHoA) in the PBU sent by the PMIP client to the LMA. The LMA would then install a route for the entire prefix, rather than a route for a single pHoA. This can be accommodated in the model proposed in this draft by a suitable extension to the Mobile IPv6 messages to carry prefixes, and a suitable modification to the MIPv6 HA behavior for use as the LMA. IPR STATEMENTS The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. COPYRIGHT NOTICE Singh et. al. Expires September 5, 2007 [Page 25] Internet-Draft A Protocol for NETLMM March 5, 2007 "Copyright (C) The IETF Trust (2007). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Acknowledgment We would like to thank Vijay Raman for editing first version of this draft. We would also like to thank Sebastian Thalanany, Pierrick SEITE, Christian Vogt, Pete McCann, Petrescu Alexandru, Julien Laganier, Behcet Sarikaya, Phil Roberts, Vidya Narayanan, Marco Liebsch and other members of NETLMM WG for reviewing and providing feedback on the draft. Singh et. al. Expires September 5, 2007 [Page 26]