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

Mark Andrews <marka@isc.org> Fri, 05 December 2014 04:08 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 71F461AC3B4; Thu, 4 Dec 2014 20:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level:
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 X7EOFsaT1zXn; Thu, 4 Dec 2014 20:07:56 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31001AC3AD; Thu, 4 Dec 2014 20:07:52 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id E900A1FCAED; Fri, 5 Dec 2014 04:07:48 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 28C41160057; Fri, 5 Dec 2014 04:11:52 +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 B814716004A; Fri, 5 Dec 2014 04:11:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0AC0C24EE5E2; Fri, 5 Dec 2014 15:07:45 +1100 (EST)
To: George Michaelson <ggm@algebras.org>
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> <89433C24-5E69-463B-804B-62F73E0DFB12@istaff.org> <CAMm+Lwhf4jxbWb9j-RMJJk7KiWdbRddbhPkyzwBntNTVQ_jHJw@mail.gmail.com> <CAKr6gn1e+Cq6v_eoPMFOpGmffX5jMeTzym3Q0DSD37zL649yhA@mail.gmail.com>
Subject: Re: Last Call: RFC 6346 successful: moving to Proposed Standard
In-reply-to: Your message of "Fri, 05 Dec 2014 13:02:22 +1000." <CAKr6gn1e+Cq6v_eoPMFOpGmffX5jMeTzym3Q0DSD37zL649yhA@mail.gmail.com>
Date: Fri, 05 Dec 2014 15:07:44 +1100
Message-Id: <20141205040745.0AC0C24EE5E2@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/O9kJJecxHSsp0-S7xSjfzwPFlzo
Cc: Dave Crocker <dcrocker@bbiw.net>, Phillip Hallam-Baker <phill@hallambaker.com>, Bob Hinden <bob.hinden@gmail.com>, IETF Discussion Mailing List <ietf@ietf.org>, IESG <iesg@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: Fri, 05 Dec 2014 04:08:02 -0000

In message <CAKr6gn1e+Cq6v_eoPMFOpGmffX5jMeTzym3Q0DSD37zL649yhA@mail.gmail.com>
, George Michaelson writes:
>
> Hang on.. the deployment of DNSSEC backed applications is a bit iffy if we
> depend on deployment of DNS based tricks to cover for V4/V6 interoperation
> surely?
> 
> -G

Agreed but people still seemed to want it despite it breaking DNSSEC.
They seemed to think that it was the only way to get to IPv6 only
which is isn't.  DS-Lite host mode will get you to a IPv6 network.
It also doesn't result in address lookups failing because people
sign their zones.

DNS64 still results in a CGN (NAT64) for IPv4 traffic.
DS-Lite still results in a CGN for IPv4 traffic.

There nothing that doesn't result in IPv4 access eventually being
through a CGN including staying with just IPv4.

> On Fri, Dec 5, 2014 at 12:39 PM, Phillip Hallam-Baker <phill@hallambaker.com
> > wrote:
> 
> >
> >
> > On Wed, Dec 3, 2014 at 4:29 PM, John Curran <jcurran@istaff.org> wrote:
> >
> >> On Dec 3, 2014, at 9:15 PM, Dave Crocker <dhc@dcrocker.net> wrote:
> >> > ...
> >> > So, after 25 years of effort, we've achieved 5% penetration.  Wow.
> >>
> >> I'm not certain that it is appropriate to count the years of protocol
> >> development, testing, and deployment into operating systems and routers
> >> as the denominator for the "5% penetration"...  There has not been a
> >> strong need for IPv6 until there was actual runout of IPv4 free pool,
> >> and this did not occur in any of the regions until 2011 (and is yet to
> >> happen in the North American region)   You should either measure service
> >> provider enablement of IPv6 from IPv4 free pool runout dates, or need to
> >> consider the IPv6 protocol support that has been achieved in deployed
> >> devices (enabled or not) over the 25 year period.
> >>
> >> Also, characterizing IPv6 success based on one providers success is
> >> probably not informative... there are service providers with much
> >> higher enablement -
> >> http://www.internetsociety.org/deploy360/blog/2014/09/verizon-wireless-hit
> s-56-ipv6-t-mobile-usa-40-att-24/
> >>
> >>
> > Just to clarify, what is the proposal here:
> >
> > 1) Address+Port become one way to manage the depleted address pool
> > 2) Address+Port become the one and only way
> >
> > I see no problem with 1, it is a sensible proposal. I would see a lot of
> > problems with 2.
> >
> >
> > Turning to John's point, the problem for IPv6 deployment is that IPv4
> > address depletion is not and will never be a reason for people deploying
> > IPv6. Until IPv6 delivers 100% of the functionality of IPv4, IPv4 behind
> > NAT will beat IPv6.
> >
> > The solution for deployment then is to make IPv6 deliver 100%
> > connectivity. And there are several ways we might go about that. DNS64 for
> > example. But any such scheme is going to require a break from the pure IP
> > end-to-end principle because the addresses have to change from IPv4 to IPv6
> > somewhere along the path.
> >
> >
> > It really isn't a major change. It does not even require a gateway to be
> > statefull. But some people think that it is more important to suppress such
> > heretical thoughts than to address the deployment problem.
> >
> 
> --001a11c32180462e9405096f4ef3
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Hang on.. the deployment of DNSSEC backed applications is =
> a bit iffy if we depend on deployment of DNS based tricks to cover for V4/V=
> 6 interoperation surely?<div><br></div><div>-G</div></div><div class=3D"gma=
> il_extra"><br><div class=3D"gmail_quote">On Fri, Dec 5, 2014 at 12:39 PM, P=
> hillip Hallam-Baker <span dir=3D"ltr">&lt;<a href=3D"mailto:phill@hallambak=
> er.com" target=3D"_blank">phill@hallambaker.com</a>&gt;</span> wrote:<br><b=
> lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
> #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra=
> "><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Wed, Dec 3, 2014=
>  at 4:29 PM, John Curran <span dir=3D"ltr">&lt;<a href=3D"mailto:jcurran@is=
> taff.org" target=3D"_blank">jcurran@istaff.org</a>&gt;</span> wrote:<br><bl=
> ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
> ccc solid;padding-left:1ex">On Dec 3, 2014, at 9:15 PM, Dave Crocker &lt;<a=
>  href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocker.net</a>&gt=
> ; wrote:<br>
> &gt; ...<br>
> <span>&gt; So, after 25 years of effort, we&#39;ve achieved 5% penetration.=
> =C2=A0 Wow.<br>
> <br>
> </span>I&#39;m not certain that it is appropriate to count the years of pro=
> tocol<br>
> development, testing, and deployment into operating systems and routers<br>
> as the denominator for the &quot;5% penetration&quot;...=C2=A0 There has no=
> t been a<br>
> strong need for IPv6 until there was actual runout of IPv4 free pool,<br>
> and this did not occur in any of the regions until 2011 (and is yet to<br>
> happen in the North American region)=C2=A0 =C2=A0You should either measure =
> service<br>
> provider enablement of IPv6 from IPv4 free pool runout dates, or need to<br=
> >
> consider the IPv6 protocol support that has been achieved in deployed<br>
> devices (enabled or not) over the 25 year period.<br>
> <br>
> Also, characterizing IPv6 success based on one providers success is<br>
> probably not informative... there are service providers with much<br>
> higher enablement - <a href=3D"http://www.internetsociety.org/deploy360/blo=
> g/2014/09/verizon-wireless-hits-56-ipv6-t-mobile-usa-40-att-24/" target=3D"=
> _blank">http://www.internetsociety.org/deploy360/blog/2014/09/verizon-wirel=
> ess-hits-56-ipv6-t-mobile-usa-40-att-24/</a><br><br></blockquote><div><br><=
> /div></div></div><div>Just to clarify, what is the proposal here:</div><div=
> ><br></div><div>1) Address+Port become one way to manage the depleted addre=
> ss pool</div><div>2) Address+Port become the one and only way=C2=A0</div><d=
> iv><br></div><div>I see no problem with 1, it is a sensible proposal. I wou=
> ld see a lot of problems with 2.</div><div><br></div><div><br></div><div>Tu=
> rning to John&#39;s point, the problem for IPv6 deployment is that IPv4 add=
> ress depletion is not and will never be a reason for people deploying IPv6.=
>  Until IPv6 delivers 100% of the functionality of IPv4, IPv4 behind NAT wil=
> l beat IPv6.</div><div><br></div><div>The solution for deployment then is t=
> o make IPv6 deliver 100% connectivity. And there are several ways we might =
> go about that. DNS64 for example. But any such scheme is going to require a=
>  break from the pure IP end-to-end principle because the addresses have to =
> change from IPv4 to IPv6 somewhere along the path.</div></div><br></div><di=
> v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It really isn&=
> #39;t a major change. It does not even require a gateway to be statefull. B=
> ut some people think that it is more important to suppress such heretical t=
> houghts than to address the deployment problem.</div></div>
> </blockquote></div><br></div>
> 
> --001a11c32180462e9405096f4ef3--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org