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

[Eric Rescorla <[e-mail]>]

On Sat, Oct 21, 2017 at 6:08 PM, Mark Andrews <[e-mail]> wrote:

>
> In message <[e-mail]
> ail.com>, Eric Rescorla writes:
> > On Fri, Oct 20, 2017 at 9:08 PM, Lorenzo Colitti <[e-mail]>
> wrote:
> >
> > > On Sat, Oct 21, 2017 at 12:36 PM, Eric Rescorla <[e-mail]> wrote:
> > >
> > >> That's reasonable, I suppose, but (a) not everyone is on mobile and
> (b)
> > >>> the endpoint's interests may not align with yours.
> > >>>
> > >>>
> > >>> 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?
> > >>>
> > >>
> > >> 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.
> > >>
> > >
> > > 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.
> > >
> >
> > 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
>
> Having IPv4 traffic increases the cost for the ISP and in turn the
> customers.
>

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?


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.


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.



> 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: [phone]                 INTERNET: [e-mail]
>