Hi Ron, > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Ronald Bonica > Sent: Tuesday, February 24, 2015 6:22 AM > To: [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > Hi Fred, > > Inline....... > > > > > Message: 1 > > Date: Mon, 23 Feb 2015 16:50:27 +0000 > > From: "Templin, Fred L" <[email protected]> > > To: "[email protected]" <[email protected]> > > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > Message-ID: > > <2134F8430051B64F815C691A62D9831832DFB25B@XCH-BLV- > > 504.nw.nos.boeing.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > Hi, I have a comment on this document. 'draft-ietf-intarea-gre-ipv6' is very > > much in the same boat as RFC2473 in terms of MTU and Fragmentation > > considerations. So, why not just cite Sections 6.7 and 7 of RFC2473 instead > > of > > inventing new text here since the considerations are exactly the same? > > > [RPB] > > RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands to > reason that the two approaches would be similar.
Not similar - identical. > However, the text in RFC 2473 is a proper subset of the text in Section 3.1 > of draft-ietf-intarea-gre-ipv6. Since much of the text in > draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes > sense to restate the part that is also presented in RFC 2473. I disagree. RFC2473 is an already-published standard that specifies MTU and fragmentation considerations that apply also to this document. This document should therefore cite the RFC2473 text normatively. If you think there is something new to be said in this document, then that should also update RFC2473. But, I don't see where this document is saying anything new. > > But then, there would still be three problems inherent in both documents: > > > > 1) There may be no way for the tunnel ingress to determine the MTU on > > the path to the egress, e.g., if ICMP PTB messages are lost or somehow > > forged by an attacker > > > [RPB] > Isn't loss or forgery of PTB messages a well-known issue for IPv6, regardless > of whether any tunnels are involved? Tunnels can address these issues by ignoring ICMP PTB messages that report a size smaller than 1500 bytes. > > 2) ICMP PTB messages may be lost on the return path from the tunnel > > ingress to the original source > [RPB] > Same comment as above What is missing is a recommendation for original sources to use RFC4821. > > 3) Even in environments where 1) and 2) are not a matter of concern, the > > original source could see an MTU smaller than 1500. > [RPB] > This is addressed in Sections 4.1 of draft-ietf-intarea-gre-ipv6. What I mean is, if the tunnel does not support a guaranteed minimum MTU of 1500 bytes then a PTB message reporting a size less than 1500 bytes would need to be returned to the sender. If that PTB message is lost, the result is a black hole. So, what I am saying is that tunnels should support a guaranteed minimum MTU of 1500 bytes as in 'draft-templin-aerolink'. This is not addressed in your document. Thanks - Fred [email protected] > Ron > > > > > These issues are addressed by Section 3.13 of 'draft-templin-aerolink', > > which > > is applicable for all tunneling environments. What is in RFC2473 right now > > (and what 'draft-ietf-intarea-gre-ipv6' should be citing) is only > > applicable for > > controlled environments. > > > > Thanks - Fred > > [email protected] > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
