PANA WG                                                Stefano M. Faccin
INTERNET-DRAFT                                                 Franck Le
Date: February 2002                                Nokia Research Center
Expires: August 2002




         An efficient method to dicover an agent in the network
                 <draft-le-pana-agent-discovery-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.


Abstract

   In many protocols, such as IP Paging [1] and PANA [2], there is the
   need for the user to discover an agent in the network: In IP Paging,
   the user first needs to discover the address of the Paging agent in
   order to perform Paging registration, Paging Area Update and other
   paging procedures. In the same way, in PANA, the user first needs to
   discover the PANA Authentication Agent to know where to send its
   credential.  This document describes an efficient method for a user
   to discover one, or many agents in the network.






Faccin, Le                                                      [Page i]





INTERNET-DRAFT               Agent discovery               February 2002


                           Table of Contents


Status of This Memo  . . . . . . . . . . . . . . . . . . . . . . . .   i

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   i

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   1

2. Motivations for a new discovery mechanism . . . . . . . . . . . .   1

3. Mechanism Overview  . . . . . . . . . . . . . . . . . . . . . . .   2

4. Advantages/Disadvantages of the described mechanism . . . . . . .   4
   4.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.2. Disadvantages  . . . . . . . . . . . . . . . . . . . . . . .   4

5. Message extensions  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.1. ICMPv4 Router Advertisement Extension for Agent
   Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.2. ICMPv6 Router Advertisement Extension for Agent
   Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5

6. Security considerations . . . . . . . . . . . . . . . . . . . . .   6

7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . .   6

8. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6

9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8

10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .   9



















Faccin, Le                                                     [Page ii]




INTERNET-DRAFT               Agent discovery               February 2002





















































Faccin, Le                                                    [Page iii]





INTERNET-DRAFT               Agent discovery               February 2002


1.  Introduction

   This document addresses the need for a user to discover an agent in
   the network.  Several methods are known and could be used to solve
   that issue, but all the current mechanisms have drawbacks. The first
   section will describe them and provide more information about the
   motivation for a new discovery mechanism.

   This internet-draft describes an efficient method for a user to
   discover an agent in the network: In order to allow a mobile node to
   send messages directly to agents in the network, this document
   suggests to extend the router advertisement messages broadcast by the
   access routers to carry an identifier for the agent. The user will
   receive such identifier and compute the IP address to be used to send
   messages to the agent according to the rules described in the
   following sections.

   The method described in this document can efficiently allow the
   discovery of both many different agents of different types (IP Paging
   agent, PAA, etc.) and many different agents for the same type (PAA1,
   PAA2, etc.) for more robustness and reliability.


2.  Motivations for a new discovery mechanism

   Many mechamisms such as DHCP, DNS, LDAP, etc. have already been
   defined and can be used to discover an agent; however these solutions
   require exchange of additional messages between the MN and entities
   in the network. For this reason, the mechanisms mentioned above may
   not be the most suitable solutions for wireless networks, in
   particular for networks with limited bandwidth availability such as
   cellular networks.

   The use of anycast address is another possibility: In such cases, the
   user uses a well-known anycast address to send messages to a given
   agent (e.g. the one required by PANA). However, the security of
   anycast is not completely specified and in addition since the agent
   in consideration will most probably be stateful (PANA and user share
   a LSA, Paging agent stores some location information about the user,
   etc.), as described in RFC 1546 [3], anycast address SHOULD NOT be
   used.

   Anycast as used in the Dynamic Home Agent discovery of Mobile IPv6
   (section 10.8 [4]) solves part of the issues but requires additional
   round trip messages and have security issues.

   Anycast finally has another drawback since it does not allow all the
   benefits described in section 4.1



Faccin, Le                                                      [Page 1]





INTERNET-DRAFT               Agent discovery               February 2002


   Advertising the IP address of the agent in the Router Advertisments
   could be another alternative and has been proposed but the IPv6
   addresses are long and several IP addresses may need to be advertised
   (PANA Authentication Agent one, Paging Agent one, etc.) This may
   therefore not be acceptable since it requires a longer Router
   Advertisment that in particular is an issue for wireless links.

   In work items of many working groups, e.g. IP Paging in Seamoby,
   there is the requirement that an agent MUST be able to serve multiple
   Access Routers. In case of IP Paging, a Paging area identifier needs
   therefore to be broadcasted and it is currently suggested to use
   Router Advertisements for the purpose. Considering this type of
   assumptions, if mechanisms such as DHCP, DNS, LDAP, etc. were used
   the MN first would have to receive a router advertisement, then
   discover the agent through such mechanisms. This would require
   additional signaling between the MN and the networks: in addition to
   the extra bytes sent over the access link, the agent discovery
   introduces delay in the procedure.  The method proposed in this
   document could be seen as an optimization of the scenario described
   above. In fact, the identifier of the agent advertised (the suffix
   identifier) also enables the MN to derive the IP address of the agent
   thus saving the need for extra messages.


3.  Mechanism Overview

   When a user enters a new subnet, it needs to get some information
   related to the subnet that are needed to obtain connectivity. The
   Router Advertisement (RtrAdv) sent by access routers (AR) currently
   broadcast the network prefix(es) to be used for the creation of care-
   of address in the AR subnet besides other information needed for the
   user to get connectivity.

   If mechanisms such as IP Paging ([1]) or such as PANA ([2]) are
   adopted, the user may need to send messages to an entity in the
   network that is not known a priori to the user.

   In order to allow a user to send messages directly to agents in the
   network, this document suggests to extend the router advertisement
   messages broadcast by the access routers to carry an identifier for
   the agent. The mobile node will receive such identifier and compute
   the IP address to be used to send messages to the agent according to
   the following rules:

      The user takes the identifier received in the Router Advertisment
      as suffix for the IP address of the agent, and the most
      significant bits (MSBs) of the address are derived from the prefix
      the access router broadcasts in the Router Advertisment. As an



Faccin, Le                                                      [Page 2]





INTERNET-DRAFT               Agent discovery               February 2002


      example (using IPv4), if the advertised network prefix is
      172.28.34.0, and the advertised suffix is 75.36, the user will
      know the IP address of the agent is 172.28.75.36. The same applies
      for IPv6.


      Network
      Prefix:    +---+
      172.28.1.0 |AR1|
                 +---+\
                       \
                        \
                       +---------------------+
      RtrAdv           |                     |
      +----+   +---+   |                     |
      |User|   |AR2|---|    IP Network       |
      +----+   +---+   |                     |
                       |                     |
                       +---------------------+
                      /                     \
      Network        /                       \
      Prefix:    +---+                     +-----+
      172.28.3.0 |AR3|                     |Agent|
                 +---+                     +-----+
                                          172.28.12.6

      1) Router advertisement from AR2
          - Network Prefix: 172.28.2.0
          - Agent Suffix: 12.6
      2) User sends requests to 172.28.12.6


   The value of the identifier is configured in the AR by the network
   according to the selection of which agent is serving the users in the
   subnet of the AR. In order to allow for the agent to be located in
   the network elsewhere than one of the AR links (and thus to have one
   agent serving the MNs in multiple Ars), the identifier is set to a
   value that allows the MN to take the prefix advertised by the AR
   (e.g. 172.28) and the identifier (e.g. 30.75.36) and create the agent
   IP address (in the example 172.30.75.36) that is not on one of the
   links of the AR but still in the same network of the AR.

   Since the address created by the user is the actual IP address of the
   agent, when the access router receives a packet destined to the
   address of the agent, the AR simply routes the packet to the
   destination address.





Faccin, Le                                                      [Page 3]





INTERNET-DRAFT               Agent discovery               February 2002


4.  Advantages/Disadvantages of the described mechanism


4.1.  Advantages

   *  The proposed solution does not require any request/response
      exchange to discover the IP address of the agent.

   *  The security issues present in other proposals (e.g. anycast
      address) do not apply to the proposed solution.

   *  In this method, the suffix could also be used to identify the
      agent and thus, no additional identifier (such as Paging area or
      PAA Identifier) needs to be broadcasted.

   *  Proposals for support of mobility such as HMIP [7] suggest
      broadcasting all the IP addresses of the MAP entities to the MNs
      using Router Advertisements. The mechanisms proposed in this draft
      would benefit such proposals by allowing to shorten the router
      advertisement messages, since only the suffix and not the full IP
      addresses of the agents needs to be sent in the router
      advertisement.


