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

Versions: 00 01 02 draft-ietf-hip-mm

Network Working Group                                        P. Nikander
Internet-Draft                                                  J. Arkko
Expires: December 16, 2003                                     P. Jokela
                                           Ericsson Research Nomadic Lab
                                                           June 17, 2003


     End-Host Mobility and Multi-Homing with Host Identity Protocol
                         draft-nikander-hip-mm-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 Internet-Draft will expire on December 16, 2003.

Copyright Notice

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

Abstract

   This document specifies end-host mobility and multi-homing mechanisms
   for the Host Identity Protocol.












Nikander, et al.       Expires December 16, 2003                [Page 1]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Conventions used in this document  . . . . . . . . . . . . .  6
   3.    Usage scenarios  . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   End-host mobility  . . . . . . . . . . . . . . . . . . . . .  7
   3.2   Location privacy . . . . . . . . . . . . . . . . . . . . . .  7
   3.3   End-host multi-homing  . . . . . . . . . . . . . . . . . . .  7
   3.4   Site multi-homing  . . . . . . . . . . . . . . . . . . . . .  8
   3.5   Combined mobility and multi-homing . . . . . . . . . . . . .  8
   3.6   Network renumbering  . . . . . . . . . . . . . . . . . . . .  8
   3.7   Combined all . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.    Overview of HIP mobility and multi-homing functionality  . .  9
   4.1   IP addresses assigned to a node  . . . . . . . . . . . . . .  9
   4.2   Informing the peer about multiple or changed address(es) . .  9
   4.3   Address verification . . . . . . . . . . . . . . . . . . . . 10
   4.4   Forwarding Agents  . . . . . . . . . . . . . . . . . . . . . 10
   4.4.1 Address leases from an Forwarding Agent  . . . . . . . . . . 11
   4.4.2 Recovering from forwarding agent crashes . . . . . . . . . . 12
   4.5   Security Associations  . . . . . . . . . . . . . . . . . . . 12
   5.    Protocol overview  . . . . . . . . . . . . . . . . . . . . . 13
   5.1   Acquiring an address lease from a Forwarding Agent . . . . . 13
   5.2   Renewing an address lease  . . . . . . . . . . . . . . . . . 14
   5.3   Readdressing and address status  . . . . . . . . . . . . . . 14
   6.    Protocol definition  . . . . . . . . . . . . . . . . . . . . 16
   6.1   Packet formats . . . . . . . . . . . . . . . . . . . . . . . 16
   6.1.1 REA - the HIP readdress packet . . . . . . . . . . . . . . . 16
   6.1.2 AC and ACR - the HIP Address Check and Address Check
         Reply  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets . . . . . . 20
   6.2   Requesting Address Leases  . . . . . . . . . . . . . . . . . 21
   6.3   Providing address Leases . . . . . . . . . . . . . . . . . . 21
   6.4   Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . 21
   6.5   Handling received REAs at end hosts  . . . . . . . . . . . . 22
   7.    Policy considerations  . . . . . . . . . . . . . . . . . . . 23
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 24
   8.1   Why does the foreign agent may require a puzzle solution?  . 24
   8.2   Attacker masquerading as a FA  . . . . . . . . . . . . . . . 24
   8.3   Location privacy . . . . . . . . . . . . . . . . . . . . . . 25
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 26
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 27
         Normative references . . . . . . . . . . . . . . . . . . . . 28
         Informative references . . . . . . . . . . . . . . . . . . . 29
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
   A.    Site multi-homing  . . . . . . . . . . . . . . . . . . . . . 31
   A.1   A host connected to a multi-homed site . . . . . . . . . . . 31
   A.2   Transit providers with NATs  . . . . . . . . . . . . . . . . 31
   B.    Implementation experiences . . . . . . . . . . . . . . . . . 32



Nikander, et al.       Expires December 16, 2003                [Page 2]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


         Intellectual Property and Copyright Statements . . . . . . . 33


















































Nikander, et al.       Expires December 16, 2003                [Page 3]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


