SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP, Telnet, or rlogin, SSH encrypts the login session, rendering the connection difficult for. The following example would connect client network 10.0.50.0/24 with remote network 10.0.99.0/24 using a point-to-point connection from 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway to the remote network, at 192.168.1.15, allows it. Ssh Connection Timeout 3 By setting these options, one can control ssh/sftp timeout. Re: ssh: connect to host xxxxx port 22: Connection timed out the server is located in the University. In those cases, connection and data exchange is made by way of a ssh proxy which handles the actual connection to the outside network (internet).
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Free
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Download
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Tool
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Pdf
Network Working Group | T. Ylonen |
Internet-Draft | T. Kivinen |
Expires: March 21, 2003 | SSH Communications Security Corp |
M. Saarinen | |
University of Jyvaskyla | |
T. Rinne | |
S. Lehtinen | |
SSH Communications Security Corp | |
September 20, 2002 |
draft-ietf-secsh-connect-16.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance withall provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2003.
Copyright Notice
Copyright © The Internet Society (2002). All RightsReserved.
Abstract
SSH is a protocol for secure remotelogin and other secure network services over an insecure network.
This document describes the SSH Connection Protocol. It providesinteractive login sessions, remote execution of commands, forwardedTCP/IPconnections, and forwarded X11 connections. All of these channels aremultiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols.
Table of Contents
- Channel Mechanism
- Interactive Sessions
- X11 Forwarding
- TCP/IP Port Forwarding
- Additional Information
References
Authors' Addresses
Full Copyright Statement
1. Introduction
The SSH Connection Protocol hasbeen designed to run on top of the SSH transport layer and userauthentication protocols. It provides interactive login sessions,remote execution of commands, forwarded TCP/IPconnections, and forwarded X11 connections. The service name for thisprotocol (after user authentication) is 'ssh-connection'.
This document should be read only after reading the SSH architecturedocument [SSH-ARCH]. This document freelyuses terminology and notation from the architecture document withoutreference or further explanation.
2. Global Requests
There are several kinds of requests that affect the state of theremote end 'globally', independent of any channels. An example is arequest to start TCP/IP forwarding for a specific port. All suchrequests use the following format.
Request names follow the DNSextensibility naming convention outlined in [SSH-ARCH].
The recipient will respond to this message with
SSH_MSG_REQUEST_SUCCESS
orSSH_MSG_REQUEST_FAILURE
if `want reply'
isTRUE
.Vssh 1 11 1 – Ssh Protocol Connectivity Tools Free
Usually the response specific data is non-existent.
If the recipient does not recognize or support the request, it simplyresponds with
SSH_MSG_REQUEST_FAILURE
.3. Channel Mechanism
All terminal sessions, forwarded connections, etc. are channels.Either side may open a channel. Multiple channels are multiplexed intoa single connection.
Channels are identified by numbers at each end. The number referringto a channel may be different on each side. Requests to open a channelcontain the sender's channel number. Any other channel-relatedmessages contain the recipient's channel number for the channel.
Channels are flow-controlled. No data may be sent to a channel untila message is received to indicate that window space is available.
3.1 Opening a Channel
When either side wishes to open a new channel, it allocates a localnumber for the channel. It then sends the following message to theother side, and includes the local channel number and initial windowsize in the message.
The channel type is a name as described in the SSH architecturedocument, with similar extension mechanisms.
`senderchannel'
is a local identifier for the channel used by the senderof this message. `initial window size'
specifies how manybytes of channel data can be sent to the sender of this message withoutadjusting the window. `Maximum packet size'
specifies themaximum size of an individual data packet that can be sent to the sender(for example, one might want to use smaller packets for interactiveconnections to get better interactive response on slow links).The remote side then decides whether it can open the channel, andresponds with either
where
`recipient channel'
is the channel number given inthe original open request, and `sender channel'
is thechannel number allocated by the other side, orIf the recipient of the
SSH_MSG_CHANNEL_OPEN
messagedoes not support the specified channel type, it simply responds withSSH_MSG_CHANNEL_OPEN_FAILURE
. The client MAY show theadditional information to the user. If this is done, the clientsoftware should take the precautions discussed in [SSH-ARCH].The following reason codes are defined:
3.2 Data Transfer
The window size specifies how many bytes the other party can sendbefore it must wait for the window to be adjusted. Both parties use thefollowing message to adjust the window.
After receiving this message, the recipient MAY send the given numberof bytes more than it was previously allowed to send; the window size isincremented.
Data transfer is done with messages of the following type.
The maximum amount of data allowed is the current window size. Thewindow size is decremented by the amount of data sent. Both parties MAYignore all extra data sent after the allowed window is empty.
Additionally, some channels can transfer several types of data. Anexample of this is stderr data from interactive sessions. Such data canbe passed with
SSH_MSG_CHANNEL_EXTENDED_DATA
messages,where a separate integer specifies the type of the data. The availabletypes and their interpretation depend on the type of the channel.Data sent with these messages consumes the same window as ordinarydata.
Currently, only the following type is defined.
3.3 Closing a Channel
When a party will no longer send more data to a channel, it SHOULDsend
SSH_MSG_CHANNEL_EOF
.No explicit response is sent to this message; however, theapplication may send EOF towhatever is at the other end of the channel. Note that the channelremains open after this message, and more data may still be sent in theother direction. This message does not consume window space and can besent even if no window space is available.
When either party wishes to terminate the channel, it sends
SSH_MSG_CHANNEL_CLOSE
. Upon receiving this message, aparty MUST send back a SSH_MSG_CHANNEL_CLOSE
unless it hasalready sent this message for the channel. The channel is consideredclosed for a party when it has both sent and receivedSSH_MSG_CHANNEL_CLOSE
, and the party may then reuse thechannel number. A party MAY send SSH_MSG_CHANNEL_CLOSE
without having sent or received SSH_MSG_CHANNEL_EOF
.This message does not consume window space and can be sent even if nowindow space is available.
It is recommended that any data sent before this message is deliveredto the actual destination, if possible.
3.4 Channel-SpecificRequests
Many channel types have extensions that are specific to thatparticular channel type. An example is requesting a pty (pseudoterminal) for an interactive session.
All channel-specific requests use the following format.
If
want reply
is FALSE
, no response will besent to the request. Otherwise, the recipient responds with eitherSSH_MSG_CHANNEL_SUCCESS
orSSH_MSG_CHANNEL_FAILURE
, or request-specific continuationmessages. If the request is not recognized or is not supported for thechannel, SSH_MSG_CHANNEL_FAILURE
is returned.This message does not consume window space and can be sent even if nowindow space is available. Request types are local to each channeltype.
The client is allowed to send further messages without waiting forthe response to the request.
request type names follow the DNS extensibility naming conventionoutlined in [SSH-ARCH]
These messages do not consume window space and can be sent even if nowindow space is available.
4. Interactive Sessions
A session is a remote execution of a program. The program may be ashell, an application, a system command, or some built-in subsystem. Itmay or may not have a tty, and may or maynot involve X11 forwarding. Multiple sessions can be activesimultaneously.
4.1 Opening a Session
A session is started by sending the following message.
Client implementations SHOULD reject any session channel openrequests to make it more difficult for a corrupt server to attack theclient.
4.2 Requesting aPseudo-Terminal
A pseudo-terminal can be allocated for the session by sending thefollowing message.
The encoding of terminal modes is described in Section Encoding ofTerminal Modes (Section 6). Zero dimensionparameters MUST be ignored. The character/row dimensions override thepixel dimensions (when nonzero). Pixel dimensions refer to the drawablearea of the window.
The dimension parameters are only informational.
The client SHOULD ignore pty requests.
4.3 X11 Forwarding
4.3.1 Requesting X11Forwarding
X11 forwarding may be requested for a session by sending
It is recommended that the authentication cookie that is sent be afake, random cookie, and that the cookie is checked and replaced by thereal cookie when a connection request is received.
X11 connection forwarding should stop when the session channel isclosed; however, already opened forwardings should not be automaticallyclosed when the session channel is closed.
If
`single connection'
is TRUE
, only asingle connection should be forwarded. No more connections will beforwarded after the first, or after the session channel has beenclosed.The
`x11 authentication protocol'
is the name of the X11authentication method used, e.g. 'MIT-MAGIC-COOKIE-1'
.The
x11 authentication cookie
MUST be hexadecimalencoded.X Protocol is documented in [SCHEIFLER].
4.3.2 X11 Channels
X11 channels are opened with a channel open request. The resultingchannels are independent of the session, and closing the session channeldoes not close the forwarded X11 channels.
The recipient should respond with
SSH_MSG_CHANNEL_OPEN_CONFIRMATION
orSSH_MSG_CHANNEL_OPEN_FAILURE
.Implementations MUST reject any X11 channel open requests if theyhave not requested X11 forwarding.
4.4 Environment VariablePassing
Environment variables may be passed to the shell/command to bestarted later. Uncontrolled setting of environment variables in aprivileged process can be a security hazard. It is recommended thatimplementations either maintain a list of allowable variable names oronly set environment variables after the server process has droppedsufficient privileges.
4.5 Starting a Shell or aCommand
Once the session has been set up, a program is started at the remoteend. The program can be a shell, an application program or a subsystemwith a host-independent name. Only one of these requests can succeedper channel.
This message will request the user's default shell (typically definedin
/etc/passwd
in UNIX systems) to be started at the otherend.This message will request the server to start the execution of thegiven command. The command string may contain a path. Normalprecautions MUST be taken to prevent the execution of unauthorizedcommands.
This last form executes a predefined subsystem. It is expected thatthese will include a general file transfer mechanism, and possibly otherfeatures. Implementations may also allow configuring more suchmechanisms. As the user's shell is usually used to execute thesubsystem, it is advisable for the subsystem protocol to have a 'magiccookie' at the beginning of the protocol transaction to distinguish itfrom arbitrary output generated by shell initialization scripts etc.This spurious output from the shell may be filtered out either at theserver or at the client.
The server SHOULD not halt the execution of the protocol stack whenstarting a shell or a program. All input and output from these SHOULDbe redirected to the channel or to the encrypted tunnel.
It is RECOMMENDED to request and check the reply for these messages.The client SHOULD ignore these messages.
Subsystem names follow the DNS extensibility naming conventionoutlined in [SSH-ARCH].
4.6 Session Data Transfer
Data transfer for a session is done using
SSH_MSG_CHANNEL_DATA
andSSH_MSG_CHANNEL_EXTENDED_DATA
packets and the windowmechanism. The extended data type SSH_EXTENDED_DATA_STDERR
has been defined for stderr data.4.7 Window Dimension ChangeMessage
When the window (terminal) size changes on the client side, it MAYsend a message to the other side to inform it of the new dimensions.
No response SHOULD be sent to this message.
4.8 Local Flow Control
On many systems, it is possible to determine if a pseudo-terminal isusing control-S/control-Q flow control. When flow control is allowed,it is often desirable to do the flow control at the client end to speedup responses to user requests. This is facilitated by the followingnotification. Initially, the server is responsible for flow control.(Here, again, client means the side originating the session, and servermeans the other side.)
The message below is used by the server to inform the client when itcan or cannot perform flow control (control-S/control-Q processing). If
`client can do'
is TRUE, the client is allowed to do flowcontrol using control-S and control-Q. The client MAY ignore thismessage.No response is sent to this message.
4.9 Signals
A signal can be delivered to the remote process/service using thefollowing message. Some systems may not implement signals, in whichcase they SHOULD ignore this message.
Signal names will be encoded as discussed in the'
exit-signal
' SSH_MSG_CHANNEL_REQUEST
.4.10 Returning ExitStatus
When the command running at the other end terminates, the followingmessage can be sent to return the exit status of the command. Returningthe status is RECOMMENDED. No acknowledgment is sent for this message.The channel needs to be closed with
SSH_MSG_CHANNEL_CLOSE
after this message.The client MAY ignore these messages.
The remote command may also terminate violently due to a signal.Such a condition can be indicated by the following message. A zeroexit_status usually means that the command terminated successfully.
The signal name is one of the following (these are from [POSIX])
Additional signal names MAY be sent in the format'
sig-name@xyz
', where `sig-name'
and`xyz'
may be anything a particular implementor wants(except the `@'
sign). However, it is suggested that if a`configure'
script is used, the non-standard signal namesit finds be encoded as '[email protected]
', where`SIG'
is the signal name without the 'SIG
'prefix, and `xyz'
be the host type, as determined by`config.guess'
.The
`error message'
contains an additional explanationof the error message. The message may consist of multiple lines. Theclient software MAY display this message to the user. If this is done,the client software should take the precautions discussed in [SSH-ARCH].5. TCP/IP Port Forwarding
![Vssh 1 11 1 – ssh protocol connectivity tools free Vssh 1 11 1 – ssh protocol connectivity tools free](https://nmac.to/wp-content/uploads/2014/04/vSSH.png)
5.1 Requesting PortForwarding
A party need not explicitly request forwardings from its own end tothe other direction. However, if it wishes that connections to a porton the other side be forwarded to the local side, it must explicitlyrequest this.
`Address to bind'
and `port number to bind'
specify the IP address andport to which the socket to be listened is bound. The address should be'0.0.0.0' if connections are allowed from anywhere. (Note that theclient can still filter connections based on information passed in theopen request.)Implementations should only allow forwarding privileged ports if theuser has been authenticated as a privileged user.
Client implementations SHOULD reject these messages; they arenormally only sent by the client.
If a client passes 0 as port number to bind and has want reply
TRUE
then the server allocates the next availableunprivileged port number and replies with the following message,otherwise there is no response specific data.A port forwarding can be cancelled with the following message. Notethat channel open requests may be received until a reply to this messageis received.
Client implementations SHOULD reject these messages; they arenormally only sent by the client.
5.2 TCP/IP ForwardingChannels
When a connection comes to a port for which remote forwarding hasbeen requested, a channel is opened to forward the port to the otherside.
Implementations MUST reject these messages unless they havepreviously requested a remote TCP/IPport forwarding with the given port number.
When a connection comes to a locally forwarded TCP/IP port, thefollowing packet is sent to the other side. Note that these messagesMAY be sent also for ports for which no forwarding has been explicitlyrequested. The receiving side must decide whether to allow theforwarding.
`Host to connect'
and `port to connect'
specify the TCP/IP host and port where the recipient should connect thechannel. `Host to connect' may be either a domain name or a numeric IPaddress.`Originator IP address'
is the numeric IP address of themachine where the connection request comes from, and `originatorport'
is the port on the originator host from where theconnection came from.Forwarded TCP/IP channels are independent of any sessions, andclosing a session channel does not in any way imply that forwardedconnections should be closed.
Client implementations SHOULD reject direct TCP/IP open requests forsecurity reasons.
6. Encoding of Terminal Modes
Terminal modes (as passed in a pty request) are encoded into a bytestream. It is intended that the coding be portable across differentenvironments.
The tty mode description is a stream of bytes. The stream consistsof opcode-argument pairs. It is terminated by opcode
TTY_OP_END(0)
. Opcodes 1 to 159 have a single uint32
argument. Opcodes 160 to 255 are not yet defined, and cause parsing tostop (they should only be used after any other data).The client SHOULD put in the stream any modes it knows about, and theserver MAY ignore any modes it does not know about. This allows somedegree of machine-independence, at least between systems that use aPOSIX-like tty interface. The protocol can support other systems aswell, but the client may need to fill reasonable values for a number ofparameters so the server pty gets set to a reasonable mode (the serverleaves all unspecified mode bits in their default values, and only somecombinations make sense).
The following opcodes have been defined. The naming of opcodesmostly follows the POSIX terminal mode flags.
0 TTY_OP_END
Indicates end of options.
1 VINTR
Interrupt character; 255 if none. Similarly for the othercharacters. Not all of these characters are supported on allsystems.
2 VQUIT
The quit character (sends SIGQUIT signal on POSIXsystems).
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Download
3 VERASE
Erase the character to left of the cursor.
4 VKILL
Kill the current input line.
5 VEOF
End-of-file character (sends EOF from the terminal).
6 VEOL
End-of-line character in addition to carriage return and/orlinefeed.
7 VEOL2
Additional end-of-line character.
8 VSTART
Continues paused output (normally control-Q).
9 VSTOP
Pauses output (normally control-S).
10 VSUSP
Suspends the current program.
11 VDSUSP
Another suspend character.
12 VREPRINT
Reprints the current input line.
13 VWERASE
Erases a word left of cursor.
14 VLNEXT
Enter the next character typed literally, even if it is a specialcharacter.
15 VFLUSH
Character to flush output.
16 VSWTCH
Switch to a different shell layer.
17 VSTATUS
Prints system status line (load, command, pid etc).
18 VDISCARD
Toggles the flushing of terminal output.
30 IGNPAR
The ignore parity flag. The parameter SHOULD be 0 if this flagis
FALSE
set, and 1 if it is TRUE
.31 PARMRK
Mark parity and framing errors.
32 INPCK
Enable checking of parity errors.
33 ISTRIP
Strip 8th bit off characters.
34 INLCR
Map NL into CR on input.
35 IGNCR
Ignore CR on input.
36 ICRNL
Map CR to NL on input.
37 IUCLC
Translate uppercase characters to lowercase.
38 IXON
Enable output flow control.
39 IXANY
Any char will restart after stop.
40 IXOFF
Enable input flow control.
41 IMAXBEL
Ring bell on input queue full.
50 ISIG
Enable signals INTR, QUIT, [D]SUSP.
51 ICANON
Canonicalize input lines.
52 XCASE
Enable input and output of uppercase characters by preceding their lowercase equivalents with `'.
53 ECHO
Enable echoing.
54 ECHOE
Visually erase chars.
55 ECHOK
Kill character discards current line.
56 ECHONL
Echo NL even if ECHO is off.
57 NOFLSH
Don't flush after interrupt.
58 TOSTOP
Stop background jobs from output.
59 IEXTEN
Enable extensions.
60 ECHOCTL
Echo control characters as ^(Char).
61 ECHOKE
Visual erase for line kill.
62 PENDIN
Retype pending input.
70 OPOST
Enable output processing.
71 OLCUC
Convert lowercase to uppercase.
72 ONLCR
Map NL to CR-NL.
73 OCRNL
Translate carriage return to newline (output).
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Tool
74 ONOCR
Translate newline to carriage return-newline (output).
75 ONLRET
Newline performs a carriage return (output).
90 CS7
7 bit mode.
91 CS8
8 bit mode.
92 PARENB
Parity enable.
93 PARODD
Odd parity, else even.
128 TTY_OP_ISPEED
Specifies the input baud rate in bits per second.
129 TTY_OP_OSPEED
Specifies the output baud rate in bits per second.
7. Summary of Message Numbers
8. Security Considerations
This protocol is assumed to run on top of a secure, authenticatedtransport. User authentication and protection against network-levelattacks are assumed to be provided by the underlying protocols.
This protocol can, however, be used to execute commands on remotemachines. The protocol also permits the server to run commands on theclient. Implementations may wish to disallow this to prevent anattacker from coming from the server machine to the client machine.
X11 forwarding provides major security improvements over normalcookie-based X11 forwarding. The cookie never needs to be transmittedin the clear, and traffic is encrypted and integrity-protected. Nouseful authentication data will remain on the server machine after theconnection has been closed. On the other hand, in some situations aforwarded X11 connection might be used to get access to the local Xserver across security perimeters.
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Pdf
Port forwardings can potentially allow an intruder to cross securityperimeters such as firewalls. They do not offer anything fundamentallynew that a user could not do otherwise; however, they make openingtunnels very easy. Implementations should allow policy control overwhat can be forwarded. Administrators should be able to denyforwardings where appropriate.
Since this protocol normally runs inside an encrypted tunnel,firewalls will not be able to examine the traffic.
It is RECOMMENDED that implementations disable all the potentiallydangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IPforwarding) if the host key has changed.
9. Intellectual Property
The IETFtakes no position regarding the validity or scope of any intellectualproperty or other rights that might be claimed to pertain to theimplementation or use of the technology described in this document orthe extent to which any license under such rights might or might not beavailable; neither does it represent that it has made any effort toidentify any such rights. Information on the IETF's procedures withrespect to rights in standards-track and standards-related documentationcan be found in BCP-11. Copies of claims of rights made available forpublication and any assurances of licenses to be made available, or theresult of an attempt made to obtain a general license or permission forthe use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF Secretariat.
The IETF has been notified of intellectual property rights claimed inregard to some or all of the specification contained in this document.For more information consult the online list of claimed rights.
10. Additional Information
The current document editor is: [email protected]. Comments onthis internet draft should be sent to the IETF SECSH working group,details at: http://ietf.org/html.charters/secsh-charter.html
References
Alvestrand, H., 'Tags for the Identification of Languages', RFC 1766, March1995.
Hinden, R., Deering, S. and Editors, 'IP Version 6 AddressingArchitecture', RFC1884, December 1995.
Yergeau, F., 'UTF-8, a transformation format of ISO 10646', RFC 2279, January1998.
Scheifler, R., 'X Window System : The Complete Reference to Xlib,X Protocol, Icccm, Xlfd, 3rd edition.', Digital Press ISBN 1555580882,Feburary 1992.
ISO/IEC, 9945-1., 'Information technology -- Portable OperatingSystem Interface (POSIX)-Part 1: System Application Program Interface(API) C Language', ANSI/IEE Std 1003.1, July 1996.
Ylonen, T., 'SSH Protocol Architecture', I-D draft-ietf-architecture-13.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/architecture.html]
Ylonen, T., 'SSH Transport Layer Protocol', I-D draft-ietf-transport-15.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/transport.html]
Ylonen, T., 'SSH Authentication Protocol', I-D draft-ietf-userauth-16.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/userauth.html]
Ylonen, T., 'SSH Connection Protocol', I-D draft-ietf-connect-16.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/connection.html]
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Markku-Juhani O. Saarinen
University of Jyvaskyla
University of Jyvaskyla
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Full CopyrightStatement
Copyright © The Internet Society (2002). All RightsReserved.
This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it orassist in its implementation may be prepared, copied, published anddistributed, in whole or in part, without restriction of any kind,provided that the above copyright notice and this paragraph are includedon all such copies and derivative works. However, this document itselfmay not be modified in any way, such as by removing the copyright noticeor references to the Internet Society or other Internet organizations,except as needed for the purpose of developing Internet standards inwhich case the procedures for copyrights defined in the InternetStandards process must be followed, or as required to translate it intolanguages other than English.
The limited permissions granted above are perpetual and will not berevoked 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 TASKFORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOTINFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY ORFITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by theInternet Society.
This HTMLversion was prepared by Casey Marshall.
Verbatim copying and distribution of this entire article is permittedin any medium.
Please forward any errors, omissions, or other inconsistencies fromthe original Internet-Draft to [email protected].