On 2/27/2015 10:45 AM, Templin, Fred L wrote:
Hi Joe,
...
Generation of atomic fragments for any reason is sufficient information
for the tunnel ingress to make a determination to fragment or drop
based on the size of the atomic fragment.
The former is a direct violation of RFC2460. The latter is what
could/should have been done in the first place when the PTB was sent.
Network fragmentation of IPv6 packets that do not include a fragment
header is the behavior that is prohibited by the specs. Fragmentation
of IPv6 packets that include a fragment header is already mandated
for IPv6/IPv4 translators. So, given there is already one example of
network fragmentation we are simply introducing another example.
If you use the atomic fragment ID to generate an ID for the tunnel
encapsulation and fragment THAT, yes.
If you intend to fragment the atomic arriving datagram, no. That's not
what the atomic ID is for - it is intended to provide an identifier for
the tunnel, not to allow on-path fragmentation of the original datagram.
...
It's a huge stretch to change IPv6 from "never fragment on-path" to
"fragment on-path".
"Fragment on-path" is already mandated for IPv6/IPv4 translators.
No; that's fragmenting at IPv4, i.e., the outer header. That's always
been allowed.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
