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.
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