rfc3540.txt

Network Working Group                                          N. Spring
Request for Comments: 3540                                  D. Wetherall
Category: Experimental                                            D. Ely
                                                University of Washington
                                                               June 2003


             Robust Explicit Congestion Notification (ECN)
                         Signaling with Nonces

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This note describes the Explicit Congestion Notification (ECN)-nonce,
   an optional addition to ECN that protects against accidental or
   malicious concealment of marked packets from the TCP sender.  It
   improves the robustness of congestion control by preventing receivers
   from exploiting ECN to gain an unfair share of network bandwidth.
   The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in
   the ECN field of the IP header, and requires a flag in the TCP
   header.  It is computationally efficient for both routers and hosts.

1.  Introduction

   Statement of Intent

      This specification describes an optional addition to Explicit
      Congestion Notification [RFC3168] improving its robustness against
      malicious or accidental concealment of marked packets.  It has not
      been deployed widely.  One goal of publication as an Experimental
      RFC is to be prudent, and encourage use and deployment prior to
      publication in the standards track.  Another consideration is to
      give time for firewall developers to recognize and accept the
      pattern presented by the nonce.  It is the intent of the Transport
      Area Working Group to re-submit this specification as an IETF
      Proposed Standard in the future after more experience has been
      gained.




Spring, et. al.               Experimental                      [Page 1]

RFC 3540                  Robust ECN Signaling                 June 2003


   The correct operation of ECN requires the cooperation of the receiver
   to return Congestion Experienced signals to the sender, but the
   protocol lacks a mechanism to enforce this cooperation.  This raises
   the possibility that an unscrupulous or poorly implemented receiver
   could always clear ECN-Echo and simply not return congestion signals
   to the sender.  This would give the receiver a performance advantage
   at the expense of competing connections that behave properly.  More
   generally, any device along the path (NAT box, firewall, QOS
   bandwidth shapers, and so forth) could remove congestion marks with
   impunity.

   The above behaviors may or may not constitute a threat to the
   operation of congestion control in the Internet.  However, given the
   central role of congestion control, it is prudent to design the ECN
   signaling loop to be robust against as many threats as possible.  In
   this way, ECN can provide a clear incentive for improvement over the
   prior state-of-the-art without potential incentives for abuse.  The
   ECN-nonce is a simple, efficient mechanism to eliminate the potential
   abuse of ECN.

   The ECN-nonce enables the sender to verify the correct behavior of
   the ECN receiver and that there is no other interference that
   conceals marked (or dropped) packets in the signaling path.  The ECN-
   nonce protects against both implementation errors and deliberate
   abuse.  The ECN-nonce:

   -  catches a misbehaving receiver with a high probability, and never
      implicates an innocent receiver.

   -  does not change other aspects of ECN, nor does it reduce the
      benefits of ECN for behaving receivers.

   -  is cheap in both per-packet overhead (one TCP header flag) and
      processing requirements.

   -  is simple and, to the best of our knowledge, not prone to other
      attacks.

   We also note that use of the ECN-nonce has two additional benefits,
   even when only drop-tail routers are used.  First, packet drops
   cannot be concealed from the sender.  Second, it prevents optimistic
   acknowledgements [Savage], in which TCP segments are acknowledged
   before they have been received.  These benefits also serve to
   increase the robustness of congestion control from attacks.  We do
   not elaborate on these benefits in this document.

   The rest of this document describes the ECN-nonce.  We present an
   overview followed by detailed behavior at senders and receivers.



Spring, et. al.               Experimental                      [Page 2]

