From: johngibson1541@yahoo.com
Date: Thu Apr 05 2007 - 01:29:37 ART
Part of my subject line is lost in GS's server. Originally I was talking
about IPv6 .
IPv6's packet header doesn't have "fragment offset" field.
An IPv6 router doesn't fragment packets it doesn't matter how
you configure it, because the header is not capable of handling
fragments, right ?
I still need to read more about "ip tcp adjust-mss" . I have
no idea what it does. Is it very important for the health of
our public internet ? Must be.
I did a http to some page of goole search result (20KB http page
source) and wireshark'ed it just now. 1470 byte packets are
everywhere which made 1484 byte frames.
And, now, those IPv4 packets from google are not using the
"fragment offset" (they are all 0's).
My question is, is IPv4's header's "fragment offset" field
so obscure that IPv6 simply discard it ? How often is
the "fragment offset" field used in IPv4 world ?
My second question is, does our PC's TCP stack (BSD socket
C language library) use the default 1470 byte packet size
intending NOT to use "fragment offset" field ?
What is the background story behind all these ? These
http, ftp programmers use BSD's default and Windows Socket
copies everything from BSD. And now BSD's default configuration
makes the world abandon "fragment offset". Did U.C. Berkley
plan all these all alone all these years ? I know they are
rich. I didn't know how they do all these.
John
>>>>>>>quote
Actually, barely any networks in the enterprise world rely on PMTU anymore.
If you are concerned with an MTU bottleneck in the middle of the
communication path, for example GRE tunnels, you'd normally use "ip tcp
adjust-mss" set to your IP MTU - 40. So for example, let's say you have a
gre tunnel somewhere in the middle. The IP mtu would normally be set to 1476
(1500 - 20 IP header - 4 GRE header), and tcp adjust-mss would be set to
1436 (1476 - 40 IP+TCP header). With this configuration these problems don't
matter anymore:
1. PMTU is not needed (tcp only)
2. Doesn't matter what MTU the server or client are using (tcp only)
3. Doesn't matter what MSS the server or client are using (tcp only)
4. Doesn't matter if the server or client are using DF bit (tcp only)
All these issues are resolved with tcp adjust-mss.... the only problem is
that it applies only to TCP traffic. The issue remains with UDP traffic. But
it's not a big deal. If UDP for some reason sends large MTU packet, it would
get fragmented. I don't know of any applications that set DF-bit and that
use full size 1500 ip packet. I don't know of any... except for one :)
Microsoft Kerberos authentication on Windows 2000 (I think it's only on
Win2K) will use UDP by default (I believe on Win2003 they changed to TCP for
default setting), and it will set the DF bit. Well, it's not a problem....
until your AD transactions (resulted from the user database size etc) reach
certain size and the packet ends up being above the "bottleneck" MTU. The
difficult way to fix it is to tell your server guys to switch Kerberos from
UDP to TCP... but it might be difficult in large environments. The other way
to fix it, of course, is to use the route-map and clear df-bit on all UDP
traffic.
Hope this helps
--------------------------------------------------------------------
Sergey Golovanov, CCIEx5 (R&S/Security/Voice/Service Provider/Storage)
"Please, don't ask me for my ccie #, there are reasons why I can't release
it"
ieMentor Instructor and Content Developer
sergey.golovanov@iementor.com
http://www.iementor.com
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:34 ART