Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 22 June 2015 23:31 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A751B2A2F for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 16:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiBZfr4RGHAs for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 16:31:38 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D25F1ACEF7 for <v6ops@ietf.org>; Mon, 22 Jun 2015 16:31:38 -0700 (PDT)
Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MNUaQk033784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 01:30:37 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <E58BE586-3637-4724-8480-6817EBBD8A91@nestlabs.com>
Date: Tue, 23 Jun 2015 01:31:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <90744458-CA06-4347-A96B-D649800855D3@muada.com> <CAKC-DJhQ3kSPtkVHoPxtiUO-CbQkymehDF735nr8Q6=EUdUz0Q@mail.gmail.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <D3310B7C-C0CD-45D6-9054-CDF08C6E5A58@muada.com> <E58BE586-3637-4724-8480-6817EBBD8A91@nestlabs.com>
To: james woodyatt <jhw@nestlabs.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/VZ_8BOqlRqzdNI8MTIKGPZJd474>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 23:31:43 -0000

On 23 Jun 2015, at 1:18, james woodyatt <jhw@nestlabs.com> wrote:

>> As such: […] I'm 99.9% sure this works the same way for UDP as for ICMPv6; […]

> It does.

So then why would this be a problem:

> pass straight through parts of the network with PMTU=1492 without generating errors and therefore never exercising any application layer logic needed to deal with UDP-PMTUD, which is typically not there at all because developers are… well, they often don’t do it.

What exactly are you objecting to? That the translated packets are too small to trigger too bigs? That also happens with native IPv6 if the path supports 1500 bytes. So if you want to test for paths with < 1500 PMTUs, you will have to, you know, do the work to test with paths with < 1500 PTMUs.

If your problem is that applications don't handle incoming too bigs, then be glad you're behind a NAT64 because this is indeed a problem with IPv4 (but easily solved by simply setting the DF bit to 0!) but it isn't for IPv6, as we just agreed that with IPv6, the IP layer catches too bigs and fragments subsequent packets without involvement from the application.