Subject: [v6ops] Eric Rescorla's No Objection on draft-ietf-v6ops-rfc6555bis-05: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 13:45:49 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-v6ops-rfc6555bis-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document should provide a rationale for why you are favoring v6 over v4
addresses when v4 addresses resolve first. Is there some technical reason
(e.g., it works better) or is there just a political reason (we want to push
people to v6). I could live with either, but the document should be clear IMO.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2017 10:11:53 +1300

Eric,

On 21/10/2017 09:45, Eric Rescorla wrote:
> people to v6). 

I don't think that's a political desire. IPv6 in general works better,
because it isn't encumbered by NAT. So we want to push people to v6
for technical reasons.

   Brian    

> I could live with either, but the document should be clear IMO.
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 14:30:29 -0700

On Fri, Oct 20, 2017 at 2:11 PM, Brian E Carpenter <
[email-masked]> wrote:

> because it isn't encumbered by NAT.

Can you please provide a reference to a measurement showing that this is
true?
-Ekr

So we want to push people to v6

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Oct 2017 14:33:02 -0700

> On Oct 20, 2017, at 2:30 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 20, 2017 at 2:11 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> Eric,
> 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/>
> >
> >
> >
> Can you please provide a reference to a measurement showing that this is true?
> -Ekr

For the draft, I'm going to update it to point to the IPv6 RFC (RFC  8200) to point to the various design benefits that an implementation may favor.

While I agree that in our experience, we've seen performance benefits gained by avoiding NATs, etc, I don't believe that we have the correct material to reference from this draft to assert that point.

Thanks,
Tommy 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Oct 2017 14:38:41 -0700

Hi Ekr,

I've just posted an update with the pointer to RFC 8200 to give background on improvements that IPv6 brings.

https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06>
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-06>

Thanks!
Tommy

> On Oct 20, 2017, at 2:33 PM, Tommy Pauly <[email-masked]> wrote:
> 
> 
> 
>> On Oct 20, 2017, at 2:30 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2017 10:56:30 +1300

> While I agree that in our experience, we've seen performance benefits gained by avoiding NATs, etc, I don't believe that we have the correct material to reference from this draft to assert that poi…

Yes, we sadly lack serious scientific measurement about this, and about NAT-induced
transaction failures too. There are data on the prevalence of CGN but not
on its effects on user performance and reliability, as far as I know.

So, Eric, I can't answer your challenge.

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 15:03:43 -0700

I'm fine with Tommy's new text

On Fri, Oct 20, 2017 at 2:56 PM, Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >> Eric,
> >>
> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ <
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/>
> >>>
> >>>
> >>>
> > For the draft, I'm going to update it to point to the IPv6 RFC (RFC
> 8200) to point to the various design benefits that an implementation may
> favor.
> >
> > While I agree that in our experience, we've seen performance benefits
> gained by avoiding NATs, etc, I don't believe that we have the correct
> material to reference from this draft to assert that point.
>
> >>> https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >>>
> >>
> >
> >
>

---

From: Ca By <[email-masked]>
Date: Fri, 20 Oct 2017 23:12:37 +0000

On Fri, Oct 20, 2017 at 2:56 PM Brian E Carpenter <
[email-masked]> wrote:

> >>> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html <
> https://www.ietf.org/iesg/statement/discuss-criteria.html>

Noted Tommy’s update to 8200.

But we also like ipv6 better than Ipv4 because it is cheaper.

>From a mobile network operator perspective, ipv4 NAT paths are dramatically
more expensive (cost creating and maintaining session state in hw on the
CGN, complex large scale stateful software , ALG bugs, buying public IPv4
address to feed the CGN ...., per transaction or per port block in time
logging for LEA, secure storage of said logs, ... ).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 16:16:24 -0700

On Fri, Oct 20, 2017 at 4:12 PM, Ca By <[email-masked]> wrote:

> From a mobile network operator perspective, ipv4 NAT paths are
> dramatically more expensive (cost creating and maintaining session state in
> hw on the CGN, complex large scale stateful software , ALG bugs, buying
> public IPv4 address to feed the CGN ...., per transaction or per port block
> in time logging for LEA, secure storage of said logs, ... ).
>

That's reasonable, I suppose, but (a) not everyone is on mobile and (b) the
endpoint's interests may not align with yours.

-Ekr

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 Oct 2017 12:11:52 +0900

On Oct 21, 2017 06:31, "Eric Rescorla" <[email-masked]> wrote:

How about
https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/
?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 20:21:40 -0700

On Fri, Oct 20, 2017 at 8:11 PM, Lorenzo Colitti <[email-masked]> wrote:

> How about https://www.internetsociety.org/blog/2015/04/facebook-
> news-feeds-load-20-40-faster-over-ipv6/ ?
>

Maybe.

"The speed increases might happen because users of IPv6 don't have to share
an IPv4 address with other subscribers using Network Address Translation, a
technique that makes the network work harder. But Facebook's Saab isn't
ready to break out the confetti just yet.

"We're still trying to clarify the data," Saab said.
This is consistent both with people with IPv6 having faster networks and
with IPv6 being faster than IPv4 on dual-stack devices. Only the latter
would motivate the recommendation in this draft.

-Ekr

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 Oct 2017 12:28:57 +0900

On Oct 21, 2017 08:17, "Eric Rescorla" <[email-masked]> wrote:

Those factors are in no way specific to mobile networks.
IPv4 addresses and NATs cost money for everyone. Stateless translation
doesn't use NAT, but because it's stateless, port space has to be assigned
in advance, so it consumes more IPv4 space than stateful translation.
Public IPv4 to users is already infeasible for new entrants, and will be
infeasible in the sort to medium term incumbents.

I don't see any cheaper alternative than IPv6. Do you?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 Oct 2017 12:35:52 +0900

> would motivate the recommendation in this draft.

IIRC the Facebook experiment measured the latter. See for example
https://www.nanog.org/sites/default/files/meetings/NANOG64/1033/20150602_Huston_The_Benefits_Of_v3.pdf
.

Clearly, it's just one measurement and the results may vary.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 20:36:05 -0700

On Fri, Oct 20, 2017 at 8:28 PM, Lorenzo Colitti <[email-masked]> wrote:

> That's reasonable, I suppose, but (a) not everyone is on mobile and (b)
> the endpoint's interests may not align with yours.
>
>

As I said, the endpoints have different incentives, namely to get the best
performance for their users.

If IPv4 and IPv6 paths are equally fast for the user, then delaying
attempts to connect v4 in cases where v4 resolves first makes the user's
experience slower. That's not to say that there's not some public good
argument for doing that anyway, but if so, that should be explained, not
just smuggled into some protocol constant.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 20:39:34 -0700

On Fri, Oct 20, 2017 at 8:35 PM, Lorenzo Colitti <[email-masked]> wrote:

> https://www.nanog.org/sites/default/files/meetings/
> NANOG64/1033/20150602_Huston_The_Benefits_Of_v3.pdf .
>

It's hard to tell just what they were measuring, but you'll note that the
first slide of the Facebook section says "No A/B Testing" which suggests
the opposite.

-Ekr

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 Oct 2017 13:08:05 +0900

On Sat, Oct 21, 2017 at 12:36 PM, Eric Rescorla <[email-masked]> wrote:

> experience slower.

Sure, but my question was about cost. Perhaps we agree that in the long
term IPv6 is cheaper, even if we don't agree that it's better.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 21:39:13 -0700

On Fri, Oct 20, 2017 at 9:08 PM, Lorenzo Colitti <[email-masked]> wrote:

>> As I said, the endpoints have different incentives, namely to get the
>> best performance for their users.
>>

I wasn't trying to answer your question. My concern is the suitability of
the recommendations this document makes and the rationales that it provides
for them.

