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

Tue Oct 2 13:56:39 UTC 2007

Thus spake "Iljitsch van Beijnum" <iljitsch at muada.com>
> 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.

S

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 