RFC 3540                  Robust ECN Signaling                 June 2003


   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Overview

   The ECN-nonce builds on the existing ECN-Echo and Congestion Window
   Reduced (CWR) signaling mechanism.  Familiarity with ECN [ECN] is
   assumed.  For simplicity, we describe the ECN-nonce in one direction
   only, though it is run in both directions in parallel.

   The ECN protocol for TCP remains unchanged, except for the definition
   of a new field in the TCP header.  As in [RFC3168], ECT(0) or ECT(1)
   (ECN-Capable Transport) is set in the ECN field of the IP header on
   outgoing packets.  Congested routers change this field to CE
   (Congestion Experienced).  When TCP receivers notice CE, the ECE
   (ECN-Echo) flag is set in subsequent acknowledgements until receiving
   a CWR flag.  The CWR flag is sent on new data whenever the sender
   reacts to congestion.

   The ECN-nonce adds to this protocol, and enables the receiver to
   demonstrate to the sender that segments being acknowledged were
   received unmarked.  A random one-bit value (a nonce) is encoded in
   the two ECT codepoints.  The one-bit sum of these nonces is returned
   in a TCP header flag, the nonce sum (NS) bit.  Packet marking erases
   the nonce value in the ECT codepoints because CE overwrites both ECN
   IP header bits.  Since each nonce is required to calculate the sum,
   the correct nonce sum implies receipt of only unmarked packets.  Not
   only are receivers prevented from concealing marked packets, middle-
   boxes along the network path cannot unmark a packet without
   successfully guessing the value of the original nonce.

   The sender can verify the nonce sum returned by the receiver to
   ensure that congestion indications in the form of marked (or dropped)
   packets are not being concealed.  Because the nonce sum is only one
   bit long, senders have a 50-50 chance of catching a lying receiver
   whenever an acknowledgement conceals a mark.  Because each
   acknowledgement is an independent trial, cheaters will be caught
   quickly if there are repeated congestion signals.

   The following paragraphs describe aspects of the ECN-nonce protocol
   in greater detail.









Spring, et. al.               Experimental                      [Page 3]

RFC 3540                  Robust ECN Signaling                 June 2003


   Each acknowledgement carries a nonce sum, which is the one bit sum
   (exclusive-or, or parity) of nonces over the byte range represented
   by the acknowledgement.  The sum is used because not every packet is
   acknowledged individually, nor are packets acknowledged reliably.  If
   a sum were not used, the nonce in an unmarked packet could be echoed
   to prove to the sender that the individual packet arrived unmarked.
   However, since these acks are not reliably delivered, the sender
   could not distinguish a lost ACK from one that was never sent in
   order to conceal a marked packet.  The nonce sum prevents the
   receiver from concealing individual marked packets by not
   acknowledging them.  Because the nonce and nonce sum are both one bit
   quantities, the sum is no easier to guess than the individual nonces.
   We show the nonce sum calculation below in Figure 1.

    Sender             Receiver
                         initial sum = 1
      -- 1:4 ECT(0)  --> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1 ---
      -- 4:8 ECT(1)  --> NS = 1(:4) + 1(4:8) = 0(:8)
      <- ACK 8, NS=0 ---
      -- 8:12 ECT(1)  -> NS = 0(:8) + 1(8:12) = 1(:12)
      <- ACK 12, NS=1 --
      -- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
      <- ACK 16, NS=0 --

   Figure 1: The calculation of nonce sums at the receiver.

   After congestion has occurred and packets have been marked or lost,
   resynchronization of the sender and receiver nonce sums is needed.
   When packets are marked, the nonce is cleared, and the sum of the
   nonces at the receiver will no longer match the sum at the sender.
   Once nonces have been lost, the difference between sender and
   receiver nonce sums is constant until there is further loss.  This
   means that it is possible to resynchronize the sender and receiver
   after congestion by having the sender set its nonce sum to that of
   the receiver.  Because congestion indications do not need to be
   conveyed more frequently than once per round trip, the sender
   suspends checking while the CWR signal is being delivered and resets
   its nonce sum to the receiver's when new data is acknowledged.  This
   has the benefit that the receiver is not explicitly involved in the
   re-synchronization process.  The resynchronization process is shown
   in Figure 2 below.  Note that the nonce sum returned in ACK 12 (NS=0)
   differs from that in the previous example (NS=1), and it continues to
   differ for ACK 16.







