Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Michel Py wrote: That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. I think we bite the bullet and go to IPv6. Screwing around with Class E address space at this late date is counterproductive. Say what you will about v6. It *does* have more bits. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Michel Py wrote: That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. When develloping IASON, first I found out, CISCO boxes would not allow me to use class E addresses nor would HP boxes. Next I found out Linux boxes would not either. I guess most boxes will not allow you to use these addresses. Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
On 14-apr-2006, at 15:52, Peter Dambier wrote: That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. When develloping IASON, first I found out, CISCO boxes would not allow me to use class E addresses nor would HP boxes. Next I found out Linux boxes would not either. I guess most boxes will not allow you to use these addresses. Use a Mac. :-) en0: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 240.240.240.240 netmask 0xff00 broadcast 240.240.240.255 (Also the only major OS that has IPv6 turned on by default.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
real time inventory management Wow! I've heard all sorts of claims for what IPv6 will do/include, but I must say that's a new one It's like Wal-Mart approach: the inventory constantly moves, it never sits still on the shelf. IPv6 addressed RFID tags look promising. [EMAIL PROTECTED] --- Noel Chiappa [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] If Boeing had rolled out IPv6 in 1993-1994 by now they would have ... real time inventory management Wow! I've heard all sorts of claims for what IPv6 will do/include, but I must say that's a new one Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Brian, Michel Py wrote: v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Brian E Carpenter wrote: Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If they had deployed 5 years ago there still would be no return as of today and if they deployed today I see no return (in reduced operating costs) for 5 years. As a shareholder my best interest so far has been not to deploy. My instructions are: keep an eye on the situation, if there is a change in conditions that means IPv6 buck could bring bang _then_ go for it; in the mean time put my cash where it does bring some bang, either by developing new products or by paying me dividends 4 times a year. As long as other shareholders (especially the ones who work there and likely have scores of unvested shares) think the same way, this is the deal. Eliot Lear wrote: Boeing has enough devices and networks that it could on its own probably exhaust a substantial portion of remaining IPv4 address space we have now. They certainly have more than a /8's worth, and that poses RFC1918 problems Boeing has 159,000 employees. RFC1918 space is 17,891,328 addresses. That's more than 100 IP addresses per employee, I think Eric can manage. That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If Boeing had rolled out IPv6 in 1993-1994 by now they would have an efficient production and real time inventory management; would have saved billions in costs and were giving (at least part of it) to Michel. As a shareholder you may want to think how you vote during the next shareholders meeting. Cheers, [EMAIL PROTECTED] --- Michel Py [EMAIL PROTECTED] wrote: Brian, Michel Py wrote: v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Brian E Carpenter wrote: Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If they had deployed 5 years ago there still would be no return as of today and if they deployed today I see no return (in reduced operating costs) for 5 years. As a shareholder my best interest so far has been not to deploy. My instructions are: keep an eye on the situation, if there is a change in conditions that means IPv6 buck could bring bang _then_ go for it; in the mean time put my cash where it does bring some bang, either by developing new products or by paying me dividends 4 times a year. As long as other shareholders (especially the ones who work there and likely have scores of unvested shares) think the same way, this is the deal. Eliot Lear wrote: Boeing has enough devices and networks that it could on its own probably exhaust a substantial portion of remaining IPv4 address space we have now. They certainly have more than a /8's worth, and that poses RFC1918 problems Boeing has 159,000 employees. RFC1918 space is 17,891,328 addresses. That's more than 100 IP addresses per employee, I think Eric can manage. That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
From: [EMAIL PROTECTED] [EMAIL PROTECTED] If Boeing had rolled out IPv6 in 1993-1994 by now they would have ... real time inventory management Wow! I've heard all sorts of claims for what IPv6 will do/include, but I must say that's a new one Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Iljitsch van Beijnum wrote: On 11-apr-2006, at 15:58, Brian E Carpenter wrote: However, geographic addressing could give us aggregation with provider independece. You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. I'm serious. Which properties would you like to examine in such a model? It shouldn't be too problematic to simulate a routing table of 100 million entries (I'm assuming there won't be any host routes...) in non real time, but simulating the interactions between several routers per AS for several ASes will be harder at this scale. Yes, simulating convergence times would be quite a challenge. So I think a sufficient initial target would be the converged BGP4 table in a core ISP. Even that will need a model for how enterprises, ISPs, ASes, peering and exchanges are distributed around the world. Lots of assumptions to specify. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 4/11/06 12:33 AM, John Loughney [EMAIL PROTECTED] wrote: In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. I'm curios to understand more of what you mean by this? Are you running out of ports? Do you have any ideas what is causing this? (I have a strong interest in the many ways NATs fail :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Cullen Jennings wrote: On 4/11/06 12:33 AM, John Loughney [EMAIL PROTECTED] wrote: In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. I'm curios to understand more of what you mean by this? Are you running out of ports? Do you have any ideas what is causing this? (I have a strong interest in the many ways NATs fail :-) Linux: http://www.eisfair.org/ host_type(echnaton,(none),Linux echnaton 2.2.19 #15). No problems, but from time to complains about not so clean seesion termination by dtag.de _ Fritz_Box_Eumex300IP cpu model : MIPS 4KEc V4.8 BogoMIPS: 149.91 Linux version 2.4.17_mvl21-malta-mips_fp_le No problem either, but from time to time I find in my telnet session: Apr 11 05:22:04 dsld[381]: Channel 0 closed (physical) Apr 11 05:22:04 dsld[381]: EVENT(36): Zeitüberschreitung bei der PPP-Aushandlung. (PPP_LCP) Apr 11 05:22:04 dsld[381]: internet: PPP_LCP TIMEOUT Apr 11 05:22:04 dsld[381]: starting autodetection Apr 11 05:22:04 voipd[402]: connstatus 4 - 2 Apr 11 05:22:07 dsld[381]: autodetect: failed Apr 11 05:22:07 dsld[381]: atm socket rmem 65534 Apr 11 05:22:07 dsld[381]: PPPoEFW: set_snd_mtu: 1492 Apr 11 05:22:07 dsld[381]: PPPoEFW: set_rcv_mtu: 1492 Apr 11 05:22:07 dsld[381]: PPPoE forwarding for lan enabled. Apr 11 05:22:07 dsld[381]: internet: set_rcv_ipaddr: 192.168.179.1 Apr 11 05:22:07 dsld[381]: internet: connecting Apr 11 05:22:07 dsld[381]: internet: 00:04:0e:6d:8a:43 Apr 11 05:22:07 dsld[381]: internet: 00:04:0e:6d:8a:43 ... repeating _ Grandstream ATA-486 Red lite blinking, saying VoIP is dead. HTML does not connect at all. No Ping either. Only unplugging power get the box back. _ dtag.de forces session termination every 24 hours. Sometimes they are nasty and terminate the session several times within a short time or they simply go dead. Happens rarely. Everytime I get a new ip-address after reconnecting. That is all what this silly session termination is about. Just to anger the VoIP people. They are selling VoIP themselves those silly buggers :) The Grandstream goes bonkers when session terminations is forced but the session is not terminated propperly but simply broken. There is another problem with the GrandStream: It does not handle ICMP properly. It breaks MTU discovery and traceroute. Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Eric Fleischman wrote: that us end users will go to great lengths to avoid any costly network upgrade that does not contribute anything to our bottom line. Think about it: why would we spend tens of millions of dollars to get equivalent network connectivity to what we already have? It makes absolutely no sense from our point-of-view. Indeed. Put these tens of millions of dollars where they rightfully belong: in my pocket. I own Boeing (well, a very little part of it). I understand this might sound shocking in some parts of the world, but the reasons I bought Boeing shares are because I expect to resell these shares later for more that what I paid for them AND collect dividends along the road. This concept is known as capitalism in some parts of the world. +-+ | Build Airplanes | +++ | v +++ | Sell Airplanes | +++ | v +-+--+ | Make a buck or two | +-+--+ | v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RE: Stupid NAT tricks and how to stop them.
Lars-Erik, From: Michel Py [mailto:[EMAIL PROTECTED] Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by default; 2 of them it was impossible to turn this off. I got into long discussions with tech support who were telling me it is impossible to design a WLAN AP-router combo that didn't NAT. My DSL provier offers me 5 DHCP address for free (consumer grade connection) and my mobile carrier is now using real IP address for GPRS (they had too many problems caused by NATed IP addresses). In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. The most common things most ISP tech support lines are unplug your router/AP/box, count to 60 and plug it back in. However, if I am just a normal user, go to Best Buy and pickup a home WLAN Access Point, I'll have a NAT by default. There is no NAT inside logo on the box, nor are there clear instructions on how to turn this off. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to a the market, the marketing message was that NATs provided a security feature. Still, I have far too many tech support discussions where there is common confusion between NAT firewall features. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved, but creates some ugly side effects. To get around these side effects, people are deploying ALRs, B2BUA and SBCs to help fix the side-effects (and to do other things). Human nature being what it is, we'll probably keep applying these quick fixes, until it gets far to messy and someone comes in and wipes these away with a new solution. Circuit switching, ATM, ISDN, etc. all have been useful for some solutions - but when you try to go beyond what they have been designed for, you tend to have to apply patches and hacks to get things working. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
On 11-apr-2006, at 4:39, Anthony G. Atkielski wrote: It is worth about the same as a postal address that comes naturally when they build a new house. In a similar way when a new device comes to existence it gets an address out of infinite universe of 0 and 1. Maybe in some part of the universe addresses are infinite, but in the part where I live it's mostly 32 bits. That would only be true if IP addresses were geographically assigned, which they aren't. You know, you could assign IPv6 addresses in a strictly geographic way and you'd have more than enough for everyone, everywhere, with very simple routing. But of course that won't be done. No, routing would be more complex. Routing is the art and science of getting to a place, which is a lot harder than simply knowing where a place is. However, geographic addressing could give us aggregation with provider independece. If you examine European routes in the routing table of a router on the American west coast, you'll see that the vast majority of those routes point towards the same next hop. So if you could express an aggregate that encompasses all those routes and point that aggregate towards that next hop, you could filter out all those specific routes and the routing table in that one router would be a lot smaller. At each hop the number of routes that have a different next hop than the aggregate increases, until at some point the aggregate doesn't serve a useful purpose anymore. But by then you're in Europe or at least on the American east coast, where you can heavily aggregate Asia. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
John Loughney wrote: Lars-Erik, From: Michel Py [mailto:[EMAIL PROTECTED] Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by default; 2 of them it was impossible to turn this off. I got into long discussions with tech support who were telling me it is impossible to design a WLAN AP-router combo that didn't NAT. Just for curiousity: The TI chipset AR7 is the core of a couple of boxes. The all run linux and you can telnet them. They can route. No need for NAT My box is an Eumex 300 IP from t-online.de It is the same as the Fritzbox from AVM. Netgear, Siemens, Linksys and D-link produce similar boxes. I remember some people at RIPE loudly thinking about writing their own software for the Netgear or the Linksys. My DSL provier offers me 5 DHCP address for free (consumer grade connection) and my mobile carrier is now using real IP address for GPRS (they had too many problems caused by NATed IP addresses). DHCP is almost as bad as NAT is. Best get an aDSL-modem, if you are connected by aDSL then distribute the line via a switch and let your five coputers to the PPPoE stuff. So your computers are the DHCP clients and can dyndns or whatever. In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. The most common things most ISP tech support lines are unplug your router/AP/box, count to 60 and plug it back in. I have had that same power-cycle problems with a GrandStrem ATA for my VoIP. My ISP dtag.de or t-online.de forces a disconnect every 24 hours. Sometimes they dont disconnect very cleanly and the Grandstream breaks. Best forget GrandStream. It breaks ICMP and it has problems with ssh and telnet passing through. Problably it does not get MTU correctly from people living behind tunnels. Their support never cared to answer. A Siemens router is now connected for half a yaer without any power-cycles. I guess the box is one of those AR7 linux boxes. My eumex too did not show any problems except for nagging about undisciplined disconnects form my ISP. However, if I am just a normal user, go to Best Buy and pickup a home WLAN Access Point, I'll have a NAT by default. There is no NAT inside logo on the box, nor are there clear instructions on how to turn this off. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. I guess if you are a normal user then you are a loser anyhow. Those people normally have open windows and they dont know how to close them :) Putting those people behind triple NAT would not only save their harddisk some viruses but it would save our bandwidth too - keeping them from p2p each other :) As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to a the market, the marketing message was that NATs provided a security feature. Still, I have far too many tech support discussions where there is common confusion between NAT firewall features. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved, but creates some ugly side effects. To get around these side effects, people are deploying ALRs, B2BUA and SBCs to help fix the side-effects (and to do other things). Human nature being what it is, we'll probably keep applying these quick fixes, until it gets far to messy and someone comes in and wipes these away with a new solution. Circuit switching, ATM, ISDN, etc. all have been useful for some solutions - but when you try to go beyond what they have been designed for, you tend to have to apply patches and hacks to get things working. John Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Peter Dambier wrote: Just for curiousity: The TI chipset AR7 is the core of a couple of boxes. The all run linux and you can telnet them. They can route. No need for NAT My box is an Eumex 300 IP from t-online.de It is the same as the Fritzbox from AVM. Netgear, Siemens, Linksys and D-link produce similar boxes. I remember some people at RIPE loudly thinking about writing their own software for the Netgear or the Linksys. People ARE writing software for these devices. And using their software. See, for instance, http://en.wikipedia.org/wiki/Wrt54g Among the publicly available enhancements you can get a tunneled v6 service if your provider doesn't support it natively. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
You know, you could assign IPv6 addresses in a strictly geographic way and you'd have more than enough for everyone, everywhere,with very simple routing. But of course that won't be done.In fact some people are doing this todaywithin their networks.IPv6 marveles ability to "address every millonth of a second of arc inlatitude and longitude on the planet" drives the entire excitment and funding.Private networks aside IP address allocation maybe needs to be done on a strictly geographical basisin a politically neutral fashion, e.g. via UN sponsored RIR / LIR. Wemay need an RFC on how tofund IANA activitiesthrough UN allowing "free" allocation of addresses to any interested individual or establishment.[EMAIL PROTECTED] "Anthony G. Atkielski" [EMAIL PROTECTED] wrote: Peter Sherbin writes: It is worth about the same as a postal address that comes naturally when they build a new house. In a similar way when a new device comes to existence it gets an address out of infinite universe of 0 and 1.That would only be true if IP addresses were geographically assigned,which they aren't.You know, you could assign IPv6 addresses in a strictly geographic wayand you'd have more than enough for everyone, everywhere, with verysimple routing. But of course that won't be done. The actual cost driver here is a need for an operator (e.g. Postal Service or ISP) to maintain a list of all existing addresses to be able to provide their services.Not necessarily. If the addressing is strictly geographic--naddresses for each area of m square metres on the planet--routingwould be very simple and wouldn't require much in the way of tables.With 78 bits, you can address every millonth of a second of arc inlatitude and longitude on the planet. That's an area of about 0.00095square millimetres.___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
... However, geographic addressing could give us aggregation with provider independece. If you examine European routes in the routing table of a router on the American west coast, you'll see that the vast majority of those routes point towards the same next hop. So if you could express an aggregate that encompasses all those routes and point that aggregate towards that next hop, you could filter out all those specific routes and the routing table in that one router would be a lot smaller. At each hop the number of routes that have a different next hop than the aggregate increases, until at some point the aggregate doesn't serve a useful purpose anymore. But by then you're in Europe or at least on the American east coast, where you can heavily aggregate Asia. You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. I'm serious. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RE: Stupid NAT tricks and how to stop them.
John Loughney wrote: We're over-analyzing things. I don't think so. The Internet is no longer this thing for researchers and geeks it used to be. Now it is a global commercial product. As long as we keep producing protocols designed by researchers and geeks for researchers and geeks with total disregard to mass-market considerations, we will keep having these discussions about why crap gets deployed instead of the good stuff. My DSL provier offers me 5 DHCP address for free (consumer grade connection) Then you don't need a router; if you don't NAT there is no address space you could route your DHCP addresses to/from. You need a bridge, just connect only the LAN side of your combo box and you'll be able to have your DHCP addresses over the WiFi. The wireless-to-wired bridge works regardless of the configuration of the WAN side of the combo box. Ironically, it is probably cheaper to buy a combo box than a pure wireless bridge, but that's another story. What you might want is a real firewall that could bridge, and as discussed earlier there are not many consumer grade offerings as of today. There few offerings because there is very little demand, and there is little demand because such firewalls have many of the inconveniences of NAT. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. I do not agree. It was not easy at the beginning; it is easier now because it has become a more mature product. The market buys products, and the vendors react by producing the gear that the market wants to buy, for cheap because it's a competitive environment. When a product is new, vendors more or less guess what it could/will be, but when a product is mature such as NAT now, vendors design products based on what sells and recurse with small changes. In mass-market products vendors have little influence over the market. Marketing and advertising can somehow change what the market wants to buy, but in the end consumers often buy what is cheap or whatever their buddies have, and the fact that something is superior might not make any difference. As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to the market, the marketing message was that NATs provided a security feature. At that time, NAT did provide some security. It was very common then to see PCs directly connected to the Internet with a public IP, with all the NetBios ports open to all would-be hackers in the world. The nothing in unless initiated inside is not perfect, but it was a heck of a lot better than an unprotected PC sitting directly on a public IP. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved I disagree with this as well. The market chose NAT. The market probably does not know it's a band-aid, nor does it care. But it knows it's cheap and it works good enough. The market chose cars that rust over stainless steel ones too (remember these cool DeLorean cars). The stainless steel car is superior to the regular car, but the inconvenience of the car rusting was not worth the difference in price and consumers did not embrace it. Same for light bulbs and neon tubes: light bulbs blow regularly and are not efficient; neons produce low-quality light. There are technologies that last long, are efficient and produce good quality light. Look around you. Same applies to NAT: if we want to get rid of it, instead of forever whining that it sucks we have to provide the market with a better alternative for about the same price, which we don't have today. Better meaning not what we deem as technically superior but what the market would consider worth implementing. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Noel, Back in 1993 I predicted that what you have just stated is what us end users will actually do in regards to IPv6 (which we called IPng back then). I documented my thoughts in that regards in RFC 1687. RFC 1687 is somewhat dated now, since the example of a killer app I selected is rather quaint (to be generous), but the types of motivation underlying that identification still persist. In any case, I applaud your insight below that us end users will go to great lengths to avoid any costly network upgrade that does not contribute anything to our bottom line. Think about it: why would we spend tens of millions of dollars to get equivalent network connectivity to what we already have? It makes absolutely no sense from our point-of-view. --Eric -Original Message- From: Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Monday, April 10, 2006 7:36 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Reality (was RE: Stupid NAT tricks and how to stop them.) From: Tony Hain [EMAIL PROTECTED] The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. The best laid plans o' mice an' men gang aft agley. -- Robert Burns 'Do not put too much faith in this hairy architecture you have constructed', retorted Daemon Feature. 'All this is insignificant compared to the Hack.' -- Mark Crispin, Software Wars Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), so I have no specific prediction to make, but... Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
On 10-apr-2006, at 7:43, Tony Hain wrote: Instead of dissecting the numbers into chunks that give you the answer you want, how about looking at the big picture? [...] The real issue is that Geoff's linear projections against the current .75 /8's per month going out from the RIRs to hit a 2012 date don't match the historical growth. The problem is that nothing matches historical growth, because it contains elements that have proven resistant against modeling. (Note that Geoff has three different projections and the linear one doesn't hit the ceiling in 2012, with 0.75 /8s per month = 151 million/year this date would be 2015.) Also, taking a very short term view creates misleading windows that lead to claims like yours that we are now on a slower pace than last year, so not to worry. While the graph does show that we were above the projection curve last year and below it so far this year, the overall trend since Jan 2000 is tracking the projection very tightly. I don't see it. If I use a formula of deltayear(n) = deltayear(n-1) * x and start in 2000, the best fit (where the yearly differences between the projection and reality as a percentage added up equals zero) is a an x of 1.09. This is obviously ridiculous because both 2002 and 2005 are off by around 30% (93 vs 69 million and 120 vs 168 million). If I ignore 2002 and 2003 it comes out to 15%. This lands us in 2010 as the year IPv4 runs out, by the way, with the projection for this year at 180 million addresses. At 9% this would be early 2014 with a projection of 131 million addresses used this year. The only way I can fit the projections closely to reality is by picking 2002 as my start date and assuming 34% growth. This way, we're out very close to the turn of the decade, but it does mean we'll be using up 222 million IPv4 addresses this year. And that's something that the current figures just don't seem to support, even though 2006 so far as increased from 35 million when I wrote my earlier message to 45 million now. However, for 222 million it would have been something like 61 million by now. (But looking at the data this closely doesn't do much good.) The good news is that at the end of the year, we'll have a much better picture: either the mini-trend of around 34% growth in yearly address use that started after 2002 will turn out to have continued more or less, or it turns out it wasn't a trend after all, just like the dip in 2002 wasn't a new trend. Until that time, I'll continue to assume 2010 - 2015 with 2012 as the most likely moment for IPv4 to run out. Changing the RIR policy is a hopeless cause. This would have to be a simultaneous global change and the process for getting global agreement takes at least 2 years (as shown by the only global agreement they have; IPv6 policy, and the much longer time it is taking to debate changes to it). By the time anything could be done there wouldn't be enough left to worry about. I don't think the actual changing is the hard part, but coming up with a new policy that is better than what we have now, is. We'll never really run out of /24s and blocks that aren't much larger because even though = /18 blocks make up 90% of all allocations they make up less than 10% of the total address space used, i.e., less than a /8 a year. So we only have to reclaim a single /8 per year to accommodate those requests. For the really big blocks that ISPs are burning through so fast these days, I don't see a reasonable policy that can slow this down without basically making IPv4 effectively run out for them at the time of the policy change rather than when we're really out. Either you give those ISPs what they need or they'll have to start putting more than one customer behind a single address. So a policy change to make the IPv4 space last longer for the big users would be impossible. There are two things we can do, however: - try to avoid destructive end-game behavior, for instance by imposing a maximum block size at one point - set aside a limited amount of IPv4 addresses (like the last 100 million addresses) for smaller address users rather than give the last bit to the large users There is however and interesting policy question: should we allow IPv4 addresses to be sold? Some people are in favor of this, but I don't see the upside of formally allowing it. (People are going to do it to some degree anyway.) The down side is that you can forget about getting back sizable legacy space chunks and people have even more of an incentive to hoard address space rather than use it. And this will break up the address space in much smaller fragments which doesn't help the routing table. With the advent of RIR-anchored address space certificates the RIRs must decide whether they allow trading or sub-delegation of address space or prohibit it. You are correct that we don't know
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
The real issue is that Geoff's linear projections against the current .75 /8's per month going out from the RIRs to hit a 2012 date don't match the historical growth. I suppose I should respond here, particularly as the quote about using linear models is not a correct one. The projection model I use is updated daily at http://ipv4.potaroo.net using a rolling window of the past 1000 days to generate a predictive model of address consumption. Today's projection of IANA pool exhaustion is September 2011 and RIR pool exhaustion a little over a year later (assuming that the RIR pool can be cleaned out with 100% efficiency - which is an unrealistic assumption, of course). The growth model used is an exponential one, and the report shows the fit of linear, exponential and O(2) polynomial curves to the data used for projection (Figure 22). The choise of exponential is based on a decent least squares linear best fit to the logarithm of the smoothed data. I use a 1000 day baseline (i.e. the last 1000 days of hourly data) to produce the projection model. i.e. the model assumes that tomorrow will be a lot like today, and the changes will be the same changes that were evident in the past. The trend predictor I use in the growth in the advertised address range in the BGP table, and I derive RIR and IANA consumption figures from a combination of this primary trend plus a related trend in the growth of the unadvertised address pool relative to the growth in the advertised address pool I then model RIR behaviour in order to model IANA pool consumption in order to derive a date of pool exhaustion, using existing IANA to RIR address allocation procedures as the basis of the model. How good is this technique? I guess we'll know in about 6 years or so, but the nature of this daily update is that it will tend to self-correct over time. Late 2005 was a large 'bubble' of addresses entering the routing table - as happened early 2003. Currently the growth rate is lower than this recent peak. This makes predictor models a little more challenging in terms of figuring out whether there is any sense in artificially weighting more recent data over older data. The one thing I'll note here is that this model makes no consideration of any form of 'run' on remaining address resources, nor any consideration of a change in allocation practices, nor a change in industry demands over and above what's already visible in trend production. I notice that this thread is labelled reality. Projections are not reality, they are always guesses to one extent or another as to what will happen. Reality is, of course, what has happened and what is happening. So, to some extent all of this predicting stuff is just fun with numbers. The reasonable high level bits to take away from this exercise and others that have occurred and will no doubt occur in the future, is that there is an increasing level of certainty that the current forms of access and distribution of IPv4 addresses will experience a discontinuity sometime in the next 4 - 8 years. regards, Geoff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
From: Tony Hain [EMAIL PROTECTED] The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. The best laid plans o' mice an' men gang aft agley. -- Robert Burns 'Do not put too much faith in this hairy architecture you have constructed', retorted Daemon Feature. 'All this is insignificant compared to the Hack.' -- Mark Crispin, Software Wars Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), so I have no specific prediction to make, but... Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Iljitsch van Beijnum wrote: The problem is that nothing matches historical growth, because it contains elements that have proven resistant against modeling. That's the way I see it myself. Until that time, I'll continue to assume 2010 - 2015 with 2012 as the most likely moment for IPv4 to run out. In the big scheme of things, I actually don't see what it changes to know the exact date now anyway. We only get to cry wolf so many times. And we have cried a lot over the last 10 years (including doom predictions over Y2K). As of today I don't see people doing anything until they actually see the wolf. And I think they won't even do anything then until the wolf proves to be a big annoyance, which remains to be seen. When we run out of IPv4 space obviously very many people will have IPv4 addresses and they'll want to keep using them. Indeed. And in the case of the US (and to a lesser extent other industrialized countries) 3 to 4 addresses per capita are enough for a very long time. It is possible that the US will remain a v4 deal forever, as many Americans are not interested in what happens elsewhere in the first place. To me, the interesting thing is not WHEN it will happen; it's WHAT happens when it does and what we can do about it. There is however and interesting policy question: should we allow IPv4 addresses to be sold? Some people are in favor of this, but I don't see the upside of formally allowing it. (People are going to do it to some degree anyway.) I think it's too early to have good decision arguments about what to do about this. The wealthy (meaning: can afford to pay $10/month for an address) will have an address no matter what. The supply is limited but so is the demand, it certainly will be interesting to see what an IP address is really worth. My take on it is that we have to wait a year or so and see how the black market develops and how bad it is. Generally speaking, the addresses already are where the money also is; unless dramatic socio-economic changes happen I don't see much movement there. The demand is not how many people want IP addresses; the demand is how many people want addresses times how much they can spend on one. Also, some governments might actually like the double-NAT idea, as it somehow restricts free flow of information and might appear more controllable. Noel Chiappa wrote: Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. I don't think the market decided it was superior. The market decided it was good enough, cheaper, and easier. Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. I agree with Noel here. Michel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
On 10-apr-2006, at 16:35, Noel Chiappa wrote: Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. That's the popular view. In reality, people deployed NAT mostly for reasons that have little to do with the global IPv4 address depletion. And IPv6 hasn't been ready for any kind of deployment until the early 2000s. I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), The future just doesn't want to honor the principle of least astonishment: what we expect to change, often stays the same, while what we expect to stay the same, more often than not changes. Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. Everyone who thinks that regular users are going to forego IPv4 connectivity in favor of IPv6 connectivity as long as IPv4 still works to a remotely usable degree is a card carrying member of the Internet Fantasy Task Force*. For now, the usability of IPv4 is relatively constant while that of IPv6 is much lower, but steadily increasing over time as IPv6 support in hard- and software increases in quantity and quality. Assuming that the people who get all those millions of IPv4 addresses every year actually use them for something, like connecting new customers, in 4 to 8 years, something will have to give. I don't think the big change will be in the demand side, as we see that countries with several IPv4 addresses per capita (even without legacy /8s) are still using up new ones while other countries have a lot of catching up to do, and more IP devices seems likely for just VoIP if nothing else. (I've made a new page that shows addresses per capita: http:// www.bgpexpert.com/addressespercountry.php There are actually several countries that have a factor 1000 fewer IPv4 addresses per capita than the US and a factor 10 is fairly common even in Europe.) I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Well, the IETF has done its job by creating IPv6, so whatever happens, we should be in decent shape. Soon enough we can turn our attention to the fact that we're still doing our interdomain routing with RIP on steroids. (-: Iljitsch * coined by Tony Hain ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Noel Chiappa wrote: Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. Wasn't there a thing called ISO or OSI? The think that was meant to revolutionize the internet. I still have my ISODE kit running on my old machines that probably never will run IPv6. ISODE could seamlessly run over IPv4 and directly on the ISDN interface. Only today ISDN runs over IPv4 itself :) I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), so I have no specific prediction to make, but... Exactly here thems to be IPv6 biggest problem. The people playing with IPv6 could not but connect via IPv4 tunnels. Nobody had a clue about routing. In the old 3fff:: network network1/64 was in Stockholm, network2/64 in Newyork, network3/64 in Stockholm again and so on. This was not a problem because everybody was connected by point-to-point links and the routing was done by IPv4. Now they have changed to the 2001:: network but they still have no clue about the routing issues at all. To make things worse site local IPv6 addresses were deprecated. So you dont have a chance to number your machines locally and play with IPv6 for learning. You have to get an official /64 network to run your site. Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Noel The chinese internet with its own root and TLDs like XN--55QX5D, XN--FIQS8S, XN--IO0A7I and the Great Firewall Router is researching into TUBA and I dont beleave we will like the outcome. Every dictator will like it. Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
--On Monday, 10 April, 2006 19:31 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: ... Everyone who thinks that regular users are going to forego IPv4 connectivity in favor of IPv6 connectivity as long as IPv4 still works to a remotely usable degree is a card carrying member of the Internet Fantasy Task Force*. Because I think part of this comment is important, I want to disagree with part of the statement. The gating factor isn't just works to a remotely useable degree. It is also a matter of cost. Especially at the regular user end of the market, decisions are typically very cost-sensitive. So, let's assume that I'm an ISP and (i) I discover that I've switched to IPv6 to avoid needing to use private addressing in my core network, (ii) I discover that it is now costing me more to support IPv4 customers (because they require protocol and address translation gateways, even with 4-to-6 and similar schemes) than it does to support native IPv6 customers. (iii) I decide to start passing those costs along to the IPv4 users, maybe even disproportionately to get people to migrate. Or suppose that, as an ISP, I decide I want to save IPv4 addresses for my big-bucks customers and hence to force those regular users to pay the big bucks to keep using IPv4. Now, at least two things impact whether migration occurs at that stage. One is whether there are still effective options for IPv4 at a sufficiently low differential price point to justify a switch in providers. How large that differential would need to be is pretty much speculation -- far harder than predicting the future of address space exhaustion. And it is complicated by the question of how much choice of providers that regular user actually has -- in many areas, the answer is not a lot of choices. The second is whether IPv6 is really good enough to deliver services (at the applications layer, which is all those regular users care about) that are roughly as good, and as complete as set, as the IPv4 services.It is there that I think we are in trouble with regard to hardware, support costs, tutorial information, etc. But it isn't just still works well enough ... there are some incentives that can be applied here and that some might claim are inevitable that might cause a regular user shift on a purely economic basis. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
it certainly will be interesting to see what an IP address is really worth.It is worth about the same as a postal address that comes naturally when they build a new house.In a similar waywhen a new device comes to existence it gets an address out of infinite universe of 0 and 1. Theactual cost driver here is aneed for an operator (e.g. Postal Service or ISP) to maintain a list of all existing addresses to be able to provide their services.Technically IP address isan enabler of a servicerather thanthe service itself such as e.g. delivery ofa message from A to B.As such addresses should not be sold or rented,they just come with devices. IP addresses, in particular IPv6 ones,ismore a common good that we all share such as air rather then an itemproduced for sale by someone who incurres costs during production.[EMAIL PROTECTED] Michel Py [EMAIL PROTECTED] wrote: Iljitsch van Beijnum wrote: The problem is that nothing matches historical growth, because it contains elements that have proven resistant against modeling.That's the way I see it myself. Until that time, I'll continue to assume 2010 - 2015 with 2012 as the most likely moment for IPv4 to run out.In the big scheme of things, I actually don't see what it changes toknow the exact date now anyway. We only get to cry wolf so many times.And we have cried a lot over the last 10 years (including doompredictions over Y2K). As of today I don't see people doing anythinguntil they actually see the wolf. And I think they won't even doanything then until the wolf proves to be a big annoyance, which remainsto be seen. When we run out of IPv4 space obviously very many people will have IPv4 addresses and they'll want to keep using them.Indeed. And in the case of the US (and to a lesser extent otherindustrialized countries) 3 to 4 addresses per capita are enough for avery long time. It is possible that the US will remain a v4 dealforever, as many Americans are not interested in what happens elsewherein the first place.To me, the interesting thing is not WHEN it will happen; it's WHAThappens when it does and what we can do about it. There is however and interesting policy question: should we allow IPv4 addresses to be sold? Some people are in favor of this, but I don't see the upside of formally allowing it. (People are going to do it to some degree anyway.)I think it's too early to have good decision arguments about what to doabout this. The wealthy (meaning: can afford to pay $10/month for anaddress) will have an address no matter what. The supply is limited butso is the demand, it certainly will be interesting to see what an IPaddress is really worth.My take on it is that we have to wait a year or so and see how the blackmarket develops and how bad it is. Generally speaking, the addressesalready are where the money also is; unless dramatic socio-economicchanges happen I don't see much movement there. The demand is not howmany people want IP addresses; the demand is how many people wantaddresses times how much they can spend on one. Also, some governmentsmight actually like the double-NAT idea, as it somehow restricts freeflow of information and might appear more controllable. Noel Chiappa wrote: Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6.I don't think the market decided it was "superior". The market decidedit was good enough, cheaper, and easier. Don't be surprised if the world, facing "complete exhaustion of the IPv4 address space (Version 2)" decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround.I agree with Noel here.Michel___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1/min.___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
To make things worse site local IPv6 addresses were deprecated. So you dont have a chance to number your machines locally and play with IPv6 for learning. You have to get an official /64 network to run your site. But now you have Locally Assigned Local Addresses and if you do the right thing choosing your prefix then you can usually connect multiple sites together without having to renumber one of them. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
From: Noel Chiappa [mailto:[EMAIL PROTECTED] I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. It's a free market qualified by force majeur. So for example there are a number of Class A domains which would probably fetch a significant sum if put up for open auction. As address space scarcity begins to bite IP address squatting will become profitable (at present it is not). More people will stock up on addresses anticipating scarcity. The problem here is that there are also parties that might decide that $10 million (or whatever) is rather a lot to pay for the privillege of talking to (say) net 18 and simply start injecting the relevant routes. This is an unacceptable outcome of course but the threat is sufficient to lower the price of involuntary recycling of address space. The only prediction I think can be made with confidence here is that whatever the choice made it is not going to be a pretty one. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Iljitsch van Beijnum writes: That's the popular view. In reality, people deployed NAT mostly for reasons that have little to do with the global IPv4 address depletion. They deployed it mainly because getting an IPv4 address costs money, and involves considerable red tape. Mainly because it costs money. The future just doesn't want to honor the principle of least astonishment: what we expect to change, often stays the same, while what we expect to stay the same, more often than not changes. Yes, this is the problem faced by all futurists, including those who work in IT. The only thing that one can reliably predict is the unknown. Everyone who thinks that regular users are going to forego IPv4 connectivity in favor of IPv6 connectivity as long as IPv4 still works to a remotely usable degree is a card carrying member of the Internet Fantasy Task Force*. Yes. Even I don't plan to do so unless my ISP forces the issue; the change would bring me nothing and would cost time and money to implement. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
John C Klensin writes: So, let's assume that I'm an ISP and (i) I discover that I've switched to IPv6 to avoid needing to use private addressing in my core network, (ii) I discover that it is now costing me more to support IPv4 customers (because they require protocol and address translation gateways, even with 4-to-6 and similar schemes) than it does to support native IPv6 customers. (iii) I decide to start passing those costs along to the IPv4 users, maybe even disproportionately to get people to migrate. Or suppose that, as an ISP, I decide I want to save IPv4 addresses for my big-bucks customers and hence to force those regular users to pay the big bucks to keep using IPv4. Plausible so far. Now, at least two things impact whether migration occurs at that stage. One is whether there are still effective options for IPv4 at a sufficiently low differential price point to justify a switch in providers. How large that differential would need to be is pretty much speculation -- far harder than predicting the future of address space exhaustion. And it is complicated by the question of how much choice of providers that regular user actually has -- in many areas, the answer is not a lot of choices. In the areas that make the heaviest use of the Internet, there will be many choices, and the only ISPs able to get away with an IPv4 surcharge will be the last ones to support IPv4. The first one to attempt a surcharge will inevitably lose customers. The second is whether IPv6 is really good enough to deliver services (at the applications layer, which is all those regular users care about) that are roughly as good, and as complete as set, as the IPv4 services.It is there that I think we are in trouble with regard to hardware, support costs, tutorial information, etc. There will also be trouble if someone decides to use IPv6 services that were never available in IPv4, and discovers that the rest of the world is still not on IPv6. The interesting thing is that the last part of the world to move to IPv6 will probably be the part that has the most IPv4 addresses ... that is, the United States. So anyone with IPv6 will have trouble dealing with hosts in the United States, and that will not help adoption of IPv6. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
Peter Sherbin writes: It is worth about the same as a postal address that comes naturally when they build a new house. In a similar way when a new device comes to existence it gets an address out of infinite universe of 0 and 1. That would only be true if IP addresses were geographically assigned, which they aren't. You know, you could assign IPv6 addresses in a strictly geographic way and you'd have more than enough for everyone, everywhere, with very simple routing. But of course that won't be done. The actual cost driver here is a need for an operator (e.g. Postal Service or ISP) to maintain a list of all existing addresses to be able to provide their services. Not necessarily. If the addressing is strictly geographic--n addresses for each area of m square metres on the planet--routing would be very simple and wouldn't require much in the way of tables. With 78 bits, you can address every millonth of a second of arc in latitude and longitude on the planet. That's an area of about 0.00095 square millimetres. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Reality (was RE: Stupid NAT tricks and how to stop them.)
Instead of dissecting the numbers into chunks that give you the answer you want, how about looking at the big picture? http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf shows the IANA to RIR on the top line (updated through 7-Apr-06), with the next line being the sum of the RIRs going out (yes it is smoother than the IANA line, but they do track closely in the big picture). Note that the combined RIR pool is tracking policy since the output side total matches the input side from IANA about 18 months ago (individual RIR rates may vary). It is also interesting to note that recently the RIRs are handing out address blocks faster than they are acquiring them because the gap in the projections of the top two lines narrows over time. Another interesting issue is the recent overall growth rate for RIPE handing out address blocks is significantly faster than any other (despite the large blocks in ARIN APNIC), while Geoff's numbers in the BGP space show that APNIC region customers are announcing what they get at a faster rate than RIPE region customers. Are these blocks that will never show up in the routing system, or is there some reason that it takes longer to deploy space in Europe? Also note that ARIN APNIC have approximately the same growth rates. The real issue is that Geoff's linear projections against the current .75 /8's per month going out from the RIRs to hit a 2012 date don't match the historical growth. Also, taking a very short term view creates misleading windows that lead to claims like yours that we are now on a slower pace than last year, so not to worry. While the graph does show that we were above the projection curve last year and below it so far this year, the overall trend since Jan 2000 is tracking the projection very tightly. Changing the RIR policy is a hopeless cause. This would have to be a simultaneous global change and the process for getting global agreement takes at least 2 years (as shown by the only global agreement they have; IPv6 policy, and the much longer time it is taking to debate changes to it). By the time anything could be done there wouldn't be enough left to worry about. You are correct that we don't know what will happen in the future. Unrealistically long projections don't serve anyone except those who look for solace in the fantasy land where nothing changes. The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. By the time any new work items make it through the process there will not be any new IPv4 space to deploy it. Tony -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 2:23 AM To: Tony Hain Cc: 'Austin Schutz'; [EMAIL PROTECTED]; iab@iab.org; 'Keith Moore'; ietf@ietf.org Subject: Re: Stupid NAT tricks and how to stop them. On 29-mrt-2006, at 2:17, Tony Hain wrote: In the past 10 years, there have been several years where the growth of the growth was less than the year before: 1996 19971998199920002001200220032004 2005 2.71.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5 (The numbers represent the number of addresses used up in that year as a percentage of the 3.7 billion total usable IPv4 addresses.) Part of the problem here is that the allocation bundles don't map well into nice clean annual buckets. It is the overall trend that matters, not the fact that any given year had a higher or lower growth rate. That's why I prefer to look at the RIR-ISP figures rather than the IANA-RIR figures. I have a few scripts on my server to download the statistics from the RIR FTP sites and parse them. (Have a look at http://bgpexpert.com/addrspace.php if you want to peruse the numbers yourself.) This is what the RIRs gave out the past few years: 78.24 M 2000 89.07 M 2001 68.97 M 2002 87.82 M 2003 128.58 M 2004 168.53 M 2005 35.14 M 2006 This basically means that unless things take a radical turn, the long- term trend is accelerating growth so that remaining 40% will be gone in less than 9 years. Probably something like 7, as Geoff Huston predicts. While the exact date of exhaustion is impossible to predict, Geoff's 2012 target is presented to placate those in serious denial. The fundamental burn rate has been compound growth since 2000, and there is no reason for it to slow. Look above. 35 million this quarter so far means we're going to end up below last year's 168 million unless things _really_ start cooking the next quarters. If you drill down a bit more we're
Re: Stupid NAT tricks and how to stop them.
Anthony G. Atkielski wrote: ATT used to charge for any telephone color other than black, even though the cost of producing a telephone was the same no matter what color it was. ATT also used to charge for additional private IP addresses. I remember one company had a bussiness package with them and was also leasing a router that came locked down and configured to use 192.168.0.0/27 on the LAN. When this company wanted more IP's internally ATT wanted to charge them more to "upgrade" them to a 192.168.0.0/24 John- I agree that no IPv6 solution involvingcustomers giving up the (percieved?) freedom of NAT for a construct that has them suckling from their ISP's tit again is really going to go over well. One small note also aboutthe ISP supplied modem - at least in my experience in Los Angeles -the basic modems I've seen act solely as a pass-through (they have no configuration menus -etc). I know today modem/home networking in a box devices are being pushed (because the ISP's charge extra for it), but the basic end user is getting no bells and whistles -(at least with SBC, Verizon, and Comcast). FWIW-(which isn't much), IMO people like NAT because it lets them do what they want without paying more or getting permission. Cause I think thats really all they want from any solution. nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
FWIW-(which isn't much), IMO people like NAT because it lets them do what they want without paying more or getting permission. Cause I think thats really all they want from any solution. ISP fees for additional addresses just leveraging an opportunity to extract a few more dollars. The opportunity stems out of: 1) a notion of leased addresses, i.e. addresses have to be returned back when a customer leaves ISP 2) a percieved scarcity of IPv4 addresses. Overall it goes all the way back to IANA allocation policy preserving the internet hierarchy. In theory IPv6 provides enough addresses for everyone. How to make sure that addresses are not wasted? Immediate answer - get addresses through your LIR. Apparently quite a lot of people would want to become LIR for themselves. At some point we may start considering e.g. UN sponsored IP address registrars allocating x-amount of IP addresses to each individual and establishment on the planet and managing such allocation. Peter Sherbin, [EMAIL PROTECTED] --- [EMAIL PROTECTED] wrote: Anthony G. Atkielski wrote: ATT used to charge for any telephone color other than black, even though the cost of producing a telephone was the same no matter what color it was. ATT also used to charge for additional private IP addresses. I remember one company had a bussiness package with them and was also leasing a router that came locked down and configured to use 192.168.0.0/27 on the LAN. When this company wanted more IP's internally ATT wanted to charge them more to upgrade them to a 192.168.0.0/24 John- I agree that no IPv6 solution involving customers giving up the (percieved?) freedom of NAT for a construct that has them suckling from their ISP's tit again is really going to go over well. One small note also about the ISP supplied modem - at least in my experience in Los Angeles - the basic modems I've seen act solely as a pass-through (they have no configuration menus -etc). I know today modem/home networking in a box devices are being pushed (because the ISP's charge extra for it), but the basic end user is getting no bells and whistles -(at least with SBC, Verizon, and Comcast). FWIW-(which isn't much), IMO people like NAT because it lets them do what they want without paying more or getting permission. Cause I think thats really all they want from any solution. nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Anthony G. Atkielski wrote: John Calcote writes: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. It is unlikely that ISPs will ever offer static IPs or multiple IPs to home users at any time in the future for free. They will continue to charge heavy premiums for such professional features, with or without IPv6. http://www.manitu.de/ They offer you: fixed IPv4 address with reverse lookup at 9.99 Euros per month. You must have already T-DSL to use this servevice and you will keep that. Means the 9.99 Euros get you a second PPPoE link over your old modem and you can have a fixed plus a dynamic IPv4 address at one and the same time. t-online.de offer a similar service but it is more expensive. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Peter Dambier writes: http://www.manitu.de/ They offer you: fixed IPv4 address with reverse lookup at 9.99 Euros per month. I don't live in Germany. The exception does not disprove the rule. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
From: Michel Py [mailto:[EMAIL PROTECTED] Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. When not even those of us who can differentiate between different Internet connections by other means then speed can manage to get a proper Internet connection (e.g. with multiple fixed addresses), how can we expect regular users to ask for such advanced features? Myself, I am stuck with a telco-ISP that do not even provide the option to buy extra IP-addresses (or fixed addresses). This means I am forced to run a NAT at home, and do the tricks to make applications work in this environment (including making servers work, which of course is not allowed, but why should I care). At several occasions, friends have asked me why some of their communications applications do not work although they have a premium Internet connection, which meant they had purchased the highest speed available. Unfortunately, they have all been fooled by the ISPs that the only difference between different Internet connections is the maximal throughput, and they have ended up in a crappy NETed home environment. But why should ISPs be honest and explain to regular users that there could be better alternatives and that what they are currently selling is a restricted Internet connection? For ISPs, these restricted connections means users have problems running some applications, which reduces the traffic they generate, but the problems users have are not attributed to limitations in what the ISP provides. Only some ISP's openly declare the details of the Internet connections they provide, such as whether IP addresses are fixed or dynamic, if one can get multiple addresses, if IPv6 can be provided, etc. However, some do, and therefore I still believe there is hope, but it is hard for regular users to understand what different alternatives would mean (especially when ISPs are not honest with these matters). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Lars, Michel Py wrote: Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. Lars-Erik Jonsson wrote: I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. For ISPs, these restricted connections means users have problems running some applications, which reduces the traffic they generate. This does not hold water either. By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. When ISPs want to curb traffic, they either: cap the speed, have monthly quotas, or (rarely, as it will result in loss of business) enforce their AUP. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-Apr-2006, at 11:09, Michel Py wrote: Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. A survey of users where? Arguments which shuttle backwards and forwards between people in regions with different packaging of internet access services are unlikely to bear fruit so long as the arguments concentrate on assumptions about packaging. Different ISPs package access in different ways. Some do the NAT for you, in their network; some do the NAT in the CPE equipment they supply; some don't do NAT for you at all. Some ISPs provide only dynamic addresses, and distinguish their packages based on speed; some ISPs have the option of static addresses, but only one per subscriber; some ISPs can assign a subnet to a customer. Some ISPs package their access services according to peak speed available; some according to a contention ratio within their network (or within the telco's network which they use to reach the customer). Some ISPs provide a data cap. Some ISPs charge for volume. Some ISPs restrict access speed when a volume threshold within a billing period has been reached. Some ISPs bill according to data transferred; some ISPs bill at a flat rate. Some ISPs filter traffic towards their customers; some don't. Some ISPs (apparently, possibly) deliberately introduce jitter and latency into their access products to discourage customers from using VoIP. Others don't. Some ISPs are happy for people to run servers; some are not. Some ISPs are happy for customers to announce their own address space to them over DSL using BGP (I know this, since I am a customer of one of them). Some ISPs sell symmetric access services; others sell asymmetric services. Some use cable; some use DSL; some use fibre; some use wireless transmission; some use frame-relay or PPP or HDLC over synchronous T1s or E1s. Some ISPs compete for customers in an open market. Some ISPs don't need to, because they have a natural monopoly in access. Some ISPs have access to the copper; some ISPs are dependent on wholesale products of telcos, and are perhaps limited in what they can provide for that reason. It's a rich tapestry. Assuming that what is available in one region implies anything about what is available in other regions is unproductive. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Michel Py wrote: Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. Joe Abley A survey of users where? Of anywhere where ISPs offer a package with static IP addresses. I mean a survey of regular customers, not fellow IETFers or geek buddies. How many of them actually have multiple static IPs and how many are behind NAT nevertheless. Run your survey and come back with data. It's a rich tapestry. It is. Assuming that what is available in one region implies anything about what is available in other regions is unproductive. Assuming that IETFers and their ideas on how to configure a network are representative of the general consumer base is ignoring this rich tapestry. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-Apr-2006, at 12:16, Michel Py wrote: Of anywhere where ISPs offer a package with static IP addresses. I mean a survey of regular customers, not fellow IETFers or geek buddies. How many of them actually have multiple static IPs and how many are behind NAT nevertheless. Run your survey and come back with data. I was under the impression that *you* were the one making assertions about user behaviour. I don't necessarily disagree with them. However, asking other people to do surveys to confirm your assertions (with the implication that people who can't be bothered to do those surveys somehow aren't fit to disagree) seems more like an exercise in rhetoric than in engineering. On 5-Apr-2006, at 11:09, Michel Py wrote: [...] Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. [...] By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. When ISPs want to curb traffic, they either: cap the speed, have monthly quotas, or (rarely, as it will result in loss of business) enforce their AUP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 08:09 -0700 Michel Py [EMAIL PROTECTED] wrote: Michel Py wrote: Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. Lars-Erik Jonsson wrote: I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. It is worth noting in this context that many of the Router products that are sold for SOHO use (including the high-end products from the first two vendors listed above) do not provide any support for multiple static addresses except via one-to-one NAT. It is simply not possible to configure those devices to support use of static public addresses for hosts on the LAN side. This situation would somewhat contaminate the results of the survey you suggest above. These are not ISP-imposed limitations, but limitations imposed by commercially-available products. It also suggests, again, that part of the current drive by vendors to support NAT is not because of address shortages but by support and configuration difficulties with providing and using small pools of provider-dependent static addresses. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
John C Klensin wrote:
It is simply not possible to configure those devices
to support use of static public addresses for hosts
on the LAN side.
First, this is totally false, see below. Second, if you want to use
public IPs on the LAN side you just have to plug your hosts directly in
the back of the {DSL|whatever} modem. Or use the firewall of your
choice.
This situation would somewhat contaminate the results
of the survey you suggest above.
Not at all, see above. Plus, read below also.
It is worth noting in this context that many of the Router
products that are sold for SOHO use (including the high-end
products from the first two vendors listed above) (Linksys,
Netgear) do not provide any support for multiple static
addresses except via one-to-one NAT.
This is simply NOT true. Large numbers of SOHO routers can operate
with or without NAT and yes including the high-end products from the
first two vendors listed above.
Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318: http://www.netgear.com/products/details/FVG318.php
And this is the norm. The one I use right now:
http://www.broadxent.com/products/8120.asp
and many more:
http://www.sonicwall.com/totalsecure/ts10.html
http://www.netopia.com/equipment/routers/routers_models.html
I have seen some of the speedstreams too and they all had an option to
run with or without NAT. Many of them also have the option to have a
bridge mode allowing the customer to provide their own router/firewall
solution.
These are not ISP-imposed limitations, but limitations
imposed by commercially-available products.
Please stop spreading disinformation. The proof is in the pudding, just
click on the links above. Maybe actually looking at what's out there
would help too.
Michel.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-apr-2006, at 17:09, Michel Py wrote: By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. This sounds a lot like NAT doesn't really break anything. If I pretend I'm a regular user for a minute, I can tell you this is not the case. When I used NAT for my Powerbook I had lots of problems doing videochats with Apple's iChat with someone else who was also behind NAT. Even when I configured the single real IP address I got on my Powerbook (very tricky because there was a Cisco SOHO box terminating a PPPoA ADSL link in the middle) it still didn't work very reliably. RTSP with Quicktime didn't work when the Cisco 82x did the NATting, but it would when an Apple Airport Extreme performed NAT. Peer-to-peer isn't a good example, because of the high built-in redundancy. Even someone who can only set up outgoing sessions can run BitTorrent without too much trouble because there are plenty of peers without NAT or portmappings of some kind (manual, uPnP or NAT- PMP) that can receive the incoming sessions. When the sessions are up, traffic can flow both ways. However, if you read forums or release notes you'll see lots of discussion on port mapping because being able to receive incoming session setup attempts means that you get to connect to more peers (all of them, without port mapping only others that are not behind NAT or do have port mapping) so your downloads are faster. Given the market place realities the IETF should be careful to make its protocols interoperate with NAT whenever possible, but don't think for a minute that adding NAT workarounds solves the problem completely. Here in the Netherlands ISPs generally give out a single real IP address to their customers, but most customers use a DSL or cable modem with NAT or an additional NAT router or wireless base station so they can connect more than one computer. Despite some individual reports to the contrary, I believe the same is true for most IP users. However, some ISPs already perform NAT for their customers in their network, and that's only going to increase as IPv4 addresses become more scarce and eventually run out completely. At that point, many people will be behind two layers of NAT. Also, reserving ports will be very hard because many systems share one real IP address. Maybe it's just me, but I don't see the IETF or anyone else for that matter coming up with something that allows communication between two people who are both behind two layers of NAT with any modicum of reliability. So in addition to supporting NAT where reasonably possible, the IETF should also continue to plan for a future where there is enough address space to make NAT unnecessary. However, universal reachability isn't coming back even if NAT is out of the picture because people love to run firewalls that break way more stuff than intended. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 11:23 -0700 Michel Py
[EMAIL PROTECTED] wrote:
John C Klensin wrote:
It is simply not possible to configure those devices
to support use of static public addresses for hosts
on the LAN side.
First, this is totally false, see below. Second, if you want
to use public IPs on the LAN side you just have to plug your
hosts directly in the back of the {DSL|whatever} modem. Or use
the firewall of your choice.
Michel, spreading disinformation is a rather strong claim; not
one I would choose to make without actually examining the
devices and their manuals, not just the marketing descriptions
you cite below. That said, I did somewhat oversimplify the
problem I described. More detail, and a pair of partial product
reviews, follows below. If I owe the vendors an apology, I will
apologize, but I will do so only in the presence of either
vendor documentation of how to do what is needed (user manual,
knowledge base article, or the equivalent) or a user-level
description of how to do it that the vendors will support. See
below.
This situation would somewhat contaminate the results
of the survey you suggest above.
Not at all, see above. Plus, read below also.
It is worth noting in this context that many of the Router
products that are sold for SOHO use (including the high-end
products from the first two vendors listed above) (Linksys,
Netgear) do not provide any support for multiple static
addresses except via one-to-one NAT.
This is simply NOT true. Large numbers of SOHO routers can
operate with or without NAT and yes including the high-end
products from the first two vendors listed above.
Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318:
http://www.netgear.com/products/details/FVG318.php And this is
the norm.
Our experience differs, but this is not disinformation. I'm
running an RV082 (the 042's bigger and more capable sibling)
here and consigned an FVG318 to the parts closet before getting
the RF082.In both cases, I bought the products at retail and
struggled for some weeks, reading manuals and using the vendor's
customer support mechanisms and, in the RV082 case, taking
advantage of some additional support resources before reaching
the conclusions that I reached.
At least part of the problem are some constraints that, as a
simplification, I didn't mention. The two most recent ISPs I've
dealt with personally, and two more I've deal with on behalf of
friends I was trying to set up, all insist on owning control of
the front-end CPE modem/ router equipment. They do not
permit (by TsCs, password control, etc.) the customer to
reconfigure that equipment to, e.g., operate it in bridge mode.
The number of static addresses available or in use is quite
small, typically a /28 or even a /29. Finally, I need a device
with the ability to specify port priorities and to supply some
firewall capability.
One implication of this is that there is a little problem of
router co-existence: the customer-supplied device has to be
plugged into the LAN side of the ISP-supplied device, using one
of those static addresses as its WAN-side but supplying the
others to devices on the actual LAN. In principle, it ought to
be possible to do that by setting up static routes, but (i)
neither vendor was able to specify how to do it and (ii) some,
if not all, of the ISPs configure their interface devices to
require that different addresses appear on the different ports
they supply.
For both of these vendors can use static addresses in
marketing literature apparently mean that one can use a static
address on its WAN side and can turn DHCP off, or run DHCP with
MAC-mapped addresses, on the LAN side. Both support those
capabilities; the problem is where the addresses come from.
Actual experience with trying to set the devices up with a
static /29 pool of public addresses used on the LAN side of the
device and with the same pool presented to and used from the
public Internet were unsuccessful.
Disclaimer about the Netgear box: I haven't tried to use it with
static, public addresses for well over a year. Perhaps new
firmware and documentation has been released and it has been
changed to better support these functions. I doubt it somehow,
but perhaps.
In the case of Netgear, there is not a hint in any of the
documentation, or in their knowledge base as of a year or so
ago, that use of public addresses is possible. After an
extended discussion with their technical support operation (and
an escalation or two), I was told that the device would not
support what I needed (i.e., public addresses on the LAN
identical to the public addresses by which the Internet saw
those hosts, with no NAT function of any sort) and that, if I
could trick it into doing what I was asking for, they would not
support it. That led to a discussion about how they could
claim support for static, public, addresses, but that discussion
didn't lead anywhere.
In the case of the Linksys device, the
RE: Stupid NAT tricks and how to stop them.
-John Calcote ([EMAIL PROTECTED])Sr. Software EngineeerNovell, Inc. John C Klensin [EMAIL PROTECTED] 4/5/2006 10:43:36 am --On Wednesday, 05 April, 2006 08:09 -0700 Michel Py[EMAIL PROTECTED] wrote: Michel Py wrote: Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them.It is worth noting in this context that many of the Routerproducts that are sold for SOHO use (including the high-endproducts from the first two vendors listed above) do not provideany support for multiple static addresses except via one-to-oneNAT. It is simply not possible to configure those devices tosupport use of static public addresses for hosts on the LANside. This situation would somewhat contaminate the results ofthe survey you suggest above.These are not ISP-imposed limitations, but limitations imposedby commercially-available products. -- I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most "bang for the buck", so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... The fact is, _when_ IPv6 becomes truly mainstream and ISP's begin to offer multiple static addresses because they can, then these companies will offer the features on their routers. Let's not mistake what the world wants, for what it is successfully living with today. John BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote EMAIL;WORK;PREF;NGW:[EMAIL PROTECTED] N:Calcote;John ORG:;Unified Identity System Eng TE TEL;WORK:1-801-861-7517 TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:John Calcote=0A= PRV-H-511=0A= Provo END:VCARD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-apr-2006, at 21:57, John C Klensin wrote: they all had an option to run with or without NAT. Many of them also have the option to have a bridge mode allowing the customer to provide their own router/firewall solution. It is that bridge mode that is critical. As I indicated above, neither the Linksys nor the Netgear devices provide it. The SonicWall does, but raises other, unrelated, issues. I carefully did not address any devices I haven't actually used. That leaves us in a state in which it is necessary to handle static public IP addresses by either * running the ISP's interface device in bridge mode, which many (although perhaps not all) ISPs prohibit * running the router devices as one-one NATs It occurs to me that there is nothing that prevents this exact same issue from coming up in IPv6. Even with an unpronouncable number of addresses, if you provide your own box that performs routing (which is generally a requirement for any kind of firewalling), the ISP has set up an address range to communicate with that box, and another address range that it forwards to that box for use behind it. I.e., if the ISP provides a CPE box under their control and I have my own router/firewall, then I need a subnet between the two and at least one more subnet on another port of my router/firewall where my hosts reside. The first issue is that this makes getting a single /64 from the ISP useless, and the second issue is that either there needs to be some manual configuration or there needs to be some kind of address provisioning protocol to be run between the CPE and the customer router/firewall, such as DHCPv6 prefix delegation. (Note by the way that PPP can do address provisioning for a single address in IPv4 but it can't do this for IPv6, making stuff like IPv6 over dial-up extremely hard to do.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
At 11:23 AM -0700 4/5/06, Michel Py wrote: John C Klensin wrote: It is simply not possible to configure those devices to support use of static public addresses for hosts on the LAN side. First, this is totally false, see below. No, it is *partially* false, but unfortunately true in many cases. Some SOHO devices allow to use the outside IP addresses on the inside, and some don't. More importantly, some that say they allow you to turn off the NAT don't actually work. In the VPNC test lab, we have found some SOHO systems (from more than one vendor, based on code from more than one OEM) where turning off the NAT using the GUI didn't do anything: the NAT was still in force. The vendors had to fix their software before they could continue with our testing because we explicitly do not test with NATs (except for our upcoming testing of IPsec NAT-traversal interop). The VPNC members were fairly happy to have discovered sooner rather than later that their NAT configuration was not what they thought it was. They were not happy to have to fix their code, of course, but it is better to have to do so early in the shipping cycle before the customer support calls come. On the other hand, one vendor who has a series of boxes that cannot have their NATs turned off said that they essentially never get complaints about it, even though the always-NAT-no-matter-what feature is not listed on the box. Assuming that the system documentation is correct in this area is not a good idea, at least from the hands-on experience in our lab. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 22:24 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 5-apr-2006, at 21:57, John C Klensin wrote: they all had an option to run with or without NAT. Many of them also have the option to have a bridge mode allowing the customer to provide their own router/firewall solution. It is that bridge mode that is critical. As I indicated above, neither the Linksys nor the Netgear devices provide it. The SonicWall does, but raises other, unrelated, issues. I carefully did not address any devices I haven't actually used. That leaves us in a state in which it is necessary to handle static public IP addresses by either * running the ISP's interface device in bridge mode, which many (although perhaps not all) ISPs prohibit * running the router devices as one-one NATs It occurs to me that there is nothing that prevents this exact same issue from coming up in IPv6. Even with an unpronouncable number of addresses, if you provide your own box that performs routing (which is generally a requirement for any kind of firewalling), the ISP has set up an address range to communicate with that box, and another address range that it forwards to that box for use behind it. I.e., if the ISP provides a CPE box under their control and I have my own router/firewall, then I need a subnet between the two and at least one more subnet on another port of my router/firewall where my hosts reside. The first issue is that this makes getting a single /64 from the ISP useless, and the second issue is that either there needs to be some manual configuration or there needs to be some kind of address provisioning protocol to be run between the CPE and the customer router/firewall, such as DHCPv6 prefix delegation. This was part of the point I was trying to make before the totally false assertion arose. The boxes can't magically a small-address-range single subnet work because making it work is tricky to do and trickier to support. If the subnet is big enough that one can plausibly throw half of it away (as might be the case with an IPv6 /64), then there is an obvious trick with subnet masks... but I believe that at least some of these router/firewall boxes won't support it. And neither many hardware vendors nor many ISPs are particularly anxious to support configurations that are tricky-- they cause (expensive for the vendor/ ISP) support calls. (Note by the way that PPP can do address provisioning for a single address in IPv4 but it can't do this for IPv6, making stuff like IPv6 over dial-up extremely hard to do.) More of the same. From my perspective, parts of this discussion, in its many repetitions and many forms, have become pointless to the level of uninteresting. Some of us believe that NATs are bad news and harmful. Others believe that NATs fall somewhere on the scale between harmless and actually good. That debate has turned into a religious war and cannot be settled -- presumed facts presented by either side are simply ignored, or rejected with claims stated in strong language, by the other. By contrast, the question of whether IPv6, by itself, will solve or eliminate NATs is one that is susceptible to engineering evaluation and, IMO, suggests work that the IETF ought to be doing. Whether we like NATs or not, we need to understand the forces that drive them and to understand that those forces are not all about address space. And, on that basis, we need to look, again IMO, at both protocols and policies to be sure that we have provided the tools for permitting those who wish to get rid of NATs to do so. If we don't know how to build, and inexpensively support, a router/firewall without address mapping, then we had better figure it out. If ISPs like NATs because they can't economically handle the perceived higher support costs of every end-user LAN having a slightly different topology, then we had better figure out how to solve the underlying problem rather than assuming that IPv6 will eliminate the NATs. If, as Iljitsch suggests, PPP (as now defined) isn't quite suitable for supporting IPv6 over dialup, then someone better be looking at fixing that -- and looking at strange-to-me setups such as PPoE in the process. And, if everyone gets a /64 really doesn't work because of outside-firewall and inside-firewall issues, we had best either figure out how to change that restriction or turn the allocation rule into everyone gets two /65s, or do something else to deal with the issues that can be standardized and built into both equipment and user manuals. Until that work is done, we, I believe, should keep our expectations about IPv6 deployment to end-user LANs very modest. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
John Calcote wrote: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... Exactly. As I said many times: vendors sells what the market wants to buy, and IETFers do not make the market. John, John C Klensin wrote: spreading disinformation is a rather strong claim; not one I would choose to make without actually examining the devices and their manuals, not just the marketing descriptions you cite below. I have personally configured non-NAT on a least a dozen different of these boxes. At least part of the problem are some constraints that, as a simplification, I didn't mention. I can see that now, but your original text said nothing. The two most recent ISPs I've dealt with personally, and two more I've deal with on behalf of friends I was trying to set up, all insist on owning control of the front-end CPE modem/ router equipment. They do not permit (by TsCs, password control, etc.) the customer to reconfigure that equipment to, e.g., operate it in bridge mode. Common issue, then ask the ISP to reconfigure it in bridge mode themselves. If the contract says you get public IPs this means these IPs available for your hosts, not for their router. I never had an ISP refuse to do this, it's quite easy at time of installation to call the sales droid and tell it that if they don't configure their stuff to deliver your public addresses on the LAN side they can stick it. Sales droid wants his commission, sales droid talks to the techs. Other method: spend $20 on eBay for a DSL modem/router that you have control of. It is not illegal to swap their modem for yours, and if you ever have to call their support (you know, the guys that ask for 1/2 hour if the power is on and if the lights are green) just plug their modem back for the time of troubleshooting and the put yours back when done. For this very reason I kept the Alcatel aDSL modem that PacBell sold me 7 years ago although I have used at least 4 different ones. FYI, in the latest ATT (formerly SBC formerly Pacific Bell) aDSL self-install kits that they ship, the password to admin the NAT box is on a sticker underneath the box. Before, techies still knew that it was the MAC address or the serial number of the box. They actually want you to try to configure the box, mess it up, and send you a tech and bill $200 to fix it. Also, they were tired of people clogging their support to ask how to make this of that work. New method: if it does not work, see your software vendor. ISPs that survive and grow provide what their customers ask for, and admin access to the CPE device to open ports is one of these demands. The number of static addresses available or in use is quite small, typically a /28 or even a /29. In my experience, /29 is good enough for a typical home and /28 for a typical small office. If you need more you fall into the medium business category and allegedly have the $$$ that go with it. Finally, I need a device with the ability to specify port priorities Your requirements are way over the typical user. If you have requirements that represent 1% of the demand, you will not be able to use the canned solution that fits the masses. Possibly not because of technical reasons but for business reasons: vendors might think that if you have such requirements you have the money to pay for them (which is partially justified by higher support costs). If you don't find what you need in el-cheapo mass-produced consumer stuff it's not because vendors are trying to screw you but because your business does not represent enough money for them to take action. and to supply some firewall capability. There is no cheap firewall solution unless you call firewall what comes with a $20 NAT box. In the case of the Linksys device, the documentation is fairly clear that the address space on the WAN-side needed to be disjoint from the address space on the LAN-side. This is the case also for many others even high-end ones such as the Cisco PIX firewall (last time I checked). Your requirements are different than the masses, you have to use the box that fits your requirements. The fact that very few firewalls support bridging is simply due to the lack of demand. A solution to this is that either the ISP-supplied CPE or the internal router device operate in bridge mode. Indeed and I do acknowledge that many firewalls do not, which I found myself to be a pain. But you still have two avenues: 1. A router/firewall
Re: Stupid NAT tricks and how to stop them.
John Calcote writes: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. It is unlikely that ISPs will ever offer static IPs or multiple IPs to home users at any time in the future for free. They will continue to charge heavy premiums for such professional features, with or without IPv6. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... SOHO users probably won't be willing to pay 500% more for multiple or static IPs, anyway. The fact is, _when_ IPv6 becomes truly mainstream and ISP's begin to offer multiple static addresses because they can ... ISPs can do that already, but they charge a great deal for it, and they probably always will. ATT used to charge for any telephone color other than black, even though the cost of producing a telephone was the same no matter what color it was. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Iljitsch van Beijnum wrote: you can make it do IPv6 NAT. Simple client-server protocols such as HTTP worked without incident as expected. However, I also tried FTP, which really isn't that bad as NAT-breaking protocols go. It didn't work because the server saw an illegal EPRT request. In IPv4 with NAT that wouldn't have happened because: 1. The FTP client would have used EPSV in order to be NAT-friendly, or 2. The FTP ALG would have intercepted the private address and rewritten it No surprise here; exact same happened with NATv4 in the early stages. We all know that NAT requires ALGs. Moral of the story: do IPv6 NAT at your peril. Was the same with NATv4 too. Now of course it's possible to argue all of the stuff that makes IPv4 NAT work to the degree that it does today can also be added to IPv6, and that is true, strictly speaking. Especially with the experience of doing it with v4. But will the vendors bother, and will the customers require it? I don't think so. That's were you're wrong, IMHO. First, the vendors will do whatever the customers want to buy, and customers are not always smart and will have a great tendency to do just the same that worked for them with v4. Second, vendors might try to do it just to see if it sells or not. Given the existing NATv4 code base, it won't cost too much to implement NATv6 on an IPv6 capable router. These guys have sold millions of NATv4 boxes, you can bet that if they eventually release a v6 product it will have NATv6, the rationale being: - If the customer wants to use NATv6, good because then they sell the product while the competitor that does not have NATv6 does not. Just a few percent makes a difference. - If the customer does not want to use NATv6, all it costs was a few weeks of coding, well worth the risk. As Tim said: if you can live with NAT, why not stay with IPv4? That saves you several headaches and it only costs you a few IPv6 nice-to-haves such as stateless autoconf that haven't been able to get people to IPv6 anyway. Oh, I agree; but what we think might not be what the market picks. The market might pick the why not stay with IPv4 part without knowing why. Maybe to accelerate the deployment of IPv6 we should advertise: It has the same wonderful NAT you like so much in IPv4 :-D running for cover The interesting thing is that even though ISDN doesn't amount to much in the US and it's mainly used for businesses in Europe, GSM which is the biggest mobile phone technology, uses ISDN Q.9xx signalling, so ISDN was never a waste of time. But was a waste of money, at least in the US. Many telcos have invested much money into ISDN that has not brought ROI. This is one of the many reasons IPv6 does not take off in the US, because some people don't want to repeat the financial ISDN fiasco and are reluctant to invest money in technologies that they don't perceive being embraced by customers any time soon. There is a slight difference between what we do in here for the greater good of humanity and what telcos and vendors do for the greater good of their shareholders. The trouble is that if you use IPv4-compatible IPv6 addresses (in the loose sense of the word, not thinking of any RFC) for instance by having the first 96 bits of the IPv6 be zero, you get to translate between v6 and v4 transparently, but you still never get to use addresses that are longer than 32 bits, Not at the beginning, but the point is a) getting ready for it and b) backwards compatibility. In the initial stage, everyone is basically wasting bandwidth and memory to carry/store all these useless zeroes. Later on, when islands begin to implement the extended bits, they can use them internally and tunnel if the backbone is not ready. Imagine that you want to develop a high-quality audio CD. Today with IPv6, you need to have both the good old CD and the new standard. Since they are no high quality CDs available on the market and good old CD works good enough for 99% of the people, it does not take off. In this situation, the only way to market is to build a high quality audio CD reader that reads the old CDs just as good and promises to read the new ones when they eventually become available. Backward compatibility. Note that I'm not saying we should do anything about this; it's either too late or too early. I have the feeling though that the protocol that will replace v4 is not v6 but something that will feature seamless backward compatibility. BTW, Michel, you said you were about to return from the dark side in true Star Wars fashion. What gives? :-) And now, ladies and gentlemen, for your entertainment: .-. |_:_| /(_Y_)\ ( \/M\/ ) '. _.'-/'-'\-'._ ': _/.--']'--.\_ ':/_' : |::| : '.\ ': // ./ |oUU| \.' :\ ': _:'..' \_|___|_/ : :| ':. .' |_[___]_| :.':\
RE: Stupid NAT tricks and how to stop them.
Christian, What you wrote is doubly incorrect. First, you missed the context: Noel Chiappa wrote: Needless to say, the real-time taken for this process to complete - i.e. for routes to a particular destination to stabilize, after a topology change which affects some subset of them - is dominated by the speed-of-light transmission delays across the Internet fabric. You can make the speed of your processors infinite and it won't make much of a difference. Christian Huitema wrote: Since events imply some overhead in processing, message passing, etc, one can assume that at any given point in time there is a limit to what a router can swallow. This is true indeed, but a) this limit has everything to do with processing power and available bandwidth and nothing to do with speed of light and b) the context was talking about infinite processing power anyway. Bottom line, you can only increase the number of routes if you are ready to dampen more aggressively. There is no close relation. Dampening affects route that flap. If the new routes don't flap, all that is required is more memory to hold them and slightly more CPU to perform lookups but not much more as the relation between lookup time and size is logarithmic. Read below for handling routes that flap because they indeed do. There is an obvious tragedy of the commons here: if more network want to multi-home and be declared in the core, then more aggressive dampening will be required, and each of the multi-homed networks will suffer from less precise routing, longer time to correct outages, etc. Again I don't see a relation here. Assuming that the newer prefixes in the core flap about as much as the current ones, what is required to handle more is to increase computing power and bandwidth in order to keep what a router can swallow under the limit it takes a hike. There are different elements at play that also limit the number of core routers. Basically, an event in a core router affects all the path that go through it, which depending on the structure of the graph is somewhere between O(M*log(M)) or O(M.log(M)). In short, the routing load grows much faster than linearly with the number of core routers. I agree; the relation between processing power requirements and number of prefixes is somehow exponential, but back to the real world: Years there was a frantic forklift upgrade business to get the biggest baddest BFR from vendors even before the paint was dry, and this happened because indeed we were starving for more CPU and more memory. This does not happen today. As Stephen points out, even the little guys aren't complaining anymore and vendors don't even put the latest technology they can in their products because nobody's screaming for it anymore. In short: the IPv6 idea of reducing the size of the routing table was necessary if IPv6 had been deployed and replaced v4 5 years ago. We have missed the launch window and as of today this problem solved by time; I hear that we could handle a million prefixes with today's technology. If it takes a THz processor to handle 10 million prefixes and a 100THz one to handle 100 million prefixes, I don't care as long as said processors are on the shelf at Fry's for $200 a piece and on a vendor's Sup for $100K a piece. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Why would a service provider give up skimming the cream with that (nearly free) extra cash that weirdos like us hand them for real IPv4 addresses? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Hi Andrew, And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. sorry for asking, but what policy are you referring to? RIR policy? Can you point out any RIRs policy that prevents from getting one public IPv4 address per machine connected to the Internet? What do you think that needs to be changed in the v4 allocation policy? Or are you talking about business model of the ISPs? (which doesn't seem to me to be related with policies, but just business...) Thanks, marcelo Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 30-mrt-2006, at 10:29, marcelo bagnulo braun wrote: And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. sorry for asking, but what policy are you referring to? RIR policy? Can you point out any RIRs policy that prevents from getting one public IPv4 address per machine connected to the Internet? On a somewhat (un)related note: it's not easy for ISPs to give out two or three IP addresses to customers because there is no good mechanism to do so. One address works very well with PPP or DHCP, but a specific number other than one doesn't, so the next step is something like a /29. On an even more (un)related note: it's not possible to give IPv6 addresses to customers over PPP, and it's very inconvenient to make a /64 - /48 be routed towards a customer router that dynamically connects to an ISP network. (I.e., my cell phone is a router and it dials up, it gets an address through stateless autoconfig but then my laptop, PDA etc that use the cell phone as their router aren't automatically reachable.) Some more work on provisioning mechanisms wouldn't be a bad thing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 30-mrt-2006, at 6:26, Anthony G. Atkielski wrote: We currently have 1/8th of the IPv6 address space set aside for global unicast purposes ... Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or 42,535,295,865,117,307,932,921,825,928,971,026,432 addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way? When I first learned about IPv6 I felt strongly that 128 bits was too much, especially since all those bits have to be carried in every IP packet twice, once as a source address and once as a destination address. However, since that time I've learned to appreciate stateless autoconfiguration and the potential usefulness of having the lower 64 bits of the IPv6 address as a place to carry some limited security information (see SEND and shim6 HBA). ... with the idea that ISPs give their customers /48 blocks. Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose. The trouble is that you need to build in space for growth. Unfortunately, at the time IPv6 was created variable length addresses weren't considered viable. (In theory CLNP has variable length addresses, in practice that doesn't really work out.) And for some strange reason, apparently only powers of two were considered as address lengths. So the choice was either 64 bits, which is a lot, but it doesn't allow for any innovation over the 32 bits we have in IPv4, or 128 which does cost 16 extra bytes in every packet, but gives us stateless autoconfig and SEND. Now you can argue that 64 or 48 bits and continuing current IPv4 practices would have been better, but given the choice for 128 bits, the current way of using the address space makes sense for the most part. The only thing I'm not too happy about is the current one address / one subnet / /48 trichotomy. Ignoring the single address for a moment, the choice between one subnet and 65536 isn't a great one, as many things require a number of subnets that's greater than one, but not by much. For instance, the cell phone as a router example I talked about earlier. A /64 and a single address, or two /64s which would be a /63 would be more useful there. The idea that we'd use up too much address space by giving out /48s doesn't seem like a real problem to me, but on the other hand most people don't need a /48 so some choice thats /48 and 64 makes sense. But a /56 as suggested by some people is suboptimal: people with growing networks will at some point need more than 256 subnets but at that point they already have very many subnets so renumbering then is painful. Making the choice between /60 and /48 makes much more sense: just give everyone a /60 rather than a /64 just in case they need a handful of subnets, which is adequate for 99% of all internet users. People who need more than a handful of subnets can get a /48 and won't have to renumber at an inconvenient point in the growth curve. Yes, I know this will use up sixteen times the number of addresses for people who really only need a single subnet, but it saves a factor 4096 for the people who need 2 - 16 subnets and would have gotten a /48 or a factor 16 for the people who would have gotten a / 56. The extra wasted address space from giving people who really only need one subnet a /60 is made up for by the people who would have gotten a /48 but can now get by with a /60 if the ratio of one-subnet to 17-subnet users is 1 : 4000 or less. (Making the choice /64 vs / 56 saves even more as long as the ratio is lower than 94 : 6 but doesn't have the desireable near-onesizefitsall quality.) If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides. The thing that is good about IPv6 is that once you get yourself a / 64, you can subdivide it yourself and still have four billion times the IPv4 address space. (But you'd be giving up the autoconfiguration advantages.) Also, when the time comes to create the next version of IP, we won't have to worry about all of this to a noticeable degree because IPvA or IPvF or whatever can have a different addressing structure that can still be expressed as an IPv6-like 128 bit number for backward compatibility with
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 18.00, Hallam-Baker, Phillip wrote: From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... Precisely. Just what is this fetish about keeping the IP address the same as the packet travels? I will have to get better at making irony clearerI most certainly hope we are not heading down the route I suggest above. I am _afraid_ we are though. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On Thu, Mar 30, 2006 at 01:36:18PM +0200, Iljitsch van Beijnum wrote: The thing that is good about IPv6 is that once you get yourself a / 64, you can subdivide it yourself and still have four billion times the IPv4 address space. (But you'd be giving up the autoconfiguration advantages.) I noticed that by deafult MS Vista doesn't use autoconf as per 2462, rather it uses a 3041-like random address. See: http://www.microsoft.com/technet/itsolutions/network/evaluate/new_network.mspx Random Interface IDs for IPv6 Addresses To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Server Longhorn and Windows Vista by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses. That reads to me like no 2462 by default. Maybe I'm misinterpreting. One could envisage an option where that randomness is applied to 48 host bits not 64. If you really really wanted to do that. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Keith Moore writes: I find myself wondering, don't they get support calls from customers having to deal with the problems caused by the NATs? Sure, and the reply is I'm sorry, but we don't support multiple computers on residential accounts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Austin Schutz wrote: On Wed, Mar 29, 2006 at 01:00:44AM +0200, Iljitsch van Beijnum wrote: 1996199719981999200020012002200320042005 2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5 (The numbers represent the number of addresses used up in that year as a percentage of the 3.7 billion total usable IPv4 addresses.) Those years where the growth was smaller than the year before never happened twice or more in a row. This basically means that unless things take a radical turn, the long- term trend is accelerating growth so that remaining 40% will be gone in less than 9 years. Probably something like 7, as Geoff Huston predicts. This is much less time than I have seen in previous reports. If this is accurate and consistent there is a greater problem than I had previously thought. If that is indeed the case then the enhanced nat road for ipv6 begins to make much more sense, even in the nearer term. Austin I am afraid the problem is even bigger. I have seen again and again that cable providers are giving out ip-addresses in the 10.0.0.0/8 area to save ip address space. Not to mention wireless hotspots. The hotspots I have been playing with own only a single one ip-address. You notice something is awfully wrong, when your VoIP phone is not working but your neighbar keeps telling you, his skype does. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
--On Thursday, March 30, 2006 08:47 -0800 Peter Sherbin [EMAIL PROTECTED] wrote: If someone calls up for help with a configuration problem, that may be six month's of profits from that customer eaten up in the cost of answering the call. That is because the current Internet pricing has been screwed-up from the start. LD settlements between telcos are fully applicable to ISPs but have never been instituted. Internet has been subsidised for years by the local access but now as wireline declines everybody starts feeling the pain. Usage based billing and inter-ISP settlements start showing up lately and they fit well for the Internet. Otherwise transit providers as well as heavy users rip all the benefits. Peter, I was describing the facts of what is going on, rather than the causes. That said, based on some experience on both the telco and ISP sides of things, I believe your analysis is incorrect in a number of important ways, starting with the difficulties of applying a settlement model that assumes that value accrues to the caller to today's Internet. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
I find myself wondering, don't they get support calls from customers having to deal with the problems caused by the NATs? Because they don't answer them. In the process of doing the work that led to RFC 4084, I reviewed the terms and conditions of service of a large number of ISPs in the US (and a few others) who provide low-cost Internet connectivity. Some prohibit connection of more than one machine to the incoming line/router/modem. Others provide a NAT-capable router but prohibit the customer from making any changes to its configuration and from running any applications that don't work in that environment. And still others indicate that customers can supply their own NATs, but must obtain any support elsewhere. All of these prohibitions are enforced the same way -- if the user calls with a problem, he or she either (i) is told that there is no support for violations of the rules and offered the opportunity to be disconnected (often with a large early termination fee) or (ii) is instructed to disconnect all equipment between the machine in question and the router, and see if the problem still occurs. If it doesn't, then the ISP has no problem and the customer's problem is of no interest. Well, the reason I asked is that when I got my DSL line, my ISP supplied me with a modem that does NAT - but only for a single host. As best as I can tell this is because the box needs to run PPPoE on the carrier side and DHCP on the host side, and the only way that the DHCP server can give the host an address under those conditions is to do NAT. So in this case (which I have no reason to believe is atypical) the ISP is supplying the NAT - and they do so even for customers who pay them extra to get a static IP address! And yes it does break things even when there are no other local hosts involved and no additional boxes between the modem and the customer's host. So I have a hard time believing that ISPs don't get support calls about failures due to NATs, at least when they install the NATs. Now of course this ISP does have a TC that prohibits running a server, but server is a pretty vague term, and you don't have to be running any kind of server to suffer from NAT brain-damage. Keith p.s. fwiw the workaround in my case was to tell the modem to work in passthrough mode and configure my local router to run PPPoE. Under those conditions, I'm happy to report, 6to4 works just fine. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Thu, Mar 30, 2006 at 11:26:40PM +0200, Iljitsch van Beijnum wrote: If that is indeed the case then the enhanced nat road for ipv6 begins to make much more sense, even in the nearer term. I remember someone saying something about enhanced NAT here a few days ago but I can't find it... What is it and what does it have to do with IPv6? It was a term Keith Moore used to describe the addition of ipv6 capability to NAT devices. Not intended as a real term, merely a marketing name to explain to the end user the benefit of having ipv6 capability. If address space does indeed burn that quickly, ISPs will start to realize they can't sell additional IP addresses as a way of making a quick profit. Those with dwindling address pools will begin to demand proper ipv6 support from router vendors to offer it at a discounted price (compared to ipv4) to their customers who are savvy enough to want to run servers but too cheap to buy ipv4 space at a premium. From there it should only be a matter of time. If key applications work with ipv6 that will probably be adequate to get the ball rolling. IIRC there was a similar transition back when virtual web hosting meant blowing an ip address for every extra domain. After an adequate number of browsers were upgraded hosting providers made available ip-less virtual hosts at a heavy discount from ip-burning ones. After a surprisingly short amount of time the vast majority of browsers were compliant. The final nail was registries refusing virtual hosting as an excuse to justify allocations. That's not news to most here, but I definitely see the similarity in the situation. Austin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Thus spake Keith Moore moore@cs.utk.edu Now of course this ISP does have a TC that prohibits running a server, but server is a pretty vague term, and you don't have to be running any kind of server to suffer from NAT brain-damage. My ISP has ingeniously defined a server as any application that does not work through NAT without port forwarding. Bingo, problem solved (from their perspective). Of course, they don't actually enforce this unless a user's upstream bandwidth usage consistently exceeds total POP upstream bandwidth divided by the number of users at the POP (in my case, about 300kB/s). Go above that and you get an email asking you to turn down the speed on your P2P client ;-) p.s. fwiw the workaround in my case was to tell the modem to work in passthrough mode and configure my local router to run PPPoE. Under those conditions, I'm happy to report, 6to4 works just fine. Alas, I've been unable to find a consumer-grade router that will run native IPv6, 6to4, or even pass through IPinIP (excluding open-source hacks which are not supported by the vendor -- that's not a solution for real consumers). If anyone knows of one, please let me know off-list. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel Chiappa wrote: If you think there aren't still stability issues, why don't you try getting rid of all the BGP dampening stuff, then? Have any major ISP's out there done that? Dampening is part of the protocol and has nothing to do with the speed of light. Removing it is akin to removing packet re-ordering in TCP; nobody with half a brain would consider it. Same as packets arriving out of sequence, stability issues are part of life for someone who actually operates a network. Code has bugs, hardware fails, power goes bezerk, UPS batteries leak, rodents chew on cables, backhoes cut fiber, fat fingers screw up configs, and rookies flap routes because they know everything about astrophysics and nothing about running a production network. That's what dampening is for. Stephen Sprunk wrote: Of course, they don't actually enforce this unless a user's upstream bandwidth usage consistently exceeds total POP upstream bandwidth divided by the number of users at the POP (in my case, about 300kB/s). Go above that and you get an email asking you to turn down the speed on your P2P client ;-) Some bigger ISPs (with large POPs) prefer to limit the upstream so they don't have to manage quotas/bandwidth. I have 512kb upstream; it's not big but I can bittorrent all of it all day long, they don't care and probably don't know. Alas, I've been unable to find a consumer-grade router that will run native IPv6, 6to4, or even pass through IPinIP There's no market for it. Consumers don't know what it is and geeks already have a hack or an el-cheapo-ebay Cisco. Heck, my home router is a 7204 why would I go for a Linksys :-D Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Dampening is part of the protocol and has nothing to do with the speed of light. Well, not really. Assume a simplistic model of the Internet with M core routers (in the default free zone) and N leaf AS, i.e. networks that have their own non-aggregated prefix. Now, assume that each of the leaf AS has a routing event with a basic frequency, F. Without dampening, each core router would see each of these events with that same frequency, F. Each router would thus see O(N*F) events per second. Since events imply some overhead in processing, message passing, etc, one can assume that at any given point in time there is a limit to what a router can swallow. In either N or F is too large, the router is cooked. Hence dampening at a rate D, so that N*F/D remains lower than the acceptable limit. Bottom line, you can only increase the number of routes if you are ready to dampen more aggressively. There is an obvious tragedy of the commons here: if more network want to multi-home and be declared in the core, then more aggressive dampening will be required, and each of the multi-homed networks will suffer from less precise routing, longer time to correct outages, etc. There are different elements at play that also limit the number of core routers. Basically, an event in a core router affects all the path that go through it, which depending on the structure of the graph is somewhere between O(M*log(M)) or O(M.log(M)). In short, the routing load grows much faster than linearly with the number of core routers. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the size of the available address space. So if what you say is true, and we manage to use up an exponential resource in linear time, then we can change our approach and try again with the second 1/8 of the space, without having to go through the upgrade pain that is the v4-v6 transition again. I suspect even arrogant engineers can get it right in 8 tries. :) -Scott On 03/29/06 at 6:15am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Thomas Narten writes: This is FUD. Care to back up your assertions with real analysis? Sure. The consistent mistake engineers make in allocating addresses is that they estimate capacity in terms of sequential and consecutive assignment of addresses--but they _assign_ addresses in terms of bit spans within the address itself, which exhausts addresses in an exponential way. They do this in part because they attempt to encode information directly into the address, instead of just using it as a serial identifier. An address of n bits contains 2^n available addresses _only_ if they are assigned serially and consecutively; dividing those bits into any arrangement of smaller fields reduces capacity exponentially. For example, if you have a 16-bit address field, at first it looks as those it has 65,536 addresses. And it does ... if you assign addresses as 0001, 0010, and so on. But if you allocate addresses by dividing those 16 bits into fields, you dramatically reduce the total address space available. If you reserve the first eight bits for a vendor, and the second eight bits for a product, you've cut the address space by 99.6%, not by 50%. You will run out of addresses in record time, and yet you'll never use more than a tiny fraction of the theoretical capacity of the address space. All because you wanted the short-term convenience of encoding information into the address itself. Engineers make this mistake over, and over, and over. I don't know if they are just too stupid to understand the above concepts, or if they are so arrogant that they think they can somehow short-circuit information theory and do the impossible. I tend to vote for arrogance, since I think (and hope) that engineers aren't really that stupid. And further evidence for pure arrogance is that engineers try to allocate address spaces now for a future that they are unable to imagine. They allocate /64 fields out of 128 bits for purposes that they understand now, even though the real need for addresses is likely to be completely different (and unforseeable) by the time addresses actually start to run short. I know I'm wasting my breath; if engineers were that easy to persuade, they would not have made the same mistake over and over for nearly a hundred years. I'm sure others have tried to point out their errors time and again, especially in recent years as more people have caught on to the problem. But they can't be told. They are convinced that it won't happen to them, even though it happened to everyone else. A 128-bit address seems like more than the universe will ever need, and it definitely is ... but only if addresses are assigned serially from the address space, without any information encoded into the address itself. As soon as you reserve any portion of the field in any way, there are multiple exponential reductions in capacity, which can exhaust the address space entirely in a very short time. The mistakes have already been made with IPv6. Someone decided to allocate bit spans out of the address, instantly invalidating the very vast majority of all possible addresses in the address space, and thereby reducing address capacity exponentially. Nobody really knows how addresses will be used 20 years from now, so why do people try to guess and sacrifice the capacity of IPv6 in the process? Don't they ever learn? Is there a safe and conservative way of allocating IPv6 address space? Yes. Set the first 96 bits to zero, and set the remaining 32 to the current IPv4 addresses. When that runs out, set the first 95 bits to zero, set the 96th bit to one, and use the remaining 32 bits for another IPv4 address space. And so on. A space of 128 bits will last for eternity in this way, and most of the space will remain available for any conceivable future addressing scheme, even those we cannot dream of today. In other words, don't allocate bit spans within the address field, allocate address _ranges_ out of the full 128 bits. But I know that won't happen. However, perhaps this message will remain archived somewhere so that I can say I told you so when the address space finally runs out (I'm pretty sure I'll still be around--we all will). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote: locators are a lot easier to deal with if they're location-independent Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? I really was talking about locators, not identifiers. Now that I understand what you actually meant, I'm not freaked out! However, you phrased your point in a way that almost guaranteed confusion! You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. This is a problem for PIP-like schemes and mobility. At any point in the network, the locator to use to reach a particular target is unique. However, the locator to use to reach a particular target is different at every point. That would be okay except that when *I* move, the way I address a target changes. That's more of a problem than having to adjust as my target moves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. This is a problem for PIP-like schemes and mobility. At any point in the network, the locator to use to reach a particular target is unique. However, the locator to use to reach a particular target is different at every point. That would be okay except that when *I* move, the way I address a target changes. well, no. it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 16:17, Keith Moore wrote: it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. - DNS is often out of sync with reality - DNS is slow and unreliable. DNS servers and the links to them do not share fate with the hosts whose RRs they serve. DNS lookup delay is often considerably longer than the RTT to the host. - many networks use other ways of doing name to address mapping for local hosts. - there's no good way for hosts to know their own DNS names - more generally, there's no good way for a host or an app to know what a DNS name means. a DNS name is not irrevocably bound to a particular host for all time, but rather, associates some role or service name with a particular address. a single host may support more than one such role or service at any particular time, but the set of roles or services supported on a host will change over time. - furthermore a single role or service with a single DNS name might be supported on multiple hosts, and DNS be used to specify which hosts are providing that particular service. this might be sufficient on an initial connection when any one of those hosts will do; but this is not sufficient when an app needs to know how to contact a process on a particular one of those hosts. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 16:43, Keith Moore wrote: it would be okay if the only apps you needed to run were two- party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. Since when is that any kind of argument? The real questions are whether it CAN work well for this and whether there's something else that can do it better/easier. - DNS is often out of sync with reality Dynamic DNS updates are your friend. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. - there's no good way for hosts to know their own DNS names Again, dynamic DNS updates. When IPv6 materializes where it's impossible to pre-populate the reverse tree and systems generate their own addresses, traditional DNS management will be out the window anyway. - more generally, there's no good way for a host or an app to know what a DNS name means. This one can be problematic but it's not a fundamental problem but rather a local management problem: apps should be able to obtain the local hostname that they can use for referral purposes. This isn't necessarily the same hostname that you'd get from a reverse lookup. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. I wouldn't have a problem with that except that people somehow think that IP addresses DO fulfill all the requirements for being stable references. In traditional IPv4 they did to a large degree, but then NAT came along. With IPv6 a single host routinely has multiple addresses (of more than one scope), and with MIP and shim those addresses change from time to time. IP addresses are what get the packets from point A to point B. That's hard enough. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. Since when is that any kind of argument? The real questions are whether it CAN work well for this and whether there's something else that can do it better/easier. - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. - there's no good way for hosts to know their own DNS names Again, dynamic DNS updates. Doesn't solve the problem, especially when DDNS is done by some DHCP server rather than the host itself. - more generally, there's no good way for a host or an app to know what a DNS name means. This one can be problematic but it's not a fundamental problem but rather a local management problem: apps should be able to obtain the local hostname that they can use for referral purposes. There's no standard way to do this - and the right name can vary from one app to another on the same host. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. I wouldn't have a problem with that except that people somehow think that IP addresses DO fulfill all the requirements for being stable references. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. In traditional IPv4 they did to a large degree, but then NAT came along. With IPv6 a single host routinely has multiple addresses (of more than one scope), and with MIP and shim those addresses change from time to time. IP addresses are what get the packets from point A to point B. That's hard enough. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. I wasn't talking about stable references - I was talking about references that are valid, for a short time, from anywhere in the network. Stable references are a different problem. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
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
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 18:34, Keith Moore wrote: - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. But there is no fundamental reason why it can't be set up correctly and be kept in reasonable sync if people care to do so. DDNS is a great tool for that, and as I wrote in my previous message, almost a requirement with IPv6, but there are other ways to do it as well. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. I wasn't talking about stable references I wasn't talking about long-term stable either, just stable enough to make referrals work. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Point made many times, and the proof is in the pudding: if they're using it so widely it means it works for them. Actually, no. The world is full of examples of practices and mechanisms that are widely adopted and entrenched that work very poorly. You only have to look at any day's newspaper to find evidence of this. The assumption that people have the wisdom to reliably realize what is in their best interests (as individuals or as a group of any size, in the short-term or long-term) is demonstrably false. And the more complex the system, the harder it is for people to use it wisely. Using past mistakes to justify future mistakes is pure foolishness. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
- DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. Of course a big part of the reason that distributed apps (not just p2p apps) don't consistently use DNS is that it doesn't work well. But it's not quite a chicken and egg problem. DNS cannot really work well for referrals. Core design assumptions in DNS no longer apply. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) I'd argue that DNS is NOT good enough for the web, and maybe not good enough for email. When you click on a link and it takes seconds before the page even starts loading, that's probably DNS. Email is less delay sensitive, but when you send mail and it bounces because the MX records were out of sync with reality, DNS is implicated there also. Some p2p apps are unreliable because they are trying to layer over a network that imposes arbitrary restrictions on its use (unlike the IP design that assumes best effort) and on top of hosts that appear and disappear at a whim. Even then, they sometimes work better than client-server apps that try to serve the same purpose. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But by expecting distributed apps to use DNS, you would be imposing the operational constraint that all of those hosts be listed in DNS. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. adding complexity that makes your app less relable is usually not a good way to go. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. no. DNS is just an app that lets other apps find out certain kinds of information about certain resources on the network. It's nowhere nearly flexible enough to be a control plane. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. What I'm saying is that if IP addresses won't be stable enough for referrals in distributed apps, they won't be stable enough for referrals in DNS either. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
Are you saying that ENUM is a dead end? F. -- [EMAIL PROTECTED] 819 692 1383 On Wed, 29 Mar 2006, Keith Moore wrote: - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. Of course a big part of the reason that distributed apps (not just p2p apps) don't consistently use DNS is that it doesn't work well. But it's not quite a chicken and egg problem. DNS cannot really work well for referrals. Core design assumptions in DNS no longer apply. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) I'd argue that DNS is NOT good enough for the web, and maybe not good enough for email. When you click on a link and it takes seconds before the page even starts loading, that's probably DNS. Email is less delay sensitive, but when you send mail and it bounces because the MX records were out of sync with reality, DNS is implicated there also. Some p2p apps are unreliable because they are trying to layer over a network that imposes arbitrary restrictions on its use (unlike the IP design that assumes best effort) and on top of hosts that appear and disappear at a whim. Even then, they sometimes work better than client-server apps that try to serve the same purpose. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But by expecting distributed apps to use DNS, you would be imposing the operational constraint that all of those hosts be listed in DNS. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. adding complexity that makes your app less relable is usually not a good way to go. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. no. DNS is just an app that lets other apps find out certain kinds of information about certain resources on the network. It's nowhere nearly flexible enough to be a control plane. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. What I'm saying is that if IP addresses won't be stable enough for referrals in distributed apps, they won't be stable enough for referrals in DNS either. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Iljitsch van Beijnum wrote: ...including the RIR reserves which are at an all time high of nearly 400 million) Also, keep in mind that the RIRs are not the only ones to have reserves. The address space itself has reserves, class E for example. ISPs have reserves, and customer have reserves too (many have been stockpiling). Besides all this, there is a huge waste out there. Last month I ran some interesting numbers; the sample is 115 so I'm not saying this is statistically significant, but I don't think it's too much far off reality either. Here it is: Out of my 115 small business consulting customers (5-300 employees, aDSL/T1/DS3) - Only one has ISDN (leaves in the middle of nowhere; no DSL, cable but no static IP). - 100% use NAT with RFC1918 addresses. - I had to renumber one customer because they merged with another one and both were using 192.168.0.0/24. - 192.168.0.0/24 or 192.168.1.0/24 is the address being used inside 75% of the time. - 50% have basic NAT boxes (generally the smaller ones), the other half have boxes that have some packet inspection/content awareness capabilities. - Out of this half, more-than-basic firewalling is enabled in only 20% even though the box is capable of. - Only one uses a non-NAT proxy server (going away soon) for HTTP surfing. The others who filter content use a content-aware NAT box (typically, a PIX or SonicWall querying a Websense server). It appears that NAT has far less issues than proxy servers. - 90% use a single IP. - 100% have been allocated more than a single IP (/29 being the smallest, /23 the largest) - The average IP use is 1.2 IPs per customer. (a) - The average allocation is 18 IPs per customer. (b) My 115 customers use 146 IP addresses out of the 2104 allocated to them. 93% waste. Just to make it clear: I'm not in denial and v4 exhaustion is not FUD, but the Internet is not going to stop the day after we allocate the last bit of v4 space either. BTW, Michel, you said you were about to return from the dark side in true Star Wars fashion. What gives? :-) If you only knew the power of the dark side ;-) Stay tuned. Michel. (a) This could be reduced to 1.1 by better configuration. Out of the dozen who use more than one IP, half really need only one. There this guy who runs 2 physically different web servers because he has two domain names, ignoring that he could bind multiple IPs to the same machine, run a virtual server, or use HTTP headers like everyone else who hosts thousands of sites on a single machine with cpanel. Also there appears to be a widely spread phenomenon with PIX boxes that use a public IP for each inside host (even though the ports are different); talking with the guys that configured them it looks that PDM makes it easier that way. (b) Multiple factors contribute to this. First, the smallest allocation is a /29; with many ISPs you can't get a single static you have to waste a /29 to use only 1 IP out of it (90% of the sample). Also, I have seen multiple occurrences where the T1 link is on a /30 and the customer is allocated a /28 for the LAN side. However, the way it's configured is that the router NATs out using the address of the T1 interface and the customer block, if used at all, is configured in a loopback for the sole purpose of allowing the ISP's level 1 support to ping it. In several cases the /28 is not even configured anywhere. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
Francois Menard wrote: Are you saying that ENUM is a dead end? F. -- [EMAIL PROTECTED] 819 692 1383 ENUM is a dead born child. ENUM is supposed to be good for VoIP. Well, I do have VoIP but my VoIP does work allthough ENUM does not. My router could use ENUM - but which one should I ask, e164.arpa or e164.org? Neither of them does know any of my phone numbers. cynikal I am told I could buy the domain that corresponds to one of my phone numbers but I would have to bring in a birth certificate of both me and my landlord to proove legal ownership of that phone number. The gouvernement of germany would hold an election about the matter and if everything was allright I might put my phone number on my tombstone finally. /cynikal In the meantime you can call me on If your VoIP provider talks to sipgate.de +49(6252)750-308 If your phone allows to do that sip:[EMAIL PROTECTED] or via no-ip.com dynamic DNS sip:[EMAIL PROTECTED] Please allow for my local time. It is Québéc + 6 hours or Paris time :) cynikal I guess, right now ENUM could not do that no-ip.com trick. I would have to ask parliament every time my ip changed, to update my A record. /cynikal Hope I was not too cynical. Kind regards Peter et Karine -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote: Now, consider that in that city one does go by street numbers but by building names. As we did for a very long time and many still do. So our building is named by the City Registry Innovation House - and if a day it is scrapped and rebuilt eleswhere everyone will keep calling it (the new) Innovation House (like for Scotland Yard for example). Now, the Room 125 is in Innovation House on _both_ streets. Obviously the zip code is not changed. Your analogy breaks here on the assumption that this is, and indeed needs, to be true for anything but a small number of highly specialized service addresses. A company can change address. As as a minor aside, whilst Scotland Yard, London, will probably arrive at the HQ of the Met, their building is New Scotland Yard. Also, my parents happen to have a house which is formally on two streets, both under two numbers, and indeed has multiple postcodes. (Four, I think). Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
At 01:28 30/03/2006, Dave Cridland wrote: On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote: Now, consider that in that city one does go by street numbers but by building names. As we did for a very long time and many still do. So our building is named by the City Registry Innovation House - and if a day it is scrapped and rebuilt eleswhere everyone will keep calling it (the new) Innovation House (like for Scotland Yard for example). Now, the Room 125 is in Innovation House on _both_ streets. Obviously the zip code is not changed. Your analogy breaks here on the assumption that this is, and indeed needs, to be true for anything but a small number of highly specialized service addresses. A company can change address. I proposed this to get that response. The main error IMHO of all the IPv6 numbering is to consider eveything has to be the same for everyone. Six global numbering systems have been foreseen. RIRs have one. ITU has said they assume one. Four others can be used. One for space? One for geography? The main reason why all this does not move is that there is no competition between those two and may be others. The role of ICANN is to foster competition in common interest. IPv6 deployment and numbering is now out of IETF, hence to ICANN. If the WSIS has asked ITU to take the lead, it is because ICANN has been unable manage ITU - and possibly create competition. RIRs are in the same situation as NSI when they sold domain names $100 a piece for two years. Would IPv6 addresses be much, much cheaper and easy to get, I am sure many points of this debate would have been already addressed to permit it. As as a minor aside, whilst Scotland Yard, London, will probably arrive at the HQ of the Met, their building is New Scotland Yard. You just confirm what I said above. Addresses can physically move - in the image of street/IPv6 this is equivalent to a change of ISP. Also, my parents happen to have a house which is formally on two streets, both under two numbers, and indeed has multiple postcodes. (Four, I think). You just describe multihoming. All the best. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
At 20:46 29/03/2006, Michel Py wrote: Just to make it clear: I'm not in denial and v4 exhaustion is not FUD, but the Internet is not going to stop the day after we allocate the last bit of v4 space either. The issue is not so much when we will be prevented from doing what we currently do. It is since when are we prevented from doing what we could have done. I think it is a very, very long time ago. Actually http.1.1. is virtual NAT. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Iljitsch van Beijnum writes: So how big would you like addresses to be, then? It's not how big they are, it's how they are allocated. And they are allocated very poorly, even recklessly, which is why they run out so quickly. It's true that engineers always underestimate required capacity, but 128-bit addresses would be enough for anything ... IF they were fully allocated. But I know they won't be, and so the address space will be exhausted soon enough. We currently have 1/8th of the IPv6 address space set aside for global unicast purposes ... Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or 42,535,295,865,117,307,932,921,825,928,971,026,432 addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way? It doesn't matter how many bits you put in an address, if you assign them this carelessly. ... with the idea that ISPs give their customers /48 blocks. Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose. Remember, trying to encode information in the address (which is what you are doing when you reserve bit spans) results in exponential (read incomprehensibly huge) reductions in the number of available addresses. It's trivially easy to exhaust the entire address space this way. If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides. Why is this so difficult for people to understand? That gives us 45 bits worth of address space to use up. You're doing it again. It's not 45 bits; it's a factor of 35,184,372,088,832. But rest assured, they'll be gone in the blink of an eye if the address space continues to be mismanaged in this way. It's generally accepted that an HD ratio of 80% should be reachable without trouble, which means we get to waste 20% of those bits in aggregation hierarchies. No. It's not 20% of the bits, it's 99.9756% of your address space that you are wasting. Do engineers really study math? This gives us 36 bits = 68 billion /48s. That's several per person inhabiting the earth, and each of those / 48s provides 65536 subnets that have room to address every MAC address ever assigned without breaking a sweat. What happens when MAC addresses go away? How are you providing for the future when you allocate address space based on the past? Why not just leave the address space alone, and allocate only the minimum slice required to handle current requirements? That's another problem of engineers: they think they can predict the future, and they are almost always wrong. What was the problem again? And that's the third problem. Remember also: any encoding of information into the address field (including anything that facilitates routing) exponentially reduces the total number of available addresses. So it might look like 2^128 addresses, but in reality it may be 2^40, or some other very small number, depending on how much information you try to encode into the address. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29/03/2006, at 5:10 AM, Scott Leibrand wrote: On 03/28/06 at 7:00am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Agreed, but they reduce the amount of money you must pay to your ISP each month by a factor of ten or more. Your ISP charges you 9 times as much for IPv4 addresses as they do for bandwidth? I'd recommend switching ISPs. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. Not if you don't live in the US. There are no options here that are at all cheap. Usually you get a flat we don't do that. And they don't do v6 either. And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Interesting discussion. Keith is hitting all the nails on the head. Phillip seems to suggest that consumers buy NATs out of choice. They don't have any choice. I surveyed my final years students last month. Just four have a static IPv4 allocation for their home network, and only one has more than a /32 for use internally. ISPs just don't give you a choice (unless you are prepared to pay a non-negligible fee). If you deply IPv6 NAT, you may as well stay with IPv4. The first ISPs offering IPv6 are offering /48's here. The allocations to FT etc (they have a /19) are clearly made on the basis of end site /48's. See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt We have deployed IPv6 in our enterprise (throughout). We're seeing some early benefits from (student) driven new services. Students are also using transition mechanisms to enable simpler use of applications between homes (rather than battling a NAT out and a NAT in on communication paths). No regrets from deploying, no significant issues either for the existing IPv4 service. And there's more than just address space to take advantage of, like embedded RP for multicast applications. Tim On Tue, Mar 28, 2006 at 12:48:13AM -0500, Keith Moore wrote: In this case the benefit to running NAT on my home network is that it saves me $50 per month in ISP fees, means I have wireless service to the whole house and means that guests can easily connect. one immediate benefit to my running IPv6 on my home network is that I can access any of my machines from anywhere else on the network (via 6to4), as long as I'm not behind a NAT. my home network also has a v4 NAT, so it's not as if they're mutually exclusive. I have never seen a coherent, rational argument as to why the network numbering on my internal network should be the same as the network numbering on the Internet. obviously you've never tried to write a distributed application in a NATted network. and presumably you never tried to do anything with UUCP mail (which had naming conflicts) or a large DECnet (which had address conflicts). the problems are immediately obvious to those of us who have had to deal with those disasters. in brief: one reason is so that apps can have the same view of the network regardless of whether they're hosted on your internal network, or on an external network, or on a combination of the two. it's MUCH simpler if apps don't have to worry about the fact that host A has address A1 from network X and address A2 from network Y. particularly since in a network with scoped addresses, hosts don't really have any way of knowing which network they're on. there are other reasons also: routing, coherent network management, DNS consistency. a network with scoped addressing is like a city where all of the streets have the same name. it becomes pretty difficult to navigate. People will still want to do NAT on IPv6. true. people do all kinds of evil things that break the net. our protocols will only work to the extent that people follow the specifications. when people start breaking things, the protocols and applications start failing. NAT is a good example. in ipv6, we can provide better ways of solving the problems that people think they're solving with NATs. if we fail to do that, or if people insist on using NATs anyway, we're screwed. but that's not a reason to give up without trying. either do something to help or get out of the way. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Today, 90% of the phones in the world are still analog. Including mine, in the capital of California and my buddies' in the heart of Silicon Valley. the (static) statement that 90% of phones are analog seems very wrong to me. according to newest ITU-D estimates, by the end of 2004, there were 1.2 billion land lines, with an average annual growth rate of 5.8% since 1999. this means 18.99 lines per 100 world inhabitants [1]. i ignore how many of these lines are analog, but what is for sure is that the most phones today do not have any lines at all: at the same time, the ITU registered 1.76 billion cellular subscribers, with an annual growth rate of 29% since 1999. This makes up for 27.61 phones per 100 world inhabitants [2]. the vast majority of cellular phones are not analog (GSM+ being the nr 1 technology [3]) and thus probably less than 50% of world phones are analog. i don't know how this relates to the current nat/ipv6/ipv4 discussion, but the argument above could be easily turned into a counter-argument: one could have said that with the original analog phones we were not able to solve the digital divide in the voice service and a new technology has become necessary :-) regards artur [1] http://www.itu.int/ITU-D/ict/statistics/at_glance/main04.pdf [2] http://www.itu.int/ITU-D/ict/statistics/at_glance/cellular04.pdf [3] http://www.gsmworld.com/index.shtml ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 00.11, Keith Moore wrote: NAT is a done deal. It's well supported at network edges. It solves the addressing issue, which was what the market wanted. It voted for NAT with dollars and time. It is the long term solution - not because it is better, but because it is. NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. Tim, You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt Remember: Users don't read drafts/RFCs. We have deployed IPv6 in our enterprise (throughout). Could you have done it if you did not have the research dollars^H^H^H^H pounds? Artur Hecker wrote: the (static) statement that 90% of phones are analog seems very wrong to me. My bad, I should have said land lines. Hallam-Baker, Phillip wrote: I have never seen a coherent, rational argument as to why the network numbering on my internal network should be the same as the network numbering on the Internet. Phillip, there a few (such as: NAT typically requires hard state, which is a pain to replicate if there is more than one edge router). NAT is not completely evil, but it's far from being clean. Pretending that there are no good reasons against NAT is going to achieve the same as trying to eliminate it: nothing. People will still want to do NAT on IPv6. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). Austin Schutz wrote: ...that opportunity may be to enhance NAT rather than throw it away Austin, this has been tried many times and never went anywhere. As there are no changes in the reasons it has failed in the past I don't see how this could make it this time. Michel Py wrote: A protocol that would be only v4 with more bits in the first place, with routers / NAT boxes that would pad/unpad extra zeroes (also including extra TBD fields). As this would be 100% compatible with v4 this could be deployed without too many headaches. Keith Moore wrote: huh? there is no way to make a protocol that can address more hosts than v4, that is 100% compatible with v4. and there's no good way to divide up the net into v4 enclaves and v6 enclaves because the applications that need v6 addressing don't fit neatly into enclaves. As long as you don't use the extra bits, no problem. IPv4 on one side, IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes, when going to v4+ to v4 remove a bunch of zeroes. Initially it's a total waste of bits, but silicon is cheap these days. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
[cc trimmed] On Tue, 2006-03-28 at 01:54 -0800, Michel Py wrote: People will still want to do NAT on IPv6. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). I guess you missed out on: http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast[RFC4193] You can use that to generate your local prefix and it is much better than site-locals as the chance of collisions is fairly low. And as you know you simply don't want to do a NAT from 10/8 to 10/8 at one point in time when two big companies merge ;) Michel Py wrote: A protocol that would be only v4 with more bits in the first place, with routers / NAT boxes that would pad/unpad extra zeroes (also including extra TBD fields). As this would be 100% compatible with v4 this could be deployed without too many headaches. (I almost got lost in the attribution level here) Then why is IPv6 causing so many headaches? As one can see 6to4 is mostly making up your IPv4+ address from the IPv4 one by doing: 2002 + ipv4 address + padding bytes ;) Ah, of course, one actually need to upgrade most of the internal stuff and upgrade all the applications, convince managers, get money to do it, do training etc... Also for the rest of the thread, overlaying IPv6 over IPv4: RFC4380 Which is more or less a p2p overlay network using IPv6 as the addressing part and thus leveraging a lot of applications already. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Mon, Mar 27, 2006 at 11:35:21PM -0500, Keith Moore wrote: now if what you're saying is that we need a standard NAT extension protocol that does that, I might agree. though IMHO the easiest way to do that is to make the NAT boxes speak IPv6. Yes, I am saying we need this or something similar. It seems like the current solution I've seen implemented is something like static port mapping with private ip space behind the NAT for most applications. There's still the limited known ports issue (discussed earlier) among several others which are as yet either unsolved or unimplemented on the global scale. again, this doesn't really solve the problem - it only nibbles off a small corner of it. NATs do harm in several different ways - they take away a uniform address space, they block traffic in arbitrary directions, they hamper appropriate specification of security policies, and these days they often destroy transparency. You have to fix all of those problems and still preserve (improve!) the plug-and-play nature of the NAT. what you end up with is something like a router that does both v4 and v6, autoconfiguring itself in both cases (including getting address blocks from upstream networks), with transparent v6, NAT on v4, a sort of generic IPv4 application socks-like proxy built into the NAT that lets v4-only apps allocate outside addresses/ports, accept connections on them, and also initiate connections from them. This sounds workable. But I really question whether there is an adequate userbase who cares enough about these problems enough to support the development and deployment of the more complex system you suggest. 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. The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. When address space becomes a more scarce resource globally will they care enough about the limitations above and beyond what bizarre NAT hacks marginally solve to fund ipv6 implementation? Maybe. I haven't seen any evidence of it yet, but maybe some time in the future they will. Austin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue Mar 28 11:33:27 2006, 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. Ah, but there's more. NAT is sold as a firewalling solution, not as a cheap hack to share a single-user DSL. The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. The first time I saw NAT outside of the hacker-at-home was in a reasonably sized ISP, about ten years ago. Since NAT is sold as a foolproof plug-and-play firewall - the lack of global addressability is promoted as an advantage - then larger organizations do use it. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
If you can't provide the functionality that the customers want your protocol purity comes down to 'you have to do it our way, oh and by the way we have no interest in listening to you'. which is why some of us wrote draft-ietf-v6ops-nap Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Mar 28, 2006, at 5:50 AM, Dave Cridland wrote: On Tue Mar 28 11:33:27 2006, 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. Ah, but there's more. NAT is sold as a firewalling solution, not as a cheap hack to share a single-user DSL. NAT may be sold as a firewalling solution, but that doesn't make it so. Regards Marshall The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. The first time I saw NAT outside of the hacker-at-home was in a reasonably sized ISP, about ten years ago. Since NAT is sold as a foolproof plug-and-play firewall - the lack of global addressability is promoted as an advantage - then larger organizations do use it. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... the overlay networks depend on having some hosts that aren't behind a NAT to serve as tunnel endpoints for hosts that do. this will become less viable in the future as IPv4 address space gets more and more scarce. also, for the most part, overlay networks do not perform as well as native networks (there are exceptions, as in bittorrent). so they do not abstract (all of) the shortcomings away. OTOH, one transition path away from NATs might be to extend NATs so that they support creation of overlay networks. such devices could also aid v4/v6 coexistence. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Hello; On Mar 27, 2006, at 11:13 PM, Anthony G. Atkielski wrote: Keith Moore writes: NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. I hardly think so, but in any case, the solution is pretty simple: give out IP addresses for free, instead of charging an arm and a leg for anything other than a single address. As long as ISPs won't provide multiple addresses, or won't provide them except at unreasonably high prices, NAT will remain. This is connected to IPv6 address assignment policies at your friendly local RIR. I would urge that people who are interested in this issue in the ARIN region join the PPML mailing list and even consider coming the Montreal ARIN meeting next month. There are two proposals coming up, 2005-1 and 2006-4, which would both relax the assignment of PI IPv6 space. Regards Marshall Eubanks ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote: Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? I think there will be IPv6 NAT, because some people will want it. That doesn't mean it's rational to deploy it :) See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt Remember: Users don't read drafts/RFCs. And users don't walk into PC World and say 'I'd like a NAT router for my home network please'. They probably ask for a broadband modem, or something that doesn't specify NAT. We have deployed IPv6 in our enterprise (throughout). 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. The 'cost' is real terms is not that high. We have had to invest time in updating OSS-type elements, but much of the rest comes 'out of the box'. I guess we would have had some training costs as a 'normal' enterprise, but we've helped address that in the academic community by running hands-on IPv6 workshops (just as the Internet2 people do for their community). Phillip, there a few (such as: NAT typically requires hard state, which is a pain to replicate if there is more than one edge router). NAT is not completely evil, but it's far from being clean. Pretending that there are no good reasons against NAT is going to achieve the same as trying to eliminate it: nothing. 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. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. And there's always IPv8 ;) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
