Subject: DF and IP ID

From: Rick Jones <[email-masked]>
Date: Fri, 13 Oct 2000 13:30:02 -0700

If an implementation of IP sets the DF bit in the header, does it need
to worry about using unique IP datagram identifiers? 

rick
-- 
rachel marina jones, 09/24 0317, 7lbs, 7oz, 20"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: [email-masked]
Date: Sat, 14 Oct 2000 18:25:21 +0400 (MSK DST)

Hello!

> to worry about using unique IP datagram identifiers? 

They are useless.

F.e. IPv6, where all the packets have implicit DF, generates
identification only for fragmented packets or in packets, which
are allowed to be fragmented by adding explicit frag header.
There are no reasons not to downgrade this finding to IPv4.

In fact, linux-2.4 does this.

Alexey Kuznetsov

---

From: Rick Jones <[email-masked]>
Date: Sat, 14 Oct 2000 09:19:05 -0700 (PDT)

> In fact, linux-2.4 does this.

Are there any places where the DF bit might get cleared along the way?
Perhaps NAT or firewall or something? Or perhaps if there was a change
in the flow where the point of origin decided to clear the DF bit on
its own? How about the "be conservative in what you send" half of the
Internet Axiom?

rick jones

---

From: [email-masked]
Date: Sat, 14 Oct 2000 20:50:52 +0400 (MSK DST)

Hello!

> Are there any places where the DF bit might get cleared along the way?

It is its goal not to be ever cleared. 8)

> Perhaps NAT

Dynamic NAT which has to defragment packets to transform them
(it is the only place where DF can be cleared), has to regenerate
IP IDs in any case otherwise flows from different hosts will collide.

> 	How about the "be conservative in what you send" half of the
> Internet Axiom?

You are allowed to make plain sillogisms from MUSTs made in base RFCs. 8)

Note also, that taking into account that at modern rates 16bit
IP ID finally lost its sense (~100 different packets with one
src/dst/protocol/ID in flight is rule. 8)), path MTU discovery became
mandatory years ago and fragmentation (sorry, not fragmentation,
but tagging each packet) on big internet is simply impossible.

In fact, avoiding useless lossage of too small ID space for
almost all the packets except for really fragmented ones is
the only solution to this problem.

Alexey Kuznetsov

---

From: Richard Wendland <[email-masked]>
Date: Sun, 15 Oct 2000 03:49:53 +0100 (BST)

> Perhaps NAT or firewall or something?

Clearing DF seems like the kind of thing some HTTP load balancers
would do.  Though if they clear DF, hopefully they'd set their own ID
as well, but I wouldn't always bet on it.

As an example of this kind of thing, look closely at HTTP traffic to
www.drugstore.com, which appears to use some kind of load balancer.
It looks like most of the conversation is mediated by some device which
clears DF, but the FIN & FIN ACK is left for NT4 to send unmediated so
has DF set.

In this case, as this device seems to set its own ID, there wouldn't
have been a problem had the web server OS set ID zero.  But it seems a
good idea "to be conservative in what you send", and follow traditional
behaviour of always providing an ID that would work for fragmentation.

Here's some example tcpdump output:

client.1588 > www.drugstore.com.80: S 993978469:993978469(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 204461079 0> (DF) (ttl 64, id 37921)
www.drugstore.com.80 > client.1588: S 1775436697:1775436697(0) ack 993978470 win 8192 <mss 1460> (ttl 45, id 56701)
client.1588 > www.drugstore.com.80: . ack 1 win 17520 (DF) (ttl 64, id 37923)
client.1588 > www.drugstore.com.80: P 1:45(44) ack 1 win 17520 (DF) (ttl 64, id 37924)
www.drugstore.com.80 > client.1588: P 1:576(575) ack 45 win 8192 (ttl 45, id 56745)

# from now on www.drugstore.com sets DF,
# with traffic direct from NT4 with a larger window and TTL

www.drugstore.com.80 > client.1588: F 576:576(0) ack 45 win 8716 (DF) (ttl 108, id 62163)
client.1588 > www.drugstore.com.80: . ack 577 win 17520 (DF) (ttl 64, id 37928)
client.1588 > www.drugstore.com.80: F 45:45(0) ack 577 win 17520 (DF) (ttl 64, id 37929)
www.drugstore.com.80 > client.1588: . ack 46 win 8716 (DF) (ttl 108, id 3028)

	Richard
-- 
Richard Wendland				[email-masked]

---

From: Andi Kleen <[email-masked]>
Date: Sun, 15 Oct 2000 06:06:20 +0200

> It is its goal not to be ever cleared. 8)

Unfortunately there are lots of tunnels who effectily ignore it. They add
an outer header that decreases the MTU of the link. Normally they should
send an fragmentation required ICMP to the sender, but with the many
pmtu blackholes on the internet that breaks often, so they fragment instead.
The fragments are likely to not carry DF bits.

[Yes, it is broken, but it is reality] 

-Andi

---

From: [email-masked]
Date: Sun, 15 Oct 2000 23:07:59 +0400 (MSK DST)

Hello!

> Unfortunately there are lots of tunnels who effectily ignore it.
...
> [Yes, it is broken, but it is reality] 

Andi, ID in tunneled packet has nothing in common with original one. 8)

Alexey

---

From: [email-masked]
Date: Sun, 15 Oct 2000 23:29:59 +0400 (MSK DST)

Hello!

> would do.

Servers sitting behind such balancer must have pmtu discovery disabled.
It is not useful in such case.

Actually, known to me splicers handle DF absolutely correctly
and even more! Some of them enforce pmtu discovery to keep mss
in right state. 8) So that instead of disabling DF on servers,
which support it, it is not so bad idea to replace bad balancer with
real one yet.

Alexey

---

From: Andi Kleen <[email-masked]>
Date: Sun, 15 Oct 2000 22:44:40 +0200

> Andi, ID in tunneled packet has nothing in common with original one. 8)

Just the DF is effectively gone (that was my whole point) 

-Andi

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 15 Oct 2000 23:14:45 -0700 (PDT)

> its own? How about the "be conservative in what you send" half of the

I've seen discussions about some PPPoE equipment used for frame relay
which either clears DF or fragments packets even if DF was set.
This "feature" was viewed as needed since some senders of packets with DF
bit set sit behind firewalls that discard all ICMP packets.

So "conservative in what you send" is probably a good idea since folks
do "creative" things out there.

  Erik

---

From: [email-masked]
Date: Mon, 16 Oct 2000 19:25:36 +0400 (MSK DST)

Hello!

> Just the DF is effectively gone (that was my whole point) 

That's why on Linux tunnels over IP sych fragmentaion is not used by default.
And it is difficult to turn it on. 8)

Alexey

---

From: [email-masked]
Date: Mon, 16 Oct 2000 19:38:25 +0400 (MSK DST)

Hello!

> bit set sit behind firewalls that discard all ICMP packets.

OK. Next time when I will have a head ache, I try to use guillotine.
Seems, it is the most conservative method of therapy. 8)

When setting DF I do this not for fun. Fragmenting of such
frame "is NOT permitted" (note capitals in rfc791). Period.

Alexey

---

From: Rick Jones <[email-masked]>
Date: Mon, 16 Oct 2000 09:10:09 -0700 (PDT)

is it _really_ all that hard to generate a "proper" IP ID in a stack
that it would not be worth doing even when DF is set to satisfy the
conservative in what is sent axiom?

rick jones

---

From: [email-masked]
Date: Mon, 16 Oct 2000 20:26:28 +0400 (MSK DST)

Hello!

> is it _really_ all that hard to generate a "proper" IP ID in a stack

It is not hard to generate "some" IP ID.

But it is theoretically impossible to generate "proper" one.

Please, reread my first mail. ID in DF packets is not generated
to make it __reliable__ in the cases when it is really required.
If some engine on internet _uses_ IP ID in all the packets for some
purpose, it is fatally broken and has no rights to exist.
I am sorry, but 16bit ID become obsolete simultaneously
with inventing 10Mbit ethernet. And rates are sort of a bit
higher nowadays. 100 times. 8)

Alexey

---

From: Rick Jones <[email-masked]>
Date: Mon, 16 Oct 2000 10:34:42 -0700 (PDT)

> Please, reread my first mail. ID in DF packets is not generated to
> make it __reliable__ in the cases when it is really required.  If
> some engine on internet _uses_ IP ID in all the packets for some
> purpose, it is fatally broken and has no rights to exist.  I am
> sorry, but 16bit ID become obsolete simultaneously with inventing
> 10Mbit ethernet. And rates are sort of a bit higher nowadays. 100
> times. 8)

I will acknowledge that it is possible, even likely, for a non-trivial
number of "IP flows" to have their ID wrap within MSL. I will also
acknowledge that something that silently clears a DF bit is
broken. However, it still seems that having even a 16-bit IP ID for
each flow is better than nothing, even with DF set. No, it is not
perfect. Nothing in the Internet is. That, I suspect, is part of the
rationale behind "Be conservative in what you send." Particularly
since it should not be all that difficult for an IP implementation to
do. 

Given current bitrates, and times of wrap-around would you also then
say that every TCP connection must use large windows and timestamps?

rick jones

---

From: [email-masked]
Date: Mon, 16 Oct 2000 21:48:46 +0400 (MSK DST)

Hello!

> rationale behind "Be conservative in what you send." 

I am so conservative that astonished myself. 8)

That's why I select IDs carefully.

> say that every TCP connection must use large windows and timestamps?

What's about timestamps, no doubts. Advertising timestamps is another
example of real conservatism.

What's about large windows, it is not a must but desired.
At least windows less than 64K are harmful.

Alexey

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 16 Oct 2000 14:20:48 -0700

> example of real conservatism.

The thing about timestamps is that they have the potential to be useful in
almost every situation (although the potential is realized more often in
some specific scenarios). Even though they are a waste of capacity for a
majority of the connections, they have the potential to be useful and
therefore yes, their usage is the most conservative approach.

> At least windows less than 64K are harmful.

Always using 64k windows is not conservative, in fact excessively-large
windows are just as harmful as excessively-small windows. If nothing else,
a window that is too large will always result in some form of
congestion-related loss as the true limits of the circuit are discovered.
Optimal window sizes are the most effective, self-tuning windows
(route-based entries that reflect true capacity characteristics) would
therefore be the most conservative if anybody used them. Nobody does so to
my knowledge however.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/