In picture in the "2.5. Fragmenting Message" there is field called
"Next Payload", but the description says "Next Fragment":
----------------------------------------------------------------------
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
o Next Fragment (1 octet) - in the very first fragment MUST be set
to Payload Type of the first inner Payload (as in Encrypted
Payload). In the rest fragments MUST be set to zero.
----------------------------------------------------------------------
In section 2.5.1 draft says:
----------------------------------------------------------------------
Using 576 bytes is a compromise - the value is
large enough for the presented solution and small enough to avoid IP
fragmentation in most situations. Sender MAY use other values if
they are appropriate.
----------------------------------------------------------------------
I think you might also point out that other protocols also assume that
same value, i.e. I think DNS packets sent over UDP also assume that
same limit, and if that long IP packets do not work, then the network
does not work for any real uses...
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