1. Introduction

   This document specifies how the Host Identity Protocol [3] (HIP)
   provides simple and efficient means for nodes to communicate while
   being multi-homed, mobile, or simultanously mobile and multi-homed.
   Additionally, HIP allows communications even when the multi-homing or
   mobility causes a change in the IP version that is available in the
   network.

   More specifically, the Host Identity Protocol [3] (HIP) defines a
   mechanism that decouples the transport layer from the internetworking
   layer, and introduces a new Host Identity namespace.  When a host
   uses HIP, the transport layer sockets and IPsec Security Associations
   are not bound to IP addresses but to Host Identifiers.  This document
   specifies how the mapping from Host Identifiers to IP addresses can
   be extended from a static one-to-one mapping into a dynamic
   one-to-many mapping.  This enables end-host mobility and
   multi-homing.  Additionally, this document introduces the concept of
   Forwarding Agents.  A Forwarding Agents provides Mobile IP Home Agent
   like functionality for HIP enabled mobility.

   In practice, the HIP base exchange creates a pair of IPsec Security
   Associations (SA) between any communicating pair of HIP enabled
   nodes.  These SAs are not bound to IP addresses but to Host
   Identifiers (public keys).  However, the hosts must also know at
   least one IP address where their peers are reachable.  Initially this
   IP address is the one used during the HIP base exchange.

   Since the SAs are not bound to IP addresses, the nodes are able to
   receive IPsec protected HIP packets from any address.  Thus, a node
   can change its IP address and continue to send packets to its peers.
   However, the peers are not able to send replies before they can
   reliably and securely update the sending node's address(es).

   This document specifies a mechanism that allow a HIP node to update
   its address(es) to its peers.  The address update is implemented with
   a new HIP packet type, the HIP Readdress (REA) packet.  Due to the
   danger of flooding attacks (see [4]), the peer must always check the
   reachability of the node before it can use the new addresses.  The
   reachability check is implemented with a pair of new HIP packet
   types, HIP Address Check (AC) and HIP Address Check Reply (ACR).  In
   addition to initiating and reachbility check, an AC packet may also
   act as an acknowledgement for a preceding REA packet.

   There are a number of situations where the simple end-to-end
   readdressing functionality is not sufficient.  These include the
   initial reachability of a mobile node, location privacy, end-host and
   site multi-homing with legacy hosts, and NAT traversal.  In these



Nikander, et al.       Expires December 16, 2003                [Page 4]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   situations there is a need for some helper functionality in the
   network.  In this document we describe mechanisms for initial
   reachability, multi-homing, recovering from simultaneous movements,
   and combining mobility and multi-homing.  Some of these functions
   require an additional node in the network, which has been given the
   name of Forwarding Agent.  As a special case, a Forwarding Agent can
   act as a lightweight Rendezvous server as defined in [3].












































Nikander, et al.       Expires December 16, 2003                [Page 5]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


2. 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 RFC2119 [1].














































Nikander, et al.       Expires December 16, 2003                [Page 6]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


3. Usage scenarios

   In this section we briefly introduce a number of usage scenarios
   where the HIP mobility and multi-homing facility is useful.  To
   understand these usage scenarios, the reader should be at least
   minimally familiar with the HIP protocol specification [3].  However,
   for the (relatively) uninitiated reader it is most important to keep
   in mind that in HIP the actual payload traffic is protected with ESP,
   and that the ESP SPI acts as an index to the right host-to-host
   context.

3.1 End-host mobility

   A mobile IP host must change its IP address according to
   connectivity.  The change of an IP address might be needed due to a
   change in the advertised IPv6 prefixes on the link, a reconnected PPP
   link, a new DHCP lease, or an actual movement to another subnet.  In
   order to maintain its communication context, the host must inform its
   peers about the new IP address.

   Although HIP enables ESP and the upper layer to be independent of the
   internetworking layer, there still needs to be a mapping of the
   pseudo-IP addresses used in the upper stack (LSI and HIT) to a real
   IP address.  Thus, from the functional point of view, it is
   sufficient that the peer nodes learn the new IP address.  The upper
   layer protocols need to know about the address and connectivity
   change only for QoS and similar purposes.  In most cases, they need
   not to know.

3.2 Location privacy

   To protect its privacy, an IP host may want to keep its actual IP
   address private.  Since HIP insulates the upper layer from the IP
   address, this can be accomplished by simple address rewriting at an
   privacy protecting node.

   Note that a mobile node may want to keep its location private. In
   that case, it informs its real address to the privacy protecting node
   and not to the actual peers.

   Full location privacy falls beyond this document.

3.3 End-host multi-homing

   A host may have multiple interfaces, and it is desired that it can
   stay reachable through all of the currently available interfaces.  It
   is expected that the set of available interfaces may change
   dynamically, and that there may be policies associated with the usage



Nikander, et al.       Expires December 16, 2003                [Page 7]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   of the different interfaces. For instance, the host may have a fast
   but low range wireless interface and a slow high range interface.
   The host may generally prefer to use the fast interface, but it may
   be available only some of the time.

   Note that a host may be multi-homed and mobile simultaneously, and
   that a multi-homed host may want to protect the location of some of
   its interface while revealing the IP address of some others.

