On Wed, Jun 1, 2016 at 4:36 PM, Joe Touch <[email protected]> wrote:
>
>
> On 6/1/2016 3:50 PM, Templin, Fred L wrote:
>> Any tunnel that traverses a 1280 link has to fragment, but instead of outer
>> fragmentation
>> it should use tunnel fragmentation which is something I have been
>> advocating for a very
>> long time. The tunnel egress should configure at least a 2KB reassembly
>> buffer size.
>
> If the only layer you have that fragments is the outermost IP, that's
> where you MUST do it.
>
> Sure, if you can fragment at an intermediate "transport" layer inside of
> IP, that's also an option. I'm not sure why it should be preferred
> except for the flaws of current equipment in supporting standards, though.
>
We defined fragmentation option in GUE
(draft-herbert-gue-fragmentation-02). The listed benefits are:
o A 32 bit identifier can be defined to avoid issues of the 16 bit
Identification in IPv4.
o Encapsulation mechanisms for security and identification such as
virtual network identifiers can be applied to each segment.
o This allows the possibility of using alternate fragmentation and
reassembly algorithms (e.g. fragmentation with Forward Error
Correction).
o Fragmentation is transparent to the underlying network so it is
unlikely that fragmented packet will be unconditionally dropped
as might happen with IP fragmentation.
We should probably add that all fragments will have the same outer
addresses and UDP ports in the encapsulation so it is likely that all
the fragments will follow the same path. Security means that we can
cover fragmentation information with checksum or stronger integrity
checks.
This option probably only makes use of fragmentation a little more
palatable, but doesn't change the fact that it's better to avoid
having to fragment in the first place if at all possible ;-).
Tom
> Joe
>
> _______________________________________________
> 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
