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

At 1:50 PM +0200 10/2/07, Iljitsch van Beijnum wrote:
>
>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.

At the point in time that NAT-PR is used for backward
compatibility (because we're connecting new sites via
IPv6) people should be encouraged to rollout their new
apps over IPv6, right?  What's the problem?

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

That's a wonderful solution, and you should feel free to use
it.
It's particularly fun from a support perspective, because
you
get to be involved all the way down the host level.

A lot of ISP's don't want to be involved in supporting
*anything*
all the way down to the local host level, and want a simple
method
for connecting new customers via IPv6 while offering some
form of
legacy connectivity to rest of of the (IPv4) Internet. 
You're asserting
that they shouldn't be allowed to use NAT-PT for this
purpose, despite
the fact that it meets their needs?

/John

On 2-okt-2007, at 14:08, John Curran wrote:

> That's a wonderful solution, and you should feel free
to use it.
> It's particularly fun from a support perspective,
because you
> get to be involved all the way down the host level.

Tunneling IPv4 over IPv6 and translating IPv4 into IPv6
pretty much  
do the same thing except that translating means information
gets  
lost. I don't see how there is a "host level"
difference between the  
two.

> A lot of ISP's don't want to be involved in supporting
*anything*
> all the way down to the local host level, and want a
simple method
> for connecting new customers via IPv6 while offering
some form of
> legacy connectivity to rest of of the (IPv4) Internet.

Well, then obviously they're not going to tunnel real
addresses, so  
address use is not an issue. This means they can easily give
out an  
address to all hosts connected to their network that wants
one. This  
only costs the amount of state required per address, which
should be  
negligible compared to the amount of state (per session)
that's  
required when users start actually using such a service.

> You're asserting
> that they shouldn't be allowed to use NAT-PT for this
purpose, despite
> the fact that it meets their needs?

"The IETF" is asserting that NAT-PT is not fit for
deployment.

What I'm saying is that there are better ways to accomplish
the same  
goals.

Not sure what I would do if I had the power to make people
stop using  
protocols that I feel they shouldn't use.

On Tue, Oct 02, 2007, Iljitsch van Beijnum wrote:

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

Please explain how you plan on getting rid of those
protocol-aware plugins
when IPv6 is widely deployed in environments with -stateful
firewalls-.

Please don't say I'm the only one who thinks this will be a
problem.

End-to-end-ness is and has been "busted" in the
corporate world AFAICT
for a number of years. IPv6 "people" seem to think
that simply providing
globally unique addressing to all endpoints will remove NAT
and all
associated trouble. Guess what - it probably won't. Plenty
of places run
a locked down firewall with a tight security policy that
requires PERMITs
in the firewall policy before access out is needed. These
are going
to need similar ALGs to NAT, even if they're not
"fiddling" with
end-points addresses.

Could someone explain how I'm wrong so I can worry about
other things?




Adrian

On 2-okt-2007, at 15:05, Adrian Chadd wrote:

> Please explain how you plan on getting rid of those
protocol-aware  
> plugins
> when IPv6 is widely deployed in environments with
-stateful  
> firewalls-.

You just open up a hole in the firewall where appropriate.

You can have an ALG, the application or the OS do this. As
you  
probably know by now, I don't favor the ALG approach.

> End-to-end-ness is and has been "busted" in
the corporate world AFAICT
> for a number of years. IPv6 "people" seem to
think that simply  
> providing
> globally unique addressing to all endpoints will remove
NAT and all
> associated trouble. Guess what - it probably won't.

If you don't want end-to-end, be a man (or woman) and use a
proxy.  
Don't tell the applications they they are connected to the
rest of  
the world and then pull the rug from under them. This works
in IPv4  
today but don't expect this to carry over to IPv6. At least
not  
without a long, bloody fight.

Thus spake "Iljitsch van Beijnum" <iljitschmuada.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 

Thus spake "Iljitsch van Beijnum" <iljitschmuada.com>
> On 2-okt-2007, at 15:05, Adrian Chadd wrote:
>> Please explain how you plan on getting rid of those
protocol-
>> aware plugins when IPv6 is widely deployed in
environments
>> with -stateful firewalls-.
>
> You just open up a hole in the firewall where
appropriate.
>
> You can have an ALG, the application or the OS do this.
As you  probably 
> know by now, I don't favor the ALG approach.

You obviously have no experience working in security.  You
can't trust the 
OS (Microsoft?  hah!), you can't trust the application
(malware), and you 
sure as heck can't trust the user (industrial espionage
and/or social 
engineering).  The only way that address-embedding protocols
can work 
through a firewall, whether it's doing NAT or not, is to use
an ALG.

The defense and healthcare industries will force vendors to
write those ALGs 
(actually, make minor changes to existing ones) if they care
about the 
protocols in question because they have no choice --
security is the law. 
And, once those ALGs are available, everyone else will use
them.

Even for home users, most have zero clue how to "open a
hole" in their home 
firewall.  Consumer OSes are far, far too insecure to let
them sit exposed 
without a firewall by default (you can't even patch a
Windows system before 
it's hacked), and we can't trust end users not to run
malware that will open 
holes for them.

>> End-to-end-ness is and has be-en "busted"
in the corporate
>> world AFAICT for a number of years. IPv6
"people" seem to
>> think that simply providing globally unique
addressing to all
>> endpoints will remove NAT and all associated
trouble. Guess
>> what - it probably won't.
>
> If you don't want end-to-end, be a man (or woman) and
use a
> proxy.   Don't tell the applications they they are
connected to the
> rest of the world and then pull the rug from under
them. This
> works in IPv4 today but don't expect this to carry over
to IPv6.
> At least not without a long, bloody fight.

If you think anyone will be deploying v6 without a stateful
firewall, you're 
delusional.  That battle is long over.  The best we can hope
for is that 
those personal firewalls won't do NAT as well.

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 Tue, Oct 02, 2007 at 10:35:11PM +1300, Perry Lorier
wrote:

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

You're talking about inbound (from the Internet to the
client) traversal,
right?  Because outbound is trivial 

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

By focussing on the mechanics of inbound NAT traversal,
you're
ignoring the fact that applications work regardless.  Web,
VoIP,
P2P utilities, games, IM, Google Earth, you name it, it
works.

On the ADSL network my employer operates, the number of
customers who
use NAT (because it's enabled by default on their CPE and
they don't
know or care enough to turn it off) is somewhere north of
95%.  The
Internet works.  Nobody cares about NAT.

Yes, it means that some classes of protocol (which rely on
full
P2P visibility) don't happen;  But they aren't going to
happen
_anyway_, because NAT or no NAT firewalls remain a reality,
and
inbound firewall traversal is every bit as problematic as
inbound
NAT traversal.

Like it or not, we don't really have a peer-to-peer Internet
anymore.
Not like we used to in the good ol' days when everyone had a
globally
routed IP address and nobody used firewalls.

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

Meanwhile, IPv6 advocates who don't like NAT are hurting
IPv6 deployment
today by waving their arms in the air and bitching about
NAT.  That
makes life difficult, because their advocacy is removing
tools 
(such as NAT-PT) which we could use to facilitate and hasten
an
IPv6 rollout.

Throughout IPv6's history, and IPng's history before that,
lots
of disparate problem domains have been bundled together as
things
that the new protocol _must_ solve.  

IPv6 solves the 32-bit-address-space-is-too-small problem.
That's all it does. 

So we've been able to run IPv6 for years, except IPv6 is
also supposed
to solve the bgp-table-is-too-big problem by (until
recently) banning
PI address space by non-ISPs and focussing attention on
vaporware like
SHIM6, so non-ISPs have yawned instead of deploying it;

and IPv6 is also supposed to solve the security problem, so
years
were wasted defining mandatory IPSEC which isn't really
mandatory;

and IPv6 is also supposed to solve the mobility problem, so
more
years were wasted working out option headers and all measure
of 
other crap needed to support mobile-IPv6;

Now IPv6 is supposed to solve the
we-want-a-p2p-internet-all-over-again
problem by making NAT go away, and anti-NAT purists have
spent 
their energy having NAT proposals for v6 written out of the
standards,
and oppose various deployment scenarios by saying, "You
can't possibly
do that beacuse you'll (re)break end-to-end, and that isn't
allowed
in an IPv6 universe!"

While all this dicking around has been happening, the
vendors have
been cooling their heels waiting for sufficient amounts of
consensus
to make it worth their while to release the mass-market CPE
with v6 
support that we'll need to drive mass-market adoption of the
new 
protocol.  Protocol purists hold the whole process to ransom
with
their aesthetic sensibilities, and every year of delay is
another
year that'll pass before grandma can go down to Frys and buy
a DLink 
ADSL modem with IPv6 support.  And until grandma has a
native IPv6
IP address, all the table-thumping in the world about
end-to-end
reachability ain't worth beans.

In a _rational_ world, we would have said, "We have a
pressing
problem, that of v4 exhaustion, so lets build a protocol
that 
solves that, and maybe after we've passed that speed-bump we
can
fit mobility, security, end-to-end visibility, routing
table
controls, etc into the new framework."

So, a reality check:

IPv6 will happen.  Eventually.  And it'll have deficiencies
which
some believe are "severe", just like the IPv4
Internet.  Such as
NAT.  Deal with it.

Throughout its history, the Internet has advanced by
applying
less-than-optimal solutions to the most pressing problems of
the
time, then going back and fixing it later when the heat has
died
down if the suboptimal solutions create their own new
problems.  If
you believe that v4 exhaustion is a pressing problem, then
I'd
humbly suggest that 2007 is a good time to shut the hell up
about
how bad NAT is and get on with fixing the most pressing
problem. 
If we're successful, there'll be plenty of time to go back
and
re-evaluate NAT afterwards when IPv6 exhaustion is a distant
memory.

  - 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 Tue, Oct 02, 2007 at 01:50:57PM +0200, Iljitsch van
Beijnum wrote:

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

No, they turn the Intenret into a network where you only get
to 
deploy new IPv4 applications when the powers that be permit
you to.

So everyone will deploy IPv6 applications, which require no
ALGs,
instead.

Isn't that a solution that everyone can be happy with?

  - 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

At 09:13 AM 10/2/2007, Iljitsch van Beijnum wrote:


>On 2-okt-2007, at 15:05, Adrian Chadd wrote:
>
>>Please explain how you plan on getting rid of those
protocol-aware
>>plugins
>>when IPv6 is widely deployed in environments with
-stateful
>>firewalls-.
>
>You just open up a hole in the firewall where
appropriate.

It might help if you understood why deep packet inspection
firewalls 
exist. If it were as easy as opening holes and trusting
hosts, Cisco 
would not have a market for its PIX/ASA products, SonicWALL
wouldn't 
exist, Juniper wouldn't have bought NetScreen, and so forth.
The 
reality is end hosts are not sufficiently secure. Network
security is 
built in layers. Sure, you use whatever you can in the
hosts, but you 
don't trust it.

Microsoft has had some spectacular holes that impacted even

uninfected hosts (by DDoS) such as CodeRed. And this isn't a
knock on 
Microsoft. There've been security issues with most systems
at one 
point or another. Trusting end systems is insufficient.

Site security policies are often far more complex than can
be 
addressed by the servers to be protected, and involve VPN
access, 
time-of-day rulesets, attack signature analysis and the
like.


>You can have an ALG, the application or the OS do this.
As you
>probably know by now, I don't favor the ALG approach.

That's great that you don't favor it, but firewalls with
stateful 
inspection can and do look deep into packets to figure out
if the 
packets are legitimate. These devices sell, because they
help. This, 
like NAT, is something that came about because of need. IPv6
does not 
remove the need for firewalls. Arguably because of the
volume of 
relatively untested software involved on the hosts,
firewalls will be 
quite important.


>>End-to-end-ness is and has been "busted"
in the corporate world AFAICT
>>for a number of years. IPv6 "people" seem
to think that simply
>>providing
>>globally unique addressing to all endpoints will
remove NAT and all
>>associated trouble. Guess what - it probably won't.
>
>If you don't want end-to-end, be a man (or woman) and
use a proxy.
>Don't tell the applications they they are connected to
the rest of
>the world and then pull the rug from under them. This
works in IPv4
>today but don't expect this to carry over to IPv6. At
least not
>without a long, bloody fight.

So I'm sure you've explained to the firewall vendors they
should be 
selling proxy boxes instead, and they've listened to you.
Sorry the 
market has dictated solutions you don't like. Time to move
on, and 
stop fighting a battle that's been lost.