> -----Original Message----- > From: Rémi Després [mailto:[email protected]] > Sent: Wednesday, January 04, 2012 9:47 AM > To: Dan Wing > Cc: 'Brian E Carpenter'; [email protected] > Subject: Re: Fragmentation-related security issues > > Le 2012-01-04 à 17:14, Dan Wing a écrit : > > >> -----Original Message----- > >> From: Rémi Després [mailto:[email protected]] > >> Sent: Wednesday, January 04, 2012 1:44 AM > >> To: Dan Wing > >> Cc: 'Brian E Carpenter'; [email protected] > >> Subject: Re: Fragmentation-related security issues > >> > >> Hi Dan, > >> > >> As you rightly reminded, the current specification permits PTB<1280 > for > >> a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids > it > >> for an IPv6 DST. > >> > >> Rather than changing this, what about clarifying that a host SHOULD > >> treat a received PTB>1280 as: > >> - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 of > >> RFC6147) > > > > That only helps in half of the RFC6144 scenarios, where the IPv6 > > host is behind the translator (e.g., "Scenario 1: an IPv6 network to > the > > IPv4 Internet"). It would not help in the other half of the RFC6144 > > scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4: > > an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4 > > where stateless IPv6/IPv4 translators, where the IPv4 network has a > > small MTU, that there is a reliance on the last paragraph of Section > > 5 of RFC2460. > > You are right, refusing PTB<12810 if IPv6 DST was not recognized as > IPv4-embedded would break scenarios 3 and 4. > Will these scenarios be as typical as those where an IPv6-only host > reaches an IPv4-only server is unclear, and even IMHO doubtful. > Yet, I agree they must be considered. > > - One approach would be to REQUIRE that IPv4 networks having IPv6-only > access to the Internet have MTU >= 1240 (requiring this ONLY for these > networks shouldn't be a big deal).
Yep. That seems a reasonable statement for an "operational consideration" document to make. It might be reasonable for a NAT64 "operational considerations" document in either BEHAVE or V6OPS. Draft-chen-v6ops-nat64-cpe could be that document; although, as I stated at the microphone in IETF82, draft-chen-v6ops-nat64-cpe needs to more clearly separate itself into the various scenarios for a NAT64 device (that is, if the IPv6 network is "the Internet" (not operated by any one entity) or if the IPv6 network is "a network" (operated by the same entity operating the NAT64). That is the same difference between RFC6144's Scenario 1 and 4.) CC'ing authors of draft-chen-v6ops-nat64-cpe. > - Another, non exclusive, would be that IPv4-embedded addresses of such > networks would be REQUIRED to have a specific format. (A V octet a la > 4rd-U, instead of the u octet of RFC6052, could for instance do the > job). RFC6052 didn't define the "u" octet; rather, RFC6052 is merely preserving the "u" bit's meaning as originally defined in RFC4291. -d > RD > > > > > > > -d > > > >> - an ERROR otherwise. > >> > >> This would at least dissuade from tolerating IPv6 paths with PMTU < > >> 1280. > >> > >> RD > >> > >> > >> > >> Le 2012-01-03 à 21:43, Dan Wing a écrit : > >>>> ... > >>>> From: Brian E Carpenter [mailto:[email protected]] > >>>> ... > >>>> On 2012-01-04 08:02, Dan Wing wrote: > >>>>> ... > >>>>> So, I don't think we can just wish away packet-too-big < 1280. > >>>> > >>>> Sadly, that seems to be true unless we make a much more radical > >> change, > >>>> because of translators. > >>> > >>> Or, we declare a new restriction that translators are not expected > to > >>> work if the IPv4 network has an MTU less than 1260 (1260=1280-20, > >>> because IPv6 header is 20B bigger than IPv4 header). I don't know > if > >> there > >>> is consensus for such a restriction. To date, both RFC2765 and > >> RFC6145 > >>> avoided such a restriction. However, if there are widespread IPv6 > >>> host implementations or firewalls that erroneously filter or ignore > >>> ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to > >>> accept that restriction, and modify their IPv4 networks to have > >>> MTU>=1260. Such IPv4 network modifications would add to further > >>> pain to IPv6 coexistence. MTU research by Ben Stasiewicz and > >>> Matthew Luckie (WAND), published and presented at RIPE and > >>> other conferences, shows a 2-3% failure rate to various popular > >>> web sites. They did additional testing during World IPv6 Day, > >>> but I haven't dug into those results yet. > >>> > >>> -d > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> IETF IPv6 working group mailing list > >>> [email protected] > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> ------------------------------------------------------------------- > - > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