4.2.  Disadvantages


   *  This method requires additional information (minimal) to be sent
      over the Router Advertisement.


5.  Message extensions


5.1.  ICMPv4 Router Advertisement Extension for Agent Discovery

   The following extension is suggested for use with ICMPv4 [5]:

       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     |         Sub options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
         Agent Identifier (TBD)





Faccin, Le                                                      [Page 4]





INTERNET-DRAFT               Agent discovery               February 2002


      Length
         This value equals the number of octets of this extension,
         excluding the Type and Length fields, i.e. only the length of
         the sub options field.

      Sub options

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Sub Type    |    Length     |         Identifier ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Sub Type

            1 PAA

            2 IP Paging

         Length
            Lentgh in octets of the identifier

         Identifier
            Value of the identifier


5.2.  ICMPv6 Router Advertisement Extension for Agent Discovery

   The following extension is suggested for use with ICMPv6 [6]:

       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     |         Sub options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
         Agent Identifier (TBD)

      Length
         This value equals the number of octets of this extension,
         excluding the Type and Length fields, i.e. only the length of
         the sub options field.

      Sub options






Faccin, Le                                                      [Page 5]





INTERNET-DRAFT               Agent discovery               February 2002


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Sub Type    |    Length     |         Identifier ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Sub Type

            1 PAA

            2 IP Paging

         Length
            Lentgh in octets of the identifier

         Identifier
            Value of the identifier


6.  Security considerations

   This document defines a mechanism for a user to discover an entity in
   the network but does not introduce any security threats to the
   current existing possible attacks (such as the ones related to
   unauthenticated neighbor discovery mechanisms).

7.  IANA considerations

   This document specifies one new ICMPv4 Router Advertisement Extension
   Type, and two sub types for this extension, that all need to receive
   values from the IANA.

   This document also requires IANA to assign values for the new ICMPv6
   Router Advertisement Extension Type defined in section 4.2 and the
   two sub type of this extension.

8.  Conclusion

   Many agent discovery mechanisms have already been defined and
   currently exist, but depending on the requirements, and the
   deployement characteristics, they may not be the optimal ones.

   This document describes an alternative solution which can be adopted
   more particularly when the agent MUST be able to serve multiple AR,
   and an Id needs to be broadcasted such as in IP Paging, PANA or to
   optimize protocols such as HMIP.





Faccin, Le                                                      [Page 6]





INTERNET-DRAFT               Agent discovery               February 2002


   The main advantage of the proposed mechanism relies in the fact that
   it requires minimal information to be advertised and avoid any
   request/reponse exchange message between the user and the network.
















































Faccin, Le                                                      [Page 7]





INTERNET-DRAFT               Agent discovery               February 2002


9.  References

   [1]       J. Kempf et al., Requirements and Functional Architecture
             for an IP Host Alerting Protocol, RFC 3154, Internet
             Engineering Task Force, August 2001

   [2]       Y. Ohba et al., PANA Usage Scenarios, Internet draft,
             Internet Engineering Task Force, January 2002

   [3]       C. Partridge et al., Host Anycasting Service, RFC 1546,
             Internet Engineering Task Force, November 1993

   [4]       David B. Johnson et Charles E. Perkins, Mobility Support in
             IPv6, Internet draft, Internet Engineering Task Force, July
             2001

   [5]       S. Deering (editor), ICMP Router Discovery Messages, RFC
             1256, Internet Engineering Task Force, September 1991

   [6]       Narten, T., Nordmark, E., Simpson, W.; Neighbor Discovery
             for IP Version 6, RFC 2461, Internet Engineering Task
             Force, December 1998.

   [7]       Hesham Soliman et al., Hierarchical MIPv6 mobility
             management (HMIPv6), Internet draft, Internet Engineering
             Task Force, July 2001

   [8]       Jun-ichiro itojun Hagino et K. Ettikan, An analysis of IPv6
             anycast, Internet draft, Internet Engineering Task Force,
             July 2001





















Faccin, Le                                                      [Page 8]





INTERNET-DRAFT               Agent discovery               February 2002


10.  Authors' Addresses


   Stefano M. Faccin
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972 894-4994
   E-mail: stefano.faccin@nokia.com



   Franck Le
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972 374-1256
   E-mail: franck.le@nokia.com





























Faccin, Le                                                      [Page 9]