3.4 Site multi-homing

   A host may have an interface that has multiple globally reachable IP
   addresses.  Such a situation may be a result of the site having
   multiple upper Internet Service Providers, or just because the site
   provides all nodes with both IPv4 and IPv6 addresses.   It is
   desirable that the host can stay reachable with all currently
   available globally routable addresses, independent on how they are
   provided.

   Note that a single interface may experience site multi-homing while
   the host itself may have multiple interfaces.

3.5 Combined mobility and multi-homing

   It looks likely that in the future many of the mobile nodes will be
   simultaneously mobile and multi-homing, i.e., have multiple mobile
   interfaces.  Furthermore, if the interfaces use different access
   technology, it is fairly likely that one of the interfaces may appear
   stable (retain its current IP address) while some other(s) may
   experience mobility (undergo IP address change).

3.6 Network renumbering

   It is expected that IPv6 networks will be renumbered much more often
   than most IPv4 networks are.  From an end-host point of view, network
   renumber is similar to mobility.

3.7 Combined all

   It is desirable that a host may simultaneously have multiple active
   interfaces, be mobile (on any or all of its interfaces), utilize
   multiple globally reachable addresses (on any or all of its
   interfaces), and protect its location privacy (on any or all of its
   interfaces).







Nikander, et al.       Expires December 16, 2003                [Page 8]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


4. Overview of HIP mobility and multi-homing functionality

   HIP mobility and multi-homing is fundamentally based on the HIP
   architecture [4], where the transport and internetworking layers are
   insulated from each other with the new host identity layer.  In the
   HIP architecure, the transport layer sockets are bound to the Host
   Identifiers (through HIT or LSI in the case of legacy APIs), and the
   Host Identifiers are translated to the actual IP address.

   In the base HIP protocol specification [3], it is defined how two
   hosts exchange their Host Identifiers and establish a pair of ESP
   Security Associations (SA).  The ESP SAs are then used to carry the
   actual payload data between the two hosts, by wrapping TCP, UDP, and
   other upper layer headers into transport mode ESP payloads.  The IP
   header, carrying the ESP header, uses actual IP addresses in the
   network.

   In the base specification, hosts use the same IP addresses for nodes
   that were used during the base HIP exchange. This specification
   defines the way how IP addresses can be changed during the
   communication.

4.1 IP addresses assigned to a node

   A host can have multiple IP addresses. It may have many interfaces
   that are assigned IP addresses or it may have multiple addresses
   assigned to one interface. There may also be multiple IP addresses in
   function of time: the node may changes its topological location in
   the network, or its network may change addresses.

   The interfaces are logical objects.  A host may claim to have any
   number of interfaces, as long as a single IP address does not appear
   to be bound to more than one interface.  The purpose of the
   interfaces is to group the addresses into collections that are likely
   to experience fate sharing.  For example, if the host needs to change
   its addresses on interface2, it is likely that both address21 and
   address22 will simultaneously become obsolete.

4.2 Informing the peer about multiple or changed address(es)

   To be able to use effectively multiple addresses assigned to the host
   and update addresses that change during the communication with
   another node, a HIP protocol packet, the REA packet (see Section
   6.1.1), is specified. The logical structure created with REA packets
   has three levels:  hosts, interfaces, and addresses.  This is
   illustrated in Figure 1.

                            address11



Nikander, et al.       Expires December 16, 2003                [Page 9]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


                          /
               interface1 - address12
             /
            /               address21
       host -- interface2 <
            \               address22
             \
               interface3 - address31
                          \
                            address32

                                Figure 1

   A single REA payload handles only one interface.  To signal
   simultaneously changes on several interfaces, it is necessary to send
   several consequtive REA payloads.  The packet structure supports
   this.

4.3 Address verification

   When a HIP host receives a group of IP addresses from another HIP
   host in a REA, it does not necessarily know for sure whether the
   other host is actually reachable at the claimed addresses.  In fact,
   if the other HIP host is not fully trusted, it may be giving a bogus
   address with the intention of causing packet flood towards the given
   address [8].  Thus, before the HIP host can actually use a new
   address, it must first check that the peer is reachable at the new
   address.  This is implemented with the HIP Address Check (AC) and
   Address Check Reply (ACR) packets.

   To acknowledge that it has received the REA, and to initiate an
   address check, the HIP host receiving a REA immediately sends an AC
   to all addresses mentioned in the REA.

   In a typical implementation, an address consists of the actual
   bitpattern used in the IP source and destination fields, a lifetime,
   and a status.  The status is used to track the reachability of the
   address.

4.4 Forwarding Agents

   For nodes that are mobile, an IP address from where it can be reached
   is necessary if the node wants to be reachable by other nodes. The
   Forwarding Agent provides one possible solution to this. The
   reachability of the HIP node may require usage of both IPv6 and IPv4.
   If the HIP node itself is behind a network that supports only one of
   the IP protocol versions, the HIP node may use the FA for acting as a
   gateway when the peer node wants to use a IP protocol version that



Nikander, et al.       Expires December 16, 2003               [Page 10]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   the HIP node behind the FA does not directly support.

   The HIP node can "lease" IP address(es) from the FA if it needs an
   address from where it can be reached.  This can be the case, for
   example, when a mobile node needs a contact address for peer nodes.
   The HIP node contacts the FA, requests for an IP address (and SPI
   range), and start announcing the IP address (and some SPI) to its
   peers. The SPI is required if the IP address leased from the FA is
   not unique, i.e. it does not map one-to-one to the HIT of the HIP
   node. Further ESP protected data packets arriving to the FA can thus
   be identified using the SPI value and verifying to which HIP node
   that particular SPI has been reserved.

   As long as the "lease" is valid, the FA will forward any packets sent
   to the IP address (and an SPI within the range) to the HIP host. The
   basic operational model is depicted in Figure 2. Without mobility
   (REA), using a FA results in triangular routing, as shown.

    +----------+                             +--------------+
    | HIP host |---------------------------->| Another host |
    +----------+                             +--------------+
         ^ real IP address                           |
         |                                           |
         |                                           |
    +----------+ leased IP address                   |
    |    FA    |<------------------------------------+
    +----------+

                                Figure 2

   The actual method of discovering FAs is beyond the scope of this
   document, and will be specified elsewhere.

4.4.1 Address leases from an Forwarding Agent

   To acquire an address lease from a given FA, the HIP host sends a
   Forwarding Agent Query (FAQ) packet to it.  In some cases, the FAQ
   may be sent as a broadcast or multicast packet; the details of such
   practice will be specified elsewhere.  The HIP host may use any
   identity it wishes; however, the identity may be subject to local
   access control by the FA.  That is, some FAs may be willing to serve
   only some HIP hosts.

   If the FA is willing to serve an address to the HIP host, it replies
   to the FAQ with a Forwarding Agent Advice (FAA) packet.  A FAA
   establishes an address lease to the HIP host.  The HIP host can rely
   on the FA to keep forwarding packets to the HIP host until the
   address lease expires.  If the FA is not willing to serve the HIP



Nikander, et al.       Expires December 16, 2003               [Page 11]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   host, it responds with a Forwarding Agent Denied (FAD) packet,
   specifying the reason for denial.

   Each address lease has a lifetime.  The HIP host may renew the
   address lease at any time before it the lease expires.  Subject to
   its policy, the FA should renew and extend the lease, but it MAY
   refuse any extensions.  In any case, it must not reduce the lease
   lifetime making it to expire prior to the initial expiration time.

   The HIP host may abandon the lease at any time, either by failing to
   renew it or by sending an Forwarding Agent Query that specifies a
   zero lifetime.  If an address lease expires without having been
   renewed, the FA simply discards the forwarding state and any
   resources associated with it.

4.4.2 Recovering from forwarding agent crashes

   If a FA crashes, it looses its state.  Consequently, it cannot
   forward packets sent to it, since it does not know the IP address
   associated with the leased address (and the SPI).  The only thing the
   forwarding agent could do would be to simulate lost state by the
   actual HIP host that is leasing the address.  However, since the
   crashed FA does not know the HIT of the host, it cannot do that.
   Effectively, the forwarding agent becomes a black hole until the HIP
   host recognizes the situation and ackquires a new lease.

   It is currently an open problem whether a crashed FA should send some
   kind of error message to the hosts sending ESP packets to it.

4.5 Security Associations

   The security associations between the nodes are not any longer
   directly connected to the IP address of the node. The SA is
   associated with the HIT and there may be either one SA between the
   nodes, or multiple SAs when the interface capabilities require such
   an arrangement.

   All addresses on a single interface share an SA.  Multiple interfaces
   may share a single SA, but each interface may also have its own SA.
   In practice, multiple interfaces may share an SA if the experienced
   latency is fairly similar, in which case the packets are received
   within the IPsec reordering window.  However, the latencies between
   two interfaces are considerably different, it becomes more likely
   that some of the packets would be discarded due to appearing to have
   been received outside of the ESP reordering window.  Thus, in that
   case it is necessary to use different SAs for different interfaces.





Nikander, et al.       Expires December 16, 2003               [Page 12]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


5. Protocol overview

   The HIP mobility and multi-homing functionality consist of the
   following subprotocols:

      Acquiring an address lease from a Forwarding Agent

      Renewing an address lease

      Informing peers about multiple addresses or address changes, and
      verifying the reachability of addresses


