doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3832.txt b/doc/rfc/rfc3832.txt
new file mode 100644
index 0000000..583ffdb
--- /dev/null
+++ b/doc/rfc/rfc3832.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            W. Zhao
+Request for Comments: 3832                                H. Schulzrinne
+Category: Experimental                               Columbia University
+                                                              E. Guttman
+                                                        Sun Microsystems
+                                                            C. Bisdikian
+                                                               W. Jerome
+                                                                     IBM
+                                                               July 2004
+
+
+                    Remote Service Discovery in the
+              Service Location Protocol (SLP) via DNS SRV
+
+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 (2004).
+
+Abstract
+
+   Remote service discovery refers to discovering desired services in
+   given remote (i.e., non-local) DNS domains.  This document describes
+   remote service discovery in the Service Location Protocol (SLP) via
+   DNS SRV.  It defines the DNS SRV Resource Records for SLP Directory
+   Agent services, discusses various issues in using SLP and DNS SRV
+   together for remote service discovery, and gives the steps for
+   discovering desired services in remote DNS domains.
+
+1.  Introduction
+
+   This document describes remote service discovery in the Service
+   Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782].  We consider
+   remote service discovery as discovering desired services in given
+   remote DNS domains, and local service discovery as discovering
+   desired services within the local administrative domain.
+
+   SLP provides a scalable framework for local service discovery and
+   selection.  In SLP, User Agents (UAs) discover desired services in
+   the local administrative domain by querying all Service Agents (SAs)
+   via multicast or querying a Directory Agent (DA) via unicast.  To
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 1]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+   query a DA using unicast, a UA needs to first learn about the DA via
+   DHCP, static configuration or multicast (listening for DAAdvert
+   multicast or issuing DA discovery SrvRqst multicast).
+
+   DNS SRV provides good support for remote service discovery.  However,
+   if multiple servers are discovered via DNS SRV for a service, only
+   priority and weight can be used to make a selection.  If additional
+   service properties (such as cost, speed and service quality) need to
+   be considered in the selection process, DNS SRV becomes insufficient.
+
+   We propose that using SLP and DNS SRV together can provide better
+   support for remote service discovery.  First, a UA uses DNS SRV to
+   find SLP DAs at a remote DNS domain.  Then, the UA uses SLP to query
+   one of those DAs to discover desired services.  In this way, we can
+   avoid the limitations in using SLP and DNS SRV separately.  On one
+   hand, without DNS SRV, an SLP UA needs to depend on static
+   configuration to learn about remote DAs because DHCP and multicast DA
+   discovery are not generally applicable beyond the local
+   administrative domain.  On the other hand, without SLP, DNS SRV has
+   limited support for service selection.
+
+   In this document, we first define the DNS SRV Resource Records (RRs)
+   for SLP DA services, which are used to map a given DNS domain to
+   remotely accessible (i.e., accessible from the Internet) DAs in that
+   domain.  Then, we discuss various issues in using SLP and DNS SRV
+   together for remote service discovery.  Finally, we give the steps
+   for discovering services in remote DNS domains.
+
+1.1.  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 BCP 14, RFC 2119
+   [RFC2119].
+
+2.  The DNS SRV RRs for SLP DA services
+
+   According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services
+   are defined as follows:
+
+   _slpda._Proto.Name TTL Class SRV Priority Weight Port Target
+
+   where "slpda" is the symbolic name for SLP DA services, the Proto
+   field is either "tcp" or "udp", and the Target field is the domain
+   name of an SLP DA.  Please refer to [RFC2782] for detailed
+   explanation of each field in DNS SRV RRs.
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 2]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+   Next we show an example of using DNS SRV RRs to map a given DNS
+   domain to remotely accessible DAs in that domain.  To discover
+   remotely accessible DAs in a remote domain (say, example.com), a UA
+   makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com
+   (or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV.  Then
+   the UA will receive a list of DNS SRV RRs in a DNS reply, which gives
+   all remotely accessible DAs in the domain example.com, such as:
+
+   ;;                             Priority Weight Port Target
+   _slpda._tcp.example.com IN SRV 0        0      427  da1.example.com
+   _slpda._tcp.example.com IN SRV 0        0      427  da2.example.com
+
+3.  Remote Service Discovery in SLP via DNS SRV
+
+   SLP DAs can be discovered in two ways: (1) using the mechanisms
+   described in RFC 2608, and (2) using DNS SRV RRs as described in this
+   document.  The second approach is useful for UAs to acquire service
+   information for remote DNS domains.  For example, a mobile node
+   visiting a network (without the use of mobile IP) may want to obtain
+   information about services in its home network.
+
+3.1.  The DNS Domain of Interest for Remote Service Discovery
+
+   Using DNS SRV RRs to discover SLP DAs requires knowledge of the
+   domain where SLP DAs are registered.  For remote service discovery,
+   it is assumed that the DNS domain of interest is known via a priori
+   knowledge.  For example, a UA is configured with a domain name or the
+   user provides the domain name manually.
+
+   Note that there is no implied "search order" of DNS domains in
+   finding remote DAs.  For instance, if a UA is looking for remote DAs
+   in the domain foo.bar.example.com, it SHOULD only look for
+   _slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and
+   MUST NOT fall back to look for _slp._tcp.bar.example.com,
+   _slp._tcp.example.com, and so on.
+
+
+3.2.  SLP DAs for Remote Service Discovery
+
+   A UA discovers desired services in a given remote DNS domain by
+   unicasting requests to DAs in that domain.  The UA uses remote DAs
+   according to these prioritized rules: (1) using DAs which it has been
+   configured with, and (2) using DAs which it has discovered via DNS
+   SRV.
+
+
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 3]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+3.3.  SLP Scopes for Remote Service Discovery
+
+   As SLP scopes are intended to be used only within one administrative
+   domain, they are likely incomprehensible to users outside of the
+   administrative domain.  Thus, any remotely accessible service MUST be
+   registered in the "default" scope, but it MAY be registered in other
+   scopes at the same time.  Similarly, all DAs advertised via DNS SRV
+   MUST serve the "default" scope, but they MAY serve other scopes at
+   the same time.  As a result, users wishing to discover services at a
+   remote DNS domain SHOULD only search the "default" scope.
+
+4.  Steps for Remote Service Discovery
+
+   The steps for a User Agent U to discover desired services in a remote
+   DNS domain D are as follows.
+
+   (1) U makes a DNS query for QNAME=_slpda._tcp.D (or
+       QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV.  Then, U gets a
+       list of DNS SRV RRs (referred to as L) in a DNS reply, which
+       gives all remotely accessible DAs in D.
+
+   (2) U selects a DA X from L based on the priority and weight
+       information per RFC 2782.
+
+   (3) U queries X in the "default" scope to discover desired services
+       in D.
+
+   Note that the services discovered in the above steps may not
+   necessarily be remotely accessible.
+
+5.  Security Considerations
+
+   To support remote service discovery, a domain exposes its service
+   information to the Internet.  Standard SLP authentication SHOULD be
+   used to protect valuable service information.  First, there is a risk
+   that any SA could advertise any service on a DA accessible from the
+   Internet.  Such a DA SHOULD reject all registrations and
+   deregistrations that cannot be authenticated.  Secondly, to avoid
+   disclosing unintended service information to remote users, a DA
+   accessible from the Internet SHOULD at least authenticate service
+   queries that are not in the "default" scope.  In addition, the
+   security considerations for DNS SRV [RFC2782] apply to this document.
+   Also, the DNS security extensions [RFC 2535] SHOULD be used to
+   provide origin authentication and integrity protection for DNS data.
+
+
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 4]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+6.  Applicability Statements
+
+   This specification describes remote service discovery in SLP via DNS
+   SRV.  It facilitates discovering services at a remote DNS domain if
+   the domain name is known via a priori knowledge.  However, it does
+   not intend to solve the problem of Internet-wide service discovery.
+
+   Users should be aware of two constraints in using DNS SRV to discover
+   SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the
+   "default" scope, and (2) an administrator may choose to register only
+   a subset of all DAs in the "default" scope via DNS SRV.  Thus, to
+   discover local DAs, implementations MUST use the standard SLP
+   mechanisms per RFC 2608.  In addition, implementations supporting
+   this specification MAY use DNS SRV to discover local DAs in the
+   "default" scope.
+
+   As SLP scopes are not intended to be used outside the local
+   administrative domain, all remote service discovery in SLP SHOULD be
+   carried only in the "default" scope.
+
+   Note that the services discovered via DNS SRV and remote SLP DAs may
+   not necessarily be remotely accessible.
+
+7.  IANA Considerations
+
+   In the DNS SRV RRs for SLP DA services, the symbolic name for the
+   Service field is "slpda", supported protocols are "tcp" and "udp".
+   The following values have been registered with IANA:
+
+       Service Field      Protocol Field     Reference
+       -------------      --------------     ---------
+           slpda                tcp          [RFC3832]
+           slpda                udp          [RFC3832]
+
+8.  Acknowledgments
+
+   The authors would like to thank Bernard Aboba, Kevin Arnold, Steven
+   Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark, and
+   Jon Peterson for their valuable comments.
+
+9.  Normative References
+
+   [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+             Location Protocol, Version 2 ", RFC 2608, June 1999.
+
+   [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+             specifying the location of services (DNS SRV)", RFC 2782,
+             February 2000.
+
+
+
+Zhao, et al.                  Experimental                      [Page 5]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain names - implementation and
+             specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+10.  Authors' Addresses
+
+   Weibin Zhao
+   Department of Computer Science
+   Columbia University
+   1214 Amsterdam Avenue, MC 0401
+   New York, NY 10027-7003
+
+   EMail: zwb@cs.columbia.edu
+
+
+   Henning Schulzrinne
+   Department of Computer Science
+   Columbia University
+   1214 Amsterdam Avenue, MC 0401
+   New York, NY 10027-7003
+
+   EMail: hgs@cs.columbia.edu
+
+
+   Erik Guttman
+   Sun Microsystems
+   Eichhoelzelstr. 7
+   74915 Waibstadt
+   Germany
+
+   EMail: Erik.Guttman@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 6]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+   Dr. Chatschik Bisdikian
+   IBM T. J. Watson Research Center
+   30 Saw Mill River Road, M/S 3S-B34
+   Hawthorne, NY 10532, USA
+
+   Phone: +1 914 784 7439
+   Fax:   +1 914 784 6225
+   EMail: bisdik@us.ibm.com
+
+
+   William F. Jerome
+   IBM Corp.
+   Thomas J. Watson Research Center
+   19 Skyline Drive
+   Hawthorne, NY 10532, USA
+
+   EMail: wfj@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 7]
+
+RFC 3832          Remote Discovery in SLP via DNS SRV          July 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Zhao, et al.                  Experimental                      [Page 8]
+