GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3111

Network Working Group E. Guttman Request for Comments: 3111 Sun Microsystems Category: Standards Track May 2001

          Service Location Protocol Modifications for IPv6

Status of this Memo

 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.

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

 This document defines the Service Location Protocol Version 2's
 (SLPv2) 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 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 Standards Track [Page 1] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

Table of Contents

 1.   Introduction  . . . . . . . . . . . . . . . . . . . . . .  2
 2.   Eliminating support for broadcast SLP requests  . . . . .  3
 3.   Address Specification for IPv6 Addresses in URLs  . . . .  3
 4.   SLP multicast behavior over IPv6  . . . . . . . . . . . .  4
 4.1.    SLPv2 Multicast Group-IDs for IPv6 . . . . . . . . . .  4
 4.2.    SLPv2 Scoping Rules for IPv6 . . . . . . . . . . . . .  5
 4.2.1   Joining SLPv2 Multicast Groups . . . . . . . . . . . .  5
 4.2.2   Sending SLPv2 Multicast Messages . . . . . . . . . . .  6
 4.2.3   Rules for Message Processing . . . . . . . . . . . . .  6
 4.2.4   SLPv2 Agents with multiple interfaces  . . . . . . . .  7
 4.2.4.1 General Rules  . . . . . . . . . . . . . . . . . . . .  7
 4.2.4.2 Multihomed UA  . . . . . . . . . . . . . . . . . . . .  8
 4.2.4.3 Multihomed SA  . . . . . . . . . . . . . . . . . . . .  8
 4.2.4.4 Multihomed DA  . . . . . . . . . . . . . . . . . . . .  9
 5.   IANA Considerations . . . . . . . . . . . . . . . . . . . 10
 6.   Security Considerations . . . . . . . . . . . . . . . . . 10
      Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
      References  . . . . . . . . . . . . . . . . . . . . . . . 11
      Author's Address  . . . . . . . . . . . . . . . . . . . . 12
      Full Copyright Statement  . . . . . . . . . . . . . . . . 13

1. Introduction

 The Service Location Protocol (SLP) 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 following are changes required to have the Service Location
 Protocol work over IPv6.  These changes include:
  1. Eliminating support for broadcast SLP requests
  1. Address Specification for IPv6 Addresses in URLs
  1. Use of IPv6 multicast addresses and IPv6 address scopes
  1. Restricted Propagation of Service Advertisements
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [4].

Guttman Standards Track [Page 2] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

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 [2].

3. Address Specification for IPv6 Addresses in URLs

 Whenever possible the DNS [5] 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 [6].  This URL is an
 "absolute URI" as defined by [7].
 A numerical IPv6 address, such as may be used in a "service:" URL, is
 specified as in [8].  The textual representation defined for literal
 IPv6 addresses in [9]:
    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

Guttman Standards Track [Page 3] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

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 [11].  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 [3].
 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 [12] 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:

Guttman Standards Track [Page 4] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

    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:

Guttman Standards Track [Page 5] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

 group-id to join = slp_hash("service:service-agent") + base address
                  = 0x01d8 + FF0X:0:0:0:0:0:1:1000
                  = FF0X:0:0:0:0:0:1:11d8
 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.

Guttman Standards Track [Page 6] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

                             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 zone.
 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.

Guttman Standards Track [Page 7] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

 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 [2].  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

Guttman Standards Track [Page 8] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

 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 [2].  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.

Guttman Standards Track [Page 9] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

 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 IPv6 multicast group-id range FF05::1:1000 - FF05::1:13FF was
 previously assigned by IANA in RFC 2375 for use by SLP [10].
 This document defines how the range of addresses FF0X::1:1000 -
 FF0X::1:13FF is used.  IANA has assigned this range of addresses for
 use by Service Location Protocol.
 This document fully defines the multicast addresses that this
 protocol will use.  There is no requirement for the IANA to establish
 a registry to assign additional addresses.

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 [13].
 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.

Guttman Standards Track [Page 10] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

References

 [1]  Bradner, S., "The Internet Standards Process -- Version 3", BCP
      9, RFC 2026, October 1996.
 [2]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
      Location Protocol, Version 2", RFC 2608, June 1999.
 [3]  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
      Location Protocol", RFC 2165, June 1997.
 [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [5]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
      13, RFC 1034, November 1987.
      Mockapetris, P., "Domain Names - Implementation and
      Specification", STD 13, RFC 1035,  November 1987.
 [6]  Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
      URLs", RFC 2609, July 1999.
 [7]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
      Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
 [8]  Hinden, R. and B. Carpenter, "Format for Literal IPv6 Addresses
      in URL's", RFC 2732, December 1999.
 [9]  Hinden, R. and S. Deering, "IP Version 6 Addressing
      Architecture", RFC 2373, July 1998.
 [10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments",
      RFC 2375, July 1997.
 [11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
      July 1998.
 [12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
      2279, January 1998.
 [13] Kent, S. and R. Atkinson, "Security Architecture for the
      Internet Protocol", RFC 2401, November 1998.

Guttman Standards Track [Page 11] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

Author's Address

 Erik Guttman
 Sun Microsystems
 Eichhoelzelstr. 7
 74915 Waibstadt, Germany
 Phone:  +49 7263 911701
 EMail:  Erik.Guttman@germany.sun.com

Guttman Standards Track [Page 12] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001

Full Copyright Statement

 Copyright (C) The Internet Society (2001).  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 Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3111.txt · Last modified: 2001/05/22 16:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki