.ds CF
.ds LH Internet Draft
.ds RH 28 June 2000
-.ds CH SILC Packet Protocol
+.ds CH
.na
.hy 0
.in 0
.in 3
-.ce
+.ce 2
SILC Packet Protocol
+<draft-riikonen-silc-pp-00.txt>
.ti 0
Status of this Memo
-This document is an Internet-Draft. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas,
-and its working groups. Note that other groups may also distribute
-working documents as Internet-Drafts.
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time. It is inappropriate to use Internet-Drafts
-as reference material or to cite them other than as
-``work in progress.''
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
-To learn the current status of any Internet-Draft, please check the
-``1id-abstracts.txt'' listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-ftp.isi.edu (US West Coast).
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
-The distribution of this memo is unlimited.
+The distribution of this memo is unlimited.
.ti 0
2.8 Packet Compression ........................................ 40
2.9 Packet Sending ............................................ 40
2.10 Packet Reception ......................................... 41
- 2.11 Packet Broadcasting ...................................... 41
- 2.12 Packet Routing ........................................... 42
- 2.13 Packet Tunneling ......................................... 42
+ 2.11 Packet Routing ........................................... 42
+ 2.12 Packet Forwarding ........................................
+ 2.13 Packet Broadcasting ...................................... 41
+ 2.14 Packet Tunneling ......................................... 42
3 Security Considerations ....................................... 43
4 References .................................................... 43
5 Author's Address .............................................. 44
Encryption And Decryption for more information.
- Broadcast 0x02
+ Forwarded 0x02
+
+ Marks the packet to be forwarded. Some specific
+ packet types may be forwarded. Receiver of packet
+ with this flag set must not forward the packet any
+ further. See section 2.12 Packet Forwarding for
+ desribtion of packet forwarding.
+
+
+ Broadcast 0x04
Marks the packet to be broadcasted. Client cannot
send broadcast packet and normal server cannot send
set must send (broadcast) the packet to its primary
route. If router has several router connections the
packet may be sent only to the primary route. See
- section 2.11 Packet Broadcasting for description of
+ section 2.13 Packet Broadcasting for description of
packet broadcasting.
- Tunneled 0x04
+ Tunneled 0x08
Marks that the packet is tunneled. Tunneling means
that extra SILC Packet Header has been applied to the
original packet. The outer header has this flag
- set. See section 2.13 Packet Tunneling for more
+ set. See section 2.14 Packet Tunneling for more
information.
.in 3
This is opposite of Success Payload. Indication of failure of
some protocol is sent in the payload.
+
.in 5
.nf
1 2 3
.in 3
+
+
+
.ti 0
2.3.6 Notify Payload
not be sent in any other packet type. Following diagram represents the
Notify Payload.
-
-
-
-
.in 5
.nf
1 2 3
.ti 0
2.3.12 Command Payload
-Command Payload is used to send SILC commands from client to server.
-Following diagram represents the Command Payload.
+Command Payload is used to send SILC commands from client to server.
+Also server may send commands to other servers. Following diagram
+represents the Command Payload.
.in 5
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| SILC Command | Arguments Num | Payload Length |
+| Payload Length | SILC Command | Arguments Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Command Unifier |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
.ce
.in 6
+o Payload Length (2 bytes) - Length of the entire command
+ payload including any command argument payloads associated
+ with this payload.
+
o SILC Command (1 byte) - SILC Command identifier. This must
be set to non-zero value. If zero (0) value is found in this
field the packet must be discarded.
field is set to zero (0). The arguments must follow the
command payload.
-o Payload Length (2 bytes) - Length of the entire command
- payload including any command argument payloads associated
- with this payload.
+o Command Unifier (2 bytes) - Unifies this command at the
+ sender's end. The entity who replies to this command must
+ set the value found from this field into the Command Payload
+ used to send the reply to the sender. This way the sender
+ can identify which command reply belongs to which originally
+ sent command. What this field includes is implementation
+ issue but it is recommended that wrapping counter value is
+ used in the field.
.in 3
See [SILC1] for detailed description of different SILC commands,
.ti 0
2.3.13 Command Reply Payload
-Command Reply Payload is used to send replies to the commands sent
-by the client. The Command Reply Payload is identical to the
-Command Payload hence see the upper sections for Command Payload
-and for Command Argument Payload specifications. Command Reply
-message uses the Command Argument Payload as well.
+Command Reply Payload is used to send replies to the commands. The
+Command Reply Payload is identical to the Command Payload thus see the
+upper sections for Command Payload and for Command Argument Payload
+specifications. Command Reply message uses the Command Argument Payload
+as well.
+
+The entity who sends the reply packet must set the Command Unifier
+field in the reply packet's Command Payload to the value it received
+in the original command packet.
See SILC Commands in [SILC1] for detailed description of different
SILC commands, their arguments and their reply messages.
in the SILC network by sending this packet payload. Channels are
created by router of the cell. Server never creates channels unless
it is a standalone server and it does not have router connection,
-in this case server acts as router. Normal server sends JOIN command
+in this case server acts as router. Normal server forwards JOIN command
to the router (after it has received JOIN command from client) which
then processes the command and creates the channel. Client never sends
this packet.
The sender of the packet must assemble the SILC Packet Header with
correct values. It must set the Source ID of the header as its own
-ID. It must also set the Destination ID of the header to the true
-destination. If the destination is client it will be Client ID, if
-it is server it will be Server ID and if it is channel it will be
-Channel ID.
+ID, unless it is forwarding the packet. It must also set the Destination
+ID of the header to the true destination. If the destination is client
+it will be Client ID, if it is server it will be Server ID and if it is
+channel it will be Channel ID.
If the sender wants to compress the packet it must apply the
compression now. Sender must also compute the padding as described
.ti 0
-2.11 Packet Broadcasting
-
-SILC packets may be broadcasted in SILC network. However, only router
-server may send or receive broadcast packets. Client and normal server
-must not send broadcast packets and they must ignore broadcast packets
-if they receive them. Broadcast packets are sent by setting Broadcast
-flag to the SILC packet header.
-
-Broadcasting packets means that the packet is sent to all routers in
-the SILC network, except to the router that sent the packet. The router
-receiving broadcast packet must send the packet to its primary route.
-The fact that SILC routers may have several router connections may
-cause problems, such as race conditions inside the SILC network, if
-care is not taken when broadcasting packets. Router must not send
-the broadcast packet to any other route except to its primary route.
-
-If the primary route of the router is the original sender of the packet
-the packet must not be sent to the primary route. This may happen
-if router has several router connections and some other router uses
-the router as its primary route.
-
-Routers use broadcast packets to broadcast for example information
-about newly registered clients, servers, channels etc. so that all the
-routers may keep these informations up to date.
-
-
-.ti 0
-2.12 Packet Routing
+2.11 Packet Routing
Routers are the primary entities in the SILC network that takes care
of packet routing. However, normal servers routes packets as well, for
.ti 0
-2.13 Packet Tunneling
+2.12 Packet Forwarding
+
+Currently SILC command packets may be forwarded from one entity to another.
+Any other packet currently cannot be forwarded but support for more packet
+types may be added if needed. Forwarding is usually used by server to
+forward some command request coming from client to the router as the server
+may be incapable to handle the request. Forwarding may be only one hop
+long; the receiver of the packet with Forwarded flag set in the SILC
+Packet header must not forward the packet any further.
+
+The normal scenario is that client sends JOIN command to the server which
+is not able to create the channel as there are no local clients on the
+channel. Channels are created always by the router of the cell thus the
+packet must be forwarded to the router. The server forwards the original
+packet coming from client to the router after it has set the Forwarded
+flag to the SILC Packet header.
+
+Router receiving the packet knows that the packet has to be processed
+specially by checking the flags and the Forwarded flag in the SILC Packet
+header. After router has joined the client to the channel (and perhaps
+created a new channel) it sends normal command reply packet to the
+client. However, as the router doesn't have direct connection to the
+client the packet is sent through the server. Server detects that
+the command reply packet is destined to the client and sends it to
+the client.
+
+
+.ti 0
+2.13 Packet Broadcasting
+
+SILC packets may be broadcasted in SILC network. However, only router
+server may send or receive broadcast packets. Client and normal server
+must not send broadcast packets and they must ignore broadcast packets
+if they receive them. Broadcast packets are sent by setting Broadcast
+flag to the SILC packet header.
+
+Broadcasting packets means that the packet is sent to all routers in
+the SILC network, except to the router that sent the packet. The router
+receiving broadcast packet must send the packet to its primary route.
+The fact that SILC routers may have several router connections may
+cause problems, such as race conditions inside the SILC network, if
+care is not taken when broadcasting packets. Router must not send
+the broadcast packet to any other route except to its primary route.
+
+If the primary route of the router is the original sender of the packet
+the packet must not be sent to the primary route. This may happen
+if router has several router connections and some other router uses
+the router as its primary route.
+
+Routers use broadcast packets to broadcast for example information
+about newly registered clients, servers, channels etc. so that all the
+routers may keep these informations up to date.
+
+
+.ti 0
+2.14 Packet Tunneling
Tunneling is a feature that is available in SILC protocol. Tunneling
means that extra SILC Packet Header is applied to the original packet
Finland
EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires 28 Jan 2001