From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antony Stone Subject: Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits Date: Sat, 21 Sep 2002 14:52:35 +0100 Sender: netfilter-admin@lists.netfilter.org Message-ID: <20020921135239.CIIH27185.mta03-svc.ntlworld.com@there> References: <0a3801c26172$51f71af0$c6b22543@repligate> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <0a3801c26172$51f71af0$c6b22543@repligate> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org 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.