Spring, et. al.               Experimental                      [Page 4]

RFC 3540                  Robust ECN Signaling                 June 2003


    Sender              Receiver
                            initial sum = 1
      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1      --
      -- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8)
      <- ACK 8, ECE NS=1  --
      -- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12)
      <- ACK 12, NS=0     --
      -- 12:16 ECT(1)     -> NS = 0(:12) + 1(12:16) = 1(:16)
      <- ACK 16, NS=1     --

   Figure 2: The calculation of nonce sums at the receiver when a
      packet (4:8) is marked.  The receiver may calculate the wrong
      nonce sum when the original nonce information is lost after a
      packet is marked.

   Third, we need to reconcile that nonces are sent with packets but
   acknowledgements cover byte ranges.  Acknowledged byte boundaries
   need not match the transmitted boundaries, and information can be
   retransmitted in packets with different byte boundaries.  We discuss
   the first issue, how a receiver sets a nonce when acknowledging part
   of a segment, in Section 6.1. The second question, what nonce to send
   when retransmitting smaller segments as a large segment, has a simple
   answer: ECN is disabled for retransmissions, so can carry no nonce.
   Because retransmissions are associated with congestion events, nonce
   checking is suspended until after CWR is acknowledged and the
   congestion event is over.

   The next sections describe the detailed behavior of senders, routers
   and receivers, starting with sender transmit behavior, then around
   the ECN signaling loop, and finish with sender acknowledgement
   processing.

3.  Sender Behavior (Transmit)

   Senders manage CWR and ECN-Echo as before.  In addition, they must
   place nonces on packets as they are transmitted and check the
   validity of the nonce sums in acknowledgments as they are received.
   This section describes the transmit process.

   To place a one bit nonce value on every ECN-capable IP packet, the
   sender uses the two ECT codepoints: ECT(0) represents a nonce of 0,
   and ECT(1) a nonce of 1.  As in ECN, retransmissions are not ECN-
   capable, so carry no nonce.

   The sender maintains a mapping from each packet's end sequence number
   to the expected nonce sum (not the nonce placed in the original
   transmission) in the acknowledgement bearing that sequence number.



Spring, et. al.               Experimental                      [Page 5]

RFC 3540                  Robust ECN Signaling                 June 2003


4.  Router Behavior

   Routers behave as specified in [RFC3168].  By marking packets to
   signal congestion, the original value of the nonce, in ECT(0) or
   ECT(1), is removed.  Neither the receiver nor any other party can
   unmark the packet without successfully guessing the value of the
   original nonce.

5.  Receiver Behavior (Receive and Transmit)

   ECN-nonce receivers maintain the nonce sum as in-order packets arrive
   and return the current nonce sum in each acknowledgement.  Receiver
   behavior is otherwise unchanged from [RFC3168].  Returning the nonce
   sum is optional, but recommended, as senders are allowed to
   discontinue sending ECN-capable packets to receivers that do not
   support the ECN-nonce.

   As packets are removed from the queue of out-of-order packets to be
   acknowledged, the nonce is recovered from the IP header.  The nonce
   is added to the current nonce sum as the acknowledgement sequence
   number is advanced for the recent packet.

   In the case of marked packets, one or more nonce values may be
   unknown to the receiver.  In this case the missing nonce values are
   ignored when calculating the sum (or equivalently a value of zero is
   assumed) and ECN-Echo will be set to signal congestion to the sender.

   Returning the nonce sum corresponding to a given acknowledgement is
   straightforward.  It is carried in a single "NS" (Nonce Sum) bit in
   the TCP header.  This bit is adjacent to the CWR and ECN-Echo bits,
   set as Bit 7 in byte 13 of the TCP header, as shown below:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 3: The new definition of bytes 13 and 14 of the TCP Header.

   The initial nonce sum is 1, and is included in the SYN/ACK and ACK of
   the three way TCP handshake.  This allows the other endpoint to infer
   nonce support, but is not a negotiation, in that the receiver of the
   SYN/ACK need not check if NS is set to decide whether to set NS in
   the subsequent ACK.





Spring, et. al.               Experimental                      [Page 6]

RFC 3540                  Robust ECN Signaling                 June 2003


6.  Sender Behavior (Receive)

   This section completes the description of sender behavior by
   describing how senders check the validity of the nonce sums.

   The nonce sum is checked when an acknowledgement of new data is
   received, except during congestion recovery when additional ECN-Echo
   signals would be ignored.  Checking consists of comparing the correct
   nonce sum stored in a buffer to that carried in the acknowledgement,
   with a correction described in the following subsection.

   If ECN-Echo is not set, the receiver claims to have received no
   marked packets, and can therefore compute and return the correct
   nonce sum.  To conceal a mark, the receiver must successfully guess
   the sum of the nonces that it did not receive, because at least one
   packet was marked and the corresponding nonce was erased.  Provided
   the individual nonces are equally likely to be 0 or 1, their sum is
   equally likely to be 0 or 1.  In other words, any guess is equally
   likely to be wrong and has a 50-50 chance of being caught by the
   sender.  Because each new acknowledgement is an independent trial, a
   cheating receiver is likely to be caught after a small number of
   lies.

   If ECN-Echo is set, the receiver is sending a congestion signal and
   it is not necessary to check the nonce sum.  The congestion window
   will be halved, CWR will be set on the next packet with new data
   sent, and ECN-Echo will be cleared once the CWR signal is received,
   as in [RFC3168].  During this recovery process, the sum may be
   incorrect because one or more nonces were not received.  This does
   not matter during recovery, because TCP invokes congestion mechanisms
   at most once per RTT, whether there are one or more losses during
   that period.

6.1.  Resynchronization After Loss or Mark

   After recovery, it is necessary to re-synchronize the sender and
   receiver nonce sums so that further acknowledgments can be checked.
   When the receiver's sum is incorrect, it will remain incorrect until
   further loss.

   This leads to a simple re-synchronization mechanism where the sender
   resets its nonce sum to that of the receiver when it receives an
   acknowledgment for new data sent after the congestion window was
   reduced.  When responding to explicit congestion signals, this will
   be the first acknowledgement without the ECN-Echo flag set: the
   acknowledgement of the packet containing the CWR flag.





Spring, et. al.               Experimental                      [Page 7]

RFC 3540                  Robust ECN Signaling                 June 2003


    Sender              Receiver
                             initial sum = 1
      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1      --
      -- 4:8 ECT(1) -> LOST
      -- 8:12 ECT(1)      -> nonce sum calculation deferred
                               until in-order data received
      <- ACK 4, NS=0      --
      -- 12:16 ECT(1)     -> nonce sum calculation deferred
      <- ACK 4, NS=0      --
      -- 4:8 retransmit   -> NS = 1(:4) + ?(4:8) +
                                  1(8:12) + 1(12:16) = 1(:16)
      <- ACK 16, NS=1     --
      -- 16:20 ECT(1) CWR ->
      <- ACK 20, NS=0     -- NS = 1(:16) + 1(16:20) = 0(:20)

   Figure 4: The calculation of nonce sums at the receiver when a
      packet is lost, and resynchronization after loss.  The nonce sum
      is not changed until the cumulative acknowledgement is advanced.

   In practice, resynchronization can be accomplished by storing a bit
   that has the value one if the expected nonce sum stored by the sender
   and the received nonce sum in the acknowledgement of CWR differ, and
   zero otherwise.  This synchronization offset bit can then be used in
   the comparison between expected nonce sum and received nonce sum.

   The sender should ignore the nonce sum returned on any
   acknowledgements bearing the ECN-echo flag.

   When an acknowledgment covers only a portion of a segment, such as
   when a middlebox resegments at the TCP layer instead of fragmenting
   IP packets, the sender should accept the nonce sum expected at the
   next segment boundary.  In other words, an acknowledgement covering
   part of an original segment will include the nonce sum expected when
   the entire segment is acknowledged.

   Finally, in ECN, senders can choose not to indicate ECN capability on
   some packets for any reason.  An ECN-nonce sender must resynchronize
   after sending such ECN-incapable packets, as though a CWR had been
   sent with the first new data after the ECN-incapable packets.  The
   sender loses protection for any unacknowledged packets until
   resynchronization occurs.









