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:53:31 -0500 [thread overview]
Message-ID: <0a5001c261b9$541d3700$c6b22543@repligate> (raw)
In-Reply-To: 20020921135239.CIIH27185.mta03-svc.ntlworld.com@there
> 16 bits - fragment identifier
http://ipv8.dyn.ee/INFO/Papers/RIFRAF/
----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Saturday, September 21, 2002 8:52 AM
Subject: Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits
> On Saturday 21 September 2002 2:25 pm, Jim Fleming wrote:
>
> > There are 160 bits in the IPv4 header, all can be considered for routing
> > purposes.
>
> 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:
>
> 4 bits - header length
> 16 bits - fragment identifier
> 13 bits - fragmentation offset
> 16 bits - header checksum
>
> Of the remaining 111 bits, even these 28 would be a challenge to use
> intelligently for routing, I think ?
>
> 4 bits - IP version no
> 16 bits - total packet length
> 8 bits - time to live
>
> The length and the ttl might make sense as numeric values, but not as
> bitmasks for routing decisions.
>
> I think it's much fairer to say that of the 160 bits in the IPv4 header, 83
> of them make sense for routing purposes:
>
> 8 bits - type of service
> 3 bits - fragmentation flags
> 8 bits - protocol identifier
> 32 bits - source address
> 32 bits - destination address
>
> Antony.
>
> --
>
> This is not a rehearsal.
> This is Real Life.
>
>
next prev parent reply other threads:[~2002-09-21 21:53 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 [this message]
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
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='0a5001c261b9$541d3700$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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.