Re: tftp protocol

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 16 Oct 2009 22:56:55 +0200 (CEST)
    From:        Havard Eidnes <he%uninett.no@localhost>
    Message-ID:  <20091016.225655.89265735.he%uninett.no@localhost>

  | Actually...  I suspect that the BUGS statement is in actual fact
  | wrong, if it implies that the protocol spec makes it impossible
  | to transfer files larger than 32MiB using tftp with the default
  | block size of 512 bytes.

Which is correct, it does, it just doesn't say it explicitly - but there
is nothing in rfc738 to suggest that it is possible for block numbers to
wrap around.

  | The "block numbers" in the tftp protocol are actually not
  | designed to do "random access" in the server-side file, it's
  | designed to distinguish between duplicate blocks and new blocks
  | at the client.

This is an assumption, nothing in rfc738 says that.   But even assuming
what you say were to be correct, then that doesn't allow block numbers
to be reused, if they are, tftp has no long delayed dup packet protection.

That is, consider a data packet N, transmitted, and "lost" somewhere in the
network (queued, for a long time).   IP (v4) allows that to be up to 4.25
minutes (if the original TTL were 255, which it might be, TFTP explicitly
says it doesn't constrain any of the values of the IP header).  The
intended recipient of that packet fails to get it within a reasonable time 
(few seconds) and requests a retransmit, which happens.   After that
all the remaining packets flow again, until we're just about to reuse block 
number N, when that long delayed packet shows up, containing block number
N, just after the (re-used) block number N-1 was received.   How is the
recipient supposed to know it is a duplicate, and wait for the other copy
of the next-time around block N instead?

The probability of this happening might be low, perhaps low enough for cisco
to get away with a gross hack, but it certainly isn't the TFTP protocol.

(Aside: this is certainly possible - with a RTT of 1ms (allows a few typical
ethernet hops) 65535 blocks take just 65.6 seconds to transfer, wrap around,
if permitted, would occur well within the possible lifetime of a delayed
IP packet.)

What's more, wraparound would require another invention - that is, what
number comes next after 65535?   The spec says "block numbers on data packets
begin with one and increase by one for each new block" - zero is only
used as an ACK of a WRQ ... if the sequence is 65534 65535 0 1 2 then you've
just used a block number the spec says doesn't exist, if the sequence is
65534 65535 1 2 3 then you've just been very creative with the concept of
wraparound, and you wouldn't expect that to be implementable without being
very carefully spelled out in the spec.

Next, think to what the original intent was - tftp was invented in the late
1970's (IEN-133 is dated January 1980, so it certainly existed before that.)
Back then, it was uncommon for an entire filestore to be much bigger than
32MB ("huge" 300MB disk drives were not all that long available.)  To
even imagine that anyone was concerned about the need to transfer a single
file > 32MB using this protocol, and consequently designed it to be able
to do that, is absurd.

Lastly, using TFTP to transfer files this big is not rational, even today.
TFTP is a very slow file transfer protocol (512 bytes/RTT max, regardless of
available bandwidth).   If you're going to be transferring very big files
(like cisco IOS images) it would make far more sense to use TFTP to
download a simple file copy application (including a TCP implementation)
and then use that to transfer the big file - even with the extra overhead
of downloading the TTCP and file transfer protocol (which could be anything)
that's going to result in a faster, and more reliable, transfer mechanism
than using TFTP file files this big.

That's why ...

  | The RFCs specifying the block size extension mention speed as a
  | motivation for the extension, not the ability to transfer files
  | larger than 32MiB...

as if you make the blocks twice as big, TFTP runs twice as fast, which
is useful, being able to transfer files bigger than 32MB just wasn't
an objective.

kre

ps: if we need more confirmation of this, we can just ask Noel Chiappa, who
is credited in rfc738 as the inventor of TFTP.