[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                           Pekka P„„kk÷nen
Document:draft-paakkonen-nemo-prefix-delegation-00.txt Juhani Latvakoski
Expires: September 2003

                                                              March 2003


            Mobile Network Prefix Delegation extension for Mobile IPv6
                  draft-paakkonen-nemo-prefix-delegation-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 Internet Society (2003). All Rights Reserved.

Abstract

This draft proposes a dynamic Mobile Network Prefix (MNP) delegation
extension for Mobile IPv6 protocol to enable MNP delegation for
mobile networks. A MNP is an IPv6 prefix used in a mobile network.
The extension supports dynamic delegation, return, refreshing and
updating operations related to MNP delegation operations between a
Mobile Router (MR) of a mobile network and the MR's Home Agent (HA).
This extension is proposed, because there is a lack for a dynamic MNP
delegation protocol related to mobile networks, and currently MNPs have
to be assigned statically to enable mobile networking.











P„„kk÷nen et al.         Expires September 2003                 [Page i]


INTERNET-DRAFT           MNP Delegation                       March 2003

Table of contents

Abstract                                                               i

1. Introduction                                                        i

2. Terms                                                               1

3. Terminology                                                         1

4. Overview                                                            1
    4.1. MIPv6 extension overview..................................... 2

5. Protocol .......................................................... 3
    5.1. Operational environment ..................................... 3
    5.2. Messages .................................................... 3
        5.2.1 MNP Delegation Message ................................. 4
    5.3. Options ..................................................... 6
        5.3.1. MNP Option ............................................ 6
        5.3.2. MNP Data Option ....................................... 7
    5.4. Operation ................................................... 8
        5.4.1. MNP Query sequence .................................... 8
        5.4.2. MNP Delegation sequence .............................. 11
        5.4.3. MNP Refresh sequence ................................. 12
        5.4.4. MNP Return sequence .................................. 13
        5.4.5. MNP Update sequence .................................. 15
    5.5. Examples ................................................... 17
        5.5.1. MNP Query sequence ................................... 17
        5.5.2. MNP Delegation sequence .............................. 19
        5.5.3. MNP Update sequence .................................. 21

6. Constants                                                          23

7. Security issues                                                    23

Acknowledgements                                                      23

References                                                            23

Author's addresses                                                    24

Full Copyright Statement                                              25

1. Introduction

This document describes how one or more Mobile Network Prefixes (MNP)
can be delegated to a mobile network with extensions to Mobile IPv6 [2]
protocol. MNP is an IPv6 prefix used in a mobile network. By using the
extensions proposed in this document it is possible to dynamically
delegate MNPs for a mobile network. MNP Delegation is executed between a
Mobile Router (MR) of a mobile network and its Home Agent (HA). MR
acquires, refreshes and returns MNPs from its HA according to its needs.
HA controls the delegation of MNPs to MRs. HA can also inform about new

P„„kk÷nen et al.         Expires September 2003                 [Page 1]


INTERNET-DRAFT           MNP Delegation                       March 2003

valid and preferred lifetimes regarding the delegated MNPs. The
extension described in this document is needed, because there is no
mechanism for dynamic delegation of MNPs to mobile networks, but instead
MNPs have to be assigned statically to mobile networks.

2. Terms

The terminology used in this document is defined in an other Internet
draft [3]. In addition to this, some new terms are defined.

MNP Requestor = MR which delegates MNPs from its HAs.

MNP Delegator = HA which delegates MNPs to a MR.

MNP Delegation = The delegation of a MNP from a HA to a MR.

MNP Refreshing = MNP delegation lease extension initiated by the MR.

MNP Returning = Returning of a MNP from MR to its HA after the initial
MNP delegation of the MNP. This operation is executed when the MR no
longer needs the delegated MNP, and returns it back to the HA which
originally delegated the MNP.

MNP Updating = The delegated MNP might change for example because
of renumbering operations at the HA. This function is used to inform
MR of valid and preferred lifetime changes regarding the leased MNP.

Transaction identifier = An identifier used to match a request message
to a response. This kind of message exchange forms a transaction between
communicating parties.

3. Terminology

The keywords "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].

4. Overview

The environment for this solution is defined in the NEMO working
group (WG) [4]. The NEMO WG is developing a solution for a mobile
network, which is based on one or more MRs connecting a mobile network
to the Internet. The basic approach is to use Mobile IPv6 and
bidirectional tunneling between the MR and its HA to enable transparent
session mobility for the Mobile Nodes (MN) of the mobile network. The
MNP is an IPv6 prefix of arbitrary length, which identifies an entire
mobile network within the Internet topology [3]. This document focuses
on the dynamic MNP delegation for a NEMO-network. Dynamic MNP assignment
for a NEMO-network using MIPv6 is desirable for the following reasons:

1. Static MNP assignment for a mobile network is laborious

- If a MNP will be statically allocated for each mobile network, it

P„„kk÷nen et al.         Expires September 2003                 [Page 2]


INTERNET-DRAFT           MNP Delegation                       March 2003

demands a great deal of management and configuration work related to
MNPs. There might be millions of mobile networks in the future and
manual allocation of a MNP for each mobile network is laborious.

2. A mobile network may need a MNP in an ad-hoc way

- MNP allocation might be managed using Router Renumbering for IPv6 [5].
But the mobile network could be formed in an ad-hoc way in which case
the MR initially does not have a MNP and requests for it dynamically. In
this case [5] is insufficient and a dynamic protocol for MNP delegation
is needed. This requirement assumes that there is a need for dynamic
mobile network formation.

3. Lifetime of the mobile network is not necessarily infinite

- Use cases of such situations are expected to occur in Personal Area
Networks (PAN), which require mobile networking capabilities only for a
short time. Addressing resources are wasted, if the delegated MNP of
the mobile network is not used. The MNP should be possible to be
returned dynamically to the MNP delegator, after it is no longer used.

4. HA of the MR needs to know the MNP used in the mobile network

- According to the solution defined in [6], HA needs to know the MNP
used in the mobile network in the "static" MR scenario, in which a
routing table entry must exist in the HA of the MR. [11] defines a
solution for mobile networks, which requires a binding cache entry in
the HA, binding the MNP used on the ingress interface of the mobile
network to the COA used on the egress interface. Because information of
the MNP used in the mobile network is needed in MR's HA, it is suggested
that dynamic MNP delegation operations are executed between the MR and
its HA. Because in that case MNP delegation messages are needed between
the MR and its HA, it is suggested that dynamic MNP delegation
functionalities are implemented as a MIPv6 extension.

4.1 MIPv6 extension overview

The defined extension borrows from the Automatic IPv6 Prefix Delegation
Protocol [7] and from IPv6 Prefix Options for DHCPv6 [8] drafts. Some
of the features in those documents are embedded to the MIPv6 extension
protocol defined in this document. MR of a mobile network acts as a MNP
requestor and HA as a MNP delegator. One new ICMPv6 message and new
options inside of it (MNP Delegation-Message) are defined to be used in
the extension. New ICMPv6 codes for MNP delegation related signalling
are also defined. This means that the MR can dynamically request,
return and refresh a MNP from its HA. Also MNP lifetime updates from
the HA to the MR are supported. HA allocates the MNP(s) to the MR for a
certain period of time. The MNP can be delegated to the MR either
temporarily or permanently. In figure 1 an example can be seen of the
extension's usage. In the example MR is at a foreign domain and MR
acquires a MNP and sends a MNP Delegation-Message to its HA. HA
allocates a MNP for the MR and sends back a MNP Delegation response and
the delegated MNP. MR receives the MNP and starts advertising it on its

P„„kk÷nen et al.         Expires September 2003                 [Page 3]


INTERNET-DRAFT           MNP Delegation                       March 2003

local links using Router Advertisements. MR can delegate MNPs also when
it is at home. More examples of the protocol usage have been
demonstrated in chapter 5.5.

       _________
      (Internet )------------Home network--HA
       (_______)                      /
          | 2. code: 'MNP Delegated' /  /\ 1. code: 'MNP Request'
          |                         /   /
    Foreign network                /   /
          |                       \/  /
        ( MR )-----------------------/
        ( |  )
        ( |  ) 3. Router Advertisement (MNP)
        ( |  )
        ( MN )
         ----

Figure 1. MNP delegation for a MR in a foreign network.

5. Protocol

In this chapter the MIPv6 protocol extension for dynamic MNP
delegation is defined.

5.1 Operational environment

There are two entities participating in the protocol as can be seen in
figure 2. MNP delegator is MR's home agent, which can delegate MNP(s)
for the MR. MR is a MNP requestor, and requests MNP(s) from its HA. MR
can have multiple HAs i.e. MNP delegators.

 __________
( Internet )------Home network--HA
 (________)                   (MNP delegator)
 |
 |
 |
MR
(MNP requestor)

Figure 2. Protocol entities.

5.2 Messages

There is one new ICMPv6 message defined for the MIPv6 protocol. MNP
Delegation-Message is used by the MR to query and request HA for MNP(s),
return MNP(s) and refresh the lease of MNP(s). MNP Delegation-Message
can also be used by HA to signal MR of updating operations regarding
the leased MNP(s). The same message type is used as a response to these
operations. Different type of operations and responses are distinquished
by the different ICMPv6 code types.


P„„kk÷nen et al.         Expires September 2003                 [Page 4]


INTERNET-DRAFT           MNP Delegation                       March 2003

5.2.1 MNP Delegation-Message

MNP Delegation-Message is used by MR to query, request, refresh and
return MNP(s). It is also used by the HA to inform MR of updating
operations.

Message format:

  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      |     Code      |          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Transaction Identifier        | Reserved                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |              Message Body                                     |


IP fields

    Source Address

      Source IPv6 address of MR or its HA

    Destination Address

      Destination address of MR or its HA.

    Hop Limit

      Set to an initial hop limit value, similarly to any other unicast
    packet sent by a mobile node.

    Routing Header:

      A routing header of type 2 MUST be added to the message if HA is
    sending a MNP Delegation-Message to the MR and MR is not at home i.e
    has a binding in the HA's binding cache. Otherwise a routing header
    of type 2 MUST not be used.

    AH or ESP header:

      IP security is not discussed in this version of the draft.

    ICMP fields:

    Type:

      xxx for MNP Delegation-Message <To be assigned by IANA>

    Code:


P„„kk÷nen et al.         Expires September 2003                 [Page 5]


INTERNET-DRAFT           MNP Delegation                       March 2003

      MNP Delegator Query (0)

        The MNP Delegator Query message is used by the MR to query MNP
      delegators (HAs) and their abilities to delegate MNP(s). This
      message is sent to MR's HA during the MNP Query sequence.

      MNP Request (1)

        The MNP Request message is used by the MR to request for MNP(s)
      from its HA(s). This message is sent during the MNP Delegation
      sequence.

      MNP Refresh (2)

        The MNP Refresh message is used by the MR to request a refresh
      on the lifetimes of delegated MNP(s). This message is sent during
      the MNP Refresh sequence.

      MNP Return (3)

        The MNP Return message is used by the MR to return delegated
      MNP(s) to its HA. This message is sent during the MNP Return
      sequence.

      MNP Delegator (4)

        A MNP Delegator message is sent by the HA during MNP Query
      sequence. It is used to inform MR of MNP(s) HA is capable of
      delegating.

      MNP Delegated (5)

        A MNP Delegated message is used by HA during MNP Delegation and
      MNP Refresh sequence. It is used to inform MR of delegated and
      refreshed MNP(s).

      MNP Returned (6)

        A MNP Returned message is sent by HA during MNP Return sequence.
      It is used to inform MR of returned MNP(s).

      MNP Unavailable (7)

        A MNP Unavailable message is used in all the sequences to inform
      of non-valid MNP(s) operations.

      MNP Update (8)

        A MNP Update message is used by HA to inform MR of lifetime
      changes concerning the delegated MNP(s).

      MNP Update-Ack (9)


P„„kk÷nen et al.         Expires September 2003                 [Page 6]


INTERNET-DRAFT           MNP Delegation                       March 2003

        A MNP Update-Ack is used by MR to responde to MNP Update
      messages sent by its HA.

    Checksum

      The ICMP Checksum as defined in [9].

    Transaction identifier

      An unique identifier used to match a MNP Delegation-Message
    request to a corresponding MNP Delegation-Message response.

    Reserved

      This field is unused. It MUST be initialized to zero by the sender
    and MUST be ignored by the receiver.

    Options:

      Destination Option:

        A Home Address destination option MUST be included if MR sends a
      MNP Delegation-Message and is away from home.

      MNP Option:

        MUST contain one MNP Option. The MNP requestor and MNP Delegator
      can describe the MNP(s) by adding a MNP Option to the MNP
      Delegation-Message.

5.3 Options

In this chapter the new options, which are used in the new ICMP
message, are defined.

5.3.1 MNP Option

This option is used in MNP Delegation-Message. It is used to contain
MNP information in one or more MNP Data Options.

Option format:

  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      |     Option length             | Option body
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |


  Type:

    0x01

P„„kk÷nen et al.         Expires September 2003                 [Page 7]


INTERNET-DRAFT           MNP Delegation                       March 2003

  Option length:

    Length of option body.

  Option body:

    Message body can contain up to x MNP Data Options. However it
  is recommended that the IPv6 packet size is smaller the MTU for
  IPv6 (1280 octets) [10] which limits the number of MNP Data
  Options used in a MNP Option.

5.3.2 MNP Data Option

  MNP Data Option holds MNP information related to a single MNP.

Option format:

  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      |     Preferred lifetime                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     Valid lifetime                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               | Prefix length | IPv6 prefix (16 octets)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                                               |
 |                                                               |
 |                                                               |
 |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |     Match     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type:

    0x02

  Preferred lifetime:

    The recommended lifetime for the MNP in the option expressed in
  seconds. A value of 0xffffffff represents infinity.

  Valid lifetime:

    The valid lifetime for the MNP in the option expressed in
  seconds. A value of 0xffffffff represents infinity.

  Prefix length:

    Length for this MNP in bits.




P„„kk÷nen et al.         Expires September 2003                 [Page 8]


INTERNET-DRAFT           MNP Delegation                       March 2003

  IPv6 prefix:

    A MNP.

  Match:

    This field is used to indicate MNP preference of the MR during MNP
  Query and MNP Delegation sequences.

  Defined values:

    0, indicates that MNP query/delegation is based on both MNP and its
    length indicated by the values in Prefix length and IPv6 prefix
    fields in the MNP Data Option.

    1, indicates that MNP query/delegation is based only on MNP length
    indicated by the value in Prefix length field in the MNP Data
    Option.

5.4 Operation

In this chapter operation of the protocol is described.

5.4.1 MNP Query sequence

The MNP Query sequence consists of a transaction between the MR and
its HA. A transaction consists of a MNP Delegation-Message and MNP
Delegation-Message response exchange with the same transaction
identifiers. The sequence is initiated by the MR to query its HA's
capabilities to delegate MNP(s) to the MR. This sequence can be
performed multiple times with one or more HAs. After the MR has queried
the capabilities of its HAs with this sequence, MR should advance to
MNP Delegation sequence with the chosen HA to proceed with MNP
delegation.

  MR functionality:

The MR might initially know the addresses of one or more of its HAs.
If the MR is at home, it learns the HA's address by receiving Router
Advertisements from its HA. If MR is away from home and does not know
any HA addresses, it SHOULD initiate Dynamic Home Agent Discovery as
defined in section 11.4.1 of [2]. After MR knows the addresses of one
or more HAs, the MNP Query sequence can be executed.

The MNP Query sequence consists of a transaction between the MR and
its HA. Transactions are initiated by the MR to query the capabilities
of MR's HA to delegate MNPs. A transaction consists of a MNP
Delegation-Message sent by the MR to its HA and a MNP Delegation-Message
response sent back to the MR by the HA. MR initiates the transaction by
sending a MNP Delegation-Message with code 'MNP Delegator Query' to one
of its HAs. The MNP Delegation-Message is constructed by the MR always
independently of its ICMPv6 code as follows:


P„„kk÷nen et al.         Expires September 2003                 [Page 9]


INTERNET-DRAFT           MNP Delegation                       March 2003

  - IP source address field: The source address SHOULD be set to its
    current Care-Of-Address if MR is away from home. If MR is at home,
    its home address MUST be used.
  - IP destination address field: Destination address MUST be set to HA
    address. If MR is away from home, the HA to which MR has a binding
    update list entry MUST be used. Otherwise the stored HA address
    SHOULD be used.
  - Home address destination option: MR's home address MUST be included
    in a Home Address destination option, if MR is not at home.
  - Transaction identifier: The Transaction identifier SHOULD be chosen
    randomly to identify this transaction uniquely.
  - MNP Option: A MNP Option MUST be set in the message to describe the
    MNP(s) MR is interested in. One MNP Data Option inside the MNP
    Option describes one MNP for delegation. The valid and preferred
    lifetimes MAY be set to indicate MR's preference for MNP(s). Match
    field MUST be set as described in section 5.3.2.
  - Binding update list: If MR is away from home it MUST have a binding
    entry in the binding cache at its HA, with which it is
    communicating. This means that the HA's address MUST be present in
    the binding update list of the MR.

In this case the code of the MNP Delegation-Message MUST be set to
'MNP Delegator Query'. If the MR doesn't receive a MNP
Delegation-Message response back within MNP_REQUEST_DELAY milliseconds,
the previously sent MNP Delegation-Message SHOULD be sent up to
MNP_REQUEST_MAX_RETRIES times to the same HA. When MR receives a MNP
Delegation-Message within MNP_REQUEST_DELAY milliseconds, it SHOULD
check it as follows independently of its ICMPv6 code:

  - ICMPv6 type: Check that the ICMPv6 type of the received message is
    MNP Delegation-Message.
  - IP destination address field: If MR is at home, check that the
    destination address in the IP header field is MR's home address. If
    MR is not at home, check that the destination address is MR's COA.
  - IP source address field: Check that the IP source address field of
    the message is the same as the destination address in the
    corresponding MNP Delegation-Message with the same transaction
    identifier.
  - Routing header type 2: If MR is not at home, the packet MUST have a
    type 2 routing header with MR's home address and destination
    IP header field has MR's COA.
  - MNP Option: Check that a MNP Option with one or more MNP Data
    Options is present in the message.

If these conditions are not met, MR MUST silently ignore the message. If
the code of the MNP Delegation-Message response is 'MNP Delegator', MR
knows that the HA is capable of delegating the MNP(s) in the MNP Option.
If the MNP in the received MNP Data Option is all zeros, HA is not
capable of delegating the wanted MNP. If MR queried for x pieces of
MNPs, the information of the MNP queries are in the corresponding places
in the reply. For example the second queried MNP information is in the
second MNP Data Option of the received MNP Option. If the code is


P„„kk÷nen et al.         Expires September 2003                [Page 10]


INTERNET-DRAFT           MNP Delegation                       March 2003

'MNP Unavailable', MR knows that the HA is not capable of delegating any
of the MNPs the MR queried. The queried MNPs are present in the MNP
Option of the reply. If MR does not receive any response after
MNP_REQUEST_MAX_RETRIES attempts, the MR MAY start the MNP Query
sequence again or conclude that its HA is not capable of delegating
MNPs.

After the MNP Query sequence MR can decide to proceed to MNP
Delegation sequence based on the received MNP information in the MNP
Option or it can continue with a new MNP Query sequence. MR might
continue MNP Query sequence with its HA, because MR might not be
satisfied with the capabilities of the HA to delegate MNPs. In that case
MR MAY change the MNP descriptions in the MNP Option of the new MNP
Delegation sequence.

  HA functionality:

After the HA receives a MNP Delegation-Message from a MR, HA has to
check it as follows independently of the code of the message:

  - ICMPv6 type: The type of the ICMPv6 message MUST be
    MNP_DELEGATION_MESSAGE.
  - IP source address field: If the received message has a Home Address
    destination option, the COA in binding cache of the home address
    MUST be equal to the IP source address.
  - IP destination address field: The destination address MUST be the
    HA's IP address.
  - MNP Option: Check that the MNP Delegation-Message has a MNP Option
    with one or more MNP Data Options.

If these checks are not valid, HA MUST silently ignore the message.

In this case the ICMPv6 code of the received message MUST be 'MNP
Delegator Query'. HA can now inform the MR about the MNP(s) it is
capable of delegating. It SHOULD make the choice based on the
received information in the MNP Option. Each MNP Data Option SHOULD be
considered as one MNP information query. If the match field is set to
zero in the MNP Data Option, the MNP is wanted to be queried based on
MNP and its length. If the match field is set to one, MNP is wanted to
be queried only based on MNP length. HA SHOULD follow these
preferencies in the sequence, but can inform MNPs based on it own
criteria. If a MNP is not wanted to be informed to the MR based on a
MNP information query, all zeros MUST be set to the MNP field in the
MNP Data Option. If the HA is not capable of delegating any MNP(s)
queried for in the request, a MNP Delegation-Message with code
'MNP Unavailable' MUST be sent to the MR. In this case the MNP Data
Options MUST be copied from the request message. Otherwise MNP
information of the MNP(s), which HA is capable of delegating MUST be
attached to the MNP Option of a MNP Delegation-Message. The MNP Data
Options in the response MUST follow the order of the information queries
in the request. This means that nth MNP Data Option to nth MNP query
MUST be in the nth position in the MNP Option. A MNP Delegation-Message


P„„kk÷nen et al.         Expires September 2003                [Page 11]


INTERNET-DRAFT           MNP Delegation                       March 2003

SHOULD be constructed and sent as follows independently of its code:

  - IP source address field: HA's global IP address is set as source
    address in the IP header source address field.
  - IP destination address field: The corresponding MNP
    Delegation-Message's source address is set as destination address in
    the IP header destination address field.
  - Transaction identifier: Copy the Transaction identifier from the MNP
    Delegation-Message to the response's transaction identifier field.
  - Routing header type 2: A type 2 routing header MUST be included with
    the MR's home address if the received MNP Delegation-Message had a
    Home Address destination option. The home address is received from
    the Home Address destination option of the corresponding MNP
    Delegation-Message.
  - The match field: The match field MUST copied from the request
    message from the corresponding MNP Data Options.

In this case the code 'MNP Delegator' is set as the type of the MNP
Delegation-Message. HA might receive multiple identical MNP
Delegation-Message messages, because of retransmissions at the MR. The
HA SHOULD handle and answer to these messages identically to those
received before.

5.4.2 MNP Delegation sequence

The MNP Delegation sequence can be initiated by the MR after the MNP
Query sequence or without it. It is used by the MR to delegate MNP(s)
from its HA(s). After successfully executing the sequence, one or more
MNP(s) have been delegated for the MR.

  MR functionality:

The MNP Delegation sequence begins when MR sends a MNP
Delegation-Message with an ICMPv6 code of 'MNP Request' to its HA. MR
can select the HA for MNP delegation based on the MNP Query sequence.
The MNP Delegation-Message is constructed and sent as described in the
MNP Query sequence (chapter 5.4.1). The ICMPv6 code of the message is
now 'MNP Request'.

If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 for MR functionality. If the checks are
valid, MR SHOULD proceed as follows:

  - If the code of the response is set to 'MNP Delegated', MR can
consider one or more MNP(s) delegated. Those MNP Data Options which have
all zeros in the MNP field, could not be delegated. The preferred and
valid lifetimes in the MNP Data Options indicate the lifetimes for the
delegated MNP(s). MR SHOULD store delegated MNP(s) with MNP length, HA's
address and lifetimes (MNP <-> MNP length <-> HA's address <-> valid
lifetime left <-> preferred lifetime left <->). This helps when
returning or refreshing the delegated MNP.



P„„kk÷nen et al.         Expires September 2003                [Page 12]


INTERNET-DRAFT           MNP Delegation                       March 2003

  - If the code is set to MNP Unavailable, none of the wanted MNP(s)
    were available for delegation. In this case MR MAY proceed MNP
    Delegation/Query sequence with different MNP preferences.

If the MR doesn't receive a MNP Delegation-Message response back
within MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message MAY be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, MR can conclude that the HA
in question is not capable of delegating the wanted MNPs.

  HA functionality:

If HA receives a MNP Delegation-Message with code 'MNP Request' it
MUST check the request as described in chapter 5.4.1 for HA
functionality. If the checks are valid, HA can proceed as follows:

 - If the wanted MNP(s) are available for delegation, HA constructs and
sends a MNP Delegation-Message as described in chapter 5.4.1 for HA
functionality except the ICMPv6 code is set to 'MNP Delegated'. A MNP
Option is added to the message based on the MNP(s) to be delegated. The
MNP Delegation occurs similarly as in the MNP Query sequence, but in
this case the MNP(s) are actually delegated instead of just informing
information about available MNPs. The HA SHOULD store the delegated
MNP(s) with the home address of the MR, MNP length and lifetimes (MNP
<-> MNP length <-> MR's home address <-> valid lifetime left <->
preferred lifetime left). This will later be helpful when refreshing or
returning related to the delegated MNP(s) occur.

 - If the MR cannot delegate any MNP(s) for the MR, it MUST send a MNP
   Delegation-Message back to the MR with a code 'MNP Unavailable' as
   described in chapter 5.4.1 for HA functionality. The MNP Option MUST
   be copied from the corresponding request.

  The MNP Delegation-Message may not reach its destination and the same
message might be retransmitted to the HA. In this case the retransmitted
message MUST be handled similarly as previously received identical
messages.

5.4.3 MNP Refresh sequence

MNP Refresh sequence is initiated by the MR to refresh the lifetimes
of leased MNP(s) with finite lifetimes.

  MR functionality:

When the valid or preferred lifetime of a delegated MNP diminishes
under a certain threshold, its lease SHOULD be renewed with the MNP
Refresh sequence. The recommended time for MNP refreshing is not
specified here. MR sets the MNP(s) to be refreshed in a MNP Option and
sends a MNP Delegation-Message to the HA from which the MNP(s) were
delegated from. The HA's address corresponding to the leased MNP should
have been previously stored with the delegated MNP, from which it can

P„„kk÷nen et al.         Expires September 2003                [Page 13]


INTERNET-DRAFT           MNP Delegation                       March 2003

be received for refreshing. The wanted lifetimes for the new MNP
delegation can be set according to the MR's preference. The MNP Refresh
sequence begins when the MNP Delegation-Message message is constructed
and sent as described in chapter 5.4.1 for MR functionality. The ICMPv6
code of the message is now 'MNP Refresh'.

If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 and in addition to that proceed as follows:

  - If the code of the response is set to 'MNP Delegated', it can
consider the MNP(s) refreshed. The preferred and valid lifetimes in the
MNP Data Options indicate the lifetimes for the delegated MNP(s). If a
MNP Data Option contains all zeros in the MNP field, the corresponding
MNP can be considered as not refreshed.

  - If the code is set to MNP Unavailable, none of the MNP(s) could be
refreshed. In this case the old lifetimes stay valid for the MNP(s).

If the MR doesn't receive a MNP Delegation-Message back within
MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, it might be because the
corresponding HA is down for some reason. In this case the MR MAY return
to MNP Refresh sequence after some unspecified amount of time.

  HA functionality:

If HA receives a MNP Delegation-Message with code 'MNP Refresh' it
MUST check the request as described in chapter 5.4.1 for HA
functionality. If the checks are valid, HA can proceed as follows:

 - If the HA is able to refresh lifetimes of one or more MNPs, HA
constructs and sends a MNP Delegation-Message as described in chapter
5.4.1 for HA functionality, except the ICMPv6 code is set to
'MNP Delegated'. The lifetimes of the refreshed MNP(s) MAY be chosen by
the delegating HA independently of the requested lifetimes in the MNP.
The requested lifetimes SHOULD however be used as guidance when
refreshing the MNP(s). All the MNP(s) which can be refreshed by the HA,
MUST be included in a MNP Option, which is sent back to the requesting
MR in a MNP Delegation-Message. If a MNP cannot be refreshed, all zeros
MUST be set to the MNP field in the MNP Data Option.

 - If the MR cannot refresh any MNP(s), it MUST send a MNP
   Delegation-Message back to the MR with a code 'MNP Unavailable'. The
   MNP Option MUST be copied from the corresponding request.

The MNP Delegation-Message message may not reach its destination and
the same message might be retransmitted to the HA. In this case the
retransmitted message MUST be handled similarly as previously received
messages.

5.4.4 MNP Return sequence

P„„kk÷nen et al.         Expires September 2003                [Page 14]


INTERNET-DRAFT           MNP Delegation                       March 2003

MNP Return sequence is initiated by the MR when the MR no longer needs
the previously delegated MNP(s).

  MR functionality:

When MR no longer needs the leased MNP(s) for some reason, it SHOULD
return them to the HA, which delegated the MNP(s). This is executed with
the MNP Return sequence. The information related to the MNP(s) to be
returned MUST be included inside a MNP Option, which is placed inside
the MNP Delegation-Message. The MNP Return sequence begins when the MNP
Delegation-Message is constructed and sent as described in chapter 5.4.1
for MR functionality. The ICMPv6 code of the message is now set to
'MNP Return'. HA's address should have been stored during MNP
Delegation, and is used now as a destination address.

If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 for MR functionality and if the checks are
valid, proceed as follows:

  - If the ICMPv6 code of the response is set to 'MNP Returned', MR can
    consider those MNP(s) returned, which have zero lifetimes in the MNP
    Option. If a MNP Data Option contains all zeros in the MNP field,
    the corresponding MNP can be considered as not returned.

  - If the ICMPv6 code is set to MNP Unavailable, none of the MNP(s) in
    the MNP Option were returned. In this case the old lifetimes stay
    valid for the MNPs.

If the MR doesn't receive a MNP Delegation-Message back within
MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, it might be because the
corresponding HA is down for some reason. In this case the MR MAY return
to MNP Return sequence after some unspecified amount of time.

  HA functionality:

If HA receives a MNP Request with ICMPv6 code 'MNP Return', it MUST
check the request as described in section 5.4.1 for HA functionality.
If the checks are valid, the HA can proceed as follows:

 - HA has to determine if the returned MNP(s) have been delegated by the
   HA to the requesting MR. The MNP(s) which have not been delegated by
   the HA, MUST have all zeros in the MNP field in the MNP Data Option.
   The MNP(s) which have been delegated by the HA and can be returned,
   MUST be included in the MNP Data Options of the response. The
   lifetimes of those MNP(s) MUST be set to zero to indicate that
   they are not valid anymore. HA constructs a MNP Delegation-Message as
   described in chapter 5.4.1 for HA functionality except the ICMPv6 code
   is set to 'MNP Returned'.

 - If none of the MNP(s) belong to the HA, a MNP Delegation-Message with

P„„kk÷nen et al.         Expires September 2003                [Page 15]


INTERNET-DRAFT           MNP Delegation                       March 2003

   the ICMPv6 code of 'MNP Unavailable' has to be returned to the
   requestor as described in chapter 5.4.1 for HA functionality. The MNP
   Option MUST be copied from the corresponding request.

The MNP Delegation-Message message may not reach its destination and
the same message might be retransmitted to the HA. In this case the
retransmitted message MUST be handled similarly as previously received
identical messages.

5.4.5 MNP Update sequence

MNP Update sequence is initiated by the HA when the valid or preferred
lifetimes of a delegated MNP are changed by the HA. With this sequence
those lifetime changes are informed to the MR, which originally
delegated the MNP. The MR might detect that the lifetimes of a delegated
MNP have been changed to zero by its HA. This means that the MNP cannot
be used anymore, and a new MNP should be delegated from the HA with the
MNP Query/Delegation sequences.

  HA functionality:

When valid or preferred lifetimes on one or more delegated MNPs are
changed by the MR, that information is informed to the MR by sending a
MNP Delegation-Message with ICMPv6 code 'MNP Update' to the MR as
described in chapter 5.4.1 for HA functionality with the following
changes to all message handling except IP source address field:

  - MNP Option: When updating MNP(s), a MNP Option MUST be added to the
    message to indicate the MNP(s) updating operation is concerned with.
    The new valid and preferred lifetimes are set to the MNP Data
    Options.
  - IP destination address field: The destination address in the IP
    header MUST be set to the MR's Home Address if that Home Address has
    no entry in the binding cache. This means that the MR is at home.
    MR's home address should have been saved during the MNP Delegation
    sequence with the MNP. Otherwise the COA from the binding cache MUST
    be used.
  - Transaction identifier: A new random transaction identifier MUST be
    used in the transaction identifier field.
  - Routing header type 2: A type 2 routing header MUST be included with
    the MR's home address, if the MR's home address has a binding cache
    entry.
  - The match field: The match field MUST set to zero in all MNP Data
    Options to indicate a match based on both MNP and its length.

If HA doesn't receive a MNP Delegation-Message message within
MNP_REQUEST_DELAY milliseconds, HA SHOULD retransmit the same message.
If no response is received after MNP_REQUEST_MAX_RETRIES
retransmissions, HA MAY proceed with its own preference. If the MR
doesn't respond for any reason, HA MAY initiate MNP Updating sequence
again after some time or it might stop sending messages to the MR.
However, the HA can only be sure that MR has received the updating MNP
Delegation-Message, when HA receives a MNP Delegation-Message with

P„„kk÷nen et al.         Expires September 2003                [Page 16]


INTERNET-DRAFT           MNP Delegation                       March 2003

ICMPv6 code of 'MNP Update Ack'.

When HA receives a MNP Delegation-Message with code 'MNP Update-Ack'
it SHOULD check it as described in chapter 5.4.1 for HA functionality
with the following additional check:

  - IP source address field: Check that the IP source address field of
    the message is the same as the destination address in the
    corresponding MNP Delegation-Message request with the same
    transaction identifier.

If the checks are valid, it SHOULD proceed as follows:

  - The MNP(s) in the MNP Data Options of the MNP Option indicate the
    MNP(s), which MR has updated. The HA SHOULD now update the
    lifetimes on its local storage. If a MNP Data Option contains all
    zeros in the MNP field, the corresponding MNP can be considered as
    not updated.

  - If the code is set to MNP Unavailable, none of the MNP(s) in the MNP
    Option were updated. In this case the old lifetimes stay valid for
    the MNPs.

  MR functionality:

When MR receives a MNP Delegation-Message with ICMPv6 code
'MNP Update', it MUST perform checks on all items except IP source
address field as described in chapter 5.4.1 for MR functionality with
the following additional checks:

  - IP source address field: Check that the IP source address field of
    the message is the HA's address from which MR originally delegated
    the MNP.

If the checks are not valid, MR MUST silently ignore the message.
Otherwise

  - Those MNP(s) which have zero lifetimes, are going to be expired and
    SHOULD not be used anymore after this message is received. Those
    MNP(s) which have non-zero lifetimes, can be used as before, and
    the lifetimes of those MNP(s) SHOULD be updated on local storage.

Based on the received update message a MNP Delegation-Message MUST be
constructed on items concerning IP source address field, Home Address
destination option and binding update list as described in chapter 5.4.1
for MR functionality. In addition the other items are constructed as
follows:

  - IP destination address field: Destination address MUST be copied
    from the destination address field of the corresponding update
    message.

  - Transaction identifier: The Transaction identifier MUST be copied

P„„kk÷nen et al.         Expires September 2003                [Page 17]


INTERNET-DRAFT           MNP Delegation                       March 2003

    from the corresponding update message.

  - The match field: Match field MUST be copied from the corresponding
    update message's MNP Data Options.

  - MNP Option and ICMPv6 code: MR MUST check that the MNP(s) in the
    update have before been delegated to the MR. Those MNP(s) which
    have been delegated before MUST be copied from the update message
    to MNP Data Option of the message. Those MNP(s) which cannot be
    updated, MUST have all zeros in the MNP field of the MNP Data
    Option. If one or more of the updated MNP(s) were updated
    successfully, ICMPv6 code of the message is set to
    'MNP Update Ack'. If none of the MNP(s) could be updated
    successfully, the MNP Data Options MUST be copied from the update
    message to the response, and the ICMPv6 code MUST be set to 'MNP
    Unavailable'

The MNP Delegation-Message message may not reach its destination and
the same MNP Delegation-Message message might be retransmitted to the
MR. In this case the retransmitted message MUST be handled similarly as
previously received identical messages.

5.5 Examples

In this section a transaction related to both MNP Query and MNP
Delegation sequences are depicted. In the first case MR is at home and
in the second case MR is at a foreign domain. Also a transaction related
to MNP Updating sequence is presented as defined in chapter 5.4.5.

5.5.1 MNP Query sequence

MR at home:

    _____________         ___________
   (             )       /           \
   (  Internet   )------|Home domain |---HA
   (_____________)       \__________/
                            |
                            MR

  In this example the MR is at home and proceeds with MNP Query with its
HA. MR wants to be delegated an arbitrary MNP of length 48 and a certain
MNP (4ffe:1:1:1/64). HA responds back to the MR by informing that a MNP
of 48 can be delegated from the HA and 4ffe:1:1:1/64 MNP is not
available for delegation.

Message flows:

MR                                             HA


----------------------------------------------->


P„„kk÷nen et al.         Expires September 2003                [Page 18]


INTERNET-DRAFT           MNP Delegation                       March 2003

MNP Delegation-Message

IP fields:
 [
 Source address: MR's home address
 Destination address: HA address
 ]

ICMP fields:
 [
 Type: MNP Delegation-Message
 Code: MNP Delegator Query
 Transaction ID: 23456
 Reserved: 0

   MNP Option:
   [
   Type=0x01
   Option length=2*sizeof(MNP Data Option)

     MNP Data Option
     [
     Preferred lifetime: 3600
     Valid lifetime: 3600
     Prefix length: 48
     IPv6 Prefix: 0x0
     Match: 1
     ]

     MNP Data Option
     [
     Preferred lifetime: 3600
     Valid lifetime: 3600
     Prefix length: 64
     IPv6 Prefix: 4ffe:1:1:1
     Match: 0
     ]
   ]
 ]

<-----------------------------------------------

MNP Delegation-Message

IP fields:
 [
 Source address: HA's address
 Destination address: MR's home address
 ]

ICMP fields:
 [
 Type: MNP Delegation-Message

P„„kk÷nen et al.         Expires September 2003                [Page 19]


INTERNET-DRAFT           MNP Delegation                       March 2003

 Code: MNP Delegator
 Transaction ID: 23456
 Reserved: 0

   MNP Option:
   [
   Type=0x01
   Option length=2*sizeof(MNP Data Option)

     MNP Data Option
     [
     Preferred lifetime: 3600
     Valid lifetime: 3600
     Prefix length: 48
     IPv6 Prefix: 3ffe:2222:2222::0
     Match: 1
     ]

     MNP Data Option
     [
     Preferred lifetime: 0
     Valid lifetime: 0
     Prefix length: 64
     IPv6 Prefix: 0::0
     Match: 0
     ]
   ]
 ]

5.5.2 MNP Delegation Sequence

MR not at home:

    _____________         __________
   (             )       /          \
   (  Internet   )------|Home domain|---HA
   (_____________)       \_________/
          |
       ___|_______
       |         |
       | Foreign |
       | domain  |
        \________/
            |
            |
            MR

In this example the MR is at a foreign domain and proceeds with MNP
delegation with its HA. MR wants to be delegated a certain MNP of length
48. HA responds by delegating the MNP for the MR.

Message flows:


P„„kk÷nen et al.         Expires September 2003                [Page 20]


INTERNET-DRAFT           MNP Delegation                       March 2003

MR                                             HA

----------------------------------------------->

MNP Delegation-Message

IP fields:
[
Source address: MR's COA
Destination address: HA's address
]

Home address destination option
[
Home Address=MR's home address
]

ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Request
Transaction ID: 67890
Reserved: 0

  MNP Option:
  [
  Type=0x01
  Option length=1*sizeof(MNP Data Option)

    MNP Data Option
    [
    Preferred lifetime: 3600
    Valid lifetime: 3600
    Prefix length: 48
    IPv6 Prefix: 3ffe:2222:2222::0
    Match: 0
    ]
  ]
]

<-----------------------------------------------

MNP Delegation-Message

IP fields:
[
Source address: HA's address
Destination address: MR's COA
]

Type 2 Routing Header
[
Home Address=MR's Home Address

P„„kk÷nen et al.         Expires September 2003                [Page 21]


INTERNET-DRAFT           MNP Delegation                       March 2003

]

ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Delegated
Transaction ID: 67890
Reserved: 0

  MNP Option:
  [
  Type=0x01
  Option length=1*sizeof(MNP Data Option)

    MNP Data Option
    [
    Preferred lifetime: 3600
    Valid lifetime: 3600
    Prefix length: 48
    IPv6 Prefix: 3ffe:2222:2222::0
    Match: 0
    ]
  ]
]

5.5.3 MNP Updating sequence

MR not at home:

    _____________         __________
   (             )       /          \
   (  Internet   )------|Home domain|---HA
   (_____________)       \_________/
          |
       ___|_______
       |         |
       | Foreign |
       | domain  |
        \________/
            |
            |
            MR

In this example the MR is at a foreign domain and HA proceeds with
updating the lifetimes of the previously delegated MNP to zero. After
this sequence the updated MNP is no longer valid in the MR, and MR has
to delegate a new MNP by running the MNP Query and MNP Delegation
sequences.

Message flows:

HA                                             MR


P„„kk÷nen et al.         Expires September 2003                [Page 22]


INTERNET-DRAFT           MNP Delegation                       March 2003

----------------------------------------------->

MNP Delegation Message:

IP fields:
 [
 Source address: HA address
 Destination address: MR's COA
 ]

Type 2 Routing header
[
Home Address=MR's home address
]

ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Update
Transaction ID: 948738
Reserved: 0

  MNP Option:
  [
  Type=0x01
  Option length=1*sizeof(MNP Data Option)

    MNP Data Option
    [
    Preferred lifetime: 0
    Valid lifetime: 0
    Prefix length: 48
    IPv6 Prefix: 3ffe:2222:2222::0
    Match: 0
    ]
  ]
]

HA                                             MR

<-----------------------------------------------

MNP Delegation-Message

IP fields:
[
Source address: MR's COA
Destination address: HA's address
]

Home address destination option
[
Home Address=MR's home address

P„„kk÷nen et al.         Expires September 2003                [Page 23]


INTERNET-DRAFT           MNP Delegation                       March 2003

]

ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Update-Ack
Transaction ID: 948738
Reserved: 0

  MNP Option:
  [
  Type=0x01
  Option length=1*sizeof(MNP Data Option)

    MNP Data Option
    [
    Preferred lifetime: 0
    Valid lifetime: 0
    Prefix length: 48
    IPv6 Prefix: 3ffe:2222:2222::0
    Match: 0
    ]
  ]
]

