diff options
Diffstat (limited to 'doc/rfc/rfc3540.txt')
| -rw-r--r-- | doc/rfc/rfc3540.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3540.txt b/doc/rfc/rfc3540.txt new file mode 100644 index 0000000..f781c50 --- /dev/null +++ b/doc/rfc/rfc3540.txt @@ -0,0 +1,731 @@ + + + + + + +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] + |