home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-svrloc-ipv6-01.txt < prev    next >
Text File  |  1997-02-05  |  10KB  |  266 lines
  1.  
  2.  
  3. Internet Engineering Task Force                            Erik Guttman
  4. INTERNET DRAFT                                         Sun Microsystems
  5. 4 February 1997                                           John Veizades
  6. Expires in six months                                     @Home Network
  7.  
  8.                 Service Location Modifications for IPv6
  9.                      draft-ietf-svrloc-ipv6-01.txt
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.   This document is an Internet-Draft.  Internet-Drafts are working
  15.   documents of the Internet Engineering Task Force (IETF), its areas,
  16.   and its working groups.  Note that other groups may also distribute
  17.   working documents as Internet-Drafts.
  18.  
  19.   Internet-Drafts are draft documents valid for a maximum of six months
  20.   and may be updated, replaced, or obsoleted by other documents at any
  21.   time.  It is inappropriate to use Internet-Drafts as reference
  22.   material or to cite them other than as ``work in progress.''
  23.  
  24.   To learn the current status of any Internet-Draft, please check the
  25.   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  26.   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.   ftp.isi.edu (US West Coast).
  29.  
  30. Abstract
  31.  
  32.   The Service Location Protocol provides a scalable framework for the
  33.   discovery and selection of network services.  Using this protocol,
  34.   computers using the Internet no longer need so much static
  35.   configuration of network services for network based applications.
  36.   This is especially important as computers become more portable, and
  37.   users less tolerant or able to fulfill the demands of network
  38.   administration.
  39.  
  40.   The Service Location Protocol is well defined for use over IPv4
  41.   networks [SLP]:  This document defines its use over IPv6 networks.
  42.   Since this protocol relies on UDP and TCP, the changes to support its
  43.   use over IPv6 are minor.
  44.  
  45. Changes since draft-ietf-svrloc-IPv6-00.txt:
  46.  
  47.   Stricter rules for advertising link local addresses using SLP.(3.0).
  48.   "Purely hex" string representation of numerical IPv6 addresses (4.0).
  49.   New text for the Security Considerations section. (6.0)
  50.   Addition of an Acknowlegments section. (7.0)
  51.  
  52. Guttman, Veizades                                              [Page 1]
  53.  
  54. Internet Draft  Service Location Modifications for IPv6      4 Feb 1997
  55.  
  56. 1.0 Protocol Changes
  57.  
  58.   The following are  changes required to have the Service Location
  59.   Protocol work over IPv6.  These changes include:
  60.  
  61.       2.0 Eliminating support for broadcast SLP requests
  62.       3.0 Restricted Propogation of Link Local Addresses
  63.       4.0 Address Specification for IPv6 Addresses in URLs
  64.       5.0 Changes to DHCP options
  65.  
  66. 2.0 Eliminating support for broadcast SLP requests
  67.  
  68.   Service Location over IPv4 allows broadcasts to send Service Location
  69.   request messages.  This is no longer supported.  If a User Agent
  70.   wishes to make a request to discover Directory Agents or make a
  71.   request of multiple Service Agents, the User Agent must multicast the
  72.   request to the appropriate multicast address.
  73.  
  74.   This change modifies the requirements described in Section 4.6 (Use
  75.   of TCP, UDP and Multicast in Service Location) and Section 22
  76.   (Implementation Requirements) of the Service Location Protocol [SLP].
  77.  
  78.   The General Service Location Multicast address and the Directory
  79.   Agent Discovery Multicast address have been assigned for IPv4, but
  80.   have not yet been assigned for IPv6.  This will be done as soon as
  81.   possible.
  82.  
  83.  
  84. 3.0 Restricted Propogation of Link Local Addresses
  85.  
  86.   A Service Agent may send a Service Registration to a Directory Agent
  87.   using its Link Local address.  This may occur in an environment where
  88.   there is no DNS [DNS] or router available.  If DNS is available, the
  89.   Service Agent SHOULD register a FQDN.  If DNS is present, then, this
  90.   would not be an issue.  If a router is available, the Service Agent
  91.   may register a routable address.
  92.  
  93.   A Directory Agent MAY propogate this Service Registration
  94.   information to User Agents, but only with several restrictions.
  95.   The DA MUST to examine the source address of requests to determine
  96.   if a Service Request came to the DA from the same link as the link
  97.   local service advertisement.  This is further complicated by the
  98.   possibility of a Directory Agent with multiple interfaces, on
  99.   different links.
  100.  
  101.   Service Advertisements with link local addresses SHOULD only be
  102.   used when they are discovered in the following way:  User Agents
  103.   issue a Service Request to the Service Location multicast address
  104.  
  105. Guttman, Veizades                                              [Page 2]
  106.  
  107. Internet Draft  Service Location Modifications for IPv6      4 Feb 1997
  108.  
  109.   (or to a service specific multicast address) with a multicast
  110.   radius of 1.  This will ensure that the Service Agents which reply
  111.   will be on the same link, as the request will not traverse any
  112.   routers.
  113.  
  114.   This constitutes an additional requirement for Directory Agents and
  115.   modifies the list given in [SLP], Section 22 (Implementation
  116.   Requirements).
  117.  
  118. 4.0 Address Specification for IPv6 Addresses in URLs
  119.  
  120.   Service Location allows the use of the protocol without the benefit
  121.   of DNS.  This is relevant when a group of systems is connected to
  122.   build a network without any previous configuration of servers to
  123.   support this network.  When Service Location is used in this manner,
  124.   addresses must be used to identify end systems.  Systems must
  125.   explicitely provide their numerical addresses in this case.
  126.  
  127.   The address specification for IPv6 replaces the address specification
  128.   description for the "dotted decimal IP address notation" in section
  129.   21.4 of the Service Location Protocol [SLP].
  130.  
  131.   The form is a string representation of the hexadecimal values of the
  132.   address, 16 two digit hexidecimal numbers. [AddrSpec].
  133.  
  134.      HEXDIGIT  = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
  135.                  "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" /
  136.                  "a" / "b" / "c" / "d" / "e" / "f"
  137.  
  138.      HEXVAL    = HEXDIGIT HEXDIGIT
  139.  
  140.      IPV6-ADDR = 16HEXVAL
  141.  
  142.  
  143.   The port number value after the colon is expressed in decimal
  144.   notation, as defined in [URL].
  145.  
  146.   When ever possible the DNS name of the service should be used rather
  147.   than the above representation.
  148.  
  149.  
  150. 5.0 Changes to DHCP Options
  151.  
  152.   The DHCP options for use in Service Location have been submitted to
  153.   the IANA and DHCP working group of the IETF for standardization.  One
  154.   of these option returns the IPv4 address of the Directory Agent for a
  155.   host to use. This option will have to be changed for IPv6 so that the
  156.   Directory Agent address will be 128 bits wide.  This new option
  157.  
  158. Guttman, Veizades                                              [Page 3]
  159.  
  160. Internet Draft  Service Location Modifications for IPv6      4 Feb 1997
  161.  
  162.  
  163.   definition will be submitted in a formal proposal in the near future.
  164.   See [DHCPv6 EXT].
  165.  
  166. 6.0 Security Considerations
  167.  
  168.   User Agents and Directory Agents may ignore all unauthenticated
  169.   Service Location messages when a valid IPSec association exists.
  170.  
  171.   Service Agents and Directory Agents must be able to use the IP
  172.   Authentication and IP Encapsulating Security Payload in Service
  173.   Location messages whenever an appropriate IPSec Security Association
  174.   exists. [IPsec]
  175.  
  176.   In the absense of the IP security associations, the Service Location
  177.   Protocol may easily be abused to provide false advertisements or to
  178.   deregister valid advertisements.  It is therefore highly recommended
  179.   that sites which deploy the Service Location Protocol also deploy the
  180.   necessary framework to support ip security.
  181.  
  182. 7.0 Acknowledgments
  183.  
  184.   Thanks to Dan Harrington for clarifying some points related to
  185.   advertising link local addresses.  Harald Alvestrand's suggestion
  186.   to change the representation of the IPv6 addresses was also useful.
  187.  
  188. 8.0 References
  189.  
  190.   [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
  191.   October 1993
  192.  
  193.   [SLP] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service
  194.   Location Protocol", Work in progress, June 1996
  195.  
  196.   [DNS] Mockapetris, P. V. "Domain names - concepts and facilities",
  197.   RFC 1034.  November 1987.
  198.  
  199.         Mockapetris, P. V. "Domain names - implementation and
  200.   specification", RFC 1035.  November 1987.
  201.  
  202.   [URL] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resourc
  203.   Locators (URL)", RFC 1738, December 1994
  204.  
  205.   [AddrSpec] Hinden, R., Deering, S., "IP Version 6 Addressing
  206.   Architecture", RFC 1884, January 1996
  207.  
  208.   [DHCPV6-EXT] Perkins, C., "Extensions for DHCPv6", Work in progress,
  209.   June 1996.
  210.  
  211. Guttman, Veizades                                              [Page 4]
  212.  
  213. Internet Draft  Service Location Modifications for IPv6      4 Feb 1997
  214.  
  215.   [IPsec] Atkinson, R. "IP Authentication Header",  RFC 1826,
  216.   August 1995.
  217.  
  218.           Atkinson, R. "IP Encapsulating Security Payload".  RFC 1827,
  219.   August 1995.
  220.  
  221.           Atkinson, R. "Security Architecture for the Internet
  222.   Protocol", RFC 1825, August 1995.
  223.  
  224. 9.0 Author Information
  225.  
  226.       Erik Guttman
  227.       Sun Microsystems
  228.       Gaisbergstr. 6
  229.       D-69115 Heidelberg Germany
  230.  
  231.       Phone:  +49 6221 601649
  232.       Fax:    +49 6221 161019
  233.  
  234.       Email:  Erik.Guttman@eng.sun.com
  235.  
  236.  
  237.       John Veizades
  238.       @Home Network
  239.       385 Ravendale Dr.
  240.       Mountain View, CA 94043
  241.  
  242.       Phone:  +1 415 944 7332
  243.       Fax:    +1 415 944 8500
  244.  
  245.       Email:  veizades@home.net
  246.  
  247.  
  248.  
  249. 10.0 This document expires August 4, 1997.
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264. Veizades, Guttman                                               [Page 5]
  265.  
  266.