* Florian Weimer > * Tore Anderson: > >> * Florian Weimer >> >>>> And I see no functional difference between the gateway and the host >>>> generating the fragment ID, except that the latter approach seems to >>>> require network-wide software updates currently. >> >> A stateless translator does not keep track of the PMTU for the IPv4 >> destinations. That means that for it to work, it would have to clear the >> Don't Fragment flag and generate a Fragment ID for every single packet >> it translates to IPv4 that ends up smaller than 1260 bytes. I don't >> believe this is desirable. > > Why?
Because the network ends up second-guessing the host. RFC 2460 allows IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the Path MTU for the destination to the indicated value. In other words, an IPv6 node can perform Path MTU Discovery for translated IPv4 destinations behind IPv4 links that have smaller MTU than 1260. I actually prefer this approach to the "lower MTU to exactly 1280 and include Fragment headers" alternative. However, if the translator is clearing the DF flag when translating o IPv4, the IPv6 host cannot perform PMTUD anymore. > You should generate the fragment ID anyway because some networks will > fragment DF=1 packets. I'm okay with generating the Fragment ID, I think. RFC 6145 section 5.1 says a translator MAY do so. What I'm not okay with is clearing the DF flag. >> Also, RFC 2460 would have to be amended in order to allow hosts to >> outright ignore ICMPv6 PTB w/MTU<1280, and the IPv6 host stacks would >> also have to be updated accordingly. It seems to me, therefore, that the >> approach of having the translator generate the Fragment ID is the one >> that requires the most network-wide software updates. > > Affected translators are in the minority. Their vendors will implement > the change (i.e., fragment IPv6 packets without fragment headers) > because that's what's required to get them working with the currrent > network. I'm running a stateless translator (a Cisco ASR1K) in front of our corporate homepage as we speak. It handles «atomic fragments» originated by the IPv6-only web server perfectly in the way RFC 6145 mandates. Absolutely *nothing* is required to change in order "to get it working with the current network". In any case, changing the translators won't stop RFC 2460-compliant nodes from generating these atomic fragments. If you want to make that happen, you need to change the host stacks so that they discard ICMPv6 PTB w/MTU<1280 (or, alternatively, implement them by lowering the PMTU to whatever MTU value indicated in the PTB, even if it's <1280). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