-Ekr

---

From: Mark Andrews <[email-masked]>
Date: Sun, 22 Oct 2017 12:08:24 +1100

> the recommendations this document makes and the rationales that it provides

Having IPv4 traffic increases the cost for the ISP and in turn the
customers.

Not preferencing IPv6 makes it much harder to determine when to
turn off IPv4 altogether and to leave IPv4 as a service to third
parties to provide like HE.NET have provided IPv6 as a service for
lots of people over the last decade and a bit.

If you don't preference IP6 you end up with 50% IPv4 and 50% IPv6
and having to support IPv4 as a service for ever.  You also end up
having to maintain both IPv4 and IPv6 servers.

This document is still has too much bias towards IPv4 in it.  It
doesn't leave enough time for a single DNS request to get to the
other side of the world and back when there is a cache miss for the
AAAA lookup and a cache hit for the A lookup before attempting the
IPv4 connection.  It assumes there will be either cache hits for
both or cache misses for both.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Oct 2017 12:42:17 +0900

Right. Hence my question on whether we can agree that IPv6 is cheaper. If
we can agree on that, then we can justify the recommendations that way.

Personally I think it's pretty clear that in the long term and at Internet
scale, IPv6 is cheaper.

On Sat, Oct 21, 2017 at 1:39 PM, Eric Rescorla <[email-masked]> wrote:

>>>> Public IPv4 to users is already infeasible for new entrants, and will
>>>> be infeasible in the sort to medium term incumbents.
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Oct 2017 11:05:46 -0700

> Having IPv4 traffic increases the cost for the ISP and in turn the

I applaud your allegiance to econ 101 marginal cost pricing, but
I'm skeptical that in practice the need to do IPv4 is an important
contributor to the price experienced by customers. Do you have
some data that shows that this is true?

> having to maintain both IPv4 and IPv6 servers.

I think this paragraph well reflects the problem I am noting, in that it
conflates the various entities involves in the transaction. By my count,
in two sentences you have used "you" to refer to at least three entities:

- The end-user's devices which do the preferencing
- The ISPs who offer IPv4 and/or IPv6 service
- The server operators who have to maintain various kinds of servers

Each of these entities have different incentives. As I noted in my initial
e-mail, absent evidence that v6 is directly better for the end-use [0] these
parameters seem chosen because of some belief that we should be
prioritizing IPv6 for some larger reason, even if it temporarily makes
matters slightly worse for users. That's a reasonable position -- though
not one I personally subscribe to -- and I agree that it's a WG decision
how to select the constants, but I think the document needs to explain
the rationale. The original text really isn't sufficient here, and while I
can live with Tommy's text, it doesn't actually seem that consistent
with the arguments being advanced in that threat.

-Ekr

[0] The data Lorenzo presents seems ambiguous at best.

---

From: Mark Smith <[email-masked]>
Date: Tue, 24 Oct 2017 05:31:56 +1100

On 21 Oct. 2017 8:56 am, "Brian E Carpenter" <[email-masked]>
wrote:

[email-masked] <mailto:[email-masked]>> wrote:
>>> Please refer to https://www.ietf.org/iesg/stat
ement/discuss-criteria.html <https://www.ietf.org/iesg/sta
tement/discuss-criteria.html>
true?

Yes, we sadly lack serious scientific measurement about this, and about
NAT-induced
transaction failures too. There are data on the prevalence of CGN but not
on its effects on user performance and reliability, as far as I know.

APNIC have measured that IPv6 is quite commonly faster than IPv4.

https://blog.apnic.net/2016/08/22/ipv6-performance-revisited/

Facebook have found that too.

https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/

Regards,
Mark.

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Oct 2017 11:44:58 -0700

Thanks for the reference.

The question is *not* whether IPv6 is faster than IPv4 for the same
physical route but rather whether it is faster for the same endpoint. To
know that, you need to do A/B testing. It's clear Facebook did not do that.

