Re: Last Call: RFC 6346 successful: moving to Proposed Standard

Mark Andrews <marka@isc.org> Thu, 11 December 2014 03:45 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A471A1A69 for <ietf@ietfa.amsl.com>; Wed, 10 Dec 2014 19:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 EXL-gEfgGkIq for <ietf@ietfa.amsl.com>; Wed, 10 Dec 2014 19:45:09 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FFF1A1B87 for <ietf@ietf.org>; Wed, 10 Dec 2014 19:45:08 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 44BCF1FCAB8; Thu, 11 Dec 2014 03:45:04 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5BA77160053; Thu, 11 Dec 2014 03:49:33 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id CAE16160045; Thu, 11 Dec 2014 03:49:32 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1776A25434AE; Thu, 11 Dec 2014 14:45:01 +1100 (EST)
To: Doug Royer <douglasroyer@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <A4CFF3FB-A9C5-47EA-A1CA-B900CDBF776E@gmail.com> <547F451C.3010507@dcrocker.net> <D0AE1053.7AA8A%Lee@asgard.org> <AF1B977B-75D4-4AF2-B231-300AF2429317@nominum.com> <CAMm+Lwji9860CKaJB_9xi3ztiVUtP3NZ8AgO1wZAVTKVWW76Nw@mail.gmail.com> <CADC+-gR+sFUELOrdfVj5e3hW-KZoftotbhvEwF6aotZvq5wOkw@mail.gmail.com> <1DF3E368-D915-458C-8009-C508735D3C88@nominum.com> <5488FEE0.2030400@gmail.com> <84E9B4C0-A2E2-41BF-955A-1B125BBE63B1@nominum.com> <54890CD3.2050800@gmail.com>
Subject: Re: Last Call: RFC 6346 successful: moving to Proposed Standard
In-reply-to: Your message of "Wed, 10 Dec 2014 20:17:39 -0700." <54890CD3.2050800@gmail.com>
Date: Thu, 11 Dec 2014 14:45:00 +1100
Message-Id: <20141211034501.1776A25434AE@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/CW4il5QHzohbWRmwuLg8DiLqToA
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2014 03:45:11 -0000

In message <54890CD3.2050800@gmail.com>, Doug Royer writes:
>
> On 12/10/2014 07:43 PM, Ted Lemon wrote:
> > A+P is for home gateways, not for servers.   That said, most uses of
> > A+P exclude the well-known port range for assignment to home gateways, so
> > if for some strange reason you wanted to do A+P with servers, you could
> > allocate those ranges to servers.   This is not a common or expected use
> > of A+P, however, so this is kind of moot.   The essential point of A+P is
> > that it creates deterministic mappings, which makes carrier-grade NAT
> > less painful and more predictable.   It really only makes sense in the
> > context of a dual-stack transition model, where you would always prefer
> > IPv6 for flows between hosts that support it.
>
> So the expectation is that ISP's will replace your NAT/router with one
> that meets this specification? Why would they just not replace it with a
> IPv6 one? I still see no time to implement gain if this is the plan.

They will install IPv6 + A+P for IPv4.

> If the mapping is done at the ISP layer and *not* the home router, then
> they better NAT the IP they give you, or your operating system firewall
> will go nuts trying to figure out when and what port range to open up.
> They can do that now with NAT, so why would they implement?
>
> *Or* your operating systems firewall software, virus protection, and
> firewalls better be updated to this specification before it is deployed.
>
> If they NAT, then what is the gain over the current NAT? I can see this
> may have been a great alternative to NAT, but we already have NAT. So why
> would they implement?

Because most of the world has sat on its collective backsides until
it was too late to do a nice orderly dual stack deployment model
without having to share IPv4 addresses between customers.   Now
many ISP's are just trying to keep IPv4 on life support long enough
to move everybody to IPv6.

> How about port 6112 incoming, probably the most common gamer port.
> (http://www.speedguide.net/port.php?port=6112)
>
> Which DHCP home 1.2.3.4 IP address gets it? Or do all gaming servers
> that connect to port 6112 on home systems have to be re-written to find
> the correct port dynamically?

They can use IPv6 or they can use a relay.

> I know about port 6112 because I did the IANA registration for UNIX/CDE
> dtspcd on port 6112. I get many emails from people wanting to know about
> their game and how to configure it and their router (which I simply
> delete). Or maybe they are wrong and it does not need to be incoming
> and makes no difference.
>
> This would also break all dynamic-DNS servers. Many ISP's could care
> less about home based dynamic-DNS updated servers. Some care, it would
> break those that do not care.

Those using dynamic-DNS will just install AAAA records.

IPv4 is dead, stinking, rotting corpse and the sooner all the ISP's
on the planet start treating is as such the better the world will
be.

> It looks to me to be another DMARC type oops.
>
> --
>
> Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
> DouglasRoyer@gmail.com
> 714-989-6135

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org