Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt

Yoav Nir <ynir@checkpoint.com> Thu, 17 October 2013 19:09 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091A811E82D0 for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 12:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.431
X-Spam-Level:
X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JrWeaazm7pN for <ipsec@ietfa.amsl.com>; Thu, 17 Oct 2013 12:09:32 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8971111E82BB for <ipsec@ietf.org>; Thu, 17 Oct 2013 12:09:31 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9HJ9E3F024337; Thu, 17 Oct 2013 22:09:14 +0300
X-CheckPoint: {52603598-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 22:09:03 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "Mike Sullenberger (mls)" <mls@cisco.com>
Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Thread-Index: AQHOy2d5pYcHqbWxPEWgj+5YQk9+DZn5D5+A
Date: Thu, 17 Oct 2013 19:09:04 +0000
Message-ID: <BF06BF82-B78C-4B3C-BE02-C1C399F1D099@checkpoint.com>
References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <alpine.LFD.2.10.1310041144500.10965@bofh.nohats.ca> <E46CD124E88F442495758F38BC026897@chichi> <alpine.LFD.2.10.1310081048530.7675@bofh.nohats.ca> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com>
In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.63]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A2F8D35534BA374F944D374C08071850@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Valery Smyslov <svanru@gmail.com>, Paul Wouters <paul@cypherpunks.ca>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2013 19:09:37 -0000

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) <mls@cisco.com> 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
> mls@cisco.com            .:|:.:|:.
> Customer Advocacy          CISCO
> 
> 
> 
>> -----Original Message-----
>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
>> Of Valery Smyslov
>> Sent: Wednesday, October 09, 2013 10:34 PM
>> To: Paul Wouters
>> Cc: ipsec@ietf.org
>> 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
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec