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 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]