Internet Engineering Task Force Erik Guttman INTERNET DRAFT Sun Microsystems 7 January 2000 Expires in six months Service Location Protocol Modifications for IPv6 draft-ietf-svrloc-ipv6-08.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Service Location Protocol 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 Service Location Protocol, Version 2 is well defined for use over IPv4 networks [3]: This document defines its 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 [2] 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 Expires: 7 July 2000 [Page 1] Internet Draft Service Location Modifications for IPv6 January 2000 Table of Contents 1. Protocol Changes . . . . . . . . . . . . . . . . . . . . 2 2. Eliminating support for broadcast SLP requests . . . . . 2 3. Restricted Propogation of Link Local Addresses . . . . . 3 4. Address Specification for IPv6 Addresses in URLs . . . . 3 5. SLP multicast behavior over IPv6 . . . . . . . . . . . . 4 5.1. SLPv2 Multicast Addresses for IPv6 . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 5 References . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Contact Information . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . 7 1. Protocol Changes The following are changes required to have the Service Location Protocol work over IPv6. These changes include: - Eliminating support for broadcast SLP requests - Restricted Propogation of Link Local Addresses - Address Specification for IPv6 Addresses in URLs - Different multicast addresses 2. Eliminating support for broadcast SLP requests Service Location over IPv4 allows broadcasts to send Service Location request messages. IPv6 makes use of link layer 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 [3]. Guttman Expires: 7 July 2000 [Page 2] Internet Draft Service Location Modifications for IPv6 January 2000 3. Restricted Propogation of Link Local Addresses SLP allows the location of services to be obtained by hosts across the network. Some hosts on an IPv6 network have link local addresses. It is possible, unless precautions are taken, that a link local service location may be obtained on a different link. This service will not be reachable, so this possibility must be guarded against. The basic rule is that a service: URL in a SLP message may not contain a literal IPv6 address which has a scope smaller than the scope of the IPv6 destination address for that message. There are three possible scenarios where such messages could be sent. The case of link local scoped addresses is the most limiting and serves to illustrate the rule. +----+ +----+ +----+ | SA |--------| UA |--------| DA | +----+ Link 1 +----+ Link 2 +----+ Figure 1: Multihomed UA In Figure 1 the UA is multihomed. The UA can issue a service request on Link 1 and discover a service from the SA. The service reply could include a service: URL with a link local name. The UA MUST issue requests to the service advertised by the SA using its interface to Link 1 not to Link 2. If the UA only has a link local address, all multicast requests it sends with SLP MUST have a link local multicast scope. +----+ +----+ +----+ | UA |--------| SA |--------| DA | +----+ Link 1 +----+ Link 2 +----+ Figure 2: Multihomed SA In Figure 2, the SA is multihomed. The SA may receive a request from the UA on Link 1. It MUST NOT return a link local address to the UA which is not in the same link local scope as the request. For example, the SA MUST NOT return an address which corresponds to its interface on Link 2, rather it MUST return its address on Link 1. The SA may receive a DAAdvert on Link 2. The SA MUST NOT send a service registration to the DA with a link local address which is not in the same link local scope as the interface which the DAAdvert arrived on. For example, the SA MUST NOT register service: URL with the DA which Guttman Expires: 7 July 2000 [Page 3] Internet Draft Service Location Modifications for IPv6 January 2000 contains a link local address from Link 1. It could register a service: URL which contains a link local address from Link 2. The SA MUST NOT include a link local address in a SAAdvert message which is for a different link than that where the message is sent. For example, the UA could receive a SAAdvert from the SA with a Link 1 link local address. Like the UA, the SA MUST use link local scope multicast to solicit DAAdverts (when doing DA discovery), if the SA has only been configured with a link local address. +----+ +----+ +----+ | UA |--------| DA |--------| SA | +----+ Link 1 +----+ Link 2 +----+ Figure 3: Multihomed DA In Figure 3, 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 Link 2 link local address from being discovered by the UA. Further, DAAdvert messages which are sent on Link 1 and Link 2 may only be sent with a link local multicast scope if they contain link local addresses. The DAAdvert message sent on Link 1 would contain a Link 1 link local address, on Link 2, it would contain a Link 2 link local address. The discussion above applies equally well to 'site local' scoped addresses. If the UA or SA only has a site local address, they may only issue multicast requests (for service or DA discovery) using a site local address. The SA or DA must not propogate service: URLs containing site local addresses from one site to another. 4. Address Specification for IPv6 Addresses in URLs When ever possible the DNS [4] name of the service should be used rather than the above representation. 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 [5]. This URL is an ``absolute URI'' as defined by [6]. A numerical IPv6 address, Guttman Expires: 7 July 2000 [Page 4] Internet Draft Service Location Modifications for IPv6 January 2000 such as may be used in a "service:" URL, is specified as in [7]. The textual representation defined for literal IPv6 addresses in [8]: 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 5. SLP multicast behavior over IPv6 SLPv2 agents MUST use the site local scope for transmission of multicast messages, unless configured to use a more restrictive scope (for example, the link local scope). 5.1 SLPv2 Multicast Addresses for IPv6 SLPv2 for IPv4 specifies only one multicast address. The reason only one address was used, is that there are only 255 relative assignments available for the Administratively Scoped Addresses [10]. IPv6, on the other hand, has scoped addresses and enough range for static assignments. SLPv2 for IPv6 uses the following multicast address assignments: FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades] FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades] FF0X:0:0:0:0:0:1:1000 Service Location [RFC2165]+??? -FF0X:0:0:0:0:0:1:13FF [NOTE: FF05::1:1000 - FF05::1:13FF has been registered. FF01::1:1000 - FF01::1:13FF must also be registered; they have not yet been.] SLP Agents using IPv6 which have only been configured with a link local scope MUST issue only multicast messages to a link local address. SLP Agents using IPv6 which have site local or global scoped address MUST send requests to site local scope. Guttman Expires: 7 July 2000 [Page 5] Internet Draft Service Location Modifications for IPv6 January 2000 SLP Agents which join any of the above multicast groups MUST join both local and site scoped multicast groups. This ensures that a SA or DA will be able to receive messages sent by other SLP Agents whatever scope they have been configured with. The SVRLOC address is used for the following messages: Service Type Request and Attribute Request messages. The SVRLOC-DA address is used for multicast Service Requests for the "service:directory-agent" service type. DAs send unsolicited DA Advert messages to the SVRLOC-DA multicast address. All other multicast Service Request messages are sent to the appropriate Service Location multicast address. SAs join the groups which correspond to the Service Types of the services they advertise. The address is determined using the algorithm provided in SLPv1. The Service Type string used in the SrvRqst is hashed to a value from 0-1023. This determines the offset into the FF05::1:1000-13FF range. An unsigned 32 bit value V is initialized to 0. Each byte of the Service Type UTF-8 [11] encoded string value is considered consecutively. First, the value V is multiplied by 33, then the value of the current string byte is added. The result is contained in the low order 10 bits of V. 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 in Service Location messages whenever an appropriate IPSec Security Association exists. [12] 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. Guttman Expires: 7 July 2000 [Page 6] Internet Draft Service Location Modifications for IPv6 January 2000 Acknowledgments Thanks to Dan Harrington, Jim Wood and Alain Durand for their thoughtful reviews of previous drafts of this document. John Veizades contributed to the original version of this document. References [1] Bradner, S., "The Internet Standards Process -- Version 3", RFC 2026, October 1996. [2] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service Location Protocol", RFC 2165, June 1997 [3] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location Protocol, Version 2", RFC 2608, June 1999. [4] Mockapetris, P. V. "Domain names - concepts and facilities", RFC 1034. November 1987. Mockapetris, P. V. "Domain names - implementation and specification", RFC 1035. November 1987. [5] Guttman, E., Perkins, C., Kempf, J., "Service Templates and URLs", RFC 2609, Juny 1999. [6] Berners-Lee, T., Fielding, R., and Masinter, L. "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Hinden, R., Carpenter, B., "Format for Literal IPv6 Addresses in URL's", , September, 1999. [8] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [9] Hinden, R., Deering, S., "IPv6 Multicast Address Assignments", RFC 2375, July 1997. [10] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [12] Kent, S., Atkinson, R. "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Guttman Expires: 7 July 2000 [Page 7] Internet Draft Service Location Modifications for IPv6 January 2000 Author's Contact Information Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Phone: +49 7263 911701 Email: Erik.Guttman@germany.sun.com Full Copyright Statement Copyright (C) The Internet Society (1999). 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 Expires: 7 July 2000 [Page 8]