RE: Meta-issues: On the deprecation of the fragmentation function

[Ronald Bonica <[e-mail]>]

> 
> 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