IETF NETLMM Working Group Vijay Raman Internet Draft Anand Bedekar Ajoy Singh Suresh Kalyanasundaram draft-raman-netlmm-protocol-00.txt Motorola Expires: August 2006 February 2006 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/ietf/1id-abstracts.txt To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document suggests a local mobility solution controlled by the network within a local mobility domain. The proposed solution employs a Proxy Mobile IPv6 client that generates a Proxy Binding Update message. Two variants of the solution are suggested depending on the realization of the Proxy Mobile IP client function. The security association between the network elements for executing the local mobility is also discussed. Raman Expires August 27, 2006 [Page 1] Internet-Draft A Protocol for NETLMM February 2006 TABLE OF CONTENTS 1.0 INTRODUCTION..................................................2 2.0 TERMINOLOGY...................................................3 3.0 BRIEF DESCRIPTION OF SOLUTION.................................4 4.0 PROTOCOL DETAILS..............................................6 4.1 INTRA-LMD MOBILITY.........................................8 4.2 KEY EXCHANGES FOR SIGNALING................................9 4.3 ADDRESS CONFIGURATION AND DUPLICATE ADDRESS DETECTION.....10 4.4 INTER-LMA MOBILITY........................................11 5.0 USING AN HMIPV6 MAP AS LMA...................................11 5.1 MAP DISCOVERY.............................................12 6.0 IANA CONSIDERATIONS..........................................13 7.0 SECURITY CONSIDERATIONS......................................13 8.0 NORMATIVE REFERENCES.........................................13 9.0 INFORMATIVE REFERENCES.......................................13 10.0 AUTHORS' ADDRESSES..........................................14 IPR STATEMENTS...................................................14 Disclaimer of Validity...........................................15 COPYRIGHT NOTICE.................................................15 Acknowledgment...................................................16 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 [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 as it moves across one local mobility domain (LMD). The IP address of the mobile may be the Home IP address of the mobile (HoA) or a care-of-address (CoA) that has been obtained by the mobile for global mobility management. As long as the mobile is within one LMD, it is reachable on the same IP address, be it its HoA or its CoA. We propose two localized mobility management solutions, both of which use IETF-standards compliant functions as the local mobility anchor (LMA) in the local mobility domains. The first employs a Mobile IPv6 home agent (HA), compliant with RFC 3775 [2], acting as the local mobility anchor (LMA). The second employs a Hierarchical Mobile IPv6 Mobility Anchor Point (MAP), compliant with RFC 4140 [3], acting as the local mobility anchor (LMA). We also propose a mechanism that allows separation of the signaling function of generating binding updates (BU) from the data plane function of Raman Expires August 27, 2006 [Page 2] Internet-Draft A Protocol for NETLMM February 2006 terminating the local mobility tunnel, while retaining RFC compliance of the above mobility anchoring functions. 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) A Mobile IPv6 host. Access Router (AR) An IPv6 entity capable of providing both layer 2 and layer3 connectivity to the MN. An AR can implement an optional PMIP assistant functionality Global Mobility Anchor (GMA) A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775 [2], capable of RADIUS [5] and can fetch MN-AAA keys from the AAA server [6]. Local Mobility Anchor (LMA) A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775 [2] or an HMIPv6 Mobility Anchor Point (MAP) as described in RFC 4140 [3], 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 Access Routers (AR) within which a 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 ARs within a local mobility domain (LMD). Proxy Binding Acknowledgment (PBack) Raman Expires August 27, 2006 [Page 3] Internet-Draft A Protocol for NETLMM February 2006 A standard Mobile IPv6 Binding Acknowledgment (BAck), as described in RFC 3775 [2], message sent by the local mobility anchor (LMA) in response to a PBU message. PMIP Client A Mobile IPv6 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 ARs within a local mobility domain (LMD). PMIP Assistant An optional functional entity located at the Access Router (AR) responsible for receiving Proxy Binding Update (PBU) from the PMIP client and forwarding it to the local mobility anchor (LMA) after some processing. 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 receiving the keys sent by the local AAA server. Mobility Anchor point (MAP) A mobility anchor point as defined in the Hierarchical Mobile IPv6 RFC 4140 [3] 3.0 BRIEF DESCRIPTION OF SOLUTION Our solution is based on the proxy Mobile IP (PMIP) technique where a PMIP client sends the binding update messages to the local mobility anchor (LMA) to establish a mapping between the MN's IP address and the IP address of the current Access Router (AR) through which the MN is reachable. A given LMA has several ARs under it, and these ARs are typically base stations or access points that terminate the layer 2 protocol with the MN. The MN may be Mobile IP capable and can send BU messages for inter- LMD mobility, i.e., global mobility. For local mobility, the ARs within an LMD make the MN believe that it is still within the same Raman Expires August 27, 2006 [Page 4] Internet-Draft A Protocol for NETLMM February 2006 site, and hence prevent the MN from initiating Mobile IP messages. The ARs in an LMD advertise the same prefix (i.e. LMA's prefix) in their neighbor advertisement messages. This draft proposes two solutions, one where the LMA is an IPv6 Home Agent compliant with RFC 3775 [2] and the other where the LMA is an HMIPv6 Mobility Anchor Point (MAP) compliant with RFC 4140 [3]. This allows reuse of existing standard IETF components and avoids additional work of standardizing a new mobility anchor. When a new AR realizes that an MN has made an L2 handoff to its cell, the new AR 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 AR's IP address. The solution proposed in this draft does not envisage the AR to which the MN hands off to be a PMIP client because of the security association that is required between the PMIP client and the HA. The security keys associated with the MN needs to be transferred from one AR to the other as the MN hands off from one cell to another. To avoid this, this draft requires the PMIP client to be fixed for a given MN for the duration that the MN is within that LMD. The PMIP client can either be a separate entity or it can be co- located at one of the ARs. This AR, for example can be the one where the MN first acquired its IP address in the LMD. In either case the security keys involved in the Mobile IP signaling shall be anchored at a single node, either the stand-alone PMIP client or the anchored AR. A stand-alone PMIP client entity achieves separation of the signaling function of generating binding updates (BU) from the data plane function of terminating the local mobility tunnel, while securely handling the keys. The draft proposes two variants for how the PMIP client can send the proxy binding update (PBU) message to the LMA. The PBU can either be sent directly from the PMIP client to the LMA, or it can be encapsulated and sent to the current serving AR, which then decapsulates the packet and sends the binding update message to the LMA. The second alternative is to overcome implementations that follow RFC 3776 [4] and assume that the source address of the binding update should be the same as the address in the "Alternative CoA" field of the BU. For this alternative, the function of decapsulating and forwarding of the PBU message is handled by the "PMIP assistant" function. The sections that follow explain in detail just the case where the LMA is a MIPv6 HA. The case where an HMIPv6 MAP can be used as an LMA is dealt in brief separately in section 5. While most of the procedures explained in section 4 can be used, section 5 proposes few additional considerations that need to be taken care while using an HMIPv6 MAP as an LMA. Raman Expires August 27, 2006 [Page 5] Internet-Draft A Protocol for NETLMM February 2006 4.0 PROTOCOL DETAILS The protocol operates when an MN first connects to an AR or when it moves from one access router AR1 to another access router AR2 connected to a local mobility anchor LMA1 as shown in Figure 1. The MN has acquired an IP address from the GMA called its Home Address (HoA). In addition to this, the MN has acquired one more IP address, called the Care of Address (CoA) associated with the link prefix of LMA. The CoA can be configured by the MN either by a stateful or a stateless autoconfiguration. The protocol enables the MN not to change the CoA when it is moving across ARs under the same LMA. Figure 2 shows the set of procedures involved when the MN first connects to an AR in an LMD. The MN first acquires a CoA in the LMD using the link prefix of LMA. The AR1 then triggers the PMIP client to send a PBU message to the LMA for binding the CoA with the IP address of AR1. The LMA can now tunnel the packets destined to MN's CoA to AR1's IP address. The AR1, in turn, detunnels the packets received from the LMA and forwards them to the MN. These procedures assume that the PMIP client has established the requisite security association with the LMA after suitably acquiring the keys required for such an association. A dynamic way of acquiring these keys is described in section 4.2. In addition, the MN sends a BU message to GMA for binding the MN's HoA with its CoA. The GMA tunnels the packets addressed to the MN's HoA to CoA after sending a BAck message to the MN in response to the BU. The PMIP client can choose to send the PBU through AR1 as shown in Figure 2. In this case, the AR must implement an additional functional entity called "PMIP assistant". The PBU is generated by the PMIP client with Source address and the Alternative CoA fields of the header set to the AR1's IP address. This PBU message is in turn encapsulated, e.g., within a UDP/IP packet, and sent to AR1. The PMIP assistant at AR1 upon reception of the PBU message decapsulates to recover the PBU and sends it to the LMA. In this case the LMA is unaware of the fact that the PBU is generated at the PMIP client. The Proxy Binding Acknowledgment (PBack) message sent by the LMA to AR1 in response to the PBU is in turn forwarded to the PMIP client for verification. The PMIP client sends the PBack verification status to the AR. Raman Expires August 27, 2006 [Page 6] Internet-Draft A Protocol for NETLMM February 2006 +-------+ | GMA | +-------+ / \ / \ / \ / \ / \ / \ +-------+ +-------+ | LMA1 | | LMA2 | +-------+ +-------+ / \ | / \ | +-------+ / \ | | PMIP | / \ | | client| / \ | +-------+ / \ | +-----+ +-----+ +-----+ | AR1 | | AR2 | | AR | +-----+ +-----+ +-----+ +--+ +--+ |MN|------------->|MN| +--+ +--+ Figure 1) Local Mobility Domain with a stand alone PMIP client Alternatively, the PMIP client may choose to send the PBU message directly to the LMA. In this case, while the Alternate CoA field is still set to the AR1's IP address, the source address will be the PMIP client's address. In this case, the LMA is aware that the PBU is sent from a different IP address than the AR's IP address to which the LMA will tunnel packets. This alternative method of sending PBU is compliant with RFC 3775 [2]. In this case, the PBack will be directly sent to PMIP client which in turns communicates the status of the binding update to AR1. Raman Expires August 27, 2006 [Page 7] Internet-Draft A Protocol for NETLMM February 2006 MN AR1 PMIP LMA GMA client | | | | | |CoA acquisition| | | | |<=============>| | | | | | | | | | |---Trigger--->| | | | | | | | | |<-Ecapsulated-| | | | | PBU | | | | | | | | | |-----------PBU-------------->| | | | | | | | |<---------PBack--------------| | | | | | | | |----PBack---->| | | | | | | | | |<---PBack-----| | | | | status | | | | | | | | |--------------------------BU------------------------------>| | | | | | |<------------------------BAck------------------------------| | | | | | | | forward packets | | |<==============|<============================|<============| | | | | | Figure 2) Procedure for MN's initial connection to an AR 4.1 INTRA-LMD MOBILITY When the MN hands off from AR1 to AR2, the PMIP client is triggered to send a PBU. As mentioned before, the PBU can either be sent through AR2 to the LMA or can be directly sent from PBU client to the LMA. The LMA now binds the MN's CoA to AR2's IP address and the packets destined to MN will be tunneled to the AR2's address. Figure 3 shows the set of procedures for an intra-LMD handoff. In addition, the above procedure may be complemented by the use of AR-to-AR communication to facilitate context and data transfer. For example, data transfer can be accomplished using FMIPv6 [7], and context transfer can be performed using Context Transfer Protocol (CXTP) [8]. Such communication can occur without the involvement of the LMA and the MN. 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 Raman Expires August 27, 2006 [Page 8] Internet-Draft A Protocol for NETLMM February 2006 PBU messages. Alternatively, the PMIP client can be co-located at one of the ARs. This AR, 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 AR. During handoffs only the data plane will be migrated to the new AR whereas the PBU message will still be generated at the anchored AR. Also, the security keys associated with the signaling shall not be transferred across ARs during the handoff. MN AR1 AR2 PMIP LMA client | | | | | | | | | | |-----------L2 Handoff-------->| | | | | | | | | | Buffered | | | | |<==packets &=>|----Trigger--->| | | context transfer | | | | | | | | | |<-Encapsulated-| | | | | PBU | | | | | | | | | |------------PBU------------>| | | | | | | | |<----------PBack------------| | | | | | | | |-----PBack---->| | | | | | | | | |<----PBack-----| | | | | status | | | | | | | | | forward packets | | |<=============================|<===========================| | | | | | Figure 3) Intra-LMD handoff procedure 4.2 KEY EXCHANGES FOR SIGNALING Security can be provided for the PBU messages by one of two ways. In the first method, a unique Security Association (SA) is set up for all the addresses that can be configured by the MNs using the LMA's prefix [2]. This method is useful for the case where the PMIP client is centralized and the PBU messages are directly sent by the PMIP client to the LMA. Note that in this case, the LMA is reachable only through a single PMIP client. The Security Policy Database (SPD) at the LMA can be configured such that all possible addresses that can be configured using the LMA's prefix map on to a pre-configured SA Raman Expires August 27, 2006 [Page 9] Internet-Draft A Protocol for NETLMM February 2006 that the LMA has with the PMIP client. Note that this method does not require dynamic bootstrapping of security keys. But it is possible that the LMA can be accessed through different PMIP clients, for example, if the PMIP client is co-located at the AR. Also, as described above, the PBU messages may be sent to the LMA through the ARs. In both these cases, if the PBU messages are sent through ARs, then the above method of securing the PBU messages cannot be used as pre-configuring of SPDs is not possible. For these cases a AAA [6] based mechanism is proposed as explained below. For carrying out this mechanism both the LMA and the PMIP client shall be co-located with a "local AAA client function". The AAA-based scheme can also be used when the PMIP client is a stand-alone entity. The AAA-based scheme creates a separate key for a separate IPSec SA for each MN, even when they use the same PMIP client and LMA [4]. 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 server. The key fetch transaction may be triggered by other events related to the MN's attempting to access the AR, for example a successful authentication of the MN. 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) [9] 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, PMIP client can send the PBU message. If we use the PMIP assistant, the PBUs will have the AR's IP address as the source address. However, the IPSec SA is still between the LMA and the MN's CoA (equating the MN's CoA to a home address as far as the LMA is concerned), as described in RFC 3776 [4], and not with the AR's IP address. The endpoint corresponding to the MN's CoA 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 [5] or DIAMETER [9] can be used. 4.3 ADDRESS CONFIGURATION AND DUPLICATE ADDRESS DETECTION (DAD) After the initial MN authentication and key acquisition for IPSec by the PMIP client, the PMIP client can (assuming that it has the Raman Expires August 27, 2006 [Page 10] Internet-Draft A Protocol for NETLMM February 2006 knowledge of MN's interface identifier) infer the addresses that can be potentially autoconfigured by the MNs. The PMIP client can therefore perform a DAD based on the MN's interface identifier (thereby detecting that some other MN has used the same interface identifier). The DAD can then be followed by IKE procedures and transmission of the PBU message. The PBack message sent in response by the LMA to the PBU message can be used as further confirmation for the DAD. Following this, the PMIP client shall advertise the LMA's link prefix to the MN. If the MN is performing stateless address autoconfiguration, the MN and AR can perform a DAD at this stage. The AR should send a proxy reply as appropriate, based on the DAD performed by the PMIP client. In order to ensure that the MN does not generate traffic for any address other than the one corresponding to the interface identifier that was authenticated, filters can be set at the AR. 4.4 INTER-LMA MOBILITY We assume a general situation where a given AR may be able to have tunnels with multiple LMAs, so that LMA domains need not be non- 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 AR, or even when the mobile remains under the same AR), the presence of the new LMA and its link prefix is advertised to the mobile. 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 SA may need to be established between the appropriate PMIP client and the new LMA for securing PBU messages. Also, for routing efficiency, the MN can change its LMA to the one in the new LMD. Even in this case the PMIP client at the previous LMD can still be used for sending PBUs. Alternatively, a new PMIP client may be selected for the MN in the new LMD. But once the MN has selected a new LMA, in either case, new key shall be fetched from the local AAA server in a manner similar to that when the MN has first connected to an LMA as described in Figure 2. By doing this, no security key transfer across PMIP clients need to be performed. 5.0 USING AN HMIPV6 MAP AS LMA An HMIPv6 Mobility Anchor Point (MAP) [3] can be used as an LMA. For this purpose, the HMIPv6 protocol is modified to implement a proxy agent similar to the PMIP client for sending BUs on behalf of MN to the MAP. The HMIPv6 signaling, and MAP function are re-used without modifications. The MN configures an IP address using the MAP's prefix, called the Regional Care of Address (RCoA) and the PMIP Raman Expires August 27, 2006 [Page 11] Internet-Draft A Protocol for NETLMM February 2006 client configures an IP address for each MN using the AR's link prefix, called the Local Care of Address (LCoA). Note that although MN configures RCoA using MAP prefix, it is not aware of the fact that network controlled HMIPv6 is being used for localized mobility management. The PMIP client sends a local PBU to the MAP for binding the LCoA with the MN's RCoA. In this implementation the AR detunnels the packets destined to MNs camped on to it. Therefore, the HMIPv6 protocol's requirement that the LCoAs need to be configured per MN need not be strictly followed. But instead, a single LCoA can be used for all the MNs under an AR. Whenever an MN moves across ARs within the LMD (which is nothing but the MAP domain) the PMIP client configures an LCoA from the AR's prefix and appropriately updates the tunnel between RCoA and LCoA by sending a PBU to the MAP. Link layer specific mechanisms can be used to detect movement of MN from one AR to another within the LMD. All the ARs within an LMD should advertise MAP's prefix to prevent the MN from configuring a new IP address when it moves across ARs within an LMD. An IPSec SA shall be established between the MAP and the MN's RCoA in the PMIP client. The security procedures involving a local AAA server and a local AAA client function, as explained in section 4.2, can also used for this purpose. The MIPv6 protocol [2] can be used for providing global mobility when the MN moves from one LMD to another. In this case, the MN configures a new RCoA compatible with the new MAP's prefix. The PMIP client as usual configures a new LCoA compatible with the MN's new AR and updates the binding between RCoA and LCoA. The procedure and possibilities mentioned in section 4.4 can also be used in this case. 5.1 MAP DISCOVERY Because the ARs within an LMD have to advertise the MAP's prefix for enabling a localized mobility management, a MAP discovery has to be performed by the ARs for learning the MAP's prefix. The existing procedures for performing this as explained in RFC 4140 [3] can be used. Also, the ARs should suppress the router advertisements containing their own prefix so as to hide the local mobility from MN. This also ensures that an MN initiated binding is performed only for an inter-LMD handoff. The MAP failure discovery mechanism as explained in [3] can be used in this implementation. But here, instead of the MN the PMIP client will be performing the MAP failure discovery. The details will be provided in the next revision of the draft. Raman Expires August 27, 2006 [Page 12] Internet-Draft A Protocol for NETLMM February 2006 6.0 IANA CONSIDERATIONS None. 7.0 SECURITY CONSIDERATIONS To avoid security vulnerabilities, the security keys and the IPSec SA is anchored at a single node, i.e., PMIP client, for handoffs. Even when the PMIP client is at the ARs, there is an anchored AR that holds the MN's security keys, which may be different for different MNs. There is a separate SA for each MN, even though several MNs may use the same LMA and PMIP client. HMIPv6 provides end-to-end security between MN and MAP. But for the case where an HMIPv6 MAP is used as an LMA and a proxy agent is used, such end-to-end security is not possible. Instead, an IPSec SA is established between the PMIP client and MAP using the MN's RCoA. Also, RCoA allocation should guarantee RCoA uniqueness for enabling this SA. 8.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] H. Soliman et al., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005 [4] J. Arkko et al., "Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004 9.0 INFORMATIVE REFERENCES [5] C. Rigney et al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000 [6] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August 2000 [7] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July 2005 [8] J. Loughney et al., "Context Transfer Protocol", RFC 4067, July 2005 [9] D. Harkins et al., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 Raman Expires August 27, 2006 [Page 13] Internet-Draft A Protocol for NETLMM February 2006 [10] P. Calhoun et al., "Diameter Base Protocol", RFC 3588, September 2003 10.0 AUTHORS' ADDRESSES Vijay Raman Motorola India Electronics Limited 66/1, Plot No. 5, Bagmane Tech Park CV Raman Nagar Post Bangalore 560093 India Phone: +91-80-26012308 Email: vijayraman@motorola.com 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 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 Email: Suresh.Kalyanasundaram@motorola.com 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 Raman Expires August 27, 2006 [Page 14] Internet-Draft A Protocol for NETLMM February 2006 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 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 "Copyright (C) The Internet Society (2006). 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 Raman Expires August 27, 2006 [Page 15] Internet-Draft A Protocol for NETLMM February 2006 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 Funding for the RFC Editor function is currently provided by the Internet Society. Raman Expires August 27, 2006 [Page 16]