idnits 2.17.1 draft-moore-sonar-03.txt: ** The Abstract section seems to be numbered 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 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 185: '... A SONAR server MUST check the versio...' RFC 2119 keyword, line 218: '...the request-type MUST be zero. This b...' RFC 2119 keyword, line 221: '...The request-type MAY be ORed with 4000...' RFC 2119 keyword, line 227: '...The request-type MAY be ORed with 2000...' RFC 2119 keyword, line 241: '...R version 0 implementations), and MUST...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 193 has weird spacing: '...st-type mean...' == Line 195 has weird spacing: '... 00 hex chea...' == Line 196 has weird spacing: '... 01 hex mini...' == Line 197 has weird spacing: '... 02 hex mean...' == Line 198 has weird spacing: '... 03 hex mini...' == (29 more instances...) -- 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.) -- The document date (4 August 1998) is 9397 days in the past. Is this intentional? 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 section? '0' on line 437 looks like a reference -- Missing reference section? '1' on line 330 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet-Draft University of Tennessee 3 Expires: 4 March 1998 4 August 1998 5 SONAR - A Network Proximity Service 6 Version 1 8 draft-moore-sonar-03.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents at 19 any time. It is not appropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 2. Abstract 30 SONAR is a service which, when presented with a list of Internet 31 Protocol addresses, attempts to order that list according to the 32 proximity from the SONAR server to each address. Given multiple 33 locations for a network accessible resource, SONAR is designed to help 34 networked applications make a reasonable choice between those 35 alternatives. This memo describes the SONAR protocol as well as an 36 experimental implementation of the SONAR service. 38 While the name "SONAR" is intended as a pun on the "ping" utility 39 that uses ICMP echo requests to verify network connectivity, the SONAR 40 service does not specify use of any particular means of estimating 41 network proximity. To the contrary, the design of SONAR assumes that 42 the best means of estimating network proximity will change over time and 43 perhaps from one network location to another. The SONAR protocol is 44 intended to provide a stable interface for applications that need to 45 measure network proximity, thus allowing proximity measurement 46 algorithms to evolve separately from those applications. 48 3. Introduction 50 One way to make a network-accessible resource available to a large, 51 and perhaps geographically distributed audience is to provide several 52 replicas (or "mirrors") of that resource at multiple locations. If a 53 there are several locations from which a resource can be accessed, and 54 either bandwidth or response-time is important to the user's perceived 55 quality of service, the user will often obtain better service if a 56 "nearby" location of that resource is favored over a "distant" one. 58 The SONAR service is designed to allow such a choice to be made by 59 an application program. Given several alternative locations from which 60 to access a resource, an application program can query a nearby SONAR 61 server to determine which locations are closer than others. The SONAR 62 server will return, for several of those locations, a metric which 63 provides a rough indication of the proximity of that location to the 64 SONAR server. Using those metrics, the application can then choose a 65 single location from which to access the resource. 67 SONAR is designed as an alternative to building proximity 68 estimation algorithms into each of several applications. By placing 69 such functionality into a separate network-accessible service, the 70 proximity estimation algorithm can be tuned (in one place) to suit the 71 requirements of a particular site. It also allows SONAR to evolve 72 independently of the applications that use it. When better proximity 73 estimation algorithms are developed, a site or ISP can upgrade its SONAR 74 servers to allow its existing applications to take advantage of those 75 improvements. 77 SONAR does not guarantee that it finds the "best" location of a 78 resource, nor does it claim to provide a precise measurement of 79 proximity. Instead, the goal of SONAR is to aid clients in making a 80 "good" choice among alternative locations of a service. It should do 81 this without imposing a long delay, and without consuming significant 82 network resources. 84 If the time required to access a resource using SONAR is usually 85 less than the time required to access the resource without it, and if 86 the use of SONAR avoids the "worst case" selection, users will see SONAR 87 as beneficial. Likewise, if the amount of network resources consumed by 88 a SONAR server in measuring network proximity is less than the amount of 89 resources that would be consumed when accessing a randomly chosen 90 location, SONAR will improve the utilization of the network. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document, when they appear in all capital letters, are to be interpreted 95 as described in RFC 2119. 97 4. Protocol 99 This memo describes the second version of SONAR, called version 1. 100 Version 0 of the SONAR protocol was intentionally as simple as possible. 101 Version 1 of SONAR adds support for IPv6, the ability to request a 102 particular kind of proximity metric, and establishes uniform ways for 103 servers to report proximity estimates. 105 An application communicates with a SONAR server using UDP port 572. 106 A SONAR request and response each consist of a single UDP datagram. In 107 the descriptions below, all numeric quantities are in standard network 108 byte order ("big-endian" format, most significant byte transmitted 109 first). 111 4.1 Request formats 113 The format of a SONAR query for IPv4 addresses is as follows: 115 offset datum 116 +-------------------+ 117 0 | protocol-version | 118 +-------------------+ 119 4 | request-type | 120 +-------------------+ 121 8 | request-id | 122 +-------------------+ 123 12 | reserved (MBZ) | 124 +-------------------+ 125 16 | timeout (usec) | 126 +-------------------+ 127 20 | count (1..255) | 128 +-------------------+ 129 24 | address[0] | 130 +-------------------+ 131 28 | address[1] | 132 +-------------------+ 133 | ... | 134 +-------------------+ 135 24+(count-1)*4 | address[count-1] | 136 +-------------------+ 138 The format of a SONAR query for IPv6 addresses is as follows: 140 offset datum 141 +-------------------+ 142 0 | protocol-version | 143 +-------------------+ 144 4 | request-type | 145 +-------------------+ 146 8 | request-id | 147 +-------------------+ 148 12 | reserved (MBZ) | 149 +-------------------+ 150 16 | timeout (usec) | 151 +-------------------+ 152 20 | count (1..255) | 153 +-------------------+ 154 24 | address[0] | 155 +-------------------+ 156 28 | address[0] | 157 +-------------------+ 158 32 | address[0] | 159 +-------------------+ 160 36 | address[0] | 161 +-------------------+ 162 40 | address[1] | 163 +-------------------+ 164 44 | address[1] | 165 +-------------------+ 166 48 | address[1] | 167 +-------------------+ 168 52 | address[1] | 169 +-------------------+ 170 | ... | 171 +-------------------+ 172 24+(count-1)*16 | address[count-1] | 173 +-------------------+ 174 28+(count-1)*16 | address[count-1] | 175 +-------------------+ 176 32+(count-1)*16 | address[count-1] | 177 +-------------------+ 178 36+(count-1)*16 | address[count-1] | 179 +-------------------+ 181 4.1.1 Protocol version 183 The protocol-version field is used to distinguish this version of 184 the SONAR protocol from other versions. This document describes version 185 1 of the protocol. A SONAR server MUST check the version-number of each 186 request and return a "Version Mismatch" response if that version is not 187 supported. 189 4.1.2 Request type 191 For SONAR version 1, valid request-types are as follows: 193 request-type meaning 195 00 hex cheapest proximity estimate 196 01 hex minimum round-trip time (microseconds) 197 02 hex mean round-trip time (microseconds) 198 03 hex minimum client-to-server delay (microseconds) 199 04 hex mean client-to-server delay (microseconds) 200 05 hex minimum server-to-client delay (microseconds) 201 06 hex mean server-to-client delay (microseconds) 202 07 hex maximum client-to-server bandwidth (bits per second) 203 08 hex mean client-to-server bandwidth (bits per second) 204 09 hex maximum server-to-client bandwidth (bits per second) 205 0A hex mean server-to-client bandwidth (bits per second) 206 0B hex mean client-to-server packet loss rate (percent) 207 0C hex mean server-to-client packet loss rate (percent) 208 0D hex mean time between circuit failure (seconds) 209 0E hex end-to-end MTU (octets) 210 0F hex hop count (hops) 212 NOTE: There is no requirement that a SONAR server implement all of these 213 request types. The large number of request types is intended to allow 214 clients to differentiate responses from different kinds of proximity 215 estimation services, and also to encourage experimentation into 216 different ways of estimating proximity. 218 Bit 80000000 (hex) of the request-type MUST be zero. This bit is 219 used to distinguish SONAR requests from SONAR responses. 221 The request-type MAY be ORed with 40000000 (hex) to indicate that 222 substitutions are allowed. If this bit is 0, the server must either 223 return a result in terms of the requested proximity metric, or it must 224 return a "metric unsupported" error. If the bit is 1, the server may 225 substitute some other metric for the one requested. 227 The request-type MAY be ORed with 20000000 (hex) to indicate that 228 the request is for IPv6 addresses. When this bit is set to 0, it 229 indicates that the request contains IPv4 addresses. If the bit is set 230 to 1, it indicates that the request contains IPv6 addresses. 232 4.1.3 Request ID 234 The request-id is any 4 octets chosen by the client, and is used to 235 associate a response with the particular request that produced. The 236 request-id will be included in the SONAR server's response. 238 4.1.4 Reserved field 240 The 4 octets beginning at offset 12 are reserved for future use, 241 (and for compatibility with SONAR version 0 implementations), and MUST 242 be zero. 244 4.1.5 Timeout 246 The timeout is the maximum number of microseconds (4 bytes) which 247 the SONAR server should wait before replying. The server MAY return a 248 response sooner than requested. A timeout of zero microseconds requests 249 that the SONAR server return a response immediately, without any active 250 probing, based on whatever proximity data it has on hand. 252 4.1.6 Address count 254 The address count (4 octets) is the number of addresses for which 255 the SONAR client wants the server to estimate relative proximity. The 256 count may be any value between 1 and 255, inclusive. SONAR servers MUST 257 ignore queries with a count of zero. The most significant three octets 258 of the count field are reserved for future use, and MUST be zero. 260 4.1.7 Addresses 262 Following the address count are that many Internet Protocol 263 addresses. If the request-type had the 20000000 (hex) bit set to 1, the 264 addresses are assumed to be IPv6 addresses; otherwise, they are assumed 265 to be IPv4 addresses. 267 4.2 SUCCESS response formats 269 Version 1 of the SONAR service has several possible response 270 formats, depending on whether the request was successful, and whether 271 the request was for IPv4 or IPv6 addresses. 273 A SUCCESS response for IPv4 is returned in the following format: 275 offset datum 276 +----------------------+ 277 0 | protocol-version = 1 | 278 +----------------------+ 279 4 | response-code | 280 +----------------------+ 281 8 | request-id | 282 +----------------------+ 283 12 | response-count | 284 +----------------------+ 285 16 | address[0] | 286 +----------------------+ 287 20 | metric[0] | 288 +----------------------+ 289 24 | address[1] | 290 +----------------------+ 291 28 | metric[1] | 292 +----------------------+ 293 | ... | 294 +----------------------+ 295 16+(count-1)*8 | address[count-1] | 296 +----------------------+ 297 20+(count-1)*8 | metric[count-1] | 298 +----------------------+ 300 A SUCCESS response for IPv6 is returned in the following format: 302 offset datum 303 +----------------------+ 304 0 | protocol-version = 1 | 305 +----------------------+ 306 4 | response-code | 307 +----------------------+ 308 8 | request-id | 309 +----------------------+ 310 12 | response-count | 311 +----------------------+ 312 16 | address[0] | 313 +----------------------+ 314 20 | address[0] | 315 +----------------------+ 316 24 | address[0] | 317 +----------------------+ 318 28 | address[0] | 319 +----------------------+ 320 32 | metric[0] | 321 +----------------------+ 322 36 | address[1] | 323 +----------------------+ 324 40 | address[1] | 325 +----------------------+ 326 44 | address[1] | 327 +----------------------+ 328 48 | address[1] | 329 +----------------------+ 330 52 | metric[1] | 331 +----------------------+ 332 | ... | 333 +----------------------+ 334 16+(count-1)*20 | address[count-1] | 335 +----------------------+ 336 20+(count-1)*20 | address[count-1] | 337 +----------------------+ 338 24+(count-1)*20 | address[count-1] | 339 +----------------------+ 340 28+(count-1)*20 | address[count-1] | 341 +----------------------+ 342 32+(count-1)*20 | metric[count-1] | 343 +----------------------+ 345 4.2.1 Protocol version 347 Protocol-version will also be 1. For all versions of SONAR, the 348 protocol-version of the response will match that of the request. 350 4.2.2 Response codes 352 The response code indicates whether the request was successful, and 353 if so, the type of metric actually returned in the response. This may 354 be different than the type of metric requested. Successful response 355 codes for SONAR version 1 include the following: 357 response-code meaning 359 80000001 hex minimum round-trip time (microseconds) 360 80000002 hex mean round-trip time (microseconds) 361 80000003 hex minimum client-to-server delay (microseconds) 362 80000004 hex mean client-to-server delay (microseconds) 363 80000005 hex minimum server-to-client delay (microseconds) 364 80000006 hex mean server-to-client delay (microseconds) 365 80000007 hex maximum client-to-server bandwidth (bits per second) 366 80000008 hex mean client-to-server bandwidth (bits per second) 367 80000009 hex maximum server-to-client bandwidth (bits per second) 368 8000000A hex mean server-to-client bandwidth (bits per second) 369 8000000B hex mean client-to-server packet loss rate (percent) 370 8000000C hex mean server-to-client packet loss rate (percent) 371 8000000D hex mean time between circuit failure (seconds) 372 8000000E hex end-to-end MTU (octets) 373 8000000F hex hop count (hops) 375 All response-types have the most significant (80000000) bit set to 376 1, so that responses can be distinguished from queries. 378 The 40000000 bit MUST be zero for a successful response. This bit 379 is used to distinguish SUCCESS responses from FAILURE responses. 381 These responses are ORed with 20000000 hex if the response is for 382 IPv6 addresses. This bit is 1 if the response contains IPv6 addresses; 383 0 if the response contains IPv4 addresses. This should match the 384 20000000 bit in the request-type of the request. 386 4.2.3 Request ID 388 The request-id in the response matches the one from the SONAR 389 query. 391 4.2.4 Response count 393 The response count field contains the number of IP addresses for 394 which proximity data is being returned. The SONAR server MAY return 395 fewer responses than the number of IP addresses for which proximity 396 information was requested. The SONAR server SHOULD limit the amount of 397 information returned if necessary to prevent the resulting datagram from 398 being fragmented. If a SONAR returns fewer responses than requested, it 399 SHOULD return the proximity estimates of the nearest hosts (if delay 400 estimation was requested), or those with the best bandwidth (if 401 bandwidth estimation was requested), or the lowest loss or failure rates 402 (if loss or failure rates were requested), or the highest MTU (if MTU 403 was requested), discarding the estimates of those that appear to be the 404 most distant (have less bandwidth, higher failure or loss rates, lower 405 MTU). However, a server which has several cached proximity estimates 406 from among those requested MAY return estimates for some subset of the 407 cached estimates, without estimating proximity for all hosts requested. 409 4.2.5 Proximity estimates 411 Following the response count are 'response count' sets of proximity 412 metrics. Each metric consists of an (IPv4 or IPv6) address, followed by 413 a proximity estimate. The proximity estimate must be use the correct 414 units for the response-type, as given in section 4.2.2. 416 The addresses returned in a SONAR response are not necessarily 417 sorted by order of proximity; the client must sort them if needed. 419 4.3 FAILURE response formats 421 A SONAR version 1 FAILURE response is of the following form: 423 offset datum 424 +-----------------------------+ 425 0 | protocol-version = 1 | 426 +-----------------------------+ 427 4 | response-code | 428 +-----------------------------+ 429 8 | request-id | 430 +-----------------------------+ 431 12 | low-version | 432 +-----------------------------+ 433 16 | high-version | 434 +-----------------------------+ 435 20 | num-supported-request-types | 436 +-----------------------------+ 437 24 | request-type-bits[0] | 438 +-----------------------------+ 439 | ... | 440 +-----------------------------+ 442 4.3.1 Protocol version 444 The protocol version of a FAILURE response MUST be consistent with 445 the format of the FAILURE response. However, the server SHOULD if pos- 446 sible return FAILURE responses that match the version of the request to 447 maximize the likelihood that the client will be able to understand them. 449 4.3.2 Response code 451 Currently defined FAILURE response codes are the following: 453 response-type meaning 455 C0000000 hex Version Mismatch 456 C0000001 hex Metric Not Supported 458 The "version mismatch" error indicates that the server does not 459 support the version of the protocol used in the client's request. The 460 low and high version fields indicate the versions of SONAR supported by 461 the server. 463 The "metric not supported" error indicates that the client 464 requested a particular kind of metric not supported by the server. This 465 might be either because the client did not set the 40000000 bit of the 466 request, indicating that substitutions were allowed; or because the 467 server could not make a reasonable substitution; or because the server 468 did not understand the request-type used by the client. The request- 469 type-bits field of the response contains the set of request-types sup- 470 ported by the server. 472 4.3.3 Request-ID 474 The request-id in the response MUST match the request-id in the 475 request. 477 4.3.4 Low Version 479 This contains the lowest-numbered version of SONAR supported by the 480 server. 482 4.3.5 High Version 484 This contains the highest-numbered version of SONAR supported by 485 the server. 487 4.3.6 Number of Supported Request Types 489 This field contains the number of request types supported by the 490 server. It indicates the size of the following supported-request-types 491 field. 493 4.3.7 Supported Request Types 495 This field consists of an integral number of 4-octet words, where 496 each word represents 32 elements of a set of supported request types. A 497 bit set to 1 indicates that the corresponding request-type is supported 498 by the server; a bit set to 0 indicates that the corresponding request- 499 type is not supported. Examples: If request-type 0 is supported, bit 0 500 (00000001 hex) if word 0 is set; if request-type 1 is supported, bit 1 501 (00000002 hex) of word 0 is set; if request-type 31 is supported, bit 31 502 (80000000 hex) of word 0 is set; and if request-type 32 is supported, 503 bit 0 (00000001 hex) of word 1 is set to 1. 505 The length of this field is determined by the num-supported- 506 request-types field. This field is ((num-supported-request- 507 types+31)/32)*4 words long. 509 5. Caveats 511 Since different SONAR servers may employ different proximity 512 estimation algorithms, metrics obtained from one SONAR server should be 513 compared with those obtained from a different server, only if they use 514 the same proximity algorithms. 516 Metrics obtained from SONAR should not be cached by an application 517 for any significant amount of time. 519 An application should normally be configured (by whatever means) to 520 use one or more SONAR servers that have a similar view of the network to 521 that application. However, for the case of an application running on a 522 single host which is separated from the rest of the Internet by a slow 523 pipe, where all of the resources of interest are on the "well-connected" 524 side of the link (e.g. a modem dialup connection) the SONAR server 525 should normally be located on the "well-connected" side. 527 In general, applications which examine raw IP addresses may be 528 confused by network address translation (NAT) devices. In particular, 529 applications that use SONAR may be confused if the application and SONAR 530 server are on different sides of a NAT box. In the case where a NAT box 531 dynamically maps 'global' addresses onto some set of 'local' addresses 532 which can be reused (e.g. when mapping global IPv6 addresses onto a 533 local IPv4 network), an application using SONAR will also be confused if 534 the combination of the SONAR server and the application, cache proximity 535 estimation data longer than the NAT box retains its mappings between 536 global and local addresses. 538 Many sites employ firewalls or filtering in routers to discourage 539 hostile attacks or probes from outside (or inside!) of a perimeter. For 540 example, some sites filter ICMP echo requests. Such sites may interfere 541 with the operation of particular kinds of SONAR servers. 543 Sites that employ NATs and/or firewalls often utilize application 544 level gateways or proxies. Use of proxies with SONAR is a topic for 545 further study. 547 6. Finding a SONAR server 549 SONAR complicates configuration of networked applications, because 550 they need to know the address of one or more SONAR servers to use it. 551 It is therefore desirable to minimize the burden of configuration. 553 SONAR-aware applications should perform a DNS query of QTYPE=A on 554 the name "sonar-server" to determine if there are any SONAR servers 555 defined for use by the local domain. (This assumes that DNS searches 556 for unqualified names take place relative to one or more local domains.) 557 Even though the local DNS hierarchy does not necessarily correspond to 558 network topology, this approach will work well for many sites. 560 A future version of SONAR may support location of servers using IP 561 broadcast, IP multicast, DHCP, PPP extensions, service location 562 protocol, or some other means to be determined. 564 7. Security Considerations 566 A naive implementation of SONAR could be used as a vehicle for a 567 denial-of-service attack on a network, for instance, by requesting SONAR 568 to probe multicast or broadcast addresses and thus generating large 569 amounts of traffic. For this reason it is recommended that SONAR 570 servers refuse to process queries sent to IP broadcast or multicast 571 addresses, ignore requests to obtain proximity information for broadcast 572 or multicast addresses, and perhaps ignore requests from remote sites. 574 The security mechanisms employed by a site to prevent certain kinds 575 of attack may thwart use of SONAR. For example, some sites filter ICMP 576 echo requests from external sites for security reasons, even though 577 other protocols such as ftp or http may be allowed. A SONAR 578 implementation that uses ICMP echo will not be able to estimate 579 proximity to hosts behind such a filter. 581 8. Author's address 583 Keith Moore 585 University of Tennessee 586 107 Ayres Hall 587 Knoxville, TN 37996-1301 588 USA 590 A mailing list has been established to discuss the SONAR protocol 591 and its implementation. To request a subscription to the list, send 592 mail to .