Spring, et. al.               Experimental                      [Page 8]

RFC 3540                  Robust ECN Signaling                 June 2003


6.2.  Sender Behavior - Incorrect Nonce Received

   The sender's response to an incorrect nonce is a matter of policy.
   It is separate from the checking mechanism and does not need to be
   handled uniformly by senders.  Further, checking received nonce sums
   at all is optional, and may be disabled.

   If the receiver has never sent a non-zero nonce sum, the sender can
   infer that the receiver does not understand the nonce, and rate limit
   the connection, place it in a lower-priority queue, or cease setting
   ECT in outgoing segments.

   If the received nonce sum has been set in a previous acknowledgement,
   the sender might infer that a network device has interfered with
   correct ECN signaling between ECN-nonce supporting endpoints.  The
   minimum response to an incorrect nonce is the same as the response to
   a received ECE.  However, to compensate for hidden congestion
   signals, the sender might reduce the congestion window to one segment
   and cease setting ECT in outgoing segments.  An incorrect nonce sum
   is a sign of misbehavior or error between ECN-nonce supporting
   endpoints.

6.2.1.  Using the ECN-nonce to Protect Against Other Misbehaviors

   The ECN-nonce can provide robustness beyond checking that marked
   packets are signaled to the sender.  It also ensures that dropped
   packets cannot be concealed from the sender (because their nonces
   have been lost).  Drops could potentially be concealed by a faulty
   TCP implementation, certain attacks, or even a hypothetical TCP
   accelerator.  Such an accelerator could gamble that it can either
   successfully "fast start" to a preset bandwidth quickly, retry with
   another connection, or provide reliability at the application level.
   If robustness against these faults is also desired, then the ECN-
   nonce should not be disabled.  Instead, reducing the congestion
   window to one, or using a low-priority queue, would penalize faulty
   operation while providing continued checking.

   The ECN-nonce can also detect misbehavior in Eifel [Eifel], a
   recently proposed mechanism for removing the retransmission ambiguity
   to improve TCP performance.  A misbehaving receiver might claim to
   have received only original transmissions to convince the sender to
   undo congestion actions.  Since retransmissions are sent without ECT,
   and thus no nonce, returning the correct nonce sum confirms that only
   original transmissions were received.







Spring, et. al.               Experimental                      [Page 9]

RFC 3540                  Robust ECN Signaling                 June 2003


7.  Interactions

7.1.  Path MTU Discovery

   As described in RFC3168, use of the Don't Fragment bit with ECN is
   recommended.  Receivers that receive unmarked fragments can
   reconstruct the original nonce to conceal a marked fragment.  The
   ECN-nonce cannot protect against misbehaving receivers that conceal
   marked fragments, so some protection is lost in situations where Path
   MTU discovery is disabled.

   When responding to a small path MTU, the sender will retransmit a
   smaller frame in place of a larger one.  Since these smaller packets
   are retransmissions, they will be ECN-incapable and bear no nonce.
   The sender should resynchronize on the first newly transmitted
   packet.

7.2.  SACK

   Selective acknowledgements allow receivers to acknowledge out of
   order segments as an optimization.  It is not necessary to modify the
   selective acknowledgment option to fit per-range nonce sums, because
   SACKs cannot be used by a receiver to hide a congestion signal.  The
   nonce sum corresponds only to the data acknowledged by the cumulative
   acknowledgement.

7.3.  IPv6

   Although the IPv4 header is protected by a checksum, this is not the
   case with IPv6, making undetected bit errors in the IPv6 header more
   likely.  Bit errors that compromise the integrity of the congestion
   notification fields may cause an incorrect nonce to be received, and
   an incorrect nonce sum to be returned.

8.  Security Considerations

   The random one-bit nonces need not be from a cryptographic-quality
   pseudo-random number generator.  A strong random number generator
   would compromise performance.  Consequently, the sequence of random
   nonces should not be used for any other purpose.

   Conversely, the pseudo-random bit sequence should not be generated by
   a linear feedback shift register [Schneier], or similar scheme that
   would allow an adversary who has seen several previous bits to infer
   the generation function and thus its future output.






Spring, et. al.               Experimental                     [Page 10]

RFC 3540                  Robust ECN Signaling                 June 2003


   Although the ECN-nonce protects against concealment of congestion
   signals and optimistic acknowledgement, it provides no additional
   protection for the integrity of the connection.

9.  IANA Considerations

   The Nonce Sum (NS) is carried in a reserved TCP header bit that must
   be allocated.  This document describes the use of Bit 7, adjacent to
   the other header bits used by ECN.

   The codepoint for the NS flag in the TCP header is specified by the
   Standards Action of this RFC, as is required by RFC 2780.  The IANA
   has added the following to the registry for "TCP Header Flags":

   RFC 3540 defines bit 7 from the Reserved field to be used for the
   Nonce Sum, as follows:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   TCP Header Flags

   Bit      Name                                    Reference
   ---      ----                                    ---------
    7        NS (Nonce Sum)                         [RFC 3540]

10.  Conclusion

   The ECN-nonce is a simple modification to the ECN signaling mechanism
   that improves ECN's robustness by preventing receivers from
   concealing marked (or dropped) packets.  The intent of this work is
   to help improve the robustness of congestion control in the Internet.
   The modification retains the character and simplicity of existing ECN
   signaling.  It is also practical for deployment in the Internet.  It
   uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as
   well as CWR and ECN-Echo) and has simple processing rules.











Spring, et. al.               Experimental                     [Page 11]

RFC 3540                  Robust ECN Signaling                 June 2003


11.  References

   [ECN]      "The ECN Web Page", URL
              "http://www.icir.org/floyd/ecn.html".

   [RFC3168]  Ramakrishnan, K., Floyd, S. and D. Black, "The addition of
              explicit congestion notification (ECN) to IP", RFC 3168,
              September 2001.

   [Eifel]    R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP
              Robust Against Spurious Retransmissions. Computer
              Communications Review, January, 2000.

   [B97]      Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Savage]   S. Savage, N. Cardwell, D. Wetherall, T. Anderson.  TCP
              congestion control with a misbehaving receiver. SIGCOMM
              CCR, October 1999.

   [Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996

12.  Acknowledgements

   This note grew out of research done by Stefan Savage, David Ely,
   David Wetherall, Tom Anderson and Neil Spring.  We are very grateful
   for feedback and assistance from Sally Floyd.

13.  Authors' Addresses

   Neil Spring
   EMail: nspring@cs.washington.edu


   David Wetherall
   Department of Computer Science and Engineering, Box 352350
   University of Washington
   Seattle WA 98195-2350
   EMail: djw@cs.washington.edu


   David Ely
   Computer Science and Engineering, 352350
   University of Washington
   Seattle, WA 98195-2350
   EMail: ely@cs.washington.edu





Spring, et. al.               Experimental                     [Page 12]

RFC 3540                  Robust ECN Signaling                 June 2003


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Spring, et. al.               Experimental                     [Page 13]