Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP

From: Joe Touch <[email-masked]>
Date: Wed, 18 Dec 2002 18:15:41 -0800

Richard Wendland wrote:
>>>I'd be very careful fixing the IP ID - I have been told by one major
>>>"interconnect" vendor that some of their products have ways to allow
>>>the customer (at customers persistent request) to cause the devices to
>>>ignore and clear the DF bit...
>>
>>That would be a violation of the STDs (1812, 791), which could cause 
>>problems that would be very difficult to debug (e.g., path MTU, etc.)
>>
>>I.e., you're worried about changing the IP ID field because vendors who 
>>violate standards will break? Go right ahead, IMO.
>>
>>Laws for the lawless are a waste of effort (shades of NAT).
> 
> An admirable attitude, but even Linux backtracked on this IP ID issue
> when faced with practical connectivity problems.  Linux for a time used
> to set IP ID zero if DF was set, but went back to setting changing IP
> IDs for TCP with DF.

What I'm asserting is that what we do should be related to the 
standards, not necessarily what NAT-supporting vendors need to make 
their systems still work.

I mean that anyone who clears the DF bit gets what they deserve - a 
nonfunctioning brick.

> I'm not a Linux kernel developer, but I think that change back is related
> to the comment in the kernel include/net/ip.h:
> 
> 	/* This is only to work around buggy Windows95/2000
> 	 * VJ compression implementations.  If the ID field
> 	 * does not change, they drop every other packet in
> 	 * a TCP stream using header compression.
> 	 */

I'm not sure we want specs to provide workarounds for bugs. Bugs should 
be fixed at the source.

> I also think I have observed a middlebox clearing DF; circumstantial
> evidence not proof though.  It appeared to me, from remote observation,
> that a HTTP load balancing device was clearing DF on TCP segments
> en-route from HTTP servers to clients.  I presume this is because the load
> balancer's developers could not be bothered to "route" ICMP fragmentation
> needed back to the appropriate HTTP server.  If this is correct, and the
> load balancer isn't cleverly changing the IP ID, there could be problems
> if TCP stacks don't set a real IP ID.
...
> It's horrid, and wrong.  But it is a problem for practical connectivity.

It's a bug that needs to be fixed, but not one that should drive standards.

Joe

---

From: Alan Cox <[email-masked]>
Date: 19 Dec 2002 18:20:09 +0000

> I'm not sure we want specs to provide workarounds for bugs. Bugs should 

Yeah sure. Given some large vendors can't even get CIDR right still (try
connecting to ftp2.linux.org.uk from various non Unix systems some day)
I don't think we can expect vendors to fix their hardware.

The reality is that even things like TCP ECN are still undeployable
because large allegedly competent organisations have everything broken.
Its only recently that tcp path mtu has become generically usable.

Alan

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2002 10:04:25 -0800

> I don't think we can expect vendors to fix their hardware.

Agreed. Perhaps we make interim software patches, but we don't adjust 
specs. If vendors can't get the first spec right, what is the point of 
making a modified spec?

> Its only recently that tcp path mtu has become generically usable.

Agreed on both counts. IMO, endsystems should deploy many such things as 
'default off' - so that those interested in playing in the _experiment_ 
of trying them can, accepting the risk of debugging it up front.

(but then, I think the IETF doesn't take full use of the experimental 
track as a stepping stone to draft standard).

Joe