RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance"

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 12 July 2012 20:01 UTC

Return-Path: <Fred.L.Templin@boeing.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 A57EF21F86EA for <ipv6@ietfa.amsl.com>; Thu, 12 Jul 2012 13:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level:
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Ro17yRQzTD for <ipv6@ietfa.amsl.com>; Thu, 12 Jul 2012 13:01:40 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB921F86E8 for <ipv6@ietf.org>; Thu, 12 Jul 2012 13:01:39 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6CK2D0m019636 for <ipv6@ietf.org>; Thu, 12 Jul 2012 15:02:13 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6CK2Dng019632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2012 15:02:13 -0500
Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6CK2DN2016644; Thu, 12 Jul 2012 15:02:13 -0500
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6CK2Cn5016261 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jul 2012 15:02:13 -0500
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Thu, 12 Jul 2012 13:02:12 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Dan Wing <dwing@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Date: Thu, 12 Jul 2012 13:02:10 -0700
Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance"
Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance"
Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQAAFsgDAAAlqBkAAExMAg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65D8F4C8A58@XCH-NW-01V.nw.nos.boeing.com>
References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <E1829B60731D1740BB7A0626B4FAF0A65D377562FB@XCH-NW-01V.nw.nos.boeing.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> <E1829B60731D1740BB7A0626B4FAF0A65D8F24D917@XCH-NW-01V.nw.nos.boeing.com> <01db01cd6047$7ba38170$72ea8450$@com> <E1829B60731D1740BB7A0626B4FAF0A65D8F24D996@XCH-NW-01V.nw.nos.boeing.com> <02ba01cd6057$fbbab170$f3301450$@com>
In-Reply-To: <02ba01cd6057$fbbab170$f3301450$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: No
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 12 Jul 2012 20:01:40 -0000

Hi Dan,

> The engineering effort to improve this situation is closely tied
> to how severe the problem really is, and how often we hit the
> small MTU layer 2 links (that draft-generic-6man-tunfrag is
> trying to fix) and how often we hit IPv6/IPv4 translators (that
> the last paragraph of Section 5 of RFC2460 is trying to fix, but
> doesn't quite handle well with stateless IPv6/IPv4 translators).
> 
> Myself, I am frustrated with layer 2 networks that have smaller
> than 1500 byte MTUs, because we know anything that looks like
> Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and
> technologies that don't look like Ethernet have enjoyed less
> success.  Can we expect those networks to fail in the market,
> or to look enough like Ethernet that IP works well on top of
> them, making draft-generic-6man-tunfrag unnecessary?  There
> is a similar question for IPv6/IPv4 translators -- will they
> persist long enough to make the engineering effort to improve
> that last paragraph in Section 5 of RFC2460 worth while, and
> will we see deployment in IPv6 hosts while there are still
> IPv6/IPv4 translators?

About this, one thing I think we can agree on is that the
value 1280 is in no way significant to IPv4 nodes. So, the
final paragraph in Section 5 of RFC2460 might just as well
be adjusted to say that the node is not required to reduce
the size of its subsequent packets to less than 1500 bytes
(not 1280).

Thanks - Fred