RFC 2090

TFTP Multicast Option

📅 published February 1997, from ietf

RFC 2090: TFTP Multicast Option 🎀

okay bestie, RFC 2090 is giving TFTP Multicast Option ✨ It was written by A. Emberson (A. Thomas Emberson) at Lanworks Technologies Inc. in February 1997. It's marked Experimental, so it's an Experimental Protocol and not an Internet standard. It doesn't list anything it obsoletes or updates, so it's a clean slate 🧚

Here are the author's contact details too: Phone (905) 238-5528 and EMail tom@lanworks.com 📮

Status of this Memo

okay so this memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard of any kind. The authors are literally asking for discussion and suggestions for improvement 🫶 Distribution of this memo is unlimited 🌈

Abstract

okay so TFTP [1] is a simple, lock-step file transfer protocol. A client can use it to get a file from a remote host or put a file onto one 💖

This document adds a brand new TFTP option 🦋 With it, multiple clients can receive the same file at the same time using Multicast packets. The TFTP Option Extension mechanism is described in [2].

Picture this: a bunch of similar computers booting up remotely, and they each need to download the same image file 😭 Multicast in the TFTP option set means two or more computers can download one file concurrently, which makes the network way more efficient 💅

This document assumes you already know the terminology and notation from both [1] and [2] 📚

Multicast Option Specification

the TFTP Read Request packet gets modified to include the multicast option, and it looks like this 👑

   +--------+----~~----+---+--~~--+---+-----------+---+---+
   |  opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
   +--------+----~~----+---+--~~--+---+-----------+---+---+
  • opc: the opcode field holds a 1, for Read Requests, as defined in [1] 🍓
  • filename: the name of the file to be read, as defined in [1]. This is a NULL-terminated field 📄
  • mode: the transfer mode, which is "netascii", "octet", or "mail", as defined in [1]. This is a NULL-terminated field 🧚
  • multicast: a request for multicast transmission of the file option, written as "multicast" (case insensitive). This is a NULL-terminated field. The value for this option request is a string of zero length 🌸

If the server is willing to accept the multicast option, it sends an Option Acknowledgment (OACK) to the client that includes the multicast option, as defined in [2] 💜 The OACK tells the client the multicast address, and it has a flag that says whether that client should send block acknowledgments (ACK) 🦋

     +-------+-----------+---+-------~~-------+---+
     |  opc  | multicast | 0 | addr, port, mc | 0 |
     +-------+-----------+---+-------~~-------+---+
  • opc: the opcode field holds the number 6, for Option Acknowledgment, as defined in [2] ✨
  • multicast: acknowledges the multicast option. This is a NULL-terminated field 🫶
  • addr: the multicast IP address. This field is terminated with a comma 🌐
  • port: the destination port of the multicast packets. Using Registered Port number 1758 (tftp-mcast) is recommended. This field is terminated with a comma 🎀
  • mc: either 0 or 1, which tells the client whether it's the master client, meaning it's responsible for sending ACKs to the server. This is a NULL-terminated field 👑

Data Transfer

once the client gets the OACK, it sends an ACK for packet zero, like in [2] 🌈 Since the multicast option was accepted, this ACK tells the server the client wants the first packet. Basically, the ACKs now work as requests for the n+1th block of data 💅 That means each client can ask for any block in the file that it might be missing 😭

the server keeps a list of clients 📋 Usually the oldest client on that list, called the Master Client from here on, is in charge of sending ACKs. When the master client is finished, the server sends another OACK to the next oldest client, telling it to start sending ACKs. When that new master client gets the OACK, it sends an ACK for the block right before the first block it needs to finish its download 🧚

any later clients can start receiving blocks partway through a transfer, then request whatever blocks they missed once they become the master client 🦋 When the current master client is done, the server notifies the next client with an OACK to make it the new master client. The new master client can then start requesting missed packets 🫶 Every client must end the transfer by sending an acknowledgment of the last packet, or by sending an error message to the server. This can happen even if the client isn't the master client 💀

Any later OACKs to a client might have empty multicast address and port fields, since that client already has this info 🍓 If a client doesn't respond in a timely manner to an OACK that makes it the master client, the server shall pick the next oldest client to be the master client. The server shall try sending the OACK to the non-responding client again once the new master client is finished. The server may stop talking to a client after a reasonable number of attempts 🙈

