Internet DRAFT - draft-koodli-idle-mode-ctv6
draft-koodli-idle-mode-ctv6
Seamoby Working Group Rajeev Koodli
INTERNET DRAFT Jari T. Malinen
13 July 2001 Communication Systems Laboratory
Idle Mode Handover Support in IPv6 Networks
draft-koodli-idle-mode-ctv6-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
This document is an individual submission for the mobile-ip Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the seamoby@diameter:org mailing list.
Distribution of this memo is unlimited.
Abstract
This document considers the problem of expediting authenticated network
access as well as enabling authorized context transfer during idle-mode
handovers. In essence, this document addresses idle-mode context
transfers, so that an idle-mode Mobile Node (MN) can resume its sessions
in a seamless fashion. We propose supplying the session key in the
paging message to the Access Router (AR) that locates the idle Mobile
Node. Subsequently, the AR issues a local challenge in the router
advertisement, and the MN replies with a hash of session key, its
previous IP address and the local challenge. The new AR grants network
access once its own hash matches that supplied by the MN. We demonstrate
how this simple procedure can be used for any generic context transfers.
Koodli, Malinen Expires 13 January 2002 [Page i]
Internet Draft Idle Mode Handover Support 13 July 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. Idle Handover Considerations 4
4. Protocol Messages 6
4.1. Key Distribution Extension to the Paging Message . . . . 6
4.2. Context Transfer Extension to the Paging Message . . . . 7
4.3. Router Advertisement with AAAv6 Local Challenge . . . . . 8
4.4. AAAv6 Request for Idle Mode Handover Support . . . . . . 10
4.5. AAAv6 Reply for Idle Mode Handover Support . . . . . . . 12
5. Protocol Constants 14
6. Security Considerations 14
Addresses 15
Koodli, Malinen Expires 13 January 2002 [Page 1]
Internet Draft Idle Mode Handover Support 13 July 2001
1. Introduction
When a MN powers up in a visited domain and obtains link connectivity
with the network, a network policy may require that MN performs network
layer authentication prior to obtaining IP connectivity. This is
critical in order to provide a mechanism for the network provider to
ensure unabused network access. The specification in [1] outlines a
mechanism based on ICMP protocol that could be used in conjunction with
other protocols, such as IPv6 address auto-configuration and Mobile
IPv6, in order to provide this kind of network layer authentication.
Provided the MN is authorized to access the network, this protocol then
enables a security association between a MN and its default Access
Router (AR) and supplies both the entities the necessary security
keys. The MN then uses the supplied key in securing its communication,
whenever necessary, with its AR.
v +------------+
+-+ | Previous |
! ! ----------------- | Access |
+-+ | Router(PAR)|
MN | |
| +------------+
| |
| | IP Paging Message
| |
| V
| ...........................
| . .
| . Paging area multicast .
V . group .
. .
v +------------+ +------------+ +------------+
+-+ | New | | New | | New |
| | -------| Access | | Access | | Access |
+-+ | Router(NAR)| | Router(NAR)| | Router(NAR)|
MN | | | | | |
+------------+ +------------+ +------------+
Figure 1: Reference Scenario for Idle-Mode Handover
Once authorized to use the network prefix advertised by the AR, the MN
may proceed to send IP packets. For instance, the MN may send a Binding
Koodli, Malinen Expires 13 January 2002 [Page 2]
Internet Draft Idle Mode Handover Support 13 July 2001
Update to its Home Agent to inform about its new location. Note that
for performance reasons, it is possible to combine the Binding Update
with network authentication messages, as proposed in [1]. Here, we
assume a logical separation between the two protocols. Nevertheless,
the MN may then engage in active packet transmission and reception, or
it may remain idle. Observe that the MN may establish feature contexts
for its packet streams and then enter idle-mode. For example, the MN
may establish QoS context for its `www' traffic, engage in active data
communication, and then transition to idle state. Furthermore, the MN
may enter idle mode even while engaged in active communication due to
the bursty nature of packet data communication. Subsequently, the MN
undergoes a handover while remaining in idle-mode. See Figure 1
The purpose of this document is to address the problem of expeditiously
authenticating network access (for the MN) as well as authorizing feature
contexts (to the MN) during idle-mode handovers. In essence, this
document addresses idle-mode context transfers, so that an idle-mode
Mobile Node (MN) can resume its sessions in a seamless fashion. We
propose a solution using simple extensions to paging messages that would
allow us to meet our objectives without the need for a dedicated paging
server or additional entries in the routing tables.
2. Terminology
Mobile Node A host that attaches to a network, untethered or
otherwise, and changes its point of attachment
due to host mobility.
Idle mode A state internal to a Mobile Node in which the
MN is not in active packet transmission or
reception. This definition assumes that it is
possible for a MN to enter idle mode, e.g., due
to silence intervals, when it has an active
traffic channel.
Paging A mechanism by which a network locates a MN
in idle mode, in order to, e.g., deliver an
incoming packet [3].
(Access) Authentication The process by which an Access Router
(AR) verifies the MN's credentials and grants
(authorizes) network access [1].
Context Transfer The process by which state information
pertaining to a MN is transferred from one AR
to another, perhaps to facilitate seamless
operation of applications running on the MN [6].
Koodli, Malinen Expires 13 January 2002 [Page 3]
Internet Draft Idle Mode Handover Support 13 July 2001
3. Idle Handover Considerations
We begin with a set of assumptions. First, we assume that each paging
area is uniquely identified by an IP multicast group called ``all access
router's multicast group'', whose members are the ARs that constitute
the paging area. Second, a Mobile Node does not perform paging area
registrations when inside the same paging area. The mechanisms by which
a MN determines that it is within the boundary of the same paging area
are beyond the scope of this document. It may make use of any known
mechanism; for example, it may make use of the paging area identifier
typically advertised on the broadcast channel to determine its location
with respect to the paging area. Third, an AR originates an IP paging
message when it determines that it cannot deliver an IP packet to its
MN. The mechanism by which an AR determines that a MN that was attached
to it is no longer visible is not specified in this document. An
AR may be able to realize this by, for example, explicit idle mode
registrations or (implicitly) via timer expirations. Note that because
of this assumption, we see no reason for a specialized paging server in
our discourse. Note also that there is no need for additional routing
table entries in this model. Finally, we assume that all the members of
the all access routers multicast group share security association with
each other.
We consider the two idle mode scenarios outlined earlier. We start
with the case where the MN moves without having initiated active data
communication.
Recall that the MN first establishes network connectivity. This means,
at the very least, the state corresponding to security association
should be present at both the MN and its default AR. Now, let us assume
that the MN moves to a subnet controlled by a different AR, yet within
the same paging area. As mentioned earlier, we assume that the MN does
not send a paging area registration message if operating within the
same paging area. This assumption is necessary since a paging area
registration may entitle the MN to IP connectivity, in which case, the
routing of IP packets follows normal Mobile IP procedures. Now, if a
packet arrives at the previous AR for the MN, the previous AR has to
locate the MN in order to deliver the packet. We assume that an IP
paging message would be available for this purpose. Whereas the exact
form and nature of such a message is not standardized yet, we will
assume the message outlined in [9], and identify extensions needed.
In [9], the PAR uses a well-known multicast address, the ``all access
routers multicast group'', to send the paging request, which we call
the ``IP paging message''. All the ARs within the paging area are
members of this multicast group, and thus receive the paging request
packet. Each AR then sends an unsolicited router advertisement that
contains the MN's IP address established while connected to PAR. This
message may trigger Layer 2 (L2) paging, when present, on each AR in
Koodli, Malinen Expires 13 January 2002 [Page 4]
Internet Draft Idle Mode Handover Support 13 July 2001
order to wake up the sleeping MN. The MN, once paged, has to determine
that it has changed its AR by verifying the source address in the router
advertisement, begin to formulate a new IP address, and then respond to
the IP paging request.
When the MN wakes up and realizes that it has changed its AR, it may be
required to perform network access authentication described earlier.
This procedure is time-consuming given the delays in accessing the MN's
home network AAA and the Home Agent. In order to minimize this delay,
we propose to transfer the key from PAR to all the potential access
routers which are members of the ``all access routers multicast group''
in the IP paging message. We assume that the MN first established
authenticated network access with PAR.
In the unsolicited router advertisement message that follows the IP
paging message, each AR sends and caches a random number in a local
challenge requiring the MN to return a token that is a hash of network
prefix advertised, the random number in the local challenge and the key
that the MN possesses. Each AR uses the key supplied in the IP paging
message to compute its own hash and allows network access if the token
supplied by the MN matches its computation. The MN uses the Embedded
Data Option in the AAAv6 Request message in [1] to include this token
as well as other information, such as the Binding Update message. When
the AR receives the AAAv6 Request, it determines that the AAAv6 Request
message corresponds to the unsolicited router advertisement (sent in
response to the paging message) by inspecting the Embedded Data Option
containing the above-mentioned hash.
The above key transfer concept can indeed be applied to handle generic
feature contexts. The MN's contexts at PAR are transferred gratuitously
to all the ARs in the paging area multicast group. When the network
policy requires explicit authorization of these contexts, each AR
mandates that the MN presents a separate access authentication token
such that the AR can verify authenticity of the feature context request.
This token is generated according to HMAC-MD5-96 [7] using the random
number advertised in the Local Challenge as an input parameter. The
details of this token computation are specified in the description of
Seamless Handover Initiate (SHIN) option [5].
We propose using the SHIN option as an embedded data in the AAAv6
request for explicit authorization of the feature context requests.
The new AR verifies that the token present in the SHIN matches its
own computation and makes the contexts available to the MN. It then
generates a SHREQ message to the PAR that originated the IP paging
message in order to set up a forwarding path for packets arriving at
PAR. The PAR SHOULD generate a SHREP message indicating the response
for the SHREQ message. The new AR MAY send a SHAK message indicating
authorization of contexts to the MN. The MN SHOULD be prepared to handle
packets treated with feature contexts without expecting a SHAK message.
Koodli, Malinen Expires 13 January 2002 [Page 5]
Internet Draft Idle Mode Handover Support 13 July 2001
Note that context transfer could happen reactively following paging.
That is, the AR that locates the MN would initiate the transfer of
contexts from the PAR in response to successfully authenticating the MN
and (optionally) processing the SHIN option. In such a scenario, only
the session key is transferred from the PAR to the members of the paging
area. The net effect is that fewer bytes are sent in the access network
since context transfer only happens between the AR that locates the MN
and the PAR.
4. Protocol Messages
In this section, we describe new protocol messages or options used
in the protocol extensions described earlier. When paging occurs, a
session key is passed along with the paging message. A paging message
triggers a router advertisement which is required to contain a Local
Challenge (LC) as in AAAv6. The router advertisement invokes the mobile
node to perform a localized AAAv6 request and reply exchange with the
AR.
4.1. Key Distribution Extension to the Paging Message
We assume that a paging entity sends a paging message containing the
IP address of the MN to a multicast group specific for the paging
area. A paging message can be, e.g., a Paging Request Message as
specified in [9]. Since the exact form of a Paging Message has not been
standardized yet, we define a generic session key option which is shown
in Figure 2. This option can be carried (with suitable padding whenever
necessary) in an appropriate paging message. The receiving AR extracts
the session key from this option, where the key is encrypted using
pre-existing shared key between the originator of the paging message and
the receiving access router.
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 | Alg | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Session Key Option
Koodli, Malinen Expires 13 January 2002 [Page 6]
Internet Draft Idle Mode Handover Support 13 July 2001
Type TBD (skippable), one for key request, one for key reply
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8
octets.
Alg 8-bit algorithm indication as specified for the
Authentication Header [4].
Key Length
8-bit unsigned integer. The length of the key in
units of 4 octets.
SPI 32-bit Security Parameter Index value.
Key Encrypted key.
4.2. Context Transfer Extension to the Paging Message
A paging entity may use this option to gratuitously supply the contexts
established at PAR to all the members of the paging area. Such an
action could provide performance benefits, since data communication
typically follows paging. The option is shown in Figure 3.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ One or more feature contexts +
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Context Transfer Option
Koodli, Malinen Expires 13 January 2002 [Page 7]
Internet Draft Idle Mode Handover Support 13 July 2001
Type (skippable) Gratuitous Context Transfer.
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8
octets.
As with the Session Key option, this option is also carried in an
appropriate paging message. The AR that locates the MN then authorizes
the use of received contexts after successfully processing the SHIN
option from the MN.
4.3. Router Advertisement with AAAv6 Local Challenge
The paging message is received by access routers in the paging area. A
subsequent router advertisement message, described in this section, is
sent out by each Access Router. The router advertisement as specified
by Neighbor Discovery [8] is modified to include the local challenge as
specified in [1]. The AR uses the value in local challenge in computing
the access authentication token.
The extension appears as a Router Advertisement option shown in 4.
Koodli, Malinen Expires 13 January 2002 [Page 8]
Internet Draft Idle Mode Handover Support 13 July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| Router Advertisement Options |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Length | Sequence no | Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Router Advertisement with AAAv6 local challenge
{1} Router Advertisement Options
A paging option contains the IP address of the paged MN. It is possible
to send a page to a group of dormant mobiles by associating a multicast
address with that group. In such a case, this option includes the IP
addresses of all the paged mobiles. May also include target Link-layer
address, Prefix Information Options, etc.
{2} AAAv6 Challenge Option in the router advertisement
Type
9 = ICMPv6 Router Advertisement Local Challenge Option
Length
1 = Length in 8 octets including the type and length fields
Sequence Number
a monotonically increasing integer that associates the IP
address, Challenge and the Key tuple. The MN supplies this
value in addition to the hash it generates to aid the AR in
verifying the checksum computation.
Reserved
0 = Ignored on reception
Challenge
This is a 32-bit random number generated by the access router
and used to prevent replay attacks.
Koodli, Malinen Expires 13 January 2002 [Page 9]
Internet Draft Idle Mode Handover Support 13 July 2001
4.4. AAAv6 Request for Idle Mode Handover Support
This section describes the message the mobile node sends in response to
the paging router advertisement which contains an AAAv6 local challenge.
This response includes a token to facilitate expedited network access
authentication and also request for context transfer authorization.
The message the MN sends is an ICMPv6 message of AAAv6 request
type. This AAAv6 message contains one or more Embedded Data Options.
Each Embedded Data Option (EDO) may contain sub types for various
purposes. The two new sub types used by this extension are the access
authentication token and Seamless Handover Initiate (SHIN). The SHIN
subtype is optional if the network policy allows context authorization
based only on network access authentication.
The access authentication token contains a hash over mobile node's
previous IP address and the challenge sent in the router advertisement.
Since the paging message from the paging router to the access routers
distributes the key known to the MN and the paging router, this key is
now known by the new router which can verify whether the hash received
is valid. If not, the packet is dropped and a diagnostics AAAv6 reply
with status AAAV6_INVALID_CREDENTIALS in the Code field is returned.
Koodli, Malinen Expires 13 January 2002 [Page 10]
Internet Draft Idle Mode Handover Support 13 July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (AAAv6 Request Options) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO |Subtype=AAToken| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Network Access Authentication Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type=EDO |Subtype=SHIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SHIN (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AAAv6 request for Idle Mode Handover Support
{1} IPv6 Header
SRC = MN's new IP address; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [2]
Type
151 (97h) [TBD] = AAAv6 Request
Code
0 - For AAA request, not defined
Checksum
Calculated as defined in [2].
Koodli, Malinen Expires 13 January 2002 [Page 11]
Internet Draft Idle Mode Handover Support 13 July 2001
{3} AAAv6 Embedded Data Option [1] for access authentication
Type
8 (unskippable) = Embedded Data Option
Subtype
5 = AAToken
Length
4 = Length of Network Access Authentication Hash in octets.
Network Access Authentication Hash
A 16-byte result of a pseudo-random function, such as
HMAC-MD5-96, computed over the identity-providing old CoA,
freshness-providing random number (LC), and the session key.
{4} AAAv6 Embedded Data Option [1] for SHIN
Type
8 (unskippable) = Embedded Data Option
Subtype
6 = SHIN
Length
4 = Length of SHIN in octets.
SHIN
Seamless Handover Initiate message.
4.5. AAAv6 Reply for Idle Mode Handover Support
In this section, we provide the extended AAAv6 reply to the AAAv6
request for idle mode context transfer support. Note that the request
for context transfer was embedded to an EDO containing the SHIN message.
Here a similar new and optional EDO contains the optional SHAK.
{1} IPv6 Header
Koodli, Malinen Expires 13 January 2002 [Page 12]
Internet Draft Idle Mode Handover Support 13 July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (AAAv6 Reply Options) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO |Subtype=SHAK | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SHAK (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AAAv6 reply for Idle Mode Handover Support
SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [2]
Type
[TBD] = AAAv6 Reply
Code
The success code for AAAv6 Reply.
Checksum
Calculated as defined in [2].
{3} AAAv6 Embedded Data Option [1] for SHAK
Type
8 (unskippable) = Embedded Data Option
Koodli, Malinen Expires 13 January 2002 [Page 13]
Internet Draft Idle Mode Handover Support 13 July 2001
Subtype
7 = SHAK
Length
Length of SHAK in octets.
SHAK
Seamless Handover Acknowledgment.
5. Protocol Constants
Three new sub-types for AAAv6 Embedded Data Option are needed, one
for access authentication token, and one for SHIN, and SHAK options,
respectively.
6. Security Considerations
This protocol assumes that when the mobile node arrives at a visited
domain, it performs a secure initial registration, after which there
is a mobile-visited domain session key in both the mobile node and the
first visited-domain router. Also, there is a pre-existing common
security association between all nodes in a paging area multicast group.
Using the assumed associations, the paging causes the session key to
be provided to the new access router which can use it to verify both
authenticity of the received AAAv6 request as well as the authorization
token present in the SHIN message. These mechanisms used together with
AAAv6 provide authorized idle mode context transfers.
Koodli, Malinen Expires 13 January 2002 [Page 14]
Internet Draft Idle Mode Handover Support 13 July 2001
References
[1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for
IPv6 Network Access (work in progress). Internet Draft, Internet
Engineering Task Force, March 2000.
[2] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet protocol version 6 (ipv6)
specification. Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[3] J. Kempf. Dormant mode host alerting (ip paging) problem
statement. Request for Comments (Informational) 3132, Internet
Engineering Task Force, June 2001.
[4] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[5] R. Koodli, , and C. Perkins. A context transfer framework for
seamless mobility (work in progress). Internet Draft, Internet
Engineering Task Force, July 2000.
[6] et al. Levkowetz, O. H. Problem description: Reasons for
performing context transfers between nodes in an ip access
network (work in progress). Internet Draft, Internet Engineering
Task Force, June 2001.
[7] C. Madson and R. Glenn. The Use of HMAC-MD5-96 within ESP and
AH. Request for Comments (Proposed Standard) 2403, Internet
Engineering Task Force, November 1998.
[8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (ipv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[9] B. Sarikaya, J. Haverinen, H.and Malinen, and V. Magret. Mobile
ipv6 regional paging (work in progress). Internet Draft,
Internet Engineering Task Force, November 2000.
Addresses
Questions about this memo can also be directed to the authors:
Koodli, Malinen Expires 13 January 2002 [Page 15]
Internet Draft Idle Mode Handover Support 13 July 2001
Rajeev Koodli Jari T. Malinen
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2359 Phone: +1-650 625-2355
EMail: rajeev.koodli@nokia.com EMail: jmalinen@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Koodli, Malinen Expires 13 January 2002 [Page 16]
