IMO, this doc should:
- document existing default behavior
- if needed, recommend SHOULD-level changes to
that default behavior via currently-available
configuration or deployment changes
I.e., describe where it can be used in a way consistent with existing
requirements, or indicate where that isn't the case and how it can be
detected and what to do when that happens.
I had already proposed a solution to this case, e.g., if the tunnel
cannot support the required IPv6 (or IPv4, for that matter) minimums, it
should shut itself down.
I'd like to see the updated text before jumping to conclusions, but I
don't think we need yet another new, undeployed solution.
Joe
On 4/9/2015 10:36 AM, Ronald Bonica wrote:
> Fred,
>
> How would you achieve backwards compatibility with legacy implementations? If
> backwards compatibility cannot be achieved, maybe you are talking about a new
> protocol, that will ultimately replace GRE?
>
> Ron
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title : GRE Tunnel Fragmentation
>> Author : Fred L. Templin
>> Filename : draft-templin-intarea-grefrag-00.txt
>> Pages : 5
>> Date : 2015-04-09
>>
>> Abstract:
>> GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet
>> when the delivery packet exceeds the tunnel MTU, or when otherwise
>> necessary. This can cause problems when unmitigated IPv4
>> fragemntation ensues, or when middleboxes drop IPv6 fragments
>> unconditionally. This document proposes GRE tunnel fragmentation
>> which avoids these pitfalls..
>>
>>
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
