Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does 
IKEv1 fragmentation.

Still, I don't think you're going to find on the modern Internet any networks 
that aren't usable by IPv6. So I think we should be pretty safe in adoption 
IPv6's minimum of 1280

Yoav

On Oct 17, 2013, at 9:34 PM, Mike Sullenberger (mls) <[email protected]> wrote:

> As I remember it IPv4 has a minimum packet size of 576 that won't (or at 
> least shouldn't be) fragmented by IP.
> 
> Mike.
> 
> 
> Mike Sullenberger, DSE
> [email protected]            .:|:.:|:.
> Customer Advocacy          CISCO
> 
> 
> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf
>> Of Valery Smyslov
>> Sent: Wednesday, October 09, 2013 10:34 PM
>> To: Paul Wouters
>> Cc: [email protected]
>> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-
>> 03.txt
>> 
>>>> I also think that PMTU discovery isn't very useful for IKE.
>>>> That's why it is MAY.
>>> 
>>> That does not help implementors who still have to implement the MAY's.
>>> if even you as a document author does not think it is very useful,
>>> then I think it should just not be in the document.
>> 
>> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not 
>> useful
>> for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram
>> size that is not fragmented by IP level. In IKE its the goal is different - 
>> to find
>> _some_reasonable_ IP datagram size that is not fragmented by IP.
>> 
>> If we have the size that is guaranteed to not be fragmented, no PMTU
>> discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. 
>> But
>> as far as I know, there's no such value for IPv4.
>> If we mandate (or recommend) using really small value e.g. 128 bytes, than
>> the performance will suffer badly, so it is not a good option.
>> I'm especially worrying about network I'm not familiar with - mobile
>> networks or other constrained environments.
>> It would be great if some experts in such networks could clarify this.
>> 
>> _______________________________________________
>> IPsec mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to