Re: [v4v6interim] Fragmentation Options in NAT6 presentation
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 03 October 2008 23:45 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 707D43A695E; Fri, 3 Oct 2008 16:45:44 -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 2F0F03A68D1 for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 16:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 ugMWxNgBW6Ok for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 16:45:42 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 50F4F3A695E for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 16:45:42 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so1935812wfd.31 for <v4v6interim@ietf.org>; Fri, 03 Oct 2008 16:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=b1kio26emTXxc4qRH5V74oEl4TJ+Xuj33Kyx2RGnL9o=; b=k7TTlS2m6JWTKk2CBZeYmPyaCwqCh4FRSJqk81liQ85QGmLzIF8rsew00uefMl2Aja Z/Na4JROn5CXIpKlZKqD+tjFok1jY1yygk50WPsktWWhjlO9YnhMaFNH2TktB5liPFH4 JXGZcVbpCHBfJqqRTPZNmtdIc60/ZznCFMCUQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=MxhdW5Ny/l9hd9Hkx8rNKxEtfVMT/OkW4tajsyyUVFtmx3s28A97OUOiRUG9/pek9a lPKWgzU7JVIBjjPVW98xxCy4bsDnZMvwqduc84Bo8gBieImbYPNQGqTPLVXvBnniIWWs BGeVk+TJVsfhKd0KwWnSQQyvjgHY2d3tgBYng=
Received: by 10.142.194.1 with SMTP id r1mr592365wff.192.1223077571601; Fri, 03 Oct 2008 16:46:11 -0700 (PDT)
Received: from ?10.1.1.4? (118-93-8-5.dsl.dyn.ihug.co.nz [118.93.8.5]) by mx.google.com with ESMTPS id 30sm5749675wfd.1.2008.10.03.16.46.09 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Oct 2008 16:46:11 -0700 (PDT)
Message-ID: <48E6AEBD.9090205@gmail.com>
Date: Sat, 04 Oct 2008 12:46:05 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hiroshi MIYATA <miyata@tahi.org>
References: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org> <BB56240F3A190F469C52A57138047A03011DB1F0@xmb-rtp-211.amer.cisco.com> <D2FC99B8-A75A-43BE-9717-DCCE2C807AB7@tahi.org>
In-Reply-To: <D2FC99B8-A75A-43BE-9717-DCCE2C807AB7@tahi.org>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org
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)