>
> Sure, the tunnel ingress can probe the path to the egress; such a
> probing method is already covered by SEAL.
Most GRE implementations do this, too.
But, if the path MTU will
> not accommodate a packet that after encapsulation is as large as
> (1280 + HLEN) there is no alternative for the ingress other than to
> start fragmenting since the ingress is not allowed to send a PTB
> message reporting a size smaller than 1280.
I understand that you want to solve for the use-case in which a tunnel interior
link has MTU < (1280 + HLEN). But before solving for that use-case, we need to
do a cost/benefit analysis.
We understand the cost of solving for this use-case. The task of reassembly is
moved to the egress router. So, we need to make sure that the egress router is
large enough to handle the task of reassembly and we need to make sure that its
resources cannot be monopolized by a DoS attack. We also have to maintain our
fragmentation capability.
Note that some of the cost is absorbed by the owner of the egress router.
However, a portion of the cost is absorbed by the entire community, as they
deal with the operation complexity associated with fragmentation.
Now let's try to understand the benefit. Is there an installed base of
IPv6-capable links with MTU < (1280 + HLEN) that carry traffic between tunnel
endpoints? Is there a reason why someone might want to design a network this
way?
If we were to solve for this use-case, who would be the beneficiary? Possibly
the party deploying the MTU-challenged link? Or, asked another way, would cost
be assigned to the beneficiary?
Ron
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
