draft-ietf-secsh-connect-23.txt   draft-ietf-secsh-connect-24.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: June 9, 2005 December 9, 2004 Expires: August 21, 2005 February 17, 2005
SSH Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-23.txt draft-ietf-secsh-connect-24.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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 June 9, 2005. This Internet-Draft will expire on August 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. services over an insecure network.
This document describes the SSH Connection Protocol. It provides This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel. channels are multiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of the The SSH Connection Protocol has been designed to run on top of the
SSH transport layer and user authentication protocols. SSH transport layer and user authentication protocols.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Global Requests . . . . . . . . . . . . . . . . . . . . . . . 3 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . . 4
5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . 5 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . 5
5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . 8 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . 8
5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . 8 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . 9
6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . 9 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . 10
6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . 9 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . 10
6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . 10 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . 10
6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . 10 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . 11
6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . 10 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . 11
6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . 11 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . 11
6.4 Environment Variable Passing . . . . . . . . . . . . . . . 11 6.4 Environment Variable Passing . . . . . . . . . . . . . . . 12
6.5 Starting a Shell or a Command . . . . . . . . . . . . . . 12 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . 12
6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . 13 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . 13
6.7 Window Dimension Change Message . . . . . . . . . . . . . 13 6.7 Window Dimension Change Message . . . . . . . . . . . . . 13
6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . 13 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . 14
6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . 14 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . 14
7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . 15 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . 16
7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . 15 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . 16
7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . 16 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . 17
8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . 17 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . 18
9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 20 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 12.1 Normative References . . . . . . . . . . . . . . . . . . . 21
12.2 Informative References . . . . . . . . . . . . . . . . . . . 21 12.2 Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 23
1. Contributors 1. Contributors
The major original contributors of this set of documents have been: The major original contributors of this set of documents have been:
Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this set of documents and also made very substantial contributions. this set of documents and also made very substantial contributions.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in requirements. These keywords are to be interpreted as described in
[RFC2119]. [RFC2119].
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434]. interpreted as described in [RFC2434].
Protocol fields and possible values to fill them are defined in this
set of documents. Protocol fields will be defined in the message
definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as
follows.
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
Throughout these documents, when the fields are referenced, they will
appear within single quotes. When values to fill those fields are
referenced, they will appear within double quotes. Using the above
example, possible values for 'data' are "foo" and "bar".
4. Global Requests 4. Global Requests
There are several kinds of requests that affect the state of the There are several kinds of requests that affect the state of the
remote end globally, independent of any channels. An example is a remote end globally, independent of any channels. An example is a
request to start TCP/IP forwarding for a specific port. Note that request to start TCP/IP forwarding for a specific port. Note that
both client and server MAY send global requests at any time, and the both client and server MAY send global requests at any time, and the
receiver MUST respond appropriately. All such requests use the receiver MUST respond appropriately. All such requests use the
following format. following format.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
skipping to change at page 6, line 4 skipping to change at page 6, line 17
The 'recipient channel' is the channel number given in the original The 'recipient channel' is the channel number given in the original
open request, and 'sender channel' is the channel number allocated by open request, and 'sender channel' is the channel number allocated by
the other side. the other side.
byte SSH_MSG_CHANNEL_OPEN_FAILURE byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 recipient channel uint32 recipient channel
uint32 reason code uint32 reason code
string description in ISO-10646 UTF-8 encoding [RFC3629] string description in ISO-10646 UTF-8 encoding [RFC3629]
string language tag as defined in [RFC3066] string language tag as defined in [RFC3066]
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
the specified 'channel type', it simply responds with the specified 'channel type', it simply responds with
SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description' SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description'
string to the user. If this is done, the client software should take string to the user. If this is done, the client software should take
the precautions discussed in [SSH-ARCH]. the precautions discussed in [SSH-ARCH].
The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in
the following table. Note that the values for the 'reason code' are the following table. Note that the values for the 'reason code' are
given in decimal format for readability but that they are actually given in decimal format for readability but that they are actually
uinit32 values. uint32 values.
description reason code Symbolic name reason code
----------- ----------- ------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2 SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4 SSH_OPEN_RESOURCE_SHORTAGE 4
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
values (and associated 'description' text) in the range of 0x00000005 values (and associated 'description' text) in the range of 0x00000005
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as
described in [RFC2434]. The IANA will not assign Channel Connection described in [RFC2434]. The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFE000000 to Failure 'reason code' values in the range of 0xFE000000 to
skipping to change at page 7, line 45 skipping to change at page 8, line 11
byte SSH_MSG_CHANNEL_EXTENDED_DATA byte SSH_MSG_CHANNEL_EXTENDED_DATA
uint32 recipient_channel uint32 recipient_channel
uint32 data_type_code uint32 data_type_code
string data string data
Data sent with these messages consumes the same window as ordinary Data sent with these messages consumes the same window as ordinary
data. data.
Currently, only the following type is defined. Note that the value Currently, only the following type is defined. Note that the value
for the 'data_type_code' is given in decimal format for readability for the 'data_type_code' is given in decimal format for readability
but that the values are actually uinit32 values. but that the values are actually uint32 values.
data data_type_code Symbolic name data_type_code
---- -------------- ------------- --------------
SSH_EXTENDED_DATA_STDERR 1 SSH_EXTENDED_DATA_STDERR 1
Extended Channel Data Transfer 'data_type_code' values MUST be Extended Channel Data Transfer 'data_type_code' values MUST be
assigned sequentially. Requests for assignments of new Extended assigned sequentially. Requests for assignments of new Extended
Channel Data Transfer 'data_type_code' values, and their associated Channel Data Transfer 'data_type_code' values, and their associated
Extended Channel Data Transfer 'data' strings, in the range of Extended Channel Data Transfer 'data' strings, in the range of
0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS 0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS
method as described in [RFC2434]. The IANA will not assign Extended method as described in [RFC2434]. The IANA will not assign Extended
Channel Data Transfer 'data_type_code' values in the range of Channel Data Transfer 'data_type_code' values in the range of
0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer
skipping to change at page 14, line 48 skipping to change at page 15, line 17
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient_channel uint32 recipient_channel
string "exit-status" string "exit-status"
boolean FALSE boolean FALSE
uint32 exit_status uint32 exit_status
The remote command may also terminate violently due to a signal. The remote command may also terminate violently due to a signal.
Such a condition can be indicated by the following message. A zero Such a condition can be indicated by the following message. A zero
'exit_status' usually means that the command terminated successfully. 'exit_status' usually means that the command terminated successfully.
byte SSH_MSG_CHANNEL_REQUEST o byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel o uint32 recipient channel
string "exit-signal" o string "exit-signal"
boolean FALSE o boolean FALSE
string signal name without the "SIG" prefix. o string signal name without the "SIG" prefix.
boolean core dumped o boolean core dumped
string error message in ISO-10646 UTF-8 encoding o string error message in ISO-10646 UTF-8 encoding
string language tag as defined in [RFC3066] o string language tag as defined in [RFC3066]
The 'signal name' is one of the following (these are from [POSIX]) The 'signal name' is one of the following (these are from [POSIX])
ABRT ABRT
ALRM ALRM
FPE FPE
HUP HUP
ILL ILL
INT INT
KILL KILL
skipping to change at page 16, line 9 skipping to change at page 16, line 24
port on the other side be forwarded to the local side, it must port on the other side be forwarded to the local side, it must
explicitly request this. explicitly request this.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward" string "tcpip-forward"
boolean want reply boolean want reply
string address to bind (e.g., "0.0.0.0") string address to bind (e.g., "0.0.0.0")
uint32 port number to bind uint32 port number to bind
The 'address to bind' and 'port number to bind' specify the IP The 'address to bind' and 'port number to bind' specify the IP
address and port to which the socket to be listened is bound. The address or domain name and port to which the socket to be listened is
address should be "0.0.0.0" if connections are allowed from anywhere. bound. Some strings used for the 'address to bind' have special-case
(Note that the client can still filter connections based on semantics.
information passed in the open request.) o "" means that connections are to be accepted on all protocol
families supported by the SSH implementation.
o "0.0.0.0" means to listen on all IPv4 addresses.
o "::" means to listen on all IPv6 addresses.
o "localhost" means to listen on all protocol families supported by
the SSH implementation on loopback addresses only, [RFC3330] and
[RFC3513].
o "127.0.0.1" and "::1" indicate listening on the loopback
interfaces for IPv4 and IPv6 respectively.
Note that the client can still filter connections based on
information passed in the open request.
Implementations should only allow forwarding privileged ports if the Implementations should only allow forwarding privileged ports if the
user has been authenticated as a privileged user. user has been authenticated as a privileged user.
Client implementations SHOULD reject these messages; they are Client implementations SHOULD reject these messages; they are
normally only sent by the client. normally only sent by the client.
If a client passes 0 as port number to bind and has 'want reply' TRUE If a client passes 0 as port number to bind and has 'want reply' TRUE
then the server allocates the next available unprivileged port number then the server allocates the next available unprivileged port number
and replies with the following message, otherwise there is no and replies with the following message, otherwise there is no
skipping to change at page 21, line 8 skipping to change at page 21, line 28
[SSH-ARCH]. Specific to this document, it is RECOMMENDED that [SSH-ARCH]. Specific to this document, it is RECOMMENDED that
implementations disable all the potentially dangerous features (e.g., implementations disable all the potentially dangerous features (e.g.,
agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
key has changed without notice or explanation. key has changed without notice or explanation.
12. References 12. References
12.1 Normative References 12.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Lonvick, C., "SSH Protocol Architecture", I-D Lonvick, C., "SSH Protocol Architecture",
draft-ietf-secsh-architecture-20.txt, December 2004. I-D draft-ietf-secsh-architecture-21.txt, February 2005.
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-22.txt, December 2004. I-D draft-ietf-secsh-transport-23.txt, February 2005.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol",
draft-ietf-secsh-userauth-25.txt, December 2004. I-D draft-ietf-secsh-userauth-26.txt, February 2005.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers",
draft-ietf-secsh-assignednumbers-10.txt, December 2004. I-D draft-ietf-secsh-assignednumbers-11.txt, February
2005.
[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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
12.2 Informative References 12.2 Informative References
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995. Architecture", RFC 1884, December 1995.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[SCHEIFLER] [SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, February 1992. Press ISBN 1555580882, February 1992.
[POSIX] ISO/IEC, 9945-1., "Information technology -- Portable [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable
Operating System Interface (POSIX)-Part 1: System Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) C Language", ANSI/IEE Application Program Interface (API) C Language",
Std 1003.1, July 1996. ANSI/IEE Std 1003.1, July 1996.
Author's Address Author's Address
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com Email: clonvick@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 23, line 46 skipping to change at page 23, line 46
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/