Christian Hopps <cho...@chopps.org> wrote:
>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do use
>> PLMTUD? Will you tell us later in the document, or is that new work?
>> (does not look like you tell us)
> I believed it was enough to just reference the mechanism (as we do for
> PMTUD as well). This was added during the transport area review.
PMTUD relies on ICMP to say "too big"
PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us that we
guessed wrong. We now have RFC8899 too, but I don't know how to apply it,
and I think that some advice is in order.
I think that we need a PL defined.
>>> The "BlockOffset" can point past the end of the "DataBlocks" data
>>> which indicates that the next data block occurs in a subsequent
>>> encapsulating packet.
>>
>> I guess, it the actual value does not matter: it's not remembered. As
>> long it is bigger than the packet, it's good. So 0xffff probably
>> works?
> Your right it just has to point past; however, it helps to have it
> point to the exact ending when implementing (the code is easy to
> implmeent and it caught multiple bugs for me as well).
So, then please tell us exactly what to do, and what the receiver is supposed
to pay attention to. I didn't like "can" here, for instance.
>>> 2.2.2. No Implicit End Padding Required
>>
>> -- I think you are telling me that the IPv4/IPv6 length field is good
>> enough to find the end of the packet. If not, I didn't quite
>> understand.
> You understood.
okay, please hit me over the head harder here.
>> Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' I
>> hope this will be acceptable :-) I think it's a reasonable hack, and I
>> don't see us wrapping around IP versions within a hundred years,
>> soooo... And pad blocks are "IPv0"
>>
>>> This possible interleaving of all-pad payloads allows the sender to
>>> always be able to send a tunnel packet, regardless of the
>>> encapsulation computational requirements.
>>
>> I think that you are telling me that a sender can have some pad
>> packets being created regularly (perhaps on a CPU dedicated to this)
>> and almost ready to send, and the pad packet is just replaced by real
>> data if it happens to be ready.
> You understood perfectly.
I think that motivating this design choice with this implementation advice is
worthwhile.
>>> If the SA back to the sender is a non- AGGFRAG_PAYLOAD enabled SA
>>> then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used to
>>> convey the information.
>>
>> is this really worth supporting?
> It doesn't take much to continue to allow for unidirectional use at the
> lowest layer (ESP/SA). It isn't relevant once you get to IKE where
> bidirectionality is required.
I think that maybe this is in the MAY.
It's isn't clear to me if I need to support that or not.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
