draft-ietf-tcpimpl-pmtud-01.txt   draft-ietf-tcpimpl-pmtud-02.txt 
Network Working Group K. Lahey Network Working Group K. Lahey
Expires: October 1999 Expires: January 2000
TCP Problems with Path MTU Discovery TCP Problems with Path MTU Discovery
<draft-ietf-tcpimpl-pmtud-01.txt> <draft-ietf-tcpimpl-pmtud-02.txt>
1. Status of this Memo 1. Status of this Memo
This documnt is an Internet-Draft and is in full onformance with all This documnt is an Internet-Draft and is in full onformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet Drafts as reference at any 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
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of does not specify an Internet standard of any kind. Distribution of
this memo is unlimited. this memo is unlimited.
2. Introduction 2. Introduction
This memo catalogs several known TCP implementation problems dealing This memo catalogs several known TCP implementation problems dealing
with Path MTU Discovery [RFC1191], including the long-standing black with Path MTU Discovery [RFC1191], including the long-standing black
hole problem, stretch ACKs due to confusion between MSS and segment hole problem, stretch ACKs due to confusion between MSS and segment
size, and MSS advertisement based on PMTU. The goal in doing so is size, and MSS advertisement based on PMTU. The goal in doing so is
to improve conditions in the existing Internet by enhancing the to improve conditions in the existing Internet by enhancing the
quality of current TCP/IP implementations. quality of current TCP/IP implementations.
While Path MTU Discovery (PMTUD) can be used with any upper-layer While Path MTU Discovery (PMTUD) can be used with any upper-layer
protocol, it is most commonly used by TCP; this document does not protocol, it is most commonly used by TCP; this document does not
attempt to treat problems encountered by other upper-layer protocols. attempt to treat problems encountered by other upper-layer protocols.
Path MTU Discovery for IPv6 [RFC1981] treats only IPv6-dependent
issues, but not the TCP issues brought up in this document.
Each problem is defined as follows: Each problem is defined as follows:
Name of Problem Name of Problem
The name associated with the problem. In this memo, the name is The name associated with the problem. In this memo, the name is
given as a subsection heading. given as a subsection heading.
Classification Classification
One or more problem categories for which the problem is classified: One or more problem categories for which the problem is classified:
"congestion control", "performance", "reliability", "non-interoper- "congestion control", "performance", "reliability", "non-interoper-
skipping to change at page 3, line 35 skipping to change at page 3, line 38
Path MTU Discovery (PMTUD) works by sending out as large a packet Path MTU Discovery (PMTUD) works by sending out as large a packet
as possible, with the Don't Fragment (DF) bit set in the IP header. as possible, with the Don't Fragment (DF) bit set in the IP header.
If the packet is too large for a router to forward on to a particu- If the packet is too large for a router to forward on to a particu-
lar link, the router must send an ICMP Destination Unreachable -- lar link, the router must send an ICMP Destination Unreachable --
Fragmentation Needed message to the source address. Fragmentation Needed message to the source address.
As was pointed out in [RFC1435], routers don't always do this cor- As was pointed out in [RFC1435], routers don't always do this cor-
rectly -- many routers fail to send the ICMP messages, for a vari- rectly -- many routers fail to send the ICMP messages, for a vari-
ety of reasons ranging from kernel bugs to configuration problems. ety of reasons ranging from kernel bugs to configuration problems.
Firewalls are often misconfigured to supress all ICMP messages. Firewalls are often misconfigured to supress all ICMP messages.
IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels shouldn't cause
these sorts of problems, if the implementations follow the advice
in the appropriate documents.
PMTUD, as documented in [RFC1191], fails when confronted with this PMTUD, as documented in [RFC1191], fails when confronted with
problem. The upper-layer protocol continues to try to send large routers that fail to send the appropriate ICMP message. The upper-
packets and, without the ICMP messages, never discovers that it layer protocol continues to try to send large packets and, without
needs to reduce the size of those packets. Its packets are disap- the ICMP messages, never discovers that it needs to reduce the size
pearing into a PMTUD black hole. of those packets. Its packets are disappearing into a PMTUD black
hole.
Significance Significance
When PMTUD fails due to the lack of ICMP messages, TCP will also When PMTUD fails due to the lack of ICMP messages, TCP will also
completly fail under some conditions. completly fail under some conditions.
Implications Implications
This failure is especially difficult to debug, as pings and some This failure is especially difficult to debug, as pings and some
interactive TCP connections to the destination host work. Bulk interactive TCP connections to the destination host work. Bulk
transfers fail with the first large packet and the connection even- transfers fail with the first large packet and the connection even-
skipping to change at page 5, line 43 skipping to change at page 6, line 6
In this case, the sender sees four packets fail to traverse the In this case, the sender sees four packets fail to traverse the
network (using a two-packet initial send window) and turns off network (using a two-packet initial send window) and turns off
PMTUD. All subsequent packets have the DF flag turned off, and the PMTUD. All subsequent packets have the DF flag turned off, and the
size set to the default value of 536 [RFC1122]. size set to the default value of 536 [RFC1122].
References References
This problem has been discussed extensively on the tcp-impl mailing This problem has been discussed extensively on the tcp-impl mailing
list; the name "black hole" has been in use for many years. list; the name "black hole" has been in use for many years.
How to detect How to detect
This shows up as a TCP connection which hanges (fails to make This shows up as a TCP connection which hangs (fails to make
progress) until closed by timeout. A series of ICMP echo packets progress) until closed by timeout (this often manifests itself as a
will show that the connection is still passing packets, a connection that connects and starts to transfer, then eventually
series of MTU-sized ICMP echo packets will show some fragmentation, terminates after 15 minutes with zero bytes transfered). This is
and a series of MTU-sized ICMP echo packets with DF set will fail. particularly annoying with an application like ftp, which will work
This can be confusing for network engineers trying to diagnose the perfectly while it uses small packets for control information, and
problem. then fail on bulk transfers.
There are several traceroute implementations that do PMTUD. See, A series of ICMP echo packets will show that the connection is
for example, ftp://ftp.psc.edu/pub/networking/tools/traceroute.tar still passing packets, a series of MTU-sized ICMP echo packets
will show some fragmentation, and a series of MTU-sized ICMP echo
packets with DF set will fail. This can be confusing for network
engineers trying to diagnose the problem.
There are several traceroute implementations that do PMTUD, and can
demonstrate the problem. See, for example,
ftp://ftp.psc.edu/pub/networking/tools/traceroute.tar
How to fix How to fix
TCP should notice that the connection is timing out. After several TCP should notice that the connection is timing out. After several
timeouts, TCP should attempt to send smaller packets, perhaps turn- timeouts, TCP should attempt to send smaller packets, perhaps turn-
ing off the DF flag for each packet. If this succeeds, it should ing off the DF flag for each packet. If this succeeds, it should
continue to turn off PMTUD for the connection for some reasonable continue to turn off PMTUD for the connection for some reasonable
period of time, after which it should probe again to try to deter- period of time, after which it should probe again to try to deter-
mine if the path has changed. mine if the path has changed.
Note that, under IPv6, there is no DF bit -- it is implicitly on at Note that, under IPv6, there is no DF bit -- it is implicitly on at
skipping to change at page 6, line 29 skipping to change at page 6, line 44
originating host. Fortunately, the minimum supported MTU for IPv6 originating host. Fortunately, the minimum supported MTU for IPv6
is 1280 octets, which is significantly larger than the 68 octet is 1280 octets, which is significantly larger than the 68 octet
minimum in IPv4. This should make it more reasonable for IPv6 TCP minimum in IPv4. This should make it more reasonable for IPv6 TCP
implementations to fall back to 1280 octet packets, when IPv4 implementations to fall back to 1280 octet packets, when IPv4
implementations will probably have to turn off DF to respond to implementations will probably have to turn off DF to respond to
black hole detection. black hole detection.
While, ideally, the ICMP black holes should be fixed when they are While, ideally, the ICMP black holes should be fixed when they are
found, the large number of these requires some more aggressive found, the large number of these requires some more aggressive
response on the part of host implementations. Any system that uses response on the part of host implementations. Any system that uses
Path MTU Discovery should also support some form of black hole Path MTU Discovery should consider support some for some form of
detection. black hole detection.
3.2. 3.2.
Name of Problem Name of Problem
Stretch ACK due to PMTUD Stretch ACK due to PMTUD
Classification Classification
Congestion Control / Performance Congestion Control / Performance
Description Description
skipping to change at page 7, line 29 skipping to change at page 7, line 45
RFC 1122 outlines the requirements for frequency of ACK generation. RFC 1122 outlines the requirements for frequency of ACK generation.
[RFC2581] expands on this and clarifies that delayed ACK is a [RFC2581] expands on this and clarifies that delayed ACK is a
SHOULD, not a MUST. SHOULD, not a MUST.
Trace file demonstrating it Trace file demonstrating it
Made using tcpdump recording at an intermediate host. The times- Made using tcpdump recording at an intermediate host. The times-
tamp options from all but the first two packets have been removed tamp options from all but the first two packets have been removed
for clarity. for clarity.
18:16:52.976657 A > B: S 3183102292:3183102292(0) win 16384 <mss 4312,nop,wscale 0,nop,nop,timestamp 12128 0> (DF) () 18:16:52.976657 A > B: S 3183102292:3183102292(0) win 16384 <mss
18:16:52.979580 B > A: S 2022212745:2022212745(0) ack 3183102293 win 49152 <mss 4312,nop,wscale 1,nop,nop,timestamp 1592957 12128> (DF) () 4312,nop,wscale 0,nop,nop,timestamp 12128 0> (DF) ()
18:16:52.979580 B > A: S 2022212745:2022212745(0) ack 3183102293 win
49152 <mss 4312,nop,wscale 1,nop,nop,timestamp 1592957 12128> (DF) ()
18:16:52.979738 A > B: . ack 1 win 17248 (DF) () 18:16:52.979738 A > B: . ack 1 win 17248 (DF) ()
18:16:52.982473 A > B: . 1:4301(4300) ack 1 win 17248 (DF) () 18:16:52.982473 A > B: . 1:4301(4300) ack 1 win 17248 (DF) ()
18:16:52.982557 C > A: icmp: B unreachable - need to frag (mtu 1500) (DF) () 18:16:52.982557 C > A: icmp: B unreachable - need to frag (mtu 1500)
(DF) ()
18:16:52.985839 B > A: . ack 1 win 32768 (DF) () 18:16:52.985839 B > A: . ack 1 win 32768 (DF) ()
18:16:54.129928 A > B: . 1:1449(1448) ack 1 win 17248 (DF) () 18:16:54.129928 A > B: . 1:1449(1448) ack 1 win 17248 (DF) ()
. .
. .
. .
18:16:58.507078 A > B: . 1463941:1465389(1448) ack 1 win 17248 (DF) () 18:16:58.507078 A > B: . 1463941:1465389(1448) ack 1 win 17248 (DF) ()
18:16:58.507200 A > B: . 1465389:1466837(1448) ack 1 win 17248 (DF) () 18:16:58.507200 A > B: . 1465389:1466837(1448) ack 1 win 17248 (DF) ()
18:16:58.507326 A > B: . 1466837:1468285(1448) ack 1 win 17248 (DF) () 18:16:58.507326 A > B: . 1466837:1468285(1448) ack 1 win 17248 (DF) ()
18:16:58.507439 A > B: . 1468285:1469733(1448) ack 1 win 17248 (DF) () 18:16:58.507439 A > B: . 1468285:1469733(1448) ack 1 win 17248 (DF) ()
18:16:58.524763 B > A: . ack 1452357 win 32768 (DF) () 18:16:58.524763 B > A: . ack 1452357 win 32768 (DF) ()
skipping to change at page 8, line 31 skipping to change at page 8, line 50
ACK packets. ACK packets.
Trace file demonstrating correct behavior Trace file demonstrating correct behavior
Made using tcpdump recording at an intermediate host. The times- Made using tcpdump recording at an intermediate host. The times-
tamp options from all but the first two packets have been removed tamp options from all but the first two packets have been removed
for clarity. for clarity.
18:13:32.287965 A > B: S 2972697496:2972697496(0) win 16384 18:13:32.287965 A > B: S 2972697496:2972697496(0) win 16384
<mss 4312,nop,wscale 0,nop,nop,timestamp 11326 0> (DF) <mss 4312,nop,wscale 0,nop,nop,timestamp 11326 0> (DF)
18:13:32.290785 B > A: S 245639054:245639054(0) ack 2972697497 win 34496 18:13:32.290785 B > A: S 245639054:245639054(0) ack 2972697497 win
34496
<mss 4312> (DF) <mss 4312> (DF)
18:13:32.290941 A > B: . ack 1 win 17248 (DF) 18:13:32.290941 A > B: . ack 1 win 17248 (DF)
18:13:32.293774 A > B: . 1:4313(4312) ack 1 win 17248 (DF) 18:13:32.293774 A > B: . 1:4313(4312) ack 1 win 17248 (DF)
18:13:32.293856 C > A: icmp: B unreachable - need to frag (mtu 1500) (DF) 18:13:32.293856 C > A: icmp: B unreachable - need to frag (mtu 1500)
(DF)
18:13:33.637338 A > B: . 1:1461(1460) ack 1 win 17248 (DF) 18:13:33.637338 A > B: . 1:1461(1460) ack 1 win 17248 (DF)
. .
. .
. .
18:13:35.561691 A > B: . 1514021:1515481(1460) ack 1 win 17248 (DF) 18:13:35.561691 A > B: . 1514021:1515481(1460) ack 1 win 17248 (DF)
18:13:35.561814 A > B: . 1515481:1516941(1460) ack 1 win 17248 (DF) 18:13:35.561814 A > B: . 1515481:1516941(1460) ack 1 win 17248 (DF)
18:13:35.561938 A > B: . 1516941:1518401(1460) ack 1 win 17248 (DF) 18:13:35.561938 A > B: . 1516941:1518401(1460) ack 1 win 17248 (DF)
18:13:35.562059 A > B: . 1518401:1519861(1460) ack 1 win 17248 (DF) 18:13:35.562059 A > B: . 1518401:1519861(1460) ack 1 win 17248 (DF)
18:13:35.562174 A > B: . 1519861:1521321(1460) ack 1 win 17248 (DF) 18:13:35.562174 A > B: . 1519861:1521321(1460) ack 1 win 17248 (DF)
18:13:35.564008 B > A: . ack 1481901 win 64680 (DF) 18:13:35.564008 B > A: . ack 1481901 win 64680 (DF)
skipping to change at page 9, line 39 skipping to change at page 10, line 10
Several solutions for this problem have been proposed: Several solutions for this problem have been proposed:
A simple solution is to ACK every other packet, regardless of size. A simple solution is to ACK every other packet, regardless of size.
This has the drawback of generating large numbers of ACKs in the This has the drawback of generating large numbers of ACKs in the
face of lots of very small packets; this shows up with applica- face of lots of very small packets; this shows up with applica-
tions like the X Window System. tions like the X Window System.
A slightly more complex solution would monitor the size of incoming A slightly more complex solution would monitor the size of incoming
segments and try to determine what segment size the sender is segments and try to determine what segment size the sender is
using. This requires slightly more state in the receiver, but has using. This requires slightly more state in the receiver, but has
the advantage of making receiver SWS avoidance computations more the advantage of making receiver silly window syndrome avoidance
accurate. computations more accurate.
3.3. 3.3.
Name of Problem Name of Problem
Determining MSS from PMTU Determining MSS from PMTU
Classification Classification
Performance Performance
Description Description
skipping to change at page 11, line 49 skipping to change at page 12, line 17
22:33:34.477580 A2 > B: P 1969:2953(984) ack 1 win 8856 (DF) 22:33:34.477580 A2 > B: P 1969:2953(984) ack 1 win 8856 (DF)
[...] [...]
Notice that the SYN packet for session A2 specifies an MSS of 984. Notice that the SYN packet for session A2 specifies an MSS of 984.
Trace file demonstrating correct behavior Trace file demonstrating correct behavior
As before, this trace was made using tcpdump running on an interme- As before, this trace was made using tcpdump running on an interme-
diate host. Host A initiates two separate consecutive connections, diate host. Host A initiates two separate consecutive connections,
A1 and A2, to host B. Router C is the location of the MTU A1 and A2, to host B. Router C is the location of the MTU bottle-
bottleneck. As usual, TCP options are removed from all non-SYN neck. As usual, TCP options are removed from all non-SYN packets.
packets.
22:36:58.828602 A1 > B: S 3402991286:3402991286(0) win 32768 22:36:58.828602 A1 > B: S 3402991286:3402991286(0) win 32768
<mss 4312,wscale 0,nop,timestamp 1123370309 0, <mss 4312,wscale 0,nop,timestamp 1123370309 0,
echo 1123370309> (DF) echo 1123370309> (DF)
22:36:58.844040 B > A1: S 946999880:946999880(0) 22:36:58.844040 B > A1: S 946999880:946999880(0)
ack 3402991287 win 16384 ack 3402991287 win 16384
<mss 65240,nop,wscale 0,nop,nop,timestamp 429552 1123370309> <mss 65240,nop,wscale 0,nop,nop,timestamp 429552 1123370309>
22:36:58.848058 A1 > B: . ack 1 win 32768 (DF) 22:36:58.848058 A1 > B: . ack 1 win 32768 (DF)
22:36:58.851514 A1 > B: P 1:1025(1024) ack 1 win 32768 (DF) 22:36:58.851514 A1 > B: P 1:1025(1024) ack 1 win 32768 (DF)
22:36:58.851584 C > A1: icmp: 129.99.238.5 unreachable - 22:36:58.851584 C > A1: icmp: 129.99.238.5 unreachable -
skipping to change at page 13, line 22 skipping to change at page 13, line 33
are often caused by over-zealous security administrators who block are often caused by over-zealous security administrators who block
all ICMP messages. It is vitally important that those who design and all ICMP messages. It is vitally important that those who design and
deploy security systems understand the impact of strict filtering on deploy security systems understand the impact of strict filtering on
upper-layer protocols. The safest web site in the world is worthless upper-layer protocols. The safest web site in the world is worthless
if most TCP implementations cannot transfer data from it. It would if most TCP implementations cannot transfer data from it. It would
be far nicer to have all of the black holes fixed rather than fixing be far nicer to have all of the black holes fixed rather than fixing
all of the TCP implementations. all of the TCP implementations.
5. Acknowledgements 5. Acknowledgements
Thanks to Mark Allman and Vern Paxon for generous help reviewing the Thanks to Mark Allman and Vern Paxson for generous help reviewing the
document, and to Matt Mathis for early suggestions of various mecha- document, and to Matt Mathis for early suggestions of various mecha-
nisms that can cause PMTUD black holes, as well as review. The nisms that can cause PMTUD black holes, as well as review. The
structure for describing TCP problems, and the early description of structure for describing TCP problems, and the early description of
that structure is from [RFC2525]. Special thanks to Amy Bock, who that structure is from [RFC2525]. Special thanks to Amy Bock, who
helped perform the PMTUD tests which discovered these bugs. helped perform the PMTUD tests which discovered these bugs.
6. References 6. References
[RFC2581] [RFC2581]
M. Allman, V. Paxson, and W. Stevens, "TCP Congestion Control", M. Allman, V. Paxson, and W. Stevens, "TCP Congestion Control",
April 1999. April 1999.
[RFC1122] [RFC1122]
R. Braden, Editor, "Requirements for Internet Hosts -- Communica- R. Braden, Editor, "Requirements for Internet Hosts -- Communica-
tion Layers," Oct. 1989. tion Layers", Oct. 1989.
[Jacobson89] [Jacobson89]
V. Jacobson, C. Leres, and S. McCanne, tcpdump, available via V. Jacobson, C. Leres, and S. McCanne, tcpdump, available via
anonymous ftp to ftp.ee.lbl.gov, Jun. 1989. anonymous ftp to ftp.ee.lbl.gov, Jun. 1989.
[RFC1435] [RFC1435]
S. Knowles, "IESG Advice from Experience with Path MTU Discovery," S. Knowles, "IESG Advice from Experience with Path MTU Discovery",
March 1993. March 1993.
[RFC1191] [RFC1191]
J. Mogul and S. Deering, "Path MTU discovery," Nov. 1990. J. Mogul and S. Deering, "Path MTU discovery", Nov. 1990.
[RFC1981]
J. McCann, S. Deering & J. Mogul, "Path MTU Discovery for IP ver-
sion 6", August 1996
[Paxson96] [Paxson96]
V. Paxson, "End-to-End Routing Behavior in the Internet," IEEE/ACM V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM
Transactions on Networking (5), pp.~601-615, Oct. 1997. Transactions on Networking (5), pp.~601-615, Oct. 1997.
[RFC2525] [RFC2525]
V. Paxon, Editor, M. Allman, S. Dawson, W. Fenner, J. Griner, I. V. Paxon, Editor, M. Allman, S. Dawson, W. Fenner, J. Griner, I.
Heavens, K. Lahey, J. Semke, and B. Volz, "Known TCP Implementation Heavens, K. Lahey, J. Semke, and B. Volz, "Known TCP Implementation
Problems", March 1999. Problems", March 1999.
[RFC879] [RFC879]
J. Postel, "The TCP Maximum Segment Size and Related Topics," J. Postel, "The TCP Maximum Segment Size and Related Topics",
November, 1983. November, 1983.
[RFC2001] [RFC2001]
W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms," Jan. 1997. and Fast Recovery Algorithms", Jan. 1997.
7. Author's Address 7. Author's Address
Kevin Lahey <kml@nas.nasa.gov> Kevin Lahey <kml@novell.com>
NASA Ames Research Center/MRJ Novell, Inc.
MS 258-6 2211 N. First St.
Moffett Field, CA 94035 San Jose, CA 95131
USA USA
Phone: +1 650/604-4334 Phone: +1 650/604-4334
This draft was created in April 1999. 8. Full Copyright Statement
It expires in October 1999.
Copyright (C) The Internet Society (1999). 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.
This draft was created in August 1999.
It expires in January 2000.
 End of changes. 25 change blocks. 
41 lines changed or deleted 67 lines changed or added

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