> 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
