Re: "Deprecate"

Mark Andrews <marka@isc.org> Fri, 02 August 2013 01:32 UTC

Return-Path: <marka@isc.org>
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 3B1EF21E829E for <ipv6@ietfa.amsl.com>; Thu, 1 Aug 2013 18:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0e50xlVBon4v for <ipv6@ietfa.amsl.com>; Thu, 1 Aug 2013 18:32:43 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 350CF11E8433 for <ipv6@ietf.org>; Thu, 1 Aug 2013 17:36:05 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F131CC944A; Fri, 2 Aug 2013 00:35:51 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375403764; bh=OujrC5rmkly5yCK+vPzeRH0eCgDsfqX26MCJ7M/mA34=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Z8TUBH7XSyJDUQ63XHw1RH+xF1j9rT4zBaL578z9dEnYAKx3tcUYf3JGKm0q+WCta STsmyzkIQPDuz0OVSuDYdEGG5nJGMwtJrEaBthwIImO2fSz1+g0Ed5WUgcgQTDStjq EyA+JvdCE4ekR+ie+IqgJYZrrc5ceTNPaLbjMo94=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 2 Aug 2013 00:35:51 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B000B160306; Fri, 2 Aug 2013 00:39:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nlwEXhyFIPew; Fri, 2 Aug 2013 00:39:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 69A78160305; Fri, 2 Aug 2013 00:39:41 +0000 (UTC)
Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3B7A4160303; Fri, 2 Aug 2013 00:39:41 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 71BB137EE821; Fri, 2 Aug 2013 10:35:47 +1000 (EST)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
From: Mark Andrews <marka@isc.org>
References: <FAD482FE-4583-472A-8B57-E789A942686E@gmail.com> <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <DEDA9E45-2839-4D7C-9D86-04360DDE9C1D@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com>
Subject: Re: "Deprecate"
In-reply-to: Your message of "Thu, 01 Aug 2013 22:40:51 +0000." <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com>
Date: Fri, 02 Aug 2013 10:35:47 +1000
Message-Id: <20130802003547.71BB137EE821@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, RJ Atkinson <rja.lists@gmail.com>
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: Fri, 02 Aug 2013 01:32:54 -0000

In message <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.co
m>, "Templin, Fred L" writes:
> Hi Ran,
> 
> > Discussion:
> >    Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode,
> >    or some other IETF specified technology, are NOT going away.
> 
> Yes, this is the same as I and others have been saying all along.
> 
> > If the physical MTU is 1280, then the tunnel MTU will be smaller.
> 
> Not allowed; the tunnel MUST be able to do a minimum 1280.
> 
> >   Nested tunnels are not unusual and can be difficult to detect
> >   absent a working PMTUD mechanism (whatever that might be).
> 
> Agree that nested tunnels are not unusual and are in fact in
> common widespread deployment. But, there is no need to "detect"
> them from the source host's perspective as long as they honor
> the IPv6 1280 minMTU. That means that tunnels MUST be prepared
> to do a small amount of fragmentation and reassembly when
> necessary.

And if we generate appoximately equal sized fragments rather than
1280 byte fragments + a runt fragment tunnels would need to fragment
less often.  Your 1500 byte UDP payloads become 2 x 750 byte fragments
which can be encapulated multiple times.

It doesn't take a lot of math to work out what size to fragment at to
produce optimal fragment sizes for a given MTU.

Mark

> Thanks - Fred
> fred.l.templin@boeing.com
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org