It's not clear that this document substantially adds to what is already covered in RFC2003 (IPv4 in IPv4), which is (surprisingly) not even cited.
Additionally, sec 3.4 discusses the 'clear the DF bit' behavior; it is worth noting that this violates 2003 sec 3.1, but is what is specified in 2401 appendix B.1 (and retained in 2401bis, which is worth citing as well). Joe Pekka Savola wrote: > Hi, > > As presented in the int-area meeting, please read and comment on the > draft. It should be getting to IETF LC soon. It's very short and > concise (10 pages of meat). > > A few answers to the questions asked and some notes: > > - the target audience is both the IETF [tunneling] protocol designers, > and the operators considering which tunneling approach to take. > > - the document has in the past been reviewed and well-regarded on > operational fora e.g. nanog. It has also gone through pmtud WG. > > - I've specifically wanted to avoid giving too rigid guidance, but > section 4 (Conclusions) gives some amount of guidance as to when > different approaches may or may not be applicable. > > - more generic tunneling issues (why they are used in the first place) > or overhead issues are interesting but seem out of scope of this > (focused) effort. (e.g., effect of sometimes piggybacking some data in > e.g., an extension header and sometimes not; this seems like an issue > for for a joint apps/int area investigation) > > ..... > > MTU and Fragmentation Issues with In-the-Network Tunneling > draft-savola-mtufrag-network-tunneling-04.txt > > Abstract > Tunneling techniques such as IP-in-IP when deployed in the middle of > the network, typically between routers, have certain issues regarding > how large packets can be handled: whether such packets would be > fragmented and reassembled (and how), whether Path MTU Discovery > would be used, or how this scenario could be operationally avoided. > This memo justifies why this is a common, non-trivial problem, and > goes on to describe the different solutions and their characteristics > at some length. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
