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]