On 4/5/12 03:39 , David Meyer wrote: > On Wed, Apr 4, 2012 at 6:31 PM, Steven Bellovin <smb@xxxxxxxxxxxxxxx> wrote: >> >> On Apr 4, 2012, at 5:21 35PM, Noel Chiappa wrote: >> >>>> From: Doug Barton <dougb@xxxxxxxxxxxxx> >>> >>>> My comments were directed towards those who still have the mindset, >>>> "NAT is the enemy, and must be slain at all costs!" >>> >>> In semi-defense of that attitude, NAT (architecturally) _is_ a crock - it puts >>> 'brittle' (because it's hard to replicate, manage, etc) state in the middle of >>> the network. Having said that, I understand why people went down the NAT road >>> - when doing a real-world cost/benefit analysis, that path was, for all its >>> problems, the preferable one. >> >> NAT didn't really exist when the basic shape of v6 was selected. > > Perhaps, but that it would happen is obvious (even to the most causal observer). Effective address expansion through port-overload is agnostic for the most part (obvious exceptions abound) about the application layer... The alternative then as now was up at the application layer and there are good reasons why that was a more bad idea at the time. Today, foo over http/https:// is a big chunk of the solution space for application layer tunneling. > Dave > > >>> >>> Part of the real problem has been that the IETF failed to carefully study, and >>> take to heart, the operational capabilities which NAT provided (such as >>> avoidance of renumbering, etc, etc), and then _failed to exert every possible >>> effort_ to provide those same capabilities in an equally 'easy to use' way. >> >> They thought -- or claimed -- that they had renumbering... >> >> v6 is not the protocol I would have chosen. For that matter, it's not the >> protocol I pushed for, as hard as I could, in the IPng directorate. At this >> point -- with all of its technical mistakes, IETF omissions, and difficulty >> of converting, we're stuck with it; we simply do not have time -- even if >> we agreed now on what we should have done, way back when -- to start over. >> Do the arithmetic... Assume we know, today, the basic structure of a >> perfect replacement for v4. It would take a minimum of 3 years to get >> through the IETF, not because of process but because there are so many >> things that it touches, like the DNS, BGP, OSPF, and more. There are >> also all of the little side-pieces, like the ARP/ND replacement, the PPP >> goo, etc. After that, it's 3 years of design/code/test by Microsoft, >> Apple, Cisco, Juniper, et al., following which we have the whole education >> cycle, the replacement cycle while old boxes die off and are replaced, and >> more. (Look at how many Windows XP boxes still exist -- and we're well >> into the second major release of Windows since then, and Windows 8 might >> be out before the end of the year.) By my arithmetic, it's a dozen years >> minimum, *after* we've agreed on the basic design. >> >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> >> >> >> >> >