One more inline ... > -----Original Message----- > From: Templin, Fred L [mailto:[email protected]] > Sent: Wednesday, April 01, 2015 7:17 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 4:08 PM > > To: Templin, Fred L; [email protected]; [email protected] > > Cc: [email protected]; [email protected] > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration > > > > > > 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. > > OK, for specific use cases then, i.e., the same as for any generic > IPv6 encapsulation in specific use cases and not only for GRE. > > > > 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. > > Specific to certain networks, perhaps, but not specific to GRE. > > > > > 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. > > This is where we differ - there is nothing in this recommendation > that is specific to GRE - the recommendation applies to any generic > IPv6 encapsulation and is appropriate to only those use cases where > shutting down the tunnel altogether is preferable to allowing the > tunnel to fragment. This is a generic IPv6 encapsulation consideration; > not a GRE consideration.
The "running code" involved here is GRE. I am concerned that we lack the foundation to update 2473 for all encapsulated protocols. > > Thanks - Fred > [email protected] > > > 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]; 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: Wednesday, April 01, 2015 8:43 AM > > > > > > To: Templin, Fred L; [email protected]; [email protected] > > > > > > Cc: [email protected]; intarea- > [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