5.1 Acquiring an address lease from a Forwarding Agent

     HIP host                         Forwarding Agent
               Forwarding Agent Query
        ----------------------------------->

                        R1
        <-----------------------------------

               Forwarding Agent Query
        ----------------------------------->

               Forwarding Agent Advice
        <-----------------------------------

   To acquire an address lease, the HIP host sends an FAQ, requesting
   for an address lease.  The host may specify the type of address it
   wants to have (IPv4, IPv6, either), the number of SPIs requested, and
   the desired lifetime.  Any of these fields may be left empty, as
   well.  The FAQ is always signed.

   If the Forwarding agent does not trust the HIP host, it may answer
   with an R1, basically asking the HIP host to solve a puzzle before
   the Forwarding Agent is even willing to consider the request.  Once
   the HIP host has solved the puzzle, it may send the FAQ again, this
   time including an answer to the puzzle.

   XXX: Is it OK that the FA answers with a normal R1, or should we use
   some other packet type, e.g., Forwarding Agent R1 (FAR1)?

   If the FA is willing to serve the HIP host, it answers with an FAA,
   specifying the leased IP address, its lifetime, and if the address is
   an IPv4 address, a range of SPIs that has been reserved for the HIP
   host.




Nikander, et al.       Expires December 16, 2003               [Page 13]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


5.2 Renewing an address lease

   Once an address lease is about to expire, the HIP host may want to
   renew it.

     HIP host                         Forwarding Agent

               Forwarding Agent Query
        ----------------------------------->

               Forwarding Agent Advice
        <-----------------------------------

   To renew a lease, the HIP host simply sends a FAQ specifying an
   existing lease, together with the desired extended lease time, and
   the FA replies with an FAA.

5.3 Readdressing and address status

     HIP host                         Another host

                       REA
        ----------------------------------->

                       AC
        <-----------------------------------

                       ACR
        ----------------------------------->

   When the host changes its IP address, gets more addresses or loses an
   address, it may want to tell this change to peer nodes.  The address
   changing host sends the readdress packet (REA) to the peer where it
   tells all available addresses. The address update packet is signed
   providing proof about the sending party.

   As the node receiving a REA packet cannot be sure if all the received
   addresses are valid even the signature is correct, it sends the
   Address Check (AC) packet to each of the new addresses received.  If
   the host receiving an AC message has sent the REA message that
   matches the received AC message, it MUST send an Address Check Reply
   (ACR) packet back to the peer for confirmation.  New addresses
   received in the REA packet are ready to be used after the ACR packet
   has been received.

   If a node receives an AC packet that does not match to any REA packet
   that is has sent out, it MUST drop the packet.  Such a packet may be
   an indication that someone else is on purpose or on mistake sending a



Nikander, et al.       Expires December 16, 2003               [Page 14]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   false address to its peer.


















































Nikander, et al.       Expires December 16, 2003               [Page 15]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


6. Protocol definition

   The location information update procedure in the HIP consists of the
   readdress packet telling the current set of addresses that the node
   is using, address check and address check replies. With this set of
   messages the IP addresses can be updated to the peer and the peer is
   able to verify that the addresses are valid.

   In addition to the actual address update, the HIP node is provided a
   possibility to get leased addresses from the FA. The FA can provide
   address(es) (and a range of SPIs) for the HIP node and the HIP node
   can use this towards other nodes. The FA thus forwards packets to the
   HIP node when it receives packets sent to the leased address.

6.1 Packet formats

6.1.1 REA - the HIP readdress packet

   A HIP readressing packet consists of one or more of REA_INFO
   payloads, followed by a signature (HIP_SIGNATURE) and a HMAC. The
   purpose of the signature is to allow middleboxes to verify the
   integrity of the packet.  The HMAC allows the peer node to verify the
   packet very fast.

   Intermediate systems that use the SPI will have to inspect ALL HIP
   packets for a REA packet.  This is a potential DoS attack against the
   Intermediate system, as the signature processing may be relatively
   expensive.  A further step against attack for the Intermediate
   systems is to implement ESP's replay protection of windowing the
   sequence number.  This requires the intermediate system to track ALL
   ESP packets to follow the Sequence Number.

   Optionally, the message may contain an ESP protected datagram. This
   datagram is processed as if it had arrived separately.  The purpose
   of allowing datagrams to be embedded inside the REA packet is to
   increase the efficiency of transmitting the first data packet, as
   only one IPv6 header is required.

   XXX Note (by Jari Arkko): I don't believe that this is a significant
   function. In fact, header compression on links is probably more
   efficient than this (the effect could be negative), and there might
   be some problems that this causes. I don't think it causes the same
   type of problems that piggybacking caused in Mobile IPv6, however,
   because the packet is always encrypted, hence it could not receive
   different treatment at the firewalls etc. But I'm not 100% sure that
   there are no other problems.





