[v4v6interim] Fragmentation Options in NAT6 presentation

Hiroshi MIYATA <miyata@tahi.org> Fri, 03 October 2008 09:33 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 12F293A6B57; Fri, 3 Oct 2008 02:33:45 -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 A2E643A6B3D for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 02:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599]
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 SBw7LPy2UJzv for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 02:33:42 -0700 (PDT)
Received: from ns.64translator.com (ns.64translator.com [202.214.123.16]) by core3.amsl.com (Postfix) with ESMTP id B820828C265 for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 02:32:04 -0700 (PDT)
Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id m939VFKp003116 for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 18:31:15 +0900 (JST) (envelope-from miyata@tahi.org)
Received: from [127.0.0.1] (fumi.64translator.com [10.21.254.6]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id m939V5kB036521 for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 18:31:06 +0900 (JST) (envelope-from miyata@tahi.org)
Message-Id: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org>
From: Hiroshi MIYATA <miyata@tahi.org>
To: v4v6interim@ietf.org
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Fri, 03 Oct 2008 18:31:04 +0900
X-Mailer: Apple Mail (2.928.1)
Subject: [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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

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