North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

  • From: Stephen Sprunk
  • Date: Tue Oct 02 11:02:38 2007

Thus spake "Iljitsch van Beijnum" <[email protected]>
On 1-okt-2007, at 19:56, Stephen Sprunk wrote:
There is no "IPv6 world". I've heard reference over and over to how developers shouldn't add "NAT support" into v6 apps, but
the reality is that there are no "v6 apps". There are IPv4 apps
and IP apps that are version agnostic. The NAT code is there
and waiting to be used whether the socket underneath happens
to be v4 or v6 at any given time.

I could talk about APIs and how IPv6 addresses are embedded in protocols, but let me suffice to say that although your applications may work over both IPv4 and IPv6, this doesn't mean that the two protocols are completely interchangeable. NATs and their ALGs as well as applications WILL have to be changed to make protocols that embed IP addresses work through NAT-PT (or IPv6 NAT).

First, there really aren't that many apps today that embed IP addresses or don't follow the traditional client-server model. We don't have more of them because of v4 NAT.

Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens.

The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6.

There are different approaches possible for this. Opening up holes in the firewall is probably better than ALGs.

That's the purpose of an ALG. Requiring users to modify their home router config or put in a change request with their IT department for a firewall exception is a non-starter if you want your app to be accepted. Whether the pinhole is needed because of a NAT or a stateful firewall is irrelevant; what matters is having an ALG create the pinhole _automatically_.

1. for IPv6-only hosts with modest needs: use an HTTPS proxy
to relay TCP connections

2. for hosts that are connected to IPv6-only networks but with
needs that can't be met by 1., obtain real IPv6 connectivity
tunneled on-demand over IPv6

Neither solves the problem of v6-only hosts talking to v4-only hosts.

Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the "IPv6-only" status from the host if not from the network it connects to.)

The former only handles outbound TCP traffic, which works through pure NAT boxes as it is. The latter "solution" ignores the problem space by telling people to not be v4-only anymore.

NAT-PT gives hosts the _appearance_ of being dual-stacked
at very little up-front cost.

Again, you're right. The costs will be ongoing in the form of reduced transparency (both in the technical/architectural sense and in the sense that applications behave unexpectedly) and the continous need to accommodate workarounds in applications.

Agreed. People have shown they're willing to accept those costs in a v4-only network. Extending that to the transition phase adds zero _new_ costs. Providing a way out for people if they deploy v6 is a new _benefit_.

Could you please explain what problems you see with the
proxy/tunnel approach and why you think NAT-PT doesn't have
these problems?

NAT-PT works for more apps/protocols. It definitely has its own problems, though. That's why I view it as a transition technology, not a desirable end state. If it's successful, it will drive itself out of existence.

When v4-only users get sick of going through a NAT-PT
because it breaks a few things, that will be their motivation to
get real IPv6 connectivity and turn the NAT-PT box off -- or
switch it around so they can be a v6-only site internally.

Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I guess I wouldn't.)

Either YouTube won't care, in which case NAT-PT obviously isn't as evil as people claim, or they will care and they'll deploy v6. I don't claim to know which scenario is correct, but I assert that it's one of the two.

No, what's going to happen is that users will demand IPv4
connectivity from their service providers if IPv6-only doesn't
work well enough.

This is one place where the duopoly will work in our favor -- most people (at least in the US) only have two choices, and if neither of them has new IPv4 addresses available due to exhaustion, people simply can't buy non-NATed v4 access. The choices will be native v6, NAT-PT to v4, or multilayered v4 NAT.

If that doesn't work "well enough", the people at the other end will be motivated to deploy native v6 on their end to make their service work better than their competitors' -- and all the evil NAT(-PT) stuff is bypassed.

On 1-okt-2007, at 20:15, Stephen Sprunk wrote:
The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.

Of course ALGs will exist in IPv6: they'll be needed for stateful firewalls, which aren't going away in even the most optimistic ideas of what an IPv6-only network will look like.

That doesn't mean it's a good idea to embrace something that requires them, because every protocol needs an ALG of its own.

No, the vast majority of protocols will use the default TCP or UDP ALGs because they don't embed IP addresses. Those that do will either get an ALG if they're popular or force people to v6 if they're not.

Today, it's perfectly reasonable to assume that everything's reachable over IPv4. At some point in the future, everything will
be reachable over IPv6. Somewhere in between, there could be
a situation where some people are running IPv4-only and others
IPv6-only, so access to a dual stack proxy would be beneficial
for both types of hosts.

s/dual stack proxy/NAT-PT/ and I'll agree with you.

One of the problems with a proxy is that you have to configure hosts to use it, and all traffic flows through it whether it's needed or not. Obviously we could make the clients smarter, but then you're back to the decade problem. It's too late for that.

Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-)

And when we run out of v4 addresses in a few years, what do you propose we do?

Use NAT for the IPv4 connectivity, I'm afraid.

We're _already_ using NAT. ITYM "multilayered NAT" here. And how, exactly, is that a better world than NAT-PT, which anyone can drop overnight by deploying native v6?

It makes little sense to tunnel v4 over v6 until v6 packets become the majority on the backbones

No, the way I see it you would have an IPv6-only local network and then have a translation box at the edge of a corporate network or in an ISP network. So you'd be in the IPv4 world before you hit any major backbones.

Or vice versa. The key is that we eliminate the need to synchronize the activity of all sites, which is obviously impossible at this stage of the Internet's development.

-- and the only way that'll happen is if everyone dual-stacks or is v6-only.

There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices.

*giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years?

The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors.


Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking