> Iljitsch van Beijnum wrote:
> 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
No surprise here; exact same happened with NATv4 in the early stages. We
all know that NAT requires ALGs.
> Moral of the story: do IPv6 NAT at your peril.
Was the same with NATv4 too.
> 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.
Especially with the experience of doing it with v4.
> But will the vendors bother, and will the customers
> require it? I don't think so.
That's were you're wrong, IMHO. First, the vendors will do whatever the
customers want to buy, and customers are not always smart and will have
a great tendency to do just the same that worked for them with v4.
Second, vendors might try to do it just to see if it sells or not. Given
the existing NATv4 code base, it won't cost too much to implement NATv6
on an IPv6 capable "router". These guys have sold millions of NATv4
boxes, you can bet that if they eventually release a v6 product it will
have NATv6, the rationale being:
- If the customer wants to use NATv6, good because then they sell the
product while the competitor that does not have NATv6 does not. Just a
few percent makes a difference.
- If the customer does not want to use NATv6, all it costs was a few
weeks of coding, well worth the risk.
> 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.
Oh, I agree; but what we think might not be what the market picks. The
market might pick the "why not stay with IPv4" part without knowing why.
Maybe to accelerate the deployment of IPv6 we should advertise: It has
the same wonderful NAT you like so much in IPv4 :-D
<running for cover>
> 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.
But was a waste of money, at least in the US. Many telcos have invested
much money into ISDN that has not brought ROI. This is one of the many
reasons IPv6 does not take off in the US, because some people don't want
to repeat the financial ISDN fiasco and are reluctant to invest money in
technologies that they don't perceive being embraced by customers any
time soon.
There is a slight difference between what we do in here for the greater
good of humanity and what telcos and vendors do for the greater good of
their shareholders.
> 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,
Not at the beginning, but the point is a) getting ready for it and b)
backwards compatibility. In the initial stage, everyone is basically
wasting bandwidth and memory to carry/store all these useless zeroes.
Later on, when islands begin to implement the extended bits, they can
use them internally and tunnel if the backbone is not ready.
Imagine that you want to develop a high-quality audio CD. Today with
IPv6, you need to have both the good old CD and the new standard. Since
they are no high quality CDs available on the market and good old CD
works good enough for 99% of the people, it does not take off.
In this situation, the only way to market is to build a high quality
audio CD reader that reads the old CDs just as good and promises to read
the new ones when they eventually become available. Backward
compatibility.
Note that I'm not saying we should do anything about this; it's either
too late or too early. I have the feeling though that the protocol that
will replace v4 is not v6 but something that will feature seamless
backward compatibility.
> BTW, Michel, you said you were about to return from the dark
> side in true Star Wars fashion. What gives? :-)
And now, ladies and gentlemen, for your entertainment:
.-.
|_:_|
/(_Y_)\
( \/M\/ )
'. _.'-/'-'\-'._
': _/.--'[[[[]'--.\_
': /_' : |::"| : '.\
': // ./ |oUU| \.' :\
': _:'..' \_|___|_/ : :|
':. .' |_[___]_| :.':\
[::\ | : | | : ; : \
'-' \/'.| |.' \ .;.' |
|\_ \ '-' : |
| \ \ .: : | |
| \ | '. : \ |
/ \ :. .; |
/ | | :__/ : \\
| | | \: | \ | ||
/ \ : : |: / |__| /|
| : : :_/_| /'._\ '--|_\
/___.-/_|-' \ \
'-'
I think I found the IPv6 killer app:
telnet towel.blinkenlights.nl
We need more of these examples where the v6 version is better than the
v4 version.
But, back to priorities. I want PI; all of this time wasted on
re-numbering should have been spent in fine-tuning the Quake aiming
proxy, this is unacceptable. I want PI.
[RFC4193] and here it is! We could not route RFC1918 on the public
internet because addresses were ambiguous, but now that we have dropped
the scoped architecture and that these addresses are reasonably unique,
problem solved. All that we need is a little financial incentive to ISPs
so they forget to read the RFC and therefore forget to filter FC00::/7;
unless site-locals there are no technical difficulties or special
handling issues. From the ISPs point of view, it's a no-brainer in the
short term: more money, less work. At the current rate of IPv6 adoption
the size of the global IPv6 routing table is not going to be a problem
any time soon.
Besides, I own shares of a large router vendor, and they're not doing as
good as they used to. Allowing everybody to advertise their FC00 prefix
on the public internet is a unique opportunity to provide router vendors
with an excuse to roll out yet another forklift upgrade. As always they
will manage to produce routers that have limited expansion capabilities,
making them obsolete fast enough to maintain a healthy forklift upgrade
cycle of two to three years, which is great for the bottom line. Wall
Street will like it, and the timing will be perfect for me to cash out
these shares at their peak just before I retire. How could we ignore
such a business opportunity?
Now that the PI problem is solved, I want private addresses. It's a lot
easier to design the v6 network by copying the v4 design, and I need my
brainpower to focus on the Quake protocol to produce a better aiming
proxy so I can frag my buddies and win all the time.
> You can still use FEC0::/10 even though the special case handling
> will be removed from future implementations
Absolutely not. First, FEC0 addresses are ambiguous (/10 not big enough,
which is why /7 was picked for RFC4193), and I don't want to fall into
the renumbering business again when merging companies. Second, I'm
worried about some remains of special handling. Therefore, it is much
better to hijack any unicast address. It's actually a lot easier than
what we did prior to RFC1597: since addresses are plentiful, someone
will quickly come up with something similar to http://wiana.org/
allowing me to register my hijacked address and insuring its uniqueness.
And finally of course, I need NATv6 to allow my unique hijacked private
IPv6 address to be translated into a publicly routed FC00 address, and
my design is complete. I do need to keep NAT under strict control in
order to maintain continued employment, but unique addresses both inside
and outside ensure that I will be able to maximize office hours to
finish pet projects instead of doing real boring work. Besides, as
everyone knows NAT is evil, and I need a scapegoat in case something
goes wrong.
Iljitsch, come with me to the dark side. I will show you the true nature
of the force. Together, we will defeat the emperor and rule the
Internet. It is your destiny.
Michel.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf