Hi <snipped agreed pieces>
First of all I see that Pasi has registered a COMMENT regarding the use of segmentation at all so this discussion may be irrelevant. Ertekin, Emre [USA] wrote: > > > - The additional text (regarding the suppression of segmentation when > > > there is no knowledge of Path MTU) that has been added to the end of > > > what is now s4.3 is the only reasonable response in an IP4 environment: > > > > > > > Under certain circumstances, IPsec implementations will not > > > > process > > > > (or receive) unprotected ICMP messages, or they will not have a > > > > Path > > > > MTU estimate value. In these cases, the IPsec implementation > > > > SHOULD > > > > NOT attempt to segment the ROHC-compressed packet, as it does > > > not > > > > have full insight into the path MTU in the unprotected domain. > > > > > > I am less clear that this is right solution for an IPv6 environment. If > > > I understand correctly, the IPsec layer would know that the channel was > > > using IPv6. The IPsec layer could decide to assume the Minimum > > > Guaranteed MTU for IPv6. Presumably the IP layer would be no better > > > informed because of the suppression of ICMP messages or whatever, so > > > deferring fragmentation to the IP layer might be more inefficient than > > > assuming the minimum guarantee and doing segmentation at the IPsec > > > layer > > > > In certain cases, I agree. However, in others (see below), > segmentation to 1280 bytes might not be the best solution. > The point I was making is that if the IP layer on the source node can't get any definite knowledge of a larger MTU it will fragment the packet to 1280 octets anyway (because of how IPv6 is supposed to work) - it doesn't have any choice whether or not there might be a low MTU tunnel buried in the path. Is it then better for the IPsec/ROHC to do the segmentation? Would this result in a more compact representation? I am not exactly sure if the cases you note where the IPsec layer doesn't have positive information about the MTU also result in the IP layer not knowing - I think the IP layer will alos be ignorant. As Pasi says the actual use cases for ROHC may mean that relevant packets aren't that big anyway so this may well be a tiny corner case. > > > > > - I am not sufficiently deep into ROHC to know if this is true. > > > Perhaps > > > a qualification for the IPv6 case is appropriate? > > > > Traditional ROHC is applied on a hop-by-hop basis; in these cases, the > compressor and decompressor implementations have a pretty good > understanding of the MTU for the ROHC channel. > > > > For ROHCoIPsec it is not straightforward, as the compression channel > may be established across an arbitrary network. So even if we are > compressing IPv6 packets, this doesn't necessarily mean that the PMTU > between compressor and decompressor is 1280. Take for instance the > following scenario: > > > > --------------- ---------- ---------------------------- > ---------- --------------- > > | IPv6 IPsec |----| Router |-----|arbitrary network cloud |-----| > Router |-----| IPv6 IPsec | > > | Compressor | | | | e.g., PMTU = 1100 | | > | | Decompressor| > > --------------- ---------- ---------------------------- > ---------- --------------- > > > > The arbitrary network cloud might consist of IPv4 hops, where the MTU > is less than 1280. If the compressor initially segments the packet to > 1280 bytes, this ROHCoIPsec segment is fragmented again in the core > network (PMTU=1100). Rather, in this case, it would've been better to > leave the packet untouched initially, and only fragmented the packet > within the core. > > > > In certain situations though (e.g., if the network was pure IPv6, or > if ROHCoIPsec was instantiated over a single hop), I agree that > segmentation might be a better solution. > > > > In summary, because there is uncertainty about the PMTU, I would > recommend that we leave this statement as SHOULD NOT. > In the IPv6 case the uncertainty is not there - it has to be assumed to be 1280 octets in the absence of positive information to the contrary. /Elwyn > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
