The other comment about the multimtu is that it doesn't
completely solve the problems for IPv6-over-(foo)-over-IPv4
tunnels. The NDISC MTU probing aspect of multimtu (which I
have also proposed earlier) only tells you a size >= 1280
that the neighbor can receive, but it does not tell whether
the underlying IPv4 network is fragmenting. (Or, if not
fragmenting presently, it does not detect if fragmentation
ensues at a later time due to routing changes.)

SEAL takes care of this w/o the need for NDISC probing. It
also lets the tunnel use MTUs larger than 1280, which could
be problematic for existing IPv6-over-(foo)-over-IPv4 tunnels.
That said, SEAL can use the RA MTU options specified by
multimtu. The ingress tunnel endpoint can send an RS to an
egress tunnel endpoint to get an RA back with MTU options
telling how large the ETE can receive.

Fred
[EMAIL PROTECTED]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to