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

From: Bob Hinden <[email-masked]>
Date: Wed, 3 Dec 2014 09:04:25 -0800

Hi,

I do not support this action.  The words in the abstract in RFC6346:

   We are facing the exhaustion of the IANA IPv4 free IP address pool.
   Unfortunately, IPv6 is not yet deployed widely enough to fully
   replace IPv4, and it is unrealistic to expect that this is going to
   change before the depletion of IPv4 addresses.  Letting hosts
   seamlessly communicate in an IPv4 world without assigning a unique
   globally routable IPv4 address to each of them is a challenging
   problem.

are not accurate.  Noting one of many statistics that IPv6 use is growing, Google is reporting that 5% of their access traffic is from IPv6:

   http://www.google.com/intl/en/ipv6/statistics.html

We have effectively gotten to the point of depletion of IPV4 addresses, and the world has not come to an end.  I don't see any need to reclassify this RFC as a standard and think doing so would cause confusion in the community and be harmful to the Internet.

Bob

On Dec 1, 2014, at 2:38 PM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from an individual participant to make
> the following status changes:
> 
> - RFC6346 from Experimental to Proposed Standard
>    (The Address plus Port (A+P) Approach to the IPv4 Address Shortage)
> 
> The supporting document for this request can be found here:
> 
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-proposed/
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-12-29. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The affected document can be obtained via
> http://datatracker.ietf.org/doc/rfc6346/
> 
> IESG discussion of this request can be tracked via
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-proposed/ballot/
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Dec 2014 09:15:08 -0800

On 12/3/2014 9:04 AM, Bob Hinden wrote:
> are not accurate.  Noting one of many statistics that IPv6 use is
> growing, Google is reporting that 5% of their access traffic is from
> IPv6:

So, after 25 years of effort, we've achieved 5% penetration.  Wow.

And that's for a single, special service provider.

And while yes, the more recent adoption rate is considerably more
promising that that statistic implies, it leaves a basic question:

     According to what operational model does 5% adoption counter a
claim that "IPv6 is not yet deployed widely enough to fully replace IPv4"?

What are the current projections for at least 60% penetrations?  And is
even that sufficient for claiming that IPv6 sufficiently counter the
above text about IPv4?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Christian de Larrinaga <[email-masked]>
Date: Wed, 03 Dec 2014 17:38:59 +0000

> even that sufficient for claiming that IPv6 sufficiently counter the

Dave

Now that's a question.

We are seeing some more promises in UK that consumer broadband providers
are planning to deploy IPv6 towards the end of 2015.

The new vendor orientated UK IPv6 Council held a meeting recently where
BskyB, BT and Virgin made cooing noises, not entirely in tune with each
other though.

https://www.linkedin.com/groups/UK-IPv6-Council-8128401?home=&gid=8128401

But I've heard this type of thing a few times before over the last decade.

One question in the air for me is those ISPs that don't want to get into
Carrier Grade NAT and so need to go to IPv6 quickly are living in a
market dominated by ISPs who have plenty of IPv4 and or who say they are
happy to CGN their customers who will consequently have no IPv6.

The critical mass of adoption that is needed to justify deployment of
IPv6 seems to be less to do with % of users as being the power of ISPs
to impose their own policies on their customers.

That is not surprising if you consider that IP address policy has been
hijacked by ISPs long ago with IP addresses treated as a resource and
convenience for ISPs to manage their customers on their network rather
than one for users to specify and control to connect into the global
Internet.

One consequence of all this is that users who are provided with IPv6
with progressive ISPs are likely to be behind CGN and home NATs for IPv4
or some other IPv4 gateway service in the network. Not exactly the
vision of dual stack that was the dream.

C

-- 
Christian de Larrinaga

@ FirstHand
-------------------------
+44 7989 386778
[email-masked]
-------------------------

---

From: Ralph Droms <[email-masked]>
Date: Wed, 3 Dec 2014 12:31:55 -0800

I do not support this action, considering the statement motivating the action and the text in RFC 6346.

In my opinion, the document has been successful in providing a framework for development of specific protocols using the techniques described in the document.  It doesn't describe a specific protocol, as such, and there is no need or advantage to moving it to Proposed Standard.

If the document is moved to Proposed Standard, I recommend that the IESG request some additional information before approving the action.  

Specifically, which mechanisms using A+P have been designed, implemented and deployed?  Which of the techniques in RFC 6346 have been incorporated into these deployed mechanisms?  Have all of the techniques that would now have "Proposed Standard" status been incorporated into specific deployed mechanisms?

- Ralph

---

From: John Curran <[email-masked]>
Date: Thu, 4 Dec 2014 01:29:07 +0400

On Dec 3, 2014, at 9:15 PM, Dave Crocker <[email-masked]> wrote:
> ...

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-hits-56-ipv6-t-mobile-usa-40-att-24/

FYI,
/John

Disclaimer: my views alone.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 3 Dec 2014 21:33:40 +0000

> So, after 25 years of effort, we've achieved 5% penetration.  Wow.

Oh, I agree, it's pretty good, especially against a functioning incumbent.

Assuming you take the 1974 Cerf and Kahn paper as the startpoint for IPv4,
which may not be entirely reasonable, then how long was it before one out
of every twenty networked computers used it? 25 years would make that 1999.
Hard to say what the percentages were, but I suspect that OSI was still
significant, Netware had started the switchover from IPX/SPX only the year
before, and Windows tended to use NetBIOS Frames (certainly the installed
base did) - however overall, I seem to recall that IPv4 availability in
businesses was fairly common at that point, so I'd be willing to bet it was
higher than 5%.

However, I would guess it didn't pass 5% until toward the end of the '90's.
Prior to Windows 95, getting IPv4 support on a typical PC required
considerable technical ability, and prior to 1996 or so Win95 didn't
install IPv4 by default, so I doubt the numbers were significant at all in
percentage terms.

So if we pretend - probably incorrectly - that Win95 OSR2 caused an
immediate rise above 5%, then it's 22 years for IPv4.

In any case, it's essentially in the same ballpark.

Dave.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 3 Dec 2014 22:30:52 +0000

> So, after 25 years of effort, we've achieved 5% penetration.  Wow.

I don’t think that’s fair. 

Yes, the protocol was designed 20 years ago (draft-ietf-ipngwg-ipv6-spec and RFC 1883 are dated in 1995), and if we were doing it today we would separate location from identity (for multihoming reasons and in order to not need mptcp) and perhaps enable the use of very short IIDs (to not need 6lowpan). From that perspective, we are where we are. 

But serious allocation/deployment didn’t start until 2007 (http://www.oecd.org/internet/ieconomy/44953210.pdf figure 2), Microsoft (the largest end system vendor) didn’t have a credible IPv6 offering until Windows 7 at the earliest (2010), and non-trivial traffic levels didn’t happen until perhaps 2012 (14 years after 1995). By comparison, what we today call IPv4 was well underway in 1978 (look at the header in section 3.1 of IEN 28), RFC 760 was deployed in Korea in 1982, the Internet as a whole turned up IPv4 in January 1983, in June 1988 had 173 routes in the route table, and didn’t see heady growth until the mid-1990’s (about 15 years after IEN 28). If you’re starting from the first publication of a protocol specification, I’d say we’re about on track. 20 years after 1978 is roughly when IPv4 took over from IPX, DecNET, and the rest, give or take a few years.

> And that's for a single, special service provider. 

Again, let’s be accurate. That’s “as measured by a single, special services provider”. They’re not the only provider measuring it, just one that is particularly noisy about it. Akamai says that 2Q14 was the first quarter in their history in which the number of IPv4 addresses accessing their service decreased, and that they are seeing significant IPv6 usage, as do Yahoo and others. 

And in all of these cases, they are not measurements of “folks having IPv6 addresses and trying to use them”, they are measurements of “folks successfully using IPv6 end to end, through one or more ISPs, and engaging in communications with” whoever is reporting the measurement.

---

From: George Michaelson <[email-masked]>
Date: Thu, 4 Dec 2014 08:32:38 +1000

Penetration varies by economy. Taking 5% (btw, I disagree with this figure,
its unadjusted for population stats from the ITU and we (APNIC) get 3% but
thats another story) is masking that we have economies above 30%, and
economies on 0.01%.

I think this is a time when a single figure is actually not helping. The
net is bifurcating into a two class model: the dual stack world which is
well provisioned, and everyone else stuck behind ageing CPE and bad
investment issues

On Thu, Dec 4, 2014 at 8:30 AM, Fred Baker (fred) <[email-masked]> wrote:

> Yes, the protocol was designed 20 years ago (draft-ietf-ipngwg-ipv6-spec
> and RFC 1883 are dated in 1995), and if we were doing it today we would
> separate location from identity (for multihoming reasons and in order to
> not need mptcp) and perhaps enable the use of very short IIDs (to not need
> 6lowpan). From that perspective, we are where we are.
>
> But serious allocation/deployment didn’t start until 2007 (
> http://www.oecd.org/internet/ieconomy/44953210.pdf figure 2), Microsoft
> (the largest end system vendor) didn’t have a credible IPv6 offering until
> Windows 7 at the earliest (2010), and non-trivial traffic levels didn’t
> happen until perhaps 2012 (14 years after 1995). By comparison, what we
> today call IPv4 was well underway in 1978 (look at the header in section
> 3.1 of IEN 28), RFC 760 was deployed in Korea in 1982, the Internet as a
> whole turned up IPv4 in January 1983, in June 1988 had 173 routes in the
> route table, and didn’t see heady growth until the mid-1990’s (about 15
> years after IEN 28). If you’re starting from the first publication of a
> protocol specification, I’d say we’re about on track. 20 years after 1978
> is roughly when IPv4 took over from IPX, DecNET, and the rest, give or take
> a few years.
>
> Again, let’s be accurate. That’s “as measured by a single, special
> services provider”. They’re not the only provider measuring it, just one
> that is particularly noisy about it. Akamai says that 2Q14 was the first
> quarter in their history in which the number of IPv4 addresses accessing
> their service decreased, and that they are seeing significant IPv6 usage,
> as do Yahoo and others.
>
> And in all of these cases, they are not measurements of “folks having IPv6
> addresses and trying to use them”, they are measurements of “folks
> successfully using IPv6 end to end, through one or more ISPs, and engaging
> in communications with” whoever is reporting the measurement.
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 3 Dec 2014 16:58:22 -0800

RFC6346 reduces the space for TCP/UDP ports, which makes port-based attacks against protocols easier, as was mentioned in RFC6056:  

  "It is also worth noting that, provided adequate algorithms are in
   use, the larger the range from which ephemeral ports are selected,
   the smaller the chances of an attacker are to guess the selected port
   number."

The primary mitigation against the Kaminsky was port randomization and attacks against other protocols may also need such port randomization.  If RFC6346 progresses to Proposed Standard, its impact to the size of the port space should be noted in RFC6346bis's security considerations.

-d

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2014 12:31:31 +1100

In message <[email-masked]>, =?utf-8?Q?=F0=9F=9
4=93Dan_Wing?= writes:
> RFC6346 reduces the space for TCP/UDP ports, which makes port-based =
> attacks against protocols easier, as was mentioned in RFC6056: =20
> 
> The primary mitigation against the Kaminsky was port randomization and =
> attacks against other protocols may also need such port randomization.  =
> If RFC6346 progresses to Proposed Standard, its impact to the size of =
> the port space should be noted in RFC6346bis's security considerations.
> 
> -d

And https://tools.ietf.org/html/draft-ietf-dnsop-cookies-00 removes
the need for port randomization once deployed.  If you don't get a
cookie back then you can retry using a randomised port.

And just so you know it is not vapour ware BIND 9.10 has a experimental
implementation sans the error code called SIT.  We haven't yet
stopped randomizing the port but that is planned for.

Once we have a allocated code point we will be dropping non SIT
responses from servers we have had a SIT response from.

> >=20
> >=20
> >=20
> >=20
> > =
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose=
> d/
> >=20
> > [email-masked] mailing lists by 2014-12-29. Exceptionally, comments may =
> be
> >=20
> >=20
> > =
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose=
> d/ballot/
> >=20
> >=20
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Thu, 4 Dec 2014 11:52:42 +1000

I understand its not the core issue, but would it be safe to assume any
resolver which passes the cookie test has 5011 capability?  do we have any
concept of a minimum functionality set which you have to meet, such that we
can assume cookies tells us anything about protocol capability?

I'm going with no, but if anyone thinks this is a viable heuristic, I'd
love to know.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2014 13:11:46 +1100

In message <CAKr6gn2P6u=[email-masked]>
, George Michaelson writes:
> resolver which passes the cookie test has 5011 capability?

No.  I would expect cookies to be deployed even if you are not doing
DNSSEC.  It is very light weight compared to DNSSEC.

As for RFC 5011, it is a crock.  We should be using something like
CDS with start and end dates plus retry timers.  That way a resolver
will know which keys/ds records are supposed to be used as trust
anchors instead of the mess we have now where there is no certainty
that any zone is using RFC 5011.

> do we have any

The prerequistes for cookies is EDNS support.  You can theoretically
deploy it without having to know if the remote supports it.  That
said there are some really broken EDNS implementations out there.

See http://users.isc.org/~marka/ts.html for various measurements.

However I think that a active campain to inform operators that they
are deploying broken servers will work.  In many cases upgrading
to the latest nameserver release will fix the issue.

We also have a the following draft-andrews-dns-no-response-issue
which covers this as well as other issues.

Mark

> --047d7bdca1e442406305095a372f
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">I understand its not the core issue, but would it be safe =
> to assume any resolver which passes the cookie test has 5011 capability? =
> =C2=A0do we have any concept of a minimum functionality set which you have =
> to meet, such that we can assume cookies tells us anything about protocol c=
> apability?<div><br></div><div>I&#39;m going with no, but if anyone thinks t=
> his is a viable heuristic, I&#39;d love to know.=C2=A0</div></div><div clas=
> s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 4, 2014 at 11:=
> 31 AM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =
> target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
> =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
> ing-left:1ex"><br>
> In message &lt;<a href=3D"mailto:9450AE5B-9401-4E16-856E-FB6B45C3FAAD@cisco=
> .com">[email-masked]</a>&gt;, =3D?utf-8?Q?=
> =3DF0=3D9F=3D9<br>
> 4=3D93Dan_Wing?=3D writes:<br>
> &gt; RFC6346 reduces the space for TCP/UDP ports, which makes port-based =
> =3D<br>
> &gt; attacks against protocols easier, as was mentioned in RFC6056: =3D20<b=
> r>
> <span class=3D"">&gt;<br>
> &gt;=C2=A0 =C2=A0&quot;It is also worth noting that, provided adequate algo=
> rithms are in<br>
> &gt;=C2=A0 =C2=A0 use, the larger the range from which ephemeral ports are =
> selected,<br>
> &gt;=C2=A0 =C2=A0 the smaller the chances of an attacker are to guess the s=
> elected port<br>
> &gt;=C2=A0 =C2=A0 number.&quot;<br>
> &gt;<br>
> </span>&gt; The primary mitigation against the Kaminsky was port randomizat=
> ion and =3D<br>
> &gt; attacks against other protocols may also need such port randomization.=
> =C2=A0 =3D<br>
> &gt; If RFC6346 progresses to Proposed Standard, its impact to the size of =
> =3D<br>
> <span class=3D"">&gt; the port space should be noted in RFC6346bis&#39;s se=
> curity considerations.<br>
> &gt;<br>
> &gt; -d<br>
> <br>
> </span>And <a href=3D"https://tools.ietf.org/html/draft-ietf-dnsop-cookies-=
> 00" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-dnsop-cookies-=
> 00</a> removes<br>
> the need for port randomization once deployed.=C2=A0 If you don&#39;t get a=
> <br>
> cookie back then you can retry using a randomised port.<br>
> <br>
> And just so you know it is not vapour ware BIND 9.10 has a experimental<br>
> implementation sans the error code called SIT.=C2=A0 We haven&#39;t yet<br>
> stopped randomizing the port but that is planned for.<br>
> <br>
> Once we have a allocated code point we will be dropping non SIT<br>
> responses from servers we have had a SIT response from.<br>
> <span class=3D""><br>
> &gt; On Dec 1, 2014, at 2:38 PM, The IESG &lt;<a href=3D"mailto:iesg-secret=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> </span>&gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; The IESG has received a request from an individu=
> al participant to make<br>
> &gt; &gt; the following status changes:<br>
> </span>&gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; - RFC6346 from Experimental to Proposed Standard=
> <br>
> &gt; &gt;=C2=A0 =C2=A0 (The Address plus Port (A+P) Approach to the IPv4 Ad=
> dress Shortage)<br>
> </span>&gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; The supporting document for this request can be =
> found here:<br>
> </span>&gt; &gt;=3D20<br>
> &gt; &gt; =3D<br>
> &gt; <a href=3D"http://datatracker.ietf.org/doc/status-change-address-plus-=
> port-to-propose=3D" target=3D"_blank">http://datatracker.ietf.org/doc/statu=
> s-change-address-plus-port-to-propose=3D</a><br>
> &gt; d/<br>
> &gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; The IESG plans to make a decision in the next fe=
> w weeks, and solicits<br>
> &gt; &gt; final comments on this action. Please send substantive comments t=
> o the<br>
> </span>&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a> mailing=
>  lists by 2014-12-29. Exceptionally, comments may =3D<br>
> <span class=3D"">&gt; be<br>
> &gt; &gt; sent to <a href=3D"mailto:[email-masked]">[email-masked]</a> instea=
> d. In either case, please retain the<br>
> &gt; &gt; beginning of the Subject line to allow automated sorting.<br>
> </span>&gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; The affected document can be obtained via<br>
> &gt; &gt; <a href=3D"http://datatracker.ietf.org/doc/rfc6346/" target=3D"_b=
> lank">http://datatracker.ietf.org/doc/rfc6346/</a><br>
> </span>&gt; &gt;=3D20<br>
> <span class=3D"">&gt; &gt; IESG discussion of this request can be tracked v=
> ia<br>
> </span>&gt; &gt; =3D<br>
> &gt; <a href=3D"http://datatracker.ietf.org/doc/status-change-address-plus-=
> port-to-propose=3D" target=3D"_blank">http://datatracker.ietf.org/doc/statu=
> s-change-address-plus-port-to-propose=3D</a><br>
> &gt; d/ballot/<br>
> &gt; &gt;=3D20<br>
> &gt; &gt;=3D20<br>
> &gt;<br>
> <span class=3D"HOEnZb"><font color=3D"#888888">--<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <br>
> </font></span></blockquote></div><br></div>
> 
> --047d7bdca1e442406305095a372f--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Dec 2014 22:06:37 -0500

> We have effectively gotten to the point of depletion of IPV4 addresses, and the world has not come to an end.  I don't see any need to reclassify this RFC as a standard and think doing so would cau…

If you think this shouldn't be a standard, why didn't you object when MAP-E, MAP-T and Lightweight 4over6 were last-called?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Dec 2014 16:51:30 +1300

> If you think this shouldn't be a standard, why didn't you object when MAP-E, MAP-T and Lightweight 4over6 were last-called?

I can't answer for Bob, but those documents were the result of
a pretty laborious rough consensus process in Softwire and would
have been very hard to challenge that consensus. Also, if I'm
not mistaken, those solutions all explicitly involve transport
of IPv4 via IPv6 (as does XLAT464); A+P is just orthgonal to IPv6.

   Brian

---

From: <[email-masked]>
Date: Thu, 4 Dec 2014 04:00:15 +0000

That's an ad-hominem argument that has no bearing on the current proposal.

Though, if I was paying better attention, I'd have complained about those moves being unnecessary too.

L.

I still regret not objecting to BEEP going standards-track. Who uses it?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Dec 2014 20:53:58 -0800

> strong need for IPv6 until there was actual runout of IPv4 free pool,

John, Dave, Fred and George, et al,

First, please note that Bob Hinden offered the single Google reference
as the basis for arguing against the proposed IPv4-related activity.
(Also please note that I'm not commenting on that proposal at all.)  I
was merely responding to the use of that number.  My note was pointing
out the problem with the implied import of that number, not with its
validity nor with other, un-cited numbers.

That said, everything I keep hearing still says that v6 adoption is
very, very far from dominating the Internet.  Things appear to be
getting better, but that doesn't mean IPv4 is dead and irrelevant.

So to all the folk who are already touting the success of IPv6 -- and
especially using this to try to denigrate or dismiss v4 work --, I will
repeat my query:  When will IPv6 use hit 60%?  And if that's the wrong
number -- I did choose it rather randomly -- please select a better one,
justify it, declare a due date, and justify that.

Second, when comparing IPv4 adoption to IPv6, let's at least try to make
the comparison between apples to some form of vegetation rather than
bicycles.

v4 was a research project.  There was arguably no serious, large-scale
commercial market until around 1990, plus or minus a couple of years.
(Some product work predates this a few years, but the market was tiny.
It really required removal of the NSF restrictions to signal permission
for global growth.  And it took that long for the distraction of
artificial enthusiasm over OSI to die down.)  So really, it took less
than 10 years for IPv4 to reach a level of global penetration to a very
high percent.

By contrast, v6 was started with an explicit goal of serving a global
market and it was started to solve a serious problem.  (Arguably the
start of that work marked the start of serious v4 adoption, since it
marked the recognition that v4 really had developed into a global market.)

Claims that we didn't have a near-term 'need' for v6, when it was first
started, go against the original, stated impetus for starting the work.
 We did make the mistake of developing arguments to convince ourselves
that we could delay 10 or 15 years.  This allowed us to take far longer
to finish the work and to create an entirely incompatible version of IP,
thereby dramatically increasing adoption costs and barriers. (For those
who haven't read about 'second system syndrome', I recommend it.)

But just for grins, let's take Fred's 2007 date for V6, although I think
it far later than reasonable.  That means that in 7 years of serious
promotion, we have achieved only 5% penetration.

Given the importance of this bit of mechanism, that is really the best
we can do in that amount of time?

d/

---

From: George Michaelson <[email-masked]>
Date: Thu, 4 Dec 2014 15:06:47 +1000

I would repeat my initial response. 5% is over simplistic. Its between 0
and 50% depending on provider, economy and CPE issues.

its like saying the world economy grew by 2% when China was on 14% and
Greece was in recession. Yes, there is a world figure. No, it doesn't
adequately desribe things.

And no, this is not the best we can do. Its the best we've done, given a
very non-interventionist model.

We didn't ask regulators to incent the industry by offering tax allowances
and accelerated plant depreciation. Telcommunications equipment can be on a
20 year deprecation schedule.

We didn't require compliance to exceed tick-box status. Many LTE
deployments have V6 capability not enabled because it wasn't required, and
saved dollars.

GOSIP experience negatively informed mandates. You know I was there, I know
you were there. I suggest, that at an industry level we took the wrong
signals from what GOSIP actually told us.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Dec 2014 01:03:52 -0500

On Thu, Dec 04, 2014 at 01:11:46PM +1100, Mark Andrews wrote:

> CDS with start and end dates plus retry timers.

[…]

> That

[…]

> which covers this as well as other issues.

To be clear, then, the reduction of available port numbers that is the
result of A+P is solved by some proposals in a couple Internet-Drafts,
neither of which yet has critical mass, and that depend on a feature
of the DNS that is still broken in lots of places more than 10 years
after its specification?  Also, you think that the only actual DNSSEC
TA rollover mechanism we standardized is a crock?

I'm just trying to calibrate what "perfectly fine" means before I send
my comments on the A+P standards-track request.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Thu, 04 Dec 2014 09:47:10 +0100

> promotion, we have achieved only 5% penetration.

That's indeed pretty poor performance for a "new" product.

I am not particularly bothered with IPv4 depreciation. I am not
particularly worried that it has taken so much time for IPv6 use to
reach 5% either, when it comes to the statistics themselves. Indeed I am
comforted that by slowly ramping up, any remaining issues with IPv6 are
being worked out in real networks and so far we haven't hit total collapse.

What I am nervous about on the other hand, is that the lack of IPv6
adoption is making the alternative growth scenarios using Carrier Grade
NAT ever more attractive for some ISPs. CGN breaks the key end to end
principle that we have on the Internet and many mobile networks are
using CGN. Some non-mobile TelCos are now saying "hey we do not need to
roll out IPv6 - just look how happy customers are in using their mobile
networks with CGN!"

Kind regards,

Olivier

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Dec 2014 18:43:55 +0900

> adoption is making the alternative growth scenarios using Carrier
> Grade NAT ever more attractive for some ISPs. CGN breaks the key end
> to end principle that we have on the Internet and many mobile networks
> are using CGN. Some non-mobile TelCos are now saying "hey we do not
> need to roll out IPv6 - just look how happy customers are in using
> their mobile networks with CGN!"

thanks for understanding what the enemy is.

at the dublin meeting, cgn could be seen on the horizon, and i was
sufficiently unhappy to stand up in plenary and rant against it.  russ
and a few others said "that's nice, put your money where your mouth is.
what's the alternative?"  this was the impetus for a+p, as the document
states right up front.

for a broader view than 6346, see

    Nejc Skoberne, Olaf Maennel, Iain Phillips, Randy Bush, Jan Zorz,
    and Mojca Ciglaric, "IPv4 Address Sharing Mechanism Classification
    and Tradeoff Analysis," IEEE/ACM Transactions On Networking April
    2014.  http://archive.psg.com/130419.ton-v4-sharing.pdf

some of the alternatives sure make stateless a+p look pretty good, eh?
my favorite may be ds-blight; nat in the core and you get to fork-lift
your cpe, a double win there.

ipv4 has pretty much run out; the iana free pool ran out long ago, along
with apnic and ripe.  arin will very soon.  like it or not, ipv6 is
depressingly poorly deployed; and our major forward strategy seems to be
denial as so well demonstrated in this thread.  the stonewalling and
denial have distracted from reducing the friction of deploying ipv6, so
have helped drive cgn deployment; so it *really* pisses me off [0].

the paragraph to which bob hinden objected

is tragically true; please point out a single untruth.  get over it.

and i like the situation less than most folk here, and with good reason.
my employer has thrown money at real ipv6 deployment for over 15 years,
wrote a lot of the stack many implementations still use today, ...

randy

---

[0] - i still feel the bruises and broken bones of the multiple years it
      took to get the tla/nla crap removed.  and that was just one of
      the battles.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2014 21:50:30 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> after its specification?

It's only broken because no one has been checking servers for
compliance.  All the bugs are about 5 minutes work to fix if they
actually get reported to the nameserver vendors and operators of
the servers. 

As for implementing cookies / SIT that is about a days work.  It's
actually a lot less work than port randomisation is.

> Also, you think that the only actual DNSSEC TA rollover mechanism we
> standardized is a crock?

Just because something is standardised doesn't mean that it is not
a crock.

RFC 5011 doesn't provide a mechanism to tell others if the operators
are using it for key management.  It overloads SEP bit.  There are
no timing parameters, one size doesn't fit all.  It increases DNSKEY
RRset size unnecessarially.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 04 Dec 2014 08:00:02 -0300

> stopped randomizing the port but that is planned for.

May I ask why would you want to do that?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 08:23:00 -0500

> That's an ad-hominem argument that has no bearing on the current proposal.

It's not "ad hominem" to ask someone why they think one thing is different from another.   I actually agree with Bob that the abstract to 6346 says something that's not true, and it needs to be changed (I hadn't thought about it before he pointed out the problem).   I asked Bob why he didn't object to the other proposals because I wanted to know.   I doubt he was unaware of them.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Dec 2014 05:34:40 -0800

> It's not "ad hominem" to ask someone why they think one thing is different from another.   I actually agree with Bob that the abstract to 6346 says something that's not true, and it needs to be cha…
It would help me understand your question (as a 3rd party to the conversation) if you would say more about why you think an objection to the tex Bob quoted from RFC 6346 would be related to objections to MAP-E, MAP-T and Lightweight 4over6.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 09:36:39 -0500

> It would help me understand your question (as a 3rd party to the conversation) if you would say more about why you think an objection to the tex Bob quoted from RFC 6346 would be related to objecti…

The question was essentially a half-formed thought that I probably should have allowed to fully form before expressing.   Bob objected to some language in 6346; I agree that the language is wrong.   It made sense to write at the time, but actually the reason A+P has been a success is because it's a good way to enable the IPv6 transition, not because it's a good way to postpone it.

So if Bob's only objection to the document is that text, I agree with him that the text is wrong and should be changed.   The question is, _is_ that his only objection?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Dec 2014 07:31:43 -0800

On 12/4/2014 5:34 AM, Ralph Droms wrote:
>> It's not "ad hominem" to ask someone why they think one thing is 
>> different from another.
...
> It would help me understand your question (as a 3rd party to the 
> conversation) if you would say more about why you think an objection 
> to the tex Bob quoted from RFC 6346 would be related to objections
> to MAP-E, MAP-T and Lightweight 4over6.

That's really an essential point.

As originally asked, the question to Ted was about Ted, since it offers
no foundation for challenging Ted on the linkage between the current
proposal and a set of previous ones.

In the form Ralph is suggesting, the questionner takes responsibility
for stating and defending the linkage, so that the question then asked
to Ted really is clearly about the linkage.

Ad hominem mis-steps often really are mis-steps in language formulation.
 Legitimate points or questions are unfortunately cast in terms of the
other person.  They almost never need to be, and even when they do, the
language can be cast with a clear focus on the substance and not the
other person.

d/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 11:26:44 -0500

> proposal and a set of previous ones.

We have two specifications that have been approved by the IESG and the IETF as standards that use A+P, and one additional that will be last-called shortly as a standards track document.   So if the error in 6346 is just in the text Bob quoted, I agree with Bob.   But if Bob is saying that A+P shouldn't be advanced because its technical content is wrong, then we would seem to have a problem.   That's the question I wanted to resolve by asking Bob the question I asked.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Dec 2014 11:28:00 -0500

Dear colleagues,

>     (The Address plus Port (A+P) Approach to the IPv4 Address Shortage)

Having re-read that document and having read the reasoning behind the
move from experimental, I do not support the current proposal, but I
support the idea of moving A+P to the standards track.  

RFC6346bis needs to address a few issues.  First, since there was an
experiment, somewhere one needs to determine what experimental pieces
worked well and what parts did not.  Any RFC6346bis should include
some notes about what changed between RFC 6346 and whatever new comes
out.  In particular, section 5 has more than one deployment scenario,
and it would be really helpful to understand which scenarios work well
(or, better, well enough) and why.  Similarly, it seems to me that
section 1 should be expanded to include observations about problems
with A+P.

In addition, I agree with the remarks elsewhere in the thread that
reducing the number of ports available to clients reduces their
resilience to certain kinds of DNS attacks.  I'm aware that someone
offers an alternative mechanism elsewhere in this thread, but that is
not yet standardized or widely deployed, so it is not an answer today.
A+P effectively reduces the utility of a spoofing-resilence technique
already deployed, so that surely needs to be in the security
considerations.

I do not accept the arguments, however, that A+P should not be put on
the standards track because doing so would somehow chip away at the
legitimacy of the arguments to deploy IPv6.  First, I do not think
that Experimental status is supposed to be some sort of second-class
version of standardization.  It is used that way too often, but that
is a mistake.  The experimental deployments have happened; there are
results.  If it worked, we should put this on the standards track.  At
the same time, if the deficiencies of this technique compared to IPv6
are sufficiently described, then either that will be positive evidence
that IPv6 is the right thing to do, or else IPv6 is not actually so
shiny.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 4 Dec 2014 16:44:02 +0000

> not yet standardized or widely deployed, so it is not an answer today.

And it's not only DNS that is being attacked, that attack just happened to be widely publicized. (For example, BGP sessions have been the target of TCP RST attacks.) Port randomization is a generally useful technique, which is why we did RFC6056, the effectiveness of which is reduced by A+P.

Lars

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 11:57:51 -0500

> And it's not only DNS that is being attacked, that attack just happened to be widely publicized. (For example, BGP sessions have been the target of TCP RST attacks.) Port randomization is a general…

This is a concern that's been discussed at length already.   It's a real problem.   However, the actually application for A+P is in a dual-stack environment, where DNS queries really ought to be going over the IPv6 transport, not the IPv4 transport.   Additionally, a great many of the commonly used port-intensive services at this point are available over IPv6, and we would prefer that they go over IPv6.   So although there is clearly a reduction in the available number of _IPv4_ ports in an A+P scenario, the total number of available ports in this situation is more: the host no doubt has at least one and perhaps more than one IPv6 address, which can be used for all but the remaining legacy applications.

So it's possible that this ought to be discussed further in the document.   But the fundamental answer to the port guessing vulnerability is "switch to IPv6."   And as several people have already mentioned on this thread, the port starvation problem exists in any NAT, whether A+P is being done or no.   It is particularly bad in CGN, whether they are stateful or stateless.   So it's good to call out the issue and use it to motivate the advice that service providers _really_ ought to be turning on IPv6 if they haven't already.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Dec 2014 12:17:34 -0500

On Thu, Dec 04, 2014 at 11:57:51AM -0500, Ted Lemon wrote:
> This is a concern that's been discussed at length already.   It's a real problem.   However, the actually application for A+P is in a dual-stack environment, where DNS queries really ought to be going over the IPv6 transport, not the IPv4 transport.

Lots of servers do funny things depending on the transport over which
the query came, so I don't think that's a viable argument.  

> So it's possible that this ought to be discussed further in the document.

That was my point: as I said, I do not oppose standardizing A+P, I
just oppose taking the existing document, slapping new boilerplate and
a new number on it, and publishing.  There are changes needed.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 12:24:21 -0500

> the query came, so I don't think that's a viable argument.  

This is actually a really good argument for saying that servers _shouldn't_ do that.   But to dig into that a bit deeper, I think there are two cases where servers do different things.   First case, the server is trying to steer traffic for a CDN.   In that case, you want to steer the traffic to IPv6, so doing the query over IPv6 is always the right thing to do in this case.   If the service provider is only providing CDN over IPv4, and the client uses the less desired path because of this, that's a problem the service provider should fix, and not a problem we need to worry about.   That said, the SP can certainly give a CDN-tailored answer based on the IPv6 source address if this is desired.

Second case, the server only returns AAAAs if the query comes over IPv6.   In this case, we want the query to go over IPv6.   But this is likely a decision being made about the SP's caching nameserver, not about the client, so we should not actually see different behavior depending on whether the _client_ does the query using IPv4 or IPv6.

Is there another case I'm missing (wouldn't surprise me)?

> a new number on it, and publishing.  There are changes needed.

Yup, I think you are right, much as I generally prefer less work to more.

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Dec 2014 04:03:36 +0900

> I actually agree with Bob that the abstract to 6346 says something
> that's not true

this is the paragraph bob quoted

please point out what is not true about that paragraph.  other than the
tense, of course; the iana pool ran out; as have apnic, ripe, and soon
arin.

the first step in solving a problem is admitting we have it.

randy

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Dec 2014 11:45:36 -0800

> of IPv4 via IPv6 (as does XLAT464); A+P is just orthgonal to IPv6.

+1

Bob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Dec 2014 21:39:24 -0500

On Wed, Dec 3, 2014 at 4:29 PM, John Curran <[email-masked]> wrote:

> higher enablement -
> http://www.internetsociety.org/deploy360/blog/2014/09/verizon-wireless-hits-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.

---

From: George Michaelson <[email-masked]>
Date: Fri, 5 Dec 2014 13:02:22 +1000

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

On Fri, Dec 5, 2014 at 12:39 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> 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.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 23:07:00 -0500

On Dec 4, 2014, at 10:02 PM, George Michaelson <[email-masked]> wrote:
> 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?

DNS64 can be done by the client, in which case DNSSEC validation can be performed _before_ translating the IPv4 address from the A record into an IPv6 address in the NAT64 prefix.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Dec 2014 15:07:44 +1100

In message <[email-masked]>
> depend on deployment of DNS based tricks to cover for V4/V6 interoperation

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.

> --001a11c32180462e9405096f4ef3
> <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">[email-masked]</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">[email-masked]</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:[email-masked]" target=3D"_blank">[email-masked]</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--
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Dec 2014 16:00:57 +1100

In message <[email-masked]>, Ted Lemon 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?
>
> DNS64 can be done by the client, in which case DNSSEC validation can be
> performed _before_ translating the IPv4 address from the A record into an
> IPv6 address in the NAT64 prefix.

Which requires every DNSSEC aware client to also be DNS64 aware.
I though we were trying to remove NAT kludges requires that they
be kept forever.

RFC 6147 also get DNSSEC signalling completely wrong.  There is NO
combination of bits that indicates validation will / will not occur.

Additionally the discover mechanism for the DNS64 parameters is to
say the least baroque.  It would have been much simpler to add a
EDNS option so the nameserver could actually return them or the
addresses it would have otherwise returned if DO=1 is set.  These
could be cached along with the NODATA response by intermediate
nameservers.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Dec 2014 00:54:26 -0500

> depend on deployment of DNS based tricks to cover for V4/V6 interoperation
Not at all.

If it isn't a public key or a security policy, an application has
absolutely no reason to validate DNSSEC chains. Since an A or AAAA record
isn't pointing to an authenticated endpoint, authentication at the client
is spurious.

There is value in validating A, AAAA etc. records at the resolver and there
is value in validating TLSA records at the application.

This is why we need DPRIV to provide authentication of the connection
between the client and its trusted resolver.

On Thu, Dec 4, 2014 at 11:07 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <
> [email-masked]>
> we

There has to be a gateway but the cute thing with DNS64 is that the gateway
can be provided in the destination network rather than having to be at the
source network. So the model is actually rather more powerful than carrier
grade NAT.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Dec 2014 06:43:03 -0300

On 12/04/2014 01:44 PM, Eggert, Lars wrote:
>> resilience to certain kinds of DNS attacks.  I'm aware that
>> someone offers an alternative mechanism elsewhere in this thread,
>> but that is not yet standardized or widely deployed, so it is not
>> an answer today.
> 
> And it's not only DNS that is being attacked, that attack just
> happened to be widely publicized. (For example, BGP sessions have
> been the target of TCP RST attacks.) Port randomization is a
> generally useful technique, which is why we did RFC6056, the
> effectiveness of which is reduced by A+P.

+1

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 5 Dec 2014 11:53:15 -0800

> I though we were trying to remove NAT kludges requires that they

The BEHAVE working group was unable to find any other approach to get DNSSEC and NAT64 to work together.  If you have a proposal, please share.

> combination of bits that indicates validation will / will not occur.

Yes, you reported that as an errata on 2012-05-30.  It was rejected on basis of "Changes that are clearly modifications to the intended consensus, or
involve large textual changes, should be Rejected.", http://www.rfc-editor.org/errata_search.php?rfc=6147.

> could be cached along with the NODATA response by intermediate

That does appear a nice approach for a DNS64-aware client to learn the NAT64 prefix.

-d

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Dec 2014 09:16:55 +1100

In message <[email-masked]>, =?utf-8?Q?=F0=9F=9
4=93Dan_Wing?= writes:
> The BEHAVE working group was unable to find any other approach to get
> DNSSEC and NAT64 to work together.  If you have a proposal, please share.

Which should have been a reason to reject DNS64 and NAT64 as anything
other than a interim measure.

> Yes, you reported that as an errata on 2012-05-30.  It was rejected on
> basis of "Changes that are clearly modifications to the intended
> consensus, or
> involve large textual changes, should be Rejected.",
> http://www.rfc-editor.org/errata_search.php?rfc=6147.

Which doesn't mean I am wrong or that RFC 6147 is correct. Just
that you want to put your fingers in your ears and go "na na na I
can't hear you".

If something is wrong it should be acknowledged regardless of the
size of the error.  This is a error in fact.  This is not a matter
of opinion.

A client can be validating with both CD=0 and CD=1 queries.

In fact it is better for a recursive validating client to use CD=0
queries than CD=1 queries in the presence of a attack as the recursive
server then filters out the forged responses it is getting rather
than passing them through to the validating stub client.  It only
falls back to CD=1 on SERVFAIL in case that SERVFAIL was a result
of a bad trust anchor or a bad clock in the resursive server.

For completeness one can also start with CD=1 and retry with CD=0
on validation failure.  This should cause the recursive server to
issue new queries and validate them before passing them onto the
client.

There is no perfect CD state for a recursive validating client to
send and I've state as much many times.

Always send CD=1 is wrong.  When you have a daisy chain of servers
the ultimate client looses control of when validation is or isn't
done in the intermeditate servers.  Unfortunately dnsext had a chair
that refused to reopen discussion on this issue.  Yes, consenus
gets things wrong.

The CD state of a outbound query should match the state of the
inbound query that triggered it.

All recursive servers need to validate.

A client can on validate if it sets DO=1.  DO=1 does not mean that
a client will be validating.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Dec 2014 19:46:40 -0500

> other than a interim measure.

That depends on what you believe the role of DNSSEC should be and where you
think validation should take place.

Right now we don't have any platform vendor committed to the client
validation model and my interactions with the two main platform vendors
were consistently negative.

We do have interest in DNSSEC validation of TLSA records but as I point
out, that is a different issue.

We need to deploy IPv6. That is absolutely essential. Maintaining the
purity of the 'end-to-end' model is not. If DNSSEC has to bend to make IPv6
transition viable then so be it.

One of the core problems here is that the DNS should be central to the
Internet architecture but it is still treated as optional.

According to our current architecture, an application performs discovery by
either using an IP address or a DNS name and these are treated as both
being application layer concerns. These should be considered two different
layers. The application should only deal in DNS names that are resolved by
its chosen resolution service.

Any application interaction with IP addresses should be strictly for
debugging purposes.

---

From: Lee Howard <[email-masked]>
Date: Wed, 10 Dec 2014 15:07:45 -0500

>So, after 25 years of effort, we've achieved 5% penetration.  Wow.

A lot of things with 5% penetration are considered wildly successful.

>claim that "IPv6 is not yet deployed widely enough to fully replace IPv4"?

Depends on what you're trying to do with it. It's great for walled gardens
and translatable clouds, with enormous displacement in some mobile
networks.

>even that sufficient for claiming that IPv6 sufficiently counter the

Eric Vyncke has provided us with a nice tool for this:
https://www.vyncke.org/ipv6status/project.php

It only lets you estimate one country at a time. Belgium is a good one,
near 30% using IPv6 to reach Google. Or, using the U.S., extrapolating
from the last 500 days using a 5th-order polynomial curve, we hit 60% in
mid-2017. And 100% in the first half of 2018.

My opinion on this Last Call: it's about IPv4, and I don't care about IPv4
anymore. We shouldn't be bothering with it in the IETF.

Lee

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Dec 2014 15:48:16 -0500

> anymore. We shouldn't be bothering with it in the IETF.

This is why I was so surprised by the controversy.   Sigh.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Dec 2014 18:18:45 -0500

On Wed, Dec 10, 2014 at 3:48 PM, Ted Lemon <[email-masked]> wrote:

> This is why I was so surprised by the controversy.   Sigh
>

Unfortunately it seems that a bunch of folk early on decided that the best
way to motivate the transition from IPv4 to IPv6 was to make IPv6 'better'
and to sabotage any attempts to mitigate the consequences of IPv4 shortage.

So we had the campaign against NAT, even though it was obviously benefiting
people economically. With 80 nodes on my internal net, I would be paying
several thousand dollars a year to have static IPs for each (not to mention
depriving others of Internet access). In fact my ISP now requires me to run
NAT.

In hindsight 32 bits was exactly the wrong size. If IPv4 had been 16 bits
we would have run out of address space long, long ago when the cost of
transition was not so prohibitive - there would only be 65K nodes to
change(!).

The way to achieve transition is to do the exact opposite of the old
strategy. Instead of making IPv6 different, we have to make it exactly the
same so that the transition cost is minimal.

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Dec 2014 17:39:13 -0700

This part scares the hell out of me:

"...Customers could, for example, receive an
   initial fixed port range, defined by the operator, and dynamically
   request additional blocks, depending on their contract. ..."

What about legacy software that decides what port it is going to use?

Well their packets go to the wrong hardware? Seems a BIG security hold to me.

-
Doug Royer
[email-masked]
(714)989-6135

On Wed, Dec 10, 2014 at 4:18 PM, Phillip Hallam-Baker <[email-masked]

> So we had the campaign against NAT, even though it was obviously
> benefiting people economically. With 80 nodes on my internal net, I would
> be paying several thousand dollars a year to have static IPs for each (not
> to mention depriving others of Internet access). In fact my ISP now
> requires me to run NAT.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Dec 2014 20:31:13 -0500

> Well their packets go to the wrong hardware? Seems a BIG security hold to me.

This is equivalent to the current practice of giving a home gateway an IP address with all 64k ports.   These ports are _already_ shared by devices behind the NAT.   The difference with port sharing is just that you start out with fewer than 64k ports.   Legacy software of the type you describe already doesn't work with a NAT.

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Dec 2014 19:18:08 -0700

> This is equivalent to the current practice of giving a home gateway an IP address with all 64k ports.   These ports are _already_ shared by devices behind the NAT.   The difference with port sharin…

Maybe I misunderstand what I read. Currently say I have 80 hosted server 
each with its own IP address
Each uses port 25 (smtp), 143 (imap), 80 (http) 22 (ssh) , 443 https), 
465 (smtp), 587 (smtp), 10000 (webmin) , and 20000 (usermin). The host 
name are say 80 random host names. Some use port 5432 (postgres), some 
port 3306 (mysql). And others use other random ports.

My hosting provider decides to follow this spec and assigns them all to 
ip address 1.2.3.4  and map
the port numbers across a 80 ranges, each with at least 9 assigned ports.

So How do say http://random-host-name-xx from a browser and have it work?
It would return 1.2.3.4 with dns, so 100% of *all* browser software 
would need to be updated to get the port extension to determine it 
really should go to http://randm-host-name-xx:1234 ?

The site admin is not going to have to know the 80 different port 
numbers for webmin (old port 10000) ?

I can't see how changing almost all Internet software is going to move 
faster than waiting for IPv6.

The current text also says double nats should be avoided. Do people know 
that a HUGE amount of home Wifi devices are NATs behind their router 
(NAT) and possibly behind their ISP NAT ?

Please tell me I misunderstand the text.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Dec 2014 21:43:40 -0500

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.

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Dec 2014 20:17:39 -0700

> 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 s…

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.

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?

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?

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.

It looks to me to be another DMARC type oops.

--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Dec 2014 22:28:06 -0500

On Dec 10, 2014, at 10:17 PM, Doug Royer <[email-masked]> wrote:
> 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

A+P is available in OpenWRT.   And you aren't listening: I just said that this makes the most sense in a dual stack environment.   Dual stack means IPv4+IPv6.   In an A+P deployment, the expectation is that you get better service over IPv6, but still need some residual support for IPv4, for which A+P is adequate.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Dec 2014 14:45:00 +1100

In message <[email-masked]>, Doug Royer writes:
> > 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.
>
> IPv6 one? I still see no time to implement gain if this is the plan.

They will install IPv6 + A+P for IPv4.

> 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?
>
> firewalls better be updated to this specification before it is deployed.
>
> 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.

> 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.

> 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.
>
> 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.

---

From: Lee Howard <[email-masked]>
Date: Thu, 11 Dec 2014 17:11:03 -0500

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Wednesday, December 10, 2014 6:18 PM
To:  Ted Lemon <[email-masked]>
Cc:  Lee Howard <[email-masked]>, IESG IESG <[email-masked]>, Bob Hinden
<[email-masked]>, Dave Crocker <[email-masked]>, IETF Discussion
<[email-masked]>
Subject:  Re: Last Call: RFC 6346 successful: moving to Proposed Standard

> Unfortunately it seems that a bunch of folk early on decided that the best way
> to motivate the transition from IPv4 to IPv6 was to make IPv6 'better' and to
> sabotage any attempts to mitigate the consequences of IPv4 shortage.

IPv6 IS the mitigation of the consequences of IPv4 shortage.

But my opinion is well-documented in draft-george-ipv6-support.

> 
> The way to achieve transition is to do the exact opposite of the old strategy.
> Instead of making IPv6 different, we have to make it exactly the same so that
> the transition cost is minimal.

It isn't clear to me that a change in strategy is required. To remain on
topic, will moving this Experimental RFC to Proposed Standard make the
transition any easier?

The goal isn't IPv6, though‹the goal is a functioning, interoperable
Internet. I believe we have consensus that IPv6 is the best mechanism to
achieve that. I think I see consensus that some transition tools are
temporarily useful as people wait for others to deploy. Do we need a
Proposed Standard for those temporary transition tools?

Lee

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 17:32:42 -0500

> IPv6 IS the mitigation of the consequences of IPv4 shortage.

The problem with IPv6 is that it is a multi-party coordination problem. I
can't deploy IPv6 unilaterally, I rely on my ISP to start supporting it.

> It isn't clear to me that a change in strategy is required.
>

Well twenty years later the only changes in IPv6 deployment strategy have
been in the direction I originally proposed and almost everyone rejected as
heresy.

> To remain on topic, will moving this Experimental RFC to Proposed Standard
> make the transition any easier?
>

Some of the transition mechanisms will be with us for decades. Yes they
need to be standardized.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Dec 2014 17:02:25 -0800

On 12/11/2014 2:11 PM, Lee Howard wrote:
> The goal isn't IPv6, though—the goal is a functioning, interoperable

The goal isn't Proposed Standard for temporary transition tools.  The
goal is a functioning, interoperable Internet.

Standardization is a means of providing common, interoperable
capabilities.  If a tool will facilitate interoperability, then
standardizing it can facilitate its adoption.

When pursuing transitions in open, diverse environments, calling a tool
'temporary' is mostly a political statement that seeks to marginalize
the tool, since transition on the Internet is often measured in decades.

Seriously, we have no idea how long these tools will get used, but we do
have experience over the years that says large-scale transitions --
especially when involving very large number of highly independent
decisions makers -- takes a very, very long time.  And saying 'decades'
is not stretching was can be expected.

By most criteria, calling that "temporary" is functionally wrong.

I suppose the other approach we can take is to say that we will ignore
95% of Google's users, until they adopt IPv6.  That seems to be the
implication of refusing to pursue IPv4-based tools in the IETF.

However that sort of coercive customer service model has its own downsides.

d/

---

From: heasley <[email-masked]>
Date: Fri, 12 Dec 2014 05:12:04 +0000

> to move everybody to IPv6.

yawn.  Much of the end-user equipment still does not support v6.  Much
of it has to be replaced with newer h/w for v6 support or support folks
have to visit each site to perform upgrades (spendy).  Many core devices
still have partial or missing support.  Some protocols still lack v6
support.  Multihoming is looking rather ugly for small networks (like
those with just 1 v4 /24, thus need less than a v6/48).  usw.

How much quicker do folks think implementation would have been by vendors,
then adoption by users, had the ietf not felt obligated to rearchitect v4?
vs. just expand the address space and ship it, which is the only area where
v6 appears to shine anyway.  [yes, I am ignoring the need for transition
mechanisms]

I don't know anyone enchanted by v6.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2014 17:15:33 +1100

In message <[email-masked]>, heasley writes:
> yawn.  Much of the end-user equipment still does not support v6.

When was the last time you could actually buy a tablet, laptop,
desktop, cell phone that didn't support IPv6?  You can get printers
that support IPv6.  You can get CPE devices that support IPv6.
Games consoles support IPv6.  Those that don't can be upgraded
over the net.

I'm not sure where TV's are at but the hardware supports IPv6 and
just yesterday the TV asked my wife whether to download a new version
of the software and this is a second hand TV.  At $0 I wasn't going
to worry if it supports IPv6.  The dogs pulled the old one over
smashing the LCD screen.  Just had to find the right remote to press
select.  There is no reason the manufacturer couldn't ship a update
that supports IPv6.

Similarly for fridges.

> Much

I saw the same excuses being handed out a decade ago.  If you have
equipment that needs to be replace now it means you failed to plan.

> v6 appears to shine anyway.  [yes, I am ignoring the need for transition

I've got 15 year old equipment running IPv6.  I've got lots of IPv6
equipment that has been end-of-lifed by the manufacturer.  Windows
XP supported IPv6 and that was releases in 2001.  I've been running
IPv6 at home for over a decade now.  I was adding IPv6 to the
products we ship ~16 years ago now and it has basically remained
unchanged since then.

If your consumer device does not support IPv6 don't blame the IETF.
Blame the manufacturer.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Dec 2014 06:06:30 -0800

On 12/11/2014 10:15 PM, Mark Andrews wrote:
> that support IPv6.  You can get

This confuses 'devices' with 'end to end communications'.  And
end-to-end communication is limited to the least-capability component in
the sequence.  (And to the extent that operators choose to provide
/different/ services over IPv4 than IPv6, the switching cost tends to be
made higher.)

It also appears to ignore use of all existing devices that do /not/
support IPv6, most of which won't convert to it.  Lest the response be
something like "they already work so they aren't a problem" please see
above.

d/

---

From: Lee Howard <[email-masked]>
Date: Fri, 12 Dec 2014 12:15:01 -0500

>goal is a functioning, interoperable Internet.

Agreed!

>standardizing it can facilitate its adoption.

By definition of "Proposed Standard," yes.

>the tool, since transition on the Internet is often measured in decades.

I see your point, but it wasn't really my intent; if it was considered a
temporary workaround, it would seem weird to advance it.

The point here is whether RFC 6346 can be moved to Proposed Standard.
Others have already pointed out problematic text, so we need a new draft
to evaluate.

The other gates to Proposed Standard (RFC2026):
* A Proposed Standard specification is generally stable,
* has resolved known design choices,
* is believed to be well-understood,
* has received significant community review, and
* appears to enjoy enough community interest to be considered valuable.

Are we arguing about "enough community interest"?

Also:
* The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

I think this qualifies under that sentence. There is probably real
operational experience, and I think it is reasonable for the IESG to
require that some of it be documented (in the document to be moved) before
advancing.

Other text changes:
* Update discussions of the status of transition
* Update references to current versions of documents (e.g., PCP,
stateless-4v6, everything that was "Work in Progress" when the doc was
originally written)
* Mention other port-allocation methods and considerations, e.g.,
draft-chen-sunset4-cgn-port-allocation-05 and the RFCs listed in its
Security Considerations document, draft-donley-behave-deterministic-cgn,
* Update the Security Considerations section (as in the previous point)
* Add more logging discussion, as documented in the above docs and
elsewhere
* Replace "Double-NAT" with NAT444 and refer to documents discussing it
* Redefine "CPE" to refer to a layer 3 device, not a layer 2 device
* A previous comment indicated that ports 0-1024 are usually reserved;
further discussion (and maybe update the examples to exclude them)
* Additional discussion of PCP experience relevant to A+P
* ICMP handling says "gateway device must rewrite the "Identifier" and
perhaps "Sequence
   Number" fields" and I would like to see more detail/experience under
that "perhaps."

Until at least these items are addressed, I oppose moving this document to
Proposed Standard.

>implication of refusing to pursue IPv4-based tools in the IETF.

This sounds like "mostly a political statement."  Trying to get this back
onto the specific question here, rather than another round of ranting
about the IPv4-IPv6 transition in general.

Lee

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2014 18:13:47 -0000

>desktop, cell phone that didn't support IPv6?

I have a Samsung SCH-S738C "Centura" phone running Android 4.0.4.  It
does not support IPv6, and it's for sale all over the U.S.  It's not a
bad phone for $40.

Perhaps things are different in oz, but it's still going to be a very long
time until we can ignore all of the v4-only devices that people use
every day.

R's,
John

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Thu, 11 Dec 2014 15:23:33 -0800

On 10 Dec 2014, at 15:18, Phillip Hallam-Baker wrote:

>>> My opinion on this Last Call: it's about IPv4, and I don't care 
>>> about
>> IPv4
> benefiting

The amount of work-arounds that NAT has caused in various protocols, and 
"interesting" behaviors in various applications that have always 
expected E2E (because that was the model we told them) is 
"entertaining."  Am I reading your statement correctly that you would 
have preferred the IETF to completely toss the base architecture of E2E 
out?  The "campaign against NAT" was, for many of us, not philosophical, 
but a campaign against application breakage, and state scale in large 
networks.  NAT has been a necessary evil, but it shouldn't be 
encouraged.

> transition was not so prohibitive - there would only be 65K nodes to

Really?  Interesting approach.  I would have just preferred a larger 
space to begin with, rather than breaking things at either the 16bit or 
32bit exhaustion point - call me boring, but I would prefer to NOT 
mutate base architecture after it is deployed.  Of course, that decision 
would have required a certain amount of foresight.

> same so that the transition cost is minimal.

I can't speak for everyone, but I can assert that, given what we know 
now, I would have preferred some different paths in the IPv6 
architecture, but again, that would have required what has turned out to 
be 20 years of foresight.  We can't get everything correct, and if we 
wait until we do, we'll never do anything.  IPv6 is what it is, and it 
does work.  It is (way past) time to stop squawking (except at the bar, 
where it is allowed) and do what is necessary to get it deployed.

Christopher

--
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Thu, 11 Dec 2014 15:24:08 -0800

On 11 Dec 2014, at 14:11, Lee Howard wrote:

>>>>> about IPv4
>> strategy.
> The goal isn't IPv6, thoughthe goal is a functioning, interoperable

Hear hear Lee!

	Christopher

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2014 08:32:05 +1300

On 12/12/2014 18:12, heasley wrote:
...
> I don't know anyone enchanted by v6.

Strange choice of word. I'm not in the least enchanted by IPv4
or by NAT44 either. I just know as a matter of fact that the
IPv4nternet ran out of addresses a while back and we have no
alternative but to fix it using IPv6. All the rest is details,
important details of course, but details.

   Brian

---

From: James Woodyatt <[email-masked]>
Date: Fri, 12 Dec 2014 11:46:48 -0800

Everyone—

After thinking about it for some time, I have decided that I support
changing the status of RFC 6346 to Proposed Standard, and I hope deployment
of A+P to become more widespread with IPv4 service.

It's my view that RFC 6346 is mainly a system to facilitate the bulk
collection of Internet communications metadata, and therefore RFC 2804, RFC
6973 and I-D.iab-privsec-confidentiality-threat would seem to me to be
relevant documents in considering what status to assign it.  The security
considerations section in RFC 6346 openly explains how NAT44/A+P is
designed to facilitate bulk metadata collection, which comports nicely with
the call in RFC 2804 to remain neutral about the morality of wiretapping
while viewing the specification of how it is done to be a Good Thing. It
also explains how the privacy considerations related to data minimization
of identity metadata retention are traded away in exchange for reduced
operating costs, which I think comports nicely with RFC 6973. Finally, I
think moving NAT44/A+P to Proposed Standard makes it clear that IETF
understands believes IPv4 users cannot expect the mapping between personal
identity and IP address to be obscured by carrier-grade NAT44 devices.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Dec 2014 08:51:53 +1100

> does not support IPv6, and it's for sale all over the U.S.  It's not a

Since Android 4.0 supported IPv6 you need to ask Samsung why they
disabled the feature.

> time until we can ignore all of the v4-only devices that people use

There is a difference between ignoring them and saying we need to
support them as anything other than a client by residential ISPs..

Manufactures have had over a decade to develop and fix their devices
to support IPv6.

---

From: "John R Levine" <[email-masked]>
Date: 12 Dec 2014 17:11:29 -0500

> Since Android 4.0 supported IPv6 you need to ask Samsung why they

Uh, Mark, I don't need to do anything.  The phone works fine, even if it 
doesn't work the way you apparently think it should.  My guess would be 
that on this low-performance phone, they stripped out the unimportant 
bits.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Dec 2014 15:26:11 -0800

> important details of course, but details.

Dear Brian,

Agreed.  One should not support the standardization of a v6 to v4 transitional scheme which significantly weakens protocol security by restricting available port assignments at various points within a path.  Suggested bit ranges of 7 to 10 bits significantly reduces protections otherwise obtained by random assignment.  As such, it makes this a trivial matter for malefactors to deduce likely source entropies.  Although IPv6 creates different challenges, it provides the only viable long term standard moving forward.  In addition, NAT keep-alives tend to consume critical mobile energy resources.

Regards,
Douglas Otis

---

From: Christian Huitema <[email-masked]>
Date: Sat, 13 Dec 2014 20:09:30 +0000

On Friday, December 12, 2014 3:26 PM, Douglas Otis wrote

> Agreed.  One should not support the standardization of a v6 to v4 transitional scheme which significantly weakens
> protocol security by restricting available port assignments at various points within a path.  Suggested bit ranges of
> 7 to 10 bits significantly reduces protections otherwise obtained by random assignment.  As such, it makes this a 
> trivial matter for malefactors to deduce likely source entropies.  Although IPv6 creates different challenges, it
> provides the only viable long term standard moving forward.  In addition, NAT keep-alives tend to consume critical > mobile energy resources.

It would be interesting to study the effect of this port range assignment on applications. For example, a lot of the NAT traversal solutions rely on reserving ports for applications using UPNP IGD, PCP, or the management UI from the NAT. That's clearly going to break if the target port falls outside the range assigned to the NAT. But the applications have no official way to learn the range. The applications will thus have to implement ever more NAT traversal cleverness. So, this is by no means a harmless hack. It will have implications on a range of end systems. Personally, I don't see any urgency from changing the status away from experimental.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Dec 2014 21:27:00 -0500

On Dec 13, 2014, at 3:09 PM, Christian Huitema <[email-masked]> wrote:
> But the applications have no official way to learn the range. 

Isn't that what PCP is for?   You don't need to know the range: you just need a port (or range of ports) allocated.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Dec 2014 03:36:05 +0000

On December 13, 2014 6:27 PM, Ted Lemon wrote 

> Isn't that what PCP is for?   You don't need to know the range: you just need a port (or range of ports) allocated.

PCP MAP would work, if well implemented. But many home routers do not support PCP yet, and many applications 
work better on their "preferred" port. Of course, all that can be fixed with sufficient effort, but it might be simpler
for the applications to just go to IPv6. Also, 6346 mentions deployment directly to devices like cell phones,
and there is no PCP there.

I understand that a big motivation of A+P is to avoid Carrier Grade NAT, and I sympathize with that. But I can see some
interesting trouble ahead...

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Dec 2014 23:17:58 -0500

> interesting trouble ahead...

Hm, I see your point, and I agree that it will be easier for apps to go to IPv6, at least in principal (availability of IPv6 is still a problem in many situations).   However, even if apps go to IPv6, there is significant utility in using PCP, particularly in situations where the HG may have a firewall with a default block policy for incoming connections.   So I don't really think there's any reason to separate the two things.   Really, apps should support IPv6, and they should support PCP.   And home gateways should support it as well; it's frustrating that at present there is no good PCP implementation for OpenWRT, for example.

The mobile/PCP intersection is interesting--I haven't seen any exploration of that yet.

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sun, 14 Dec 2014 16:41:32 +0000

Sent from my iPad

>> desktop, cell phone that didn't support IPv6?

I don't think my televisions, or  any of the set top boxes,  support IPv6. 

The are a lot of domestic items, with long expected service lives, that are IPv4 only.

Stewart

---

From: heasley <[email-masked]>
Date: Mon, 15 Dec 2014 17:38:55 +0000

> important details of course, but details.

The point is that expanded address space is the only reason folks are
driven to v6.  The other protocol changes are not received as improvements
and IMO have only served to further hinder adoption.  These could have
been omitted and by doing so, i argue that, adoption would be (have been)
swifter.

---

From: heasley <[email-masked]>
Date: Mon, 15 Dec 2014 22:08:15 +0000

> equipment that needs to be replace now it means you failed to plan.

You may be over-estimating the margins on home internet access and under-
estimating the cost to upgrade every household (whether the ISP provides
the modem or [worse] the end-user).  thats just one piece of the puzzle.

> If your consumer device does not support IPv6 don't blame the IETF.

You can not compare a PC where things can be reasonably done in s/w and
that software is easily upgraded to a simple modem at an end-user location
or to head-end h/w that has to do forwarding in ASICs to deliver the b/w
expected.  These may adapt more slowly and often do not at all, requiring
replacement.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Dec 2014 12:06:22 +1300

> been omitted and by doing so, i argue that, adoption would be (have been)

That might be true, but of course we will never know. The opposite
might have been true too ("Why bother upgrading to 64 bit addresses
when we can just use double NAT and there is no other improvement?").

    Brian

   Bria

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Dec 2014 10:24:55 +1100

> the modem or [worse] the end-user).  thats just one piece of the puzzle.

Windows XP shipped with IPv6 support in 2001 and it was not the
first box to ship with IPv6.  It is now the end of 2014.

If a consumer device does not support IPv6 as well as IPv4 it should
be sent back to the manufacture / supplier as "not fit for purpose"
and a full refund should be requested.  It shouldn't cost the
consumer anything other than some time to get their devices fixed.

NAT and CIDR bought manufactures plenty time to add IPv6 support
to their products.  If they failed to use that time wisely they can
pay the price.

Additionally even if the ISP makes the last mile IPv6 only that
does not mean the home has to be IPv6 only.  There are a whole raft
of technologies to deliver IPv4 over IPv6 some of which a ISP could
out source to third party providers.

> expected.  These may adapt more slowly and often do not at all, requiring

ISP's have had 15+ years lead time to upgrade head end gear /
routers.  It is not like they didn't know a problem was coming all
those years ago.

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 15 Dec 2014 16:52:34 -0800

On Dec 13, 2014, at 12:09 PM, Christian Huitema <[email-masked]> wrote:

> It would be interesting to study the effect of this port range assignment on applications. For example, a lot of the NAT traversal solutions rely on reserving ports for applications using UPNP IGD, PCP, or the management UI from the NAT.

I agree UPnP IGD will break.  But PCP should be fine, as it sends a suggested-port in its request and the response can be any port, http://tools.ietf.org/html/rfc6887#page-41.  The UI from the (in-home?) NAT should be okay, as it needs to be A+P aware, and as part of that awareness it would know the assigned port numbers.  If the UI belongs to the carrier's A+P device itself, it also knows the assigned port numbers.

-d

> That's clearly going to break if the target port falls outside the range assigned to the NAT. But the applications have no official way to learn the range. The applications will thus have to implement ever more NAT traversal cleverness. So, this is by no means a harmless hack. It will have implications on a range of end systems. Personally, I don't see any urgency from changing the status away from experimental.
> 
> -- Christian Huitema
> 
> 
> 
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 15 Dec 2014 16:52:36 -0800

> Isn't that what PCP is for?   You don't need to know the range: you just need a port (or range of ports) allocated.

PCP can't provide the entire range of allocatable ports.  Knowing the entire range isn't useful, anyway -- even if port "X" was available a few minutes ago, it might not be available now because some other host (in the same home) is now using that port.

-d

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 16 Dec 2014 13:30:12 +0000

> consumer anything other than some time to get their devices fixed.
Whether that makes sense depends on the rest of the selection
criteria. The IPv6 alternatives might well be insufficient in some
other important characteristic.

Stewart