> > 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"?
Yes, specifically networks where a GMTU < 1280 always indicates a problem. > Section 7 of RFC2473 already provides guidance that applies also > to GRE in any use case. Ok, as previously noted - the text here is specific to GRE and certain networks. > > 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. Right now, the exception case is proposed as GRE-only, and hence is appropriate for this draft. I hesitate to generalize it to all IPv6 tunnels or have the GRE provisions await that being done. Thanks, --David > -----Original Message----- > From: Templin, Fred L [mailto:[email protected]] > Sent: Wednesday, April 01, 2015 5:34 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 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]; intarea- > [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]; intarea- > [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; draft-ietf-intarea-gre- > [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