6. Constants

MNP_REQUEST_DELAY=500
MNP_REQUEST_MAX_RETRIES=3

7. Security issues

Security issues of this MIPv6 extension are not considered in the
draft. These issues must be considered in the next version of the draft.

Acknowledgements

The author would like to thank the following persons on the NEMO mailing
list for feedback in an alphabetical order:

Erik Nordmark
Alexandru Petrescu
Mattias Pettersson

References

[1] S. Bradner "Key words for use in RFCs to Indicate Requirement
    Levels" BCP 14, RFC 2119, Internet Engineering Task Force, March
    1997.

[2] D. B. Johnson, C. E. Perkins, J. Arkko "Mobility Support in IPv6"
    (draft-ietf-mobile-ipv6-21), Internet Draft, Internet Engineering
    Task Force, Feb 2003.

P„„kk÷nen et al.         Expires September 2003                [Page 24]


INTERNET-DRAFT           MNP Delegation                       March 2003

[3] T. Ernst, H. Lach "Network Mobility Support Terminology" (draft-
    ernst-nemo-terminology-01), Internet Draft, Internet Engineering
    Task Force, Nov 2002.

[4] NEtwork MObility working group website URL: http://www.nal.motlabs.
    com/nemo.

[5] M. Crawford "Router Renumbering for IPv6" RFC 2894, Internet
    Engineering Task Force, Aug 2000.

