Stuart Cheshire and Mary Baker, "Consistent Overhead Byte Stuffing."
IEEE/ACM Transactions on Networking, April 1999
This is an improved version of the SIGCOMM paper; it is a little longer, but the descriptions are a little easier to understand, and it also includes HDLC in the experiments comparing COBS to other stuffing methods.
Stuart Cheshire, "Latency and the Quest for Interactivity".
White paper commissioned by Volpe Welty Asset Management, L.L.C., for
the Synchronous Person-to-Person Interactive Computing Environments
Meeting, San Francisco, November 1996.
Mary G. Baker, Xinhua Zhao, Stuart Cheshire and Jonathan Stone,
"Supporting Mobility in MosquitoNet" Proceedings of the 1996
USENIX Technical Conference, January 1996.
Stuart Cheshire and Mary Baker, "Experiences with a Wireless Network
in MosquitoNet." Proceedings of the IEEE Hot Interconnects Symposium
'95, August 1995. Also republished in IEEE Micro, February 1996.
Abstract: The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
RFC 6886 NAT Port Mapping Protocol (NAT-PMP), April 2013
Category: Informational
Abstract: This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.
RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers, February 2013
Category: Standards Track
Abstract: This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.
RFC 6763 DNS-Based Service Discovery, February 2013
Category: Standards Track
Abstract: This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
Abstract: As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
Abstract: This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.
RFC 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP), February 2013
Category: Informational
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.
RFC 6709 Design Considerations for Protocol Extensions, September 2012
Category: Informational
Abstract: This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.
RFC 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry, August 2011
Category: Best Current Practice
Abstract: This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered.
RFC 6281 Understanding Apple's Back to My Mac (BTMM) Service, June 2011
Category: Informational
Abstract: This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices.
RFC 6055 IAB Thoughts on Encodings for Internationalized Domain Names, February 2011
Category: Informational
Abstract: This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.
RFC 5505 Principles of Internet Host Configuration, May 2009
Category: Informational
Abstract: This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.
RFC 5227 IPv4 Address Conflict Detection, July 2008
Category: Standards Track
Abstract: When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem.
This 2008 document is the foundation for the 2005 document RFC 3927, IPv4 Link-Local Addressing. IPv4LL can be viewed as a combination of two simple technologies: a random number generator to pick addresses, coupled with IPv4ACD to tell when it has picked a bad one. However, IETF politics was such that the idea of detecting address conflicts was very contentious, so the more complicated document (random number generator + ACD) was published first, and then the simpler document (ACD alone) was published three years later. If they'd been published in the other order, the IPv4LL document would have been much shorter, because it would have simply referenced RFC 5227 for how to detect address conflicts, instead of duplicating the text.
RFC 4436 Detecting Network Attachment in IPv4 (DNAv4), March 2006
Category: Standards Track
Abstract: The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.
RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses, May 2005
Category: Standards Track
Abstract: To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
RFC 3442 DHCPv4 Classless Static Route Option, November 2002
Category: Standards Track
Abstract: This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless — each routing table entry includes a subnet mask.
RFC 3397 DHCPv4 Domain Search Option, November 2002
Category: Standards Track
Abstract: This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames using DNS.
RFC 3396 Encoding Long Options in DHCPv4, December 2002
Category: Standards Track
Abstract: This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.
iChatAutoLocationStatus sets your iChat status automatically, according to your network connectivity, which it uses as an indicator of your physical location.
A local loop-back AppleTalk adev, so that you can keep AppleTalk
active without draining the battery power on your PowerBook, and without
tying up the serial port that you wanted to connect your modem to.
This is not my work, but it's listed here because it uses the
STRIP protocol (and because it's really cool). RadioScope is a
software-controlled digital oscilloscope designed by
Elliot Poger.
For its interface to the outside world the RadioScope uses a Metricom
radio in its "Starmode" packet datagram mode. RadioScope implements
the STRIP protocol, and a functional subset of UDP and IP, all in 1800
bytes of Motorola 68HC11 8-bit microcontroller code. A huge testament,
I think, to the elegance of datagram protocols. If the RadioScope had
used a connection-oriented device like a Hayes modem for its interface
to the outside world it would have taken a lot more than 1800 bytes of
code to make it work — having to do dial-up/hang-up,
connect/disconnect/reconnect, modem initialization strings, etc.,
etc., etc. Using connectionless UDP datagram packets not only allows
anyone anywhere on the Internet to communicate with the RadioScope
without having to first "dial" its "modem"; it also allows any number
of people to be communicating with the RadioScope at the same time,
because you're not limited to only having one person at a time be
"connected" to it. All in all, a great piece of work. Check it out!
The world is crying out for easier-to-use IP, especially for
small-office and home networks. NBP/IP would bring some of AppleTalk's
legendary ease of use to IP, allowing IP to be used across the room as
well as across the world.
Humans may be unpredictable, but application software often isn't.
Why make the OS guess when the next disk access is going to happen,
when a simple API could allow applications to tell it?
Bishop Vesey's Grammar School is 500 years old, and when I was
there in the 1980s, it had no computer science program whatsoever,
I think because they assumed that computers would be merely a passing
fad. This may not have been a bad thing, because my enthusiasm for the
field was not crushed in boring classes. (I expect Bishop Vesey's does
teach computer science these days.) To track down old friends, take
a look at the
registry of old Veseyans.
In 1998, between finishing my PhD and starting work full-time at Apple, I built a deck.
Several friends were interested to see my progress, so each day I took some
photos with my QuickTake 200
digital camera so you can see my progress. On the subject of the
QuickTake 200 camera, I found an absolutely excellent source of
information at the
QuickTake
200/Fuji DS-7 Users' Page.
Used to be <something>@cs.stanford.edu; had to remove email address because of spam.
Sadly I do not have time to check my old cs.stanford.edu address
very often, so that is no longer a good way to reach me. Guessing my
new email address is left as an exercise for the reader :-)
(November 2005)
(July 1995)