Network Working Group A.J. McGregor Internet Draft M.J. Luckie Expiration Date: July 2003 Waikato University February 2003 IP Measurement Protocol (IPMP) 1. 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 This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Abstract The practice and need for active measurement of networks is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. McGregor [Page 1] INTERNET-DRAFT IP Measurement Protocol February 2003 2. Introduction The practice and need for active measurement of networks is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. For example, ICMP is widely used for measurement despite its well known limitations for this task. These limitations include it being treated different to other IP protocols at routers and hosts because it is difficult to efficiently generate appropriate response packets. ICMP has also received bad press from denial of service attacks and because of the number of sites generating monitoring traffic. As a consequence, some ISPs disable ICMP even though this potentially causes poor performance and does not comply with RFC1009 [1]. Current packet probing techniques are not suited to measuring packet delay at the router level. Routers often make bad measurement targets because they are optimised for the relatively simple task of forwarding packets. Routers may process tasks that are resource intensive and therefore an opportunity for a denial of service attack at low priority or not at all. Some measurement techniques construct measurement traffic that can be difficult to efficiently detect and respond to amongst other network traffic. This type of measurement traffic precludes measuring to a router and makes the task of identifying where delay occurs in the network difficult. IPMP addresses these issues by providing a measurement protocol that is tightly constrained, efficient and easy to implement. The protocol has been designed so measurement packets can be processed with about the same level of computation as IP packet forwarding. The protocol operates as an echo protocol allowing packet loss, one-way path length, RTT and in some cases, one-way delay measurements to be taken. The protocol also allows a measurement host to identify individual router units from the interface IP addresses it collects in the echo exchange by exchanging information packets after the measurement has completed. Packets are generated by a measurement host and returned by an echoing router or host, known as an echoing system in this memo. The translation of router time stamps to real time time stamps is supported through a separate information request and reply exchange between the measurement system and systems that insert time stamps into the echo request or reply. McGregor [Page 2] INTERNET-DRAFT IP Measurement Protocol February 2003 2.1 Packet formats 2.1.1 IPMP Echo Request and Echo Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux IP Prot | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Pointer | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Path Record(s) | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version = 0 Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IPMP message starting with the version number. For computing the checksum, the checksum is set to zero. Faux IP Prot, Faux Source Port, Faux Destination Port The faux IP prot, faux source port, and faux destination port mimic the IP protocol field and TCP or UDP source and destination ports (if appropriate). These fields allow an IPMP echo packet to be queued or filtered based on a five-tuple of values when combined with the IP source and destination addresses. Intermediate routers schedule this packet if they implement a packet scheduling discipline that is not FIFO. When the echo packet is received at the target, the faux source and destination ports MUST be swapped to reflect the way that ports are conceptually swapped in a UDP or TCP header at the target. McGregor [Page 3] INTERNET-DRAFT IP Measurement Protocol February 2003 Identifier, Sequence Number The echo request packet should contain enough information to match an echo response packet. The identifier SHOULD be set to the lower 16 bits of the process identifier responsible for sending the packet, and the sequence number SHOULD increment for each echo request packet sent to a unique IP address with a particular identifier value. Firewalls that keep state SHOULD use the Identifier field - combined with the source and destination IP addresses and IP protocol number (not faux IP Prot) - to hash a packet in order to decide which echo packets to pass. Path Pointer The position, in bytes from the beginning of the IPMP packet, of the next available path record location, if there is space. If an intermediary inserts a path record, it MUST increment the path pointer by the size of the path record inserted. Path Records The measurement host MAY pre-allocate space for path records to be inserted. The start and end offsets of the space are given by the IPMP path pointer and IP length fields respectively. The pre-allocated space MUST be initialised to zero. IPMP Options 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Res |S|I|R| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E = echo packet I = information packet (see section 2.1.3) R = request packet = 0 / response packet = 1 S = singleton packet, used for one-way probes, not echoed McGregor [Page 4] INTERNET-DRAFT IP Measurement Protocol February 2003 2.1.2 Path Record format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address of Receiving Interface | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL |U| Reserved | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address of Receiving Interface | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HLIM |U| Reserved | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Address of Receiving Interface The address of interface at which the packet was received by the system that inserted the Path Record into the Echo Request or Echo Reply packet. TTL / HLIM A host or router MAY include the value of the TTL or HLIM field in the packet's IP header after it has been decremented as part of the forwarding process. This allows an end-host to identify gaps in the network where a path record was not inserted. If this field is not inserted by a host or router that does insert a path record it MUST be left at zero. Timestamp A host or router MAY include the time at which the interface completed receiving the packet. If the timestamp is not set in the path record, the value is left as zero. The timestamp is allocated 48 bits, although the host or router can use any number of bits. The timestamp, if included, SHOULD represent the time that the last bit of the packet was received. McGregor [Page 5] INTERNET-DRAFT IP Measurement Protocol February 2003 A host or router MAY specify that the timestamp is recorded relative to UTC by setting the U bit. In this case, the first 16 bits specify seconds elapsed since the last time the seconds field wrapped, and the following 32 bits specify the fraction of the second that has elapsed. This timestamp format has a resolution of 200 picoseconds. The seconds field wraps approximately every 18 hours. To recover the timestamp to seconds since the epoch, the following C code could be used struct ipmp_pathrecord { struct in_addr addr; u_int8_t ttl; u_int8_t opts; u_int16_t sec; u_int32_t fsec; } pr; struct timeval tv; gettimeofday(&tv, &tz); tv.tv_sec = (tv_sec & 0xffff0000) | (ntohs(pr.sec) & 0xffff); The precise relationship between the timestamp and real time, if there is one, must be derived using information from an IPMP Information Reply (see section 4.3). If a timestamp is included by a system, it must be able to process IPMP Information Request Packets at the address included in the Path Record. 2.1.3 IPMP Information Request and Information Reply Information Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux P-Type | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : (optional) Reported Time Of Interest | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McGregor [Page 6] INTERNET-DRAFT IP Measurement Protocol February 2003 Information Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux P-Type | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Performance Data Pointer | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address Identifying Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPMP Processing Overhead | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Real Time Reference Points | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Performance Data | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version, IPMP Options, Checksum, Faux Source Port, Faux Destination Port, Faux P-Type, Identifier, Sequence Number See section 2.1.1 Performance Data Pointer The position, in bytes from the beginning of the IPMP packet, of the performance data field, if it exists. If there is no performance data field, it is set to 0. IP Address Identifying Router In order for a measurement host to identify individual routers on a network, a router must reply to information requests sent to any of its interfaces using a consistent address in this field. The field may contain any address unique to the router. McGregor [Page 7] INTERNET-DRAFT IP Measurement Protocol February 2003 IPMP Processing Overhead The maximum difference between the time taken to process and forward an IPMP packet and the time taken to forward an IP packet with the same characteristics. The echo system may use the values supplied in faux IP Prot, Faux Source Port, and Faux Destination Port if it implements a queueing discipline that is not FIFO. If the overhead is unknown, then the value recorded is MAX_TIME, i.e. all bits to 1. Reported Time of Interest A measurement system MAY request that the end system constrain the real time reference points to cover a particular timestamp that it received. In this case the timestamping system SHOULD return a realtime reference point for just this timestamp or a pair of reference points, one before and one after the timestamp. In other cases the timestamping system MAY return an arbitrary number of reference points bounded by the size of the packet it can send. Realtime Reference Points A realtime reference point (see section 2.1.4) gives the relationship between realtime and the timestamp that would have been placed in a path record by the interface at that time. If any reference points are included, there must be at least two. Within the bounds of the overall size of the packet any number of reference points may be included. Performance Data The Performance Data field allows arbitrary information from the MIB of the system or the interface to optionally be included in the Information Reply. It is formatted as a VarBindList from the SNMPv2-PDU defined in [4]. In this context ObjectSyntax is the only valid choice within VarBind. McGregor [Page 8] INTERNET-DRAFT IP Measurement Protocol February 2003 I.E. IPMP-PERFORMANCE-DATA DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, FROM SNMPv2-SMI; -- IPMP simplified list element IPMPVarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } -- variable-binding list VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF IPMPVarBind END 2.1.4 Realtime Reference Point 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reported Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reported Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Realtime Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Estimated Error | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reported Timestamp A 48-bit timestamp that the host or router used in a path record. Realtime timestamp An NTP formatted timestamp representing the realtime. McGregor [Page 9] INTERNET-DRAFT IP Measurement Protocol February 2003 Estimated Error An NTP formatted timestamp estimating the error bounds of the real time timestamp. 2.2 IP Protocol Header Values Version = 4 IHL = 5 Identification = 0 Flags = DF Fragment offset = 0 IP Protocol type = TO BE ASSIGNED. IP options are forbidden. 3. Processing of IPMP packets 3.1 Measurement host processing A measurement host constructs an IPMP request, encapsulates it in an IP datagram and the appropriate link layer protocol and sends it into the network. Performance information is gleaned from the presence or absence of a reply, the delay between the request and the reply, the value of TTL and the path record(s) if present, and possibly the presence of errors. The measurement host, when constructing the echo request, sets all words from the end of the data field to the end of the echo request (the space allocated for path records) to zero. When an IPMP echo reply arrives, the checksum is recomputed and checked with the checksum present in the IPMP header. McGregor [Page 10] INTERNET-DRAFT IP Measurement Protocol February 2003 3.2 Echoing system processing The IPMP Echo Request and Echo Reply packet formats are designed to make processing at the echoing host simple and efficient. On receipt of the IPMP Echo Request, the echoing system constructs the echo reply from the echo request by: 1. exchanging the IP source and destination addresses 2. exchanging the Faux Source and Destination ports 3. setting the reply bit in the IPMP Options field and incrementally updating the checksum 4. optionally inserting a path record as described in section 3.3.1 5. scheduling the packet for forwarding, taking account of the queue type field if appropriate The echoing system does not: o validate the value of the IPMP checksum present in the header against the contents of the packet o recalculate the IPMP checksum from scratch before transmitting the packet o decrement or otherwise alter the IP header's TTL or recalculate the IP header's checksum o process fragments or IP options Processing IPMP Information Request packets requires more resources than an Echo Request. Direct measurements are not made from Information Request packets. Consequently, an implementer may choose to processes Information Request packets off the interface card and/or at low priority. McGregor [Page 11] INTERNET-DRAFT IP Measurement Protocol February 2003 3.3 Forwarding System Processing A forwarding router does not need to be IPMP aware. In the simplest case, an IPMP packet is forwarded like any other IP packet. If the forwarding system schedules packets based on the value of any combination of the IP protocol field and the TCP or UDP source and destination ports, then the forwarding system MUST use the faux fields in the IPMP header for this purpose instead of the IP, TCP or UDP fields. Note that the Faux Source and Destination port numbers are in the same position in an IPMP packet as they are in a TCP or UDP packet but the Faux IP prot is not. A forwarding router MAY include a path record as described in section 3.3.1. 3.3.1 Path Record Insertion Inclusion of path records is optional. A path record MAY be inserted by forwarding systems on the forward and reverse paths, by the measurement host, and by the echoing system. A forwarding system SHOULD NOT insert a path record if it cannot modify the packet in the same processing stream that any other packet would take. This is to avoid the measurement path being significantly different to that taken by a regular packet, and to reduce opportunities for denial of service (see section 3.4). A system that can insert a path record MUST check for sufficient space in the echo packet based on the size of the path record inserted. An IPv4 path record requires 12 bytes, while the IPv6 path record requires 24 bytes. A system which inserts a path record MUST increase the Path Pointer as appropriate, and MUST also incrementally update the IPMP Checksum field as described in [5]. The length of the packet is not changed. A system that adds a path record MAY include a timestamp in the path record. If it does not include a timestamp, the timestamp field in the path record is left unaltered, i.e. remains zero. McGregor [Page 12] INTERNET-DRAFT IP Measurement Protocol February 2003 3.4 Denial of service attacks Because IPMP echo request packets are processed with about the same effort as forwarding an IP packet they do not introduce any new denial of service opportunities. IPMP Information Request packets require more processing and may be used as the basis of a denial of service attack in the same way as any information request on a router or host. Because Information Request packets are not used to make measurements an implementer may implement protection against denial of service attacks made with these packets in the same way as other information requests. This might involve processing IPMP Information Requests at a low priority or regulating the maximum flow of packets. 4. Discussion 4.1 Checksums The IPMP checksum is calculated by the measurement host when it creates the echo request packet. It is incrementally updated by forwarding systems that insert a path record. The checksum is not checked by a forwarding system or an echoing system. Errors that occur between the measurement host and the echoing system on the forward and reverse paths are detected when the echo reply is received at the measurement host. 4.2 Realtime Timestamps 32 bit realtime timestamp fields are coded following the conventions described in RFC1305 NTP [2]. Summarising from RFC1305: In conformance with standard Internet practice, timestamps are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left, or high-order, position. All quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0. Timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order can be set to 0. McGregor [Page 13] INTERNET-DRAFT IP Measurement Protocol February 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds Fraction (0-padded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format allows convenient multiple-precision arithmetic and conversion to UDP/TIME representation (seconds), but does complicate the conversion to ICMP Timestamp message representation, which is in milliseconds. The most future time that can be represented is 4,294,967 (some time in the year 2036) with a precision of about 200 picoseconds, which should be adequate for even the most demanding measurements. RFC 2030 (SNTP) contains a proposal for extending timestamps beyond the year 2036. 4.3 Inferred Realtime The realtime of a timestamp in a path record can be inferred when a system provides an IPMP Information Reply with at least one Real Time Reference Point earlier and one later than the timestamp. For the purpose of this inference, the clock drift of the is assumed to be linear. Linear interpolation is used between the two nearest Realtime Reference Points, where one is greater than and one is less than the timestamp. The timestamp in the path record structure may be of any format, as discussed in Section 2.1.2, and the timestamp potentially can wrap over the course of a series of measurements. It is the responsibility of the measurement host to send information requests to the timestamping systems sufficiently frequently to avoid information loss. The correct frequency can be estimated from an information reply. 4.4 Minimum Implementations. 4.4.1 Echoing System The simplest echoing system implementation returns the IPMP echo request without a path record. As described in section 3.2, this only requires that the IP source and destination addresses be exchanged, the R bit in the IPMP options field to be set and the packet scheduled for forwarding. Because of the format of the IPMP echo request and echo reply packets this can be implemented with a very small number of instructions. A system that does not insert path records does not need to processes IPMP Information Requests. McGregor [Page 14] INTERNET-DRAFT IP Measurement Protocol February 2003 Systems which just provide this level of implementation allow a number of measurements to be made that are not currently possible, particularly if they are routers that processes ICMP at a low priority to avoid DOS attacks. 4.4.2 Forwarding System Forwarding systems do not need to be IPMP aware. A forwarding system that is IPMP aware MAY include path records with only the Forwarding IP Address set. This requires writing the address to the packet and updating the checksum and Path Pointer in the packet as described in section 3.3.1 and 4.2.1. In this case the forwarding system does not need to process IPMP Information Request packets. 5. References [1] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987. [2] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and analysis", RFC 1305, March 1992. [3] Mills, D. "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [4] Case, J., et al. "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, October 1996. [5] Rijsinghani, A., editor. "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. McGregor [Page 15] INTERNET-DRAFT IP Measurement Protocol February 2003 6. Authors' Address Anthony J. McGregor Department of Computer Science Waikato University Private Bag 3105 Hamilton New Zealand Phone: +64 7 838 4651 EMail: tonym@cs.waikato.ac.nz Matthew J. Luckie Department of Computer Science Waikato University Private Bag 3105 Hamilton New Zealand EMail: mjl@luckie.org.nz Expiration Date: July 2003 McGregor [Page 16]