On 28-mrt-2006, at 11:54, Michel Py wrote:
Tim Chown wrote:
If you deploy IPv6 NAT, you may as well stay with IPv4.
You're the one who convinced me some three years ago that there
will be
IPv6 NAT no matter what, what's the message here?
I've travelled to this strange land where there is IPv6 and it's
NATed... Some enterprising souls apparently took it upon themselves
to build IPv6 support into a firewalling package that (as so many
firewalls do) supports NAT. With the result that if you know how to
enable this, you can make it do IPv6 NAT. Simple client-server
protocols such as HTTP worked without incident as expected. However,
I also tried FTP, which really isn't that bad as NAT-breaking
protocols go. It didn't work because the server saw an illegal EPRT
request. In IPv4 with NAT that wouldn't have happened because:
1. The FTP client would have used EPSV in order to be NAT-friendly, or
2. The FTP ALG would have intercepted the private address and
rewritten it
Moral of the story: do IPv6 NAT at your peril. Now of course it's
possible to argue all of the stuff that makes IPv4 NAT work to the
degree that it does today can also be added to IPv6, and that is
true, strictly speaking. But will the vendors bother, and will the
customers require it? I don't think so. As Tim said: if you can live
with NAT, why not stay with IPv4? That saves you several headaches
and it only costs you a few IPv6 nice-to-haves such as stateless
autoconf that haven't been able to get people to IPv6 anyway.
Artur Hecker wrote:
the (static) statement that "90% of phones are
analog" seems very wrong to me.
My bad, I should have said land lines.
The interesting thing is that even though ISDN doesn't amount to much
in the US and it's mainly used for businesses in Europe, GSM which is
the biggest mobile phone technology, uses ISDN Q.9xx signalling, so
ISDN was never a waste of time.
People will still want to do NAT on IPv6.
Not enough to make it work well enough.
Yes, and since site-locals have been deprecated they will also
hijack an
unallocated block of addresses to use as private,
You can still use FEC0::/10 even though the special case handling
will be removed from future implementations and there are unique site
locals for which there is a specific hijacking methodology that
minimizes the dreaded ambiguity of private space.
Keith Moore wrote:
huh? there is no way to make a protocol that can address more hosts
than v4, that is 100% compatible with v4. and there's no good way to
divide up the net into v4 enclaves and v6 enclaves because the
applications that need v6 addressing don't fit neatly into enclaves.
As long as you don't use the extra bits, no problem. IPv4 on one side,
IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes,
when going to v4+ to v4 remove a bunch of zeroes. Initially it's a
total
waste of bits, but silicon is cheap these days.
When people will begin to scream bloody murder to use the extended
bits
(because v4 is getting near exhaustion) the infrastructure could be
already in place, and then the pressure will be on software developers
to recode their stuff with 128-bit addresses. When that has happened,
then we can make use of all these reserved fields for better purposes,
and possibly allocate PI to everybody which is another pre-
requisite to
get rid of NAT.
The trouble is that if you use IPv4-compatible IPv6 addresses (in the
loose sense of the word, not thinking of any RFC) for instance by
having the first 96 bits of the IPv6 be zero, you get to translate
between v6 and v4 transparently, but you still never get to use
addresses that are longer than 32 bits, so the only thing it gains
you is simpler IP processing (no header checksum etc) but not more
address space. For this, you need a mechanism so that the initiator
of the communication knows that the recipient supports longer
addresses. That's what we do with AAAA records in the DNS today.
There are no shortcuts here.
BTW, Michel, you said you were about to return from the dark side in
true Star Wars fashion. What gives? :-)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf