Internet Draft Z. Ness Document: draft-ness-updp-00.txt Individual Expires: 2001 January 2001 Internet Draft - Universal Packet Driver Protocol (UPDP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This Internet Draft describes the Universal Packet Driver Protocol (UPDP). This protocol is intended to provide a standardized method for a device to communicate its interface information. It is a protocol based on extending ICMP [1] within the bounds of the original intention of ICMP. The protocol can be used by any device to send and receive device interface information. Ness 1 1 Universal Packet Driver Protocol January 2001 Overview This protocol was developed to fill a perceived need to standardize device communication of interface information. Using the protocol, a device (such as a printer, disk controller, or robotic arm controller) sends a message containing the packet size it expects, the commands that the device accepts, and a security key. Another device receiving that interface information can begin communicating with the first device immediately with the provided settings, or can respond with a UPDP reply including it's own security key for authentication. The main uses of this protocol are expected to be: a device announcing its availability by sending an unsolicited reply; or a device requesting interface information from another device. An anticipated consequence of this protocol is to eliminate the need to develop separate drivers for compliant devices. Applications can use the information provided in a device reply to interface directly with compliant devices. Conventions used in this document In this document, devices are divided into requestors and responders. A requestor is a device that uses the protocol to query interface information from another device. A responder is a device that uses the protocol to send interface information. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Ness Internet Draft - Expires July 2001 2 Universal Packet Driver Protocol January 2001 Message Formats UPDP is an extension of ICMP. ICMP messages are sent using the basic IP header. The first octet of the data portion of the datagram is a ICMP type field; the value of this field determines the format of the remaining data. Any field labeled "unused" is reserved for later extensions and must be zero when sent, but receivers should not use these fields (except to include them in the checksum). Unless otherwise noted under the individual format descriptions, the values of the internet header fields are as follows: Version 4 IHL Internet header length in 32-bit words. Type of Service 0 Total Length Length of internet header and data in octets. Identification, Flags, Fragment Offset Used in fragmentation, see [2]. Time to Live Time to live in seconds; as this field is decremented at each machine in which the datagram is processed, the value in this field should be at least as great as the number of gateways which this datagram will traverse. Protocol ICMP = 1 Header Checksum The 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future. Source Address Ness Internet Draft - Expires July 2001 3 Universal Packet Driver Protocol January 2001 The address of the device that composes the ICMP message. Unless otherwise noted, this can be any of a device's addresses. Destination Address The address of the device to which the message should be sent. UPDP Message - An Extension of the Information Request or Information Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Key continued ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Addresses The address of the source in an information request message will be the destination of the information reply message. To form an information reply message, the source and destination addresses are simply reversed, the type changed to 16, the code toggled, and the checksum recomputed. IP Fields: Type 15 for information request message. 16 for information reply message. Code 1 for Universal Packet Driver message. Checksum Ness Internet Draft - Expires July 2001 4 Universal Packet Driver Protocol January 2001 The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum , the checksum field should be zero. This checksum may be replaced in the future. Identifier If code = 1, identifier contains packet size, maybe zero (packet size setting ignored if zero). Sequence Number If code = 1, a sequence number contains the expected number of commands, maybe zero (packet size setting ignored if zero). Command N If code = 1, command n contains the nth command name that the device will accept. Each command is restricted to the 32 bit command n field size. There may be no commands if Sequence Number is zero. Security Key If code = 1, a security key to be used for security, may be zero. The key can be any length, starting after the (N+2)*32 bit into the datagram. Requestor and responder will need to know the expected security key length. Description Two scenarios apply to this message. The Requestor may send a type 15, request, message. If a device accepts that message, it may reply (possibly using the security key to verify access) with a type 16 message, reply, containing the necessary interface information. The Responder may send a type 16 message, reply, without a request. If a Requestor receives the message, it may begin communicating using the interface specified in the message. The requestor also may reply with a type 15, request, message for the purposes of authentication via the security key. These messages may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). The replying IP module should send the reply with the addresses fully specified. This message is a way for a Requestor to find available devices, or for a Responder to announce availability of the device. Ness Internet Draft - Expires July 2001 5 Universal Packet Driver Protocol January 2001 Known problems/issues Should more fields be added to handle a more detailed interface, such as port number? Is there any broadcast storm potential with this protocol? Should a standard list of commands be maintained, or should it be up to a device manufacturer to determine what the device command names are (as long as they are within 32 bits in size), and to provide corresponding command usage details? Security Considerations This protocol does not define any secure communications method. The variable length security key allows the specific security methods (applied to communication through specified interface) to be defined by the devices involved. Once security keys are exchanged, they may provide the basis of secure communications between devices. Ness Internet Draft - Expires July 2001 6 Universal Packet Driver Protocol January 2001 References [1] Postel, J. (ed.), " INTERNET CONTROL MESSAGE PROTOCOL - DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981. [2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981. Author's Addresses Zoltan Ness 125 23rd Ave. Phone: 1-206-200-4800 Seattle, Wa. USA Email: zness@usa.net Ness Internet Draft - Expires July 2001 7