From: "Jim Fleming" <JimFleming@ameritech.net>
To: Antony Stone <Antony@Soft-Solutions.co.uk>,
netfilter@lists.netfilter.org
Subject: Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits
Date: Sat, 21 Sep 2002 16:56:03 -0500 [thread overview]
Message-ID: <0a5401c261b9$ae9e01f0$c6b22543@repligate> (raw)
In-Reply-To: 20020921135239.CIIH27185.mta03-svc.ntlworld.com@there
----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> I think that is an extreme ( = unreasonable ) point of view.
>
> Of the 160 bits in an IPv4 header, I really do not see how you could
> reasonably use these 49 for routing purposes:
>
> 16 bits - fragment identifier
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
September 1981
Identification
"The choice of the Identifier for a datagram is based on the need to
provide a way to uniquely identify the fragments of a particular
datagram. The protocol module assembling fragments judges fragments
to belong to the same datagram if they have the same source,
destination, protocol, and Identifier. Thus, the sender must choose
the Identifier to be unique for this source, destination pair and
protocol for the time the datagram (or any fragment of it) could be
alive in the internet.
It seems then that a sending protocol module needs to keep a table
of Identifiers, one entry for each destination it has communicated
with in the last maximum packet lifetime for the internet.
However, since the Identifier field allows 65,536 different values,
some host may be able to simply use unique identifiers independent
of destination.
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment."
next prev parent reply other threads:[~2002-09-21 21:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-20 12:23 Iptables bandwidth limit Rob Sterenborg
2002-09-20 12:35 ` Andrei Ivanov
2002-09-20 19:46 ` Oskar Andreasson
2002-09-21 13:25 ` Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits Jim Fleming
2002-09-21 13:38 ` Andrei Ivanov
2002-09-21 13:52 ` Antony Stone
2002-09-21 21:53 ` Jim Fleming
2002-09-21 21:59 ` Antony Stone
2002-09-21 23:15 ` Jim Fleming
2002-09-22 8:21 ` Antony Stone
2002-09-22 10:25 ` Sascha Reissner
2002-09-22 10:35 ` Antony Stone
2002-09-22 13:54 ` Jim Fleming
2002-09-22 13:35 ` Jim Fleming
2002-09-22 13:48 ` Antony Stone
2002-09-22 14:15 ` Sascha Reissner
2002-09-22 14:20 ` Antony Stone
2002-09-22 15:18 ` Jim Fleming
2002-09-22 14:39 ` Jim Fleming
2002-09-21 21:56 ` Jim Fleming [this message]
2002-09-21 22:01 ` Antony Stone
2002-09-21 22:57 ` Jim Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='0a5401c261b9$ae9e01f0$c6b22543@repligate' \
--to=jimfleming@ameritech.net \
--cc=Antony@Soft-Solutions.co.uk \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox