doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3154.txt b/doc/rfc/rfc3154.txt
new file mode 100644
index 0000000..f9707b3
--- /dev/null
+++ b/doc/rfc/rfc3154.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                           J. Kempf
+Request for Comments: 3154                               C. Castelluccia
+Category: Informational                                         P. Mutaf
+                                                             N. Nakajima
+                                                                 Y. Ohba
+                                                               R. Ramjee
+                                                            Y. Saifullah
+                                                             B. Sarikaya
+                                                                   X. Xu
+                                                             August 2001
+
+
+              Requirements and Functional Architecture for
+                     an IP Host Alerting Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document develops an architecture and a set of requirements
+   needed to support alerting of hosts that are in dormant mode.  The
+   architecture and requirements are designed to guide development of an
+   IP protocol for alerting dormant IP mobile hosts, commonly called
+   paging.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al.                Informational                      [Page 1]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+Table of Contents
+
+   1. Introduction ...................................................3
+   2. Terminology ....................................................3
+   3. Security Considerations ........................................3
+    3.1.   DoS Amplification .........................................3
+    3.2.   Queue Overflow ............................................4
+    3.3.   Selective DoS against Hosts ...............................4
+   4. Requirements ...................................................5
+    4.1.   Impact on Power Consumption ...............................5
+    4.2.   Scalability ...............................................5
+    4.3.   Control of Broadcast/Multicast/Anycast ....................5
+    4.4.   Efficient Signaling for Inactive Mode .....................6
+    4.5.   No Routers ................................................6
+    4.6.   Multiple Dormant Modes ....................................6
+    4.7.   Independence of Mobility Protocol .........................6
+    4.8.   Support for Existing Mobility Protocols ...................6
+    4.9.   Dormant Mode Termination ..................................6
+    4.10.  Network Updates ...........................................6
+    4.11.  Efficient Utilization of L2 ...............................7
+    4.12.  Orthogonality of Paging Area and Subnets ..................7
+    4.13.  Future L3 Paging Support ..................................7
+    4.14.  Robustness Against Failure of Network Elements ............7
+    4.15.  Reliability of Packet Delivery ............................7
+    4.16.  Robustness Against Message Loss ...........................7
+    4.17.  Flexibility of Administration .............................7
+    4.18.  Flexibility of Paging Area Design .........................8
+    4.19.  Availability of Security Support ..........................8
+    4.20.  Authentication of Paging Location Registration ............8
+    4.21.  Authentication of Paging Area Information .................8
+    4.22.  Authentication of Paging Messages .........................8
+    4.23.  Paging Volume .............................................8
+    4.24.  Parsimonious Security Messaging ...........................8
+    4.25.  Noninterference with Host's Security Policy ...............8
+    4.26.  Noninterference with End-to-end Security ..................9
+    4.27.  Detection of Bogus Correspondent Nodes ....................9
+   5. Functional Architecture ........................................9
+    5.1.   Functional Entities .......................................9
+    5.2.   Interfaces ...............................................10
+    5.3.   Functional Architecture Diagram ..........................12
+   6. Acknowledgements ..............................................12
+   7. References ....................................................13
+   8. Authors' Addresses ............................................13
+   9. Full Copyright Statement ......................................16
+
+
+
+
+
+
+
+Kempf, et al.                Informational                      [Page 2]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+1.   Introduction
+
+   In [1], a problem statement was developed to explain why an IP
+   protocol was desirable for alerting hosts in dormant mode, commonly
+   called paging.  In this document, a set of requirements is developed
+   for guiding the development of an IP paging protocol.  Based on the
+   requirements, an architecture is developed to represent the
+   functional relationships between logical functional entities
+   involved.
+
+2.   Terminology
+
+   Please see [1] for definition of terms used in describing paging.  In
+   addition, this document defines the following terms:
+
+      Wide Casting - Either broadcasting or multicasting.
+
+         Inactive Mode - The host is no longer listening for any
+         packets, not even periodically, and not sending packets.  The
+         host may be in a powered off state, it may have shut down all
+         interfaces to drastically conserve power, or it may be out of
+         range of a radio access point.
+
+3.   Security Considerations
+
+   An IP paging protocol introduces new security issues.  In this
+   section, security issues with relevance to formulating requirements
+   for an IP paging protocol are discussed.
+
+3.1. DoS Amplification
+
+   A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack generally
+   consists of flooding a target network with bogus IP packets in order
+   to cause degraded network performance at victim nodes and/or routers.
+   Performance can be degraded to the point that the network cannot be
+   used.  Currently, there is no preventive solution against these
+   attacks, and the impacts can be very important.
+
+   In general a DoS attacker profits from a so-called "amplifier" in
+   order to increase the damage caused by his attack.  Paging can serve
+   for an attacker as a DoS amplifier.
+
+   An attacker (a malicious correspondent node) can send large numbers
+   of packets pretending to be sent from different (bogus) correspondent
+   nodes and destined for large numbers of hosts in inactive and dormant
+   modes.  This attack, in turn, will be amplified by the paging agent
+   which wide casts paging messages over a paging area, resulting in
+   more than one networks being flooded.  Clearly, the damage can be
+
+
+
+Kempf, et al.                Informational                      [Page 3]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+   more important in wireless networks that already suffer from scarce
+   radio bandwidth.
+
+   Alternatively, an attacker can sort out a host which:
+
+      1. sends periodic messages declaring that it is in dormant mode,
+
+      2. never replies to paging requests.
+
+   Such a node may be the attacker's node itself, or a second node
+   participating in the attack.
+
+   That node is never in inactive mode because of behavior 1 above.  In
+   this case, the attacker can send large numbers of packets destined
+   for that host which periodically declares that it is in dormant mode
+   but never replies to paging messages.  The impact will be the same as
+   above however in this case the attack will be amplified indefinitely.
+
+3.2. Queue Overflow
+
+   For reliability reasons, the paging protocol may need to make
+   provisions for a paging queue where a paging request is buffered
+   until the requested host replies by sending a location registration
+   message.
+
+   An attacker can exploit that by sending large numbers of packets
+   having different (bogus) correspondent node addresses and destined
+   for one or more inactive hosts.  These packets will be buffered in
+   the paging queue.  However, since the hosts are inactive, the paging
+   queue may quickly overflow, blocking the incoming traffic from
+   legitimate correspondent nodes.  As a result, all registered dormant
+   hosts may be inaccessible for a while.  The attacker can re-launch
+   the attack in a continuous fashion.
+
+   An attacker together with a bogus host that fails to respond to pages
+   can overflow the buffering provided to hold packets for dormant mode
+   hosts.  If the attacker keeps sending packets while the dormant mode
+   host fails to reply, the buffer can overflow.
+
+3.3. Selective DoS against Hosts
+
+   The following vulnerabilities already exist in the absence of IP
+   paging.  However, they are included here since they can affect the
+   correct operation of the IP paging protocol.
+
+   These vulnerabilities can be exploited by an attacker in order to
+   eliminate a particular host.  This, in turn, can be used by an
+   attacker as a stepping stone to launch other attacks.
+
+
+
+Kempf, et al.                Informational                      [Page 4]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+   Forced Battery Consumption
+
+   An attacker can frequently send packets to a host in order to prevent
+   that host from switching to dormant mode.  As a result the host may
+   quickly run out of battery.
+
+   Bogus Paging Areas
+
+   An attacker can periodically emit malicious packets in order to
+   confuse one or more hosts about their actual locations.  Currently,
+   there is no efficient way to authenticate such packets.
+
+   In the case of IP paging, these packets may also contain bogus paging
+   area information.  Upon receipt of such a packet, a host may move and
+   send a location registration message pointing to a non-existing or
+   wrong paging area.  The functional entities of the IP paging protocol
+   may loose contact with the host.
+
+   More importantly, this attack can serve for sorting out a host which
+   shows the behaviors 1 and 2 described in Section 3.1.
+
+   Bogus Paging Agents
+
+   An attacker can wide cast fake paging messages pretending to be sent
+   by a paging agent.  The impacts will be similar to the ones described
+   in Sections 4.1 and 4.3.1.  However, depending on how the IP paging
+   protocol is designed, additional harm may be caused.
+
+4.   Requirements
+
+   The following requirements are identified for the IP paging protocol.
+
+4.1. Impact on Power Consumption
+
+   The IP paging protocol MUST minimize impact on the Host's dormant
+   mode operation, in order to minimize excessive power drain.
+
+4.2. Scalability
+
+   The IP paging protocol MUST be scalable to millions of Hosts.
+
+4.3. Control of Broadcast/Multicast/Anycast
+
+   The protocol SHOULD provide a filter mechanism to allow a Host prior
+   to entering dormant mode to filter which broadcast/multicast/anycast
+   packets active a page.  This prevents the Host from awakening out of
+   dormant mode for all broadcast/multicast/anycast traffic.
+
+
+
+
+Kempf, et al.                Informational                      [Page 5]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+4.4. Efficient Signaling for Inactive Mode
+
+   The IP paging protocol SHOULD provide a mechanism for the Tracking
+   Agent to determine whether the Host is in inactive mode, to avoid
+   paging when a host is completely unreachable.
+
+4.5. No Routers
+
+   Since the basic issues involved in handling mobile routers are not
+   well understood and since mobile routers have not exhibited a
+   requirement for paging, the IP paging protocol MAY NOT support
+   routers.  However, the IP paging protocol MAY support a router acting
+   as a Host.
+
+4.6. Multiple Dormant Modes
+
+   Recognizing that there are multiple possible dormant modes on the
+   Host, the IP paging protocol MUST work with different implementations
+   of dormant mode on the Host.
+
+4.7. Independence of Mobility Protocol
+
+   Recognizing that IETF may support multiple mobility protocols in the
+   future and that paging may be of value to hosts that do not support a
+   mobility protocol, the IP paging protocol MUST be designed so there
+   is no dependence on the underlying mobility protocol or on any
+   mobility protocol at all.  The protocol SHOULD specify and provide
+   support for a mobility protocol, if the Host supports one.
+
+4.8. Support for Existing Mobility Protocols
+
+   The IP paging protocol MUST specify the binding to the existing IP
+   mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3].  The
+   IP paging protocol SHOULD make use of existing registration support.
+
+4.9. Dormant Mode Termination
+
+   Upon receipt of a page (either with or without an accompanying L3
+   packet), the Host MUST execute the steps in its mobility protocol to
+   re-establish a routable L3 link with the Internet.
+
+4.10.   Network Updates
+
+   Recognizing that locating a dormant mode mobile requires the network
+   to have a rough idea of where the Host is located, the IP paging
+   protocol SHOULD provide the network a way for the Paging Agent to
+   inform a dormant mode Host what paging area it is in and the IP
+   paging protocol SHOULD provide a means whereby the Host can inform
+
+
+
+Kempf, et al.                Informational                      [Page 6]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+   the Target Agent when it changes paging area.  The IP paging protocol
+   MAY additionally provide a way for the Host to inform the Tracking
+   Agent what paging area it is in at some indeterminate point prior to
+   entering dormant mode.
+
+4.11.   Efficient Utilization of L2
+
+   Recognizing that many existing wireless link protocols support paging
+   at L2 and that these protocols are often intimately tied into the
+   Host's dormant mode support, the IP paging protocol SHOULD provide
+   support to efficiently utilize an L2 paging protocol if available.
+
+4.12.   Orthogonality of Paging Area and Subnets
+
+   The IP paging protocol MUST allow an arbitrary mapping between
+   subnets and paging areas.
+
+4.13.   Future L3 Paging Support
+
+   Recognizing that future dormant mode and wireless link protocols may
+   be designed that more efficiently utilize IP, the IP paging protocol
+   SHOULD NOT require L2 support for paging.
+
+4.14.   Robustness Against Failure of Network Elements
+
+   The IP paging protocol MUST be designed to be robust with respect to
+   failure of network elements involved in the protocol.  The self-
+   healing characteristics SHOULD NOT be any worse than existing routing
+   protocols.
+
+4.15.   Reliability of Packet Delivery
+
+   The IP paging protocol MUST be designed so that packet delivery is
+   reliable to a high degree of probability.  This does not necessarily
+   mean that a reliable transport protocol is required.
+
+4.16.   Robustness Against Message Loss
+
+   The IP paging protocol MUST be designed to be robust with respect to
+   loss of messages.
+
+4.17.   Flexibility of Administration
+
+   The IP paging protocol SHOULD provide a way to flexibly auto-
+   configure Paging Agents to reduce the amount of administration
+   necessary in maintaining a wireless network with paging.
+
+
+
+
+
+Kempf, et al.                Informational                      [Page 7]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+4.18.   Flexibility of Paging Area Design
+
+   The IP paging protocol MUST be flexible in the support of different
+   types of paging areas.  Examples are fixed paging areas, where a
+   fixed set of bases stations belong to the paging area for all Hosts,
+   and customized paging areas, where the set of base stations is
+   customized for each Host.
+
+4.19.   Availability of Security Support
+
+   The IP paging protocol MUST have available authentication and
+   encryption functionality at least equivalent to that provided by
+   IPSEC [5].
+
+4.20.   Authentication of Paging Location Registration
+
+   The IP paging protocol MUST provide mutually authenticated paging
+   location registration to insulate against replay attacks and to avoid
+   the danger of malicious nodes registering for paging.
+
+4.21.   Authentication of Paging Area Information
+
+   The IP paging protocol MUST provide a mechanism for authenticating
+   paging area information distributed by the Paging Agent.
+
+4.22.   Authentication of Paging Messages
+
+   The IP paging protocol MUST provide a mechanism for authenticating L3
+   paging messages sent by the Paging Agent to dormant mode Hosts. The
+   protocol MUST support the use of L2 security mechanisms so
+   implementations that take advantage of L2 paging can also be secured.
+
+4.23.   Paging Volume
+
+   The IP paging protocol SHOULD be able to handle large numbers of
+   paging requests without denying access to any legitimate Host nor
+   degrading its performance.
+
+4.24.   Parsimonious Security Messaging
+
+   The security of the IP paging protocol SHOULD NOT call for additional
+   power consumption while the Host is in dormant mode, nor require
+   excessive message exchanges.
+
+4.25.   Noninterference with Host's Security Policy
+
+   The IP paging protocol MUST NOT impose any limitations on a Host's
+   security policies.
+
+
+
+Kempf, et al.                Informational                      [Page 8]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+4.26.   Noninterference with End-to-end Security
+
+   The IP paging protocol MUST NOT impose any limitations on a Host's
+   ability to conduct end-to-end security.
+
+4.27.   Detection of Bogus Correspondent Nodes
+
+   The IP paging protocol SHOULD make provisions for detecting and
+   ignoring bogus correspondent nodes prior to paging messages being
+   wide cast on behalf of the correspondent node.
+
+5.   Functional Architecture
+
+   In this section, a functional architecture is developed that
+   describes the logical functional entities involved in IP paging and
+   the interfaces between them.  Please note that the logical
+   architecture makes absolutely no commitment to any physical
+   implementation of these functional entities whatsoever.  A physical
+   implementation may merge particular functional entities.  For
+   example, the Paging Agent, Tracking Agent, and Dormant Monitoring
+   Agent may all be merged into one in a particular physical
+   implementation.  The purpose of the functional architecture is to
+   identify the relevant system interfaces upon which protocol
+   development may be required, but not to mandate that protocol
+   development will be required on all.
+
+5.1. Functional Entities
+
+   The functional architecture contains the following elements:
+
+      Host - The Host (H) is a standard IP host in the sense of [4]. The
+      Host may be connected to a wired IP backbone through a wireless
+      link over which IP datagrams are exchanged (mobile usage pattern),
+      or it may  be connected directly to a wired IP network, either
+      intermittently (nomadic usage pattern) or constantly (wired usage
+      pattern).  The Host may support some type of IP mobility protocol
+      (for example, mobile IP [2] [3]).  The Host is capable of entering
+      dormant mode in order to save power (see [1] for a detailed
+      discussion of dormant mode).  The Host also supports a protocol
+      allowing the network to awaken it from dormant mode if a packet
+      arrives.  This protocol may be a specialized L2 paging channel or
+      it may be a time-slotted dormant mode in which the Host
+      periodically wakes up and listens to L2 for IP traffic, the
+      details of the L2 implementation are not important.  A dormant
+      Host is also responsible for determining when its paging area has
+      changed and for responding to changes in paging area by directly
+
+
+
+
+
+Kempf, et al.                Informational                      [Page 9]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+      or indirectly informing the Tracking Agent about its location.
+      Since routers are presumed not to require dormant mode support, a
+      Host is never a router.
+
+      Paging Agent - The Paging Agent is responsible for alerting the
+      Host when a packet arrives and the Host is in dormant mode.
+      Alerting of the Host proceeds through a protocol that is peculiar
+      to the L2 link and to the Host's dormant mode implementation,
+      though it may involve IP if supported by the L2.  Additionally,
+      the Paging Agent maintains paging areas by periodically wide
+      casting information over the Host's link to identify the paging
+      area.  The paging area information may be wide cast at L2 or it
+      may also involve IP.  Each paging area is served by a unique
+      Paging Agent.
+
+      Tracking Agent - The Tracking Agent is responsible for tracking a
+      Host's location while it is in dormant mode or active mode, and
+      for determining when Host enters inactive mode.  It receives
+      updates from a dormant Host when the Host changes paging area.
+      When a packet arrives for the Host at the Dormant Monitoring
+      Agent, the Tracking Agent is responsible for notifying the Dormant
+      Monitoring Agent, upon request, what Paging Agent is in the Host's
+      last reported paging area.  There is a one to one mapping between
+      a Host and a Tracking Agent.
+
+      Dormant Monitoring Agent - The Dormant Monitoring Agent detects
+      the delivery of packets to a Host that is in Dormant Mode (and
+      thus does not have an active L2 connection to the Internet).  It
+      is the responsibility of the Dormant Monitoring Agent to query the
+      Tracking Agent for the last known Paging Agent for the Host, and
+      inform the Paging Agent to page the Host.  Once the Paging Agent
+      has reported that a routable connection to the Internet exists to
+      the Host, the Dormant Monitoring Agent arranges for delivery of
+      the packet to the Host.  In addition, the Host or its Tracking
+      Agent may select a Dormant Monitoring Agent for a Host when the
+      Host enters dormant mode, and periodically as the Host changes
+      paging area.
+
+5.2. Interfaces
+
+   The functional architecture generates the following list of
+   interfaces.  Note that the interfaces between functional entities
+   that are combined into a single network element will require no
+   protocol development.
+
+      Host - Paging Agent (H-PA) - The H-PA interface supports the
+      following types of traffic:
+
+
+
+
+Kempf, et al.                Informational                     [Page 10]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+         -  Wide casting of paging area information from the Paging
+            Agent.
+
+         -  The Paging Agent alerting the Host when informed by the
+            Dormant Monitoring Agent that a packet has arrived.
+
+      Host - Tracking Agent (H-TA) - The H-TA interface supports the
+      following types of traffic:
+
+         -  The Host informing the Tracking Agent when it has changed
+            paging area, and, optionally, prior to entering dormant
+            mode, in what paging area it is located.
+
+         -  Optionally, the Host informs the Tracking Agent at a planned
+            transition to inactive mode.
+
+      Dormant Monitoring Agent - Tracking Agent (DMA-TA) - The DMA-TA
+      interface supports the following types of traffic:
+
+         -  A report from the Dormant Monitoring Agent to the Tracking
+            Agent that a packet has arrived for a dormant Host for which
+            no route is available.
+
+         -  A report from the Tracking Agent to the Dormant Monitoring
+            Agent giving the Paging Agent to contact in order to page
+            the Host.
+
+         -  A report from the Tracking Agent to the Dormant Monitoring
+            Agent that a Host has entered inactive mode, if not provided
+            directly by the Host
+
+         -  A report from the Tracking Agent to the Dormant Monitoring
+            Agent that a Host has entered dormant mode, if not provided
+            directly by the Host.
+
+      Dormant Monitoring Agent - Paging Agent (DMA-PA) - The DMA-PA
+      interface supports the following types of traffic:
+
+         -  A request from the Dormant Monitoring Agent to the Paging
+            Agent to page a particular Host in dormant mode because a
+            packet has arrived for the Host.
+
+         -  Negative response indication from the Paging Agent if the
+            Host does not respond to a page.
+
+         -  Positive response from the Paging Agent indication if the
+            Host does respond to a page.
+
+
+
+
+Kempf, et al.                Informational                     [Page 11]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+         -  Delivery of the packet to the Host.
+
+      Host - Dormant Monitoring Agent (H-DMA) - The H-DMA interface
+      supports the following types of traffic:
+
+         -  The Host registers to the Dormant Monitoring Agent prior to
+            entering dormant mode, (if needed) with filtering
+            information on which broadcast/multicast/anycast packets
+            trigger a page.
+
+         -  The Host informs the Dormant Monitoring Agent, when it
+            directly deregisters from the Dormant Monitoring Agent due
+            to a change from dormant mode to active or inactive mode.
+
+5.3. Functional Architecture Diagram
+
+   The functional architecture and interfaces lead to the following
+   diagram.
+
+            +------+          H-TA            +----------+
+            | Host | <----------------------> | Tracking |
+            +------+                          |   Agent  |
+                ^ ^                           +----------+
+                | |           H-DMA                 ^
+                | +------------------------------+  |
+                |                                |  | DMA-TA
+                |                                |  |
+                | H-PA                           |  |
+                v                                v  v
+            +--------+         DMA-PA         +------------+
+            | Paging | <--------------------> |  Dormant   |
+            | Agent  |                        | Monitoring |
+            +--------+                        |   Agent    |
+                                              +------------+
+
+
+                Figure 1 - Paging Functional Architecture
+
+6.   Acknowledgements
+
+   The authors would like to thank Arthur Ross for helpful comments on
+   this memo.
+
+
+
+
+
+
+
+
+
+Kempf, et al.                Informational                     [Page 12]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+7.   References
+
+   [1]   Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
+         Statement", RFC 3132, June 2001.
+
+   [2]   Perkins, C., ed., "IP Mobility Support", RFC 2002, October,
+         1996.
+
+   [3]   Johnson, D., and Perkins, C., "Mobility Support in Ipv6", Work
+         in Progress.
+
+   [4]   Braden, R., "Requirements for Internet Hosts - Communication
+         Layers", STD 3, RFC 1122, October 1989.
+
+   [5]   Kent, S., and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+8.   Authors' Addresses
+
+   James Kempf
+   Sun Microsystems Laboratories
+   901 San Antonio Rd.
+   UMTV29-235
+   Palo Alto, CA
+   95303-4900
+   USA
+
+   Phone: +1 650 336 1684
+   Fax:   +1 650 691 0893
+   EMail: James.Kempf@Sun.COM
+
+
+   Pars Mutaf
+   INRIA Rhone-Alpes
+   655 avenue de l'Europe
+   38330 Montbonnot Saint-Martin
+   FRANCE
+
+   Phone:
+   Fax:   +33 4 76 61 52 52
+   EMail: pars.mutaf@inria.fr
+
+
+
+
+
+
+
+
+
+
+Kempf, et al.                Informational                     [Page 13]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+   Claude Castelluccia
+   INRIA Rhone-Alpes
+   655 avenue de l'Europe
+   38330 Montbonnot Saint-Martin
+   FRANCE
+
+   Phone: +33 4 76 61 52 15
+   Fax:   +33 4 76 61 52 52
+   EMail: claude.castelluccia@inria.fr
+
+
+   Nobuyasu Nakajima
+   Toshiba America Research, Inc.
+   P.O. Box 136
+   Convent Station, NJ
+   07961-0136
+   USA
+
+   Phone: +1 973 829 4752
+   EMail: nnakajima@tari.toshiba.com
+
+
+   Yoshihiro Ohba
+   Toshiba America Research, Inc.
+   P.O. Box 136
+   Convent Station, NJ
+   07961-0136
+   USA
+
+   Phone: +1 973 829 5174
+   Fax:   +1 973 829 5601
+   EMail: yohba@tari.toshiba.com
+
+
+   Ramachandran Ramjee
+   Bell Labs, Lucent Technologies
+   Room 4g-526
+   101 Crawfords Corner Road
+   Holmdel, NJ
+   07733
+   USA
+
+   Phone: +1 732 949 3306
+   Fax:   +1 732 949 4513
+   EMail: ramjee@bell-labs.com
+
+
+
+
+
+
+Kempf, et al.                Informational                     [Page 14]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+   Yousuf Saifullah
+   Nokia Research Center
+   6000 Connection Dr.
+   Irving, TX
+   75039
+   USA
+
+   Phone: +1 972 894 6966
+   Fax:   +1 972 894 4589
+   EMail:  Yousuf.Saifullah@nokia.com
+
+
+   Behcet Sarikaya
+   Alcatel USA, M/S CT02
+   1201 Campbell Rd.
+   Richardson, TX
+   75081-1936
+   USA
+
+   Phone: +1 972 996 5075
+   Fax:   +1 972 996 5174
+   EMail: Behcet.Sarikaya@usa.alcatel.com
+
+
+   Xiaofeng Xu
+   Alcatel USA, M/S CT02
+   1201 Campbell Rd.
+   Richardson, TX
+   75081-1936
+   USA
+
+   Phone: +1 972 996 2047
+   Fax:     +1 972 996 5174
+   Email:  xiaofeng.xu@usa.alcatel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al.                Informational                     [Page 15]
+
+RFC 3154                  Paging Requirements                August 2001
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al.                Informational                     [Page 16]
+