Nikander, et al.       Expires December 16, 2003               [Page 16]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


6.1.1.1 REA_INFO payload

   Note that the REA_INFO payload is a kind of "expanded" NES.

   XXX (Pekka): Note that I have, for the time being, removed the old
   ESP sequence number.  Firstly, it may be hard to acquire reliably in
   some implemtations (ours included).  Secondly, we now have a REA ID
   field, which is basically a REA sequence number.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Interface ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Current SPI in reverse direction              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Current SPI                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            New SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Keymaterial index       |             REA ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Nikander, et al.       Expires December 16, 2003               [Page 17]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


      Type               128
      Length             Length in octets, excluding Type and Length
                         fields
      Interface ID       Interface ID, as defined by the sending host
      Current SPI rev.   The current SPI used in the reverse direction
      Current SPI        The current SPI used for receiving ESP on this
                         interface
      New SPI            The new SPI used for receiving ESP on this
                         interface
      Keymaterial index  A bit index to the KEYMAT, where to pick up
                         the keying material for the new SA.
      REA ID             A 16-bit sequence number of nonce, used to
                         match the REA packet to the corresponding AC
                         packet.
      Address Lifetime   Address lifetime
      Reserved           Zero when sent, ignored when received
      Address            An IPv6 address or an IPv4-in-IPv6 format
                         IPv4 address
   [2]

   The Interface ID field identifies the (logical) interface that this
   packet applies to.  It is implicitly qualified by the Host Identity
   of the sending host.  The Interface ID groups a set of addresses to
   an interface.  The purpose of the Interface ID is to allow a
   knowledgeable peer to interact with the sender.  For example, the
   sender could be informing its peer that that an interface has both an
   IPv4 address and one or more IPv6 addresses.

   The sending host is free to introduce interface IDs at will. That is,
   if a received REA has a new interface ID, it means that all the old
   addresses, assigned to other interface IDs, are also supposed to
   still work, while the new addresses in the REA are supposed to be
   associated with a new interface.  On the other hand, if a received
   REA has an interface ID that the receiver already knows about, it
   would replace (all) the address(es) currently associated with the
   interface with the new one(s).

   If the SA is changed, and if the SA is not used at any other
   interface any more, it MUST NOT be deleted until all ESP packets with
   a lower Sequence Number have been received and processed, or a
   reasonable time has elapsed (to account for lost packets).

6.1.1.2 HMAC

   The HMAC SHA-1 is used to verify a received packet.

    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



Nikander, et al.       Expires December 16, 2003               [Page 18]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                           HMAC data                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type         65532
      Length       Length in octets, excluding Type and Length fields
      HMAC data    20 bytes of HMAC SHA-1 data


6.1.2 AC and ACR - the HIP Address Check and Address Check Reply

   The HIP Address Check (AC) and Address Check Reply (ACR) packets
   contain an AC_INFO payload, followed by a HMAC.

   In addition to acting as an address probe, the Address Check packet
   may also acts as an implicit acknowledgement to a REA packet.

6.1.2.1 AC_INFO payload

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             AC ID             |            REA ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTT timestamp                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type           129
      Length         Length in octets, excluding Type and Length
                     fields
      AC ID          A 16-bit sequence number of nonce, used to match
                     the AC packet to the corresponding ACR packet.
      REA ID         A 16-bit sequence number of nonce, used to match
                     the REA packet to the corresponding AC packet.
      RTT timestamp  A timestamp field which may be used for RTT
                     estimation
      Reserved       Zero when sent, ignored when received




Nikander, et al.       Expires December 16, 2003               [Page 19]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets

   The HIP FAQ, FAA and FAD packets contain an FA_INFO payload, and
   possibly other payloads.  If a forwarding agent sends an R1 in
   response to FAQ, the second FAQ must also contain an BIRTHDAY_COOKIE
   payload, containing the cookie response.  The FAA, and FAD packets
   MUST contain a HOST_ID or HOST_ID_FQDN payload. The FAA packet MAY
   contain a HOST_ID or HOST_ID_FQDN payload.

6.1.3.1 FA_INFO payload

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Request ID           |            Lease ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Lease duration                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reserved                 |   Addr type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 address:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Min SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Max SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv4 address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 address:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      IPv6 address (128 bits)                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type            130
      Length          Length in octets, excluding Type and Length
                      fields



