draft-ietf-tcpm-tcp-soft-errors-06.txt   draft-ietf-tcpm-tcp-soft-errors-07.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Intended status: Informational Intended status: Informational
Expires: December 26, 2007 Expires: June 28, 2008
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-06.txt draft-ietf-tcpm-tcp-soft-errors-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2007. This Internet-Draft will expire on June 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a non-standard, but widely implemented, This document describes a non-standard, but widely implemented,
modification to TCP's handling of ICMP soft error messages, that modification to TCP's handling of ICMP soft error messages, that
rejects pending connection-requests when those error messages are rejects pending connection-requests when those error messages are
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.2. Reaction to ICMP error messages that indicate soft 2.2. Reaction to ICMP error messages that indicate soft
errors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problems that may arise from TCP's reaction to soft errors . . 5 3. Problems that may arise from TCP's reaction to soft errors . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5
3.2. Problems that may arise with Dual Stack IPv6 on by 3.2. Problems that may arise with Dual Stack IPv6 on by
Default . . . . . . . . . . . . . . . . . . . . . . . . . 6 Default . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployed workarounds for long delays between 4. Deployed workarounds for long delays between
connection-establishment attempts . . . . . . . . . . . . . . 7 connection-establishment attempts . . . . . . . . . . . . . . 7
4.1. Context-sensitive ICMP/TCP interaction . . . . . . . . . . 7 4.1. Context-sensitive ICMP/TCP interaction . . . . . . . . . . 7
4.2. Context-sensitive ICMP/TCP interaction with repeated 4.2. Context-sensitive ICMP/TCP interaction with repeated
confirmation . . . . . . . . . . . . . . . . . . . . . . . 7 confirmation . . . . . . . . . . . . . . . . . . . . . . . 8
5. Possible drawbacks of changing ICMP semantics . . . . . . . . 8 5. Possible drawbacks of changing ICMP semantics . . . . . . . . 9
5.1. Non-deterministic transient network failures . . . . . . . 9 5.1. Non-deterministic transient network failures . . . . . . . 9
5.2. Deterministic transient network failures . . . . . . . . . 9 5.2. Deterministic transient network failures . . . . . . . . . 9
5.3. Non-compliant Network Address Translators (NATs) . . . . . 9 5.3. Non-compliant Network Address Translators (NATs) . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Change log (to be removed before publication of Appendix A. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 12 the document as an RFC) . . . . . . . . . . . . . . . 12
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-05 . . . . . 12 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-06 . . . . . 13
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 12 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-05 . . . . . 13
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 12 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 13
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 13 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 13
A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 13 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 13
A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 13 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 14
A.7. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 13 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 14
A.8. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 13 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 14
A.9. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 13 A.9. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 14
A.10. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The handling of network failures can be separated into two different The handling of network failures can be separated into two different
actions: fault isolation and fault recovery. Fault isolation actions: fault isolation and fault recovery. Fault isolation
consists of the actions that hosts and routers take to determine that consists of the actions that hosts and routers take to determine that
there is a network failure. Fault recovery, on the other hand, there is a network failure. Fault recovery, on the other hand,
consists of the actions that hosts and routers perform in an attempt consists of the actions that hosts and routers perform in an attempt
to survive a network failure [RFC0816]. to survive a network failure [RFC0816].
skipping to change at page 6, line 21 skipping to change at page 6, line 21
signaled by some intermediate router to the local TCP by means of an signaled by some intermediate router to the local TCP by means of an
ICMP soft error message, the local TCP will still repeatedly ICMP soft error message, the local TCP will still repeatedly
retransmit the SYN segment until the connection timer expires (in the retransmit the SYN segment until the connection timer expires (in the
hopes that the error is transient). The Host Requirements RFC hopes that the error is transient). The Host Requirements RFC
[RFC1122] states that this timer MUST be large enough to provide [RFC1122] states that this timer MUST be large enough to provide
retransmission of the SYN segment for at least 3 minutes. This would retransmission of the SYN segment for at least 3 minutes. This would
mean that the application on the local host would spend several mean that the application on the local host would spend several
minutes for each unreachable address it uses for trying to establish minutes for each unreachable address it uses for trying to establish
the TCP connection. These long delays between connection the TCP connection. These long delays between connection
establishment attempts would be inappropriate for many interactive establishment attempts would be inappropriate for many interactive
applications such as the web ([Shneiderman] and [Thadani] offer some applications such as the web. [Shneiderman] and [Thadani] offer some
insight into interactive systems). This highlights that there is no insight into interactive systems (e.g., how the response time affects
the usability of an application). This highlights that there is no
one definition of a "transient error" and that the level of one definition of a "transient error" and that the level of
persistence in the face of failure represents a tradeoff. persistence in the face of failure represents a tradeoff.
It is worth noting that while most applications try the addresses It is worth noting that while most applications try the addresses
returned by the name-to-address function in serial, this is certainly returned by the name-to-address function in serial, this is certainly
not the only possible approach. For example, applications could try not the only possible approach. For example, applications could try
multiple addresses in parallel until one succeeds, possibly avoiding multiple addresses in parallel until one succeeds, possibly avoiding
the problem of long delays between connection establishment attempts the problem of long delays between connection establishment attempts
described in this document. described in this document.
skipping to change at page 6, line 52 skipping to change at page 7, line 4
possible variants of this scenario, which differ in whether the lack possible variants of this scenario, which differ in whether the lack
of connectivity is signaled to the sending node, or not. of connectivity is signaled to the sending node, or not.
In those scenarios in which packets sent to a destination are In those scenarios in which packets sent to a destination are
silently dropped and no ICMPv6 [RFC4443] errors are generated, there silently dropped and no ICMPv6 [RFC4443] errors are generated, there
is little that can be done other than waiting for the existing is little that can be done other than waiting for the existing
connection timeout mechanism in TCP, or an application timeout, to be connection timeout mechanism in TCP, or an application timeout, to be
triggered. triggered.
In scenarios where a node has no default routers and Neighbor In scenarios where a node has no default routers and Neighbor
Unreachability Detection (NUD) [RFC2461] fails for destinations Unreachability Detection (NUD) [RFC4861] fails for destinations
assumed to be on-link, or where firewalls or other systems that assumed to be on-link, or where firewalls or other systems that
enforce scope boundaries send ICMPv6 errors, the sending node will be enforce scope boundaries send ICMPv6 errors, the sending node will be
signaled of the unreachability problem. However, as discussed in signaled of the unreachability problem. However, as discussed in
Section 2.2, standard TCP implementations will not abort connections Section 2.2, standard TCP implementations will not abort connections
when receiving ICMP error messages that indicate soft errors. when receiving ICMP error messages that indicate soft errors.
4. Deployed workarounds for long delays between connection- 4. Deployed workarounds for long delays between connection-
establishment attempts establishment attempts
The following subsections describe a number of workarounds for the The following subsections describe a number of workarounds for the
skipping to change at page 7, line 34 skipping to change at page 7, line 35
As discussed in Section 1, it may make sense for the fault recovery As discussed in Section 1, it may make sense for the fault recovery
action to depend not only on the type of error being reported, but action to depend not only on the type of error being reported, but
also on the state of the connection against which the error is also on the state of the connection against which the error is
reported. For example, one could infer that when an error arrives in reported. For example, one could infer that when an error arrives in
response to opening a new connection, it is probably caused by response to opening a new connection, it is probably caused by
opening the connection improperly, rather than by a transient network opening the connection improperly, rather than by a transient network
failure [RFC0816]. failure [RFC0816].
A number of TCP implementations have modified their reaction to soft A number of TCP implementations have modified their reaction to soft
errors, to treat the errors as hard errors in the SYN-SENT or SYN- errors, to treat the errors as hard errors in the SYN-SENT or SYN-
RECEIVED states. However, this change violates section 4.2.3.9 of RECEIVED states. For example, this workaround has been implemented,
[RFC1122], which states that these Unreachable messages indicate soft for example, in the Linux kernel since version 2.0.0 (released in
error conditions and TCP MUST NOT abort the corresponding connection. 1996) [Linux]. However, it should be noted that this change violates
section 4.2.3.9 of [RFC1122], which states that these Unreachable
messages indicate soft error conditions and therefore TCP MUST NOT
abort the corresponding connection.
This workaround has been implemented, for example, in the Linux [RFC3168] states that a host that receives a RST in response to the
kernel since version 2.0.0 (released in 1996) [Linux]. Section 4.2 transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and
discusses a more conservative approach than that sketched above that ECE cleared. This is meant to deal with faulty middle-boxes that
is implemented in FreeBSD. reject connections when a SYN segment has the ECE and CWR bits set.
Given that this section describes a modification that processes ICMP
error messages as hard errors when they are received for a connection
in any of the non-synchronized states, systems implementing this
behavior could resend the SYN segment with the ECE and CWR bits
cleared when an ICMP error message is received in response to a SYN
segment that had these bits set.
Section 4.2 discusses a more conservative approach than that sketched
above, that is implemented in FreeBSD.
4.2. Context-sensitive ICMP/TCP interaction with repeated confirmation 4.2. Context-sensitive ICMP/TCP interaction with repeated confirmation
A more conservative approach than simply treating soft errors as hard A more conservative approach than simply treating soft errors as hard
errors as described above would be to abort a connection in the SYN- errors as described above would be to abort a connection in the SYN-
SENT or SYN-RECEIVED states only after an ICMP Destination SENT or SYN-RECEIVED states only after an ICMP Destination
Unreachable has been received a specified number of times, and the Unreachable has been received a specified number of times, and the
SYN segment has been retransmitted more than some specified number of SYN segment has been retransmitted more than some specified number of
times. times.
skipping to change at page 10, line 16 skipping to change at page 10, line 31
the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP
"Destination Unreachable" message that indicates a soft error. "Destination Unreachable" message that indicates a soft error.
Therefore, the modification could be exploited to reset valid Therefore, the modification could be exploited to reset valid
connections during the connection-establishment phase. connections during the connection-establishment phase.
The non-standard workaround described in this document makes TCP more The non-standard workaround described in this document makes TCP more
vulnerable to attack, even if only slightly. However, we note that vulnerable to attack, even if only slightly. However, we note that
an attacker wishing to reset ongoing TCP connections could send any an attacker wishing to reset ongoing TCP connections could send any
of the ICMP hard error messages in any connection state. of the ICMP hard error messages in any connection state.
Generally, TCP backs off its retransmission timer each time it
retransmits the SYN segment for the same connection. If a TCP
implements the modification described in this document, that is,
tries the next address in the list upon receipt of an ICMP error
message, it might end up injecting more packets into the network than
if it had simply retried the same address a number of times.
However, compliant TCP implementations might already incur into this
behaviour (e.g., as a result of cycling through the list of IP
addressses in response to RST segments) as there are currently no
recommendations on methods for limiting the rate at which SYN
segments are sent for connecting to a specific destination.
A discussion of the use of ICMP to perform a variety of attacks A discussion of the use of ICMP to perform a variety of attacks
against TCP, and a number of counter-measures that minimize the against TCP, and a number of counter-measures that minimize the
impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks]. impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks].
A discussion of the security issues arising from the use of ICMPv6 A discussion of the security issues arising from the use of ICMPv6
can be found in [RFC4443]. can be found in [RFC4443].
7. Acknowledgements 7. Acknowledgements
The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry
skipping to change at page 11, line 17 skipping to change at page 11, line 44
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
Discovery for IP Version 6 (IPv6)", RFC 2461, of Explicit Congestion Notification (ECN) to IP",
December 1998. RFC 3168, September 2001.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
9.2. Informative References 9.2. Informative References
[Guynes] Guynes, J., "Impact of System Response Time on State [Guynes] Guynes, J., "Impact of System Response Time on State
Anxiety", Communications of the ACM , 1988. Anxiety", Communications of the ACM , 1988.
[I-D.ietf-behave-tcp] [I-D.ietf-behave-tcp]
Guha, S., "NAT Behavioral Requirements for TCP", Guha, S., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-07 (work in progress), April 2007. draft-ietf-behave-tcp-07 (work in progress), April 2007.
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
skipping to change at page 12, line 18 skipping to change at page 13, line 5
[Stevens2] [Stevens2]
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
[Thadani] Thadani, A., "Interactive User Productivity", IBM Systems [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems
Journal No. 1, 1981. Journal No. 1, 1981.
Appendix A. Change log (to be removed before publication of the Appendix A. Change log (to be removed before publication of the
document as an RFC) document as an RFC)
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-05 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-06
o Added a paragraph (in Section 4.1) about the interaction of the
described modification with ECN-enabled connections
o Added a paragraph (in Section 6) about the possible scenario in
which a host injects SYN segments into the network at a high rate,
in response to ICMP soft errors.
o Miscellaneous editorial changes
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-05
o Miscellaneous edits, clarifications, and reorganization of both o Miscellaneous edits, clarifications, and reorganization of both
workarounds into a single top-level section, as suggested by Pasi workarounds into a single top-level section, as suggested by Pasi
Sarolahti. Sarolahti.
o Added note on non-compliant NATs, as suggested by Ted Faber and o Added note on non-compliant NATs, as suggested by Ted Faber and
Saikat Guha Saikat Guha
o Miscellaneous edits suggested by Gorry Fairhurst o Miscellaneous edits suggested by Gorry Fairhurst
o Added a table to clarify how to extrapolate the concept of ICMPv4 o Added a table to clarify how to extrapolate the concept of ICMPv4
"soft errors" to ICMPv6 (as suggested by Arifumi Matsumoto and "soft errors" to ICMPv6 (as suggested by Arifumi Matsumoto and
Gorry Fairhurst). Gorry Fairhurst).
o Miscellaneous edits, clarification on alternative approach by o Miscellaneous edits, clarification on alternative approach by
sending connection requests in parallel, example of mobile system sending connection requests in parallel, example of mobile system
(for non-deterministic errors), and note on the possible impact of (for non-deterministic errors), and note on the possible impact of
the workarounds on TCP's robusteness (as suggested by Joe Touch) the workarounds on TCP's robusteness (as suggested by Joe Touch)
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-04 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-04
o Addresses feedback sent by Carlos Pignataro (adds missing error o Addresses feedback sent by Carlos Pignataro (adds missing error
codes in Section 2, and fixes a number of typos/writeos). codes in Section 2, and fixes a number of typos/writeos).
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-03 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-03
o Addresses feedback sent by Ted Faber and Gorry Fairhurst o Addresses feedback sent by Ted Faber and Gorry Fairhurst
(miscellaneous editorial changes). (miscellaneous editorial changes).
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-02 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-02
o Moved appendix on FreeBSD's approach to the body of the draft. o Moved appendix on FreeBSD's approach to the body of the draft.
o Removed rest of the appendix, as suggested by Ron Bonica and Mark o Removed rest of the appendix, as suggested by Ron Bonica and Mark
Allman. Allman.
o Reworded some parts of the document to make the text more neutral. o Reworded some parts of the document to make the text more neutral.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-01 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-01
o Addressed feedback posted by Sally Floyd (remove sentence in o Addressed feedback posted by Sally Floyd (remove sentence in
Section 2.1 regarding processing of RST segments) Section 2.1 regarding processing of RST segments)
A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-00 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.7. Changes from draft-gont-tcpm-tcp-soft-errors-02 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-02
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.8. Changes from draft-gont-tcpm-tcp-soft-errors-01 A.9. Changes from draft-gont-tcpm-tcp-soft-errors-01
o Changed wording to describe the mechanism, rather than proposing o Changed wording to describe the mechanism, rather than proposing
it it
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.9. Changes from draft-gont-tcpm-tcp-soft-errors-00 A.10. Changes from draft-gont-tcpm-tcp-soft-errors-00
o Added reference to the Linux implementation in Section 4.1 o Added reference to the Linux implementation in Section 4.1
o Added Section 5 o Added Section 5
o Added section on Higher-Level API o Added section on Higher-Level API
o Added Section 4.2 o Added Section 4.2
o Moved section "Asynchronous Application Notification" to Appendix o Moved section "Asynchronous Application Notification" to Appendix
 End of changes. 23 change blocks. 
44 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/