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.temp...@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 > > >
