One document matched: draft-singh-netlmm-protocol-00.txt
IETF NETLMM Working Group Anand Bedekar
Internet Draft Ajoy Singh
Suresh Kalyanasundaram
Motorola
draft-singh-netlmm-protocol-00.txt
Expires: June 05, 2007 December 05,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.
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.
Singh, et. al. Expires June 6, 2007 [Page 1]
Internet-Draft A Protocol for NETLMM December 05, 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..........................................12
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 within a 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
Singh, et. al. Expires June 06,2007 [Page 2]
Internet-Draft A Protocol for NETLMM December 05, 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). Local binding
update message as described in RFC 4140 [3] can be used when
HMIPv6 MAP is used as LMA.
Singh, et. al. Expires June 06,2007 [Page 3]
Internet-Draft A Protocol for NETLMM December 05, 2006
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. Local binding ack message as described
in RFC 4140 [3] can be used when HMIPv6 MAP is used as LMA.
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 agent (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
The proposed 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 may or may not be co-located with base stations or
access points that terminate the layer 2 protocol with the MN.
Singh, et. al. Expires June 06,2007 [Page 4]
Internet-Draft A Protocol for NETLMM December 05, 2006
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
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 router advertisement messages. The figure 1 describes a local
mobility domain with standalone PMIP client.
+-------+
| GMA |
+-------+
/ \
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+
| LMA1 | | LMA2 |
+-------+ +-------+
/ \ |
/ \ |
+-------+ / \ |
| PMIP | / \ |
| client| / \ |
+-------+ / \ |
+-----+ +-----+ +-----+
| AR1 | | AR2 | | AR |
+-----+ +-----+ +-----+
+--+ +--+
|MN|------------->|MN|
+--+ +--+
Figure 1) Local Mobility Domain with a stand alone PMIP client
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 experimental 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 a cell that
it serves, 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.
Singh, et. al. Expires June 06,2007 [Page 5]
Internet-Draft A Protocol for NETLMM December 05, 2006
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 LMA.
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 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.
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 above 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 auto-configuration. 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
Singh, et. al. Expires June 06,2007 [Page 6]
Internet-Draft A Protocol for NETLMM December 05, 2006
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.
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
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 de-
capsulates 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
Singh, et. al. Expires June 06,2007 [Page 7]
Internet-Draft A Protocol for NETLMM December 05, 2006
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.
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.
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
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.
Singh, et. al. Expires June 06,2007 [Page 8]
Internet-Draft A Protocol for NETLMM December 05, 2006
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
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
Singh, et. al. Expires June 06,2007 [Page 9]
Internet-Draft A Protocol for NETLMM December 05, 2006
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
knowledge of MN's interface identifier) infer the addresses that can
be potentially auto-configured 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.
Singh, et. al. Expires June 06,2007 [Page 10]
Internet-Draft A Protocol for NETLMM December 05, 2006
Following this, the PMIP client shall provide a suitable link prefix
to the AR, which will then send a router advertisement containing the
link prefix to the MN. In addition, the PMIP client should also send
to the AR the outcome of the DAD that it has performed internally. If
the MN is performing stateless address auto-configuration, 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. Such
as 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 SA may need to be established between
the appropriate PMIP client and the new LMA for securing PBU
messages.
In any case, once a new LMA has been selected, 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. Moreover, it will also be necessary to advertise an
appropriate new link prefix to the MN through a router
advertisement. Here we are assuming that access router will learn
LMA prefix during AAA interaction and advertise new prefix to mobile
node to trigger global mobility.
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
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.
Singh, et. al. Expires June 06,2007 [Page 11]
Internet-Draft A Protocol for NETLMM December 05, 2006
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.
6.0 IANA CONSIDERATIONS
None.
Singh, et. al. Expires June 06,2007 [Page 12]
Internet-Draft A Protocol for NETLMM December 05, 2006
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
[10] P. Calhoun et al., "Diameter Base Protocol", RFC 3588, September
2003
Singh, et. al. Expires June 06,2007 [Page 13]
Internet-Draft A Protocol for NETLMM December 05, 2006
10.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
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
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
Singh, et. al. Expires June 06,2007 [Page 14]
Internet-Draft A Protocol for NETLMM December 05, 2006
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
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."
Singh, et. al. Expires June 06,2007 [Page 15]
Internet-Draft A Protocol for NETLMM December 05, 2006
Acknowledgment
We would like to thank Vijay Raman for editing first version of this
draft. We would like to thank Petrescu Alexandru for valuable
feedback.
Singh, et. al. Expires June 06,2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 11:00:17 |