Jeroen Massar wrote:
I guess you missed out on:
http://www.iana.org/assignments/ipv6-address-space
I declined to co-author it, as a matter of fact. It started as GUSL
(Globally Unique Site Locals), did you miss that season? Read the dark
side stuff I will post later...
Austin Schutz wrote:
The limitations of NAT you mention make little difference to most
of the NAT users I am familiar with. These are typically end users
or small organizations. They generally don't know what they are
missing, and NAT works adequately well for their purposes. I don't
foresee them switching or "enhancing" unless there is some killer
application as yet unsurfaced which demands it and won't work
adequately well with a limited amount of bizarre hacks and
workarounds.
Point made many times, and the proof is in the pudding: if they're using
it so widely it means it works for them.
Tim Chown wrote:
We have deployed IPv6 in our enterprise (throughout).
Michel Py wrote:
Could you have done it if you did not have the
research dollars^H^H^H^H pounds?
While we ironed out many issues with research funding assistance in
6NET, I would say the deployment we have now could be done as part
of a natural evolutionary procurement process.
I don't see much of this out of the academic community though, save for
some in Japan.
I note Phillip's extremes of view on IPv6 and DNSSEC.
It's interesting to compare how critical these two
elements are, and his views on them.
Point well taken.
And there's always IPv8 ;)
Dang, I forgot about this. Why are we deploying IPv6 when Jim has
already provided us with the perfect solution :-D
Noel Chiappa wrote:
Since this old canard has resurfaced again, it's clearly time
to drag out some old messages, which I resend every couple of
years, and send them around yet again.
The executive summary is: The issue with routing table size (and
why big ones are Very Bad) is really not the size of the memory
needed to hold the table (which is a static thing), but the
dynamics - i.e. things like stabilization time after topology
changes (and we have real problems there, as all the fancy BGP
route-flapping and dampening stuff attests).
I know; I made this very point myself in several public presentations.
In general, all of these (including extra addresses) have the
attribute
that "you plug this box in at the edge of the network, and don't have
to change anything else". *That* is what really sold NAT.
Which is why I have said many times that getting rid of NAT requires
giving PI.
We aren't *ever* going to give everyone PI space (at least, PI space
in whatever namespace the routers use to forward packets), any more
than we are going to let them take their street addresses with them
when they move.
Routing (i.e. path-finding) algorithms simply cannot cope with
tracking 10^9 individual destinations (see prior message).
Noel, I think you're dead wrong on this. This reasoning was valid with
10^8 Hz processors and 10^8 bytes of memory it's no longer true with
10^11 or 10^12 Hz processors and memory (we're almost at 10^10 cheap
ones). I'm not saying it's elegant or good engineering or anything, but
it will happen.
Anthony G. Atkielski wrote:
BTW, giving out /64s is one reason why the IPv6 address space
will be exhausted in barely more time than was required to
exhaust the IPv4 address space.
Thomas Narten wrote:
This is FUD. Care to back up your assertions with real analysis?
FUD it is, don't bother. We all ran the numbers; although
retrospectively there could be some good reasons to have more than 128
bits (such as embedding a locator in the address or embedding some
crypto, or giving a few more bits to Tony for his GeoPI) we have enough
IPv6 for a period of time long enough for me.
Michel.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf