doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3111.txt b/doc/rfc/rfc3111.txt
new file mode 100644
index 0000000..a7d7db0
--- /dev/null
+++ b/doc/rfc/rfc3111.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         E. Guttman
+Request for Comments: 3111                              Sun Microsystems
+Category: Standards Track                                       May 2001
+
+
+            Service Location Protocol Modifications for IPv6
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Service Location Protocol Version 2's
+   (SLPv2) use over IPv6 networks.  Since this protocol relies on UDP
+   and TCP, the changes to support its use over IPv6 are minor.
+
+   This document does not describe how to use SLPv1 over IPv6 networks.
+   There is at the time of this publication no implementation or
+   deployment of SLPv1 over IPv6.  It is RECOMMENDED that SLPv2 be used
+   in general, and specifically on networks which support IPv6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman                     Standards Track                     [Page 1]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+Table of Contents
+
+   1.   Introduction  . . . . . . . . . . . . . . . . . . . . . .  2
+   2.   Eliminating support for broadcast SLP requests  . . . . .  3
+   3.   Address Specification for IPv6 Addresses in URLs  . . . .  3
+   4.   SLP multicast behavior over IPv6  . . . . . . . . . . . .  4
+   4.1.    SLPv2 Multicast Group-IDs for IPv6 . . . . . . . . . .  4
+   4.2.    SLPv2 Scoping Rules for IPv6 . . . . . . . . . . . . .  5
+   4.2.1   Joining SLPv2 Multicast Groups . . . . . . . . . . . .  5
+   4.2.2   Sending SLPv2 Multicast Messages . . . . . . . . . . .  6
+   4.2.3   Rules for Message Processing . . . . . . . . . . . . .  6
+   4.2.4   SLPv2 Agents with multiple interfaces  . . . . . . . .  7
+   4.2.4.1 General Rules  . . . . . . . . . . . . . . . . . . . .  7
+   4.2.4.2 Multihomed UA  . . . . . . . . . . . . . . . . . . . .  8
+   4.2.4.3 Multihomed SA  . . . . . . . . . . . . . . . . . . . .  8
+   4.2.4.4 Multihomed DA  . . . . . . . . . . . . . . . . . . . .  9
+   5.   IANA Considerations . . . . . . . . . . . . . . . . . . . 10
+   6.   Security Considerations . . . . . . . . . . . . . . . . . 10
+        Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
+        References  . . . . . . . . . . . . . . . . . . . . . . . 11
+        Author's Address  . . . . . . . . . . . . . . . . . . . . 12
+        Full Copyright Statement  . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+   The Service Location Protocol (SLP) provides a scalable framework for
+   the discovery and selection of network services.  Using this
+   protocol, computers using IP based networks no longer need so much
+   static configuration of network services for network based
+   applications.  This is especially important as computers become more
+   portable, and users less tolerant of or less able to fulfill the
+   demands of network administration.
+
+   The following are changes required to have the Service Location
+   Protocol work over IPv6.  These changes include:
+
+      -  Eliminating support for broadcast SLP requests
+
+      -  Address Specification for IPv6 Addresses in URLs
+
+      -  Use of IPv6 multicast addresses and IPv6 address scopes
+
+      -  Restricted Propagation of Service Advertisements
+
+   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 [4].
+
+
+
+
+Guttman                     Standards Track                     [Page 2]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+2. Eliminating support for broadcast SLP requests
+
+   Service Location over IPv4 allows broadcasts to send Service Location
+   request messages.  IPv6 makes use of link-local multicast in place of
+   broadcast.  Broadcast-only configuration for SLP is not supported
+   under IPv6.  If a User Agent wishes to make a request to discover
+   Directory Agents or make a request of multiple Service Agents, the
+   User Agent must multicast the request to the appropriate multicast
+   address.
+
+   This change modifies the requirements described in Section 6.1 (Use
+   of Ports, UDP and Multicast) of the Service Location Protocol [2].
+
+3. Address Specification for IPv6 Addresses in URLs
+
+   Whenever possible the DNS [5] name of the service should be used
+   rather than the numerical representation described in this section.
+
+   Service Location allows the use of the protocol without the benefit
+   of DNS.  This is relevant when a group of systems is connected to
+   build a network without any previous configuration of servers to
+   support this network.  When Service Location is used in this manner,
+   numerical addresses must be used to identify the location of
+   services.
+
+   The format of a "service:" URL is defined in [6].  This URL is an
+   "absolute URI" as defined by [7].
+
+   A numerical IPv6 address, such as may be used in a "service:" URL, is
+   specified as in [8].  The textual representation defined for literal
+   IPv6 addresses in [9]:
+
+      ipv6-addr  =  "[" num-addr "]"
+      num-addr   =  ; Text represented IPv6 address syntax is as
+                    ; specified in RFC 2373 [8], Section 2.2,
+
+   Examples:
+
+      This is a site-local scoped address, as could be used in a SLP
+      DAAdvert message.
+
+         service:directory-agent://[FEC0::323:A3F9:25ff:fe91:109D]
+
+      This is a link-local scoped address, as could be used by a SA to
+      advertise its service on a IPv6 network with no routers or DNS
+      service.
+
+         service:printer:ipp://[FE80::a15A:93ff:fe5D:B098]:8080/path
+
+
+
+Guttman                     Standards Track                     [Page 3]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+4. SLP multicast and unicast behavior over IPv6
+
+   Section 4.1 describes how different multicast addresses are used for
+   transmitting and receiving SLPv2 messages over IPv6.  Section 4.2
+   defines rules for the use of these addresses and covers scoped
+   address issues in general.
+
+4.1 SLPv2 Multicast Group-IDs for IPv6
+
+   SLPv2 for IPv4 specifies only one multicast address, relative to an
+   Administratively Scoped Address range [11].  The reason only one
+   address was used is that there are only 256 relative assignments
+   available for this purpose.  IPv6, on the other hand, has scoped
+   addresses and enough space for a range of assignments.
+
+   SLPv2 for IPv6 uses the following multicast group-id assignments:
+
+      FF0X:0:0:0:0:0:0:116     SVRLOC
+      FF0X:0:0:0:0:0:0:123     SVRLOC-DA
+      FF0X:0:0:0:0:0:1:1000    Service Location
+       -FF0X:0:0:0:0:0:1:13FF
+
+   These group-ids are combined with the scope prefix of the scope to
+   which the multicast message is to be sent.
+
+   The SVRLOC group-id is used for the following messages: Service Type
+   Request and Attribute Request messages.
+
+   The SVRLOC-DA group-id is used for multicast Service Requests for the
+   "service:directory-agent" service type.  Also, DAs send unsolicited
+   DA Advert messages to the SVRLOC-DA multicast group-id.
+
+   All other multicast Service Request messages are sent to the
+   appropriate Service Location multicast group-id.  SAs join the groups
+   which correspond to the Service Types of the services they advertise.
+   The group-id is determined using the algorithm provided in SLPv1 [3].
+   The Service Type string used in the SrvRqst is hashed to a value from
+   0-1023.  This determines the offset into the FF0X::1:1000-13FF range.
+
+   The hash algorithm is defined as follows:
+
+   An unsigned 32 bit value V is initialized to 0.  Each byte of the
+   Service Type UTF-8 [12] encoded string value is considered
+   consecutively.  The current value V is multiplied by 33, then the
+   value of the current string byte is added.  Each byte in the Service
+   Type string is processed in this manner.  The result is contained in
+   the low order 10 bits of V.  For example, the following code
+   implements this algorithm:
+
+
+
+Guttman                     Standards Track                     [Page 4]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+      unsigned long slp_hash(const char *pc, unsigned int len) {
+          unsigned long h = 0;
+          while (len-- != 0) {
+              h *= 33;
+              h += *pc++;
+          }
+          return (0x3FF & h); /* round to a range of 0-1023 */
+      }
+
+4.2 SLPv2 Scoping Rules for IPv6
+
+   IPv6 provides different scopes for interface address configuration
+   and multicast addresses.  A SLPv2 Agent might discover services that
+   it cannot use or not discover services which it could use unless
+   rules are given to prevent this.
+
+   Say a SLPv2 UA, for example, could request a service using site-local
+   scope multicast and obtain a service: URL containing a link-local
+   literal address.  If the service referred to were not on the same
+   link as the SLPv2 UA, the service could not be reached.
+
+4.2.1 Joining SLPv2 Multicast Groups
+
+   A SLPv2 Agent MAY send a multicast message using any scope which it
+   is allowed to (see section 4.2.2).  A SA and a DA MUST join all
+   groups to which a SLPv2 Agent may send a message.  This ensures that
+   the SA or DA will be able to receive all multicast messages.
+
+   Specifically, a SLPv2 Agent MUST NOT join a multicast group which has
+   greater scope for an interface than it is configured with for use
+   with unicast.  For example, an interface which is only configured
+   with a link-local address joins groups in scopes with FF01 and FF02.
+   If the interface is configured with a site-local or global address,
+   the scope of all multicast groups joined can be no greater than scope
+   FF05.  In this case, SLPv2 SAs and DAs MUST join multicast groups in
+   all the following scopes: FF01 - FF05.
+
+   A DA MUST join the SVRLOC-DA group to receive SrvRqst messages
+   requesting DAAdverts.
+
+   A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
+
+   A SA MUST join the groups from the Service Location range of group-
+   ids to receive SrvRqst messages.  The SA only joins those groups
+   corresponding to services it advertises.  For example, a service
+   agent which responds to requests for "service:service-agent" (used
+   for SA discovery), would join groups with the group-id derived from
+   the hash function defined in section 4.1:
+
+
+
+Guttman                     Standards Track                     [Page 5]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+   group-id to join = slp_hash("service:service-agent") + base address
+                    = 0x01d8 + FF0X:0:0:0:0:0:1:1000
+                    = FF0X:0:0:0:0:0:1:11d8
+
+   The SA MAY join the SVRLOC group in order to receive SrvTypeRqst and
+   AttrRqst messages; these features are OPTIONAL for the SA to
+   implement.
+
+   A UA MAY join the SVRLOC-DA group at any or all of these scopes in
+   order to receive DAAdvert messages.
+
+4.2.2 Sending SLPv2 Multicast Messages
+
+   The maximum scope for a SLPv2 multicast message is site-local (FF05).
+
+   Multicast SLPv2 messages are sent using a particular scope.  An SLPv2
+   agent MUST issue this request using a source address with a scope no
+   less than the scope of the multicast group.
+
+   This prevents, for example, a site-local multicast message being sent
+   from a link-local source address.
+
+   A SLPv2 UA with an interface configured with at least one global
+   address could multicast a SrvRqst to any scope up to and including
+   site-local, for instance.
+
+4.2.3 Rules for Message Processing
+
+   SLPv2 SAs and DAs MUST determine which scope a service: URL address
+   is in.  This may be possible by examining the URL if it contains a
+   numerical IPv6 address.  If the URL contains a host name, the SA or
+   DA MUST resolve that name to a set of addresses.
+
+   A SLPv2 SA or DA MUST NOT respond to a SrvRqst with a service: URL
+   for a service with an address scope less than the request's source
+   address scope.  The rules are given in Figure 1, below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman                     Standards Track                     [Page 6]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+                               Request Source Address Scope
+                          +------------+------------+---------+
+                          | Link-Local | Site-Local | Global  |
+            +-------------+------------+------------+---------+
+   Service  | Link-Local  |  Respond   |    Drop    |   Drop  |
+   Address  +-------------+------------+------------+---------+
+   Scope    | Site-Local  |  Respond   |   Respond  |   Drop  |
+            +-------------+------------+------------+---------+
+            | Global      |  Respond   |   Respond  | Respond |
+            +-------------+------------+------------+---------+
+
+                      Figure 1:  Out-of-Scope Rules
+
+   This prevents UAs from being able discover service: URLs for services
+   which cannot be accessed.
+
+4.2.4 SLPv2 Agents with multiple interfaces
+
+   A scope zone, or a simply a zone, is a connected region of topology
+   of a given scope.  For example, the set of links connected by routers
+   within a particular site, and the interfaces attached to those links,
+   comprise a single zone of site-local scope.  To understand the
+   distinction between scopes and zones, observe that the topological
+   regions within two different sites are considered to be two DIFFERENT
+   zones, but of the SAME scope.
+
+   A host which has multiple interfaces attached to different links is
+   by definition is attached to two link-local zones.  A host may also
+   be attached to multiple zones of other scopes.
+
+   A SLPv2 Agent MUST NOT propagate service advertisements from one zone
+   to another.  Another way of saying this is a SLPv2 SA or DA MUST NOT
+   respond to a request from one zone with service information
+   associated with a service in a different zone.
+
+   The specific implication of these rules is discussed in the sections
+   which follow.
+
+4.2.4.1 General rules
+
+   Service Locations (in SrvReg, SrvRply, AttrRst, SAAdvert or DAAdvert
+   messages) whose locations are literal addresses MUST only be sent to
+   SLP agents located on the same zone.
+
+   For example, a service: URL containing a link-local address on link A
+   may be sent in a SLPv2 message on link A, to a link-local destination
+   address only.
+
+
+
+
+Guttman                     Standards Track                     [Page 7]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+   Each interface of a multihomed device is potentially on a separate
+   link.  It is often difficult to determine whether two interfaces are
+   connected to the same link.  For that reason a prudent implementation
+   strategy is to not issue SLP messages containing link-local service
+   locations except on the interface where the service is known to
+   reside.
+
+4.2.4.2 Multihomed UA
+
+                   +----+        +----+        +----+
+                   | SA |--------| UA |--------| DA |
+                   +----+ Link 1 +----+ Link 2 +----+
+
+                      (Zone 1)            (Zone 2)
+
+                       Figure 2:  Multihomed UA
+
+   In Figure 2 the UA is multihomed.  The UA can issue a service request
+   in Zone 1 and discover services on the SA or in Zone 2 and discover
+   services advertised by the DA.  For example, if the request is issued
+   from a link-local source address, the SA will only reply with a
+   service available on link 1, the DA only with a service available on
+   link 2.
+
+   The UA MUST use active discovery to detect DAs before issuing
+   multicast requests, as per SLPv2 [2].  The UA MUST issue requests
+   using increasing multicast scopes starting at FF01 and increasing to
+   a maximum scope of FF05, to solicit DAAdvertisements.  Note the
+   restrictions in Section 4.2.2.
+
+   If the UA is unable to discover any DAs using multicast discovery, it
+   may issue site-local scope (FF05) or less multicast requests.  (Note
+   that the source address of the request must be of at least the scope
+   of the multicast, as described in section 4.2.2.)
+
+   If the UA wishes to discover all services, it must issue requests
+   into both Zone 1 and 2.
+
+4.2.4.3 Multihomed SA
+
+                   +----+        +----+        +----+
+                   | UA |--------| SA |--------| DA |
+                   +----+ Link 1 +----+ Link 2 +----+
+
+                      (Zone 1)            (Zone 2)
+
+                        Figure 3: Multihomed SA
+
+
+
+
+Guttman                     Standards Track                     [Page 8]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+   In Figure 3, the SA is multihomed.  The SA may receive a request from
+   the UA on Link 1 (Zone 1).  The SA MUST NOT return service
+   information for services offered on a different zone as a request.
+   For example, the UA could discover services offered in Zone 1 not
+   Zone 2.
+
+   The SA may receive a DAAdvert on Link 2 (Zone 2).  The SA MUST NOT
+   send a service registration to the DA for a service which is present
+   in Zone 1.  The SA MUST register a service with the DA which is
+   present in Zone 2.
+
+   The SA MUST NOT include an address in a SAAdvert message which is
+   sent on a zone where the address is not valid.  For example, the SA
+   MUST NOT send a SAAdvert onto link 2, if the SAADvert contains a
+   service: URL with a literal link-local scoped IPv6 address for Link
+   1.
+
+   The SA performs active DA discovery, as described in SLPv2 [2].  The
+   SA MUST issue requests using multicast scope FF02 to solicit
+   DAAdvertisements.  If the SA has a site-local or global source
+   address, it MUST reissue the request with increasing scopes up to a
+   maximum scope of FF05.  Active DA discovery must be attempted in both
+   Zone 1 and 2.  This ensures that the SA will discover as many DAs in
+   its scope as possible.
+
+4.2.4.4 Multihomed DA
+
+                   +----+        +----+        +----+
+                   | UA |--------| DA |--------| SA |
+                   +----+ Link 1 +----+ Link 2 +----+
+
+                      (Zone 1)            (Zone 2)
+
+                        Figure 4: Multihomed DA
+
+   In Figure 4, the DA is multihomed.  The DA MUST keep track of which
+   interface registrations were made on.  The DA MUST prevent a
+   registration from the SA which contains a service information valid
+   in one zone from being discovered in another zone.  For example,
+   services registered by the SA in Zone 2 would not be discoverable by
+   the UA in Zone 1.
+
+   Care must be taken when issuing DAAdverts.  The DA must respond to
+   active DA discovery requests using the same scope as the request.
+   For instance, if the SA issues a SrvRqst message for service type
+   "service:directory" from a link-local source address, the DA MUST
+   respond with a link-local (link 2) source address.
+
+
+
+
+Guttman                     Standards Track                     [Page 9]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+   The DA MUST multicast unsolicited DAAdverts on each interface using
+   link-local and site-local source addresses, unless it is only
+   configured with a link-local address.  In that case, the DA MUST
+   issue DAAdverts with link-local scope only.
+
+   The DA URL MUST contain the address of the greatest scope the DA is
+   configured with in the zone.  For instance, if the DA is configured
+   with a link-local, site-local and global address in Zone 2, it would
+   use the global address in the DA URL (as a literal IPv6 address).
+
+5. IANA Considerations
+
+   The IPv6 multicast group-id range FF05::1:1000 - FF05::1:13FF was
+   previously assigned by IANA in RFC 2375 for use by SLP [10].
+
+   This document defines how the range of addresses FF0X::1:1000 -
+   FF0X::1:13FF is used.  IANA has assigned this range of addresses for
+   use by Service Location Protocol.
+
+   This document fully defines the multicast addresses that this
+   protocol will use.  There is no requirement for the IANA to establish
+   a registry to assign additional addresses.
+
+6. Security Considerations
+
+   User Agents and Directory Agents MAY ignore all unauthenticated
+   Service Location messages when a valid IPSec association exists.
+
+   Service Agents and Directory Agents MUST be able to use the IP
+   Authentication and IP Encapsulating Security Payload for issuing and
+   processing Service Location messages whenever an appropriate IPSec
+   Security Association exists [13].
+
+   SLP allows digital signatures to be produced to allow the
+   verification of the contents of messages.  There is nothing in the
+   Modifications for IPv6 document which weakens or strengthens this
+   technique.
+
+Acknowledgments
+
+   Thanks to Dan Harrington, Jim Wood and Alain Durand, Thomas Narten,
+   Dave Thaler and Erik Nordmark for their reviews of this document.
+   John Veizades contributed to the original version of this document.
+   The hash function is modified from a code fragment attributed to
+   Chris Torek.  Text on Scope Zones is taken from writing by Steve
+   Deering, Brian Haberman and Brian Zill.
+
+
+
+
+
+Guttman                     Standards Track                    [Page 10]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Version 3", BCP
+        9, RFC 2026, October 1996.
+
+   [2]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+        Location Protocol, Version 2", RFC 2608, June 1999.
+
+   [3]  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
+        Location Protocol", RFC 2165, June 1997.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, November 1987.
+
+        Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035,  November 1987.
+
+   [6]  Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+        URLs", RFC 2609, July 1999.
+
+   [7]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [8]  Hinden, R. and B. Carpenter, "Format for Literal IPv6 Addresses
+        in URL's", RFC 2732, December 1999.
+
+   [9]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments",
+        RFC 2375, July 1997.
+
+   [11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
+        July 1998.
+
+   [12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+   [13] Kent, S. and R. Atkinson, "Security Architecture for the
+        Internet Protocol", RFC 2401, November 1998.
+
+
+
+
+
+
+
+
+Guttman                     Standards Track                    [Page 11]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 2001
+
+
+Author's Address
+
+   Erik Guttman
+   Sun Microsystems
+   Eichhoelzelstr. 7
+   74915 Waibstadt, Germany
+
+   Phone:  +49 7263 911701
+   EMail:  Erik.Guttman@germany.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman                     Standards Track                    [Page 12]
+
+RFC 3111    Service Location Protocol Modifications for IPv6    May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman                     Standards Track                    [Page 13]
+