idnits 2.17.1 draft-cheshire-dnsext-nbp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (12 January 2011) is 4824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Document: draft-cheshire-dnsext-nbp-10.txt Stuart Cheshire 3 Internet-Draft Marc Krochmal 4 Category: Informational Apple Inc. 5 Expires: 16 July 2011 12 January 2011 7 Requirements for a Protocol to Replace AppleTalk NBP 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on 16th July 2011. 34 Abstract 36 One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based 37 Service Discovery (DNS-SD) was the desire to retire AppleTalk and the 38 AppleTalk Name Binding Protocol, and to replace them with an IP-based 39 solution. This document presents a brief overview of the capabilities 40 of AppleTalk NBP, and outlines the properties required of an IP-based 41 replacement. The views expressed in this Informational document 42 represent the opinions of the authors, not IETF consensus. 44 Table of Contents 46 1. Introduction...................................................3 47 2. Zero Configuration Networking..................................4 48 3. Requirements...................................................5 49 3.1 Name-to-Address Mapping........................................5 50 3.2 Name Services, not Hardware....................................5 51 3.3 Address Services, not Hardware.................................6 52 3.4 Typed Name Space...............................................8 53 3.5 User-Friendly Names............................................9 54 3.6 Zeroconf Operation.............................................9 55 3.7 Name Space Management.........................................10 56 3.8 Late Binding..................................................11 57 3.9 Simplicity....................................................11 58 3.10 Network Browsing..............................................11 59 3.11 Browsing and Registration Guidance............................12 60 3.12 Power Management Support......................................12 61 3.13 Protocol Agnostic.............................................13 62 3.14 Distributed Cache Coherency Protocol..........................13 63 3.15 Immediate and Ongoing Information Presentation................13 64 4. Existing Protocols............................................14 65 5. IPv6 Considerations...........................................14 66 6. Security Considerations.......................................14 67 7. IANA Considerations...........................................15 68 8. Copyright Notice..............................................15 69 9. Informative References........................................15 70 10. Author's Address..............................................16 72 1. Introduction 74 A important goal of the participants working on Zeroconf, Multicast 75 DNS, and DNS-Based Service Discovery was to provide a viable IP-based 76 replacement for AppleTalk and the AppleTalk Name Binding Protocol 77 (NBP). 79 There are many who are experts in the area of DNS who know nothing 80 about NBP, and without some background on how AppleTalk and NBP 81 worked, it may be difficult to understand the reasoning and 82 motivations that led to some of the design decisions in Multicast 83 DNS, and DNS-Based Service Discovery. 85 This document seeks to remedy this problem by clearly stating the 86 requirements for an IP-based replacement for AppleTalk and NBP. 87 Replacing NBP was not the sole goal of Multicast DNS, and therefore 88 these requirements are not the sole design considerations. However, 89 replacing NBP was a major motivation behind the work in Multicast 90 DNS. 92 In most cases, the requirements presented in this document are simply 93 a restatement of what AppleTalk NBP currently does. However, this 94 document is not restricted to describing only what NBP currently 95 does. Achieving at least equivalent functionality to NBP is a 96 necessary but not sufficient condition for a viable replacement. 97 In some cases, the requirements for a viable IP-based replacement go 98 beyond NBP. For example, AppleTalk NBP uses Apple Extended ASCII for 99 its character set. It is clear that an IP-based replacement being 100 designed today should use Unicode, in the form of UTF-8 [RFC 3629]. 101 AppleTalk NBP has a reputation, partially deserved, partially not, 102 for being too 'chatty' on the network. An IP-based replacement should 103 not have this same failing. The intent is to learn from NBP and build 104 a superset of its functionality, not to replicate it precisely with 105 all the same flaws. 107 The protocols specified in "Multicast DNS" [mDNS] and "DNS-Based 108 Service Discovery" [DNS-SD], taken together, describe a solution 109 that meets these requirements. This document is written, in part, 110 in response to requests for more background information explaining 111 the rationale behind the design of those protocols. 113 The design principles and requirements outlined in this Informational 114 document represent the opinions of the authors, not IETF consensus. 116 2. Zero Configuration Networking 118 Historically TCP/IP networking required configuration, either in the 119 form of manual configuration by a human operator, or in the form 120 of automated configuration provided by a DHCP server [RFC 2131]. 122 One of the characteristics of AppleTalk was that it could operate 123 without any dependency on manual configuration of a network service 124 to provide automated configuration. An AppleTalk network could be 125 as small as just two laptop computers connected via an Ethernet 126 cable, or wirelessly. 128 IP now has self-assigned link-local addresses [RFC 3927] [RFC 4862], 129 which enable IP-based networking in the absence of external 130 configuration. What remains is the need for Zero Configuration 131 name-to-address translation and service discovery, both capabilities 132 that AppleTalk NBP offered. 134 It is not necessarily the case that Zero Configuration Networking 135 protocols will always be used in all three areas (addressing, naming, 136 service discovery) simultaneously on any given network. For example, 137 even on networks with a DHCP server to provide address configuration, 138 users may still use Zero Configuration protocols for name-to-address 139 translation and service discovery. Indeed, on a single network, users 140 may use conventional Unicast DNS for looking up the addresses of 141 Internet web sites while at the same time using Multicast DNS for 142 looking up the addresses of peers on the local link. Therefore, Zero 143 Configuration Networking protocols must coexist peacefully with 144 conventional configured IP networking when used together on the same 145 network. 147 Networks change state over time. Hosts and services may come and go. 148 Connectivity, addresses and names change. In a manually configured 149 network a human operator can remedy errors when they arise. In a Zero 150 Configuration Network, no such human operator is available to 151 diagnose and troubleshoot problems, so Zero Configuration protocols 152 need to be self-correcting, automatically accommodating changing 153 network conditions. 155 3. Requirements 157 This section lists the 15 requirements for an IP-based replacement 158 for AppleTalk NBP. 160 3.1 Name-to-Address Mapping 162 NBP's primary function is translating names to addresses. 164 NBP stands for Name Binding Protocol, not Network Browsing Protocol. 165 Many people know NBP only as "that thing that used to let you browse 166 the network in the old Macintosh Chooser". While browsing is an 167 important facility of NBP, it is secondary to NBP's primary function 168 of translating names to addresses. 170 Every time a user prints using AppleTalk, the printing software takes 171 the name of the currently selected printer, looks up the current 172 AppleTalk address associated with that named service, and establishes 173 a connection to that service on the network. The user may invoke 174 NBP's browsing capability once when first selecting the desired 175 printer in the Chooser, but then after that, every time something 176 is printed, it is a simple efficient name-to-address lookup 177 that is being performed, not a full-fledged browsing operation. 179 Any NBP replacement needs to support, as it's primary function, 180 an efficient name-to-address lookup operation. 182 3.2 Name Services, not Hardware 184 The primary named entities in NBP are services, not "hosts", 185 "machines", "devices", or pieces of hardware of any kind. This 186 concept is more subtle than it may seem at first, so it bears some 187 discussion. 189 The AppleTalk NBP philosophy is that naming a piece of hardware on 190 the network is of little use if you can't communicate with that piece 191 of hardware. To communicate with a piece of hardware, there needs 192 to be a piece of software running on that hardware which sends and 193 receives network packets conforming to some specific protocol. This 194 means that whenever you communicate with a machine, you are really 195 communicating with some piece of software on that machine. Even if 196 you just 'ping' a machine to see if it is responding, it is not 197 really the machine that you are 'pinging', it is the software on 198 that machine that generates ICMP Echo Responses [RFC 792]. 200 Consequently, this means that the only thing worth naming is the 201 software entities with which you can communicate. A user who wants to 202 use a print server or a file server needn't care about what hardware 203 implements those services. There may be a single machine hosting both 204 services, or there may be two separate machines. The end user doesn't 205 need to care. 207 The one exception to this is network managers, who may want to name 208 physical hardware for the purpose of tracking physical inventory. 209 However, even this can be recast into a service-oriented view of the 210 world by saying that what you're naming is not the hardware, but the 211 ICMP Echo Responder that runs (or is assumed to be running) on every 212 piece of IP hardware. 214 3.3 Address Services, not Hardware 215 -or- 216 Escape the Tyranny of Well Known Ports 218 The reader may argue that DNS already supports the philosophy 219 of naming services instead of hosts. When we see names like 220 "www.example.com.", "pop.example.com.", "smtp.example.com.", 221 "news.example.com." and "time.example.com.", we do not assume that 222 each of those names refer to a different host. They are clearly 223 intended to be logical service names, and could in fact all refer 224 to the same IP address. 226 The shortcoming here is that although the names are clearly logical 227 service names, the result today of doing a conventional ("A" or 228 "AAAA") DNS lookup for those names gives you only the IP address 229 of the hardware where the service is located. To communicate with 230 the desired service, you also need to know the port number 231 at which the service can be reached, not just the IP address. 233 This means that the port number has to be communicated out-of-band, 234 in some other way. One way is for the port number to be a specific 235 well-known constant for any given protocol. This makes it hard 236 to run more than one instance of a service on a single piece of 237 hardware. Another way is for the user to explicitly type in the 238 port number, for example, "www.example.com.:8080" instead of 239 "www.example.com.", but needing to know and type in a port number 240 is as ugly and fragile as needing to know and type in an IP address. 242 Another aspect of the difficulty of running more than one instance of 243 a service on a single piece of hardware is that it forces application 244 programmers to write their own demultiplexing capability. AppleTalk 245 did not suffer this limitation. If an AppleTalk print server offered 246 three print queues, each print queue ran as its own independent 247 service, listening on its own port number (called a socket number 248 in AppleTalk terminology), each advertised as a separate independent 249 named NBP entity. When a client looks up the address of that named 250 NBP entity, the reply encodes not only on which net and subnet the 251 service resides, and on which host on that subnet (like an IP address 252 does), but also on which socket number (port number) within that 253 host. In contrast, if an lpr print server offers three print queues, 254 all three print queues are typically reached through the same 255 well-known port number (515), and then the lpr protocol has to use 256 its own demultiplexing capability (the print queue name) in order 257 to determine which print queue is sought. This makes it especially 258 difficult to run two different pieces of print queue software from 259 different vendors on the same machine, because they cannot both use 260 the same well-known port. 262 A similar trick is used in HTTP 1.1, where the "Host" header line 263 is used to allow multiple logical http services to run at the same 264 IP address. Again, this works for a single-vendor solution, but if 265 you have an image server, a database program, an http email access 266 gateway, and a standard http server, they can't all run on the same 267 TCP port on the same machine. 269 Yet another problem of well-known ports is that port numbers are a 270 finite resource. Originally, port numbers 0-255 were reserved for 271 well-known services and the remaining 99.6% of the port space was 272 free for dynamic allocation [RFC 1122]. Since then, the range of 273 "Registered Ports" has crept upwards until today, ports 0-49151 are 274 reserved, and only 25% of the space remains available for dynamic 275 allocation. Even though 65535 may seem like a lot of available port 276 numbers, with the pace of software development today, if every new 277 protocol gets its own private port number, we will eventually 278 run out. To avoid having to do application-level demultiplexing, 279 protocols like the X Window System wisely use a range of port 280 numbers, and let TCP do the demultiplexing for them. The X Window 281 System uses 64 ports, in the range 6000-6063. If every new protocol 282 were to get its own chunk of 64 ports, we would run out even faster. 284 Any NBP replacement needs to provide, not just the network number, 285 subnet number, and host number within that subnet (i.e. the IP 286 address) but also the port number within that host where the service 287 is located. Furthermore, since many existing IP services such as 288 lpr *do* already use additional application-layer demultiplexing 289 information such as a print queue name, an NBP replacement needs 290 to support this too by including this information as part of the 291 complete package of addressing information provided to the client 292 to enable it to use the service. The NBP replacement needs to name 293 individual print queues as first-class entities in their own right. 294 It is not sufficient merely to name a print server, within which 295 separate print queues can then be found by some other mechanism. 297 One possible answer here is that an IP-based NBP replacement could 298 use a solution derived from DNS SRV records instead of "A" records, 299 since SRV records *do* provide a port number. However, this alone is 300 not a complete solution, because SRV records cannot tell you an lpr 301 print queue name. 303 3.4 Typed Name Space 305 AppleTalk NBP names are structured names, generally written as: 307 Name : Type @ Zone 309 Name: The Name is the user-visible name of the service. 311 Type: The Type is an opaque identifier which identifies the service 312 protocol and semantics. The user may think of the Type as identifying 313 the end-user function that the device performs (e.g. "printing"), and 314 for the typical end-user this may be an adequate mental model, but 315 strictly speaking, from a protocol-design perspective, the Type 316 identifies the semantic application protocol the service speaks, 317 no more, no less. For convenience, the opaque Type identifier is 318 generally constructed using descriptive ASCII text, but this text has 319 no meaning to the protocol, and care should be taken in inferring too 320 much meaning from it. For example, the NBP Service Type "LaserWriter" 321 means "any service that speaks PostScript over PAP/ATP/DDP (AppleTalk 322 Printer Access Protocol over AppleTalk Transaction Protocol over 323 AppleTalk Datagram Delivery Protocol)". It does not necessarily mean 324 an Apple-branded "LaserWriter" printer; nor does the service even 325 have to be a printer. A device that archives documents to digital 326 media could advertise itself as a "LaserWriter", meaning that it 327 speaks PostScript over PAP, not necessarily that it prints that 328 document on paper when it gets it. The end-user never directly sees 329 the Service Type. It is implicit in the user's action; e.g. when 330 printing, the printing software knows what protocol(s) it speaks and 331 consequently what Service Type(s) it should be looking for -- the 332 user doesn't have to tell it. 334 Zone: The Zone is an organizational or geographical grouping of named 335 services. Typical AppleTalk Zone Names are things like "Engineering", 336 "Sales", and "Building 1, 3rd floor, North". The equivalent concept 337 in DNS could be a subdomain such as "Engineering.example.com.", 338 "Sales.example.com." or "Building 1, 3rd floor, North.example.com." 340 Each {Type,Zone} pair defines a name space in which service names 341 can be registered. It is not a name conflict to have a printer 342 called "Sales" and a file server called "Sales", because one is 343 "Sales:LaserWriter@Zone" and the other is "Sales:AFPServer@Zone". 345 Any NBP replacement needs to provide a mechanism that allows names 346 to be grouped into organizational or geographical "zones", and within 347 each "zone", to provide an independent name space for each service 348 type. 350 3.5 User-Friendly Names 352 When repeatedly typing in names on command-line systems, it is 353 helpful to have names that are short, all lower-case, with no spaces 354 or other unusual characters. 356 Since Service Names are intended to be selected from a list, not 357 repeatedly typed in on a keyboard, there is no reason for them to 358 be restricted so. Users should be able to give their printers names 359 like "Sales", "Marketing", and "3rd Floor Copy Room", not just 360 "printer1.example.com." Of course a user is free to name a particular 361 service using only lower-case letters and no spaces if they wish, 362 but they should not be forced to do that. 364 Any NBP replacement needs to support a full range of rich text 365 characters, including upper case, lower case, spaces, accented 366 characters, and so on. The correct solution is likely to be UTF-8 367 Unicode [RFC 3629]. 369 Note that this requirement for user-friendly rich-text names applies 370 equally to the Zones/domains in which services are registered and 371 discovered. 373 Note that although the characters ':' and '@' are used when writing 374 AppleTalk NBP names, they are simply a notational convenience in 375 written text. In the on-the-wire protocol and in the software data 376 structures, NBP Name, Type and Zone strings are all allowed to 377 contain almost any character, including ':' and '@'. The naming 378 scheme provided by an NBP replacement must allow use of any desired 379 characters in service names, including dots ('.'), spaces, percent 380 signs, etc. 382 3.6 Zeroconf Operation 384 AppleTalk NBP is self-configuring. On a network of just two hosts, 385 they communicate peer-to-peer using multicast. On a large managed 386 network, AppleTalk routers automatically perform an aggregation 387 function, allowing name lookups to be performed via unicast to a 388 service running on the router, instead of by flooding the entire 389 network with multicast packets to every host. 391 Any NBP replacement needs to be able to operate in the absence of 392 external network infrastructure. However, this should not be the only 393 mode of operation. In larger managed networks, it should also be 394 possible to take advantage of appropriate external network 395 infrastructure when present, to perform queries via unicast instead 396 of multicast. 398 3.7 Name Space Management 399 -or- 400 Name Conflict Detection 402 Because an NBP replacement needs to operate in a Zeroconf 403 environment, it cannot be assumed that a central network 404 administrator is managing the network. In a managed network normal 405 administrative controls may apply, but in the Zeroconf case an NBP 406 replacement must make it easy for users to name their devices as 407 they wish, without the inconvenience or expense of having to seek 408 permission or pay some organization like a domain name registry for 409 the privilege. However, this ease of naming and freedom to choose any 410 desired name means that two users may independently decide to run a 411 personal file server on their laptop computers, and (unimaginatively) 412 name it "My Computer". When these two users later attend the next 413 IETF meeting and find themselves part of the same wireless network, 414 there may be problems. 416 Similarly, every Brother network printer may ship from the factory 417 with its Service Name set to "Brother Printer". On a typical small 418 home network where there is only one printer this is not a problem, 419 but it could be a problem if two or more such printers are connected 420 to the same network. 422 Any NBP replacement needs to detect such conflicts, and handle 423 them appropriately. In the case of the laptop computers, which have 424 keyboards, screens, and human users, the software should display a 425 message telling one or both users that they need to select a new 426 name. 428 In the case of the printers which have no keyboard or screen, the 429 software should automatically select a new unique name, perhaps by 430 appending an integer to the end of the existing name, e.g. "Brother 431 Printer 2". Note that although this programmatically-derived name 432 should be recorded persistently for use next time the device is 433 powered on, the user is not forced to use that name as the long-term 434 name for the service/device. In a network with more than one printer, 435 the typical user will assign human-meaningful names to those 436 printers, such as "Upstairs Printer" and "Downstairs Printer", but 437 the ability to rename the printer using some configuration tool (e.g. 438 a Web Browser) depends on the ability to find the printer and connect 439 to it in the first place. Hence the programmatically-derived unique 440 name serves a vital bootstrapping role, even if its use in that role 441 is short-lived. 443 Because of the potentially transient nature of connectivity on small 444 portable devices that are becoming more and more common (especially 445 when used with wireless networks), this name conflict detection 446 needs to be an ongoing process. It is not sufficient to simply verify 447 uniqueness of names for a few seconds during the boot process and 448 then assume that the names will remain unique indefinitely. 450 If the Zeroconf naming mechanism is integrated with the existing 451 global DNS naming mechanism, then it would be beneficial for a sub- 452 tree of that global namespace to be designated as having only local 453 significance, for use without charge by cooperating peers, much 454 as portions of the IPv4 address space are already designated as 455 local-significance-only, available for organizations to use locally 456 without charge as they wish [RFC 1918]. 458 3.8 Late Binding 460 When the user selects their default printer, the software should not 461 store the IP address and port number, but just the name. Then, every 462 time the user prints, the software should look up the name to find 463 the current IP address and port number for that service. This allows 464 a named logical service to be moved from one piece of hardware to 465 another without disrupting the user's ability to print to that named 466 print service. 468 On a network using DHCP [RFC 2131] or self-assigned link-local 469 addresses [RFC 3927] [RFC 4862], a device's IP address may change 470 from day to day. By deferring binding of name to address until actual 471 use, this allows the client to get the correct IP address at the time 472 the service is used. 474 Similarly, with a service using a dynamic port number instead of a 475 fixed well-known port, the service may not get the same port number 476 every time it is started or restarted. By deferring binding of name 477 to port number until actual use, this allows the client to get the 478 correct port number at the time the service is used. 480 3.9 Simplicity 482 Any NBP replacement needs to be simple enough that vendors of even 483 a low-cost network ink-jet printer can afford to implement it in the 484 device's limited firmware. 486 3.10 Network Browsing 488 AppleTalk NBP offers certain limited wild-card functionality. For 489 example, the service name "=" means "any name". This allows a client 490 to perform an NBP lookup such as "=:LaserWriter@My Zone" and receive 491 back in response a list of all the PAP (AppleTalk Printer Access 492 Protocol) printers in the Zone called "My Zone". 494 Any NBP replacement needs to allow a piece of software, such as a 495 printing client, or a file server client, to enumerate all the named 496 instances of services in a specified zone (domain) which speak its 497 protocol(s). 499 3.11 Browsing and Registration Guidance 501 AppleTalk NBP provides certain meta-information to the client. 503 On a network with multiple AppleTalk Zones, the AppleTalk network 504 infrastructure informs the client of the list of Zones that are 505 available for browsing. It also informs the client of the default 506 Zone, which defines the client's logical "home" location. This is 507 the Zone that is selected by default when the Macintosh Chooser is 508 opened, and is usually the Zone where the user is most likely to find 509 services like printers that are physically nearby, but the user is 510 still free to browse any Zone in the offered list that they wish. 512 A Brother printer may be pre-configured at the factory with the 513 Service Name "Brother Printer", but they do not know on which network 514 the printer will eventually be installed, so the printer will have to 515 learn this from the network on arrival. On a network with multiple 516 AppleTalk Zones, the AppleTalk network infrastructure informs the 517 client of a single default Zone within which it may register Service 518 Names. In the case of a device with a human user, the AppleTalk 519 network infrastructure may also inform the client of a list of Zones 520 within which the client may register Service Names, and the user may 521 choose to register Service Names in any one of those Zones instead of 522 in the suggested default Zone. 524 Any NBP replacement needs to provide the following information to 525 the client: 527 * The suggested zone (domain) in which to register Service Names. 528 * A list of recommended available zones (domains) in which Service 529 Names may be optionally registered. 530 * The suggested default zone (domain) for network browsing. 531 * A list of available zones (domains) which may be browsed. 533 Note that because the domains used in this context are intended 534 for service browsing in a graphical user interface, they should 535 be permitted to be full user-friendly rich text, just like the 536 rest of a service name. 538 3.12 Power Management Support 540 Many modern network devices have the ability to go into a low-power 541 mode where only a small part of the Ethernet hardware remains 542 powered, and the device can be woken up by sending a specially 543 formatted Ethernet frame which the device's power-management hardware 544 recognizes. A modern service discovery protocol should provide 545 facilities to enable this low-power mode to be used effectively 546 without sacrificing network functionality, such as the ability to 547 wake a device up when it is needed. 549 3.13 Protocol Agnostic 551 Fashions come and go in the computer industry, but a service 552 discovery protocol, being one of the foundation components on which 553 everything else rests, has to be able to outlive these swings of 554 fashion. A useful service discovery protocol should be agnostic to 555 the protocols being used by the higher-layer software it serves. If a 556 service discovery protocol requires all the higher layer software to 557 be written in a new computer language, or requires all the higher 558 layer protocols to embrace some trendy new data representation format 559 that is currently in vogue, then that service discovery protocol is 560 likely to have limited utility after the fashion changes and computer 561 industry moves on to its next infatuation. 563 3.14 Distributed Cache Coherency Protocol 565 Any modern service discovery protocol must use some kind of caching 566 for efficiency. Any time a distributed cache is maintained, a cache 567 coherency protocol is required to control the effects of stale data. 568 Thus a useful service discovery protocol needs to include cache 569 coherency mechanisms. 571 3.15 Immediate and Ongoing Information Presentation 573 Many current discovery mechanisms display an hourglass or a "Please 574 Wait" message for five or ten seconds, and then present a list of 575 results to the user. At this point, the list of results is static, 576 and does not update in response to changes in the environment. 577 To see current information the user is forced to click a "Refresh" 578 button repeatedly, waiting another five to ten seconds each time. 580 Neither limitation is acceptable in a protocol that is to replace 581 NBP. When a user initiates a browsing operation, the user interface 582 should take at most one second to present the list of results. 583 In addition, the list should update in response to changes in the 584 environment as they happen. If the user is waiting for a particular 585 service to become available, they should be able simply to watch 586 until it appears, with no "Refresh" button that they need to keep 587 clicking. A protocol to replace AppleTalk NBP must be able to meet 588 these requirement for timeliness of information discovery, and 589 liveness of information updating, without placing undue burden 590 on the network. 592 4. Existing Protocols 594 The question has been asked, "Isn't SLP the IETF replacement for 595 NBP?" 597 SLP [RFC 2608] provides extremely rich and flexible facilities in 598 the area of Requirement 10, "Network Browsing". However, SLP provides 599 none of the service naming, automatic name conflict detection, or 600 efficient name-to-address lookup which form the majority of what 601 AppleTalk NBP does. 603 SLP returns results in the form of URLs. In the absence of DNS, URLs 604 cannot usefully contain DNS names. Discovering a list of service URLs 605 of the form "ipp://169.254.17.202/" is not particularly informative 606 to the user. Discovering a list of service URLs of the form 607 "ipp://epson-stylus-900n.local./" is slightly less opaque (though 608 still not very user-friendly), but to do even this SLP would have 609 to depend on Multicast DNS or something similar to resolve names 610 to addresses in the absence of a conventional DNS server. 612 SLP provides fine-grained query capabilities, such as the ability to 613 prune a long list of printers to show only those that have blue paper 614 in the top tray, which could be useful on extremely large networks 615 with very many printers, but are certainly unnecessary for a typical 616 home or small office with only one or two printers. 618 In summary, SLP alone fails to meet most of the requirements, 619 and provides vastly more mechanism than necessary in the area of 620 Requirement 10. 622 5. IPv6 Considerations 624 An IP replacement for AppleTalk Name Binding Protocol needs to 625 support IPv6 as well as IPv4. 627 6. Security Considerations 629 AppleTalk Name Binding Protocol was developed in an era where little 630 consideration was given to security issues. In today's world this 631 would no longer be appropriate. Any modern replacement for AppleTalk 632 NBP should have security measures appropriate to the environment in 633 which it will be used. Given that this document is a broad historical 634 overview of how AppleTalk NBP worked, and does not specify any new 635 protocol(s), detailed discussion of possible network environments, 636 what protocols would be appropriate in each, and what security 637 measures would be expected of each such protocol, is beyond the scope 638 of this document. 640 7. IANA Considerations 642 No IANA actions are required by this document. 644 8. Copyright Notice 646 Copyright (c) 2011 IETF Trust and the persons identified as the 647 document authors. All rights reserved. 649 This document is subject to BCP 78 and the IETF Trust's Legal 650 Provisions Relating to IETF Documents 651 (http://trustee.ietf.org/license-info) in effect on the date of 652 publication of this document. Please review these documents 653 carefully, as they describe your rights and restrictions with respect 654 to this document. 656 9. Informative References 658 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 659 Discovery", Internet-Draft (work in progress), 660 draft-cheshire-dnsext-dns-sd-08.txt, January 2011. 662 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 663 Internet-Draft (work in progress), 664 draft-cheshire-dnsext-multicastdns-13.txt, January 2011. 666 [RFC 792] Postel, J., "Internet Control Message Protocol", 667 STD 5, RFC 792,September 1981. 669 [RFC 1122] Braden, R. (Editor), "Requirements for Internet Hosts -- 670 Communication Layers", STD 3, RFC 1122, October 1989. 672 [RFC 1918] Rekhter, Y., et al., "Address Allocation for Private 673 Internets", RFC 1918, February 1996. 675 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", 676 RFC 2131, March 1997. 678 [RFC 2608] Guttman, Perkins, Veizades & Day, "Service Location 679 Protocol, Version 2", RFC 2608, June 1999. 681 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 682 10646", RFC 3629, November 2003. 684 [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, 685 "Dynamic Configuration of IPv4 Link-Local Addresses", 686 RFC 3927, May 2005. 688 [RFC 4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 689 Address Autoconfiguration", RFC 4862, September 2007. 691 10. Author's Address 693 Stuart Cheshire 694 Apple Inc. 695 1 Infinite Loop 696 Cupertino 697 California 95014 698 USA 700 Phone: +1 408 974 3207 701 EMail: cheshire@apple.com 703 Marc Krochmal 704 Apple Inc. 705 1 Infinite Loop 706 Cupertino 707 California 95014 708 USA 710 Phone: +1 408 974 4368 711 EMail: marc@apple.com