Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
4 February 1997 John Veizades
Expires in six months @Home Network
Service Location Modifications for IPv6
draft-ietf-svrloc-ipv6-01.txt
Status of this Memo
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.''
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 the Internet 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 or able to fulfill the demands of network
administration.
The Service Location Protocol is well defined for use over IPv4
networks [SLP]: 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.
Changes since draft-ietf-svrloc-IPv6-00.txt:
Stricter rules for advertising link local addresses using SLP.(3.0).
"Purely hex" string representation of numerical IPv6 addresses (4.0).
New text for the Security Considerations section. (6.0)
Addition of an Acknowlegments section. (7.0)
Guttman, Veizades [Page 1]
Internet Draft Service Location Modifications for IPv6 4 Feb 1997
1.0 Protocol Changes
The following are changes required to have the Service Location
Protocol work over IPv6. These changes include:
2.0 Eliminating support for broadcast SLP requests
3.0 Restricted Propogation of Link Local Addresses
4.0 Address Specification for IPv6 Addresses in URLs
5.0 Changes to DHCP options
2.0 Eliminating support for broadcast SLP requests
Service Location over IPv4 allows broadcasts to send Service Location
request messages. This is no longer supported. 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 4.6 (Use
of TCP, UDP and Multicast in Service Location) and Section 22
(Implementation Requirements) of the Service Location Protocol [SLP].
The General Service Location Multicast address and the Directory
Agent Discovery Multicast address have been assigned for IPv4, but
have not yet been assigned for IPv6. This will be done as soon as
possible.
3.0 Restricted Propogation of Link Local Addresses
A Service Agent may send a Service Registration to a Directory Agent
using its Link Local address. This may occur in an environment where
there is no DNS [DNS] or router available. If DNS is available, the
Service Agent SHOULD register a FQDN. If DNS is present, then, this
would not be an issue. If a router is available, the Service Agent
may register a routable address.
A Directory Agent MAY propogate this Service Registration
information to User Agents, but only with several restrictions.
The DA MUST to examine the source address of requests to determine
if a Service Request came to the DA from the same link as the link
local service advertisement. This is further complicated by the
possibility of a Directory Agent with multiple interfaces, on
different links.
Service Advertisements with link local addresses SHOULD only be
used when they are discovered in the following way: User Agents
issue a Service Request to the Service Location multicast address
Guttman, Veizades [Page 2]
Internet Draft Service Location Modifications for IPv6 4 Feb 1997
(or to a service specific multicast address) with a multicast
radius of 1. This will ensure that the Service Agents which reply
will be on the same link, as the request will not traverse any
routers.
This constitutes an additional requirement for Directory Agents and
modifies the list given in [SLP], Section 22 (Implementation
Requirements).
4.0 Address Specification for IPv6 Addresses in URLs
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,
addresses must be used to identify end systems. Systems must
explicitely provide their numerical addresses in this case.
The address specification for IPv6 replaces the address specification
description for the "dotted decimal IP address notation" in section
21.4 of the Service Location Protocol [SLP].
The form is a string representation of the hexadecimal values of the
address, 16 two digit hexidecimal numbers. [AddrSpec].
HEXDIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" /
"a" / "b" / "c" / "d" / "e" / "f"
HEXVAL = HEXDIGIT HEXDIGIT
IPV6-ADDR = 16HEXVAL
The port number value after the colon is expressed in decimal
notation, as defined in [URL].
When ever possible the DNS name of the service should be used rather
than the above representation.
5.0 Changes to DHCP Options
The DHCP options for use in Service Location have been submitted to
the IANA and DHCP working group of the IETF for standardization. One
of these option returns the IPv4 address of the Directory Agent for a
host to use. This option will have to be changed for IPv6 so that the
Directory Agent address will be 128 bits wide. This new option
Guttman, Veizades [Page 3]
Internet Draft Service Location Modifications for IPv6 4 Feb 1997
definition will be submitted in a formal proposal in the near future.
See [DHCPv6 EXT].
6.0 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. [IPsec]
In the absense of the IP security associations, the Service Location
Protocol may easily be abused to provide false advertisements or to
deregister valid advertisements. It is therefore highly recommended
that sites which deploy the Service Location Protocol also deploy the
necessary framework to support ip security.
7.0 Acknowledgments
Thanks to Dan Harrington for clarifying some points related to
advertising link local addresses. Harald Alvestrand's suggestion
to change the representation of the IPv6 addresses was also useful.
8.0 References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
October 1993
[SLP] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service
Location Protocol", Work in progress, June 1996
[DNS] Mockapetris, P. V. "Domain names - concepts and facilities",
RFC 1034. November 1987.
Mockapetris, P. V. "Domain names - implementation and
specification", RFC 1035. November 1987.
[URL] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resourc
Locators (URL)", RFC 1738, December 1994
[AddrSpec] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, January 1996
[DHCPV6-EXT] Perkins, C., "Extensions for DHCPv6", Work in progress,
June 1996.
Guttman, Veizades [Page 4]
Internet Draft Service Location Modifications for IPv6 4 Feb 1997
[IPsec] Atkinson, R. "IP Authentication Header", RFC 1826,
August 1995.
Atkinson, R. "IP Encapsulating Security Payload". RFC 1827,
August 1995.
Atkinson, R. "Security Architecture for the Internet
Protocol", RFC 1825, August 1995.
9.0 Author Information
Erik Guttman
Sun Microsystems
Gaisbergstr. 6
D-69115 Heidelberg Germany
Phone: +49 6221 601649
Fax: +49 6221 161019
Email: Erik.Guttman@eng.sun.com
John Veizades
@Home Network
385 Ravendale Dr.
Mountain View, CA 94043
Phone: +1 415 944 7332
Fax: +1 415 944 8500
Email: veizades@home.net
10.0 This document expires August 4, 1997.
Veizades, Guttman [Page 5]