Templin, Fred L wrote:
Also, when IPv4 is used as the outer encapsulation layer, the 16-bit ID field can result in reassembly errors at high data rates [RFC4963].
As your proposal, too, gives up to have unique IDs, does that matter? Note that, with your draft, a route change between two tunnels with same C may cause block corruption.
Additionally, encapsulating a 1500 inner packet in an outer IP header results in a 1500+ outer packet - and the ingress has no way of knowing whether the egress is capable of reassembling larger than 1500.
Operators are responsible to have tunnel end points with sufficient capabilities.
(With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte MTU on the tunnel, fragment the outer packet, let the other end of the tunnel do the reassembly. Not providing 1500 byte end-to-end (at least with in the network I control) for IPv4 has proven to consume lots of troubleshooting time; fragmenting the inner packet doesn't work unless you ignore the DF bit that is typically set by TCP endpoints who want to do PMTU discovery.)
Ignoring the (explicit) DF bit for IPv4 and ignoring the (implicit) DF bit for IPv6 is what I am suggesting.
Thanks - Fred fred.l.templin@boeing.com
I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint?
-- Brett