On 3/25/2015 9:58 PM, Tom Herbert wrote:
> This draft describes a fragmentation option for GUE. The option is
> intended for use cases where GUE is used over a network where we might
> not be able to control or know what the link MTUs in a tunnel are.
> This also provides a answer to the interesting degenerative case where
> someone configures an MTU of 1280 on the link and there is an attempt
> to encapsulate an IPv6 packet of size 1280-- in this case the packet
> size + encapsulation > link MTU & we cannot send a ICMP PTB since 1280
> is specified minimum MTU for IPv6.
>
> This describes only the mechanics of fragmentation/reassembly in GUE.
> It does cover the the semantics of use such as how to determine tunnel
> Path MTU, when to fragment.
FWIW, there are a few issues that should be addressed. RFC4459 suggests
a taxonomy, but it's informational (and IMO incorrect) on a few points.
Below are suggestions.
Joe
---
Section 1, also Sec 3.1:
There are two separate trigger points for MTU handling:
A- the tunnel path MTU
this is defined by the protocols over
which the tunnel is defined to operate
B- the tunnel egress reassembly maximum
this is specified by the tunnel protocol
description
The following cases should be handled as follows:
1. encaps packet <= A
send as-is
2. A < encaps packet <= B
fragment and reassemble
3. encaps packet >B
drop and send PTB
If you don't want to ever do frag/reassembly, then make sure A=B.
Note that A cannot match B whenever a tunnel mechanism is used
"recursively", e.g., GUE over GUE, even indirectly (GUE over IP over GUE).
---
The wrap of the IPv4 frag field and the impact of avoiding fragmentation
is described in RFC 6864.
---
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