Nikander, et al.       Expires December 16, 2003               [Page 20]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


      Request ID      A 16-bit sequence number of nonce, used to
                      match the FAQ packet to the corresponding
                      FAA/FAD packet.
      Lease ID        A 16-bit number XXX
      Lease duration  Duration of the lease
      Reserved        Zero when sent, ignored when received
      Addr type       Address type: 4 for IPv4 and 6 for IPv6 (TBD)


6.2 Requesting Address Leases

   To request address leases from the FA, the HIP node sends an FAQ
   packet to the FA.  The FAQ packet consists of the HIP header, FA_INFO
   payload and a HIP_SIGNATURE. If the FAQ packet is the second one sent
   from the HIP node to the FA, i.e. the FA responded to the first FAQ
   with an R1 packet, a BIRTHDAY_COOKIE payload containing the cookie
   response must be included in the packet.

6.3 Providing address Leases

   When the FA receives an FAQ packet from a HIP node, it may verify the
   signature in the packet. If the FA does not trust on the requesting
   node, it may generate an R1 packet containing a puzzle for the
   requesting HIP node.

   If the FA trusts to the requesting HIP node, or the HIP node
   responded to the R1 packet with a new FAQ with a solved puzzle, the
   FA can allocate address(es) and possibly SPIs for the requesting
   node. The FA_INFO payload may contain information about the requested
   addresses or the requested SPI ranges. If these requests can be met,
   the FA may allocate address(es) and possible SPIs for the requesting
   node.

   If the allocation request was accepted and a successfull reservation
   of data was performed, the FA responds to the requesting node with a
   FAA packet. The FAA consists of an FA_INFO payload describing the
   address(es) and possible SPIs that are reserved for the requesting
   node.

   However, if the FA was not able to allocate address(es), SPIs or the
   request was malformed, the FA responds with a FAD packet.

6.4 Sending REAs

   The HIP node may want to send address information to the peer node
   whenever there are updates in the addresses that are assigned to it.
   The leased addresses can be considered also to be possible addresses
   and they must be assigned to a logical interface.



Nikander, et al.       Expires December 16, 2003               [Page 21]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   The REA packet contains the HIP header, one or more REA_INFO,
   HIP_SIGNATURE and HMAC TLVs. The REA_INFO describes all the addresses
   that are associated with that particular interface identifier. If a
   previously associated address is not included in the list, the peer
   considers it as a lost address and removes it from the address
   associations.

6.5 Handling received REAs at end hosts

   When a HIP node receives a REA packet, it verifies the signature in
   it. If the packet was valid, it may initiate an address check
   procedure. The address check (AC) packet is sent to all addresses
   that were listed in the REA_INFO payload. The HIP node receiving the
   REA packet from a node that it trusts, may accept all addresses
   without making any address check for them. If ACs are sent, the
   addresses in the REA_INFO must not be used until corresponding ACR
   packet is received from the peer node.


































Nikander, et al.       Expires December 16, 2003               [Page 22]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


7. Policy considerations

   TBD
















































Nikander, et al.       Expires December 16, 2003               [Page 23]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


8. Security Considerations

   (Initial text by Jari Arkko): If not controlled in some manner,
   messaging related to address changes would create the following types
   of vulnerabilities:

      Revealing the contents of the (cleartext) communications

      Hijacking communications and man-in-the-middle attacks

      Denial of service for the involved nodes, by disabling their
      ability to receive the desired communications

      Denial of service for third parties, by redirecting a large amount
      of traffic to them

      Revealing the location of the nodes to other parties

   In HIP, communications are bound to the public keys of the end-points
   and not to IP addresses. The REA message is signed with the sender's
   private key, and hence it becomes impossible to hijack the
   communications of another node through the use of the REA message.
   Similarly, since only the node itself can sign messages to move its
   traffic flows to a new IP address, denial of service attacks through
   REA can not cause the traffic flows to be sent to an IP address that
   the node did not wish to use. Finally, In HIP all communications are
   encrypted with ESP, so a hijack attempt would also be unable to
   reveal the contents of the communications.

   Malicous nodes that use HIP can, however, try to cause a denial of
   service attack by establishing a high-volume traffic flow, such as a
   video stream, and then redirecting it to a victim.  However, the
   return routability check provides some assurance that the given
   address is willing to accept the new traffic.  Only attackers who are
   on the path between the peer and the new address could respond to the
   test.

8.1 Why does the foreign agent may require a puzzle solution?

   In Section 5.1 it is stated that a foreign agent may pass a puzzle,
   in an R1, to the HIP host if it does not trust the HIP host.  This
   protects the foreing agent from CPU consuming DoS attacks.  If this
   protection were not used, an attacker could send a stream of bogus
   FAQ packets to the foreign agent, making it to spend all of its CPU
   to verify signatures that might be full garbage.

