Two of my messages to the list were blocked so I am converting to plaintext and re-responding to Ron below. Ron, can you respond to my points?
Thanks - Fred [email protected] >> See Section 5 of: >> >> https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/ > > Fred, > > This draft expires on Saturday. Do you know if Fernando intends to refresh it? > Does it appear to have traction in 6man? I do not know. It was presented during 6man at one of the recent IETFs (last one or the one before; don’t remember) and I argued against it because I think there is value in retaining the RFC2460 text. > Even if this draft one day becomes an RFC, it wouldn’t change > draft-ietf-intarea-gre-ipv6. It would only influence how people set the > configuration option described at the bottom of Section 3.1. That would be a shame, because then the method would then revert completely to RFC2473-mode. What makes your proposal interesting is the opportunity for the tunnel ingress to fragment the payload packet (instead of the delivery packet) which removes the reassembly burden from the egress. However, it only works if you can somehow coax the original source to include a fragment header which it seems Fernando’s draft would prevent. I have proposed sending PTB with MTU less than 1280 before as well: http://www.ietf.org/archive/id/draft-templin-6man-linkadapt-01.txt The idea is to enlist the original source’s aid in easing the frag/reass burdens from the tunnel ingress and egress. It is similar to what you are proposing, but did not say that the ingress could fragment the payload packet. Rather, it wanted for the original source to do the fragmentation. However, there is one fundamental flaw in this entire line of reasoning – it requires reliable and authentic delivery of PTB messages in an unreliable and untrustworthy Internet. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
