RE: Iptables bandwidth limit

RE: Iptables bandwidth limit

[Rob Sterenborg]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

> You can almost do this with the limit module, but you should 
> better use
> HTB or CBQ (QOS) which are really done for this.
> 
I first accomplished it with CBQ, but later I switched to HTB which is a lot
easier to configure.


Rob

[-- Attachment #2: Type: text/html, Size: 689 bytes --]

RE: Iptables bandwidth limit

[Andrei Ivanov]

What amazes me is that iptables doesn't know to match packets by a tos 
value other then the ones in ip.h... this really SUCKS.

On Fri, 20 Sep 2002, Rob Sterenborg wrote:

> > You can almost do this with the limit module, but you should 
> > better use
> > HTB or CBQ (QOS) which are really done for this.
> > 
> I first accomplished it with CBQ, but later I switched to HTB which is a lot
> easier to configure.
> 
> 
> Rob
> 

RE: Iptables bandwidth limit

[Oskar Andreasson]

First of all, the limitation was created since you should not use other 
TOS values than specified in the RFC's. You may get extremely strange 
problems if you start doing random TOS matches on packets. 

Anyways, iptables _is_ actually able to do irregular TOS matching with the
ftos patch applied to the kernel (I _think_ it may still be in
patch-o-matic, but I don't know for sure). It should also be available 
somewhere on the www.paktronix.com site.

Have a nice day,



On Fri, 20 Sep 2002, Andrei Ivanov wrote:

> 
> What amazes me is that iptables doesn't know to match packets by a tos 
> value other then the ones in ip.h... this really SUCKS.
> 
> On Fri, 20 Sep 2002, Rob Sterenborg wrote:
> 
> > > You can almost do this with the limit module, but you should 
> > > better use
> > > HTB or CBQ (QOS) which are really done for this.
> > > 
> > I first accomplished it with CBQ, but later I switched to HTB which is a lot
> > easier to configure.
> > 
> > 
> > Rob
> > 
> 
> 
> 

-- 
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

> On Fri, 20 Sep 2002, Andrei Ivanov wrote:
> 
> > 
> > What amazes me is that iptables doesn't know to match packets by a tos 
> > value other then the ones in ip.h... this really SUCKS.
....that appears to be a "political policy" slipped into the software...

There are 160 bits in the IPv4 header, all can be considered for routing purposes.
Some of those bits are more useful than others, especially those controlled via the DNS.

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved ("Spare") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt


Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.netfilter.org/
http://www.analogx.com/contents/dnsdig.htm
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org

----- Original Message ----- 
From: "Oskar Andreasson" <blueflux@koffein.net>
To: "Andrei Ivanov" <andrei.ivanov@ines.ro>
Cc: <netfilter@lists.netfilter.org>
Sent: Friday, September 20, 2002 2:46 PM
Subject: RE: Iptables bandwidth limit


> 
> First of all, the limitation was created since you should not use other 
> TOS values than specified in the RFC's. You may get extremely strange 
> problems if you start doing random TOS matches on packets. 
> 
> Anyways, iptables _is_ actually able to do irregular TOS matching with the
> ftos patch applied to the kernel (I _think_ it may still be in
> patch-o-matic, but I don't know for sure). It should also be available 
> somewhere on the www.paktronix.com site.
> 
> Have a nice day,
> 
> 
> 
> On Fri, 20 Sep 2002, Andrei Ivanov wrote:
> 
> > 
> > What amazes me is that iptables doesn't know to match packets by a tos 
> > value other then the ones in ip.h... this really SUCKS.
> > 
> > On Fri, 20 Sep 2002, Rob Sterenborg wrote:
> > 
> > > > You can almost do this with the limit module, but you should 
> > > > better use
> > > > HTB or CBQ (QOS) which are really done for this.
> > > > 
> > > I first accomplished it with CBQ, but later I switched to HTB which is a lot
> > > easier to configure.
> > > 
> > > 
> > > Rob
> > > 
> > 
> > 
> > 
> 
> -- 
> ----
> Oskar Andreasson
> http://www.frozentux.net
> http://iptables-tutorial.frozentux.net
> http://ipsysctl-tutorial.frozentux.net
> mailto:blueflux@koffein.net
> 
> 
> 
> 
> 

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Andrei Ivanov]

All I really care is that I want iptables to be able to match all the
possible values of TOS. As you said it, my ISP used TOS for routing
purposes, marking the packets coming from outside with 0x62.

On Sat, 21 Sep 2002, Jim Fleming wrote:

> > On Fri, 20 Sep 2002, Andrei Ivanov wrote:
> >
> > >
> > > What amazes me is that iptables doesn't know to match packets by a tos
> > > value other then the ones in ip.h... this really SUCKS.
> ....that appears to be a "political policy" slipped into the software...
>
> There are 160 bits in the IPv4 header, all can be considered for routing purposes.
> Some of those bits are more useful than others, especially those controlled via the DNS.
>
> 128-bit DNS AAAA Record Flag Day Formats
> 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
> [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
> 1-bit to set the Reserved ("Spare") bit in Fragment Offset [S]
> 1-bit to set the Don't Fragment (DF) bit [D]
> 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
> 1-bit for Options Control [O]
> 7-bits to set the Identification Field(dst) [FFFFFFF]
> 4-bits to set the TOS(dst) Field [TTTT]
> Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
> FFF.FFFF.TTTT = GGG.SSSS.SSSS
> http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
>
>
> Jim Fleming
> 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
> http://www.netfilter.org/
> http://www.analogx.com/contents/dnsdig.htm
> http://ipv8.dyndns.tv
> http://ipv8.yi.org
> http://ipv8.dyns.cx
> http://ipv8.no-ip.com
> http://ipv8.no-ip.org
> http://ipv8.no-ip.biz
> http://ipv8.no-ip.info
> http://ipv8.myip.us
> http://ipv8.dyn.ee
> http://ipv8.community.net.au
> http://ipv8.ods.org
>
> ----- Original Message -----
> From: "Oskar Andreasson" <blueflux@koffein.net>
> To: "Andrei Ivanov" <andrei.ivanov@ines.ro>
> Cc: <netfilter@lists.netfilter.org>
> Sent: Friday, September 20, 2002 2:46 PM
> Subject: RE: Iptables bandwidth limit
>
>
> >
> > First of all, the limitation was created since you should not use other
> > TOS values than specified in the RFC's. You may get extremely strange
> > problems if you start doing random TOS matches on packets.
> >
> > Anyways, iptables _is_ actually able to do irregular TOS matching with the
> > ftos patch applied to the kernel (I _think_ it may still be in
> > patch-o-matic, but I don't know for sure). It should also be available
> > somewhere on the www.paktronix.com site.
> >
> > Have a nice day,
> >
> >
> >
> > On Fri, 20 Sep 2002, Andrei Ivanov wrote:
> >
> > >
> > > What amazes me is that iptables doesn't know to match packets by a tos
> > > value other then the ones in ip.h... this really SUCKS.
> > >
> > > On Fri, 20 Sep 2002, Rob Sterenborg wrote:
> > >
> > > > > You can almost do this with the limit module, but you should
> > > > > better use
> > > > > HTB or CBQ (QOS) which are really done for this.
> > > > >
> > > > I first accomplished it with CBQ, but later I switched to HTB which is a lot
> > > > easier to configure.
> > > >
> > > >
> > > > Rob
> > > >
> > >
> > >
> > >
> >
> > --
> > ----
> > Oskar Andreasson
> > http://www.frozentux.net
> > http://iptables-tutorial.frozentux.net
> > http://ipsysctl-tutorial.frozentux.net
> > mailto:blueflux@koffein.net
> >
> >
> >
> >
> >
>
>
>

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

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.

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

> 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.
> 
> 

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Saturday 21 September 2002 10:53 pm, Jim Fleming wrote:

> > 16 bits - fragment identifier
>
> http://ipv8.dyn.ee/INFO/Papers/RIFRAF

Fair enough, but that's not IPv4.

As the webpage says, it's an extension to IPv4 which they've chosen to call 
IPv8 (which I think is really confusing considering the next version due to 
hit the streets is called IPv6).

Antony.

-- 

How I want a drink, alcoholic of course, after the heavy chapters
involving quantum mechanics.

 - 3.14159265358979

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Saturday, September 21, 2002 4:59 PM
Subject: Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits


> On Saturday 21 September 2002 10:53 pm, Jim Fleming wrote:
> 
> > > 16 bits - fragment identifier
> >
> > http://ipv8.dyn.ee/INFO/Papers/RIFRAF
> 
> Fair enough, but that's not IPv4.
> 
> As the webpage says, it's an extension to IPv4 which they've chosen to call 
> IPv8 (which I think is really confusing considering the next version due to 
> hit the streets is called IPv6).
> 

IPv4 has a 0100 in the first four bits of the 160 bits that come screaming at you down the wire...
...correct ?

Have you ever set the 16 bits of the Identification Field ?....and used those for Extended Addressing ?
...before you do that, do you agree those 16 bits do not get changed across the IPv4 global transport ?

If Fragmentation does NOT occur, what are the 16 bits in the Identification used for ?
...are you aware TCP has its own Identification bits ?

In fact, if Fragmentation does not occur or is not used, what are all 32 bits in the second word used for ?
....one bit is used to say...Don't Fragment (DF)....that frees up 31 bits, in theory...

Backing up, have you seen the Random Identification Field feature in *BSD ?
...where random values are placed in the Identification Field to fool systems that try to tell what O/S
one is running by looking at patterns in the Identification Field...

Since Random works, one can assume they can take some of the bits and set them for their purposes
and leave some others to be used with the incrementing counter approach used in many systems...
How many bits can be safely "re-used" ?....8...14 ?...with 14 that is two 7-bit Extended Addressing Fields...
...couple that with the 4-bits from the TOS field and one has 11-bits of Extended Addressing...

As for IPv6...that is a 320-bit header with a 0110 in the first 4 bits....and a lot of useless complexity and
overhead to follow which uses bandwidth which is still precious and often ends up with a 160-bit header
in front of the 320 bits, for a minimum total of 480 bits to accomplish what can be done in 160-bits.
...jump on that band-wagon if you like....but that is not IPv4....

Should we release the C@t ?
http://www.ddj.com/articles/1993/9310/

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Sunday 22 September 2002 12:15 am, Jim Fleming wrote:

> IPv4 has a 0100 in the first four bits of the 160 bits that come screaming
> at you down the wire... ...correct ?

Yes.   Otherwise you wouldn't know it's IPv4.

> Have you ever set the 16 bits of the Identification Field ?....and used
> those for Extended Addressing ?

No, I haven't.   That would be using part of the IPv4 header in a manner 
different from the standard specification, which is not what I was talking 
about.   I was talking about which bits of the standard IPv4 header you can 
use to make routing decisions.

It sounds to me as though you're talking about finding parts of the header 
which you can get away with using for a different purpose than originally 
intended, and then claim that they're routing bits.

If that's the case then sure, feel free to do whatever you like at both ends 
of a link, but don't expect compatibility with a standard IPv4 stack.

On the other hand, if we're discussing which bits in a genuine IPv4 header it 
makes sense to read and base routing decisions on, then I still say that 83 
of them make sense, 28 are doubtful, and 49 are useless.

Either way I think this thread has got sufficiently off-topic for netfilter 
that we may as well end the discussion on the list.

By the way, I was not advocating IPv6 per se - I was simply commenting on the 
confusion which would ensure if this thing called IPv8 became at all well 
known in the time between IPv4, which we all use now, and IPv6, which we're 
all supposed to be using sometime soon.

Antony.

-- 

Having been asked to provide a reference for this man,
I can confidently state that you will be very lucky indeed
if you can get him to work for you.

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Sascha Reissner]

From: "Antony Stone" <Antony@Soft-Solutions.co.uk>

> By the way, I was not advocating IPv6 per se - I was simply commenting on
the
> confusion which would ensure if this thing called IPv8 became at all well
> known in the time between IPv4, which we all use now, and IPv6, which
we're
> all supposed to be using sometime soon.

Antony, dont care..

Jim Flemming was known for abusing this list as a propagate medium for his -
what he calls - IPv8 and IPv16 theories.

He used to reply with total off-topic stuff mentioning his theories..

i thought he one day left the list and we used to be quite happy but it
seems like he thought it would be smart to return.

just try to not get into deeper discussions with him about that stuff and he
will calm down, too.

Sascha.
--
mailto:sascha.reissner@toxicnet.de  -  http://www.fo0bar.org  -
contaminatiung the internet since 2001

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Sunday 22 September 2002 11:25 am, Sascha Reissner wrote:

> From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
>
> > By the way, I was not advocating IPv6 per se - I was simply commenting on
> > the confusion which would ensure if this thing called IPv8 became at all
> > well known in the time between IPv4, which we all use now, and IPv6, which
> > we're all supposed to be using sometime soon.
>
> Antony, don't care..

Oh, that's okay - I don't.

> Jim Flemming was known for abusing this list as a propagate medium for his
> - what he calls - IPv8 and IPv16 theories.
>
> He used to reply with total off-topic stuff mentioning his theories..

Hmmm.   I thought I'd been around this list for quite some time, but this is 
the first I'd come across anything called IPv8, and it just seemed such a 
silly idea that I didn't want to leave it in the archives without some 
response pointing out how it breaks the IPv4 standard and could confuse a lot 
of people who aren't too familiar with normal routing.

> just try to not get into deeper discussions with him about that stuff and
> he will calm down, too.

Fair enough.   I already said in my last posting that it was getting too 
off-topic for netfilter, so let's stop.   It's only in retrospect that I 
realised how off-topic it had already got from the original poster's 
question, which was how to recognise the TOS bits being set by his ISP...

Antony.

-- 

Success is a lousy teacher.   It seduces smart people into thinking they 
can't lose.

 - William H Gates III

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Sascha Reissner" <sascha.reissner@toxicnet.de>
> --
> mailto:sascha.reissner@toxicnet.de  -  http://www.fo0bar.org  -
> contaminatiung the internet since 2001
> 
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
3:89 DE   (GERMANY)

http://www.IN-ADDR.de

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Sunday, September 22, 2002 3:21 AM
Subject: Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits


> On Sunday 22 September 2002 12:15 am, Jim Fleming wrote:
> 
> > IPv4 has a 0100 in the first four bits of the 160 bits that come screaming
> > at you down the wire... ...correct ?
> 
> Yes.   Otherwise you wouldn't know it's IPv4.
> 
> > Have you ever set the 16 bits of the Identification Field ?....and used
> > those for Extended Addressing ?
> 
> No, I haven't.   That would be using part of the IPv4 header in a manner 
> different from the standard specification.....

The 0100 is quite wasteful to have it in every packet. In some systems, one could
asssume that by plugging into the right jack, a certain version is being used. Have
you ever calculated how much bandwidth is wasted each year with 4 of the 160 bits
in every packet as useless ? Could those bits be removed and not sent down the wire
to save bandwidth ?...and added in as they go up into the stack ?

As for the "standard specification", part of the purpose of "Netfilter" is to allow people
to process ALL 160 bits in the header. Modules can be added to do all sorts of things.
Do you think NAT is part of the "standard specification" ? Other than 160 bits and
what happens when those are presented to the global core transport, what is the
standard specification ?

What happens to the "standard specification" when you add a programmable engine
to the stack ?...that can be loaded with programs which process the packet flows ?
Have you ever done that ? Can that "Mangle Packets" ? Does that mean the standard
specification is mangled ?

http://www.netfilter.org/

http://ipv8.dyn.ee/INFO/Papers/VPC/

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Sunday 22 September 2002 2:35 pm, Jim Fleming wrote:

> Have you ever calculated how much bandwidth is wasted each year
> with 4 of the 160 bits in every packet as useless ?

Actually, it's 4 of every 160 bits in the *header* - there's up to another 
1500 *bytes* (on ethernet) of body in the packet as well, so the wasted 
bandwidth varies from 4/160 = 2.5% for empty packets, to 4/12160 = 0.03% for 
full ones.

Most people are going to have full packets in one direction (the direction 
that's got saturated bandwidth), and empty ACK packets in the other direction 
(which has oodles of bandwidth to spare because all the packets are empty).

Therefore I think 0.03% wasted bandwidth on a full link, and 2.5% wasted on a 
virtually idle link are very acceptable.

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Sascha Reissner]

From: "Antony Stone" <Antony@Soft-Solutions.co.uk>

> On Sunday 22 September 2002 2:35 pm, Jim Fleming wrote:
>
> > Have you ever calculated how much bandwidth is wasted each year
> > with 4 of the 160 bits in every packet as useless ?
>
> Actually, it's 4 of every 160 bits in the *header* - there's up to another
> 1500 *bytes* (on ethernet) of body in the packet as well, so the wasted
> bandwidth varies from 4/160 = 2.5% for empty packets, to 4/12160 = 0.03%
for
> full ones.
>
> Most people are going to have full packets in one direction (the direction
> that's got saturated bandwidth), and empty ACK packets in the other
direction
> (which has oodles of bandwidth to spare because all the packets are
empty).
>
> Therefore I think 0.03% wasted bandwidth on a full link, and 2.5% wasted
on a
> virtually idle link are very acceptable.
>
> Antony.


i guess 1 more offtopic mails like this compensates all "useless header
overhead" per user for a year.

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Sunday 22 September 2002 3:15 pm, Sascha Reissner wrote:

> From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
>
> > I think 0.03% wasted bandwidth on a full link, and 2.5% wasted
> > on a virtually idle link are very acceptable.

> i guess 1 more offtopic mails like this compensates all "useless header
> overhead" per user for a year.

Sorry :-)   You're right.   I just hate to see bullshit spread about in what 
is usually a very helpful and informative mailing list.

I'll stop now.

Antony.

-- 

Normal people think "if it ain't broke, don't fix it".
Engineers think "if it ain't broke, it doesn't have enough features yet".

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> 
> Sorry :-)   You're right.   I just hate to see bullshit spread about in what 
> is usually a very helpful and informative mailing list.
> 

I think that is an extreme ( = unreasonable ) point of view.

Of the 160 bits in an IPv4 header, **YOU** 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, **YOU** 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.

**YOU** 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
=======

Other people also have a right to think...and do as they please with the 160 bits...
There are...
1.4615016373309029182036848327163e+48
...possible 160 bit headers....all of them may not be useful....
NetFilter allows each person to decide which are useful and which are not...
...educated people know what is in those 160 bits...and how they can be used...
http://www.netfilter.org/

An ISP that does not pass TOS Field end-to-end with no change, is not an ISP...
An ISP that sets the TOS Field for you is not an ISP...

By the way, there are only 2 bits used for Fragmentation Flags...MF and DF...

What do **YOU** use the Spare Bit for ?

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> On Sunday 22 September 2002 2:35 pm, Jim Fleming wrote:
> 
> > Have you ever calculated how much bandwidth is wasted each year
> > with 4 of the 160 bits in every packet as useless ?
> 
> Actually, it's 4 of every 160 bits in the *header* - there's up to another 
> 1500 *bytes* (on ethernet) of body in the packet as well, so the wasted 
> bandwidth varies from 4/160 = 2.5% for empty packets, to 4/12160 = 0.03% for 
> full ones.
> 

Are there also 4 bits in each 320 bit header, when the value is 0110 ?

Is that an improvement ?....with 4/320 = 1.25%

Can routing be done on the values 0100 and 0110 ?

Are those 4 bits included in your count of useless routing bits ?

From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
"I still say that 83 of them make sense, 28 are doubtful, and 49 are useless.
=============================

Moving to the next 4 bits....do you agree they are almost always 0101 (5) ?

IF one assumed they did not care about "options", could those bits be assumed ?...and dropped ?
Is that another 2.5% savings ?

If the 0100 and the 0101 are tossed, is that a 5% savings ?

...or, could the 0100.0101 be considered an 8 bit "version" number ?
do people want or need 256 versions ?
==========

Going back to the mention of the *header*....could the 4-bits really be a header ?
...are all 16 values valid ?....what is 0000 and 0001 ?
Does the 4-bit "Version Header" describe the "Next Header" which follows ?

0000 = 0 bit header
0001 = ??
...
0100 = 160 bit header
...
0110 = 320 bit header

===========

Does NetFilter route based on the first 4 bits ?
http://www.netfilter.org/

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- 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."
           
     

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Antony Stone]

On Saturday 21 September 2002 10:56 pm, Jim Fleming wrote:

> ----- 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."

Sorry for the lengthy quote of the previous posting, but I really don't see 
what you're trying to say here.   The above is a good description of the 
fragment identifier field in the IPv4 header, however it doesn't mention 
routing at all, which is what I thought we were discussing ?

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Re: Setting and Routing on the TOS Source (SRC) and Destination (DST) Bits

[Jim Fleming]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> 
> 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
> 

The "3 bits - fragmentation flags" are complicated...

One is Spare....it can be set to 0 or 1 and seems to pass thru untouched...

The other two MF-More Fragments and DF-Don't Fragment can not easily be touched.

One could argue that the DF bit turns off the usage of the 13 Fragment Offset Bits...
IF one wanted to give up Fragmentation, they could redefine DF to be an Extended Address
indicator and the 13 bits (plus the one Spare) could make up two 7-bit fields. Unfortunately,
that approach would make it such that Extended Addressing would only apply to packets
that do not have the Fragmentation Feature...(shades of IPv6, which does not have that field).

The 8-bits of Protocol could also be re-worked with care to be a 2-bit field and a 6-bit field.
The 2-bit field would specify one of the 3 dominate Protocols or Legacy values. With the
three dominant protocols, ICMP, UDP and TCP, one could have two 3-bit fields for Extended
Addressing. This again, has its limits because those Extended Address spaces would then only
be used with that limited set of Protocols. That may not be all that bad. The 3-bits then create
8 planar networks for each of the dominant protocols. It is like adding 7 stories to an existing
building.

The 8 TOS bits are the easiest to split into two 4-bit Extended Addressing fields. That instantly
makes the existing IPv4 Internet, 15 times larger. The TOS values with 0x0* or 0x*0 can be
viewed, as special, if one assumes that 0x00 is the legacy Internet. All other values can be used
to route between the planes, 0x43 would be a SRC=4 and a DST=3. Going back the other way
the TOS is reversed to be 0x34. A value such as 0x30 may not make sense because a legacy node
will not know how to reverse the bits and reply to 0x03. All of the useful TOS values fit into the
special point codes.

All of this of course does not touch the UDP and TCP Port Numbers which are an integral part
of the address space. Those 16-bits can be loaded into a 128-bit DNS AAAA record in the
right-most bits for the quickest expansion and to gain access to bits which never before fit in the
32-bit A records. Those bits increase the 32-bit addressing by a huge factor. The limit again is that
not all services use the dominant UDP and TCP protocols. YMMV.

In the end, the marketplace can take the 160-bits and use every one in various ways, and eventually
a consensus can be reached about what bits make the most sense in the 128-bit DNS AAAA
records. Not all of the 128-bit DNS AAAA record bit have to go in the header. As an example,
one bit can be used for "Options Control" indicating that no IPv4 Options are supported at the Destination.
That will show up as the Header Length=5, which is common. If one moved to a situation where it was
assumed that there was ALWAYs at least One Option, then the Options Control resulting in the value
of 5 would tag packets as "unique" and in some sense that is a form of control and routing could be
done special on HL=5 and HL!=5.

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved ("Spare") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS

People have only begun to consider all the ways that 160 bits can be set, and what happens
to those bits with respect to the edge devices and the core transport. It is critical to consider
what bits are unchanged across the transport, and which bits can have any value without impacting
the results of the transport, which can end up being an interim transport, as edge devices are
deployed which can route directly to each other base on bits in the 160-bit header that are not
part of the transport's routing activity. Only packets, as a last resort, need to go across the
global transport. As more and more traffic flows around the edges, eventually, the 32-bit legacy
core can be turned off, just like many networks over time. People evolve and expand and route
around the legacy road-blocks....


Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.netfilter.org/
http://www.analogx.com/contents/dnsdig.htm
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org