< draft-ietf-svrloc-ipv6-11.txt		draft-ietf-svrloc-ipv6-12.txt >
	Internet Engineering Task Force Erik Guttman		A new Request for Comments is now available in online RFC libraries.
	INTERNET DRAFT Sun Microsystems
	16 October 2000 Expires in six months
	Service Location Protocol Modifications for IPv6
	draft-ietf-svrloc-ipv6-11.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.
	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 Group-IDs for IPv6 . . . . . . . . . . 3
	4.2. SLPv2 Scoping Rules for IPv6 . . . . . . . . . . . . . 4
	4.2.1 Joining SLPv2 Multicast Groups . . . . . . . . . . . . 5
	4.2.2 Sending SLPv2 Multicast Messages . . . . . . . . . . . 5
	4.2.3 Rules for Message Processing . . . . . . . . . . . . . 6
	4.2.4 SLPv2 Agents with multiple interfaces . . . . . . . . 6
	4.2.4.1 General Rules . . . . . . . . . . . . . . . . . . . . 7
	4.2.4.2 Multihomed UA . . . . . . . . . . . . . . . . . . . . 7
	4.2.4.3 Multihomed SA . . . . . . . . . . . . . . . . . . . . 8
	4.2.4.4 Multihomed DA . . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . 9
	6. 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
	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 and unicast behavior over IPv6
	Section 4.1 describes how different multicast addresses are used for
	transmitting and receiving SLPv2 messages over IPv6. Section 4.2
	defines rules for the use of these addresses and covers scoped
	address issues in general.
	4.1 SLPv2 Multicast Group-IDs for IPv6
	SLPv2 for IPv4 specifies only one multicast address, relative to an
	Administratively Scoped Address range [10]. The reason only one
	address was used is that there are only 256 relative assignments
	available for this purpose. IPv6, on the other hand, has scoped
	addresses and enough space for a range of assignments.
	SLPv2 for IPv6 uses the following multicast group-id assignments:
	FF0X:0:0:0:0:0:0:116 SVRLOC
	FF0X:0:0:0:0:0:0:123 SVRLOC-DA
	FF0X:0:0:0:0:0:1:1000 Service Location
	-FF0X:0:0:0:0:0:1:13FF
	These group-ids are combined with the scope prefix of the scope to
	which the multicast message is to be sent.
	The SVRLOC group-id is used for the following messages: Service Type
	Request and Attribute Request messages.
	The SVRLOC-DA group-id is used for multicast Service Requests for the
	"service:directory-agent" service type. Also, DAs send unsolicited
	DA Advert messages to the SVRLOC-DA multicast group-id.
	All other multicast Service Request messages are sent to the
	appropriate Service Location multicast group-id. SAs join the groups
	which correspond to the Service Types of the services they advertise.
	The group-id is determined using the algorithm provided in SLPv1 [2].
	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 hash 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 */
	}
	4.2 SLPv2 Scoping Rules for IPv6
	IPv6 provides different scopes for interface address configuration
	and multicast addresses. A SLPv2 Agent might discover services that
	it cannot use or not discover services which it could use unless
	rules are given to prevent this.
	Say a SLPv2 UA, for example, could request a service using site-local
	scope multicast and obtain a service: URL containing a link-local
	literal address. If the service referred to were not on the same
	link as the SLPv2 UA, the service could not be reached.
	4.2.1 Joining SLPv2 Multicast Groups
	A SLPv2 Agent MAY send a multicast message using any scope which it
	is allowed to (see section 4.2.2). A SA and a DA MUST join all
	groups to which a SLPv2 Agent may send a message. This ensures that
	the SA or DA will be able to receive all multicast messages.
	Specifically, a SLPv2 Agent MUST NOT join a multicast group which has
	greater scope for an interface than it is configured with for use
	with unicast. For example, an interface which is only configured
	with a link-local address joins groups in scopes with FF01 and FF02.
	If the interface is configured with a site-local or global address,
	the scope of all multicast groups joined can be no greater than scope
	FF05. In this case, SLPv2 SAs and DAs MUST join multicast groups in
	all the following scopes: FF01 - FF05.
	A DA MUST join the SVRLOC-DA group to receive SrvRqst messages
	requesting DAAdverts.
	A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
	A SA MUST join the groups from the Service Location range of group-
	ids to receive SrvRqst messages. The SA only joins those groups
	corresponding to services it advertises. For example, a service
	agent which responds to requests for "service:service-agent" (used
	for SA discovery), would join groups with the group-id derived from
	the hash function defined in section 4.1:
	group-id to join = slp_hash("service:service-agent") + base address
	= 472 + FF0X:0:0:0:0:0:1:1000
	= FF0X:0:0:0:0:0:1:1472
	The SA MAY join the SVRLOC group in order to receive SrvTypeRqst and
	AttrRqst messages; these features are OPTIONAL for the SA to
	implement.
	A UA MAY join the SVRLOC-DA group at any or all of these scopes in
	order to receive DAAdvert messages.
	4.2.2 Sending SLPv2 Multicast Messages
	The maximum scope for a SLPv2 multicast message is site-local (FF05).
	Multicast SLPv2 messages are sent using a particular scope. An SLPv2
	agent MUST issue this request using a source address with a scope no
	less than the scope of the multicast group.
	This prevents, for example, a site-local multicast message being sent
	from a link-local source address.
	A SLPv2 UA with an interface configured with at least one global
	address could multicast a SrvRqst to any scope up to and including
	site-local, for instance.
	4.2.3 Rules for Message Processing
	SLPv2 SAs and DAs MUST determine which scope a service: URL address
	is in. This may be possible by examining the URL if it contains a
	numerical IPv6 address. If the URL contains a host name, the SA or
	DA MUST resolve that name to a set of addresses.
	A SLPv2 SA or DA MUST NOT respond to a SrvRqst with a service: URL
	for a service with an address scope less than the request's source
	address scope. The rules are given in Figure 1, below.
	Request Source Address Scope
	+------------+------------+---------+
	| Link-Local | Site-Local | Global |
	+-------------+------------+------------+---------+
	Service | Link-Local | Respond | Drop | Drop |
	Address +-------------+------------+------------+---------+
	Scope | Site-Local | Respond | Respond | Drop |
	+-------------+------------+------------+---------+
	| Global | Respond | Respond | Respond |
	+-------------+------------+------------+---------+
	Figure 1: Out-of-Scope Rules
	This prevents UAs from being able discover service: URLs for services
	which cannot be accessed.
	4.2.4 SLPv2 Agents with multiple interfaces
	A scope zone, or a simply a zone, is a connected region of topology
	of a given scope. For example, the set of links connected by routers
	within a particular site, and the interfaces attached to those links,
	comprise a single zone of site-local scope. To understand the
	distinction between scopes and zones, observe that the topological
	regions within two different sites are considered to be two DIFFERENT
	zones, but of the SAME scope.
	A host which has multiple interfaces attached to different links is
	by definition is attached to two link-local zones. A host may also
	be attached to multiple zones of other scopes.
	A SLPv2 Agent MUST NOT propagate service advertisements from one zone
	to another. Another way of saying this is a SLPv2 SA or DA MUST NOT
	respond to a request from one zone with service information
	associated with a service in a different scope.
	The specific implication of these rules is discussed in the sections
	which follow.
	4.2.4.1 General rules
	Service Locations (in SrvReg, SrvRply, AttrRst, SAAdvert or DAAdvert
	messages) whose locations are literal addresses MUST only be sent to
	SLP agents located on the same zone.
	For example, a service: URL containing a link-local address on link A
	may be sent in a SLPv2 message on link A, to a link-local destination
	address only.
	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 implementation
	strategy is to not issue SLP messages containing link-local service
	locations except on the interface where the service is known to
	reside.
	4.2.4.2 Multihomed UA
	+----+ +----+ +----+
	| SA |--------| UA |--------| DA |
	+----+ Link 1 +----+ Link 2 +----+
	(Zone 1) (Zone 2)
	Figure 2: Multihomed UA
	In Figure 2 the UA is multihomed. The UA can issue a service request
	in Zone 1 and discover services on the SA or in Zone 2 and discover
	services advertised by the DA. For example, if the request is issued
	from a link-local source address, the SA will only reply with a
	service available on link 1, the DA only with a service available on
	link 2.
	The UA MUST use active discovery to detect DAs before issuing
	multicast requests, as per SLPv2 [3]. The UA MUST issue requests
	using increasing multicast scopes starting at FF01 and increasing to
	a maximum scope of FF05, to solicit DAAdvertisements. Note the
	restrictions in Section 4.2.2.
	If the UA is unable to discover any DAs using multicast discovery, it
	may issue site-local scope (FF05) or less multicast requests. Note
	that the source address of the request must be of at least the scope
	of the multicast, as described in section 4.2.2.)
	If the UA wishes to discover all services, it must issue requests
	into both Zone 1 and 2.
	4.2.4.3 Multihomed SA
	+----+ +----+ +----+
	| UA |--------| SA |--------| DA |
	+----+ Link 1 +----+ Link 2 +----+
	(Zone 1) (Zone 2)
	Figure 3: Multihomed SA
	In Figure 3, the SA is multihomed. The SA may receive a request from
	the UA on Link 1 (Zone 1). The SA MUST NOT return service
	information for services offered on a different zone as a request.
	For example, the UA could discover services offered in Zone 1 not
	Zone 2.
	The SA may receive a DAAdvert on Link 2 (Zone 2). The SA MUST NOT
	send a service registration to the DA for a service which is present
	in Zone 1. The SA MUST register a service with the DA which is
	present in Zone 2.
	The SA MUST NOT include an address in a SAAdvert message which is
	sent on a zone where the address is not valid. For example, the SA
	MUST NOT send a SAAdvert onto link 2, if the SAADvert contains a
	service: URL with a literal link-local scoped IPv6 address for Link
	1.
	The SA performs active DA discovery, as described in SLPv2 [3]. The
	SA MUST issue requests using multicast scope FF02 to solicit
	DAAdvertisements. If the SA has a site-local or global source
	address, it MUST reissue the request with increasing scopes up to a
	maximum scope of FF05. Active DA discovery must be attempted in both
	Zone 1 and 2. This ensures that the SA will discover as many DAs in
	its scope as possible.
	4.2.4.4 Multihomed DA
	+----+ +----+ +----+
	| UA |--------| DA |--------| SA |
	+----+ Link 1 +----+ Link 2 +----+
	(Zone 1) (Zone 2)
	Figure 4: Multihomed DA
	In Figure 4, 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 service information valid
	in one zone from being discovered in another zone. For example,
	services registered by the SA in Zone 2 would not be discoverable by
	the UA in Zone 1.
	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 DA MUST multicast unsolicited DAAdverts on each interface using
	link-local and site-local source addresses, unless it is only
	configured with a link-local address. In that case, the DA MUST
	issue DAAdverts with link-local scope only.
	The DA URL MUST contain the address of the greatest scope the DA is
	configured with in the zone. For instance, if the DA is configured
	with a link-local, site-local and global address in Zone 2, it would
	use the global address in the DA URL (as a literal IPv6 address).
	5. IANA Considerations
	The following IPv6 multicast group-id 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 multicast group-id range has already been registered
	[9].
	FF05::1:1000 - FF05::1:13FF For site-local service discovery.
	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 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.
	Acknowledgments
	Thanks to Dan Harrington, Jim Wood and Alain Durand, Thomas Narten,
	Dave Thaler 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. Text on Scope Zones is taken from writing by Steve
	Deering, Brian Haberman and Brian Zill.
	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, 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., "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,		RFC 3111
	July 1998.
	[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646",		Title: Service Location Protocol Modifications for IPv6
	RFC 2279, January 1998.		Author(s): E. Guttman
			Status: Standards Track
			Date: May 2001
			Mailbox: Erik.Guttman@germany.sun.com
			Pages: 13
			Characters: 25543
			Updates/Obsoletes/SeeAlso: None
	[12] Kent, S., Atkinson, R. "Security Architecture for the Internet		I-D Tag: draft-ietf-svrloc-ipv6-12.txt
	Protocol", RFC 2401, November 1998.
	Author's Contact Information		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3111.txt
	Erik Guttman		This document defines the Service Location Protocol Version 2's
	Sun Microsystems		(SLPv2) use over IPv6 networks. Since this protocol relies on UDP and
	Eichhoelzelstr. 7		TCP, the changes to support its use over IPv6 are minor.
	74915 Waibstadt Germany
	Phone: +49 7263 911701		This document does not describe how to use SLPv1 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.
	Email: Erik.Guttman@germany.sun.com		This document is a product of the Service Location Protocol
			Working Group of the IETF.
	Full Copyright Statement		This is now a Proposed Standard Protocol.
	Copyright (C) The Internet Society (1999). All Rights Reserved.		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	This document and translations of it may be copied and furnished to		This announcement is sent to the IETF list and the RFC-DIST list.
	others, and derivative works that comment on or otherwise explain it		Requests to be added to or deleted from the IETF distribution list
	or assist in its implementation may be prepared, copied, published		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	and distributed, in whole or in part, without restriction of any		added to or deleted from the RFC-DIST distribution list should
	kind, provided that the above copyright notice and this paragraph are		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	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		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	revoked by the Internet Society or its successors or assigns.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and the information contained herein is provided on an		To: rfc-info@RFC-EDITOR.ORG
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		Subject: getting rfcs
	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		help: ways_to_get_rfcs
	Funding for the RFC Editor function is currently provided by the		Requests for special distribution should be addressed to either the
	Internet Society.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 15 change blocks.
	530 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/