On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: > Hi All, > > It will probably come as no surprise to many of you that I have spent > quite a bit of time over the last few years trying to understand why > people use NATs and how they could be replaced with more > architecturally harmonious mechanisms. I have been completely > convinced for several years that IPv6 will not eliminate the (real or > perceived) need for NATs, at least not without significant follow-on > work from the IETF. Did you ever think of the fact that many participants in the IETF earned a lot of money selling: - NAT "solutions" - VPN "solutions" to overcome the NAT problem - Consulting in many ways - Services to 'merge multiple enterprise networks' - ... Maybe some people do not want to solve the problem... Remember that people still need to have food on the plate the next day. > We won't be able to eliminate or substantially reduce the use of NAT > in the Internet architecture unless we come up with better ways to > address the problems that NAT is being used to solve, where better is > defined from the user's perspective not from an architectural > perspective. For IPv4 you can totally forget the removal/elimination of NAT. For IPv6 there is still a chance that people are educated properly to not even think about it. > The average Internet user (home user or enterprise administrator) > does not care about the end-to-end principle or the architectural > purity of the Internet. Never heard that gamer complaining that his friends could not join that game server she setup on her computer behind that NAT box? Also any P2P application loves end-2-end because then you don't have to use a 3rd party host to relay the traffic. They care but they don't realize what the problem is especially with the plethora of hacks that allow a NAT to somewhat work like a real end to end address. The problem though is that you have to hack around the NAT every single time. Which IMHO is more costly than getting some extra IP's. > These users care about ease of deployment, > cost and avoiding unscheduled outages (whether due to security issues > or ISP changes). They only want three things: - that it works without problems - with low latency so they can aim correctly in that 3d shoot-em-up. - with high download speeds to get their newest movies and other warez. > Home users primarily care about client access to > the Web, and enterprise administrators primarily care about keeping > internal network connectivity as stable as possible. Web? That is only a _fraction_ of the traffic they are generating. Also web is due to the simplicity of the protocol one of the few generally used protocols that doesn't have any problems with NAT's. Peer-2-Peer (read: end-to-end) is what they are using it for. MSN (and many other similar setups) for instance has this cam addon so that you can view the others person face and chat with the other person. Doesn't work when behind a NAT when you want to broadcast, unless you use the many tricks (eg uPNP) to avoid the NAT. > IMO, Internet users are primarily using NATs to solve four problems > that the IETF has not reasonably addressed: > (1) free IP address space for use on VPNs or other private networks, The world relies on money, nothing is free. RFC1918 came nicely with the problems that we see today with it's usage in combination with NAT's. RFC1918 isn't bad actually, but the thing called NAT is. For IPv6 ULA's should solve this spot quite well. > (2) stable provider-independent IP addressing For global or local connectivity? Local see ULA/RFC1918. For Global this cannot be done unless you want 128bit ASN's and 2^128 routing entries. See HIP for instance for one of the solutions to this problem. IP is a routing protocol, not an addressing protocol (DNS is the current addressing protocol in that respect). > (3) one-way connectivity to provide protection for > "client-only" nodes You mean firewalls? Could somebody at Cisco wake up and _release_ a working version of Cisco PIX's that support IPv6 please!? They said they had one 3 years ago by now, currently it is 'next release'... > (4) zero-configuration home and small office networking. I guess you forgot DHCP for both IPv4 and IPv6 and Router Advertisement for IPv6. Did you read the excellent NAP draft? (Currently draft-vandevelde-v6ops-nap-00 soon, I understood a -01) > Let me consider each of these problems separately: > > (1) Current ISP business models are tied to IP address allocation, > and that will need to change to remove the economic/business > incentives for enterprises to limit their use of IP addresses. There > might be similar changes needed to registry policies and business > models. Given that there are some rather large political and > financial forces involved, I don't have any idea how/if these changes > will come about. In the meantime, the only alternative for the IETF > is define portions of the address space that can be used for private > addressing on VPNs and other private networks. RIR's currently allocate IPv6 space with the following assumption on behalve of the LIR: The LIR will provide at least 200 /48's to endsites in the coming n years. When a LIR thus gives /128's or silly things like /64 to endsites they are thus violating the reasons why the requested the /32 (or larger in the first place). For IPv4 it is really a money business, want more IP's : pay for it. That is how they earn their money even though they basically get IP addresses for free (minus some administration costs, which really is not that much when you earn millions). ISP's should charge for _bandwidth_ just like they get charged by their upstreams/transits etc. But that isn't an effective finanicial situation as when you charge for that you can't be sure of a $large income. <SNIP (2), see comment above> > (3) There is work ongoing in the multi6 and hip WGs to address one of > the reasons why enterprises want provider-independent address space > -- enterprise-level multihoming. However, the solutions being > considered there will not eliminate the other primary reason why > enterprises want provider-independence -- avoiding dependence on a > particular ISP, which can lead to lock-in, higher prices and/or > unplanned renumbering events due to provider network changes, > failures, mergers, etc. With HIP you can swap addresses when you want, there is no dependence. The ISP is then doing where you pay her for: shoving bits. > To offer true provider-independence, we would need to offer > long-term, renewable assignments of IP address prefixes directly to > enterprises, similar to the "swamp space" in IPv4, but perhaps with > an annual fee required to allow recapturing unused prefixes. You are inventing extra work for the RIR's here, they have enough to do. Again IP is for routing, not addressing... <SNIP> > problem. So, enterprises are forced to use NAT to gain provider > independence -- a trait that they obviously (based on the wide-spread > deployment of NAT for this purpose) value above end-to-end > connectivity for their internal nodes. Why are they forced to use NAT? The problem is that IPv4 usually doesn't allow multiple addresses on the same interface, IPv6 allows this, you can use thus ULA prefix for local communication and one or more globals from one or more upstream ISP's. Nevertheless, forget about IPv4, that problem is unsolvable. > (4) NATs are also currently used as an element of zero-configuration > home networking solutions. While it is probably possible to build a > low-cost, zero configuration home gateway without using NATs or > scoped addressing (which I consider to be almost as bad as NAT), we > don't seem to be working on this problem in the IETF. Should we be? I guess you missed out on the DHCP-PD documents? > Without solutions to these four problems on the horizon, I can't > voice any enthusiasm that the larger address space in IPv6 will > eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf