Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

Joe Touch <> Wed, 17 May 2017 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7218E127369 for <>; Wed, 17 May 2017 11:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M-5xESB3Erkm for <>; Wed, 17 May 2017 11:57:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23721126CD6 for <>; Wed, 17 May 2017 11:52:38 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v4HIqF9F009577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 11:52:15 -0700 (PDT)
To: "Templin, Fred L" <>
Cc: "" <>
References: <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 17 May 2017 11:52:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 May 2017 18:57:47 -0000

Hi, Fred,

Circling back to this item:

On 3/29/2017 2:18 PM, Templin, Fred L wrote:
> One other comment. I agree with figures 12 and 13 but (and I think this is
> a crucial point) I think they need a supporting sentence or two explaining
> why the procedure is "fragment then encapsulate" and not "encapsulate
> then fragment".
Will do.

> This is the difference between tunnel fragmentation
> and ordinary outer fragmentation, where your document is correctly
> advocating tunnel fragmentation.
Yeah, but I was unable to find definitive and RFC citations for those
terms ("inner fragmentation" and "outer fragmentation"). 4459 mentions
fragmentation of 'inner' and 'outer', but those terms go back to 2003
and before, and I'm not sure warrant a citation.

> To the best of my knowledge, this was
> first documented in Section 3.1.7 of RFC2764 and should be cited as such.
> At least, that is what Bob B. suggested to me about 10yrs ago.
The idea of differentiating inner and outer fragmentation goes back to
RFC2003 at least, AFAICT.

That section of RFC2764 mentions that outer fragmentation avoids
fragmentation inside the tunnel, but doesn't recommend it (it just says
"alternative"). Further, it claims that none of the existing tunneling
protocols support this (even though RFC2003 does).

I'm not convinced this is worth tracking down for its origins. Let me
know if you feel otherwise, but we'd need stronger evidence AFAICT.