< draft-ietf-ipsec-dpd-03.txt   draft-ietf-ipsec-dpd-04.txt >
IPSec Working Group IPSec Working Group
G. Huang G. Huang
S. Beaulieu S. Beaulieu
Internet Draft D. Rochefort Internet Draft D. Rochefort
Document: draft-ietf-ipsec-dpd-03.txt Cisco Systems, Inc. Document: draft-ietf-ipsec-dpd-04.txt Cisco Systems, Inc.
Expires: January 2004 June 2003 Expires: April 2004 October 2003
A Traffic-Based Method of Detecting Dead IKE Peers A Traffic-Based Method of Detecting Dead IKE Peers
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
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 line 33 skipping to change at line 33
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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.
Abstract Abstract
This draft describes a method of detecting a dead IKE peer. The This document describes the method detecting a dead IKE peer that is
method, called Dead Peer Detection (DPD) uses IPSec traffic patterns presently in use by a number of vendors. The method, called Dead
to limit the number of IKE messages sent. DPD, like other keepalive Peer Detection (DPD) uses IPSec traffic patterns to minimize the
mechanisms, is often necessary to perform IKE peer failover, or to number of IKE messages that are needed to confirm liveness. DPD,
reclaim lost resources. like other keepalive mechanisms, is needed to determine when to
perform IKE peer failover, and to reclaim lost resources.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Abstract...........................................................1 Abstract...........................................................1
Table of Contents..................................................1 Table of Contents..................................................1
1. Introduction....................................................2 1. Introduction....................................................2
2. Conventions used in this document...............................3 2. Conventions used in this document...............................3
3. Document Roadmap................................................3 3. Document Roadmap................................................3
4. Rationale for Periodic Message Exchange for Proof of Liveliness.3 4. Rationale for Periodic Message Exchange for Proof of Liveliness.3
5. Keepalives vs. Heartbeats.......................................3 5. Keepalives vs. Heartbeats.......................................3
Huang, Beaulieu, Rochefort Expires January 2004 1 Huang, Beaulieu, Rochefort Expires April 2004 1
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
5.1 Keepalives:..................................................3 5.1 Keepalives:..................................................3
5.2 Heartbeats:..................................................5 5.2 Heartbeats:..................................................5
6. DPD Protocol....................................................6 6. DPD Protocol....................................................6
6.1 DPD Vendor ID................................................6 6.1 DPD Vendor ID................................................6
6.2 Message Exchanges............................................7 6.2 Message Exchanges............................................7
6.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format...............7 6.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format...............7
6.4 Impetus for DPD Exchange.....................................8 6.4 Impetus for DPD Exchange.....................................8
6.5 Implementation Suggestion....................................8 6.5 Implementation Suggestion....................................8
skipping to change at line 100 skipping to change at line 101
The problem with current heartbeat and keepalive proposals is their The problem with current heartbeat and keepalive proposals is their
reliance upon their messages to be sent at regular intervals. In reliance upon their messages to be sent at regular intervals. In
the implementation, this translates into managing some timer to the implementation, this translates into managing some timer to
service these message intervals. Similarly, because rapid detection service these message intervals. Similarly, because rapid detection
of the dead peer is often desired, these messages must be sent with of the dead peer is often desired, these messages must be sent with
some frequency, again translating into considerable overhead for some frequency, again translating into considerable overhead for
message processing. In implementations and installations where message processing. In implementations and installations where
managing large numbers of simultaneous IKE sessions is of concern, managing large numbers of simultaneous IKE sessions is of concern,
these regular heartbeats/keepalives prove to be infeasible. these regular heartbeats/keepalives prove to be infeasible.
To this end, this draft proposes an approach to detect peer To this end, a number of vendors have implemented their own
liveliness without needing to send messages at regular intervals. approach to detect peer liveliness without needing to send messages
at regular intervals. This informational document describes the
current practice of those implementations. This scheme, called Dead
Peer Detection (DPD), relies on IKE Notify messages to query the
liveliness of an IKE peer.
Huang, Beaulieu, Rochefort Expires January 2004 2 Huang, Beaulieu, Rochefort Expires April 2004 2
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
This scheme, called Dead Peer Detection (DPD), relies on IKE Notify
messages to query the liveliness of an IKE peer.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3]. this document are to be interpreted as described in RFC-2119 [3].
3. Document Roadmap 3. Document Roadmap
As mentioned above, there are already proposed solutions to the As mentioned above, there are already proposed solutions to the
problem of detecting dead peers. Section 4 elaborates the rationale problem of detecting dead peers. Section 4 elaborates the rationale
skipping to change at line 157 skipping to change at line 159
peers must agree upon the interval at which keepalives are sent, peers must agree upon the interval at which keepalives are sent,
meaning that some negotiation is required during Phase 1. For any meaning that some negotiation is required during Phase 1. For any
prompt failover to be possible, the keepalives must also be sent at prompt failover to be possible, the keepalives must also be sent at
rather frequent intervals -- around 10 seconds or so. In this rather frequent intervals -- around 10 seconds or so. In this
hypothetical keepalives scenario, peers A and B agree to exchange hypothetical keepalives scenario, peers A and B agree to exchange
keepalives every 10 seconds. Essentially, every 10 seconds, one keepalives every 10 seconds. Essentially, every 10 seconds, one
peer must send a HELLO to the other. This HELLO serves as proof of peer must send a HELLO to the other. This HELLO serves as proof of
liveliness for the sending entity. In turn, the other peer must liveliness for the sending entity. In turn, the other peer must
acknowledge each keepalive HELLO. If the 10 seconds elapse, and one acknowledge each keepalive HELLO. If the 10 seconds elapse, and one
Huang, Beaulieu, Rochefort Expires January 2004 3 Huang, Beaulieu, Rochefort Expires April 2004 3
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
side has not received a HELLO, it will send the HELLO message side has not received a HELLO, it will send the HELLO message
itself, using the peer's ACK as proof of liveliness. Receipt of itself, using the peer's ACK as proof of liveliness. Receipt of
either a HELLO or ACK causes an entity's keepalive timer to reset. either a HELLO or ACK causes an entity's keepalive timer to reset.
Failure to receive an ACK in a certain period of time signals an Failure to receive an ACK in a certain period of time signals an
error. A clarification is presented below: error. A clarification is presented below:
Scenario 1: Scenario 1:
Peer A's 10-second timer elapses first, and it sends a HELLO to B. Peer A's 10-second timer elapses first, and it sends a HELLO to B.
skipping to change at line 211 skipping to change at line 213
After some number of errors, A assumes B is dead; deletes SAs and After some number of errors, A assumes B is dead; deletes SAs and
possibly initiates failover. possibly initiates failover.
An advantage of this scheme is that the party interested in the An advantage of this scheme is that the party interested in the
other peer's liveliness begins the message exchange. In Scenario 1, other peer's liveliness begins the message exchange. In Scenario 1,
peer A is interested in peer B's liveliness, and peer A consequently peer A is interested in peer B's liveliness, and peer A consequently
sends the HELLO. It is conceivable in such a scheme that peer B sends the HELLO. It is conceivable in such a scheme that peer B
would never be interested in peer A's liveliness. In such a case, would never be interested in peer A's liveliness. In such a case,
the onus would always lie on peer A to initiate the exchange. the onus would always lie on peer A to initiate the exchange.
Huang, Beaulieu, Rochefort Expires January 2004 4 Huang, Beaulieu, Rochefort Expires April 2004 4
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
5.2 Heartbeats: 5.2 Heartbeats:
By contrast, consider a proof-of-liveliness scheme involving By contrast, consider a proof-of-liveliness scheme involving
unidirectional (unacknowledged) messages. An entity interested in unidirectional (unacknowledged) messages. An entity interested in
its peer's liveliness would rely on the peer itself to send periodic its peer's liveliness would rely on the peer itself to send periodic
messages demonstrating liveliness. In such a scheme, the message messages demonstrating liveliness. In such a scheme, the message
exchange might look like this: exchange might look like this:
Scenario 3: Scenario 3:
skipping to change at line 267 skipping to change at line 269
such a scheme becomes clear in the remote-access scenario. Consider such a scheme becomes clear in the remote-access scenario. Consider
a VPN aggregator that terminates a large number of sessions (on the a VPN aggregator that terminates a large number of sessions (on the
order of 50,000 peers or so). Each peer requires fairly rapid order of 50,000 peers or so). Each peer requires fairly rapid
failover, therefore requiring the aggregator to send HELLO packets failover, therefore requiring the aggregator to send HELLO packets
every 10 seconds or so. Such a scheme simply lacks scalability, as every 10 seconds or so. Such a scheme simply lacks scalability, as
the aggregator must send 50,000 messages every few seconds. the aggregator must send 50,000 messages every few seconds.
In both of these schemes (keepalives and heartbeats), some In both of these schemes (keepalives and heartbeats), some
negotiation of message interval must occur, so that each entity can negotiation of message interval must occur, so that each entity can
Huang, Beaulieu, Rochefort Expires January 2004 5 Huang, Beaulieu, Rochefort Expires April 2004 5
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
know how often its peer expects a HELLO. This immediately adds a know how often its peer expects a HELLO. This immediately adds a
degree of complexity. Similarly, the need to send periodic messages degree of complexity. Similarly, the need to send periodic messages
(regardless of other IPSec/IKE activity), also increases (regardless of other IPSec/IKE activity), also increases
computational overhead to the system. computational overhead to the system.
6. DPD Protocol 6. DPD Protocol
DPD addresses the shortcomings of IKE keepalives- and heartbeats- DPD addresses the shortcomings of IKE keepalives- and heartbeats-
schemes by introducing a more reasonable logic governing message schemes by introducing a more reasonable logic governing message
skipping to change at line 322 skipping to change at line 324
It is important to note that the decision about when to initiate a It is important to note that the decision about when to initiate a
DPD exchange is implementation specific. An implementation might DPD exchange is implementation specific. An implementation might
even define the DPD messages to be at regular intervals following even define the DPD messages to be at regular intervals following
idle periods. See section 6.5 for more implementation suggestions. idle periods. See section 6.5 for more implementation suggestions.
6.1 DPD Vendor ID 6.1 DPD Vendor ID
To demonstrate DPD capability, an entity must send the DPD vendor To demonstrate DPD capability, an entity must send the DPD vendor
ID. Both peers of an IKE session MUST send the DPD vendor ID before ID. Both peers of an IKE session MUST send the DPD vendor ID before
DPD exchanges can begin. The format of the DPD Vendor ID is: DPD exchanges can begin. The format of the DPD Vendor ID is:
Huang, Beaulieu, Rochefort Expires January 2004 6 Huang, Beaulieu, Rochefort Expires April 2004 6
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !M!M! ! !M!M!
! HASHED_VENDOR_ID !J!N! ! HASHED_VENDOR_ID !J!N!
! !R!R! ! !R!R!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 374 skipping to change at line 376
6.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format 6.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format
When sent, the R-U-THERE message MUST take the following form: When sent, the R-U-THERE message MUST take the following form:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) ! ! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size = 16 ! Notify Message Type ! ! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Security Parameter Index (SPI) ~ ~ Security Parameter Index (SPI) ~
Huang, Beaulieu, Rochefort Expires January 2004 7 Huang, Beaulieu, Rochefort Expires April 2004 7
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! Notification Data !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and
Payload Length fields should be set accordingly. The remaining Payload Length fields should be set accordingly. The remaining
fields are set as: fields are set as:
- Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI. - Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.
- Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP. - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP.
- SPI Size (2 octets) - SHOULD be set to sixteen (16), the length of - SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of
two octet-sized ISAKMP cookies. two octet-sized ISAKMP cookies.
- Notify Message Type (2 octets) - MUST be set to R-U-THERE - Notify Message Type (2 octets) - MUST be set to R-U-THERE
- Security Parameter Index (16 octets) - SHOULD be set to the - Security Parameter Index (16 octets) - SHOULD be set to the
cookies of the Initiator and Responder of the IKE SA (in that cookies of the Initiator and Responder of the IKE SA (in that
order) order)
- Notification Data (4 octets) - MUST be set to the sequence number - Notification Data (4 octets) - MUST be set to the sequence number
corresponding to this message corresponding to this message
skipping to change at line 436 skipping to change at line 436
implementation SHOULD retransmit R-U-THERE queries when it fails to implementation SHOULD retransmit R-U-THERE queries when it fails to
receive an ACK. After some number of retransmitted messages, an receive an ACK. After some number of retransmitted messages, an
implementation SHOULD assume its peer to be unreachable and delete implementation SHOULD assume its peer to be unreachable and delete
IPSec and IKE SAs to the peer. IPSec and IKE SAs to the peer.
6.5 Implementation Suggestion 6.5 Implementation Suggestion
Since the liveliness of a peer is only questionable when no traffic Since the liveliness of a peer is only questionable when no traffic
is exchanged, a viable implementation might begin by monitoring is exchanged, a viable implementation might begin by monitoring
idleness. Along these lines, a peer's liveliness is only important idleness. Along these lines, a peer's liveliness is only important
Huang, Beaulieu, Rochefort Expires January 2004 8 Huang, Beaulieu, Rochefort Expires April 2004 8
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
when there is outbound traffic to be sent. To this end, an when there is outbound traffic to be sent. To this end, an
implementation can initiate a DPD exchange (i.e., send an R-U-THERE implementation can initiate a DPD exchange (i.e., send an R-U-THERE
message) when there has been some period of idleness, followed by message) when there has been some period of idleness, followed by
the desire to send outbound traffic. Likewise, an entity can the desire to send outbound traffic. Likewise, an entity can
initiate a DPD exchange if it has sent outbound IPSec traffic, but initiate a DPD exchange if it has sent outbound IPSec traffic, but
not received any inbound IPSec packets in response. A complete DPD not received any inbound IPSec packets in response. A complete DPD
exchange (i.e., transmission of R-U-THERE and receipt of exchange (i.e., transmission of R-U-THERE and receipt of
corresponding R-U-THERE-ACK) will serve as proof of liveliness until corresponding R-U-THERE-ACK) will serve as proof of liveliness until
skipping to change at line 490 skipping to change at line 490
7.1 Sequence Number in DPD Messages 7.1 Sequence Number in DPD Messages
To guard against message replay attacks and false proof of To guard against message replay attacks and false proof of
liveliness, a 32-bit sequence number MUST be presented with each R- liveliness, a 32-bit sequence number MUST be presented with each R-
U-THERE message. A responder to an R-U-THERE message MUST send an U-THERE message. A responder to an R-U-THERE message MUST send an
R-U-THERE-ACK with the same sequence number. Upon receipt of the R- R-U-THERE-ACK with the same sequence number. Upon receipt of the R-
U-THERE-ACK message, the initial sender SHOULD check the validity of U-THERE-ACK message, the initial sender SHOULD check the validity of
the sequence number. The initial sender SHOULD reject the R-U- the sequence number. The initial sender SHOULD reject the R-U-
THERE-ACK if the sequence number fails to match the one sent with THERE-ACK if the sequence number fails to match the one sent with
the R-U-THERE message. the R-U-THERE message.
Huang, Beaulieu, Rochefort Expires January 2004 9 Huang, Beaulieu, Rochefort Expires April 2004 9
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
Additionally, both the receiver of the R-U-THERE and the R-U-THERE- Additionally, both the receiver of the R-U-THERE and the R-U-THERE-
ACK message SHOULD check the validity of the Initiator and Responder ACK message SHOULD check the validity of the Initiator and Responder
cookies presented in the SPI field of the payload. cookies presented in the SPI field of the payload.
7.2 Selection and Maintenance of Sequence Numbers 7.2 Selection and Maintenance of Sequence Numbers
As both DPD peers can initiate a DPD exchange (i.e., both peers can As both DPD peers can initiate a DPD exchange (i.e., both peers can
send R-U-THERE messages), each peer MUST maintain its own sequence send R-U-THERE messages), each peer MUST maintain its own sequence
number for R-U-THERE messages. The first R-U-THERE message sent in number for R-U-THERE messages. The first R-U-THERE message sent in
skipping to change at line 544 skipping to change at line 544
assurance of the peer's liveliness. As long as a receiver verifies assurance of the peer's liveliness. As long as a receiver verifies
the validity of a DPD R-U-THERE message (by verifying its the validity of a DPD R-U-THERE message (by verifying its
incremented sequence number), then the receiver can be assured of incremented sequence number), then the receiver can be assured of
the peer's liveliness by the very fact that the sender initiated the the peer's liveliness by the very fact that the sender initiated the
query. Nonces, by contrast, cannot provide this assurance. query. Nonces, by contrast, cannot provide this assurance.
9. IANA Considerations 9. IANA Considerations
There is no IANA action required for this draft. DPD uses notify There is no IANA action required for this draft. DPD uses notify
numbers from the private range. numbers from the private range.
Huang, Beaulieu, Rochefort Expires January 2004 10 Huang, Beaulieu, Rochefort Expires April 2004 10
A Traffic-Based Method of Detecting Dead IKE Peers June 2003 A Traffic-Based Method of Detecting Dead IKE Peers June 2003
10. References 10. References
1 RFC 2409 Harkins, D. and Carrel, D., "The Internet Key Exchange 1 RFC 2409 Harkins, D. and Carrel, D., "The Internet Key Exchange
(IKE)," November 1998. (IKE)," November 1998.
2 RFC 2401 Kent, S. and Atkinson, R., "Security Architecture for 2 RFC 2401 Kent, S. and Atkinson, R., "Security Architecture for
the Internet Protocol," November 1998. the Internet Protocol," November 1998.
3 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 3 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at line 591 skipping to change at line 591
The IPsec working group can be contacted through the chairs: The IPsec working group can be contacted through the chairs:
Barbara Fraser Barbara Fraser
byfraser@cisco.com byfraser@cisco.com
Cisco Systems, Inc. Cisco Systems, Inc.
Ted T'so Ted T'so
tytso@mit.edu tytso@mit.edu
Massachusetts Institute of Technology Massachusetts Institute of Technology
Huang, Beaulieu, Rochefort Expires January 2004 11 Huang, Beaulieu, Rochefort Expires April 2004 11
 End of changes. 18 change blocks. 
27 lines changed or deleted 27 lines changed or added

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