[6] T. J. Kniveton, J. T. Malinen, V. Devarapalli, C. E. Perkins "Mobile
    Router Tunneling Protocol" (draft-kniveton-mobrtr-03) Internet
    Draft, Internet Engineering Task Force, Nov 2002.

[7] B. Haberman, J. Martin "Automatic Prefix Delegation Protocol for
    Internet Protocol Version 6 (IPv6)"
    (draft-haberman-ipngwg-auto-prefix-02), Internet Draft, Internet
    Engineering Task Force, Feb 2002.

[8] O. Troan, R. Droms "IPv6 Prefix Options for DHCPv6"
    (draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03), Internet Draft,
    Internet Engineering Task Force, March, 2003.

[9] A. Conta, S. Deering "Internet Control Message Protocol (ICMPv6)
    for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463,
    Internet Engineering Task Force, Dec 1998.

[10] S. Deering, R. Hinden "Internet Protocol, Version 6 (IPv6)
     Specification" RFC 2460, Dec 1998.

[11] Wakikawa R. K. Uehara, K. Mitsuya, T. Ernst "Basic Metwork Mobility
     Support" (draft-wakikawa-nemo-basic-00), Internet Draft, Internet
     Engineering Task Force, Feb, 2003.

Authors' addresses

Pekka P„„kk÷nen
VTT Electronics
Kaitov„yl„ 1
90571 Oulu
Finland
email: pekka.paakkonen@vtt.fi

Juhani Latvakoski
VTT Electronics
Kaitov„yl„ 1
90571 Oulu
Finland
email: juhani.latvakoski@vtt.fi





P„„kk÷nen et al.         Expires September 2003                [Page 25]

INTERNET-DRAFT           MNP Delegation                       March 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into 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.


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/