On Mon, Oct 2, 2017 at 3:26 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 02/10/2017 21:42, Randy Bush wrote:
...
> yes, it has been compelling cgns and nat44444 all the hell over the
> place. major win!
In a way I regret not having completely blocked deployment of the http
nonsense back in 1993, when I ran the team that ran the network that
Tim Berners-Lee first polluted with this web stuff. But since I
didn't do that, just as Tim's managers didn't stop him wasting time
on it instead of doing his day job, the massive growth of the IPv4
network (before IPv6 was ready) became inevitable, so NAT44 and
NAT444 became inevitable, so CGNs and NAT64 became inevitable, so
here we are.
Since I spent much of the morning looking at material posted by Internet Research Agency bots peddling false stories in the hope of exploiting the Vegas shooting, I am rather short on tolerating sarcasm right now.
But for the Web, OSI might well have won. When the killer apps of the Internet were email and file transfer, interconnection between networks could be achieved as well through gateways as by establishing a consistent namespace. The Web ended the network wars because URLs didn't work across network namespaces. So even though you could run HTTP over DECNET phase IV, there was no point in doing that as all the content was on the Internet.
As for carrier grade NAT being inevitable, it took a very long time for IETF to accept that fact. People who suggested that the IETF had to work out how to live with NAT and make it part of the solution were bullied and isolated. And you were chair while much of the unpleasantness was going on.
The only way to effect any technology change is to make it as seamless and transparent as possible. That used to be understood, that is why flag days were considered to be a bad thing.
The strategy adopted instead was to reserve new features for the new protocol. With the result that new features were also delayed or botched. It is a long time since I used an IPSEC VPN because they still didn't work reliably through NAT last time I bothered to try while SSH works pretty much flawlessly.
If you want IPv6 to work, how about considering doing it my way, just the once? Not doing it mind, just considering the alternative approach without driving out the heretics.
It really is quite simple in my view. If you want IPv6 to become unbiquitous, you need to provide people with a new internet API that isolates the application from ALL of the IPv4/IPv6/NAT issues. And thanks to Stuart Cheshire and co, 90% of the work is already done.
At the moment, the network API is in effect:
Address = nslookup_its_an_ipv4_address_right ("example.com")
Socket = get_socket_ipv4 (Address, 80)
(for the other Internet protocol, replace port 80 with 443).
The problem here is that the application programmer is asked to implement whatever the IPv6 transition strategy is this week. And frankly, why would any of my engineers bother when IPv4 is guaranteed to work and they have plenty of other features that are higher in priority.
If you want transition to work, then you need to give the application programmer a black box that they can plug into their code and just works without them having to think about it. i.e.
Client = GetOutbound ("example.com", "_http._tcp")
Service= GetInbound ("example.com", "_http._tcp")
or for legacy
Client = GetOutbound ("example.com", 80)
Service= GetInbound ("example.com", 80)
A call to any of those should do all the work for the programmer including:
* Configure NAT (if required) - see TURN/STUN rfc5766
* Resolve the DNS name
* Decide on the session protocol TCP or QUIC
* Decide whether to use a transport layer security (e.g. TLS)
* Validate any cert chain presented
As I said earlier, we already have a spec that almost completely constrains the space, its RFC6763. I would like to see the space constrained further and establish standard tags for service properties so that a service can offer QUIC or mandate use of TLS in a consistent way.
We have all the parts, what has held us back is a series of niche interest groups who are so obsessed with achieving their own technology transition that they are oblivious to the fact that they are sabotaging the mission of the IETF as a whole:
* The IPv6 purists who insisted on sabotaging protocols to prevent use of NAT
* The DNS purists who insist that the answer to every DNS issue is a new DNS resource record.
IP and DNS are just plumbing. They matter but nobody ever bought a house because they were impressed by how beautiful the pipework was. The only time it enters into the picture is when it isn't working.