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

[Tom Herbert <[e-mail]>]

On Fri, Aug 31, 2018 at 7:16 PM, Joe Touch <[e-mail]> wrote:
> 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.
>
Hi Joe,

The GUE fragmentation option includes a orig-proto field to hold the
protocol of the reassembled packet. That needs to be matched in all
fragments along with srd/dst and ID, Also the protocol field in the
GUE header of the first fragment must also match. So the ID space is
basically defined the same way as IP fragmentation.

Tom

> Joe