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

Randy, Alain,

>
>     o nat-pt with standardized algs for at least dns,
smtp, http, sip, and
>     rtp
>
>
> -->> This is on my top 3 hot topics. And make it
works both way, v4 to
> v6 and v6 to v4.
> And also don’t call it NAT-PT. That name is dead.

For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual
stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.

Jari

>> o nat-pt with standardized algs for at least dns,
smtp, http, sip, 
>> and rtp -->> This is on my top 3 hot topics.
And make it works both
>>  way, v4 to v6 and v6 to v4. And also don’t call it
NAT-PT. That 
>> name is dead.
> For what it is worth, this is one of the things that I
want to do.

i took you at your word the other month, so stopped worrying
about
motivating it.  as far as getting it through the ivtf, well,
that ain't
my job any more.  i gave at the office.  thank you for
accepting the burden.

> I don't want to give you an impression that NAT-PT++
will solve all
> the IPv6 transition issues

heck no.  but it will enable folk to have v6-almost-only
(except for one
ipv4 address) sites in a dual stack and mostly v4 world.  it
will allow
end site transition.

randy

On 28-sep-2007, at 6:25, Jari Arkko wrote:

>> And make it works both way, v4 to v6 and v6 to v4.
>> And also don’t call it NAT-PT. That name is dead.

> For what it is worth, this is one of the things that I
want
> to do. I don't want to give you an impression that
NAT-PT++
> will solve all the IPv6 transition issues; I suspect
dual stack
> is a better answer. But nevertheless, the IETF needs
to
> produce a revised spec for the translation case. Fred
and
> I are organizing an effort to do this.

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. Rather than
"solving" this issue  
by trying harder, I would like to take the IETF to adopt the
 
following approach:

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

The advantage of 1. is that proxies and applications that
can use  
proxies are already in wide use. The advantage of 2. is that
it  
provides real IPv4 connectivity without compromises.
Different hosts  
(even on the same subnet) can have different IPv4
connectivity (NAT/ 
no NAT, firewalled/unfirewalled) without having to provision
the  
complete path between the user and the edge of the network 

specifically for that type of connectivity. And no lost
addresses for  
subnetting etc.

At 04:39 PM 9/28/2007, Iljitsch van Beijnum wrote:



>On 28-sep-2007, at 6:25, Jari Arkko wrote:
>
>>>And make it works both way, v4 to v6 and v6 to
v4.
>>>And also don't call it NAT-PT. That name is
dead.
>
>>For what it is worth, this is one of the things that
I want
>>to do. I don't want to give you an impression that
NAT-PT++
>>will solve all the IPv6 transition issues; I suspect
dual stack
>>is a better answer. But nevertheless, the IETF needs
to
>>produce a revised spec for the translation case.
Fred and
>>I are organizing an effort to do this.
>
>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.

NAT grew out of need. It didn't grow up in the IETF. We did
have a 
NAT WG, to document, define common terminology and
guidelines. We 
took a lot of heat for just documenting what was out there.
The 
marketplace resulted in the success of NAT. Even if there
had been 
limitless address space, it's unlikely NAT would have been
avoided.

>  Rather than "solving" this issue
>by trying harder, I would like to take the IETF to adopt
the
>following approach:
>
>1. for IPv6-only hosts with modest needs: use an HTTPS
proxy to relay
>TCP connections

So your fobia over all things NAT is so deep that you would
insist on 
the use of a SOCKS-like mechanism, breaking end-to-end
connectivity, 
to avoid implementing NAT of any sort. Pardon me for
thinking this is 
a stretch.


>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

Add more devices in the path, resulting in a tortured
"end-2-end" 
that has lots of points of failure, and lots of state in the
network 
for those tunnel endpoints, timeouts on same, etc.

I fail to see how your proposals preserve the end-to-end
nature of 
the Internet in any meaningful way. You've gone a long way
to find 
something, anything, that can take the place of NAT, but in
so doing, 
you've proposed solutions which do not appreciably differ in
effect 
on the function of the Internet. 

> NAT grew out of need. It didn't grow up in the IETF. We
did have a NAT
> WG, to document, define common terminology and
guidelines. We took a lot
> of heat for just documenting what was out there. The
marketplace
> resulted in the success of NAT. Even if there had been
limitless address
> space, it's unlikely NAT would have been avoided.

nat is not a technology, it is the anti-$deity, at least to
some. the
ivtf loves to throw out multiple confusing and competing
technologies
and say "let the market decide." but it somehow
has had very deaf ears
when the market decided nat in a very big way. this is not
to say i
would want a nat to marry my brother!

but, ome months back, some wiser heads in the ivtf listened
and agreed
that nat-pt (no, alain, i will not be silly and let people
force me to
confuse things by calling it something else), is seriously
required even
though it is disgusting to us all.  thank you russ and jari;
and i am
sure others will climb on the bandwagon and wave flags.

the alternatives are more disgusting, and lack of nat-pt is
a serious
impediment to ipv6 deployment, a critical one in a world of
ipv4 address
space scarcity.

for an example of the problems of public proxies, as Jeffrey
Streifling
said (in http://www.civi
l-tongue.net/clusterf/ wiki),
  o Email/SMTP is a mandatory application
  o Everyone needs to be able to send email to arbitrary
recipients,
    i.e. everyone else
  o But, due to SPAM, no one can run an open SMTP relay
  o So all IPv6 sites need to have the ability to SMTP to
arbitrary IPv4
    sites
  o Therefore everyone needs private dual stack relay until
the world is
    all dual stack SMTP

randy

On 29-sep-2007, at 2:11, Daniel Senie 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.

> NAT grew out of need. It didn't grow up in the IETF. We
did have a  
> NAT WG, to document, define common terminology and
guidelines. We  
> took a lot of heat for just documenting what was out
there. The  
> marketplace resulted in the success of NAT. Even if
there had been  
> limitless address space, it's unlikely NAT would have
been avoided.

And how exactly does that relate to the discussion at hand?

For the purpose of this particular discussion, NAT in IPv4
is  
basically a given: coming up with an IPv4-IPv6 transition
mechanism  
that only works with if no IPv4 NAT is present both defeats
the  
purpose (if we had that kind of address space we wouldn't
have a  
problem in the first place) and it's completely
unrealistic.

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.

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

> So your fobia over all things NAT is so deep that you
would insist  
> on the use of a SOCKS-like mechanism, breaking
end-to-end  
> connectivity, to avoid implementing NAT of any sort.
Pardon me for  
> thinking this is a stretch.

I don't see the problem with proxying, except that it only
works for  
TCP. Yes, you need a box in the middle, but that's true of
any  
solution where you have an IPv6-only host talk to an
IPv4-only host.  
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.

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

> Add more devices in the path, resulting in a tortured
"end-2-end"  
> that has lots of points of failure, and lots of state
in the  
> network for those tunnel endpoints, timeouts on same,
etc.

Apparently these downsides aren't big enough to stop the use
of PPPoE.

The advantage is that you can have an IPv6-only routed
network. This  
at the very least avoids having to provision both protocols 

throughout the network, and probably avoids a lot more
complexity  
that is necessary in typical IPv4 networks (NAT hole
punching etc).

> I fail to see how your proposals preserve the
end-to-end nature of  
> the Internet in any meaningful way. You've gone a long
way to find  
> something, anything, that can take the place of NAT,
but in so  
> doing, you've proposed solutions which do not
appreciably differ in  
> effect on the function of the Internet.

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

This can indeed be used to avoid NAT if you use public IPv4 

addresses, but it's also the solution that incurs the least
amount of  
NAT issues if you don't, because those issues stay in IPv4
where  
they're well known.

PS. someone told me that work on tunneling IPv4 over IPv6 is
under  
way in the IETF under the name "softwires".

Thus spake "Iljitsch van Beijnum" <iljitschmuada.com>
> On 28-sep-2007, at 6:25, Jari Arkko wrote:
>>> And make it works both way, v4 to v6 and v6 to
v4.
>>> And also don’t call it NAT-PT. That name is
dead.
>
>> For what it is worth, this is one of the things
that I want
>> to do. I don't want to give you an impression that
NAT-PT++
>> will solve all the IPv6 transition issues; I
suspect dual stack
>> is a better answer. But nevertheless, the IETF
needs to
>> produce a revised spec for the translation case.
Fred and
>> I are organizing an effort to do this.
>
> 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.

Yes, ideally the NAT code wouldn't get used if the socket
were v6.  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.

> Rather than "solving" this issue by trying
harder, I would like to
> take the IETF to adopt the following approach:
>
> 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.

The fundamental flaw in the transition plan is that it
assumes every host 
will dual-stack before the first v6-only node appears.  At
this point, I 
think we can all agree it's obvious that isn't going to
happen.

NAT-PT gives hosts the _appearance_ of being dual-stacked at
very little 
up-front cost.  It allows v6-only hosts to appear even if
there still remain 
hosts that are v4-only, as long as one end or the other has
a NAT-PT box. 
The chicken and egg problem is _solved_.  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.

The alternative is that everyone just deploys multi-layered
v4 NAT boxes and 
v6 dies with a whimper.  Tell me, which is the lesser of the
two evils?

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 

Thus spake "Iljitsch van Beijnum" <iljitschmuada.com>
> For the purpose of this particular discussion, NAT in
IPv4 is  basically a 
> given: coming up with an IPv4-IPv6 transition
> mechanism that only works with if no IPv4 NAT is
present both
> defeats the purpose (if we had that kind of address
space we
> wouldn't have a problem in the first place) and it's
completely
> unrealistic.
>
> 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.

> I don't see the problem with proxying, except that it
only works for  TCP. 
> Yes, you need a box in the middle, but that's true of
any  solution where 
> you have an IPv6-only host talk to an IPv4-only
> host.  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.  Better, if both sides
support the same 
version (either v4 or v6), that would be used without any
proxying or 
translating at all.

> 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?  It makes little sense to tunnel v4 over v6 until v6
packets become the 
majority on the backbones -- and the only way that'll happen
is if everyone 
dual-stacks or is v6-only.  If everyone has v6 connectivity,
then why do we 
need to route v4 anymore, even over tunnels?

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 

At 12:56 PM -0500 10/1/07, Stephen Sprunk wrote:
>...
>The fundamental flaw in the transition plan is that it
assumes every host will dual-stack before the first v6-only
node appears.  At this point, I think we can all agree it's
obvious that isn't going to happen.
>
>NAT-PT gives hosts the _appearance_ of being
dual-stacked at very little up-front cost.  It allows
v6-only hosts to appear even if there still remain hosts
that are v4-only, as long as one end or the other has a
NAT-PT box. The chicken and egg problem is _solved_.  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.
>
>The alternative is that everyone just deploys
multi-layered v4 NAT boxes and v6 dies with a whimper.  Tell
me, which is the lesser of the two evils?

Stephen -

  Very well 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?

  Oh wait, wrong mailing list... 

/John