Internet Engineering Task Force Erik Guttman INTERNET DRAFT Sun Microsystems 18 November 1997 John Veizades Expires in six months @Home Network Service Location Modifications for IPv6 draft-ietf-svrloc-ipv6-02.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. Guttman, Veizades Expires: 18 May 98 [Page 1]
Internet Draft Service Location Modifications for IPv6 November 1997 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 - Changes to DHCP options - 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 there is a router in the network. Service advertisements will include routable addresses in this case, where the addresses can be obtained with [ADDRCONF]. If there is no router, a Service Agent may send Service Registrations to a Directory Agent using its Link Local address. This may occur in an environment where there is no router available. As discussed in [LINKNAME], fully qualified domain names (FQDN) should not be associated with a link local address. Service Agents MAY respond to multicast requests with link local scope from UAs with either link local numerical addresses or link local names (see [LINKNAME] for a definition of link local name Guttman, Veizades Expires: 18 May 98 [Page 2]
Internet Draft Service Location Modifications for IPv6 November 1997 resolution.) A DA MAY propogate URLs with link local names or numeric addresses to User Agents, but only with several restrictions. This is further complicated by the possibility of a Directory Agent with multiple interfaces, on different links. DAs which have multiple interfaces may receive service advertisements from SAs which include a URL with a link local address. The DA MUST keep track of which link this service advertisement arrived on. The DA MUST NOT forward this service advertisement on any link other than that on which it was registered. A multihomed DA which cannot tell its interfaces apart (for whatever reason) MUST NOT forward link local addresses. 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 service locations. Changes to DHCP Options The DHCP options for use in Service Location have been submitted to the IANA and DHCP working group of the IETF for standardization. One of these option returns the IPv4 address of the Directory Agent for a host to use. This option will have to be changed for IPv6 so that the Directory Agent address will be 128 bits wide. This new option definition will be submitted in a formal proposal in the near future. 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] In the absense of the IP security associations, the Service Location Protocol may easily be abused to provide false advertisements or to deregister valid advertisements. It is therefore highly recommended Guttman, Veizades Expires: 18 May 98 [Page 3]
Internet Draft Service Location Modifications for IPv6 November 1997 that sites which deploy the Service Location Protocol also deploy the necessary framework to support ip security. Assigned numbers for IPv6 The assigned multicast addresses for SLP under IPv6 differ from those in IPv6. These numbers are defined in [MC6]. The values are: FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades] FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades] FF05:0:0:0:0:0:1:1000 Service Location [RFC2165] -FF05:0:0:0:0:0:1:13FF 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. References [ADDRCONF] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, October 1993 [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. [LINKNAME] Harrington, D., "Link Local Addressing and Name Resolution in IPv6", draft-ietf-ipngwg-linkname-01.txt, January 1997. A work in progress. Guttman, Veizades Expires: 18 May 98 [Page 4]
Internet Draft Service Location Modifications for IPv6 November 1997 [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-04.txt, November 1997. A work in progress. [URL] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994. Author Information Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany Phone: +49 7263 911701 Email: Erik.Guttman@eng.sun.com John Veizades @Home Network 385 Ravendale Dr. Mountain View, CA 94043 Phone: +1 415 944 7332 Fax: +1 415 944 8500 Email: veizades@home.net Guttman, Veizades Expires: 18 May 98 [Page 5]
