Eric S. Raymond wrote:
...
To sum up, NAT gives me two features:
1. Multiple machines on the single-address allocation the ISP gives me.
2. Decoupling of mt local network addresses from the ISP assignment.
This is a very restricted subset of:
http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt
Please send comments if you think something is wrong or missing.
Market perceived benefits of IPv4 NAT
Function IPv4 IPv6
+------------------+-----------------------+-----------------------+
| Simple Gateway | DHCP - single | DHCP-PD - arbitrary |
| | address upstream | length customer |
| | DHCP - limited | prefix upstream |
| | number of individual | SLAAC via RA |
| | devices downstream | downstream |
+------------------|-----------------------|-----------------------+
| Simple Security | Filtering side | Explicit Context |
| | effect due to lack | Based Access Control |
| | of translation state | (Reflexive ACL) |
+------------------|-----------------------|-----------------------+
| Local usage | NAT state table | Address uniqueness |
| tracking | | |
+------------------|-----------------------|-----------------------+
| End system | NAT transforms | Temporary use |
| privacy | device ID bits in | privacy addresses |
| | the address | |
+------------------|-----------------------|-----------------------+
| Topology hiding | NAT transforms | Untraceable addresses|
| | subnet bits in the | using IGP host routes|
| | address | /or MIPv6 tunnels for|
| | | stationary systems |
+------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & ULA |
| Autonomy | | |
+------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 340,282,366,920,938, |
| Pool | | 463,463,374,607,431, |
| Conservation | | 768,211,456 |
| | | (3.4*10^38) addresses|
+------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime |
| Multi-homing | at border | per prefix & Multiple|
| | | addresses per |
| | | interface |
+------------------+-----------------------+-----------------------+
Chris Palmer wrote:
There's another feature of NAT that is desirable that has not yet been
mentioned, and which at least some customers may be cognizant of: the
fact that NAT is a pretty restrictive firewall.
NAT != Firewall - despite all the marketing to the contrary, the artifact of
lack of state is not a firewall. Marketing needs to be retrained that an
IPv6 context based firewall will provide more comprehensive security that
doesn't mangle headers in the process. Assuming this is implemented in the
'plug-n-play' model as Fred suggests, sales could easily surpass nat.
Richard Shockey wrote:
I think the problem the Internet Engineering community has had is that
we have not taken out to lunch some of our friends in Economic Theory
who would help us understand the IPV6 adoption problem for what it is
an economic not a technical issue.
Yes deployment will be gated by economic factors. The problem the IETF and
the transit network operator community keep overlooking is that the economic
costs are not down in the plumbing. The costs are in application development
and end system/lan administration. Once the application development
community recognizes that it is cheaper for them to build over IPv6 than to
retain small armies to develop nat workaround hacks or deal with the
additional support costs from that complexity, and that through tunneling
they don't have to wait for lethargic operators to move first, there will be
plenty of economic motivation for deployment.
The hard part is getting the word out, because the IETF still isn't serious
about making IPv6 the default protocol for all work, and the operations
community continues to spread FUD about the useful lifetime of IPv4. As
several people have pointed out on this list recently, people can't get the
space they want today, so we are effectively already out.
The frog is in the pot and the water temperature is rising. Given the
general state of denial it is likely that the water will boil before the
dead frog wakes up to notice.
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf