IETF Logo Mail Archive

Re: Non-Last Small IPv6 Fragments

神明達哉 <jinmei@wide.ad.jp> Fri, 11 January 2019 00:56 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B640712D7F8 for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 16:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level:
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u95GCmy0nIOm for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 16:56:41 -0800 (PST)
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F35123FFD for <ipv6@ietf.org>; Thu, 10 Jan 2019 16:56:40 -0800 (PST)
Received: by mail-wr1-f41.google.com with SMTP id p4so13435362wrt.7 for <ipv6@ietf.org>; Thu, 10 Jan 2019 16:56:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLxVkyeXukno69zY5PSwzZw/dXnXNudUhhejowfTXrY=; b=Zs9g9avgYGsFC8vAzchDGfWsh5+amUFOMpPyDC9JM7vBJ37cqTssjJlJ0Ukp+do2WH 0jgvcOMDMJ3icTP77wROkwaPAhMBs+dYNeZJ2zZMU9tKeW11Q1lYkR2uO0jOQd4izaR2 y7Q6wyOJms4YNXZrooBTVZ+HSfLRtQ3MvGY58sUao+PifeyVYi/18L2jxe+dOsuYzfy9 hhCD41xIP9dGRmqpKDZa0ZUX1ajEYouNDNXut/3AokG1HbaEj0brk5IwOWwF7EAjkb54 imPrb9UX6s8bG/ik+302ApldNf4Izn1Wgj2EyhsGDRKmqxxSermmEXfAUrWiT/3YMrfC 3w1w==
X-Gm-Message-State: AJcUukerIgZYXj3Y6y+AwpUi1LCyD7tZIRTbyXwNhVyiKGyQQennz9pM TZ6snjAzQNLuzvoafUAd8p1eGE9Nk94tlszsDwk=
X-Google-Smtp-Source: ALg8bN5mzDpF4p69BdIPbV+wviEEXi67ehXz+b0UPF/0Pi7sshkK3eVEWdun4gF6t7vml17kImwjQDBH0WDoOE/aQbY=
X-Received: by 2002:a5d:6a42:: with SMTP id t2mr12186640wrw.50.1547168199105; Thu, 10 Jan 2019 16:56:39 -0800 (PST)
MIME-Version: 1.0
References: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com> <CAJE_bqe2MqH4WGZHcNeWiaBvvpYB2TEvMoOUWE523TSq-Bd0=Q@mail.gmail.com> <AB78518A-F1C3-4668-B0E7-5A267126941C@tzi.org>
In-Reply-To: <AB78518A-F1C3-4668-B0E7-5A267126941C@tzi.org>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Thu, 10 Jan 2019 16:56:27 -0800
Message-ID: <CAJE_bqfBwrixzzwq0J=ny53xJZDQO3Azdgr83cph8t_5+UWFig@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: cabo@tzi.org
Cc: IPv6 IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ea64a9057f242aca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_iG-sqkaAOumJIcbLaUqpcvwJ3E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2019 00:56:43 -0000

At Fri, 11 Jan 2019 00:30:45 +0100,
Carsten Bormann <cabo@tzi.org> wrote:

> > I
> > would even consider it "reasonable" (not just "allowed by the
> > standard") if an implementation divides a 1300-octet packet into two
> > 650-octet fragments (ignoring common header overhead for brevity)
> > instead of 1280 + 20,
>
> Actually, something more on the side of 20 + 1280 might also be a useful
choice.

(I don't think you misunderstood my point but just in case) that's not
the point.  My point was that it's not surprising (to me at least) if
some implementation prefers the "650+650" fragmentation and so it
would be too "illiberal" to drop such fragments unconditionally.  Of
course "1280+20" can also make sense (if nothing else, it would be
simpler to implement), and in fact I believe most implementations take
that approach.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email