Internet Engineering Task Force Erik Guttman INTERNET DRAFT Sun Microsystems 20 January 1998 Expires in six months Service Location Modifications for IPv6 draft-ietf-svrloc-ipv6-03.txt Status of this Memo 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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 is well defined for use over IPv4 networks [SLP]: 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. 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 Guttman Expires: 20 July 1998 [Page 1] Internet Draft Service Location Modifications for IPv6 January 1998 - Address Specification for IPv6 Addresses in URLs - Different multicast addresses 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 4.6 (Use of TCP, UDP and Multicast in Service Location) and Section 22 (Implementation Requirements) of the Service Location Protocol [SLP]. The General Service Location Multicast address and the Directory Agent Discovery Multicast address have been assigned for IPv4, but have not yet been assigned for IPv6. This will be done as soon as possible. Restricted Propogation of Link Local Addresses Link local advertisements MUST NOT be used if the SLP Agent has a routable address. Service advertisements will include routable addresses in this case. Further, without routable addresses all User Agents (UAs), Service Agents (SAs) and Directory Agents (DAs) transmit multicast SLP messages with a TTL of 1: This includes SrvRqst, AttrRqst, SrvTypeRqst and unsolicited DAAdvert messages. This request is transmitted using a link local scope multicast address. If the SA has no routable address it may send a Service Registration to a DA using its Link Local address. This may occur in an environment where there is no router available. This address must be specified in the Service URL using an IPv6 address specification (see below.) A DA or SA MAY return URLs in SrvRply messages which contain link local IPv6 addresses to UAs, but only with several restrictions. First, the DA or SA must not be multihomed. If the DA or SA is multihomed the configuration complexity would be too great to ensure that the link local address would not be transmitted to another link. Second, the DA or SA must not be configured with a routable address. Guttman Expires: 20 July 1998 [Page 2] Internet Draft Service Location Modifications for IPv6 January 1998 Last, the SA and DA must listen only for link local multicast requests. (The DA will listen for multicast DA discovery requests, the SA will listen for various multicast requests.) If multihomed agents or routable addresses are desired for SLP with IPv6, a router MUST be deployed on the network. Address Specification for IPv6 Addresses in URLs When ever possible the DNS 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. A numerical IPv6 address used in a "service:" URL is specified as ipv6-addr = 32*HEX HEX = 'a' / 'b' / 'c' / 'd' / 'e' / 'f' / 'A' / 'B' / 'C' / 'D' / 'E' / 'F' / DIGIT 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. [IPsec] 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. Assigned numbers for IPv6 The assigned multicast addresses for SLP under IPv6 differ from those in IPv6. These numbers are defined in [MC6]. Their values are: FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades] FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades] Guttman Expires: 20 July 1998 [Page 3] Internet Draft Service Location Modifications for IPv6 January 1998 FF05:0:0:0:0:0:1:1000 Service Location [RFC2165] -FF05:0:0:0:0:0:1:13FF Site Local Scope is used with normal operation of SLP. Only when discovery is performed by hosts who have no routable addresses are multicast messages sent with Link Local Scope. Acknowledgments Thanks to Dan Harrington and Alain Durand for their thoughtful reviews of previous drafts of this document. Harald Alvestrand's suggestion to change the representation of the IPv6 addresses was also useful. John Veizades contributed to this document. References [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997 [DNS] Mockapetris, P. V. "Domain names - concepts and facilities", RFC 1034. November 1987. Mockapetris, P. V. "Domain names - implementation and specification", RFC 1035. November 1987. [IPsec] Atkinson, R. "IP Authentication Header", RFC 1826, August 1995. Atkinson, R. "IP Encapsulating Security Payload". RFC 1827, August 1995. Atkinson, R. "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [MC6] Hinden, R., Deering, S., "IPv6 Multicast Address Assignments", draft-ietf-ipngwg-multicast-assgn-04.txt, July 1997, A work in progress. [SLP] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service Location Protocol", RFC 2165, June 1997 [SURL] Guttman, E., Perkins, C., Kempf, J., "Service Templates and URLs", draft-ietf-svrloc-service-scheme-06.txt, November 1997, A work in progress. [URL] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994 Guttman Expires: 20 July 1998 [Page 4] Internet Draft Service Location Modifications for IPv6 January 1998 Author Information Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany Phone: +49 7263 911701 Email: Erik.Guttman@eng.sun.com Guttman Expires: 20 July 1998 [Page 5]