8.2 Attacker masquerading as a FA




Nikander, et al.       Expires December 16, 2003               [Page 24]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   The ability for an attacker to masquerade as a forwarding agent
   depends on how the HIP host locates forwarding agents.  That, in
   turn, falls beyond the scope of this document.  However, if the HIP
   host accepts services from unknown or untrusted forwarding agents, it
   is taking a risk of getting a black hole or eavesdropped address.
   The resulting attack is usually not very serious, though, since all
   actual data traffic is protected with ESP, and the HIP packets are
   signed.  Thus, the worst an untrustworthy forwarding agent can do is
   to blackhole the packets.

8.3 Location privacy

   TBD






































Nikander, et al.       Expires December 16, 2003               [Page 25]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


9. IANA Considerations


















































Nikander, et al.       Expires December 16, 2003               [Page 26]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


10. Acknowledgments

   Thanks to Kimmo Nieminen.
















































Nikander, et al.       Expires December 16, 2003               [Page 27]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Normative references

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

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [3]  Nikander, P. and R. Moskowitz, "Host Identity Protocol",
        draft-moskowitz-hip-06 (work in progress), May 2003.

   [4]  Moskowitz, R., "Host Identity Protocol Architecture",
        draft-moskowitz-hip-arch-03 (work in progress), May 2003.






































Nikander, et al.       Expires December 16, 2003               [Page 28]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Informative references

   [5]  Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998.

   [6]  Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security,
        Mobility, and Multi-Homing in  a HIP Way", Network and
        Distributed Systems Security Symposium (NDSS'03),  February 6-7,
        2003,  San Diego, CA, pages 87-99,  Internet Society, February
        2003.

   [7]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
        Security Considerations", draft-iab-sec-cons-03 (work in
        progress), February 2003.

   [8]  Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E.
        Nordmark, "Mobile IP version 6 Route Optimization Security
        Design Background", draft-nikander-mobileip-v6-ro-sec-00 (work
        in progress), April 2003.


Authors' Addresses

   Pekka Nikander
   Ericsson Research Nomadic Lab

   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: pekka.nikander@nomadiclab.com


   Jari Arkko
   Ericsson Research Nomadic Lab

   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: jari.arkko@nomadiclab.com











Nikander, et al.       Expires December 16, 2003               [Page 29]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   Petri Jokela
   Ericsson Research Nomadic Lab

   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: petri.jokela@nomadiclab.com











































Nikander, et al.       Expires December 16, 2003               [Page 30]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Appendix A. Site multi-homing

   A site, connected to multiple transit providers, is considered to be
   multi-homed. There is a possibility to send traffic using any of the
   transit provider networks. A node, connected to a multi-homed site,
   can experience this multi-homing from the received IP addresses.

A.1 A host connected to a multi-homed site

   When a node connects to a multi-homed network, it may receive
   multiple IP addresses on this connected interface. These addresses
   can be either local IP addresses (behind a NAT) or public addresses.

   A traditional node setting up a connection, selects one of the
   available local addresses for this particular connection. This
   address cannot be changed for the existing connection.

   A HIP node experiencing similar site multi-homing is not limited to
   the one source address selected during the connection set up. The
   node has multiple IP addresses on one interface and the mapping
   between the Host Identity - Interface - IP addresses is a mapping
   from one to one to many. The used IP address can be changed while the
   connection exists.

   When configured multiple addresses to one interface, the node can
   update this list of addresses to peer nodes. Thus, the different
   transit providers can be used according to policies defined in the
   node. The policies can be defined locally or they can be received by
   other methods. (see policies, TBD)

A.2 Transit providers with NATs

   A transit provider may have NAT boxes in the network.  The HIP node
   connected to a site that is further connected to a transit provider
   using NATs, must get the knowledge about the NAT box between itself
   and the peer node. The address that the HIP node sends to the peer
   node must be a public one, thus NATted address is not valid.

   The NAT box on the path must support address (and SPI) leasing for
   the HIP node. When the HIP node finds out that there is a NAT box,
   the host must get a leased address (or a set of addresses) from the
   NAT. These addresses are routable at the other side of the NAT. They
   still need not to be globally routable as there may be another NAT
   box on the path.







Nikander, et al.       Expires December 16, 2003               [Page 31]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Appendix B. Implementation experiences


















































Nikander, et al.       Expires December 16, 2003               [Page 32]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


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 assignees.

   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



Nikander, et al.       Expires December 16, 2003               [Page 33]


Internet-Draft       HIP Mobility and Multi-Homing             June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Nikander, et al.       Expires December 16, 2003               [Page 34]


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