RFC 6760

Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)

📅 published February 2013, from ietf

RFC 6760: Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) 🎀

Okay so this RFC was written by S. Cheshire and M. Krochmal, both from Apple Inc. ✨ It's dated February 2013 and its category is Informational, so it's not an Internet Standards Track spec 📖 The ISSN is 2070-1721. The title block has no Obsoletes or Updates entries, so this one doesn't obsolete or update anything 🫶

Abstract 🌸

Okay so the people behind Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) had a big goal: retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and replace them with an IP-based solution 💅 This doc gives a quick rundown of what AppleTalk NBP can do and lays out the properties an IP-based replacement needs to have 🦋

Status of This Memo 📌

This document is not an Internet Standards Track specification. It's published just for informational purposes 🌈

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). ✨ Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🧐

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6760 💖

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) as they stand on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as the Simplified BSD License describes 📜

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

1. Introduction 💖

A big goal for the folks working on Zeroconf, Multicast DNS, and DNS-Based Service Discovery was to build a viable IP-based replacement for AppleTalk and the AppleTalk Name Binding Protocol (NBP) 🎀

Here's the thing: lots of people who are DNS experts have never heard of AppleTalk NBP 🙈 Without some background on how AppleTalk and NBP worked, it can be really hard to get why Multicast DNS and DNS-Based Service Discovery were designed the way they were ✨

So this document fixes that by clearly spelling out the requirements for an IP-based replacement for AppleTalk and NBP 📝 Replacing NBP wasn't the only goal of Multicast DNS, so these requirements aren't the only design considerations. Still, replacing NBP was a major motivation behind the Multicast DNS work 🦋

Mostly, the requirements here just restate what AppleTalk NBP already does. But this doc isn't limited to what NBP does today 👑 Matching NBP's functionality is a necessary but not sufficient condition for a viable replacement. Sometimes the requirements go beyond NBP. For example, AppleTalk NBP uses Apple Extended ASCII as its character set. An IP-based replacement designed today should use Unicode, in the form of UTF-8 [RFC3629] 🌈 AppleTalk NBP also has a reputation, partly deserved, for being too 'chatty' on the network. An IP-based replacement should not have that same failing 💀 The goal is to learn from NBP and build a superset of its functionality, not to copy it exactly with all the same flaws 💅

The protocols in "Multicast DNS" [RFC6762] and "DNS-Based Service Discovery" [RFC6763], taken together, describe a solution that meets these requirements ✨ This document is partly a response to requests for more background on the reasoning behind those protocols' designs 🧚

2. Zero Configuration Networking 🦋

Historically, TCP/IP networking needed configuration, either manually by a human operator or automatically through a DHCP server [RFC2131] 🙃

One of AppleTalk's defining traits was that it could work with no dependency on manual configuration or on a network service for automatic configuration 🍓 An AppleTalk network could be as tiny as two laptops connected by an Ethernet cable (or wirelessly) 💜

IP now has self-assigned link-local addresses [RFC3927] [RFC4862], which make IP networking possible without any external configuration 🌸 What's still missing is Zero Configuration name-to-address translation and Zero Configuration service discovery, which are both things AppleTalk NBP offered ✨

Zero Configuration Networking protocols won't always be used in all three areas at once (addressing, naming, and service discovery) on a given network 💖 For example, even on a network with a DHCP server handling address configuration, users may still use Zero Configuration protocols for name-to-address translation and service discovery. Honestly, on a single network, users might use conventional Unicast DNS to look up the addresses of Internet websites while using Multicast DNS to look up the addresses of peers on the local link 🌐 So Zero Configuration Networking protocols have to coexist peacefully with conventional configured IP networking when they're used on the same network 🫶

Networks change over time 🔄 Hosts and services come and go, and connectivity, addresses, and names all change. On a manually configured network, a human operator can fix errors as they pop up 🧑‍💻 But on a Zero Configuration Network there's no human operator around to diagnose and troubleshoot problems 😭 So Zero Configuration protocols need to be self-correcting. They have to automatically adapt to changing network conditions and keep converging on correctness without anyone manually fixing errors ⭐

3. Requirements 📝

This section lists the 15 requirements for an IP-based replacement for AppleTalk NBP 🎀

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 🙈 Lots of people only know NBP as "that thing that used to let you browse the network in the old Macintosh Chooser" 🍎 Browsing is an important feature of NBP, but it's secondary to its main job of translating names to addresses ✨

Every time a user prints with AppleTalk, the printing software takes the name of the currently selected printer, looks up the current AppleTalk address associated with that named service, and sets up a connection to that service on the network 🖨️ The user might invoke NBP's browsing feature once, when first picking the printer in the Chooser. After that, every print job is just a simple, efficient name-to-address lookup, not a full-blown browsing operation 🦋

So any NBP replacement needs to support, as its primary function, an efficient name-to-address lookup operation 👑

3.2. Name Services, Not Hardware 💅

The main named entities in NBP are services, not "hosts", "machines", "devices", or pieces of hardware of any kind 🧚 This idea is subtler than it looks at first, so it's worth talking through 🫧

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 hardware 📡 To talk to a piece of hardware, there has to be software running on it that sends and receives network packets following some specific protocol. So whenever you communicate with a machine, you're really communicating with some software on that machine 💜 Even if you just 'ping' a machine to see whether it's responding, you're not really pinging the machine. You're pinging the software on it that generates ICMP Echo Responses [RFC792] 🏓

That means the only things worth naming are the software entities you can actually communicate with 💖 A user who wants to use a print server or a file server doesn't need to care what hardware runs those services. One machine might host both, or they might be on two separate machines, and the end user doesn't need to know either way 🌸

The one exception is network managers, who might want to name physical hardware to track their inventory 📦 Even that can be recast in a service-oriented view: what you're naming isn't the hardware itself, but the ICMP Echo Responder that runs (or is assumed to be running) on every piece of IP hardware 🌈

tbc, part 2 incoming 🧚💜

3.3. Address Services, Not Hardware -- or -- Escape the Tyranny of Well-Known Ports 🦋

Okay but hear me out 🧚 someone's gonna say DNS already does the whole "name the service, not the host" thing, and like... fair? When you see www.example.com., pop.example.com., smtp.example.com., news.example.com., and time.example.com., you don't automatically assume they're five different machines. They're clearly meant to be logical service names, and they could literally all resolve to the same IP address 💅

The catch is that even though those names are obviously logical service names, a normal ("A" or "AAAA") DNS lookup today only hands you the IP address of the hardware where the service lives 😩 To actually talk to the service, you also need the port number it's reachable on, not just the IP address.

So the port number has to be shared out-of-band, some other way. One option is making the port a specific well-known constant for each protocol, but that makes it really hard to run more than one instance of a service on one piece of hardware 🙃 Another option is for the user to type the port number in themselves, like "www.example.com.:8080" instead of "www.example.com.", and honestly, needing to know and type a port number is just as ugly and fragile as needing to know and type an IP address 💀

Running more than one instance of a service on one machine is also a problem because it forces application programmers to write their own demultiplexing capability. AppleTalk didn't have this limitation, and it was so good about it 😭 If an AppleTalk print server offered three print queues, each queue ran as its own independent service, listening on its own port number (called a socket number in AppleTalk terminology), and each one was advertised as a separate, independently named NBP entity. When a client looked up the address of that named NBP entity, the reply encoded not only which net and subnet the service lived on and which host on that subnet (like an IP address does), but also which socket number (port number) within that host. Iconic.

Compare that to an lpr print server with three print queues. All three are typically reached through the same well-known port number (515), so the lpr protocol has to use its own demultiplexing capability (the print queue name) to figure out which queue is being asked for 🫠 That makes it especially painful to run two different pieces of print queue software from different vendors on the same machine, because they can't both listen on the same well-known port. Not me, having to fight over a port like it's a parking spot 🚗

HTTP 1.1 does a similar trick with the "Host" header line, which lets multiple logical HTTP services share one IP address. Again, that works fine for a single-vendor solution. But if a user wants to run several web servers on one machine (say an image server, a database program, an HTTP email access gateway, and a conventional HTTP server), they can't all listen on TCP port 80, the traditional HTTP port. Main character energy is not available to all of them 😤

Here's another problem with well-known ports: 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 sounds like a ton of port numbers, with how fast software is being developed right now, if every new protocol gets its own private port number, we will eventually run out. To avoid application-level demultiplexing, protocols like the X Window System smartly 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 took its own chunk of 64 ports, we would run out even faster 😭

So any NBP replacement needs to provide more than just the network number, subnet number, and host number within that subnet (i.e., the IP address). It also needs to provide the port number within that host where the service is located. And since lots of existing IP services, like lpr, do already use extra application-layer demultiplexing information such as a print queue name, an NBP replacement needs to support that too, by including this information as part of the complete package of addressing information given to the client so it can use the service ✨ Print queues need to be named as first-class entities in their own right. It isn't enough to just name a print server and then expect the separate print queues to be found some other way 🙅‍♀️

One possible answer is that an IP-based NBP replacement could use something derived from DNS SRV records instead of "A" records, since SRV records do provide a port number. However, that alone isn't a complete solution, because SRV records can't tell you an lpr print queue name 💔

3.4. Typed Name Space 🎀

AppleTalk NBP names are structured names, generally written like this:

Name : Type @ Zone

Name: The Name is the user-visible name of the service. This is the part people actually see and pick ✨

Type: The Type is an opaque identifier that identifies the service protocol and semantics. As an end user, you might think of the Type as the function the device performs (e.g., "printing"), and for most people that's a perfectly fine 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 usually built from descriptive ASCII text, but that text has no meaning to the protocol, so be careful about reading too much into 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, and the service doesn't even have to be a printer 😂 A device that archives documents to digital media could advertise itself as a "LaserWriter", meaning it speaks PostScript over PAP, not that it prints the document on paper when it gets it. The end-user never directly sees the Service Type. It's implicit in what the user is doing. For example, when printing, the printing software already knows which protocol(s) it speaks and therefore which Service Type(s) it should look for, so the user doesn't have to tell it anything 🫶

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's 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 lets names be grouped into organizational or geographical "zones", and within each "zone", provides an independent name space for each service type 🌈

3.5. User-Friendly Names 🍓

When you're repeatedly typing names on command-line systems, it helps to have names that are short, all lowercase, and free of spaces or hard-to-type characters 💻

But service names are meant to be picked from a list, not typed over and over, so there's no real reason to restrict them like that 🙌 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 service using only lowercase letters and no spaces if they want to, but they shouldn't 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. Zones get the same glow-up 🥰

Note also that although the characters ':' and '@' are used when writing AppleTalk NBP names, they're just a notational convenience in written text. On the wire 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 talk peer-to-peer using multicast. On a large managed network, AppleTalk routers automatically perform an aggregation function, which allows name lookups to be done via unicast to a service running on the router, instead of flooding the entire network with multicast packets to every host. Smart, right? 🥹

Any NBP replacement needs to be able to operate in the absence of external network infrastructure. However, that shouldn't be the only mode of operation. In larger managed networks, it should also be possible to take advantage of appropriate external network infrastructure when it's present, so queries can go via unicast instead of multicast 💜

3.7. Name Space Management -- or -- Name Conflict Detection ✨

okay so an NBP replacement has to work in a Zeroconf environment, which means nobody can assume there's a central network admin running the show 🙈 In managed networks, normal admin controls might apply, but in the Zeroconf case the replacement has to make it easy for users to name their devices however they want. No asking permission, no paying a domain name registry for the privilege 💅 The catch is that this freedom to pick any name can cause name conflicts. Two users might both set up a personal file server on their laptops and (unimaginatively) call it My Computer. Then when they both show up at the next IETF meeting and land on the same wireless network? Chaos 😭

Same energy with printers. Every Brother network printer may ship from the factory with its Service Name set to Brother Printer. On a typical small home network with one printer, no biggie. But if two or more of them are on the same network, it becomes a problem 🙃

So any NBP replacement needs to detect these conflicts and handle them appropriately. For a laptop, which has a keyboard, a screen, and a human user, the software should display a message telling the user they need to pick a new name 🎀

For printers, which usually have no keyboard or screen, the software should automatically select a new unique name, maybe by tacking an integer onto the end of the existing one, like Brother Printer 2. Here's the iykyk part: even though this auto-generated name should be recorded persistently so it's used next time the device powers on, the user isn't stuck with it forever 🦋 In a network with more than one printer, the typical user will rename them to human-meaningful names like "Upstairs Printer" and "Downstairs Printer". The thing is, renaming the printer through some configuration tool (like a web browser) depends on being able to find the printer and connect to it in the first place. So the programmatically derived unique name is doing a vital bootstrapping job, even if it's only temporary 🧚

Also, connectivity on small portable devices is super transient (especially on wireless networks), so conflict detection has to be an ongoing process 🌸 It's not enough to check that names are unique for a few seconds during boot and then just assume they'll stay unique forever. Not how this works, bestie.

If the Zeroconf naming mechanism gets integrated with the existing global DNS naming mechanism, it would be super beneficial for a sub-tree of that global namespace to be designated as having only local significance. Cooperating peers could use it for free, kind of like how portions of the IPv4 address space are already set aside as local-significance-only, so organizations can use them locally however they like without paying [RFC1918] 💜

3.8. Late Binding 🦋

When the user picks their default printer, the software should store only the name, not the IP address and port number. Then every time they print, the software looks up the name to find the current IP address and port number for that service. This means a named logical service can be moved from one piece of hardware to another without messing up the user's ability to print to it. Main character energy 👑

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. Delaying the binding of name to address until the moment of actual use means the client grabs the correct IP address right when the service is needed ✨

Same deal with ports. A service using a dynamic port number instead of a fixed well-known port might not get the same port number every time it starts or restarts. By delaying the binding of name to port number until actual use, the client gets the correct port number at that exact moment 🫶

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. Budget printers deserve love too 💖

3.10. Network Browsing 🔥

AppleTalk NBP has some limited wild-card functionality. For example, the service name = means "any name". So a client can do an NBP lookup like =:LaserWriter@My Zone and get back a list of all the PS/PAP (AppleTalk Printer Access Protocol) printers in the Zone called My Zone. Iconic 🙌

Any NBP replacement needs to let a piece of software, like a printing client or a file server client, enumerate all the named instances of services in a specified zone (domain) that speak its protocol(s). Browsing should be easy, not a treasure hunt 🌈

3.11. Browsing and Registration Guidance 🧚‍♀️

AppleTalk NBP gives the client some meta-information. On a network with multiple AppleTalk Zones, the AppleTalk network infrastructure tells the client which Zones are available for browsing. It also tells the client the default Zone, which is the client's logical "home" location. That's the Zone selected by default when the Macintosh Chooser opens. It's usually where the user is most likely to find nearby stuff like printers, but they're still free to browse any Zone on the offered list 💅

Now, a Brother printer might be pre-configured at the factory with the Service Name Brother Printer, but the factory has no idea which network it'll end up on. So the printer has to learn this from the network when it arrives 🎁 On a network with multiple AppleTalk Zones, the infrastructure tells the client a single default Zone where it may register Service Names. For a device with a human user, the infrastructure may also share a list of Zones where the client can register Service Names, and the user can choose any one of those instead of the suggested default 🦋

Any NBP replacement needs to give the client the following information:

  • 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.

Because these domains are meant for service browsing in a graphical user interface, they should be allowed to be full user-friendly rich text, just like the rest of a service name. Expressive names are the whole vibe ✨

3.12. Power Management Support 🌙

Lots of modern network devices can go into a low-power mode, where only a small part of the Ethernet hardware stays powered. The device can be woken up by sending a specially formatted Ethernet frame that its power-management hardware recognizes. A modern service discovery protocol should provide facilities that make this low-power mode work well without sacrificing network functionality, like being able to discover services on sleeping devices and waking a sleeping device up when it's needed 😴➡️⚡

3.13. Protocol Agnostic 💜

Fashions come and go in the computer industry, but a service discovery protocol is one of the foundation pieces everything else rests on. It has to outlive these swings of fashion 👑 A useful service discovery protocol should be agnostic to the protocols used by the higher-layer software it serves. If it requires all the higher-layer software to be written in some brand-new computer language, or requires every higher-layer protocol to adopt a trendy data representation format that's currently in vogue, it's likely to have limited utility once the fashion changes and the 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. Whenever a distributed cache is maintained, a cache coherency protocol is required to control the effects of stale data. So a useful service discovery protocol needs to include cache coherency mechanisms. Nobody wants outdated info serving them up as the tea ☕

3.15. Immediate and Ongoing Information Presentation ⚡

Lots of current discovery mechanisms show an hourglass or a "Please Wait" message for five or ten seconds, and then present a list of results. At that point the list is static and doesn't update when things change around it. To see current info, the user has to click a "Refresh" button over and over, waiting another five to ten seconds each time 😩

Neither limitation is acceptable in a protocol that's meant to replace NBP. When a user starts a browsing operation, the user interface should take at most one second to present the list of results. The list should also update as changes in the environment happen. If a user is waiting for a particular service to show up, they should be able to simply watch until it appears, with no "Refresh" button they have to keep clicking 🙅‍♀️ A protocol to replace AppleTalk NBP must be able to meet these requirements for timeliness of information discovery and liveness of information updating, without placing undue burden on the network. Fast, fresh, and light on the network, or it's not it 🔥

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, people have been asking, "Isn't SLP the IETF replacement for AppleTalk NBP?" 🤔

The Service Location Protocol (SLP) [RFC2608] provides extremely rich and flexible facilities for Requirement 10, "Network Browsing". However, SLP provides none of the service naming, automatic name conflict detection, or efficient name-to-address lookup that make up most of what AppleTalk NBP does. Not quite the same vibe 🙃

SLP returns results as URLs. Without DNS, URLs can't usefully contain DNS names. Getting a list of service URLs like ipp://169.254.17.202/ isn't very informative to the user 😵 A list like ipp://epson-stylus-900n.local./ is slightly less opaque (though still not very user-friendly). But to get even that, 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 also has fine-grained query capabilities, like pruning a long list of printers to show only the ones with blue paper in the top tray. That could be useful on extremely large networks with lots of printers, but it's totally unnecessary for a typical home or small office with only one or two printers. Overkill alert 🚨

In summary, SLP alone fails to meet most of the requirements, and it provides vastly more mechanism than necessary for Requirement 10. Bestie, we need something better 💅

5. IPv6 Considerations 🌐

An IP replacement for the AppleTalk Name Binding Protocol needs to support IPv6 as well as IPv4. Both, always, no exceptions 🫶

6. Security Considerations 🔒

okay bestie, this part is kinda serious 🥺 AppleTalk NBP was built back when nobody was really thinking about security, so it had basically none. ngl that's not it anymore 💀 Any modern replacement for AppleTalk NBP needs security measures that fit the environment it's actually going to run in. Since this doc is a big historical overview of how NBP worked and doesn't specify any new protocols, it's out of scope for it to go deep on possible network environments, which protocols would fit each one, or what security each protocol should have. That's a whole other conversation, babes 🫶

7. Informative References 📚

These are the extra reads that aren't required to understand this doc, but they're super worth bookmarking 🌸

  • [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.

Authors' Addresses 🦋

These are the brains behind the doc, so here's how to reach them 💜

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
📦 where this page comes from