Internet Engineering Task Force John Veizades INTERNET DRAFT @Home Network 11 July 1996 Erik Guttman Expires in six months Sun Microsystems Service Location Modifications for IPv6 draft-ietf-svrloc-IPv6-00.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 the Internet 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 or 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. 1.0 Protocol Changes The following are changes required to have the Service Location Veizades, Guttman [Page 1] Internet Draft Service Location Modifications for IPv6 11 July 1996 Protocol work over IPv6. These changes include: 2.0 Eliminating support for broadcast SLP requests 3.0 Restricted Propogation of Link Local Addresses 4.0 Address Specification for IPv6 Addresses in URLs 5.0 Changes to DHCP options 2.0 Eliminating support for broadcast SLP requests Service Location over IPv4 allows broadcasts to send Service Location request messages. This is no longer supported. 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. 3.0 Restricted Propogation of Link Local Addresses A Service Agent may send a Service Registration to a Directory Agent using its Link Local address. This may occur in an environment where there is no DNS [DNS] or router available. If DNS is available, the Service Agent SHOULD register a FQDN. If DNS is present, then, this would not be an issue. If a router is available, the Service Agent may register a routable address. A Directory Agent must not propogate this Service Registration information to User Agents that request it from other links. This means that Directory Agents must inspect the URL registered by a Service Agent in a Service Registration message and ascertain whether the address included is a numerical IPv6 address which specifies a link local address. In this case, it must be returned to User Agent Service Requests only if the User Agent is on the same link as the link local address of the Service URL. This constitutes an additional requirement for Directory Agents and modifies the list given in [SLP], Section 22 (Implementation Requirements). Veizades, Guttman [Page 2] Internet Draft Service Location Modifications for IPv6 11 July 1996 4.0 Address Specification for IPv6 Addresses in URLs 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, addresses must be used to identify end systems. Systems must explicitely provide their numerical addresses in this case. The address specification for IPv6 replaces the address specification description for the "dotted decimal IP address notation" in section 21.4 of the Service Location Protocol [SLP]. The form is a string representation of the hexadecimal values of the eight 16-bit pieces of the address [AddrSpec]. The colons in the address must be escaped for the purposes of inclusion in a URL [URL]. The IPv6 address represented in a URL will take the following form: Examples: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 becomes: FEDC%3aBA98%3a7654%3a3210%3aFEDC%3aBA98%3a7654%3a3210 To add a port number (say 3431) to this address specification, a colon followed by the port number value may be appended, as follows: FEDC%3aBA98%3a7654%3a3210%3aFEDC%3aBA98%3a7654%3a3210:3431 The port number value after the colon is expressed in decimal notation, as defined in [URL]. When ever possible the DNS name of the service should be used rather than the above representation. 5.0 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 Veizades, Guttman [Page 3] Internet Draft Service Location Modifications for IPv6 11 July 1996 definition will be submitted in a formal proposal in the near future. See [DHCPv6 EXT]. 6.0 Security Considerations Security issues are not discussed in this document. 7.0 References [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, October 1993 [SLP] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service Location Protocol", Work in progress, June 1996 [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. [URL] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994 [AddrSpec] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 1884, January 1996 [DHCPV6-EXT] Perkins, C., "Extensions for DHCPv6", Work in progress, June 1996. Veizades, Guttman [Page 4] Internet Draft Service Location Modifications for IPv6 11 July 1996 8. Author Information 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 Erik Guttman Sun Microsystems 2550 Garcia Avenue, MS PAL01-550 Mountain View, CA 94043-1100 Phone: +1 415 336 6697 Fax: +1 415 336 0673 Email: Erik.Guttman@eng.sun.com 9.0 This document expires January 16, 1997. Veizades, Guttman [Page 5]