Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Tuesday, February 24, 2015 10:06 AM > To: Templin, Fred L; Joe Touch; [email protected] > Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6 > > Fred, > > The problems of PTB loss and forgery apply to IPv6 fragmentation in general. > They are not specific to GRE tunneling. Therefore, they > are beyond the scope of the current draft. > > I invite you to a thought experiment. Imagine a network. At one end of the > network is a GRE ingress and at the other end is a GRE > egress. Both tunneled and non-tunneled traffic traverse the network. > > The network drops ICMP PTBs. To make matters worse, somebody is forging ICMP > PTBs. How do these impact tunneled packets > differently from non-tunneled?
That is an end system problem, and for that we have RFC4821. End systems have become conditioned to expect 1500 byte packets to be delivered or a suitable PTB message returned. If the tunnel cannot guarantee that a suitable PTB message can be returned, then it needs to do 1500 minimum. Thanks - Fred [email protected] > > Ron > > > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Tuesday, February 24, 2015 12:45 PM > > To: Ronald Bonica; Joe Touch; [email protected] > > Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:[email protected]] > > > Sent: Tuesday, February 24, 2015 9:40 AM > > > To: Joe Touch; Templin, Fred L; [email protected] > > > Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > > > Joe, > > > > > > Because RFC 2784 is PS, and this document UPDATES the procedures > > > defined in RFC 2784, we have no choice but to ask for PS. (You can't > > UPDATE a PS with INFORMATIONAL). > > > > > > So, I guess we have no choice other than to discuss what should be. > > > > > > Please make your case that what we have in draft-ietf-intarea-gre-ipv6 is > > not what should be. > > > > The case is already made that the PTB messages this document relies on can > > be lost or forged, resulting in a black hole or degenerate MTUs. So what > > should be is correct continuous operation even when PTB messages are lost > > or forged. > > > > Thanks - Fred > > [email protected] > > > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Joe Touch [mailto:[email protected]] > > > > Sent: Tuesday, February 24, 2015 12:24 PM > > > > To: Templin, Fred L; Ronald Bonica; [email protected] > > > > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > On 2/24/2015 9:20 AM, Templin, Fred L wrote: > > > > > Hi Ron, > > > > > > > > > >> -----Original Message----- > > > > >> From: Ronald Bonica [mailto:[email protected]] > > > > >> Sent: Tuesday, February 24, 2015 9:13 AM > > > > >> To: Joe Touch; Templin, Fred L; [email protected] > > > > >> Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > >> > > > > >> Joe, > > > > >> > > > > >> The latter. The following is text from the draft: > > > > >> > > > > >> " This document specifies GRE procedures for IPv6, used as either the > > > > >> payload or delivery protocol. It updates RFC 2784 [RFC2784]. > > > > >> Like > > > > >> RFC 2784, this specification describes GRE how has been > > implemented > > > > >> by several vendors." > > > > > > > > > > You are asking for Proposed Standards status. That goes beyond > > > > > documenting just "what is", and specifies once and for all "what > > > > > will forever > > > > be". > > > > > > > > This document will forever be "what is currently commonly used". > > > > > > > > We've been around the block on "let's describe what SHOULD be, but > > > > isn't deployed". While I agree that's important, that is not the > > > > function of this document. > > > > > > > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
