Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
Hi Yoav, thank you for your review. I think the draft is in good shape and is almost ready for publication. There is a bunch of grammatical issues with it, but I think the RFC editor is much better at fixing those than most of us. Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. I tried to be conservative here. Lastly, some nits: Section 2.1: OLD: The idea of the protocol is to split large IKE message into the set of smaller ones, calling IKE Fragment Messages. NEW: The idea of the protocol is to split large IKE message into a set of smaller ones, called IKE Fragment Messages. Fixed. Section 2.5: OLD: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero. NEW: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero or one. I disagree. Total Fragments of one is perfectly valid. It makes sense in situations, when short request could generate large response (consider request of some parameters via Configuration Payload). In this case initiator may send fragmented message (even if there will be the only fragment) to quickly kick off responder to send fragmented response. And in general nothing in the draft prohibits some simple implementation from always sending messages in fragmented form even the short ones. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
On 2013-10-25 23:51, Yoav Nir wrote: On Oct 25, 2013, at 11:23 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU. The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet. 1280 leaves room for various tunnels, encapsulations and what not. Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore. Yoav If we give a recommendation, I think it should be based on measured data. See for example Sec. 5.5 of http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
On Oct 26, 2013, at 12:14 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: On 2013-10-25 23:51, Yoav Nir wrote: On Oct 25, 2013, at 11:23 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU. The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet. 1280 leaves room for various tunnels, encapsulations and what not. Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore. Yoav If we give a recommendation, I think it should be based on measured data. See for example Sec. 5.5 of http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf Thanks for the link. And only 1 (out of 1150) probes found a PMTU in IPv4 smaller than 1280, and that was 1280. More than 2/3 were exactly 1500, and the vast majority was over 1400. Smallest they found was 1240. Any reason to set the limit (much) below that? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
On Oct 26, 2013, at 2:25 PM, Yoav Nir y...@checkpoint.com wrote: On Oct 26, 2013, at 12:14 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: On 2013-10-25 23:51, Yoav Nir wrote: On Oct 25, 2013, at 11:23 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU. The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet. 1280 leaves room for various tunnels, encapsulations and what not. Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore. Yoav If we give a recommendation, I think it should be based on measured data. See for example Sec. 5.5 of http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf Thanks for the link. And only 1 (out of 1150) probes found a PMTU in IPv4 smaller than 1280, and that was 1280. More than 2/3 were exactly 1500, and the vast majority was over 1400. Smallest they found was 1240. Any reason to set the limit (much) below that? s/and that was 1280/and that was 1240/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
Although there is a spirited, useful discussion going on between three or four participants, we could certainly use more reviewers for this WG document. Please send any comments to the list, and feel free to hop into the threads already running. Thanks! --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
Hi I think the draft is in good shape and is almost ready for publication. There is a bunch of grammatical issues with it, but I think the RFC editor is much better at fixing those than most of us. Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. Lastly, some nits: Section 2.1: OLD: The idea of the protocol is to split large IKE message into the set of smaller ones, calling IKE Fragment Messages. NEW: The idea of the protocol is to split large IKE message into a set of smaller ones, called IKE Fragment Messages. Section 2.5: OLD: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero. NEW: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero or one. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation
On Oct 25, 2013, at 11:23 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today. This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU. The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet. 1280 leaves room for various tunnels, encapsulations and what not. Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
