Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'

Joe Touch <> Sat, 01 September 2018 02:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F30B124BE5 for <>; Fri, 31 Aug 2018 19:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6eieDg56EJr8 for <>; Fri, 31 Aug 2018 19:16:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3073B130E90 for <>; Fri, 31 Aug 2018 19:16:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0LmWBOhpveFEe3/ZstvQ1sTFWhkTnTZqRrTBxy6AvS4=; b=o24PuVTaGezcMJyP3/4SYQuD7 +Ns1RhIVU8ppZjW0mJmypCJq+BMBMNSIHW05sulYs5kE+JV6pdybh29Pua8N5CT++u1+9rdKFgeIR rKlwQgIs8lm/l3FbpurLby73BkLz+Mnnt8AxVA1Pn+9d78UDarT7VeQJMAB46xnOMc7L9JYVz/uIX fc4INB9EjPqhyItJWdp+04SlqBD1TcYXdBzbUQBZQFmpWLGwvsrTJbkTRVG4SafMoQYuZBoQQe+EF MAJRmAyJAy+kZSEL7MpTfCXvsKk/K/kdjEgsNSVyz/jdZXC4rQf+3VLuN+9V/wwfqC13Y+f2KzhUO yZ0DUf/Xw==;
Received: from ([]:52070 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1fvvSz-0043iH-KQ; Fri, 31 Aug 2018 22:16:50 -0400
To: "Templin (US), Fred L" <>, Tom Herbert <>
Cc: "" <>
References: <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Fri, 31 Aug 2018 19:16:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------B502C7F65600580AD395D763"
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Sep 2018 02:16:55 -0000

Hi, all,

On 8/30/2018 8:29 AM, Templin (US), Fred L wrote:
>>> Section 3.2.1:
>>> Final paragraph beginning: "IP protocol number 59 ("No next header") can be set
>>> to indicate that the GUE payload does not begin with the header of an IP protocol."
>>> The example given was GUE fragmentation, but would that not represent a
>>> departure from the way things are done for IP fragmentation? I believe in
>>> IP fragmentation the protocol field contains the same value for both initial
>>> and non-initial fragments. Is there a reason for the departure here?
>> Yes. GUE allows a node to skip over the GUE header to inspect the
>> encapsulated payload, For instance, a firewall may be looking for an
>> inner IP destination in an encapsulated packet. The GUE payload is
>> interpreted based on the protocol in the Proto/ctype field. So if the
>> payload is not a parseable IP protocol (like it would be for a
>> non-first GUE fragment), then 59 is used to avoid devices trying to
>> parse it.
> I am OK with ipproto-59. In hindsight, maybe IP fragmentation should have
> adopted a similar convention when it was specified so many decades ago.
FWIW, IP fragmentation copies the IP header in each fragment because
that field is part of the context for the ID field; i.e., ID MUST be
unique within src/dst/proto. If fragments had a different proto field,
it would undermine that context.