doc: Add RFC documents

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]
+