Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
3 July 2000
Expires in six months
Service Location Protocol Modifications for IPv6
draft-ietf-svrloc-ipv6-09.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: 3 January 2000 [Page 1]
Internet Draft Service Location Modifications for IPv6 July 2000
Table of Contents
1. Protocol Changes . . . . . . . . . . . . . . . . . . . . 2
2. Eliminating support for broadcast SLP requests . . . . . 2
3. Address Specification for IPv6 Addresses in URLs . . . . 3
4. SLP multicast behavior over IPv6 . . . . . . . . . . . . 3
4.1. SLPv2 Multicast Addresses for IPv6 . . . . . . . . . . . 4
4.2. SLPv2 Multicast Scopes for IPv6 . . . . . . . . . . . . 5
5. Restricted Propagation of Service Advertisements . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Contact Information . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . 11
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
- Address Specification for IPv6 Addresses in URLs
- Use of IPv6 multicast addresses and IPv6 address scopes
- Restricted Propagation of Service Advertisements
2. Eliminating support for broadcast SLP requests
Service Location over IPv4 allows broadcasts to send Service Location
request messages. IPv6 makes use of link-local 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
Guttman Expires: 3 January 2000 [Page 2]
Internet Draft Service Location Modifications for IPv6 July 2000
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].
3. Address Specification for IPv6 Addresses in URLs
Whenever possible the DNS [4] name of the service should be used
rather than the numerical representation described in this section.
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, 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
4. SLP multicast behavior over IPv6
Section 4.1 describes how different multicast addresses are used for
transmitting and receiving different SLPv2 messages. Section 4.2
describes which scope these addresses have.
Guttman Expires: 3 January 2000 [Page 3]
Internet Draft Service Location Modifications for IPv6 July 2000
4.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 a range of
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
-FF0X:0:0:0:0:0:1:13FF
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 FF0X::1:1000-13FF range.
The has algorithm is defined as follows:
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. The current value V is multiplied by 33, then the
value of the current string byte is added. Each byte in the Service
Type string is processed in this manner. The result is contained in
the low order 10 bits of V. For example, the following code
implements this algorithm:
unsigned long slp_hash(const char *pc, unsigned int len) {
unsigned long h = 0;
while (len-- != 0) {
h *= 33;
h += *pc++;
}
return (0x3FF & h); /* round to a range of 0-1023 */
}
Guttman Expires: 3 January 2000 [Page 4]
Internet Draft Service Location Modifications for IPv6 July 2000
4.2 SLPv2 Multicast Scopes for IPv6
SLPv2 agents MAY use either the site-local scope or link-local scope
for transmission of multicast messages. Site-local scope multicast
discovery messages will discover services in the same site (whose
addresses are either of site-local or global scope). Link- local
scope multicast messages will only discover services whose location
is on the same link.
SLPv2 SAs and DAs MUST join multicast groups in both of the following
scopes: site-local scope (FF05) and link-local (FF02). If an SLP
agent does not have a site-local or global scope address, it MUST
join only the link-local scoped group.
Joining both site-local and link-local scope multicast groups ensures
that services advertised by SAs and DAs are discoverable by SLPv2
agents whichever multicast scope they issue their requests in.
SLP agents MAY join the SVRLOC-DA group in order to receive DAAdverts
which are sent by each DA periodically. The SLPv2 agent MUST join
both the site- and link-local scoped SVRLOC-DA multicast group
(provided it has been configured with either site-local or global
scoped address.) That way the SLP agent can detect a DA whether the
DAAdvert is sent using link-local or site-local scope multicast.
5. Restricted Propagation of Service Advertisements
Section 4.2 defines which multicast scope to use for issuing requests
as well as rules for listening for them. These rules ensure that:
A. Hosts with a configured site-local or global scope address which
issue requests using the site-local multicast scope will only
discover services which are advertised by SAs which are
configured with site-local or global scope addresses. These
requests may discover services advertised in the local site.
B. Hosts which issue link-local multicast requests will do so with a
link-local source address. These requests will only discover
services advertised on that link.
It is possible, unless precautions are taken, that a link-local
service location may be obtained on a different link. Further, a
host which is multihomed and attached to two different sites, could
propagate a service location with a site-local address from one site
to the other. These services will not be reachable, so SLPv2 must
not allow their discovery.
The following rules prevent this possibility:
1. URLs containing literal IPv6 addresses MUST NOT be sent to a
Guttman Expires: 3 January 2000 [Page 5]
Internet Draft Service Location Modifications for IPv6 July 2000
destination address which has a scope different than the scope
of than that of the URL address.
This prevents the possibility that a UA with a link-local address
will obtain a site-local or global scope address for a service and be
unable to use it (since the service may be on another link.)
This also prevents the possibility that a UA with a site-local or
global scope address will obtain a link-local address for a service
for a link other than that to which the UA is attached.
2. SAs and DAs which are multihomed MUST NOT propagate service
advertisements beyond their the scope of the advertisement.
2.1 Service Locations (in SrvReg, SrvRply, SAAdvert or DAAdvert
messages) whose locations are link-local scoped addresses
MUST only be sent to SLP agents located on the same link
as the service.
Each interface of a multihomed device is potentially on a
separate link. It is often difficult to determine whether
two interfaces are connected to the same link. For that
reason a prudent policy is to not issue SLP messages containing
link-local service locations except on the interface where the
service is known to reside.
2.2 If a multihomed host is configured with more than one site-local
address (in more than one site), special rules apply. Service
Locations (in SrvReg, SrvRply, SAAdvert or DAAdvert messages)
whose locations are site-local scoped addresses MUST only be
sent to SLP agents located in the same site as the service.
There are three possible scenarios where such messages could be sent.
+----+ +----+ +----+
| SA |--------| UA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
or or
Site 1 Site 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. There are two
possibilities. (1) The UA issues a request using a link-local
source address. The SA replies with a service with a link-local
address. (2) The UA issues a request with a site-local (site 1) or
global address. The SA responds with a service advertisement
containing a site-local (site 1) or global scope address.
Guttman Expires: 3 January 2000 [Page 6]
Internet Draft Service Location Modifications for IPv6 July 2000
In both cases, the UA will be able to communicate with the service
whose location it obtains from the SA.
The UA may also issue a request to the DA it discovers on Link 2. If
it issues a request to the DA using a link-local address, the DA MUST
only return services advertisements whose location is on the same
link (link 2). If the UA's request is sent with a source address
which is site-local or global scope, the DA may return service
advertisements whose locations are in the same site (site 2) or whose
addresses are global scope.
The UA MUST use active discovery to detect DAs before issuing
multicast requests, as per SLPv2 [3].
To discover services on an attached link, in the absence of DAs on
the link, the UA issues multicast requests in link-local scope, (from
a link-local source address).
If the UA is unable to discover any DAs using site-local scoped
multicast discovery, it may issue site-local scope multicast requests
(with a site-local or global scope source address.) These SLPv2
messages may discover services with site-local or global scope
addresses.
+----+ +----+ +----+
| UA |--------| SA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
or or
Site 1 Site 2
Figure 2: Multihomed SA
In Figure 2, the SA is multihomed. The SA may receive a request from
the UA on Link 1, Site 1. The SA MUST NOT return a link-local
address to the UA which is not in the same link-local scope as the
request. The SA MUST NOT return a site-local address to the UA which
is not in the same site as the UA, either. For example, the SA MUST
NOT return an address for a service which is advertised on link 2,
site 2.
The SA may receive a DAAdvert on Link 2, site 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. The SA MUST NOT send a service registration to
the DA with a site 1 site-local scope to the DA either.
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.
The SA MUST NOT include a site-local address in a SAAdvert message to
a site other than where the site-local scope is valid. For example,
Guttman Expires: 3 January 2000 [Page 7]
Internet Draft Service Location Modifications for IPv6 July 2000
the UA could receive a SAAdvert from the SA containing a URL with a
Link 1 link-local address or a site-local scope valid in site 1.
The SA MUST use both site-local and link-local scope multicast to
solicit DAAdvertisements and detect them actively and passively,
unless the SA is only configured with a link-local address. In that
case it MUST at least use link-local scope multicast to detect DAs.
+----+ +----+ +----+
| UA |--------| DA |--------| SA |
+----+ Link 1 +----+ Link 2 +----+
or or
Site 1 Site 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. The DA MUST prevent a registration
from the SA with a Site 2 site-local address from being discovered by
the UA, also.
Care must be taken when issuing DAAdverts. The DA must respond to
active DA discovery requests using the same scope as the request.
For instance, if the SA issues a SrvRqst message for service type
"service:directory" from a link-local source address, the DA MUST
respond with a link-local (link 2) source address. The DAAdvert
would contain a DA URL with a link 2 link-local address as well.
The DA must multicast unsolicited DAAdverts on each interface using
link-local source (and DA URL) with link-local scope multicast. If
the DA has a site-local or global scoped address, it MUST multicast
unsolicited DAAdverts on each interface using site-local scoped
multicast, as well. That way all SLP agents on the link and the site
will be able to discover the DA.
6. IANA Considerations
The following IPv6 multicast address range assignment must be
registered with IANA.
FF0X::1:1000 - FF0X::1:13FF For SLPv2 service discovery.
This document defines how to use SLPv2 for link-local and site-local
scope service discovery. Future documents may define how SLPv2 may
be used with other multicast scopes.
The following address range has already been registered [9].
Guttman Expires: 3 January 2000 [Page 8]
Internet Draft Service Location Modifications for IPv6 July 2000
FF05::1:1000 - FF05::1:13FF For site-local service discovery.
7. 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 for issuing and
processing 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: 3 January 2000 [Page 9]
Internet Draft Service Location Modifications for IPv6 July 2000
Acknowledgments
Thanks to Dan Harrington, Jim Wood and Alain Durand, Thomas Narten
and Erik Nordmark for their reviews of this document. John Veizades
contributed to the original version of this document. The hash
function is modified from a code fragment attributed to Chris Torek.
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", RFC 2732 , December, 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: 3 January 2000 [Page 10]
Internet Draft Service Location Modifications for IPv6 July 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: 3 January 2000 [Page 11]
