Re: [v4v6interim] Fragmentation Options in NAT6 presentation
"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 03 October 2008 19:19 UTC
Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF8F3A6986; Fri, 3 Oct 2008 12:19:19 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2015D3A6986 for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 12:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.073
X-Spam-Level:
X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElI6Qjn9PBwl for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 12:19:17 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9BB843A6A32 for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 12:19:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,358,1220227200"; d="scan'208";a="21594529"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2008 19:19:44 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m93JJitF013059; Fri, 3 Oct 2008 21:19:44 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m93JJiRT000220; Fri, 3 Oct 2008 19:19:44 GMT
Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 21:19:43 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 03 Oct 2008 21:16:34 +0200
Message-ID: <CE2BF2A7B1008C459FD7978065C6ECE007949456@xmb-ams-33a.emea.cisco.com>
In-Reply-To: <BB56240F3A190F469C52A57138047A03011DB1F0@xmb-rtp-211.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [v4v6interim] Fragmentation Options in NAT6 presentation
Thread-Index: AcklOzbv7AvOH9xVQyuPwJwY/JGnogAS1TLwAAFUT4A=
References: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org> <BB56240F3A190F469C52A57138047A03011DB1F0@xmb-rtp-211.amer.cisco.com>
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>, Hiroshi MIYATA <miyata@tahi.org>, v4v6interim@ietf.org
X-OriginalArrivalTime: 03 Oct 2008 19:19:43.0824 (UTC) FILETIME=[FDAAAD00:01C9258C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2770; t=1223061584; x=1223925584; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:=20=22Eric=20Vyncke=20(evyncke)=22=20<evyncke@cisco.c om> |Subject:=20RE=3A=20[v4v6interim]=20Fragmentation=20Options =20in=20NAT6=20presentation |Sender:=20; bh=zmM1rUF0w0wFy6RZBly9TyX1uL7XwhQHG96T9Ey483k=; b=dIKwF+wqgYAme9Hr9TpEJORbxDvqt/HxUDZr4G9glvgCUv1JsxJ0oVRIYQ 1yITnn6eYLye3tYRgtxUqtBgYn/rvGLBRvONHnlDUh5QDHOjafKSkleF5AXR 6t4FrD/jtU;
Authentication-Results: ams-dkim-1; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Subject: Re: [v4v6interim] Fragmentation Options in NAT6 presentation
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org
Or more precisely, SP won't block ICMP in transit but have NO choice but rate limiting the number of ICMPv6 packet too big _generated_ by a router to 100 pps or so... (NB: this is already the case now in IPv4 and IPv6 in order to save CPU) Of course, if Google Map (or any other applications) has to open 50+ connections per end-user transaction, and if there are more than 2 end-users connecting to Google Maps within the same second (this is assumed to by ironical -- Friday evening), then some connections will fail... (cached information will only be available after the connection timed out I'm afraid). Hence the importance of setting 'manually' the MTU right at the edge where the ICMP generation rate is probably (?) lower than in the core. -éric > -----Original Message----- > From: v4v6interim-bounces@ietf.org > [mailto:v4v6interim-bounces@ietf.org] On Behalf Of Wes Beebee > (wbeebee) > Sent: vendredi 3 octobre 2008 20:36 > To: Hiroshi MIYATA; v4v6interim@ietf.org > Subject: Re: [v4v6interim] Fragmentation Options in NAT6 presentation > > Some SP's may view ICMP as an attack vector and may > explicitly block ICMP messages. > > In this case, the only way to get connectivity for packets > that are too large is to fragment. > > - Wes > > -----Original Message----- > From: v4v6interim-bounces@ietf.org > [mailto:v4v6interim-bounces@ietf.org] > On Behalf Of Hiroshi MIYATA > Sent: Friday, October 03, 2008 5:31 AM > To: v4v6interim@ietf.org > Subject: [v4v6interim] Fragmentation Options in NAT6 presentation > > Jennings, > > > FYI. > Though it is already clearly explained by Dave, let me give > you the pointer. > The answer for your question of "Fragmentation options" is > clearly stated in RFC2765(SIIT) as end-to-end path MTU discovery. > See Section 3 and 4. > > And of course RFC1981(PMTUD) is compliant with it. ;-) Chap. 4 > Note: A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link > MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun > link MTU, > but rather must include a Fragment header in those > packets [IPv6- > SPEC]. > > It must work well. ;-) > > Regards, > > ....miyata > _______________________________________________ > v4v6interim mailing list > v4v6interim@ietf.org > https://www.ietf.org/mailman/listinfo/v4v6interim > _______________________________________________ > v4v6interim mailing list > v4v6interim@ietf.org > https://www.ietf.org/mailman/listinfo/v4v6interim > _______________________________________________ v4v6interim mailing list v4v6interim@ietf.org https://www.ietf.org/mailman/listinfo/v4v6interim
- [v4v6interim] Fragmentation Options in NAT6 prese… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Wes Beebee (wbeebee)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Wes Beebee (wbeebee)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Fred Baker
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Rémi Denis-Courmont
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Mark Andrews
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Dan Wing
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Magnus Westerlund
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Rémi Denis-Courmont
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Iljitsch van Beijnum
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)