Re: WG Action: Conclusion of IP Version 6 (ipv6)

On Mon, 01 Oct 2007 14:39:16 EDT, John Curran said:

>   Now the more interesting question is:  Given that
we're going
>   to see NAT-PT in a lot of service provider
architectures to make
>   deploying IPv6 viable, should it be considered a
general enough
>   transition mechanism to be Proposed Standard or just
be a very
>   widely deployed Historic protocol?

"Historic" usually refers to "stuff we've
managed to mostly stamp out production
use".

So it boils down to "Do you think that once that camel
has gotten its nose
into the tent, he'll ever actually leave?".

(Consider that if (for example) enough ISPs deploy that sort
of migration
tool, then Amazon has no incentive to move to IPv6, and then
the ISP is stuck
keeping it around because they don't dare turn off
Amazon).

At 3:11 PM -0400 10/1/07, Valdis.Kletnieksvt.edu
wrote:
>So it boils down to "Do you think that once that
camel has gotten its nose
>into the tent, he'll ever actually leave?".
>
>(Consider that if (for example) enough ISPs deploy that
sort of migration
>tool, then Amazon has no incentive to move to IPv6, and
then the ISP is stuck
>keeping it around because they don't dare turn off
Amazon).

If indeed one believes that's there more functionality for
having
end-to-end IPv6, then presumably their competitors will roll
out
services which make use of these capabilities, and Amazon
will
feel some pressure to follow. 

Operating through NAT-PT is not very exciting and it's not
going
to take much (e.g. quality video support) to cause major
content
providers to want to have native end-to-end communication. 
Amazingly, it creates an actual motivation for existing IPv4
content
sites to considering adding IPv6 support, which is something
we've
lacked to date.

/John

>   Now the more interesting question is:  Given that
we're going
>   to see NAT-PT in a lot of service provider
architectures to make
>   deploying IPv6 viable, should it be considered a
general enough
>   transition mechanism to be Proposed Standard or just
be a very
>   widely deployed Historic protocol?

to remind you of my original message pushing nat-pt.  the
nat
functionality itself needs standardization, as well as algs
for dns,
smtp, http, sip, and rtp.

these will be sufficiently widely deployed, that we need
the
interchangability and testability that standardization gives
us.

what i did not say at that time, but think would be quite
useful, is
that it would be nice to have a standardized api for new
algs.

randy

Thus spake <Valdis.Kletnieksvt.edu>
> "Historic" usually refers to "stuff
we've managed to mostly stamp
> out production use".
>
> So it boils down to "Do you think that once that
camel has gotten
> its nose into the tent, he'll ever actually
leave?".

This particular camel will be here until we manage to get v4
turned off, 
regardless of what status the IETF dogmatists assign it. 
Once that happens, 
though, there will be no need for NAT-PT anymore  

> (Consider that if (for example) enough ISPs deploy that
sort of
> migration tool, then Amazon has no incentive to move to
IPv6, and
> then the ISP is stuck keeping it around because they
don't dare
> turn off Amazon).

That depends.  If Amazon sees absolutely no ill effects from
v6 users 
reaching it via v4, then they obviously have little
technical incentive to 
migrate.  OTOH, if that is true, then all the whining about
how "evil" 
NAT-PT is is obviously bunk.  We can't have it both ways,
folks: either 
NAT-PT breaks things and people would move to native v6 to
get away from it, 
or NAT-PT doesn't break things and there's no reason not to
use it.

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 

On Mon, Oct 01, 2007 at 09:18:43PM -0500, Stephen Sprunk
wrote:

 > That depends.  If Amazon sees absolutely no ill
effects from v6 users 
 > reaching it via v4, then they obviously have little
technical incentive to 
 > migrate.  OTOH, if that is true, then all the whining
about how "evil" 
 > NAT-PT is is obviously bunk.  We can't have it both
ways, folks: either 
 > NAT-PT breaks things and people would move to native
v6 to get away from 
 > it, or NAT-PT doesn't break things and there's no
reason not to use it.

The IPv4 Internet has been awash with dodgy NATs that
negatively 
affect functionality ever since NAT arrived on the scene.

What has happened?  Well, application protocols have evolved
to 
accommodate NAT weirdness (e.g., SIP NAT discovery), and
NATs have
undergone incremental improvements, and almost no end-users
care about
NATs.  As long as they can use the Google, BitTorrent and
Skype, most
moms and dads neither know nor care about any technical
impediments
NATs erect between them and their enjoyment of the
Internet.

There's no rational reason to believe that NAT-PT would be
any
different.  If NAT-PT breaks stuff, it'll get improved. 
It'll
keep getting better until we don't need it anymore (or
forever,
whichever comes first)

   - mark

-- 
Mark Newton                               Email:  newtoninternode.com.au (W)
Network Engineer                          Email:  newtonatdot.dotat.org  (H)
Internode Systems Pty Ltd                 Desk:  
+61-8-82282999
"Network Man" - Anagram of "Mark Newton"
 Mobile: +61-416-202-223

On 1-okt-2007, at 19:56, Stephen Sprunk wrote:

>> The problem with NAT-PT (translating between IPv6
and IPv4
>> similar to IPv4 NAT) was that it basically
introduces all the NAT
>> ugliness that we know in IPv4 into the IPv6 world.

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

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

>> 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 fundamental flaw in the transition plan is that it
assumes  
> every host will dual-stack before the first v6-only
node appears.

You're right, that doesn't work.

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

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

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

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.

>> If both sides use a dual stack proxy, it's even
possible to
>> use address-based referrals. E.g., the IPv4 host
asks the proxy
>> to set up a session towards 2001:db8:31::1 and
voila, the IPv4
>> host can talk to the IPv6 internet. Not possible
with a NAT-PT
>> like solution.

> Only one side needs to proxy/translate; if both sides
have a device  
> to do it, one of them will not be used.

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.

> Better, if both sides support the same version (either
v4 or v6),  
> that would be used without any proxying or translating
at all.

True. It would be nice if applications or OSes could use
direct  
communication if a destination is reachable that way and
only use the  
proxy when there is an IP version mismatch.

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

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

> -- 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. For the same reason,
running  
IPv6-only is pretty close to being feasible. (It already is
if you  
don't mind conf t and can skip the fancy management stuff.)
On hosts  
you have the trouble that all applications must run over
IPv6 before  
you can yank the IPv4 address and while everything still has
IPv4  
anyway, there is little value in adding IPv6.

> What has happened?  Well, application protocols have
evolved to 
> accommodate NAT weirdness (e.g., SIP NAT discovery),
and NATs have
> undergone incremental improvements, and almost no
end-users care about
> NATs.  As long as they can use the Google, BitTorrent
and Skype, most
> moms and dads neither know nor care about any technical
impediments
> NATs erect between them and their enjoyment of the
Internet.

Except every service that used to work using direct TCP
connections has
either moved to UDP, or moved towards having unNATted boxes
that people
can relay through.

While NAT traversal for TCP is theoretically possible, it
relies on
rarely used features of TCP (Simultaneous open) and good
timing, both of
which are likely to cause issues.  I've never heard of a
successful real
world application successfully doing this. (Feel free to
educate me if
you know of a realworld application in common use that does
do TCP NAT
traversal and has it work a significant amount of the
time).

Even p2p apps like bittorrent rely on the fact that there
are /some/
people /somewhere/ in the swarm that have either configured
their NAT to
allow pinholing or don't have any NAT between them and the
Internet.
Plastered everywhere over anything P2P filetransfer related
is "poor
performance?  Add a pinhole to your NAT box!"
suggesting quite strongly
that NAT is causing large problems for P2P swarms.

NAT is hurting applications today, and applications aren't
getting
deployed (or even written) because of problems NAT causes.

At 10:43 AM +0200 10/2/07, Iljitsch van Beijnum wrote:

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

For you? now?  Not likely.  About the time that a very large
number
of new Internet sites are being connected via IP6 because
there is
little choice, that's a different story. 

Providers would be likely be telling customers to send their
complaints
to YouTube, and that everyone's in the same situation until
Youtube
gets a real connection.

The proxy&tunnel vs NAT-PT differences of opinion are
entirely based
on deployment model... proxy has the same drawbacks as
NAT-PT,
only without the attention to ALG's that NAT-PT will
receive, and
tunnelling is still going to require NAT in the deployment
mode once
IPv4 addresses are readily available.  For now, HTTPS proxy
or a IPv4
tunnel over IPv6 works fine, but most folks don't really
care about
IPv6 deployment right now.  They're looking for a model
which works
3 years from now, when the need to deploy IPv6 is clear and
present.
At that point, there's high value in having a standard
NAT-PT / ALGs
approach for providing limited IPv4 backwards
compatibility.

/John

At 5:36 AM -0400 10/2/07, John Curran wrote:
>...
>tunnelling is still going to require NAT in the
deployment mode once
>IPv4 addresses are readily available.

c/are/are no longer/

(before my morning caffeine fix)
/John

On 2-okt-2007, at 11:36, John Curran wrote:

> The proxy&tunnel vs NAT-PT differences of opinion
are entirely based
> on deployment model... proxy has the same drawbacks as
NAT-PT,

The main issue with a proxy is that it's TCP-only. The main
issue  
with NAT-PT is that the applications don't know what going
on. Rather  
different drawbacks, I'd say.

> only without the attention to ALG's that NAT-PT will
receive,

ALGs are not the solution. They turn the internet into a
telco-like  
network where you only get to deploy new applications when
the powers  
that be permit you to.

> and tunnelling is still going to require NAT in the
deployment mode  
> once
> IPv4 addresses are readily available.

Yes, but it's the IPv4 NAT we all know and love (to hate).
So this  
means all the ALGs you can think of already exist and we get
to leave  
that problem behind when we turn off IPv4. Also, not
unimportant: it  
allows IPv4-only applications to work trivially. Another
advantage is  
that hosts with different needs can get different classes of
tunneled  
IPv4 connectivity even though they happen to live on the
same subnet,  
something that's hard to do with native IPv4.