Re: [v4v6interim] Fragmentation Options in NAT6 presentation

"Wes Beebee (wbeebee)" <wbeebee@cisco.com> Fri, 03 October 2008 18:35 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 1C5C83A6A3E; Fri, 3 Oct 2008 11:35:39 -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 B628A3A6AEF for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 11:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level:
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 jtdpDYVQFh7d for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 11:35:36 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2B40D28C18C for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 11:35:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,358,1220227200"; d="scan'208";a="23121451"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Oct 2008 18:36:01 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m93Ia136019344; Fri, 3 Oct 2008 14:36:01 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m93Ia1rr001278; Fri, 3 Oct 2008 18:36:01 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 14:36:01 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 03 Oct 2008 14:36:00 -0400
Message-ID: <BB56240F3A190F469C52A57138047A03011DB1F0@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [v4v6interim] Fragmentation Options in NAT6 presentation
Thread-Index: AcklOzbv7AvOH9xVQyuPwJwY/JGnogAS1TLw
References: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org>
From: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
To: Hiroshi MIYATA <miyata@tahi.org>, v4v6interim@ietf.org
X-OriginalArrivalTime: 03 Oct 2008 18:36:01.0778 (UTC) FILETIME=[E2CE3520:01C92586]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1359; t=1223058961; x=1223922961; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20<wbeebee@cisco.co m> |Subject:=20RE=3A=20[v4v6interim]=20Fragmentation=20Options =20in=20NAT6=20presentation |Sender:=20 |To:=20=22Hiroshi=20MIYATA=22=20<miyata@tahi.org>,=20<v4v6i nterim@ietf.org>; bh=CtPXbYmB+ODMAm4PN2sNizs45a5Scaoo8AccUFKz3FM=; b=eisMoacgCZIpOShj6SlxeZmELhF2MwyQD+VjvLLn8XF/U9UHFR6Bmls/V8 AlO0gueLw/zqPMUFdDcUISYndfa5WmjJQNFVo4wnQkQex9YohfEk19tOj4Wg Qs6w0+tBVB;
Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

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