Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
9 August 1999 Expires in six months
Service Location Protocol Modifications for IPv6
draft-ietf-svrloc-ipv6-06.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.
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 [2]. 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 equally applies to SLP,
version 2 [3].
Guttman Expires: 9 February 1999 [Page 1]
Internet Draft Service Location Modifications for IPv6 August 1999
Table of Contents
1. Protocol Changes . . . . . . . . . . . . . . . . . . . . 2
2. Eliminating support for broadcast SLP requests . . . . . 2
3. Restricted Propagation of Link Local Addresses . . . . . 3
4. Address Specification for IPv6 Addresses in URLs . . . . 3
5. SLP multicast behavior over IPv6 . . . . . . . . . . . . 4
5.1. SLPv1 Multicast Addresses for IPv6 . . . . . . . . . . . 4
5.2. SLPv2 Multicast Addresses for IPv6 . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 6
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 Propagation 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.
Guttman Expires: 9 February 1999 [Page 2]
Internet Draft Service Location Modifications for IPv6 August 1999
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 [2].
3. Restricted Propagation 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. SLP DAs and SAs MUST NOT
respond to SLP messages when they are multihomed and use link local
addresses.
Second, the DA or SA must not be configured with a routable address.
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.
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
Guttman Expires: 9 February 1999 [Page 3]
Internet Draft Service Location Modifications for IPv6 August 1999
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, 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::A3F9:251C:1291: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::015A:93C0:D85D:B098]:8080/path
5. SLP multicast behavior over IPv6
Since IPv6 offers scoped multicast addresses, these are used instead
of setting TTL to 32. In SLPv1, for instance, the default TTL
setting was chosen to limit the propagation of discovery messages to
a site local network. SLPv1 and 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. SLPv1 Multicast Addresses for IPv6
The assigned multicast addresses for SLPv1 under IPv4 differ from
those in IPv6. These numbers are defined in [9]. Their 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
The SVRLOC-DA address is used by SLPv1 UAs and SAs to discover SLPv1
DAs. The SVRLOC address is used by SLPv1 UAs to multicast requests
to SLPv1 SAs. The range of Service Location addresses MAY be used
by SLPv1 UAs and MUST be listened for by SLPv1 SAs. This address
range is used to distribute Service Request queries over the range
Guttman Expires: 9 February 1999 [Page 4]
Internet Draft Service Location Modifications for IPv6 August 1999
of addresses. A hashing scheme is used based on the service type
of the request, as described in [2].
5.2 SLPv2 Multicast Addresses for IPv6
SLPv2 for IPv4 specifies only one multicast address. The reason only
one address was used, instead of the variety of addresses specified
for SLPv1, 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 same addresses as defined for SLPv1. 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 advertisements to the
SVRLOC-DA multicast address.
All other multicast SrvRqst 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: 9 February 1999 [Page 5]
Internet Draft Service Location Modifications for IPv6 August 1999
Acknowledgments
Thanks to Dan Harrington, Jon 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, July 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, July 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., "Preferred Format for Literal
IPv6 Addresses in URL's", <draft-ietf-ipng-url-literal-02.txt>,
July, 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: 9 February 1999 [Page 6]
Internet Draft Service Location Modifications for IPv6 August 1999
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."
Guttman Expires: 9 February 1999 [Page 7]