Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets

"Dan Wing" <dwing@cisco.com> Mon, 08 February 2010 17:45 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1CA3A7462 for <behave@core3.amsl.com>; Mon, 8 Feb 2010 09:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 R1tocuKkfkEg for <behave@core3.amsl.com>; Mon, 8 Feb 2010 09:45:12 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D124628C0DE for <behave@ietf.org>; Mon, 8 Feb 2010 09:45:11 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsgFAKfcb0urRN+K/2dsb2JhbACHeoESuBaXJIRUBA
X-IronPort-AV: E=Sophos;i="4.49,431,1262563200"; d="scan'208";a="84706839"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2010 17:46:14 +0000
Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o18HkDf2021241; Mon, 8 Feb 2010 17:46:13 GMT
From: Dan Wing <dwing@cisco.com>
To: 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, behave@ietf.org
References: <4B6F08CC.2070900@wand.net.nz> <063A973F-EBC3-4CD0-B5B6-B0FB42A8593D@muada.com><00f201caa8da$b78e3e90$c4f0200a@cisco.com> <4B704153.2020007@it.uc3m.es>
Date: Mon, 08 Feb 2010 09:46:13 -0800
Message-ID: <015801caa8e6$9b72fff0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <4B704153.2020007@it.uc3m.es>
Thread-Index: Acqo3yJLiK4ckIlgSsaKCbr7ug1DHAAAyP2Q
Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2010 17:45:13 -0000

 

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun
> Sent: Monday, February 08, 2010 8:53 AM
> To: behave@ietf.org
> Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> 
> El 08/02/10 17:21, Dan Wing escribió:
> >
> > But no matter the reason, I agree that a greater than 50% 
> > failure on the
> > Internet means the function is effectively broken.  In my 
> > view, Ben's testing
> > invalidates the consensus reached in the meeting at IETF76 
> > (Hiroshima),and I
> >    
> > have asked authors of xlate and xlate-stateful to revise 
> > the documents accordingly.
> >
> >    
> 
> I am not sure what the translator should do now... what do 
> you have in mind?

We can't rely on sending ICMPv6 packet-too-big to IPv6 hosts
if the packet-too-big indicates an MTU less than 1280.  Thus,
the text from RFC2765 (SIIT),

   However, [IPv6]
   requires that IPv6 nodes handle such an ICMP "packet too big" message
   by reducing the path MTU to 1280 and including an IPv6 fragment
   header with each packet.  This allows end-to-end path MTU discovery
   across the translator as long as the path MTU is 1280 bytes or
   greater.  When the path MTU drops below the 1280 limit the IPv6
   sender will originate 1280 byte packets that will be fragmented by
   IPv4 routers along the path after being translated to IPv4.

is true, but testing results on the Internet show it fails more than
50% of the time.  Thus, we can't rely on it.  draft-ietf-behave-v6v4-xlate-08 
has incorporated that same text from RFC2765 and the current design 
relies on that function.  

For stateless translation, we need to simply translate small packets
(which was smaller than 1280 on the IPv6 side) with IPv4 DF=0, and allow
it to be fragmented on the IPv4 side.  This is because if the translator
does receive an IPv4 ICMP packet-too-big describing an MTU smaller than 
1280, and translated it to IPv6, more than 50% of the IPv6 hosts would 
be unable to successfully process it.  This means we lose end-to-end 
PMTUD across the translator for links smaller than 1280.  However, we 
still have end-to-end PMTUD for links greater than 1280, so translators
will allow moving to larger packets in the future.


For stateful translation, it is _possible_ for the translator
to include MTU in its IPv4 and IPv6 tables, and do provide end-to-end
PMTUD even for links below 1280.  To do this, a stateful translator
would maintain the MTU for all IPv4 hosts that currently have a mapping,
and go ahead and translate with DF=1.  Then, if an IPv4 ICMP PTB is
received and describes an MTU smaller than 1280, go ahead and translate
that to ICMPv6 (in the hopes of hitting the ~45% of hosts that will
successfully process it), but also modify the MTU in the mapping table
so that subsequent packets are always fragmented by the stateful
translator.  This allows the IPv6 host to realize it isn't getting
end-to-end PMTUD (because it was sent the ICMPv6 PTB message, 
indicating a smaller-than-1280 MTU), and also allows the stateful
translator to set DF=0 only for those IPv4 destinations that need
it.  But, this all seems complicated for stateful translation; I 
don't know if we need to get into such an optimization, especially at
this late date with our specifications.

Thoughts?

-d


> Regards, marcelo
> 
> > If anyone thinks we should keep the IETF76 consensus, 
> please speak up now!
> >
> > -d
> >
> >
> >    
> >> Begin forwarded message:
> >>
> >>      
> >>> From: Ben Stasiewicz<ben@wand.net.nz>
> >>> Date: 7 februari 2010 19:39:08 GMT+01:00
> >>> To: mtu@psc.edu
> >>> Cc: Matthew Luckie<mjl@wand.net.nz>
> >>> Subject: Re: IPv6 hosts sending<1280 byte packets [was RE:
> >>>        
> >> RRG discussion of SEAL, IPTM - and my critique of RFC4821]
> >>
> >>      
> >>> On 29/01/10 08:40, Dan Wing wrote:
> >>>        
> >>>> Ben, would it be possible to conduct a test to see how
> >>>>          
> >> hosts react to PTB
> >>      
> >>>> smaller than 1280?
> >>>>          
> >>      
> >>> I conducted such a test and found that 299 (43.46%) of the 688
> >>> IPv6-capable web servers that I tested did include an IPv6
> >>>        
> >> fragmentation
> >>      
> >>> header in their response packets after they were sent an 
> ICMPv6 PTB
> >>> message specifying an MTU<  1280 bytes. The other 389
> >>>        
> >> (56.54%) did not.
> >>
> >>      
> >>> I am happy to answer any questions about the test.
> >>>        
> >> _______________________________________________
> >> Behave mailing list
> >> Behave@ietf.org
> >> https://www.ietf.org/mailman/listinfo/behave
> >>      
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >    
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave