Hello Dan and Remi, Thanks for providing this information to us. I have a glance on the discussion. As an author of draft-chen-v6ops-nat64-cpe, I think it's valuable to state that as one of NAT64 experiences. I will bring my comments to the list after my second reading. Many thanks
Gang -----Original Message----- From: Rémi Després [mailto:[email protected]] Sent: Thursday, January 05, 2012 5:09 PM To: Dan Wing Cc: 'Brian E Carpenter'; [email protected]; [email protected] Subject: Re: Fragmentation-related security issues Le 2012-01-05 à 03:45, Dan Wing a écrit : >> -----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.) Agreed. > > CC'ing authors of draft-chen-v6ops-nat64-cpe. Good idea. >> - 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. Well, RFC6052 does include in sec. 2.3 '... insert the null octet "u"...' and '... remove the "u" octet...'. I agree that, in view of the privacy option that pre-existed, this didn't add a new value of this octet (the point you make if I get it right). Yet, RFC6052 did introduce an interpretation of the u bit that, from a puristic point of view, would conflict with that of RFC4291: - RFC4291 says: "the "u" bit is set to one (1) to indicate universal scope, and it is set to zero (0) to indicate local scope". - In RFC6052, 64:ff9b::X.X.X.X means IPv4 address X.X.X.X whose scope is universal despite its u=0. In my understanding, another RFC that would introduce a V octet using the u=v=1 escape combination wouldn't conflict with RFC4291 more than RFC4291 does, i.e. acceptably little. RD > > -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 --------------------------------------------------------------------
