doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3082.txt b/doc/rfc/rfc3082.txt
new file mode 100644
index 0000000..cdc5eb6
--- /dev/null
+++ b/doc/rfc/rfc3082.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                           J. Kempf
+Request for Comments: 3082                                J. Goldschmidt
+Category: Experimental                                  Sun Microsystems
+                                                              March 2001
+
+
+                 Notification and Subscription for SLP
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Service Location Protocol (SLP) provides mechanisms whereby
+   service agent clients can advertise and user agent clients can query
+   for services.  The design is very much demand-driven, so that user
+   agents only obtain service information when they specifically ask for
+   it.  There exists another class of user agent applications, however,
+   that requires notification when a new service appears or disappears.
+   In the RFC 2608 design, these applications are forced to poll the
+   network to catch changes.  In this document, we describe a protocol
+   for allowing such clients to be notified when a change occurs,
+   removing the need for polling.
+
+1. Introduction
+
+   The Service Location Protocol (SLP) [1] provides a mechanism for
+   service agent (SA) clients to advertise network services and for user
+   agent (UA) clients to find them.  The mechanism is demand-driven.
+   UAs obtain service information by actively querying for it, and do
+   not obtain any information unless they do so.  While this design
+   satisfies the requirements for most applications, there are some
+   applications that require more timely information about the
+   appearance or disappearance in the services of interest.
+
+   Ideally, these applications would like to be notified when a new
+   service comes up or when a service disappears.  In order to obtain
+   this information with SLP as described in RFC 2608, such applications
+   must poll the network to periodically refresh their local cache of
+   available service advertisements.
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 1]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   An example of such a client is a desktop GUI that wants to display
+   network service icons as soon as they appear to provide users with an
+   accurate picture of all services available to them.
+
+   Because polling is inefficient and wasteful of network and processor
+   resources, we would like to provide these applications a mechanism
+   whereby they can be explicitly notified of changes.  In this
+   document, we describe a scalable mechanism allowing UAs to be
+   notified of changes in service availability.
+
+2. Notation Conventions
+
+   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 RFC 2119 [2].
+
+3. Terminology
+
+   In this section, we present some additional terminology beyond that
+   in [1] and [3].
+
+   Notification - A message sent to an interested agent informing that
+                  agent that a service has appeared or disappeared.
+
+   Subscription - A request to be informed about changes in service
+                  availability for a particular service type and scopes.
+
+4. Design Considerations
+
+   The primary design consideration in a notification protocol for SLP
+   is that we would like it to exhibit the same high degree of
+   scalability and robustness that the base SLP protocol exhibits.
+   Notification should work in small networks with only a few SAs, as
+   well as large enterprise networks with thousands of SAs and hundreds
+   of DAs.  Small networks should not be required to deploy DAs in order
+   to receive the benefits of notification.  We also want to assure that
+   notification in large networks does not cause heavy processing loads
+   to fall on any one particular SLP agent.  This requires that the task
+   of notification be distributed rather than centralized, to avoid
+   loading down one agent with doing all the notification work.
+   Finally, we would like the notification scheme to be robust in the
+   face of DA failures, just as the base SLP design is.
+
+   An important consideration is that the UA clients obtain
+   notifications of SA events in a timely fashion.  If a UA has
+   subscribed to notification for a particular service type, the UA
+   should receive such notification regardless of the state of
+   intervening DAs.  SLP is transparent with respect to DAs supporting a
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 2]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   particular scope; that is, a UA can use any DA with a particular
+   scope and expect to get the same service advertisements.
+   Notifications should exhibit the same property.  Whether or not a UA
+   receives a notification should not depend on the DA to which they
+   happen to connect. This preserves the DAs' identity as a pure cache.
+
+   Another goal is that the notification messages contain enough
+   information about the triggering event that the UA can determine
+   whether or not it is of interest in the large majority of cases
+   without having to issue another SLP request a priori.  The UA may, of
+   course, issue an SLP request for related reasons, but it should not
+   have to issue a request to obtain more information on the event that
+   triggered the notification in most cases.  This reduces the amount of
+   network traffic related to the event.
+
+   In order to simplify implementation, we would like to use similar
+   mechanisms for notification in large and small networks.  The
+   mechanisms are not identical, obviously, but we want to avoid having
+   radically different mechanisms that require completely separate
+   implementations.  Having similar mechanisms reduces the amount of
+   code in UA and SA clients.
+
+   A minor goal is to make use of existing SLP message types and
+   mechanisms wherever possible.  This reduces the amount of code
+   necessary to implement the notification mechanism, because much code
+   can be reused between the base SLP and the notification mechanism.
+   In particular, we expect to make use of the SLP extension mechanism
+   in certain cases to support subscription.
+
+5. Notification Design Description
+
+   In order to support scalability, we split the design into two parts.
+   A small network design is used when no DAs are present in the
+   network.  A large network design is used in networks with DAs.  The
+   following subsections describe the two designs.
+
+5.1 Small Network Design
+
+   In networks without DAs, UAs are notified by an SA when the SA
+   initially appears, and when the SA disappears.  This allows UAs to
+   know about the list of service types the SA supports.  In small
+   networks, there is no centralized agent available to administer
+   subscriptions for newly appearing SAs.  This rules out any kind of
+   subscription design in which a UA subscribes to notifications for a
+   particular service type in particular scopes of interest, because a
+   newly appearing SA can't tell whether or not there are any
+   subscriptions without a centralizing agent to tell it.
+
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 3]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   As a result, SAs perform notification when they come on line and
+   prior to shutting down regardless of their scope or service type, if
+   they are capable of performing notification.  This means that a UA
+   receives notification of all types of changes for all scopes and
+   service types, and consequently must be prepared to filter out those
+   changes in which it is not interested (other scopes, other service
+   types).
+
+   The design requires SAs to perform notification by IP multicasting
+   (or broadcasting in IPv4 if multicast is not available) SLP SrvReg or
+   SrvDereg messages using the multicast transmit algorithm described in
+   Section 9.0.  The port number for notifications is not the default
+   SLP port, because that port is only accessible to privileged users on
+   some operating systems, but rather the port 1847, as assigned by
+   IANA.
+
+   In IPv4, the SA performs multicast on the SLP multicast address
+   (239.255.255.253, default TTL 255) and is administratively scoped in
+   the same manner as SLP [4].  IPv4 UAs interested in notification join
+   the multicast group 239.255.255.253 and listen on port 1847.  In
+   IPv6, the multicast is performed to the scoped IPv6 addresses for the
+   service type advertised, as described in [8].  The SA advertises on
+   all addresses up to and including the largest multicast scope that it
+   supports.  IPv6 UAs interested in notification join the multicast
+   groups corresponding to the multicast scopes and service type in
+   which they are interested and listen on port 1847.  For example, an
+   IPv6 UA that has access to site local scope and is interested in a
+   service type whose hash is 42, calculated according to the algorithm
+   in [8], joins the groups FF01:0:0:0:0:0:10042 through
+   FF05:0:0:0:0:0:10042.
+
+5.2 Large Network Design
+
+   In networks with DAs, a DA supporting a particular scope can act as
+   an intermediary for administering UA subscriptions.  A subscription
+   consists of a service type and a collection of scopes.  A UA
+   interested in being notified about changes in a particular service
+   type attaches the Subscribe extension to a SrvRqst message sent to
+   the DA.  The DA obtains multicast group addresses for notification
+   based on the algorithm described in Section 8.0 and puts them into a
+   NotifyAt extension which it attaches to the SrvRply.  The UA listens
+   on the group addresses in the reply for notifications.
+
+   When a new subscription comes in, existing SAs are informed about the
+   subscription using the following procedure.  The DA compares the
+   service type and scopes in the new subscription against a list of
+   existing subscriptions.  If no previous subscription has the same
+   service type and scopes, the DA MUST multicast a DAAdvert, using the
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 4]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   multicast transmit algorithm described in Section 9.0, and MUST
+   include the NotifyAt extension with the multicast group addresses for
+   notification.  If an existing subscription covers the same service
+   type and scopes as the new subscription, the DA MUST NOT multicast a
+   DAAdvert.
+
+   A DA MUST keep track of subscriptions it has arranged as well as
+   subscriptions arranged by other DAs in any scopes with which the DA
+   is configured.  To avoid multiple multicast NotifyAt messages, a DA
+   MUST wait a random amount of time, uniformly distributed between 0
+   and 3 seconds before sending the multicast DAAdvert with NotifyAt.
+   During this period, the DA MUST listen for NotifyAt messages that
+   match the one from the new subscription.  If a matching NotifyAt is
+   detected, the DA MUST not multicast.
+
+   When a new SA registers with a DA that has existing subscriptions,
+   the new SA is informed of notifications it should perform using the
+   following procedure.  If the service type and scopes in the new SA's
+   SrvReg messages match an existing subscription, a NotifyAt containing
+   the multicast addresses for notification MUST be included in the
+   SrvAck.  If the SA doesn't support notification, it simply ignores
+   the extension.  If the service type and scopes in the new SA's SrvReg
+   do not match any existing subscriptions, the DA MUST NOT include a
+   NotifyAt.
+
+   The DA itself MUST also perform notification, according to the
+   multicast transmit algorithm, when a service advertisement times out.
+   Time-out of a service advertisement results in the DA multicasting a
+   SrvDereg for the deregistered URL.  This allows interested UAs to be
+   informed of the service advertisement's demise even if the SA has
+   disappeared without deregistering.  A DA MUST NOT perform
+   notification when it receives a SrvReg from an SA, however, that is
+   the job of the SA.
+
+   As in small networks, notification is performed primarily by SAs.  If
+   an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the
+   following conditions are met:
+
+           1. The SA supports notification.
+
+           2. The SA's service type matches the service type in the
+              NotifyAt extension.
+
+           3. The SA's scopes match one of the scopes of the NotifyAt
+              extension.
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 5]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   then the SA saves the multicast addresses that correspond to the
+   scopes and service types it supports.  The SA MUST perform
+   notification immediately after the SA has performed the SrvReg or
+   SrvDereg with the DA.  An SA that has detected a DA in its scopes
+   MUST NOT multicast any notifications unless it receives a NotifyAt
+   extension in a SrvAck with service type and scopes matching the SA's
+   service type and scopes.
+
+6. Subscribe Extension
+
+   The Subscribe extension has the following format:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Extension Type = 0x0004    |        Extension Length       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Ex. Len. (ct) | Abs. Type Fl. |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The scope list and service type of the extension are taken from the
+   accompanying SrvRqst.  The abstract type flag indicates whether the
+   UA is interested in hearing from all SAs advertising concrete
+   instances of an abstract type [3], and is only of interest if the
+   service type in the SrvRqst is a concrete type.  If the flag is 1,
+   the UA is interested in hearing from all SAs advertising concrete
+   types having the same abstract type as the type of the SrvRqst.  If
+   the flag is 0, the UA is only interested in hearing from SAs
+   supporting the particular concrete type in the SrvRqst.  If the
+   service type in the accompanying SrvRqst is not a concrete type, the
+   flag is ignored.
+
+7. NotifyAt Extension
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Extension Type = 0x0005    |        Extension Length       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Ext. Len (ct) |  Subscription Lifetime        |SGL List Len.  \
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |SGL L. Len (ct)|       Scope/Group List                        \
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  Length of Service Type Name  |        Service Type Name      \
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 6]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   The service type name is in the same format as in the SrvRqst.  The
+   scope/group list is a list of scope names and multicast group
+   addresses.  The following ABNF [5] syntax describes the list:
+
+        sglist          = sgitem / sgitem "," sglist
+        sgitem          = scope-name ":" ip-addr
+        ip-addr         = ipv4-number | ipv6-number
+        scope-name      =  ; See RFC 2608 for the format of scope names.
+        ipv4-number     =  1*3DIGIT 3("." 1*3DIGIT)
+        ipv6-number     = ;See RFC 2373 [9] Section 2.2
+
+   An example of a scope/group list for IPv4 is:
+
+        eng:239.255.255.42,corp:239.255.255.43
+
+   An example of a scope/group listfor IPv6 is:
+
+        eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042
+
+   The scope/group list gives the multicast addresses to use for
+   notifications involving the service type for the given scopes.
+
+   The service type name can be a simple type name, an abstract type
+   name, or a concrete type name.  If the name is an abstract type name,
+   all SAs advertising the abstract type MUST notify.  If the name is a
+   concrete or simple type name, ONLY those SAs advertising the simple
+   or concrete type MUST notify, others MUST NOT notify.  A DA that
+   receives a subscription for a concrete type with the abstract type
+   flag set, MUST include the abstract type name in all the NotifyAt
+   messages it sends.  If the DA receives a subscription for a concrete
+   type with the abstract type flag not set, the DA MUST NOT include the
+   abstract type, but rather MUST include the concrete type name.
+
+   There are three cases in which an agent may receive a NotifyAt
+   extension: in a SrvRply returned to a UA, in a multicast DAAdvert,
+   and in a SrvAck returned to an SA.  The three subsections below
+   describe the response in each of these cases.
+
+7.1 NotifyAt received with SrvRply
+
+   When a UA sends a SrvRqst with a Subscribe extension, the DA responds
+   with a SrvRply including a NotifyAt.  The DA MUST NOT unicast a
+   NotifyAt to a UA with any other message and MUST NOT send a NotifyAt
+   unless a SrvRqst with a Subscribe extension was received.
+
+   The UA responds by setting up a multicast listener to the group
+   addresses included in the extension on the SLP notification port
+   1847.  The UA MAY also want to note the expiration lifetime of the
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 7]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   subscription assigned by the DA, and reissue a  subscription before
+   the lifetime expires.
+
+7.2 NotifyAt received with Multicast DAAdvert
+
+   The DA multicasts a NotifyAt with a DAAdvert using the multicast
+   transmit algorithm when a UA has requested notification and the
+   scopes and service type in the subscription were not previously seen.
+   This message informs existing SAs having the service type and scopes
+   in the announcement that they should multicast notifications when
+   they shut down.
+
+   A receiving SA participating in notification responds by noting the
+   multicast address if the service type and scopes match.  When the SA
+   is about to go down, the SA MUST first unicast a SrvDereg without
+   attribute tag list to its DAs (as per standard SLP), then it MUST
+   multicast the same SrvDereg message according to the multicast
+   transmit algorithm.  The SA MUST cease performing notification when
+   the subscription lifetime expires, unless a subsequent NotifyAt is
+   received prolonging the subscription.
+
+   A UA that is performing passive DA detection will naturally also
+   receive the extension, but the UA SHOULD ignore the extension.
+
+7.3 NotifyAt received with SrvAck
+
+   An SA can receive a NotifyAt with a SrvAck when it first comes up and
+   registers itself with a DA.  If the DA has any subscriptions from UAs
+   for the service type and scopes represented by the SA, it MUST return
+   a NotifyAt with the SrvAck.
+
+   The SA upon receiving the NotifyAt immediately multicasts the same
+   SrvReg it sent to the DA, according to the multicast transmit
+   algorithm.  The SA MUST only perform the multicast algorithm once,
+   even if it registers with more than one DA and receives the NotifyAt
+   in reply from more than one.  Prior to its demise and after
+   deregistering with a DA, the SA MUST notify with the same SrvDereg,
+   as described in Section 7.2.
+
+8. Multicast Address Allocation
+
+   Enterprise networks that allow SLP notification SHOULD deploy the
+   Multicast Address Allocation Architecture (MAAA) including
+   administratively scoped multicast and Multicast Address Dynamic
+   Client Allocation Protocol (MADCAP) [6].
+
+   If it is not possible to obtain a multicast address for use in SLP
+   notifications, the SLP multicast address is used.
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 8]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   If the MAAA infrastructure is deployed, DAs and SAs obtain their
+   scope configuration from MADCAP, because the SLP scopes are the same
+   as the MADCAP scopes.  Each SLP scope MUST correspond to a multicast
+   scope name, in the sense of [6].  In such a case, a DA allocates,
+   using MADCAP, a new multicast group address for each new service
+   type/scope pair to which a UA subscribes.  The allocation is made by
+   MADCAP from the multicast address range for the scope.  In this way,
+   only those UAs interested in the service type and scopes in the
+   subscription receive the multicast notification.  The DA sets up the
+   lease on the multicast address to correspond with the duration of the
+   subscription.  If the MADCAP server runs out of addresses, the SLP
+   multicast group is used as a last resort.
+
+   For example, if the multicast scope has an address range of 239.1.0.0
+   through 239.1.255.255, the notification group address for service
+   type X in scope A could be 239.1.0.42 and for service type Y in scope
+   B could be 239.1.42.42.
+
+9. Multicast Transmit Algorithm
+
+   The DA and SAs use a multicast transmit algorithm similar to that
+   used for discovering services in SLP, described in RFC 2608 [1],
+   except the agent performing the notification doesn't wait for
+   replies.  The agent performing the notification transmits a
+   notification message repeatedly over a period of 15 seconds, backing
+   off exponentially on the duration of the time interval between the
+   multicasts.  The rationale for this algorithm is to limit the
+   duration and scope of the multicast announcement while still
+   repeating the announcement enough times to increase the probability
+   that one message gets through.
+
+   For an SA, a notification message is either a SrvReg or a SrvDereg
+   message, depending on whether the SA is registering a new service or
+   deregistering a service.  When a new service is registered, the
+   SrvReg message MUST have the fresh bit set in the SLP header.  The
+   entire list of attributes for the service SHOULD be included.  The
+   SrvDereg message MUST NOT include an attribute tag list.
+   Notifications MUST NOT be transmitted at any other time, to minimize
+   multicast traffic.
+
+   Since a SrvReg could contain attribute lists of arbitrary length, the
+   message could potentially overflow the packet MTU for UDP.  If an
+   attribute list causes a packet MTU overflow, the SA MUST set the
+   overflow bit in the SLP header.  The attribute list in the
+   notification message MUST be formatted so that a UA can use the
+   attributes even if an overflow occurs.  If a UA needs more attributes
+   than are transmitted in the notification message, it can contact the
+   SA (if no DA is present) or the DA for the attributes it needs.
+
+
+
+Kempf & Goldschmidt           Experimental                      [Page 9]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   A DA multicasts a DAAdvert when a subscription comes in containing a
+   service type and scopes that do not match any on the DA's list of
+   known subscriptions.  The same algorithm MUST be used.  If the
+   combination of the DA attributes and the NotifyAt message cause the
+   DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to
+   allow the NotifyAt to fit and the overflow bit MUST be set in the
+   header.  An SA knows that the purpose of the message is to inform it
+   of a new subscription rather than for passive advertisement, because
+   of the extension, and it can therefore ignore the DA attribute list
+   field if the overflow bit is set in the header.  A DA also transmits
+   a SrvDereg message when a service advertisement is deregistered due
+   to timeout, following the same rules as for an SA.
+
+10.0 DA Disappearance
+
+   Robustness to DA failure is an important goal of the design.  When a
+   DA disappears due to unforeseen circumstances, subscription
+   information from UAs is lost.  UAs continue to get notifications from
+   existing SAs.  However, new SAs will not be informed of the
+   subscription unless other DAs also have the subscription information.
+   Because a UA may not discover a new DA until it tries to perform an
+   active request, the UA could potentially miss the appearance of new
+   services.  For this reason, UAs that are concerned about receiving
+   notification of absolutely every service that appears SHOULD issue
+   subscriptions to every newly discovered DA that supports the scopes
+   it supports.  Similarly, if a DA disappears through controlled
+   shutdown, a UA performing passive discovery can detect the shutdown
+   and reissue the subscription to an alternate DA.
+
+   On the SA side, when a DA goes down, existing SAs continue to notify
+   until the subscription expires.  Before ceasing to notify, an SA MUST
+   determine whether the DA is still active and, if not, verify with
+   another DA whether the subscription has been extended.  If no other
+   DA is available, the SA MUST ignore the subscription expiration time
+   and continue notifying until a new DA is discovered.  When a new DA
+   is discovered the SA must send a new SrvReg to the DA, according to
+   RFC 2608 [1].  The replying SrvAck contains a NotifyAt extension if
+   the UA has renewed its subscription with the DA.  If the SrvAck does
+   not contain a NotifyAt message the SA MUST continue to notify until
+   the subscription expires.  If a UA is interested in continuing the
+   notification, it renews the subscription with the new DA prior to the
+   expiration  of the old one, and so the SA is informed to continue
+   notifying.
+
+
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                     [Page 10]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+   Note that this procedure still does not inform SAs that come up
+   between the time a newly booted DA comes up and the time the UA has
+   renewed its subscription with the newly booted DA.  If this situation
+   is of concern, multiple DAs can be used to assure that all
+   subscriptions are covered when a DA goes down.
+
+11.  Network Administration Considerations
+
+   In SLP networks with DAs as described in RFC 2608, the only multicast
+   is the SrvRqst for DAAdverts performed during active DA discovery,
+   and unsolicited DAAdverts sent periodically by the DA for passive
+   discovery.  There is no multicast involved in UA queries or SA
+   registrations.  This allows network administrators to set up DAs for
+   a particular collection of IP subnets and confine all service
+   discovery traffic to unicast between the SA and UA clients and the
+   DA.  Administratively scoped multicast can additionally be used to
+   limit the extent of active DA discovery and passive DA advertising.
+   The amount of multicast involved is not high and DHCP DA and scope
+   configuration can be used to limit which DAs a particular UA or SA
+   client sees, or to inhibit multicast entirely so that UAs and SAs
+   only use configured DAs.
+
+   With notification, however, multicast traffic involving events in SAs
+   becomes available.  Because DAs request multicast addresses based on
+   scope and service type, the multicast associated with particular
+   events should only propagate to those subnets in which UAs and SAs of
+   the same scope are interacting.  Routers should be configured with
+   administrative multicast scoping to limit multicast.  If DAs are not
+   deployed (or the MAAA is not deployed), however, the amount of
+   multicast on the SLP multicast address when notifications are being
+   used could quickly become very large.  Therefore, it is crucial that
+   DAs supporting notification be deployed in large networks where UA
+   clients are interested in notification.
+
+12. Security Considerations
+
+   The SrvReg and SrvDereg messages contain authentication blocks for
+   all SLP SPIs supported by the DAs with which the SA registers.  Since
+   these SPIs are necessarily the same as those that UAs can verify, a
+   UA receiving a multicast notification is in a position to verify the
+   notification.  It does so by selecting the authentication block or
+   blocks that it can verify.  If authentication fails, either due to
+   lack of an authentication block, or lack of the proper SPI, the UA
+   simply discards the notification.  In a network without DAs, the SPIs
+   of the UA and SA must also match.
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                     [Page 11]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+13. IANA Considerations
+
+   The SLP Notification services use the IANA-assigned port number of
+   1847.  The SLP extension identifiers assigned by IANA are 0x0004 for
+   Subscribe and 0x0005 for NotifyAt.
+
+14. Acknowledgements
+
+   The authors would like to thank Charles Perkins, of Nokia, and Erik
+   Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating
+   discussion and suggestions during the initial phases of the
+   subscription/notification design.  We would also like to thank Erik
+   for his intense scrutiny of the specification during the later
+   phases.  His comments were instrumental in refining the design.
+   Shivaun Albright, of HP, motivated simplification of the protocol to
+   focus on initial registration and deregistration only.  Vaishali
+   Mithbaokar implemented the simplified protocol.
+
+15. References
+
+   [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+       Location Protocol", RFC 2608, July 1999.
+
+   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+       service: Schemes", RFC 2609, July 1999.
+
+   [4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
+       1998.
+
+   [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+       Specifications: ABNF", RFC 2234, November 1997.
+
+   [6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
+       Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
+
+   [7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
+
+   [8] Guttman, E., "Service Location Protocol Modifications for IPv6",
+       Work in Progress.
+
+   [9] Hinden, R. and S. Deering, "IP Version 6 Addressing
+       Architecture", RFC 2375, July 1997.
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                     [Page 12]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+16. Author's Addresses
+
+   James Kempf
+   Sun Microsystems
+   UMPK15-214
+   901 San Antonio Rd.
+   Palo Alto, CA 94040
+   USA
+
+   Phone:    +1 650 786 5890
+   EMail:    james.kempf@sun.com
+
+
+   Jason Goldschmidt
+   Sun Microsystems
+   UMPK17-202
+   901 San Antonio Rd.
+   Palo Alto, CA 94040
+   USA
+
+   Phone: +1 650 786 3502
+   EMail: jason.goldschmidt@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Goldschmidt           Experimental                     [Page 13]
+
+RFC 3082         Notification and Subscription for SLP        March 2001
+
+
+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 & Goldschmidt           Experimental                     [Page 14]
+