idnits 2.17.1 draft-ietf-svrloc-ipv6-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([IPsec], [ADM], [SLPv2], [SLP], [Veizades], [AD6], [MC6], [RFC2165]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '...l advertisements MUST NOT be used if t...' RFC 2119 keyword, line 88: '... A DA or SA MAY return URLs in SrvRp...' RFC 2119 keyword, line 91: '... multihomed. SLP DAs and SAs MUST NOT...' RFC 2119 keyword, line 102: '... IPv6, a router MUST be deployed on t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 45 has weird spacing: '...ing are chang...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Veizades' is mentioned on line 145, but not defined == Missing Reference: 'RFC2165' is mentioned on line 146, but not defined == Unused Reference: 'DHCP' is defined on line 166, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 169, but no explicit reference was found in the text == Unused Reference: 'SURL' is defined on line 200, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 204, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1541 (ref. 'DHCP') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1826 (ref. 'IPsec') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 2373 (ref. 'AD6') (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 2375 (ref. 'MC6') == Outdated reference: A later version (-15) exists of draft-ietf-svrloc-protocol-v2-10 == Outdated reference: A later version (-14) exists of draft-ietf-svrloc-service-scheme-12 ** Obsolete normative reference: RFC 2396 (ref. 'URL') (Obsoleted by RFC 3986) Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Erik Guttman 2 INTERNET DRAFT Sun Microsystems 3 26 October 1998 John Veizades 4 Expires in six months @Home Network 6 Service Location Protocol Modifications for IPv6 7 draft-ietf-svrloc-ipv6-05.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The Service Location Protocol provides a scalable framework for the 30 discovery and selection of network services. Using this protocol, 31 computers using IP based networks no longer need so much static 32 configuration of network services for network based applications. 33 This is especially important as computers become more portable, and 34 users less tolerant of or less able to fulfill the demands of network 35 administration. 37 The Service Location Protocol is well defined for use over IPv4 38 networks [SLP]: This document defines its use over IPv6 networks. 39 Since this protocol relies on UDP and TCP, the changes to support its 40 use over IPv6 are minor. This document equally applies to SLP, 41 version 2 [SLPv2]. 43 Protocol Changes 45 The following are changes required to have the Service Location 46 Protocol work over IPv6. These changes include: 48 - Eliminating support for broadcast SLP requests 50 - Restricted Propogation of Link Local Addresses 52 - Address Specification for IPv6 Addresses in URLs 54 - Different multicast addresses 56 Eliminating support for broadcast SLP requests 58 Service Location over IPv4 allows broadcasts to send Service Location 59 request messages. IPv6 makes use of link layer multicast in place of 60 broadcast. Broadcast only configuration for SLP is not supported 61 under IPv6. If a User Agent wishes to make a request to discover 62 Directory Agents or make a request of multiple Service Agents, the 63 User Agent must multicast the request to the appropriate multicast 64 address. 66 This change modifies the requirements described in Section 4.6 (Use 67 of TCP, UDP and Multicast in Service Location) and Section 22 68 (Implementation Requirements) of the Service Location Protocol [SLP]. 70 Restricted Propogation of Link Local Addresses 72 Link local advertisements MUST NOT be used if the SLP Agent has a 73 routable address. Service advertisements will include routable 74 addresses in this case. 76 Further, without routable addresses all User Agents (UAs), Service 77 Agents (SAs) and Directory Agents (DAs) transmit multicast SLP 78 messages with a TTL of 1: This includes SrvRqst, AttrRqst, 79 SrvTypeRqst and unsolicited DAAdvert messages. This request is 80 transmitted using a link local scope multicast address. 82 If the SA has no routable address it may send a Service Registration 83 to a DA using its Link Local address. This may occur in an 84 environment where there is no router available. This address must be 85 specified in the Service URL using an IPv6 address specification (see 86 below.) 88 A DA or SA MAY return URLs in SrvRply messages which contain link 89 local IPv6 addresses to UAs, but only with several restrictions. 91 First, the DA or SA must not be multihomed. SLP DAs and SAs MUST NOT 92 respond to SLP messages when they are multihomed and use link local 93 addresses. 95 Second, the DA or SA must not be configured with a routable address. 97 Last, the SA and DA must listen only for link local multicast 98 requests. (The DA will listen for multicast DA discovery requests, 99 the SA will listen for various multicast requests.) 101 If multihomed agents or routable addresses are desired for SLP with 102 IPv6, a router MUST be deployed on the network. 104 Address Specification for IPv6 Addresses in URLs 106 When ever possible the DNS name of the service should be used rather 107 than the above representation. 109 Service Location allows the use of the protocol without the benefit 110 of DNS. This is relevant when a group of systems is connected to 111 build a network without any previous configuration of servers to 112 support this network. When Service Location is used in this manner, 113 numerical addresses must be used to identify the location of 114 services. 116 A numerical IPv6 address used in a "service:" URL is specified as 118 ipv6-addr = v6num "-" 6( [v6num] "-") v6num ".ipv6" 119 ; Text represented IPv6 address syntax is as 120 ; specified in RFC 2373 [AD6], Section 2.2, 121 ; replacing ':' with '-'. 122 v6num = 1*4HEXDIGIT 124 Security Considerations 126 User Agents and Directory Agents may ignore all unauthenticated 127 Service Location messages when a valid IPSec association exists. 129 Service Agents and Directory Agents must be able to use the IP 130 Authentication and IP Encapsulating Security Payload in Service 131 Location messages whenever an appropriate IPSec Security Association 132 exists. [IPsec] 134 SLP allows digital signatures to be produced to allow the 135 verification of the contents of messages. There is nothing 136 in the Modifications for IPv6 document which weakens or 137 strengthens this technique. 139 Assigned numbers for IPv6 141 The assigned multicast addresses for SLP under IPv4 differ from 142 those in IPv6. These numbers are defined in [MC6]. Their values are: 144 FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades] 145 FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades] 146 FF05:0:0:0:0:0:1:1000 Service Location [RFC2165] 147 -FF05:0:0:0:0:0:1:13FF 149 The SLPv1 General Service Location Multicast address and the Directory 150 Agent Discovery Multicast address have been assigned for IPv6, see 151 [MC6]. For SLPv2, only the SVRLOC multicast is used (not the SVRLOC-DA 152 address. These addresses are define in [MC6].) 154 Note that for SLPv2, multicast TTL is not used to limit the 155 propogation of service location multicast requests. Instead, 156 Administratively Scoped multicast addresses [ADM] are used in 157 IPv4 and 'site-local scope' multicast [AD6] is used in IPv6. 159 Acknowledgments 161 Thanks to Dan Harrington, Jim Wood and Alain Durand for their thoughtful 162 reviews of previous drafts of this document. 164 References 166 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 167 October 1993 169 [DNS] Mockapetris, P. V. "Domain names - concepts and facilities", 170 RFC 1034. November 1987. 172 Mockapetris, P. V. "Domain names - implementation and 173 specification", RFC 1035. November 1987. 175 [IPsec] Atkinson, R. "IP Authentication Header", RFC 1826, 176 August 1995. 178 Atkinson, R. "IP Encapsulating Security Payload". RFC 1827, 179 August 1995. 181 Atkinson, R. "Security Architecture for the Internet 182 Protocol", RFC 1825, August 1995. 184 [AD6] Hinden, R., Deering, S., "IP Version 6 Addressing 185 Architecture", RFC 2373, July 1998. 187 [MC6] Hinden, R., Deering, S., "IPv6 Multicast Address Assignments", 188 RFC 2375, July 1997. 190 [ADM] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 191 July 1998. 193 [SLP] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 194 Location Protocol", RFC 2165, June 1997 196 [SLPv2] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service 197 Location Protocol, Version 2", 198 draft-ietf-svrloc-protocol-v2-10.txt, October 1998. 200 [SURL] Guttman, E., Perkins, C., Kempf, J., "Service Templates and 201 URLs", draft-ietf-svrloc-service-scheme-12.txt, October 1998, 202 A work in progress. 204 [URL] Berners-Lee, T., Fielding, R., and Masinter, L. "Uniform 205 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 206 1998. 208 Author Information 210 Erik Guttman 211 Sun Microsystems 212 Bahnstr. 2 213 74915 Waibstadt Germany 215 Phone: +49 7263 911701 217 Email: Erik.Guttman@eng.sun.com 219 John Veizades 220 @Home Network 221 385 Ravendale Dr. 222 Mountain View, CA 94043 224 Phone: +1 415 944 7332 225 Fax: +1 415 944 8500 227 Email: veizades@home.net