Hi David, > -----Original Message----- > From: Black, David [mailto:[email protected]] > Sent: Wednesday, April 01, 2015 1:26 PM > To: Templin, Fred L; [email protected]; [email protected] > Cc: [email protected]; [email protected]; > Black, David > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration > > Fred, > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > I agree with the text quoted above, > > Adding the rest of the sentence ... > > > > but what I'm observing is that there > > > are networks for which GMTU is an indication that something is wrong > > > (this is a consequence of operator decisions that are specific to such > > > a network). > > > OK, then this document should cite Section 7 of RFC2473 normatively. > > I think it would be better to directly explain the GRE situation here, and > add an informative citation of RFC 2473 as providing additional explanation, > particularly for situations in which different operational practices are used.
How is the GRE situation any different than for any generic encapsulation in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific use cases"? Section 7 of RFC2473 already provides guidance that applies also to GRE in any use case. > > If there is operational assurance that all links in the tunnel path > > configure > > a sufficiently large MTU, and there will never be a nesting of tunnels that > > would result in a too-small MTU, then tunnel fragmentation would not > > need to be invoked and there is no need to talk about sending PTBs with > > GMTU less than 1280. > > Never say "never" ... quoting RFC 5706, "Anything that can be configured can > be misconfigured." ;-). Right, that's what I said (having used that phrase many times in the past myself). > I'll leave the rationale for sending PTBs to Ron, but keep in mind that > "running code" (i.e., existing implementations) is(are) an important > consideration - see the second sentence in the Introduction. Sending PTB with MTU<1280 is supposed to have an effect as described in Section 5 of RFC. Namely, the original source is supposed to start including IPv6 fragment headers in subsequent packets and the network is supposed to find some way to get them through. What Ron's text is suggesting is that the original source lives up to its part of the bargain but then the network dumps the packets into a black hole. > > Or, if you did want to include text that would tell > > what to do in the case of misconfigurations, then this document would > > need to update RFC2473 since the same considerations apply to generic > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > It's more than misconfigurations - attacks on PMTU monitoring can have > similar effects. If you want to start talking about PTB forgery, then we should also talk about PTB filtering and how the mechanisms work when PTBs are lost. RFC2473 itself is imperfect in that regard, and this draft is not proposing anything different than RFC2473. > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not > cite RFC 2473); I think a separate draft would be more appropriate. OK, then have this draft simply cite RFC2473, Section 7 normatively and break the exception cases out into a separate document like intarea-tunnels. The exception cases are not limited to GRE in particular, and apply also to any generic tunneling in IPv6. Thanks - Fred [email protected] > Thanks, > --David > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Wednesday, April 01, 2015 12:12 PM > > To: Black, David; [email protected]; [email protected] > > Cc: [email protected]; [email protected] > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration > > > > Hi David, > > > > > -----Original Message----- > > > From: Black, David [mailto:[email protected]] > > > Sent: Wednesday, April 01, 2015 8:43 AM > > > To: Templin, Fred L; [email protected]; [email protected] > > > Cc: [email protected]; [email protected]; > > Black, David > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > configuration > > > > > > Fred, > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > I agree with the text quoted above, > > > > OK, then this document should cite Section 7 of RFC2473 normatively. > > > > > but what I'm observing is that there > > > are networks for which GMTU is an indication that something is wrong > > > (this is a consequence of operator decisions that are specific to such > > > a network). The alternative configuration is intended for such networks, > > > but is not intended for all networks, and would need to be qualified > > > with words making it applicable primarily or only (or suggest some > > > other words) to such networks. > > > > If there is operational assurance that all links in the tunnel path > > configure > > a sufficiently large MTU, and there will never be a nesting of tunnels that > > would result in a too-small MTU, then tunnel fragmentation would not > > need to be invoked and there is no need to talk about sending PTBs with > > GMTU less than 1280. Or, if you did want to include text that would tell > > what to do in the case of misconfigurations, then this document would > > need to update RFC2473 since the same considerations apply to generic > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > Thanks - Fred > > [email protected] > > > > > Upshot: the use of "necessarily" in the text quoted above is correct, but > > > misses the point. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:[email protected]] > > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > > To: Black, David; [email protected]; [email protected] > > > > Cc: [email protected]; [email protected] > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > configuration > > > > > > > > Hi David, > > > > > > > > > -----Original Message----- > > > > > From: Black, David [mailto:[email protected]] > > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > > To: Templin, Fred L; [email protected]; [email protected] > > > > > Cc: [email protected]; > > > > > [email protected]; > > > > Black, David > > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > > > configuration > > > > > > > > > > So, I talked to Ron off-list and it looks like something is missing > > > > > from > > > > > this discussion. > > > > > > > > > > The "alternative configuration" is not motivated by a desire to allow > > > > > implementation flexibility or bless broken implementations. It's > > motivated > > > > > by consideration of networks with operational practices wherein a GMTU > > of > > > > > less than 1280 octets is evidence that something is seriously wrong. > > That > > > > > something might be misconfiguration (quoting RFC 5706, "Anything that > > > > > can be configured can be misconfigured."), or an attack on the GRE > > > > > ingress's PMTU estimation. > > > > > > > > > > So, in the situation of interest (GMTU < 1280) something is wrong, and > > > > > the operator may be faced with a Hobson's choice: either blackhole the > > > > > traffic that can no longer be sent without fragmentation, or fragment > > > > > a > > > > > lot of traffic, causing problems at the GRE egress by overwhelming its > > > > > reassembly code - there may be good operational and/or security > > > > > reasons > > > > > to not want to do the latter. All of this ought to be explained in > > > > > the > > > > > draft. > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > > > Thanks - Fred > > > > [email protected] > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > -----Original Message----- > > > > > > From: Int-area [mailto:[email protected]] On Behalf Of > > Templin, > > > > Fred L > > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > > To: Ronald Bonica; [email protected]; [email protected] > > > > > > Cc: [email protected]; intarea- > > [email protected] > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ronald Bonica [mailto:[email protected]] > > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > > To: Templin, Fred L; [email protected]; [email protected] > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > [email protected]; > > > > > > [email protected] > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre- > > ipv6 > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > It appears that we disagree and have taken to repeating ourselves. > > > > > > > > > > > > This is not a disagreement; this is a case in which the text is > > actually > > > > > > broken > > > > > > which you have more or less acknowledged. You can fix the text in > > question > > > > > > as follows: > > > > > > > > > > > > OLD: > > > > > > **** > > > > > > In its default configuration, the GRE ingress router MUST: > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header and > > > > > > IP > > > > > > delivery header > > > > > > > > > > > > o fragment the delivery header, so that it can be reassembled by > > the > > > > > > GRE egress > > > > > > > > > > > > However, in an alternative configuration, the GRE ingress MAY: > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the > > IPv6 > > > > > > packet source. The MTU field in the ICMPv6 PTB message is set > > to > > > > > > the GMTU. > > > > > > > > > > > > NEW: > > > > > > **** > > > > > > The GRE ingress router MUST: > > > > > > > > > > > > o if the IPv6 payload packet includes a fragment header, > > > > > > fragment > > the > > > > > > payload packet into fragments no larger than the GMTU and > > > > encapsulate > > > > > > each fragment in a single GRE header and IP delivery header. > > > > Otherwise: > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header > > > > > > and > > IP > > > > > > delivery header > > > > > > > > > > > > o fragment the delivery packet, so that it can be reassembled > > > > > > by > > the > > > > > > GRE egress > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the > > IPv6 > > > > > > packet source, subject to rate limiting. The MTU field in > > the > > > > ICMPv6 > > > > > > PTB > > > > > > message is set to the GMTU. > > > > > > > > > > > > > So, why don't we solicit opinions from the rest of the WG and > > > > > > > defer > > to > > > > their > > > > > > will. > > > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text through > > > > > > the > > > > > > process based on popular opinion does not make it good. > > > > > > > > > > > > Thanks - Fred > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Templin, Fred L [mailto:[email protected]] > > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > > To: Ronald Bonica; [email protected]; [email protected] > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > [email protected]; > > > > > > intarea- > > > > > > > > [email protected] > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > draft-ietf-intarea-gre- > > ipv6 > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes > > > > > > > > and > > so > > > > the > > > > > > > > design must account for tunnel paths that include links with > > > > > > > > such > > a > > > > small > > > > > > > > MTU. The design must also account for nested tunnels-within- > > tunnels, > > > > > > > > where the MTU seen by the first tunnel ingress may be reduced by > > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot > > legitimately > > > > send > > > > > > PTBs > > > > > > > > that report a size smaller than 1280 *and* perpetually drop > > packets > > > > > > smaller > > > > > > > > than 1280 which is exactly the behavior your text is permitting. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ronald Bonica [mailto:[email protected]] > > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > > To: Templin, Fred L; [email protected]; [email protected] > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > [email protected]; > > > > > > > > > [email protected] > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea- > > gre- > > > > ipv6 > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > In the last network that I operated, all interior links had > > > > > > > > > MTU > > > > > > > > > greater than 9k. If I configured a GRE tunnel between two > > > > > > > > > points > > in > > > > that > > > > > > > > network and detected a GMTU less than 1280, it would have > > indicated > > > > one of > > > > > > > > the following: > > > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in how their > > networks > > > > > > > > > would behave. Why deny them this flexibility by taking away > > > > > > > > > the > > > > > > > > configuration option? > > > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packet that > > might > > > > > > degrade > > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Templin, Fred L [mailto:[email protected]] > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > > To: Ronald Bonica; [email protected]; [email protected] > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > [email protected]; > > > > > > > > > > intarea- [email protected] > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Ronald Bonica [mailto:[email protected]] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > > To: Templin, Fred L; [email protected]; [email protected] > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > [email protected]; > > > > > > > > > > > [email protected] > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in which > > > > > > > > > > > all > > > > links > > > > > > > > > > > have MTU greater than or equal to 1500. In those networks, > > the > > > > > > > > > > > very detection of a GMTU smaller than 1280 indicates > > brokenness. > > > > > > > > > > > Those > > > > > > > > > > operators, the alternative behavior may be preferable to the > > > > default. > > > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the > > > > > > > > > > link > > must > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does not > > indicate > > > > > > > > > > brokennesss; it can naturally happen if 1) there is a link > > with a > > > > > > > > > > small MTU in the path, or > > > > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 is a > > > > > > > > > > no- > > no, > > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Templin, Fred L [mailto:[email protected]] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > > To: Ronald Bonica; [email protected]; [email protected] > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > [email protected]; > > > > > > > > > > > > intarea- [email protected] > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Ronald Bonica [mailto:[email protected]] > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > > To: [email protected]; [email protected] > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > > [email protected]; > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, the > > > > > > > > > > > > > > GRE > > > > ingress > > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] > > > > message > > > > > > > > > > > > > > to the > > > > > > > > > > IPv6 > > > > > > > > > > > > > > packet source. The MTU field in the ICMPv6 > > > > > > > > > > > > > > PTB > > > > message > > > > > > is set > > > > > > > > to > > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when the > > GRE > > > > > > > > > > > > > > ingress sends a PTB reporting a size less than 1280. > > > > > > > > > > > > > > According to RFC2460, Section 5, the standard > > > > > > > > > > > > > > behavior > > for > > > > a > > > > > > > > > > > > > > host that receives > > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > > is not required to reduce the size of subsequent > > packets > > > > to > > > > > > less > > > > > > > > than > > > > > > > > > > > > > > 1280, but must include a Fragment header in those > > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a > > perpetual > > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280 which is > > > > > > > > > > > > > > probably not what we > > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > All true. This is why the WG decided to make this the > > > > > > > > > > > > > alternative behavior > > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless of > > whether > > > > it > > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide > > > > guidance > > > > > > > > > > > > > > to hosts on how to react to PTB messages that > > > > > > > > > > > > > > report a > > > > small > > > > > > size. > > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in > > > > > > > > > > > > > Section > > 5 or > > > > > > > > > > > > > RFC > > > > > > > > > > > > > 246 are > > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision > > > > > > > > > > > > > regarding > > the > > > > > > > > > > > > > current > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether > > alternative > > > > or > > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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