Skimming the APNIC results, it appears that they show that for the A/B
test, v4 and v6 are similar:

"These measurements show that in a large set of individual comparisons
where the IPv4 and IPv6 paths between the same two dual stack endpoints are
examined, the two protocols, as measured by the TCP SYN round trip time,
are roughly equivalent on average, but with some significant outliers."

You might also take note of:

"While the TCP connection performance is roughly equivalent once the
connection is established, the probability of establishing the connection
is not the same. The current connection failure rate for IPv4 connections
was seen to be some 0.2% of all connection attempts, while the equivalent
connection failure rate for unicast IPv6 is eight times higher, at 1.6% of
all connection attempts.
"

-Ekr

---

From: Ca By <[email-masked]>
Date: Mon, 23 Oct 2017 19:03:21 +0000

On Mon, Oct 23, 2017 at 11:06 AM Eric Rescorla <[email-masked]> wrote:

>> In message <
>> [email-masked]>,
>> Eric Rescorla writes:
> matters slightly worse for users.
>

I think we are in bike shed area, but i am fine with saying that ipv6 is
better and preferred for network operators in terms of cost and scalability
and keep the end users out of it. I think those benefits are obvious (cgn
cost on v4 vs no cgn on v6)

I have deployed ipv6 to 10s of millions of users because it was the best
decision for our business and network, and it is great that customers
largely have no idea we did.  End users dont know or care about v6.

End users are just one stakeholder in this ecosystem and optimizing just
for their metrics is a suboptimzation for the larger internet we are trying
to shepherd here.

That's a reasonable position -- though

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Oct 2017 12:06:37 -0700

> for their metrics is a suboptimzation for the larger internet we are trying

I agree that we need to look at the bigger picture, but that also involves
acknowledging that we are potentially asking the users t do something less
good for them.

-Ekr

>>> <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Oct 2017 08:08:46 +1300

> connection failure rate for unicast IPv6 is eight times higher, at 1.6% of

None of which addresses the question of how many user transactions succeed
or fail with IPv4 or IPv6 respectively, assuming acceptable performance
in both cases. It's really very hard to define and measure metrics that
really answer Eric's challenge.

---

From: David Schinazi <[email-masked]>
Date: Mon, 23 Oct 2017 12:27:58 -0700

Hi all,

I also don't think the review of RFC6555bis is the right place to be having the discussion of whether to prefer IPv6 or not.
The IETF reached consensus on preferring IPv6 with RFC3484 (now RFC6724).
The benefits of IPv6 are documented more thoroughly in RFC8200.

The text in draft-ietf-v6ops-rfc6555bis-06 is as follows:

   Note that this document assumes that the host destination address
   preference policy favors IPv6 over IPv4.  IPv6 has many desirable
   properties designed to be improvements over IPv4 [RFC8200].  If the
   host is configured to have a different preference, the
   recommendations in this document can be easily adapted.

As such, RFC6555bis does not recommend IPv6 or IPv4, which is left to other documents.

Thanks,
David Schinazi

> On Oct 23, 2017, at 12:08, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Oct 2017 13:17:19 -0700

In case I wasn't clear before (totally possible) I have no problem with
this text.

-Ekr

On Mon, Oct 23, 2017 at 12:27 PM, David Schinazi <[email-masked]>
wrote:

> Hi all,
>
> I also don't think the review of RFC6555bis is the right place to be
> having the discussion of whether to prefer IPv6 or not.
> [email-masked] <mailto:[email-masked]
> <[email-masked]>>> wrote:
>
> Eric,
>
> This document should provide a rationale for why you are favoring v6
>
> over v4
>
> addresses when v4 addresses resolve first. Is there some technical
>
> reason
>
> (e.g., it works better) or is there just a political reason (we want
>
> to push
>
> people to v6).
>
>
> Can you please provide a reference to a measurement showing that this
>
> is true?
>
> -Ekr
>
>