draft-ietf-svrloc-ipv6-00

8/2/2019 draft-ietf-svrloc-IPv6-00

1/15


2/15


3/15

Internet Engineering Task Force John Veizades INTERNET DRAFT @Home Network 11

July 1996 Erik Guttman Expires in six months Sun Microsystems

Service Location Modifications for IPv6 draft-ietf-svrloc-IPv6-00.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.

1.0 Protocol Changes

The following are changes required to have the Service Location

Veizades, Guttman [Page 1]


4/15


5/15


6/15

Internet Draft Service Location Modifications for IPv6 11 July 1996

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 yetbeen 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 must not propogate this Service Registration information

to User Agents that request it from other links. This means that Directory

Agents must inspect the URL registered by a Service Agent in a Service

Registration message and ascertain whether the address included is a

numerical IPv6 address which specifies a link local address. In this case, it

must be returned to User Agent Service Requests only if the User Agent is on

the same link as the link local address of the Service URL.

This constitutes an additional requirement for Directory Agents and modifies

the list given in [SLP], Section 22 (Implementation Requirements).



7/15


8/15


9/15


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 identifyend 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 eight

16-bit pieces of the address [AddrSpec].

The colons in the address must be escaped for the purposes of inclusion in

a URL [URL]. The IPv6 address represented in a URL will take the following

form:

Examples:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

becomes:

FEDC%3aBA98%3a7654%3a3210%3aFEDC%3aBA98%3a7654%3a3210

To add a port number (say 3431) to this address specification, a colon

followed by the port number value may be appended, as follows:

FEDC%3aBA98%3a7654%3a3210%3aFEDC%3aBA98%3a7654%3a3210:3431

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



10/15


11/15


12/15


definition will be submitted in a formal proposal in the near future. See

[DHCPv6 EXT].

6.0 Security Considerations

Security issues are not discussed in this document.

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



13/15


14/15


15/15


8. Author Information

John Veizades @Home Network 385 Ravendale Dr. Mountain View, CA 94043

Phone: +1 415 944 7332 Fax: +1 415 944 8500

Email: [email protected]

Erik Guttman Sun Microsystems 2550 Garcia Avenue, MS PAL01-550 Mountain View,

CA 94043-1100

Phone: +1 415 336 6697 Fax: +1 415 336 0673

Email: [email protected]

9.0 This document expires January 16, 1997.


draft-ietf-svrloc-ipv6-00

Documents