Subject: WG Last Call for "SLP modifications for IPv6"

From: Erik Guttman <[email-masked]>
Date: Mon, 9 Aug 1999 11:57:15 +0200 (MET DST)

This is a notice for WG last call for draft-ietf-svrloc-ipv6-06.txt.
This last call period will end on August 27.  At that time, if there
are no comments, this document will be submitted to the IESG for
advancement to a proposed standard.
 
This document went through WG and into IETF last call previously.
The IESG did not approve the portion of this document which specified
a numerical IPv6 address format for inclusion in SLP URLs.  A new
document has appeared <draft-ietf-ipngwg-url-literal-02.txt> which
specifies how these URLs are to be encoded.
 
A further change, which necessitates a WG last call once again, is a
request for clarification of the use of the 'range of multicast addresses'
defined for SLPv1 over IPv6.  This was not clearly specified in previous
drafts.
 
In SLPv1, global multicast addresses were used.  The 'range of multicast
addresses' to be used for service discover in SLPv1 was *never assigned*.
This was due to the fact that by the time the assignments were to be made
we understood that it was *not a good idea to assign global addresses to
a discovery protocol.*
 
Instead, we assigned a 'relative' address in the Administratively Scoped
Multicast Address range - please refer to RFC 2365 for details.   We made
only *one* assignment for SLPv2, since relative address assignments are
a precious resource.
 
This is not to say that using a separate address for DA discovery or using
the range of addresses hashed from the service type of a service request
are a bad idea.  In IPv6 we have enough addresses and multicast scopes were
added in advance, not as an afterthought.  For this reason, I have changed
the text of SLP modifications for IPv6 draft to make use of the multicast
address assignments already in place.  I include the changed section in
this message and encourage comments to the list.
 
The SLP modifications for IPv6 proposes no new mechanisms - it simply
defines RFC 2165 mechanisms be used for SLPv2 for multicast behavior.
This behavior is inappropriate over IPv4, but quite advantageous over
IPv6.

The changed sections of this document follow (though the entire document
was cleaned up with respect to the References section and a table of
contents was added).

---------------------------------------------------------------------------

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.