Short version: The only applications I can think of which work OK
behind NAT and which would be easy to use with
IPv6 would be client-server applications, in which
the client may be behind NAT and the server cannot
be. These are not the most challenging types
of applications to make work from behind NAT.
Hi patte,
>> As far as I know, CEE won't work with NAT. That is not necessarily a
>> bad thing with IPv6, since it has long been hoped that NAT would not
>> infest IPv6.
>
> NAT is evil, no doubt about that. But if we wouldn't have had NAT most
> likely the application people would have written more applications
> that are relying directly on IP-addresses and a migration of
> application to e.g. IPv6 would be much harder. So it is bad but there
> is something good also.
I can't think why an IPv4 application which has been made to work
from behind NAT, I guess with specific messy protocols and external
servers to trick the NAT box into allowing various things to happen,
would be easier to modify for IPv6 operation. As far as I know,
making an application able to operate from behind NAT isn't some
special generalised independence from how each host is connected or
where, which would somehow ease rewriting the code for IPv6.
This is pretty generalised discussion. Can you think of some
examples? Below I consider client-server applications where the
client may be behind NAT and does all its work with a server which is
not behind NAT, using HTTP - which could be over IPv4 or IPv6.
However, other applications need communication between two or more
hosts which may be behind NAT, ideally without a server.
>>> - so actually it is not the CEE's
>>> fault that you get into trouble with these kind of applications. And a
>>> new architecture comes with a cost, not everything can be preserved as
>>> such - if everything is preserved, then it can't be a new
>>> architecture.
>>
>> Yes, but the only benefit of CEE I know of, apart from architectural
>> purity, is that it enables multihoming and perhaps mobility on a
>> scalable basis without the need to upgrade the routing system at all.
>>
>> This is impressive and interesting, but it comes at a cost, as I
>> argue in my recent message about how CES is very different from CEE:
>> more delays in establishing most communication sessions, more work
>> for hosts, more packets going back and forth between hosts, more
>> lookups by hosts into slow, less then 100% reliable global query
>> server systems (such as DNS) - and all this is made worse still for
>> any host which is on a wireless link with congestion, delay, dropped
>> packets etc.
>>
>> Then there is the fact that CEE only delivers substantial benefits to
>> adopters and to scalable routing after everyone has adopted it in
>> their hosts and after essentially all applications have been
>> rewritten to use the new CEE API in the stack.
>>
>> This is never going to happen. The Internet is not so broken that we
>> have to rewrite the apps.
>
> True, but NAT has done us a favor here. The application which works
> well over NAT shouldn't care what is happening on the network layer
> and most of the applications working over Internet shouldn't be a big
> issue.
I am not sure this is true - except to the extent that if the
application simply relies on an underlying protocol, such as TCP or
HTTP, to connect to a server which is not behind NAT. It is easy to
do client-server applications where the client is behind NAT and the
server isn't. If the application uses HTTP as its basis, and always
tells the HTTP layer to open a session to a given URL, then I agree,
the application has nothing to do with IPv4 or IPv6, and will work
fine no matter how the HTTP system makes the session to the specified
server - assuming the URL somehow gives the HTTP layer access to its
choice of IPv4 and IPv6 server.
But this is only one subset of applications. The real trick with NAT
is to make it possible for the behind-NAT host to receive a packet
from some other host (which itself may be behind NAT) when this host
has not previously opened up a session to the other host. A further
trick is to make this work if the unfortunate host is behind two or
more layers of NAT.
I don't see how such necessarily messy arrangements for outsmarting a
variety of types of NAT (and the host can't easily tell which kind of
NAT it is behind, or how many levels) necessarily means that the
application can be made to work on IPv6 without much fuss.
> But then when you have a look on what is used inside an
> enterprises' Intranet it is a different story - there is quite a lot
> of applications that has been tailored for businesses and if you
> change that it will be expensive, very expensive
There's no way all these applications are going to be rewritten for
the purpose of supporting scalable routing. They might be rewritten
if there is ever sufficient impetus to make them work with IPv6.
CES provides scalable routing much better and with more immediate
benefits to adoptors and routing scalability than CEE. Only CEE
requires rewriting applications.
>>> So is NAT really that evil as its reputation?
>>
>> I think NAT is very evil. The any-to-any connectivity model of the
>> Internet is an excellent thing.
>
> It is evil, no doubt - but it is today part of the package.
Yes.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