each transfer gets its own multicast address to distribute the data packets 🌸 There can be multiple servers on one network, or a server might only have a limited number of addresses, so more than one transfer might end up using the same multicast address 😭 To make sure a client only accepts the right packets, each transfer must use a unique port on the server. The source IP address and port number identify the data packets for that transfer. So the server must send the unicast OACK packet to the client using the same port it'll use for the multicast data packets 👑

If any client other than the master client sends an ACK to the server, the server responds with another OACK whose mc field is zero 💅 If that client keeps sending bad ACKs, the server may send an error packet to it, which ends the file transfer for that client 🚫

The server may also send unicast packets to a lone client, which cuts down the bad effects on other machines 🌈 Machines might otherwise be forced to process loads of extra multicast packets just to receive a single multicast address 🫠

Example

here's the whole exchange, with clients C1, C2, and C3 and the server M 🎀

           clients                                      server  message
           ------------------------------------------------------------
    1  C1  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
    2                C1 <- |6|multicast|224.100.100.100,1758,1|  OACK
    3  C1  |4|0| ->                                              ACK
    4                          M <- |3|1|1| 512 octets of data|  DATA
    5  C1  |4|1| ->                                              ACK
    6                          M <- |3|2|1| 512 octets of data|  DATA
    7  C2  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
    8                C2 <- |6|multicast|224.100.100.100,1758,0|  OACK
    9  C2  |4|0| ->                                              ACK
   10  C1  |4|2| ->                                              ACK
   11                          M <- |3|3|1| 512 octets of data|  DATA
   12  C3  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
   13                C3 <- |6|multicast|224.100.100.100,1758,0|  OACK
   14  C1  |4|3| ->                                              ACK
   15  C2  |4|0| ->                                              ACK
   16              M (except C2) <- |3|4|1| 512 octets of data|  DATA
   17  C1  |4|4| ->                                              ACK
   18                          M <- |3|5|1| 512 octets of data|  DATA
   19  C1  |4|5| ->                                              ACK
   20                          M <- |3|6|1| 100 octets of data|  DATA
   21  C1  |4|6| ->                                              ACK
   22                                   C2 <- |6|multicast|,,1|  OACK
   23  C2  |4|0| ->                                              ACK
   24                          M <- |3|1|1| 512 octets of data|  DATA
   25  C2  |4|1| ->                                              ACK
   26                          M <- |3|2|1| 512 octets of data|  DATA
   27  C2  |4|3| ->                                              ACK
   28                          M <- |3|4|1| 512 octets of data|  DATA
   29  C2  |4|6| ->                                              ACK
   30                                   C3 <- |6|multicast|,,1|  OACK
   31  C3  |4|2| ->                                              ACK
   32                          M <- |3|3|1| 512 octets of data|  DATA
   33  C3  |4|6| ->                                              ACK

the comments that go with the steps above 🧠

  • 1: request from client 1
  • 2: option acknowledgment
  • 3: acknowledgment for the option acknowledgment, or a request for the first block of data
  • 4: first data packet sent to the multicast address
  • 7: request from client 2
  • 8: option acknowledgment to client 2, send no acknowledgments
  • 9: OACK acknowledgment from client 2
  • 15: OACK acknowledgment from client 3
  • 16: client 2 fails to receive a packet
  • 21: client 1 acknowledges receipt of the last block, telling the server it's done
  • 23: option acknowledgment to client 2, which is now the master client
  • 25: client 2 acknowledges with a request for the first block
  • 27: client 2 acknowledges with a request for a missed block
  • 29: client 2 signals it's finished
  • 31: client 3 is the master client and asks for missing blocks
  • 33: client 3 signals it's finished

Conclusion

with the multicast and blocksize [3] options, TFTP can do fast, efficient downloads 🚀 Using TFTP with the multicast option keeps backward compatibility for both clients and servers 💖

Security Considerations

okay, the security stuff: this memo doesn't discuss security issues at all 🙈 Please keep that in mind before you deploy anything 🚨

References

[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, MIT, July 1992. 📘

[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782, Xylogics, Inc., Hewlett Packard Co., March 1995. 📗

[3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783, Xylogics, Inc., Hewlett Packard Co., March 1995. 📙

Author's Address

A. Thomas Emberson 💌

Lanworks Technologies, Inc.

2425 Skymark Avenue, Mississauga, Ontario, Canada L4W 4Y6

Phone: (905) 238-5528

EMail: tom@lanworks.com

📦 where this page comes from