[quicwg/base-drafts] Proposal for Handling Issues with NAT due to QUIC being a UDP protocol (#2824)

john01dav <notifications@github.com> Fri, 21 June 2019 08:02 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1DE120072 for <quic-issues@ietfa.amsl.com>; Fri, 21 Jun 2019 01:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Level:
X-Spam-Status: No, score=-8.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 uflNnnS1g9Wz for <quic-issues@ietfa.amsl.com>; Fri, 21 Jun 2019 01:02:41 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F075E120048 for <quic-issues@ietf.org>; Fri, 21 Jun 2019 01:02:40 -0700 (PDT)
Date: Fri, 21 Jun 2019 01:02:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561104159; bh=dEvX6+nxeXbUq0yLKoU955IuW9bchUrbQjtGXUm9CKk=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=N1hdQJ+uJUL0Ef6XGNgdjlfZHs/4AxkIY3iZwe4fMg4ayd/VyhJtTHQwounVKLAnm wVmWThZiSGc04TzWJuSsTXRW1/NLupPu3BXJzkw2qeXOImlfBTnKiA8mpMTj6uzJHp IaLhCbOk36YyYl3qdOpsvm6h6Y7ykFJzvFCtHBa4=
From: john01dav <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2HGKJEXPNOICJLRKV3DHAZ7EVBNHHBWXGMQU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2824@github.com>
Subject: [quicwg/base-drafts] Proposal for Handling Issues with NAT due to QUIC being a UDP protocol (#2824)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d0c8f1f3e871_1b383fbff54cd96c3105f4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: john01dav
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/DonIakQ-yGKXZY9w3gl61waNUf0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2019 08:02:43 -0000

I recently read [Cloudflare's blog post on QUIC](https://blog.cloudflare.com/the-road-to-quic/), and one of the issues that they stated that QUIC needs to solve before becoming viable is the issue of NATs blocking UDP packets as the normal TCP connection based system won't work. As I read this, a possible solution jumped out at me: ipv6. With ipv6, there almost never NAT, so this issue is eliminated. If QUIC were to become an ipv6-only protocol, designed to be deployed along-side traditional HTTP for legacy clients, then it could encourage ipv6 deployment. There is precedent for something like this, where a new protocol is only available if some other improvements go with it. When HTTP/2.0 came out (and SPDY before it), most client implementations set it up to only work with TLS-enabled connections. In this way, any website that wants to take advantage of the performance benefits of HTTP/2.0 must also setup TLS, making the Internet a better place. ipv6 support will have to happen eventually, and right now it is mostly held back because many networks refuse to support it as there is little advantage (read: profit) to doing so right now. QUIC being an ipv6-only protocol would create an advantage to ipv6 deployment, especially for mobile websites as at least one major mobile network already supports ipv6 (T Mobile)¹. This would allow the world to move past ipv4 more quickly, by making ipv6 a more viable protocol by itself. 

1: This point is especially important because generally mobile devices have carrier-grade NAT, if any, thus making a mobile network's deployment of ipv6 particularly beneficial. Furthermore, the main areas where QUIC shines (packet loss and high latency) are particularly common on mobile networks compared to wifi or wired networks.  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2824