idnits 2.17.1 draft-ietf-wrec-wpad-01.txt: -(244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(301): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(704): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(943): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == There are 13 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 915 has weird spacing: '...ocation of ...' -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '13' is mentioned on line 409, but not defined == Missing Reference: 'RFC2608' is mentioned on line 536, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2052 (ref. '2') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul Gauthier 2 Expires: December 1999 Inktomi Corporation 3 Category: Standards Track Josh Cohen 4 draft-ietf-wrec-wpad-01.txt Microsoft Corporation 5 Martin Dunsmuir 6 RealNetworks, Inc. 7 Charles Perkins 8 Sun Microsystems, Inc. 10 Web Proxy Auto-Discovery Protocol 12 Status of This Memo 14 This document is a submission by the WREC Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be 16 submitted to the wrec@cs.utk.edu mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 A mechanism is needed to permit web clients to locate nearby web 39 proxy caches. Current best practice is for end users to hand 40 configure their web client (i.e., browser) with the URL of an "auto 41 configuration file". In large environments this presents a 42 formidable support problem. It would be much more manageable for 43 the web client software to automatically learn the configuration 44 information for its web proxy settings. This is typically referred 45 to as a resource discovery problem. 47 Web client implementers are faced with a dizzying array of resource 48 discovery protocols at varying levels of implementation and 49 deployment. This complexity is hampering deployment of a "web proxy 50 auto-discovery "facility. This document proposes a pragmatic 51 approach to web proxy auto-discovery. It draws on a number of 52 proposed standards in the light of practical deployment concerns. It 53 proposes an escalating strategy of resource discovery attempts in 54 order to find a nearby web proxy server. It attempts to provide rich 56 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 58 mechanisms for supporting a complex environment, which may contain 59 multiple web proxy servers. 61 Table of Contents 63 Status of This Memo...................................................1 64 Abstract..............................................................1 65 Table of Contents.....................................................2 66 1. Conventions used in this document................................2 67 2. Introduction.....................................................2 68 3. Defining Web Proxy Auto-Discovery................................3 69 4. The Discovery Process............................................4 70 4.1. WPAD Overview................................................4 71 4.2. When to Execute WPAD.........................................6 72 4.2.1. Upon Startup of the Web Client............................7 73 4.2.2. Network Stack Events......................................7 74 4.2.3. Expiration of the CFILE...................................7 75 4.3. WPAD Protocol Specification..................................7 76 4.4. Discovery Mechanisms.........................................9 77 4.4.1. DHCP......................................................9 78 4.4.2. SVRLOC/SLP...............................................10 79 4.4.3. DNS A/CNAME "Well Known Aliases�........................10 80 4.4.4. DNS SRV Records..........................................10 81 4.4.5. DNS TXT service: Entries.................................11 82 4.4.6. Fallback.................................................11 83 4.4.7. Timeouts.................................................11 84 4.5. Composing a Candidate CURL..................................12 85 4.6. Retrieving the CFILE at the CURL............................12 86 4.7. Resuming Discovery..........................................12 87 5. Client Implementation Considerations............................12 88 6. Proxy Server Considerations.....................................13 89 7. Administrator Considerations....................................13 90 8. Conditional Compliance..........................................14 91 8.1. Class 0 - Minimally compliant...............................15 92 8.2. Class 1 - Compliant.........................................15 93 8.3. Class 2 - Maximally compliant...............................15 94 9. Security Considerations.........................................15 95 10. Acknowledgements................................................16 96 11. Copyright.......................................................16 97 12. References......................................................16 98 13. Author Information..............................................17 100 1. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in "Key words for use in 105 RFCs to Indicate Requirement Levels" [KEYWORDS]. 107 2. Introduction 109 The problem of locating nearby web proxy cache servers can not wait 110 for the implementation and large scale deployment of various 112 Category: Standards Track Expires: December 1999 114 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 116 upcoming resource discovery protocols. The widespread success of the 117 HTTP protocol and the recent popularity of streaming media has 118 placed unanticipated strains on the networks of corporations, ISPs 119 and backbone providers. There currently is no effective method for 120 these organizations to realize the obvious benefits of web caching 121 without tedious and error prone configuration by each and every end 122 user. 124 The de-facto mechanism for specifying a web proxy server 125 configuration in web clients is the download of a script or 126 configuration file named by a URL. Users are currently expected to 127 hand configure this URL into their Browser or other web client. 128 This mechanism suffers from a number of drawbacks: 130 - Difficulty in supporting a large body of end-users. Many users 131 misconfigure their proxy settings and are unable to diagnose the 132 cause of their problems. 134 - Lack of support for mobile clients who require a different proxy 135 as their point of access changes. 137 - Lack of support for complex proxy environments where there may 138 exist a number of proxy servers with different affinities for 139 different clients (based on network proximity, for example). 140 Currently, clients would have to "know" which proxy server was 141 optimal for their use. 143 Currently available methods for resource discovery need to be 144 exploited in the context of a well defined framework. Simple, 145 functional and efficient mechanisms stand a good chance of solving 146 this pressing and basic need. As new resource discovery mechanisms 147 mature they can be folded into this framework with little 148 difficulty. 150 This document is a specification for implementers of web client 151 software. It defines a protocol for automatically configuring those 152 clients to use a local proxy. It also defines how an administrator 153 should configure various resource discovery services in their 154 network to support WPAD compatible web clients. 156 While it does contain suggestions for web proxy server implementers, 157 it does not make any specific demands of those parties. 159 3. Defining Web Proxy Auto-Discovery 161 As mentioned above, currently web client software needs to be 162 configured with the URL of a proxy auto-configuration file or 163 script. The contents of this script are vendor specific and not 164 currently standardized. This document does not attempt to discuss 165 the contents of these files (see[8] for an example file format). 167 Thus, the Web Proxy Auto-Discovery (WPAD) problem reduces to 168 providing the web client a mechanism for discovering the URL of the 170 Category: Standards Track Expires: December 1999 172 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 174 Configuration File. Once this Configuration URL (CURL) is known, the 175 client software already contains mechanisms for retrieving and 176 interpreting the Configuration File (CFILE) to enable access to the 177 specified proxy cache servers. 179 It is worth carefully noting that the goal of the WPAD process is to 180 discover the correct CURL at which to retrieve the CFILE. The client 181 is *not* trying to directly discover the name of the proxy server. 182 That would circumvent the additional capabilities provided by proxy 183 Configuration Files (such as load balancing, request routing to an 184 array of servers, automated fail-over to backup proxy server [6,8]). 186 It is worth noting that different clients requesting the CURL may 187 receive completely different CFILEs in response. The web server may 188 send back different CFILES based on a number of criteria such as the 189 "User-Agent" header, "Accept" headers, client IP address/subnet, 190 etc. The same client could conceivably receive a different CFILE on 191 successive retrievals (as a method of round-robin load balancing, 192 for example). 194 This document will discuss a range of mechanisms for discovering the 195 Configuration URL. The client will attempt them in a predefined 196 order, until one succeeds. Existing widely deployed facilities may 197 not provide enough expressiveness to specify a complete URL. As 198 such, we will define default values for portions of the CURL which 199 may not be expressible by some discovery mechanisms: 201 http://: 203 - There is no default for this potion. Any succeeding 204 discovery mechanism will provide a value for the portion 205 of the CURL. The client MUST NOT provide a default. 207 - The client MUST assume port 80 if the successful discovery 208 mechanism does not provide a port component. 210 - The client MUST assume a path of "/wpad.dat" if the 211 successful discovery mechanism does not provide a path 212 component. 214 4. The Discovery Process 216 4.1. WPAD Overview 218 This sub-section will present a descriptive overview of the WPAD 219 protocol. It is intended to introduce the concepts and flow of the 220 protocol. The remaining sub-sections (3.2-3.7) will provide the 221 rigorous specification of the protocol details. WPAD uses a 222 collection of pre-existing Internet resource discovery mechanisms to 223 perform web proxy auto-discovery. Readers may wish to refer to [1] 224 for a similar approach to resource discovery, since it was a basis 225 for this strategy. The WPAD protocol specifies the following: 227 Category: Standards Track Expires: December 1999 229 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 231 - how to use each mechanism for the specific purpose of web proxy 232 auto-discovery 233 - the order in which the mechanisms should be performed 234 - the minimal set of mechanisms which must be attempted by a WPAD 235 compliant web client 237 The resource discovery mechanisms utilized by WPAD are as follows. 238 - Dynamic Host Configuration Protocol (DHCP, [3,7]). 239 - Service Location Protocol (SLP, [4]). 240 - "Well Known Aliases� using DNS A records [5,9]. 241 - DNS SRV records [2,9]. 242 - "service: URLs" in DNS TXT records [10]. 244 Of all these mechanisms only the DHCP and �Well Known Aliases� are 245 required in WPAD clients. This decision is based on three reasons: 246 these facilities are currently widely deployed in existing vendor 247 hardware and software; they represent functionality that should 248 cover most real world environments; they are relatively simple to 249 implement. 251 DNS servers supporting A records are clearly the most widely 252 deployed of the services outlined above. It is reasonable to expect 253 API support inside most web client development environments (POSIX 254 C, Java, etc). The hierarchical nature of DNS makes it possible to 255 support hierarchies of proxy servers. 257 DNS is not suitable in every environment, unfortunately. 258 Administrators often choose a DNS domain name hierarchy that does 259 not correlate to network topologies, but rather with some 260 organizational model (for example, foo.development.bar.com and 261 foo.marketing.bar.com). DHCP servers, on the other hand, are 262 frequently deployed with concern for network topologies. DHCP 263 servers provide support for making configuration decisions based on 264 subnets, which are directly related to network topology. 266 Full client support for DHCP is not as ubiquitous as for DNS. That 267 is, not all clients are equipped to take advantage of DHCP for their 268 essential network configuration (assignment of IP address, network 269 mask, etc). APIs for DHCP are not as widely available. Luckily, 270 using DHCP for WPAD does not require either of these facilities. It 271 is relatively easy for web client developers to speak just the 272 minimal DHCP protocol to perform resource discovery. It entails 273 building a simple UDP packet, sending it to the subnet broadcast 274 address, and parsing the reply UDP packet(s) which are received to 275 extract the WPAD option field. A reference implementation of this 276 code in C is available [11]. 278 The WPAD client attempts a series of resource discovery requests, 279 using the discovery mechanisms mentioned above, in a specific order. 280 Clients only attempt mechanisms that they support (obviously). Each 281 time the discovery attempt succeeds; the client uses the information 282 obtained to construct a CURL. If a CFILE is successfully retrieved 284 Category: Standards Track Expires: December 1999 286 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 288 at that CURL, the process completes. If not, the client resumes 289 where it left of in the predefined series of resource discovery 290 requests. If no untried mechanisms remain and a CFILE has not been 291 successfully retrieved, the WPAD protocol fails and the client is 292 configured to use no proxy server. 294 First the client tries DHCP, followed by SLP. If no CFILE has been 295 retrieved the client moves on to the DNS based mechanisms. The 296 client will cycle through the DNS SRV, �Well Known Aliases� and DNS 297 TXT record methods multiple times. Each time through the QNAME being 298 used in the DNS query is made less and less specific. In this manner 299 the client can locate the most specific configuration information 300 possible, but can fall back on less specific information. Every DNS 301 lookup has the QNAME prefixed with �wpad� to indicate the resource 302 type being requested. 304 As an example, consider a client with hostname johns- 305 desktop.development.foo.com. Assume the web client software supports 306 all of the mechanisms listed above. This is the sequence of 307 discovery attempts the client would perform until one succeeded in 308 locating a valid CFILE: 310 - DHCP 311 - SLP 312 - DNS A lookup on QNAME=wpad.development.foo.com. 313 - DNS SRV lookup on QNAME=wpad.development.foo.com. 314 - DNS TXT lookup on QNAME=wpad.development.foo.com. 315 - DBS A lookup on QNAME=wpad.foo.com. 316 - DNS SRV lookup on QNAME=wpad.foo.com. 317 - DNS TXT lookup on QNAME=wpad.foo.com. 319 4.2. When to Execute WPAD 321 Web clients need to perform the WPAD protocol periodically to 322 maintain correct proxy settings. This should occur on a regular 323 basis corresponding to initialization of the client software or the 324 networking stack below the client. As well, WPAD will need to occur 325 in response to expiration of existing configuration data. The 326 following sections describe the details of these scenarios. 3.2.1. 327 Periodic Discovery 329 The web proxy auto-discovery process MUST occur at least as 330 frequently as one of the following two options. A web client can use 331 either option depending on which makes sense in their environment. 332 Clients MUST use at least one of the following options. They MAY 333 also choose to implement both options. 334 - Upon startup of the web client. 335 - Whenever there indication from the networking stack that the IP 336 address of the client host either has, or could have, changed. 338 In addition, the client MUST attempt a discovery cycle upon 339 expiration of a previously downloaded CFILE in accordance with 340 HTTP/1.1. 342 Category: Standards Track Expires: December 1999 344 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 346 4.2.1. Upon Startup of the Web Client 348 For many types of web client (like web browsers) there can be many 349 instances of the client operating for a given user at one time. This 350 is often to allow display of multiple web pages in different 351 windows, for example. There is no need to re-perform WPAD every time 352 a new instance of the web client is opened. WPAD MUST be performed 353 when the number of web client instances transitions from 0 to 1. It 354 SHOULD NOT be performed as additional instances are created. 356 4.2.2. Network Stack Events 358 Another option for clients is to tie the execution of WPAD to 359 changes in the networking environment. If the client can learn about 360 the change of the local host�s IP address, or the possible change of 361 the IP address, it MUST re-perform the WPAD protocol. Many 362 operating systems provide indications of �network up� events, for 363 example. Those types of events and system-boot events might be the 364 triggers for WPAD in many environments. 366 4.2.3. Expiration of the CFILE 368 The HTTP retrieval of the CURL may return HTTP headers specifying a 369 valid lifetime for the CFILE returned. The client MUST obey these 370 timeouts and rerun the PAD process when it expires. A client MAY 371 rerun the WPAD process if it detects a failure of the currently 372 configured proxy (which is not otherwise recoverable via the 373 inherent mechanisms provided by the currently active Configuration 374 File). 376 Whenever the client decides to invalidate the current CURL or CFILE, 377 it MUST rerun the entire WPAD protocol to ensure it discovers the 378 currently correct CURL. Specifically, if the valid lifetime of the 379 CFILE ends(as specified by the HTTP headers provided when it was 380 retrieved),the complete WPAD protocol MUST be rerun. The client MUST 381 NOT simply re-use the existing CURL to obtain a fresh copy of the 382 CFILE. 384 A number of network round trips, broadcast and/or multicast 385 communications may be required during the WPAD protocol. The WPAD 386 protocol SHOULD NOT be invoked at a more frequent rate than 387 specified above (such as per-URL retrieval). 389 4.3. WPAD Protocol Specification 391 The following pseudo-code defines the WPAD protocol. If a 392 particular discovery mechanism is not supported, treat it as a 393 failed discovery attempt in the pseudo-code. 395 In addition, this logic is expressed below in pseudo-code. 396 The following pseudo-code fragment defines WPAD. Unsupported 397 discovery mechanisms are treated as failure in the pseudo-code. 399 Category: Standards Track Expires: December 1999 401 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 403 Two subroutines need explanation. The subroutine 404 strip_leading_component(dns_string) strips off the leading 405 characters, up to and including the first dot (`.') in the string 406 which is passed as a parameter, and is expected to contain DNS name. 407 The Boolean subroutine is_not_canonical(dns_string) returns FALSE if 408 dns_string is one of the canonical domain suffixes defined in RFC 409 1591 [13] (for example, "com"). 411 The slp_list and dns_list elements below are assumed to be linked 412 lists containing a data field and a pointer to the next element. 413 The data field contains the elements used to override the default 414 values in creating a CURL, as detailed in section 3.5. 416 load_CFILE() { 417 /* MUST use DHCP */ 418 curl = dhcp_query(/*WPAD option (section 4.4.1) */); 419 if (curl != null) { /* DHCP succeeded */ 420 if isvalid (read_CFILE(curl)) 421 return SUCCESS; /* valid CFILE */ 422 } 424 /* Should use SLP */ 425 slp_list = slp_query(/*(WPAD attributes (Section 4.4.2)*/); 426 while (slp_list != null) { /* test each curl */ 427 if isvalid(read_CFILE(slp_list.curl_data)) 428 return SUCCESS; /* valid CFILE */ 429 else 430 slp_list = slp_list.next; 431 } 433 /* all the DNS mechanisms */ 434 TGTDOM = gethostbyname(me); 435 TGTDOM = strip_leading_component(TGTDOM); 437 while (is_not_canonical(TGTDOM)) { 439 /* SHOULD try DNS SRV records */ 440 dns_list = dns_query(/*QNAME=wpad.TGTDOM., 441 QTYPE=SRV (section 4.4.4)*/); 442 while (dns_list != null) { /* each TXT record */ 443 if isvalid(read_CFILE(dns_list, curl_data)) 444 return SUCCESS; /* valid CFILE */ 445 else 446 dns_list = dns_list.next; 447 } 449 /* SHOULD try DNS TXT records */ 450 dns_list = dns_query(/*QNAME=wpad.TGTDOM., 451 QTYPE=TXT (section 4.4.5)*/); 452 while (dns_list != null) { /* each TXT record */ 453 if isvalid(read_CFILE(dns_list, curl_data)) 454 return SUCCESS; /* valid CFILE */ 456 Category: Standards Track Expires: December 1999 458 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 460 else 461 dns_list = dns_list.next; 462 } 464 /* MUST try DNS A records */ 465 dns_list = dns_query(/*QNAME=wpad.TGTDOM., 466 QTYPE=A (Section 4.4.3)*/); 468 while (dns_list != null) { /* check each A record */ 469 if isvalid(read_CFILE(dns_list, curl_data)) 470 return SUCCESS; /* valid CFILE */ 471 else 472 dns_list = dns_list.next; 473 } 475 /* Still no match, remove leading component and iterate */ 476 TGTDOM = strip_leading_component(TGTDOM); 478 } /* no A, TXT or SRV records for wpad.* */ 480 return FAILED; /* could not locate valid CFILE */ 481 } 483 4.4. Discovery Mechanisms 485 Each of the resource discovery methods will be marked as to whether 486 the client MUST, SHOULD, MAY, or MUST NOT implement them to be 487 compliant. Client implementers are encouraged to implement as many 488 mechanisms as possible, to promote maximum interoperability. 490 +-------------------------+--------+----------+ 491 | Discovery | | Document | 492 | Mechanism | Status | Section | 493 +-------------------------+--------+----------+ 494 | DHCP | MUST | 4.4.1 | 495 | SLP | SHOULD | 4.4.2 | 496 | "Well Known Alias" | MUST | 4.4.3 | 497 | DNS SRV Records | SHOULD | 4.4.4 | 498 | DNS TXT "service: URLs" | SHOULD | 4.4.5 | 499 +-------------------------+--------+----------+ 501 SUMMARY OF DISCOVERY MECHANISMS 503 4.4.1. DHCP 505 Client implementations MUST support DHCP. DHCP has widespread 506 support innumerous vendor hardware and software implementations, and 507 is widely deployed. It is also perfectly suited to this task, and is 508 used to discover other network resources (such a time servers, 509 printers, etc). The DHCP protocol is detailed in RFC 2131 [3]. 510 We propose a new DHCP option with code 252 for use in web proxy 511 auto-discovery. See RFC 2132 [7] for a list of existing DHCP 513 Category: Standards Track Expires: December 1999 515 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 517 options. See "Conditional Compliance" for more information on DHCP 518 requirements. 520 The client should obtain the value of the DHCP option code 252 as 521 returned by the DHCP server. If the client has already conducted 522 DHCP protocol during its initialization, the DHCP server may already 523 have supplied that value. If the value is not available through a 524 client OS API, the client SHOULD use a DHCPINFORM message to query 525 the DHCP server to obtain the value. 527 The DHCP option code for WPAD is 252 by agreement of the DHC working 528 group chair. This option is of type STRING. This string contains a 529 URL which points to an appropriate config file. The STRING is of 530 arbitrary size. 531 An example STRING value would be: 532 "http://server.domain/proxyconfig.pac" 534 4.4.2. Service Location Protocol /SLP 536 The Service Location Protocol [RFC2608] is a Proposed Standard for 537 discovering services in the Internet. SLP has several reference 538 implementations available; for details, check the following web 539 page: 541 http://www.svrloc.org/ 543 A service type for use with WPAD has been defined and is available 544 as an Internet Draft. 546 Client implementations SHOULD implement SLP. SLP Service Replies 547 will provide one or more complete CURLs. Each candidate CURL so 548 created should be pursued as specified in section 4.5 and beyond. 550 4.4.3. DNS A/CNAME "Well Known Aliases� 552 Client implementations MUST support this mechanism. This should be 553 straightforward since only basic DNS lookup of A records is 554 required. See RFC 2219 [5] for a description of using "well known" 555 DNS aliases for resource discovery. We propose the "well known 556 alias� of "wpad" for web proxy auto-discovery. 558 The client performs the following DNS lookup: 559 QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=A 561 Each A RR, which is returned, contains an IP address which is used 562 to replace the default in the CURL. 564 Each candidate CURL so created should be pursued as specified in 565 section 4.5 and beyond. 567 4.4.4. DNS SRV Records 569 Category: Standards Track Expires: December 1999 571 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 573 Client implementations SHOULD support the DNS SRV mechanism. Details 574 of the protocol can be found in RFC 2052 [2]. If the implementation 575 language/environment provides the ability to perform DNS lookups on 576 QTYPEs other than A, client implementers are strongly encouraged to 577 provide this support. It is acknowledged that not all resolver APIs 578 provide this functionality. 580 The client issues the following DNS lookup: 581 QNAME=wpad.tcp.TGTDOM., QCLASS=IN, QTYPE=SRV 583 If it receives SRV RRs in response, the client should use each valid 584 RR in the order specified in RFC 2052 [2]. Each valid record will 585 specify both a and a to override the CURL defaults. 587 Each candidate CURL so created should be pursued as specified in 588 section 4.5 and beyond. 590 4.4.5. DNS TXT service: Entries 592 Client implementation SHOULD support this mechanism. If the 593 implementation language/environment provides the ability to perform 594 DNS lookups on QTYPEs other than A, the vendor is strongly 595 encouraged to provide this support. It is acknowledged that not all 596 resolver APIs provide this functionality. 597 The client should attempt to retrieve TXT RRs from the DNS to obtain 598 �service: URLs� contained therein. The �service: URL� will be of the 599 following format, specifying a complete candidate CURL for each 600 record located: 602 service: wpad:http://: 604 The client should first issue the following DNS query: 605 QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=TXT 607 It should process each TXT RR it receives (if any) using each 608 service:URL found (if any) to generate a candidate CURL. These CURLs 609 should be pursued as described in section 3.5 and beyond. 610 Readers familiar with [1] should note that WPAD clients MUST NOT 611 perform the QNAME=TGTDOM., QCLASS=IN, QTYPE=TXT lookup which would 612 be suggested by that document. 614 4.4.6. Fallback 616 Clients MUST NOT implement the "Fallback" mechanism described in 617 [1]. It is unlikely that a client will find a web server prepared to 618 handle the CURL request at a random suffix of its FQDN. This will 619 only increase the number of DNS probes and introduce an excess of 620 spurious "GET" requests on those hapless web servers. 622 Instead, the "Well Known Aliases� method of section 3.4.4 provides 623 equivalent functionality. 625 4.4.7. Timeouts 627 Category: Standards Track Expires: December 1999 629 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 631 Implementers are encouraged to limit the time elapsed in each 632 discovery phase. When possible, limiting each phase to 10 seconds 633 is considered reasonable. Implementers may choose a different value 634 which is more appropriate to their network properties. For example, 635 a device implementation, which operated over a wireless network, may 636 use a much larger timeout to account for low bandwidth or high 637 latency. 639 4.5. Composing a Candidate CURL 641 Any successful discovery mechanism response will provide a 642 (perhaps in the form of an IP address). Some mechanisms will 643 also provide a and/or a . The client should override 644 the default CURL fields with all of those supplied by the discovery 645 mechanism. 647 4.6. Retrieving the CFILE at the CURL 649 The client then requests the CURL via HTTP. 650 When making the request it MUST transmit HTTP "Accept" headers 651 indicating what CFILE formats it is capable of accepting. For 652 example, Netscape Navigator browsers with versions 2.0 and beyond 653 might include the following line in the HTTP Request: 655 Accept: application/x-ns-proxy-autoconfig 657 The client MUST follow HTTP redirect directives (response codes 3xx) 658 returned by the server. The client SHOULD send a valid "User-Agent" 659 header. 661 4.7. Resuming Discovery 663 If the HTTP request fails for any reason (fails to connect, server 664 error response, etc) the client MUST resume the search for a 665 successful CURL where it left off. It should continue attempting 666 other sub-steps in a specific discovery mechanism, and then move on 667 to the next mechanism or TGTDOM iteration, etc. 669 5. Client Implementation Considerations 671 The large number of discovery mechanisms specified in this document 672 may raise concerns about network traffic and performance. The DHCP 673 portion of the process will result in a single broadcast by the 674 client, and perhaps a few replies by listening DHCP servers. 676 The remaining mechanisms are all DNS based. All DNS queries should 677 have the QNAME terminated with a trailing '.' to indicate a FQDN and 678 expedite the lookup. As such each TGTDOM iteration will cause 3 DNS 679 lookups, each a unicast UDP packet and a reply. Most clients will 680 have fewer than 2TGTDOM iterations, limiting the total number of DNS 681 request/replies to6. 683 Category: Standards Track Expires: December 1999 685 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 687 All total, 7 UDP request/reply packets on client startup is quite a 688 low overhead. The first web page downloaded by the client will 689 likely dwarf that packet count. Each of the DNS lookups should stand 690 a high chance of hitting the cache in the client's DNS server, since 691 other clients will have likely looked them up recently, providing a 692 low total elapsed time. 694 This is of course the worst case, where no CURLS are obtained, and 695 assuming a long client FQDN. Often, a successful CURL will be found 696 early in the protocol, reducing the total packet count. 697 Client implementations are encouraged to overlap this protocol work 698 with other startup activities. Also, client implementers with 699 concerns about performance can choose to implement only the 700 discovery mechanisms listed as MUST in section 3.4. 702 A longer delay could occur if a CURL is obtained, but the hosting 703 web server is down. The client could spend considerable time waiting 704 for the TCP �connect ()� call to fail. Luckily this is an extremely 705 rare case where the web server hosting the CFILE has failed. See 706 section 5, where proxy server implementers are encouraged to provide 707 support for hosting CURLs on the proxy itself (acting as web 708 server). Since proxy servers are often deployed with considerable 709 attention to fault tolerance, this corner case can be further 710 minimized. 712 6. Proxy Server Considerations 714 As mentioned in the previous section, it is suggested that proxy 715 servers be capable of acting as a web server, so that they can host 716 the CURL directly. 718 The implementers of proxy servers are most likely to understand the 719 deployment situations of proxy caches, the formats of proxy 720 configuration files, etc. They can also build in the ability select 721 a CFILE based on all the various inputs at the time of the CURL 722 request("User-Agent", "Accept", client IP address/subnet/hostname, 723 topological distribution of nearby proxy servers, etc). 725 7. Administrator Considerations 727 Administrators should configure at least one of the DHCP or DNS A RR 728 methods in their environment (since those are the only two all 729 compatible clients MUST implement). Beyond that, configuring to 730 support mechanisms earlier in the search order will improve client 731 startup time. 733 One of the major motivations for this protocol structure was to 734 support client location of "nearby" proxy servers. In many 735 environments there may be a number of proxy servers (workgroup, 736 corporate gateway, ISP, backbone). There are a number of possible 737 points at which "nearness" decisions can be made in this framework: 739 Category: Standards Track Expires: December 1999 741 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 743 - DHCP servers for different subnets can return different answers. 744 They can also base decisions on the client cipaddr field or the 745 client identifier option. 747 - DNS servers can be configured to return different SRV/A/TXT RRs 748 for Different domain suffixes (for example, QNAMEs 749 wpad.marketing.bigcorp.com and wpad.development.bigcorp.com). 751 - The web server handling the CURL request can make decisions based 752 on the "User-Agent", "Accept", client IP 753 address/subnet/hostname, and the topological distribution of 754 nearby proxy servers, etc. This can occur inside a CGI 755 executable created to handle the CURL. As mentioned above it 756 could be a proxy server itself handing the CURL request and 757 making those decisions. 759 - The CFILE may be expressive enough to select from a set of 760 alternatives at "runtime" on the client. CARP [6] is based on 761 this premise for an array of caches. It is not inconceivable 762 that the CFILE could compute some network distance or fitness 763 metrics to a set of candidate proxy servers and then select the 764 "closest" or "most responsive" server. 766 Note that it is valid to configure a DHCP daemon to respond only to 767 INFORM option queries in static IP environments 769 Not all of the above mechanisms can be supported in all currently 770 deployed vendor hardware and software. The hope is that enough 771 flexibility is provided in this framework that administrators can 772 select which mechanisms will work in their environments. 774 8. Conditional Compliance 776 In light of the fact that many of the discovery technologies 777 described in this document are not well deployed or not available on 778 all platforms, this specification permits conditional compliance. 779 Conditional compliance is designated by three class identifications. 781 Additionally, due to the possible security implications of a DHCP 782 broadcast request, it is onerous to REQUIRE an implementer to put 783 himself or his implementation at undue risk. It is quite common to 784 have rogue DHCP servers on a network which may fool a DHCP broadcast 785 implementation into using a malicious configuration file. On 786 platforms which do not support DHCP natively and cannot get the WPAD 787 option along with its IP address, and which cannot support the DHCP 788 INFORM unicast request, presumably to a known and trusted DHCP 789 server, the likelihood of an undetected spoofing attack is 790 increased. Having an individual program, such as a browser, trying 791 to detect a DHCP server on a network is unreasonable, in the 792 authors' opinion. On platforms which use DHCP for their system IP 793 address and have previously trusted a DHCP server, a unicast DHCP 794 INFORM to that same trusted server does not introduce any additional 795 trust to that server. 797 Category: Standards Track Expires: December 1999 799 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 801 8.1. Class 0 - Minimally compliant 803 A WPAD implementation which implements only the following discovery 804 mechanisms and interval schemes is considered class 0 compliant: 806 DNS A record queries 807 Browser or System session refresh intervals 809 Class 0 compliance is only applicable to systems or implementations 810 which do not natively support DHCP and or cannot securely determine 811 a trusted local DHCP server. 813 8.2. Class 1 - Compliant 815 A WPAD implementation which implements only the following discovery 816 mechanisms and interval schemes is considered class 1 compliant: 818 DNS A record queries 819 DHCP INFORM Queries 821 Network stack change refresh intervals 822 CFILE expiration refresh intervals 824 8.3. Class 2 - Maximally compliant 826 A WPAD implementation which implements only the following discovery 827 mechanisms and interval schemes is considered class 1 compliant: 829 DNS A record queries 830 DHCP INFORM Queries 831 DNS TXT service: queries 832 DNS SRV RR queries 833 SVRLOC Queries 834 Network stack change refresh intervals 835 CFILE expiration refresh intervals 837 To be considered compliant with a given class, an implementation 838 MUST support the features listed above corresponding to that class. 840 9. Security Considerations 842 This document does not address security of the protocols involved. 843 The WPAD protocol is vulnerable to existing identified weaknesses in 844 DHCP and DNS. The groups driving those standards, as well as the SLP 845 protocol standards, are addressing security. 847 When using DHCP discovery, clients are encouraged to use unicast 848 DHCP INFORM queries instead of broadcast queries which are more 849 easily spoofed in insecure networks. 851 Minimally, it can be said that the WPAD protocol does not create new 852 security weaknesses. 854 Category: Standards Track Expires: December 1999 856 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 858 10. Acknowledgements 860 The authors' work on this specification would be incomplete without 861 the assistance of many people. Specifically, the authors would like 862 the express their gratitude to the following people: 864 Chuck Neerdaels, Inktomi, for providing assistance in the design of 865 the WPAD protocol as well as for providing reference 866 implementations. 868 Arthur Bierer, Darren Mitchell, Sean Edmison, Mario Rodriguez, Danpo 869 Zhang, and Yaron Goland, Microsoft, for providing implementation 870 insights as well as testing and deployment. 872 Ari Luotonen, Netscape, for his role in designing the first web 873 proxy. 875 In addition, the authors are grateful for the feedback provided by 876 the following people: 878 Jeremy Worley - RealNetworks 879 Eric Twitchell - United Parcel Service 881 11. Copyright 883 Copyright (C) The Internet Society 1998. All Rights Reserved. This 884 document and translations of it may be copied and furnished to 885 others, and derivative works that comment on or otherwise explain it 886 or assist in its implementation may be prepared, copied, published 887 and distributed, in whole or in part, without restriction of any 888 kind, provided that the above copyright notice and this paragraph 889 are included on all such copies and derivative works. However, this 890 document itself may not be modified in any way, such as by removing 891 the copyright notice or references to the Internet Society or other 892 Internet organizations, except as needed for the purpose of 893 developing Internet standards in which case the procedures for 894 copyrights defined in the Internet Standards process must be 895 followed, or as required to translate it into languages other than 896 English. The limited permissions granted above are perpetual and 897 will not be revoked by the Internet Society or its successors or 898 assigns. This document and the information contained herein is 899 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 900 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 901 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 902 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 12. References 907 [1] Moats, R., Hamilton, M., and P. Leach, "Finding Stuff (How to 908 discover services)", Internet Draft, October 1997. 910 Category: Standards Track Expires: December 1999 912 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 914 [2] Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying the 915 location of services (DNS SRV)", RFC 2052, October 1996 917 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 918 March 1997. 920 [4] Veizades, J., Guttman, E., Perkins, C., and M. Day, "Service 921 Location Protocol," Internet Draft, October 1997. 923 [5] Hamilton, M., and R. Wright, "Use of DNS Aliases for Network 924 Services", RFC 2219, October 1997. 926 [6] Valloppillil, V., and K. Ross, "Cache Array Routing Protocol", 927 Internet Draft, October 1997. 929 [7] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 930 Extensions", RFC 2132, March 1997. 932 [8] Luotonen, A., "Navigator Proxy Auto-Config File Format", 933 Netscape Corporation, 934 http://home.netscape.com/eng/mozilla/2.0/relnotes/ 935 demo/proxy-live.html, March 1996. 937 [9] Mockapetris, P., "Domain Names - Concepts and Facilities", 938 RFC 1034, November 1987. 940 [10] Perkins, C., Guttman, E., and J. Kempf, "Service Templates and 941 service: Schemes", Internet Draft, December 1997. 943 [11] �A Sample DHCP Implementation for WPAD�, Inktomi Corporation, 944 http://www.inktomi.com/TBD.html, February 1998. 946 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, March 1997. 949 13. Author Information 951 Paul Gauthier 952 Inktomi Corporation 953 1900 South Norfolk Street Suite 310, San Mateo, CA 94403-1151 954 Phone: (650) 653-2800 955 Email: gauthier@inktomi.com 957 Josh Cohen 958 Microsoft Corporation 959 One Microsoft Way, Redmond, WA 98052 960 Phone: (425) 703-5812 961 Email: joshco@microsoft.com 963 Martin Dunsmuir 964 RealNetworks, Inc. 965 1111 3rd Ave, Suite 2900, Seattle, WA 98101 966 Phone: (206) 674-2237 968 Category: Standards Track Expires: December 1999 970 INTERNET-DRAFT Web Proxy Auto-Discovery Protocol 7/28/99 972 Email: martind@real.com 974 Charles Perkins 975 Sun Microsystems, Inc. 976 15 Network Circle, Menlo Park, CA 94025 977 Phone: (650) 786-6464 978 Email: charles.perkins@Sun.COM 980 Category: Standards Track Expires: December 1999