Pekka Savola wrote: > On Wed, 11 Oct 2006, Joe Touch wrote: >> RFC4301 still recommends that it is acceptable to clear the DF bit (sec >> 5.1.2.1), although it does so in the process of tunneling. That >> tunneling is (IMO) already covered in RFC2003, which (in sec 3.1) >> prohibits such behavior. Those cases are important to note, and to note >> that tunnels - of any kind - are a particularly vexing case as a result. >> See RFC4459 for more info. > > Note that in RFC 4301, 'clearing the DF bit' is in the context of new > outer (encapsulating) header. The original inner packet's DF bit is not > modified. So maybe you implied that fragmentation could be a > particularly serious issue especially between tunnel endpoints if those > don't set DF?
Yes. The issue is that the fragmentation won't get signalled back to the origin (internal) endpoint. > (Some implementations also allow modification of the inner DF bit as > described in 4459 but that's a separate topic..) > >> It's also worth noting - as others pointed out - that this is >> IPv4-specific, and that IPv6's prohibition of in-network fragmentation >> doesn't solve the problem (notably because a tunnel acts as an endpoint >> for its encapsulated packets, so tunnels remain a problem). > > I'm not sure what you mean by "doesn't solve the problem". IMO, it won't make fragmentation less likely. Tunneling will drive fragmentation up, i.e. > Certainly > there is still fragmentation in IPv6 world (see below), but I guess the > main issue with respect to this draft is whether it can be classified > "Very Harmful"? > > It's true that the tunnel encap/decap points may need to fragment and > reassemble the encapsulating packet in certain cases (see Section 7 of > RFC2473), but still there is 16 bits more of ID space, which is > significant improvement -- not enough for "Very Harmful" in my book. The 16 bits of ID space there can be _more_ limiting, not less. The protocol type is constant (IP inside), so the 16 bits is for all tunneled traffic. And tunnels can be aggregation points, which means that multiple IP sources sent over a tunnel use the same tunnel endpoint addresses. The only thing left is the IP ID field; all other fields are identical for tunneled traffic, which makes things worse, not better. Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
