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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
