Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Lorenzo Colitti <lorenzo@google.com> Fri, 26 October 2012 01:53 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D85B21F8583 for <v6ops@ietfa.amsl.com>; Thu, 25 Oct 2012 18:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.899
X-Spam-Level:
X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG84EWMXjr7F for <v6ops@ietfa.amsl.com>; Thu, 25 Oct 2012 18:53:47 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3473521F856D for <v6ops@ietf.org>; Thu, 25 Oct 2012 18:53:47 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so2485568obq.31 for <v6ops@ietf.org>; Thu, 25 Oct 2012 18:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=zZhRbWWHrokEjS1DphwobGcTHkxoV1HEVxP6ng2JgJM=; b=YSFaLwkQqnl7VAufgUcdmOVlYLk0I4oJo+jWO+o9JIeDlQUiqG8Djs3j3KFKgwVmpm 9Gx4sEZVpErnjIUfX4g2itUDinbtBEPy065f6x8BIL/+zWUQZjDug+RAi3QckLqWrEBG /2D0jK16wiYUdeMSfl1Wg+kHhJo93HWK3yqh/gr+zUpbE3nivOUmgkS908uvRiX0uylm 4Be3eU9GnXV+9R9Ipgql/oWWrRuLhBZ1U7Dxu03dcG73+G71JtJNq8LIIx+9x9xw9Kuu P6k3xNhYYwojSEuq7YPtXbPV4Q3p46/uOgIUgnZB8LUgIHNsgwE5CaeXf60ewf3qTjhG Pc7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=zZhRbWWHrokEjS1DphwobGcTHkxoV1HEVxP6ng2JgJM=; b=R6vQIBrJVcBam8HBXrlTN/ZnVWqsyc1/rIQWt4FwCa9kG7s8/A9yhOO+FL4tR7D3Tn TTaJqB6yUx9F0e6AM6GAbN2vQjKCjbsfbA9D9aqGXa6yS5+1EpsG1PAmLLfNSuPKgJQ+ TmOtambqC1z+1vaPvD3T7FgLqoLUw4d0gcDAF4Yu8JT6IZ4HPWR9Wb5s+R7sL622LoAF aJ0RW81wa7Fjl8wrZflPfmsSJmDRprt7LY39BLxd7dlqOFPSIebt0dKyNsoRJGDesMuP oNnDbzpSuzxgwpHlA45jaWu1hRvontGOi/DBXJJJ0fv33GtmgJVxhJtPebTO2dE62pnu 5jsA==
Received: by 10.182.38.101 with SMTP id f5mr17543993obk.80.1351216426690; Thu, 25 Oct 2012 18:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.176.106 with HTTP; Thu, 25 Oct 2012 18:53:26 -0700 (PDT)
In-Reply-To: <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net> <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C66F@XCH-NW-01V.nw.nos.boeing.com> <5085319B.60707@inex.ie> <CAKD1Yr2qDsM6cCPapRmKuWw7SG-cuMd9PuiBD7ineqj7Bp4+Xw@mail.gmail.com> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 26 Oct 2012 10:53:26 +0900
Message-ID: <CAKD1Yr1xDC7BefRyaHHKfw9THRkyQWwHS5P05_uWTOV539uS2w@mail.gmail.com>
To: Mark Smith <markzzzsmith@yahoo.com.au>
Content-Type: multipart/alternative; boundary="f46d0446300820a71f04ccec97ca"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnt18jIJTTLwuIPKrWbiOyS9P/1ZBYCi8QGXILJiBs6Vm/feLJynZ1d+YLJ4dSM1gPM2313v9YVsDX8Y7dKAMvOvaUQhs1IjtsIyfMHcNJagivAibkPGKhjq/EHcHLyX7n1ChO2lT4lNfzX2fMLFSQPzTBhrESvvdm+d07M8Vl9LA+BOcMFB9MwFkvFNHiWiSMpz+uZ
Cc: V6 Ops <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2012 01:53:48 -0000

On Thu, Oct 25, 2012 at 5:41 PM, Mark Smith <markzzzsmith@yahoo.com.au>wrote:

> I think there should be advice. If the IETF has seen fit to
> make fragmentation a capability of IPv6, then I think that is inherently
> saying
> that the IETF strongly suggests if not requires forwarding rather than
> dropping of fragments for successful IPv6 operation. This seems to me to
> be an RFC2775 Internet Transparency issue.
>
> Alternatively, if fragments are more trouble than they're worth,
> they should be deprecated.
>

I agree that there should be advice, but unfortunately, I don't see a way
to do that.

For example, I personally think that fragments are more trouble than
they're worth, they don't work in today's Internet (IPv4 *or* IPv6), create
security issues (see e.g., Fernando's issues with fragmented RAs, plus an
history of security issues in fragment-handling code) and that applications
are much better off implementing their own fragmentation above UDP or
whatever else they may use. Unfortunately, it doesn't seem likely that this
working group will reach consensus on such a recommendation.

On the other hand, giving the opposite advice, and saying "fragmentation is
required and fragments MUST always be allowed" is out of touch with
reality, because current implementations and network designs are not
capable of doing this, and is therefore useless because operators can't do
what implementations are not capable of. I doubt we'll reach consensus on
such a recommendation either.

As always, the danger in trying to reach consensus on a controversial topic
is that of endlessly discussing the issue, which makes it impossible to
make a useful contribution to it. The way I see it, if we can't reach
consensus, it's better to punt entirely and at least issue a statement
about the issues. At least we will have done something useful. If we get
deadlocked forever in trying to decide what the right thing to do is, we
will get nothing useful done at all.


> It seems to me that developing an application that may be used over
> the Internet involves developing for the worst case, not the best. If a
> small
> but significant enough portion of sites on the Internet drop fragments,
> then applications will be developed to avoid using fragments. Once
> applications avoid using fragments to suit some sites on the Internet, then
> all sites on the Internet may as well drop them, because they've been
> rendered useless.
>

I agree. But on the other hand, the data presented in this draft shows
clearly that what you describe ("a small but significant enough portion of
sites on the Internet drop fragments") is true today (actually, it's not
even "small"). So fragments have already been rendered useless in the
general case. But some of the reactions to the draft were, "That's
incorrect and it will break things. The operators filtering fragments
likely don't know that what they're doing is bad, and once we explain that
to them, they will fix it".