RE: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]