Re: [v4v6interim] Fragmentation Options in NAT6 presentation
Hiroshi MIYATA <miyata@tahi.org> Sat, 04 October 2008 08:57 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 467CA3A69FC; Sat, 4 Oct 2008 01:57:56 -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 BFCAA3A69FC for <v4v6interim@core3.amsl.com>; Sat, 4 Oct 2008 01:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level:
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 MTEoXh92ymCR for <v4v6interim@core3.amsl.com>; Sat, 4 Oct 2008 01:57:54 -0700 (PDT)
Received: from ns.64translator.com (ns.64translator.com [202.214.123.16]) by core3.amsl.com (Postfix) with ESMTP id A17F83A690E for <v4v6interim@ietf.org>; Sat, 4 Oct 2008 01:57:54 -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 m948uuKS044598; Sat, 4 Oct 2008 17:56:56 +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 m948ubAL080852; Sat, 4 Oct 2008 17:56:38 +0900 (JST) (envelope-from miyata@tahi.org)
Message-Id: <ECC150A9-5846-40D7-83EE-669F3B21E050@tahi.org>
From: Hiroshi MIYATA <miyata@tahi.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <48E6AEBD.9090205@gmail.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Sat, 04 Oct 2008 17:56:35 +0900
References: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org> <BB56240F3A190F469C52A57138047A03011DB1F0@xmb-rtp-211.amer.cisco.com> <D2FC99B8-A75A-43BE-9717-DCCE2C807AB7@tahi.org> <48E6AEBD.9090205@gmail.com>
X-Mailer: Apple Mail (2.928.1)
Cc: v4v6interim@ietf.org
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-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
Brian, Thanks for your input. I will investigate it! Cheers! ...miyata On 2008/10/04, at 8:46, Brian E Carpenter wrote: > Actually the *correct* solution is to use a method of > PMTU discovery that does not depend on ICMP. > That's the point of RFC 4821. > > Brian > > On 2008-10-04 08:51, Hiroshi MIYATA wrote: >> Correct! >> >> We have met the problem, and, yes, only the way is fragmenting >> the packet on the Translator. >> We have developed it as a optional behavior. >> >> It may cause the argument if we state it in document, since >> it break the PMTU Discovery semantics. >> >> But it is the fact. >> >> Maybe it is not recommended to describe on BEHAVE documents >> as a requirement. >> But we should give the hint of this issue on the documents >> as possible problems and solution and utilization (since >> it is not recommended to use this in public service, but >> possible to be used for controllable area of the administrator.) >> >> Regards, >> >> ....miyata >> >> >> On 2008/10/04, at 3:36, Wes Beebee (wbeebee) wrote: >> >>> 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)