Re: [v6ops] IPREF as a transitioning tool

["[e-mail]" <[e-mail]>]

> (a) IPREF is 100% customer premise technology. As such, its use is totally dependent on the customers choice. There is nothing IETF can do to stop them. It is similar to NAT in this respect. NAT was widely despised, still is, by IPv6 enthusiast but it took over the world in spite of attempts to  block it.

NAT took over the world because we dithered around too long before providing working IPv6 and that was a tragic missed opportunity.

Sadly, we took so long that we now have a generation and a half of network engineers who don’t understand how peer to peer networking is supposed to work and regard address transparency as a security risk. Indeed, I’m constantly having to teach actual network and systems administrators that it is possible to do stateful inspection without mutilating the packet header and that it provides all the same security benefits as stateful inspection combined with header mutilation, with the added benefits of rational audit trails, easier troubleshooting, and transparent addressing.

I haven’t had a chance to look at IPREF in detail (and I guarantee if you keep that name, it’s going to crate wonderful confusion with iperf the beloved performance measurement tool), so I don’t know whether it’s a good or bad thing.

> (b) Related to (a), enterprises love the ability to control the process themselves, without anybody dictating what they should or should not do with their networks. In addition, the economic profile hugely favors IPREF. It is simply cheaper not to do dual stacks, not to do two step transition, not to have to upgrade what they don't want to upgrade, not to have to coordinate with peers. Less cost, less risk.

Enterprises claim to love that, but they also love cloud (at the moment) which is completely antithetical to that claim. Anything that gets us to IPv6-only sooner and/or cheaper does seem appealing. If IPREF does that, I’ll end up being a supporter.

> (c) Related to (b) the economic profile of IPREF is hugely attractive to  ISPs as well. Why doing IPv4-as-a-service if it is not necessary, why burden pure IPv6 Internet with IPv4 services if they're not needed? How can IPv6 compete with IPv4 if it is required to provide extra functionality but which can be avoided? Less cost, less risk.

At some point, there are going to be IPv6-only services because there simply aren’t enough IPv4 addresses for services to continue to grow indefinitely. The only requirement for ISPs to continue to provide IPv4 as a service stems from content/services that are not available on IPv6.

Fortunately, Amazon (one of the biggest holdouts) is doing better about this finally. (They’re still not quite there yet as order-status doesn’t work v6-only, but I was able to place an order on Amazon without IPv4 a while back).

Some of the larger Chinese service providers (Tencent, 163, Alibaba) are among the worst remaining laggards in this arena.

It’s slowly getting better, but for now, I don’t see how you get around IPv4AAS at some level because the customer needs some way to connect to IPv4-only content and services.

> I am just an individual, an inventor, I can do only so much. There are different roles played by different entities. IPREF must be picked up by others. By vendors to build commercial gateways, by architects and operators to complete its specification. This project is in a very vulnerable stage. It can be easily dismissed. Because of (a), (b), and (c) above, it would be foolish to do so. You must allow that the project might be picked up at some point, the gateways will be built, and in the end the economy of the method will prevail. IPv6 cause is better served embracing it than fighting it.

Ironically, this entire message doesn’t reference any ID or RFC regarding IPERF.

Owen