GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6760

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6760.txt · Last modified: 2013/02/20 20:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki