On 2/27/2015 10:25 AM, Templin, Fred L wrote:
...
Or pick another path. Or break.
I don't see anything in the standards that would support either of those
behaviors. A node that does not handle PTB with MTU<1280 as specified
in Section 5 of RFC2460 is not compliant with the standards.
Breaking is what happens when we rely on a code path we don't typically
use. Yes, it's not compliant.
Nothing in IP REQUIRES an endpoint to "try harder" when it gets an error
message, though. It can always either give up or try another path -
that's compliant.
The tunnel ingress will then know that it is dealing
with a legacy source,
Hosts already generate atomic fragments for other reasons, so that
itself isn't enough to "KNOW" anything.
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.
and will fragment the payload packet using the
fragment header conveniently provided by the source.
That's a violation of on-path fragmentation. RFC2460 gives a very
specific reason for those - focusing on IPv6/IPv4 translation:
...In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments.
It should not be so much of a stretch to update RFC2460 to allow tunnels
to use the supplied fragment header to fragment the original packet.
It's a huge stretch to change IPv6 from "never fragment on-path" to
"fragment on-path".
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
