summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6760.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6760.txt')
-rw-r--r--doc/rfc/rfc6760.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc6760.txt b/doc/rfc/rfc6760.txt
new file mode 100644
index 0000000..c3d5d5b
--- /dev/null
+++ b/doc/rfc/rfc6760.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Cheshire
+Request for Comments: 6760 M. Krochmal
+Category: Informational Apple Inc.
+ISSN: 2070-1721 February 2013
+
+
+ Requirements for a Protocol to Replace
+ the AppleTalk Name Binding Protocol (NBP)
+
+Abstract
+
+ One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based
+ Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk
+ Name Binding Protocol (NBP) and to replace them with an IP-based
+ solution. This document presents a brief overview of the
+ capabilities of AppleTalk NBP and outlines the properties required of
+ an IP-based replacement.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6760.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 1]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Zero Configuration Networking ...................................4
+ 3. Requirements ....................................................4
+ 3.1. Name-to-Address Mapping ....................................5
+ 3.2. Name Services, Not Hardware ................................5
+ 3.3. Address Services, Not Hardware -- or -- Escape the
+ Tyranny of Well-Known Ports ................................6
+ 3.4. Typed Name Space ...........................................8
+ 3.5. User-Friendly Names ........................................9
+ 3.6. Zeroconf Operation .........................................9
+ 3.7. Name Space Management -- or -- Name Conflict Detection ....10
+ 3.8. Late Binding ..............................................11
+ 3.9. Simplicity ................................................11
+ 3.10. Network Browsing .........................................11
+ 3.11. Browsing and Registration Guidance .......................12
+ 3.12. Power Management Support .................................12
+ 3.13. Protocol Agnostic ........................................13
+ 3.14. Distributed Cache Coherency Protocol .....................13
+ 3.15. Immediate and Ongoing Information Presentation ...........13
+ 4. Existing Protocols .............................................14
+ 5. IPv6 Considerations ............................................14
+ 6. Security Considerations ........................................14
+ 7. Informative References .........................................15
+
+
+
+
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 2]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+1. Introduction
+
+ An important goal of the participants working on Zeroconf, Multicast
+ DNS, and DNS-Based Service Discovery was to provide a viable IP-based
+ replacement for AppleTalk and the AppleTalk Name Binding Protocol
+ (NBP).
+
+ There are many who are experts in the Domain Name System (DNS) who
+ know nothing about the AppleTalk Name Binding Protocol (NBP).
+ Without some background on how AppleTalk and NBP worked, it may be
+ difficult to understand the reasoning and motivations that led to the
+ design decisions in Multicast DNS and DNS-Based Service Discovery.
+
+ This document seeks to remedy this problem by clearly stating the
+ requirements for an IP-based replacement for AppleTalk and NBP.
+ Replacing NBP was not the sole goal of Multicast DNS; therefore,
+ these requirements are not the sole design considerations. However,
+ replacing NBP was a major motivation behind the work in Multicast
+ DNS.
+
+ In most cases, the requirements presented in this document are simply
+ a restatement of what AppleTalk NBP currently does. However, this
+ document is not restricted to describing only what NBP currently
+ does. Achieving at least equivalent functionality to NBP is a
+ necessary but not sufficient condition for a viable replacement. In
+ some cases, the requirements for a viable IP-based replacement go
+ beyond NBP. For example, AppleTalk NBP uses Apple Extended ASCII for
+ its character set. It is clear that an IP-based replacement being
+ designed today should use Unicode, in the form of UTF-8 [RFC3629].
+ AppleTalk NBP has a reputation, partially deserved, for being too
+ 'chatty' on the network. An IP-based replacement should not have
+ this same failing. The intent is to learn from NBP and build a
+ superset of its functionality, not to replicate it precisely with all
+ the same flaws.
+
+ The protocols specified in "Multicast DNS" [RFC6762] and "DNS-Based
+ Service Discovery" [RFC6763], taken together, describe a solution
+ that meets these requirements. This document is written, in part, in
+ response to requests for more background information explaining the
+ rationale behind the design of those protocols.
+
+
+
+
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 3]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+2. Zero Configuration Networking
+
+ Historically, TCP/IP networking required configuration, either in the
+ form of manual configuration by a human operator or in the form of
+ automated configuration provided by a DHCP server [RFC2131].
+
+ One of the characteristics of AppleTalk was that it could operate
+ without any dependency on manual configuration or a network service
+ to provide automated configuration. An AppleTalk network could be as
+ small as just two laptop computers connected via an Ethernet cable
+ (or wirelessly).
+
+ IP now has self-assigned link-local addresses [RFC3927] [RFC4862],
+ which enable IP-based networking in the absence of external
+ configuration. What remains is the need for Zero Configuration name-
+ to-address translation and Zero Configuration service discovery, both
+ capabilities that AppleTalk NBP offered.
+
+ It is not necessarily the case that Zero Configuration Networking
+ protocols will always be used in all three areas (addressing, naming,
+ and service discovery) simultaneously on any given network. For
+ example, even on networks with a DHCP server to provide address
+ configuration, users may still use Zero Configuration protocols for
+ name-to-address translation and service discovery. Indeed, on a
+ single network, users may use conventional Unicast DNS for looking up
+ the addresses of Internet web sites while at the same time using
+ Multicast DNS for looking up the addresses of peers on the local
+ link. Therefore, Zero Configuration Networking protocols must
+ coexist peacefully with conventional configured IP networking when
+ used together on the same network.
+
+ Networks change state over time. Hosts and services may come and go.
+ Connectivity, addresses, and names change. In a manually configured
+ network, a human operator can remedy errors when they arise. In a
+ Zero Configuration Network, no such human operator is available to
+ diagnose and troubleshoot problems, so Zero Configuration protocols
+ need to be self-correcting, automatically accommodating changing
+ network conditions, continually converging to correctness in the
+ absence of human intervention to manually rectify errors.
+
+3. Requirements
+
+ This section lists the 15 requirements for an IP-based replacement
+ for AppleTalk NBP.
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 4]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+3.1. Name-to-Address Mapping
+
+ NBP's primary function is translating names to addresses.
+
+ NBP stands for Name Binding Protocol, not Network Browsing Protocol.
+ Many people know NBP only as "that thing that used to let you browse
+ the network in the old Macintosh Chooser". While browsing is an
+ important facility of NBP, it is secondary to NBP's primary function
+ of translating names to addresses.
+
+ Every time a user prints using AppleTalk, the printing software takes
+ the name of the currently selected printer, looks up the current
+ AppleTalk address associated with that named service, and establishes
+ a connection to that service on the network. The user may invoke
+ NBP's browsing capability once, when first selecting the desired
+ printer in the Chooser, but after that, every time something is
+ printed, it is a simple efficient name-to-address lookup that is
+ being performed, not a full-fledged browsing operation.
+
+ Any NBP replacement needs to support, as its primary function, an
+ efficient name-to-address lookup operation.
+
+3.2. Name Services, Not Hardware
+
+ The primary named entities in NBP are services, not "hosts",
+ "machines", "devices", or pieces of hardware of any kind. This
+ concept is more subtle than it may seem at first, so it bears some
+ discussion.
+
+ The AppleTalk NBP philosophy is that naming a piece of hardware on
+ the network is of little use if you can't communicate with that piece
+ of hardware. To communicate with a piece of hardware, there needs to
+ be a piece of software running on that hardware that sends and
+ receives network packets conforming to some specific protocol. This
+ means that whenever you communicate with a machine, you are really
+ communicating with some piece of software on that machine. Even if
+ you just 'ping' a machine to see if it is responding, it is not
+ really the machine that you are 'pinging', it is the software on that
+ machine that generates ICMP Echo Responses [RFC792].
+
+ Consequently, this means that the only things worth naming are the
+ software entities with which you can communicate. A user who wants
+ to use a print server or a file server needn't care about what
+ hardware implements those services. There may be a single machine
+ hosting both services, or there may be two separate machines. The
+ end user doesn't need to care.
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 5]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+ The one exception to this is network managers, who may want to name
+ physical hardware for the purpose of tracking physical inventory.
+ However, even this can be recast into a service-oriented view of the
+ world by saying that what you're naming is not the hardware, but the
+ ICMP Echo Responder that runs (or is assumed to be running) on every
+ piece of IP hardware.
+
+3.3. Address Services, Not Hardware -- or -- Escape the Tyranny of
+ Well-Known Ports
+
+ The reader may argue that DNS already supports the philosophy of
+ naming services instead of hosts. When we see names like
+ "www.example.com.", "pop.example.com.", "smtp.example.com.",
+ "news.example.com.", and "time.example.com.", we do not assume that
+ those names necessarily refer to different hosts. They are clearly
+ intended to be logical service names and could, in fact, all resolve
+ to the same IP address.
+
+ The shortcoming here is that although the names are clearly logical
+ service names, the result today of doing a conventional ("A" or
+ "AAAA") DNS lookup for those names gives you only the IP address of
+ the hardware where the service is located. To communicate with the
+ desired service, you also need to know the port number at which the
+ service can be reached, not just the IP address.
+
+ This means that the port number has to be communicated out-of-band,
+ in some other way. One way is for the port number to be a specific
+ well-known constant for any given protocol. This makes it hard to
+ run more than one instance of a service on a single piece of
+ hardware. Another way is for the user to explicitly type in the port
+ number, for example, "www.example.com.:8080" instead of
+ "www.example.com.", but needing to know and type in a port number is
+ as ugly and fragile as needing to know and type in an IP address.
+
+ Another aspect of the difficulty of running more than one instance of
+ a service on a single piece of hardware is that it forces application
+ programmers to write their own demultiplexing capability. AppleTalk
+ did not suffer this limitation. If an AppleTalk print server offered
+ three print queues, each print queue ran as its own independent
+ service, listening on its own port number (called a socket number in
+ AppleTalk terminology), each advertised as a separate, independently
+ named NBP entity. When a client looks up the address of that named
+ NBP entity, the reply encodes not only on which net and subnet the
+ service resides, and on which host on that subnet (like an IP address
+ does), but also on which socket number (port number) within that
+ host. In contrast, if an lpr print server offers three print queues,
+ all three print queues are typically reached through the same well-
+ known port number (515), and then the lpr protocol has to use its own
+
+
+
+Cheshire & Krochmal Informational [Page 6]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+ demultiplexing capability (the print queue name) in order to
+ determine which print queue is sought. This makes it especially
+ difficult to run two different pieces of print queue software from
+ different vendors on the same machine, because they cannot both
+ listen on the same well-known port.
+
+ A similar trick is used in HTTP 1.1, where the "Host" header line is
+ used to allow multiple logical HTTP services to run at the same IP
+ address. Again, this works for a single-vendor solution, but if a
+ user wishes to run multiple web servers (for example, an image
+ server, a database program, an HTTP email access gateway, and a
+ conventional HTTP server) on a single machine, they can't all listen
+ on TCP port 80, the traditional HTTP port.
+
+ Yet another problem of well-known ports is that port numbers are a
+ finite resource. Originally, port numbers 0-255 were reserved for
+ well-known services, and the remaining 99.6% of the port space was
+ free for dynamic allocation [RFC1122]. Since then, the range of
+ "Registered Ports" has crept upwards until today, ports 0-49151 are
+ reserved, and only 25% of the space remains available for dynamic
+ allocation. Even though 65535 may seem like a lot of available port
+ numbers, with the pace of software development today, if every new
+ protocol gets its own private port number, we will eventually run
+ out. To avoid having to do application-level demultiplexing,
+ protocols like the X Window System wisely use a range of port
+ numbers, and let TCP do the demultiplexing for them. The X Window
+ System uses 64 ports, in the range 6000-6063. If every new protocol
+ were to get its own chunk of 64 ports, we would run out even faster.
+
+ Any NBP replacement needs to provide, not just the network number,
+ subnet number, and host number within that subnet (i.e., the IP
+ address) but also the port number within that host where the service
+ is located. Furthermore, since many existing IP services such as lpr
+ *do* already use additional application-layer demultiplexing
+ information such as a print queue name, an NBP replacement needs to
+ support this too by including this information as part of the
+ complete package of addressing information provided to the client to
+ enable it to use the service. The NBP replacement needs to name
+ individual print queues as first-class entities in their own right.
+ It is not sufficient merely to name a print server, within which
+ separate print queues can then be found by some other mechanism.
+
+ One possible answer here is that an IP-based NBP replacement could
+ use a solution derived from DNS SRV records instead of "A" records,
+ since SRV records *do* provide a port number. However, this alone is
+ not a complete solution, because SRV records cannot tell you an lpr
+ print queue name.
+
+
+
+
+Cheshire & Krochmal Informational [Page 7]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+3.4. Typed Name Space
+
+ AppleTalk NBP names are structured names, generally written as:
+
+ Name : Type @ Zone
+
+ Name: The Name is the user-visible name of the service.
+
+ Type: The Type is an opaque identifier that identifies the service
+ protocol and semantics. The user may think of the Type as
+ identifying the end-user function that the device performs (e.g.,
+ "printing"), and for the typical end-user, this may be an adequate
+ mental model, but strictly speaking, from a protocol-design
+ perspective, the Type identifies the semantic application protocol
+ the service speaks: no more, no less. For convenience, the opaque
+ Type identifier is generally constructed using descriptive ASCII
+ text, but this text has no meaning to the protocol, and care should
+ be taken in inferring too much meaning from it. For example, the NBP
+ Service Type "LaserWriter" means "any service that speaks
+ PS/PAP/ATP/DDP (PostScript over AppleTalk Printer Access Protocol
+ over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery
+ Protocol)". It does not necessarily mean an Apple-branded
+ "LaserWriter" printer; nor does the service even have to be a
+ printer. A device that archives documents to digital media could
+ advertise itself as a "LaserWriter", meaning that it speaks
+ PostScript over PAP, not necessarily that it prints that document on
+ paper when it gets it. The end-user never directly sees the Service
+ Type. It is implicit in the user's action; for example, when
+ printing, the printing software knows what protocol(s) it speaks and
+ consequently what Service Type(s) it should be looking for -- the
+ user doesn't have to tell it.
+
+ Zone: The Zone is an organizational or geographical grouping of named
+ services. AppleTalk Zones were typically given names like
+ "Engineering", "Sales", or "Building 1, 3rd floor, North". The
+ equivalent concept in DNS could be a subdomain such as
+ "Engineering.example.com.", "Sales.example.com.", or "Building 1, 3rd
+ floor, North.example.com."
+
+ Each {Type,Zone} pair defines a name space in which service names can
+ be registered. It is not a name conflict to have a printer called
+ "Sales" and a file server called "Sales", because one is
+ "Sales:LaserWriter@Zone" and the other is "Sales:AFPServer@Zone".
+
+ Any NBP replacement needs to provide a mechanism that allows names to
+ be grouped into organizational or geographical "zones", and within
+ each "zone", to provide an independent name space for each service
+ type.
+
+
+
+Cheshire & Krochmal Informational [Page 8]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+3.5. User-Friendly Names
+
+ When repeatedly typing in names on command-line systems, it is
+ helpful to have names that are short, all lowercase, without spaces
+ or hard-to-type characters.
+
+ Since Service Names are intended to be selected from a list, not
+ repeatedly typed in on a keyboard, there is no reason for them to be
+ restricted so. Users should be able to give their printers names
+ like "Sales", "Marketing", and "3rd Floor Copy Room", not just
+ "printer1.example.com.". Of course, a user is free to name a
+ particular service using only lowercase letters and no spaces if they
+ wish, but they should not be forced to do that.
+
+ Any NBP replacement needs to support a full range of rich text
+ characters, including uppercase, lowercase, spaces, accented
+ characters, and so on. The correct solution is likely to be UTF-8
+ Unicode [RFC3629].
+
+ Note that this requirement for user-friendly rich-text names applies
+ equally to the zones (domains) in which services are registered and
+ discovered.
+
+ Note that although the characters ':' and '@' are used when writing
+ AppleTalk NBP names, they are simply a notational convenience in
+ written text. In the on-the-wire protocol and in the software data
+ structures, NBP Name, Type, and Zone strings are all allowed to
+ contain almost any character, including ':' and '@'. The naming
+ scheme provided by an NBP replacement must allow the use of any
+ desired characters in service names, including dots ('.'), spaces,
+ percent signs, etc.
+
+3.6. Zeroconf Operation
+
+ AppleTalk NBP is self-configuring. On a network of just two hosts,
+ they communicate peer-to-peer using multicast. On a large managed
+ network, AppleTalk routers automatically perform an aggregation
+ function, allowing name lookups to be performed via unicast to a
+ service running on the router, instead of by flooding the entire
+ network with multicast packets to every host.
+
+ Any NBP replacement needs to be able to operate in the absence of
+ external network infrastructure. However, this should not be the
+ only mode of operation. In larger managed networks, it should also
+ be possible to take advantage of appropriate external network
+ infrastructure when present, to perform queries via unicast instead
+ of multicast.
+
+
+
+
+Cheshire & Krochmal Informational [Page 9]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+3.7. Name Space Management -- or -- Name Conflict Detection
+
+ Because an NBP replacement needs to operate in a Zeroconf
+ environment, it cannot be assumed that a central network
+ administrator is managing the network. Unlike managed networks where
+ normal administrative controls may apply, in the Zeroconf case an NBP
+ replacement must make it easy for users to name their devices as they
+ wish, without the inconvenience or expense of having to seek
+ permission or pay some organization like a domain name registry for
+ the privilege. However, this ease of naming, and freedom to choose
+ any desired name, may lead to name conflicts. Two users may
+ independently decide to run a personal file server on their laptop
+ computers, and (unimaginatively) name it "My Computer". When these
+ two users later attend the next IETF meeting and find themselves part
+ of the same wireless network, there may be problems.
+
+ Similarly, every Brother network printer may ship from the factory
+ with its Service Name set to "Brother Printer". On a typical small
+ home network where there is only one printer, this is not a problem;
+ however, it could become a problem if two or more such printers are
+ connected to the same network.
+
+ Any NBP replacement needs to detect such conflicts, and handle them
+ appropriately. In the case of a laptop computer, which has a
+ keyboard, screen, and a human user, the software should display a
+ message telling the user that they need to select a new name.
+
+ In the case of printers, which typically have no keyboard or screen,
+ the software should automatically select a new unique name, perhaps
+ by appending an integer to the end of the existing name, e.g.,
+ "Brother Printer 2". Note that, although this programmatically
+ derived name should be recorded persistently for use next time the
+ device is powered on, the user is not forced to use that name as the
+ long-term name for the service/device. In a network with more than
+ one printer, the typical user will assign human-meaningful names to
+ those printers, such as "Upstairs Printer" and "Downstairs Printer",
+ but the ability to rename the printer using some configuration tool
+ (e.g., a web browser) depends on the ability to find the printer and
+ connect to it in the first place. Hence, the programmatically
+ derived unique name serves a vital bootstrapping role, even if its
+ use in that role is temporary.
+
+ Because of the potentially transient nature of connectivity on small
+ portable devices that are becoming more and more common (especially
+ when used with wireless networks), this name conflict detection needs
+ to be an ongoing process. It is not sufficient simply to verify
+ uniqueness of names for a few seconds during the boot process and
+ then assume that the names will remain unique indefinitely.
+
+
+
+Cheshire & Krochmal Informational [Page 10]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+ If the Zeroconf naming mechanism is integrated with the existing
+ global DNS naming mechanism, then it would be beneficial for a sub-
+ tree of that global namespace to be designated as having only local
+ significance, for use without charge by cooperating peers, much as
+ portions of the IPv4 address space are already designated as local-
+ significance-only, available for organizations to use locally without
+ charge as they wish [RFC1918].
+
+3.8. Late Binding
+
+ When the user selects their default printer, the software should
+ store only the name, not the IP address and port number. Then, every
+ time the user prints, the software should look up the name to find
+ the current IP address and port number for that service. This allows
+ a named logical service to be moved from one piece of hardware to
+ another without disrupting the user's ability to print to that named
+ print service.
+
+ On a network using DHCP [RFC2131] or self-assigned link-local
+ addresses [RFC3927] [RFC4862], a device's IP address may change from
+ day to day. Deferring binding of name to address until actual use
+ allows the client to get the correct IP address at the time the
+ service is used.
+
+ Similarly, with a service using a dynamic port number instead of a
+ fixed well-known port, the service may not get the same port number
+ every time it is started or restarted. By deferring binding of name
+ to port number until actual use, the client gets the correct port
+ number at the time the service is used.
+
+3.9. Simplicity
+
+ Any NBP replacement needs to be simple enough that vendors of even a
+ low-cost network ink-jet printer can afford to implement it in the
+ device's limited firmware.
+
+3.10. Network Browsing
+
+ AppleTalk NBP offers certain limited wild-card functionality. For
+ example, the service name "=" means "any name". This allows a client
+ to perform an NBP lookup such as "=:LaserWriter@My Zone" and receive
+ back in response a list of all the PS/PAP (AppleTalk Printer Access
+ Protocol) printers in the Zone called "My Zone".
+
+ Any NBP replacement needs to allow a piece of software, such as a
+ printing client or a file server client, to enumerate all the named
+ instances of services in a specified zone (domain) that speak its
+ protocol(s).
+
+
+
+Cheshire & Krochmal Informational [Page 11]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+3.11. Browsing and Registration Guidance
+
+ AppleTalk NBP provides certain meta-information to the client.
+
+ On a network with multiple AppleTalk Zones, the AppleTalk network
+ infrastructure informs the client of the list of Zones that are
+ available for browsing. It also informs the client of the default
+ Zone, which defines the client's logical "home" location. This is
+ the Zone that is selected by default when the Macintosh Chooser is
+ opened, and is usually the Zone where the user is most likely to find
+ services like printers that are physically nearby, but the user is
+ still free to browse any Zone in the offered list that they wish.
+
+ A Brother printer may be pre-configured at the factory with the
+ Service Name "Brother Printer", but they do not know on which network
+ the printer will eventually be installed, so the printer will have to
+ learn this from the network on arrival. On a network with multiple
+ AppleTalk Zones, the AppleTalk network infrastructure informs the
+ client of a single default Zone within which it may register Service
+ Names. In the case of a device with a human user, the AppleTalk
+ network infrastructure may also inform the client of a list of Zones
+ within which the client may register Service Names, and the user may
+ choose to register Service Names in any one of those Zones instead of
+ in the suggested default Zone.
+
+ Any NBP replacement needs to provide the following information to the
+ client:
+
+ * The suggested zone (domain) in which to register Service Names.
+
+ * A list of recommended available zones (domains) in which Service
+ Names may be optionally registered.
+
+ * The suggested default zone (domain) for network browsing.
+
+ * A list of available zones (domains) that may be browsed.
+
+ Note that, because the domains used in this context are intended for
+ service browsing in a graphical user interface, they should be
+ permitted to be full user-friendly rich text, just like the rest of a
+ service name.
+
+3.12. Power Management Support
+
+ Many modern network devices have the ability to go into a low-power
+ mode, where only a small part of the Ethernet hardware remains
+ powered, and the device can be woken up by sending a specially
+ formatted Ethernet frame that the device's power-management hardware
+
+
+
+Cheshire & Krochmal Informational [Page 12]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+ recognizes. A modern service discovery protocol should provide
+ facilities to enable this low-power mode to be used effectively
+ without sacrificing network functionality, such as the ability to
+ discover services on sleeping devices, and wake up a sleeping device
+ when it is needed.
+
+3.13. Protocol Agnostic
+
+ Fashions come and go in the computer industry, but a service
+ discovery protocol, being one of the foundation components on which
+ everything else rests, has to be able to outlive these swings of
+ fashion. A useful service discovery protocol should be agnostic to
+ the protocols being used by the higher-layer software it serves. If
+ a service discovery protocol requires all the higher-layer software
+ to be written in a new computer language, or requires all the higher-
+ layer protocols to embrace some trendy new data representation format
+ that is currently in vogue, then that service discovery protocol is
+ likely to have limited utility after the fashion changes and computer
+ industry moves on to its next infatuation.
+
+3.14. Distributed Cache Coherency Protocol
+
+ Any modern service discovery protocol must use some kind of caching
+ for efficiency. Any time a distributed cache is maintained, a cache
+ coherency protocol is required to control the effects of stale data.
+ Thus, a useful service discovery protocol needs to include cache
+ coherency mechanisms.
+
+3.15. Immediate and Ongoing Information Presentation
+
+ Many current discovery mechanisms display an hourglass or a "Please
+ Wait" message for five or ten seconds, and then present a list of
+ results to the user. At this point, the list of results is static,
+ and does not update in response to changes in the environment. To
+ see current information, the user is forced to click a "Refresh"
+ button repeatedly, waiting another five to ten seconds each time.
+
+ Neither limitation is acceptable in a protocol that is to replace
+ NBP. When a user initiates a browsing operation, the user interface
+ should take at most one second to present the list of results. In
+ addition, the list should update in response to changes in the
+ environment as they happen. If the user is waiting for a particular
+ service to become available, they should be able simply to watch
+ until it appears, with no "Refresh" button that they need to keep
+ clicking. A protocol to replace AppleTalk NBP must be able to meet
+ these requirement for timeliness of information discovery, and
+ liveness of information updating, without placing undue burden on the
+ network.
+
+
+
+Cheshire & Krochmal Informational [Page 13]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+4. Existing Protocols
+
+ Ever since this work began with Stuart Cheshire's email to the net-
+ thinkers@thumper.vmeng.com mailing list in July 1997, the question
+ has been asked, "Isn't SLP the IETF replacement for AppleTalk NBP?"
+
+ The Service Location Protocol (SLP) [RFC2608] provides extremely rich
+ and flexible facilities in the area of Requirement 10, "Network
+ Browsing". However, SLP provides none of the service naming,
+ automatic name conflict detection, or efficient name-to-address
+ lookup that form the majority of what AppleTalk NBP does.
+
+ SLP returns results in the form of URLs. In the absence of DNS, URLs
+ cannot usefully contain DNS names. Discovering a list of service
+ URLs of the form "ipp://169.254.17.202/" is not particularly
+ informative to the user. Discovering a list of service URLs of the
+ form "ipp://epson-stylus-900n.local./" is slightly less opaque
+ (though still not very user-friendly), but to do even this, SLP would
+ have to depend on Multicast DNS or something similar to resolve names
+ to addresses in the absence of a conventional DNS server.
+
+ SLP provides fine-grained query capabilities, such as the ability to
+ prune a long list of printers to show only those that have blue paper
+ in the top tray, which could be useful on extremely large networks
+ with very many printers, but are certainly unnecessary for a typical
+ home or small office with only one or two printers.
+
+ In summary, SLP alone fails to meet most of the requirements, and
+ provides vastly more mechanism than necessary in the area of
+ Requirement 10.
+
+5. IPv6 Considerations
+
+ An IP replacement for the AppleTalk Name Binding Protocol needs to
+ support IPv6 as well as IPv4.
+
+6. Security Considerations
+
+ The AppleTalk Name Binding Protocol was developed in an era when
+ little consideration was given to security issues. In today's world,
+ this would no longer be appropriate. Any modern replacement for
+ AppleTalk NBP should have security measures appropriate to the
+ environment in which it will be used. Given that this document is a
+ broad historical overview of how AppleTalk NBP worked, and does not
+ specify any new protocol(s), it is beyond the scope of this document
+ to provide detailed discussion of possible network environments, what
+ protocols would be appropriate in each, and what security measures
+ would be expected of each such protocol.
+
+
+
+Cheshire & Krochmal Informational [Page 14]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+7. Informative References
+
+ [RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, September 1981.
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
+ "Service Location Protocol, Version 2", RFC 2608, June
+ 1999.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses", RFC 3927, May
+ 2005.
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862, September 2007.
+
+ [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+ February 2013.
+
+ [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
+ Discovery", RFC 6763, February 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 15]
+
+RFC 6760 Replacement of AppleTalk NBP February 2013
+
+
+Authors' Addresses
+
+ Stuart Cheshire
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: cheshire@apple.com
+
+
+ Marc Krochmal
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cheshire & Krochmal Informational [Page 16]
+