Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

[Responses to John and Lee in the same email]

On 29 Dec 2016, at 16:52, John C Klensin wrote:

> > I completely agree with this. But I also see access providers
> > and enterprises that regardless of how they have built their
> > networks today do run out of IPv4 space. And when they have
> > run out they only have a few choices:
> >
> > 1. Add another layer of NAT
> >
> > 2. Buy IPv4 addresses
> >
> > 3. Start running IPv6
> Actually, two more options:
>
> 4.  Run IPv6 (exclusively) in their backbones, converting to IPv4 islands at 
> their boundaries.  The mechanism may be a
> variation on NAT, but the architecture is different.
This implies NAT64 but I do not see that be closer in evolution than other 
alternatives. And hard to deploy in combination with for example DNSSEC. It 
further sets quite high requirements not only on the NAT64 operator on how the 
network is deployed, provisioning systems etc.

So, yes an alternative in theory but not in reality.

> 5. Run <something-else> in their backbones, converting to IPv4 islands at the 
> boundaries.  It isn't very hard to think about candidates for 
> <something-else> given that there is no
> requirement for interoperation with other ISPs and the key
> requirement is support for semi-permanent virtual circuits (or, if one 
> prefers, channels or tunnels).
Actually, I have very hard problems finding what <something-else> is that you 
can deploy, find hardware, software and provisioning software for. Do you have 
any suggestions?

> Of those five cases, only your (3) implies even the possibility of end-to-end 
> IPv6.
I would add that [3], [4] and [5] all three imply running IPv6 to the end user. 
And that is not cooked yet. See below.

> A comparison to the deployment of IPv4 may be helpful.  That deployment 
> incorporated, among other things, the following
> characteristics for which there is no IPv6 equivalent that I can find:
Agree.

That said, the largest problem with IPv6 deployment is that I find so many 
mistakes be done at or close to the edge. The access provider was forgotten.

> That is where our analyses differ a bit ... and differs more the more we see 
> the network in terms of concurrent flows from a
> large number of clients to a small number of servers (or server clusters).  
> If we were designing an optimal network architecture for a CDN, especially a 
> provider-optimized CDN, I suggest it wouldn't look much like IPv6 or evem 
> IPv6.
So you choose [1]?

> We certainly agree about the "must make (3) easier" part.  A different way of 
> stating my concern is that, each few years that pass when we have not widely 
> deployed IPv6 and have figured out way to control the pain, the more we may 
> create the perception that we can manage without IPv6 forever.  Whether that 
> is true or not, the assumption tends to drive decisions whose
> side-effect is driving the perceived pain of IPv6 conversion up.
Yes!

And on top of this, the alternatives to [3] are also used for higher lock-in of 
customers, building silos (specifically when eye balls communicate with fewer 
and fewer clouds), and other things that act against open Internet but in favor 
of market economy driving forces.

On 29 Dec 2016, at 16:28, Lee Howard wrote:

> > > I don't particularly dislike IPv6, I just think we've failed to
> > > pay enough attention to incentives and barriers.  I wish it were
> > > otherwise, really I do.
> Lessons learned, and captured in draft-iab-protocol-transitions-04
Agree and in this case I claim specifically 4.1 is interesting.

> > I completely agree with this. But I also see access providers and
> > enterprises that regardless of how they have built their networks today
> > do run out of IPv4 space. And when they have run out they only have a few
> > choices:
> >
> > 1. Add another layer of NAT
> >
> > 2. Buy IPv4 addresses
> >
> > 3. Start running IPv6
> These are not alternatives, but complementary elements to an overall strategy.
Yes and no. [1] and [2] do not imply deployment of IPv6. [3] (and [4], [5] of 
Johns proposal) imply deployment of IPv6 at edge. Deployment of IPv6 at edge of 
an ISP is hard.

First of all, remember that every access customer, except cellphone networks, 
that run IPv4 already have one layer of NAT. What you talk about here is adding 
a 2nd layer of NAT. In cellphone networks there was at first no NAT, but is now 
in most cases. Growth of end nodes have been on mobile data networks.

> Running IPv6 doesn¹t mean you don¹t need to buy addresses or deploy NAT.
> It may reduce the amount your NAT is used (esepcially useful for those 
> applications that don¹t play well with NAT). It might reduce the number of 
> addresses you need to buy (if your addresses are being used on the outside of 
> your NAT).
> The value of running IPv6 increases over time.
Somewhat, yes, of course you are right. But, the step to add a 2nd layer of NAT 
for an access provider is not easy.

> > No, we are obviously not ready with [3] yet,
> I don¹t understand this statement, since thousands of access providers and 
> enterprises are running IPv6.
Not really...

> As reported by Mr. Vyncke, users in 20 nations use IPv6 10% of the time to 
> get to IPv6-enabled sites; that¹s only a fraction of the number of users who 
> have IPv6 capability. Most people in Belgium use IPv6, and about 1/3 of users 
> in four other countries use IPv6.
I disagree.

I see IPv6 deployment:

a. At some cellphone providers. It is ready to add IPv6 in the cellphone 
network(s) as long as you as a provider do have some control (or understand) 
how the handsets work.

b. Enterprises that did have fixed IPv4 address, i.e. one router port per 
customer.

c. Hosting providers, because they in reality are like [b].

But we do not see deployment of IPv6 in general:

d. In DSL-based networks.

e. In FTTH (and similar) networks where DHCP in various split VLAN based L2 
domains are in use.

[d] just because it was never implemented.

[e] just because IETF never really did agree on how to handle zero-conf. Too 
many alternatives, and definitely not "as easy" as setting DHCP helper address. 
This in turn lead to complications in the CPE management. You can not even 
today "buy a CPE and plug it in".

> I don¹t see how this is a failure, or how IPv6 isn¹t ready.
Zeroconf and IPv6 is a mess.

> I¹ve been predicting 2018 as The Tipping Year for IPv6 for about five years, 
> and I¹m standing by it.
That I agree with, but the zeroconf must be cleaned up. Specifically in 
implementations. As easy for an access provider as allocation of a subnet for a 
VLAN and then add DHCP helper address to the interface.

> > Because of this, I still think we must make [3] easier, because when
> > people really need IPv6 we must be done.
> In what ways is it difficult to ³Start running IPv6²?
> We even have guidance on this in RFC7381 ³Enterprise IPv6 deployment 
> Guidelines.²
I am not talking about Enterprise. That is ready.

You say in 7381:

> Last but not least, one of the most important design choices to make
> while deploying IPv6 on the internal network is whether to use SLAAC
> [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> [RFC3315], or a combination thereof.
To be blunt, as long as there is a choice, we will not see large deployment.

   paf

signature.asc
Description: OpenPGP digital signature