Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Maciej Żenczykowski" <maze@google.com>
Cc: Tore Anderson <tore@fud.no>, David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	Tom Herbert <therbert@google.com>
Subject: Re: [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing
Date: Tue, 24 Apr 2012 22:10:28 +0200	[thread overview]
Message-ID: <1335298228.5205.168.camel@edumazet-glaptop> (raw)
In-Reply-To: <CANP3RGd0mV8RcH1zCLBg+N9sgPGbiynhOSfoUAYpcMgYsvzeNA@mail.gmail.com>

On Tue, 2012-04-24 at 12:49 -0700, Maciej Żenczykowski wrote:
> Why do we refuse to set ipv6 mtu's below 1280?
> how is what we do any better?

I guess you didnt read Tore use case.

Thats the standard : http://tools.ietf.org/html/rfc2460#section-5

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

  reply	other threads:[~2012-04-24 20:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 17:37 [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing Eric Dumazet
2012-04-24 19:49 ` Maciej Żenczykowski
2012-04-24 20:10   ` Eric Dumazet [this message]
2012-04-24 21:50     ` Maciej Żenczykowski
2012-04-24 21:51       ` Maciej Żenczykowski
2012-04-25  5:32       ` Eric Dumazet
2012-04-25  7:34         ` Maciej Żenczykowski
2012-04-25  9:20           ` Tore Anderson
2012-04-25  9:38             ` Eric Dumazet
2012-04-25  9:51               ` Tore Anderson
2012-04-25  9:52               ` Maciej Żenczykowski
2012-04-25 10:02               ` Eric Dumazet
2012-04-25 18:39                 ` David Miller
2012-04-25  9:48             ` Maciej Żenczykowski
2012-04-25 10:04               ` Tore Anderson
2012-04-25 10:15                 ` Eric Dumazet
2012-04-25 10:30                 ` Maciej Żenczykowski
2012-04-25 10:44                   ` Eric Dumazet
2012-04-26 10:32                     ` Tore Anderson
2012-04-25 10:45                   ` Tore Anderson
2012-04-25 11:02                     ` Maciej Żenczykowski
2012-04-25 11:49                       ` Tore Anderson
2012-04-25 11:55                         ` Maciej Żenczykowski
2012-04-27  4:03 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1335298228.5205.168.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=therbert@google.com \
    --cc=tore@fud.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox