Re: [arin-announce] IPv4 Address Space (fwd)
Are you actually saying that providers in the middle should build their networks to accommodate any amount of DDOS traffic their ingress can support instead of filtering it at their edge? How do you expect them to pay for that? Do you really want $10,000/megabit transit costs? Owen --On Friday, October 31, 2003 7:43 AM -0500 Alex Yuriev [EMAIL PROTECTED] wrote: It is content filtering. You are filtering packets that you think are causing problems to the ES that you may not control. No, he said quite clearly he's filtering packets (such as Nachi ICMP) that are causing harm to *his* network. He gets to make a choice - filter the known problem packets so the rest of the traffic can get through, or watch the network melt down and nobody gets anything. He needs to fix his network so those 92 byte ICMP packets wont break it. Alex -- If it wasn't signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
Are you actually saying that providers in the middle should build their networks to accommodate any amount of DDOS traffic their ingress can support instead of filtering it at their edge? How do you expect them to pay for that? Do you really want $10,000/megabit transit costs? I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? Fix the networks. Force the customers to play by the rules. Alex
RE: [arin-announce] IPv4 Address Space (fwd)
I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? GM seems to still be building cars and trucks, and Nader lost a presidential election. Which lesson were we supposed to learn? Matthew Kaufman [EMAIL PROTECTED]
RE: [arin-announce] IPv4 Address Space (fwd)
I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? GM seems to still be building cars and trucks, and Nader lost a presidential election. GM seems to also have cut a very big check to pay the judgements. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
Date: Tue, 28 Oct 2003 21:51:01 -0500 From: [EMAIL PROTECTED] The real problem is that we have an environment where the malware can figure out how to disable the firewall but the user can't. And part of why the current Internet has so much peer-to-peer traffic on it. ;-) Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: [arin-announce] IPv4 Address Space (fwd)
JB Date: Wed, 29 Oct 2003 15:27:27 -0600 JB From: Jack Bates JB I think the point that was being made was that NAT allows the JB filtering of the box to be more idiot proof. Firewall rules JB tend to be complex, which is why mistakes *do* get made and JB systems still get compromised. NAT interfaces and setups JB tend to be more simplistic, and the IP addresses of the JB device won't route publicly through the firewall or any JB unknown alternate routes. NAT security is a byproduct of NAT's stateful filtering. One can accomplish the same effect with check-state allow ip any any recv internal0 keep-state deny ip any any Such a default fw config would be equally idiot-proof with no IP obfuscation. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: [arin-announce] IPv4 Address Space (fwd)
That was _exactly_ the point I was attempting to make. If you recall there was a case recently where a subcontractor at a power generation facility linked their system to an isolated network which gave unintentional global access to the isolated network. a NAT at the subcontrator's interface would have prevented this. Scott C. McGrath On Wed, 29 Oct 2003, Jack Bates wrote: David Raistrick wrote: You seem to be arguing that NAT is the only way to prevent inbound access. While it's true that most commercial IPv4 firewalls bundle NAT with packet filtering, the NAT is not required..and less-so with IPv6. I think the point that was being made was that NAT allows the filtering of the box to be more idiot proof. Firewall rules tend to be complex, which is why mistakes *do* get made and systems still get compromised. NAT interfaces and setups tend to be more simplistic, and the IP addresses of the device won't route publicly through the firewall or any unknown alternate routes. -Jack
Re: [arin-announce] IPv4 Address Space (fwd)
On Thu, 2003-10-30 at 09:22, Scott McGrath wrote: That was _exactly_ the point I was attempting to make. If you recall there was a case recently where a subcontractor at a power generation facility linked their system to an isolated network which gave unintentional global access to the isolated network. a NAT at the subcontrator's interface would have prevented this. So would have a stateful firewall set to keep state, default deny inbound. This is how customer grade firewall products should work with NAT disabled, although they probably don't. -Paul -- Paul Timmins [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
Leave content filtering to the ES, and *force* ES to filter the content. Its not content filtering, I'm not filtering only certain html traffic (like access to porn sites), I'm filtering traffic that is causing harm to my network and if I know what traffic is causing problems for me, I'll filter it first chance I get. It is content filtering. You are filtering packets that you think are causing problems to the ES that you may not control. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
Recently, [EMAIL PROTECTED] (Alex Yuriev) wrote: Leave content filtering to the ES, and *force* ES to filter the content. Its not content filtering, I'm not filtering only certain html traffic (like access to porn sites), I'm filtering traffic that is causing harm to my network and if I know what traffic is causing problems for me, I'll filter it first chance I get. It is content filtering. You are filtering packets that you think are causing problems to the ES that you may not control. Alex Alex, please re-read the first paragraph. He said I'm filtering traffic that is causing harm to *my* network... (emphasis mine). He's not filtering out packets he thinks are causing problems to the ES, he's filtering out packets that are causing him problems directly, as the IS. Matt
Re: [arin-announce] IPv4 Address Space (fwd)
Alex, please re-read the first paragraph. He said I'm filtering traffic that is causing harm to *my* network... (emphasis mine). He's not filtering out packets he thinks are causing problems to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
At 02:41 PM 10/30/2003, Alex Yuriev wrote: Alex, please re-read the first paragraph. He said I'm filtering traffic that is causing harm to *my* network... (emphasis mine). He's not filtering out packets he thinks are causing problems to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Do you have a generator in your colo/server space? Why? To follow your logic out, should you not simply be *forcing* the Electric Company to provide power and hold it responsible for not doing so? ( Hmm, no that is slightly different as you are direct customer ). Better example if you are UPS and a package being shipped is emitting RF that is interferring with your plane avionics, should you not remove that package from the shipment ( filter it out, as it were )? Or do you simply carry on and crash the plane, destroying the other packages onboard and simply try to hold the sender of the bad package responsible? It is sound business logic that if something is impacting your ability to provide service *and* you are provided with the means to address the problem, that you should utilize those means ( w/ in the extent allowed by the law and your legal agreements ). -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net
Re: [arin-announce] IPv4 Address Space (fwd)
to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Do you have a generator in your colo/server space? Why? To follow your logic out, should you not simply be *forcing* the Electric Company to provide power and hold it responsible for not doing so? ( Hmm, no that is slightly different as you are direct customer ). I am so glad that you used that example. The way currently people propose everyone operates is equivalent to a company that transmits AC to customer deciding that some part of the AC waveform is harmful to its equipment, and therefore should be filtered out. Of course, no one bothers to tell the customer that the filter exists, or what is being filtered, or when, or how. Better example if you are UPS and a package being shipped is emitting RF that is interferring with your plane avionics, should you not remove that package from the shipment ( filter it out, as it were )? Another excellent example - UPS will not remove that. The shipper will. It is sound business logic that if something is impacting your ability to provide service *and* you are provided with the means to address the problem, that you should utilize those means ( w/ in the extent allowed by the law and your legal agreements ). The first part of any legal agreement establishes the parties subject to it. That is exactly what you are missing while being an IS. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
At 03:25 PM 10/30/2003, Alex Yuriev wrote: to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Do you have a generator in your colo/server space? Why? To follow your logic out, should you not simply be *forcing* the Electric Company to provide power and hold it responsible for not doing so? ( Hmm, no that is slightly different as you are direct customer ). I am so glad that you used that example. The way currently people propose everyone operates is equivalent to a company that transmits AC to customer deciding that some part of the AC waveform is harmful to its equipment, and therefore should be filtered out. Of course, no one bothers to tell the customer that the filter exists, or what is being filtered, or when, or how. So, electric grids do not have any mechanisms to disconnect from other grids ( ie, stop transiting their electricity ) if one is doing something that causes problems on the local grid? As a customer I would very much like my provider to filter out waveforms that would prevent their ability to provide me with my service. If the issue is how to communicate what is being filtered to the customer, then simply need to find a way to do that. The solution to it is hard to communicate what is being filtered to the end-users is not oh well, we won't filter anything. At least not as I see it. Supposing a network *did* provide a way to inform customers what was being filtered. Would you still object to the filtering? Another excellent example - UPS will not remove that. The shipper will. How? I'm the shipper. I put the RF generating device into package and give it to UPS. They will do nothing to remove it or not ship it? It is only up to me to not do it? Al Qaeda would love that to be true I'm sure. :) The first part of any legal agreement establishes the parties subject to it. That is exactly what you are missing while being an IS. There is a chain of agreements connecting you to the source/dest of any traffic on your network. Even if it is a customer of a customer of a customer, you have a chain of agreements that establishes you as a party. In what scenario would there not be a chain of agreements to connect you as a party? -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net
Re: [arin-announce] IPv4 Address Space (fwd)
On Thu, 30 Oct 2003 12:12:22 EST, Alex Yuriev said: Leave content filtering to the ES, and *force* ES to filter the content. Its not content filtering, I'm not filtering only certain html traffic (like access to porn sites), I'm filtering traffic that is causing harm to my network and if I know what traffic is causing problems for me, I'll filter it first chance I get. It is content filtering. You are filtering packets that you think are causing problems to the ES that you may not control. No, he said quite clearly he's filtering packets (such as Nachi ICMP) that are causing harm to *his* network. He gets to make a choice - filter the known problem packets so the rest of the traffic can get through, or watch the network melt down and nobody gets anything. pgp0.pgp Description: PGP signature
RE: [arin-announce] IPv4 Address Space (fwd)
Christian: And I bet then still somebody will build an IPv6 NAT box for some bizarro reason. ftp://ftp.rfc-editor.org/in-notes/rfc2766.txt Gary Blankenship Foundry Networks (Japan)
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, Oct 29, 2003 at 10:06:37AM +0100, Stefan Mink wrote: Does anybody honestly think companies will commit the capex needed to implement IPv6? Not without additional benefits. We need either applications that are working a lot better at ipv6 or we may yet have to see ipv4 space ran out before it becomes clear to everybody that ipv6 is a must. imagine a network without NAT. I stopped counting applications that are struggling/breaking with NAT... But many people still believe rfc1918 and NAT are a cool thing because they just got used to it... They're a cool thing for other reasons. If more IP addresses is the only motivation for using IPv6, it's really not enough. For environments where direct access to the internet isn't required, NAT serves perfectly well. There's also no *need* to use public IP's on a private internal-only network either, so it makes little sense to do so. The way I see it, there are a lot of reasons not to use IPv6..
Re: [arin-announce] IPv4 Address Space (fwd)
Avleen Vig wrote: If more IP addresses is the only motivation for using IPv6, it's really not enough. For environments where direct access to the internet isn't required, NAT serves perfectly well. IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT, doesn't it?
Re: [arin-announce] IPv4 Address Space (fwd)
No. Anything that relies on knowing which host it is talking to by looking at the source address of packets breaks. Plenty of UDP based apps work over NAT. Simon On Wed Oct 29, 2003 at 10:57:35AM -, Dave Howe wrote: Avleen Vig wrote: If more IP addresses is the only motivation for using IPv6, it's really not enough. For environments where direct access to the internet isn't required, NAT serves perfectly well. IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT, doesn't it? -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote: No. Anything that relies on knowing which host it is talking to by looking at the source address of packets breaks. Plenty of UDP based apps work over NAT. Indeed, and IPSec tunnels are frequently done between routers on networks, rather than individual hosts on networks (at least in most multi-site enterprises i've seen).
Re: [arin-announce] IPv4 Address Space (fwd)
Simon Lockhart wrote: Anything that relies on knowing which host it is talking to by looking at the source address of packets breaks. Indeed. Novell networking for example - or MS Exchange New Mail notification. of course, you shouldn't be doing either on the internet, but a common small branch office solution involves ADSL, NAT and a single VPN client Plenty of UDP based apps work over NAT. depends a lot on the nat - if the UDP app isn't port-specific, then often a smart nat can create a virtual map for it (and IPSec NAT traversal often relies on a single internal initiator creating such a map on the nat device, and the destination not minding too much) If the outside sender expects the recipient to be on a fixed port though, often the best you can hope for is that *one* internal host can receive data.
Re: [arin-announce] IPv4 Address Space (fwd)
Avleen Vig wrote: Indeed, and IPSec tunnels are frequently done between routers on networks, rather than individual hosts on networks (at least in most multi-site enterprises i've seen). Indeed so yes - however... A large and increasing segment of my users are VPN laptop users with ADSL at home. our accounts department looks a certain amount of askance at IT when they get a large phone bill in expenses for someone using a 33.6 modem right next to a nice shiny half meg ADSL connection that IPSec won't traverse
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Avleen Vig wrote: Indeed, and IPSec tunnels are frequently done between routers on networks, rather than individual hosts on networks (at least in most multi-site enterprises i've seen). The most common use of VPN links is the roadwarrior. IPSEC in this context is broken badly by NAT. Even when the extensive hackery required to workaround NAT is enabled, it still can not work in the case where two roadwarriors are behind a single address connecting to the same VPN gateway.
Re: [arin-announce] IPv4 Address Space (fwd)
Kuhtz, Christian wrote: And there are workarounds for all those. NAT-T for ipsec is really intended for endnodes only - which is fine if you are doing the NAT yourself (typical medium/large company scenario - internal users shouldn't be using IPSEC, that is done at the gateway/firewall) but sucks if your cable or xDSL ISP decides NAT is the way to go. (usually followed by a well, you shouldn't need two or more nodes there/want to run a server/care about SIP, a business should pay for a DEDICATED link for a little three-man sales office in the backend of nowhere) But regardless, all the workarounds are doing is trying to patch the fact that UDP dependent connections are not NAT friendly by special-casing (or app-layer proxying) particular instances of UDP in a way that doesn't drop dead TOO often
RE: [arin-announce] IPv4 Address Space (fwd)
Seems several commercial clients (such as Cisco's VPN client) offer workaround for that (tunneling IPSEC in a TCP session). Works great. -Original Message- From: Greg Maxwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 9:56 AM To: Avleen Vig Cc: Simon Lockhart; Dave Howe; Email List: nanog Subject: Re: [arin-announce] IPv4 Address Space (fwd) On Wed, 29 Oct 2003, Avleen Vig wrote: Indeed, and IPSec tunnels are frequently done between routers on networks, rather than individual hosts on networks (at least in most multi-site enterprises i've seen). The most common use of VPN links is the roadwarrior. IPSEC in this context is broken badly by NAT. Even when the extensive hackery required to workaround NAT is enabled, it still can not work in the case where two roadwarriors are behind a single address connecting to the same VPN gateway. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.60
Re: [arin-announce] IPv4 Address Space (fwd)
Dave Howe wrote: Indeed so yes - however... A large and increasing segment of my users are VPN laptop users with ADSL at home. our accounts department looks a certain amount of askance at IT when they get a large phone bill in expenses for someone using a 33.6 modem right next to a nice shiny half meg ADSL connection that IPSec won't traverse IPSec can traverse NAT. Often times, it's the implementation of IPSec that doesn't traverse NAT. Software vendors apparently didn't think it necessary to allow for address translation. Tis sad, really. I have customers that can VPN through NAT and customers that require public addressing. The one's that really make me laugh seem to require a static IP address. Of course, the customer is always right. -Jack
Re: [arin-announce] IPv4 Address Space (fwd)
Kuhtz, Christian wrote: Seems several commercial clients (such as Cisco's VPN client) offer workaround for that (tunneling IPSEC in a TCP session). Works great. Yup. there are various proprietary solutions that require us to trash out an expensive and *working* VPN-1 solution, buy an equally expensive and unfamilar solution, and retrain our salesforce in the use of the new software - just to work around NAT. Nice, isn't it?
RE: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Kuhtz, Christian wrote: Seems several commercial clients (such as Cisco's VPN client) offer workaround for that (tunneling IPSEC in a TCP session). Works great. I'm sure I could also setup a PPPoEmail shim that would bypass most of these problems.. Who needs routers with PBR when you have sendmail with m4 configuration! The fact that something can be worked around with enough footwork really doesn't make okay. Consider the congestion related behavior of TCP inside TCP. Consider the additional perpacket overhead of TCP encap, and the effect of the additional fragmentation that will happen since few networks will pass datagrams over 1500 bytes. If networks operators had demanded IPv6 in the past far more products today would be enabled and the 'upgrades are expensive' argument would be moot. Simply passing the buck to the customer is not a globally wise solution.
RE: [arin-announce] IPv4 Address Space (fwd)
The fact that something can be worked around with enough footwork really doesn't make okay. Sure. Neither is it ok for VPN vendors to pretend as if NAT wasn't a part of daily life and reality. Consider the congestion related behavior of TCP inside TCP. Consider the additional perpacket overhead of TCP encap, and the effect of the additional fragmentation that will happen since few networks will pass datagrams over 1500 bytes. So? So fragmentation will happen. Look at all the existing DSL etc infrastructures where you do have to live with MTU molestations. Frag happens. So what. It still works nicely. What are we gonna do next? Whine about broken PMTUD? If networks operators had demanded IPv6 in the past far more products today would be enabled and the 'upgrades are expensive' argument would be moot. Simply passing the buck to the customer is not a globally wise solution. Sure. Simply ignoring present reality isn't a globally wise solutions. Hence we have broken VPN products incapable of dealing with NAT. Some are capable of dealing with NAT just fine, and are readily available. Enough said. VPN vendors incapable of dealing with NAT (which is really a quite simple fix, totally independent of the NAT box) should be terminated with extreme prejudice. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.61
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003 15:10:18 GMT, Dave Howe [EMAIL PROTECTED] said: but sucks if your cable or xDSL ISP decides NAT is the way to go. (usually followed by a well, you shouldn't need two or more nodes there/want to run a server/care about SIP, a business should pay for a DEDICATED link for a little three-man sales office in the backend of nowhere) Or the road warrior case. If you send 3 engineers to Detroit and they end up at the wrong hotel. But regardless, all the workarounds are doing is trying to patch the fact that UDP dependent connections are not NAT friendly by special-casing (or app-layer proxying) particular instances of UDP in a way that doesn't drop dead TOO often People are continually managing to make bears dance, and are surprised when said bears decide it's time to voice their opinions on the matter pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
Kuhtz, Christian wrote: Kuhtz, Christian wrote: Seems several commercial clients (such as Cisco's VPN client) offer workaround for that (tunneling IPSEC in a TCP session). Works great. Yup. there are various proprietary solutions that require us to trash out an expensive and *working* VPN-1 solution, buy an equally expensive and unfamilar solution, and retrain our salesforce in the use of the new software - just to work around NAT. Nice, isn't it? And you can continue daydreaming and believe NAT will go away if you continue to whine about it. Or I can make sure that the services my company buys, either for itself or for its sales force, don't make life harder for us just to make life easier for the supplier. XYZ insists that you route though their NAT? fine, company ABC don't, and they get the business. If I have to put up with NAT getting in the way of NAT-unfriendly applications, then fine - I will work around it when I can, find alternatives when I can't. Doesn't stop me bitching about it though - which at least serves the useful task of letting someone else thinking of investing in (say) VPN-1 know that the problems are out there. And I bet then still somebody will build an IPv6 NAT box for some bizarro reason. Probably the same idiots who market a NATted dialup as a security enhanced connection
Re: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 09:35:13AM -0600, Kuhtz, Christian wrote: Simply ignoring present reality isn't a globally wise solutions. Hence we have broken VPN products incapable of dealing with NAT. Some are capable of dealing with NAT just fine, and are readily available. Enough said. The danger here isn't that it can be made to work, but that as network operators we are driving application vendors to a very dangerous lowest common denominator. The VPN people have already figured out: A) The technology must run over a TCP connection that encodes no local endpoint information so it can pass through NAT. B) The technology must be able to run on TCP port 80 to bypass overly restrictive filters. Other applications are doing the same. Many of the file sharing services can already meet both of these points. The end result is that in the near future it will be much harder, or impossible for network operators to collect statistics based on traffic type or to filter particular types of traffic without being able to dig into the payload itself and see what type of traffic is passing. Some people see this as a problem, some do not. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
No. IPSEC and SIP break because their payloads include information that is dependent on the IP address header. In the case of IPSEC, this is to support end-to-end authentication and avoid certain kinds of man-in- the-middle attacks. In the case of SIP, it's because SIP is a call setup protocol which facilitates the creation of an RTP session. It's much the same problem as FTP. The reason FTP doesn't BORK is because most NAT gateways understand about the need to proxy FTP and because PASSIVE mode FTP doesn't have the same call-setup problems. In the case of IPSEC, there is an IPSEC standard for NAT traversal. It allows for a slight compromise in the end-to-end security while still preserving most of the capabilities of IPSEC. UDP works just fine through NAT, as evidenced by DNS and other protocols that aren't inherently broken with NAT. (Of course, DNS could suffer from the same effects as SIP on some levels since the contents of the DNS A record answers may be dependent on an un-natted world). Owen --On Wednesday, October 29, 2003 10:57 AM + Dave Howe [EMAIL PROTECTED] wrote: Avleen Vig wrote: If more IP addresses is the only motivation for using IPv6, it's really not enough. For environments where direct access to the internet isn't required, NAT serves perfectly well. IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT, doesn't it? -- If it wasn't signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
Right... Forgot about the SNMP breakage. SIP doesn't depend on knowing which host it's talking to from the source address, but, it does depend on being able to assign RTP session parameters based on IP addresses contained within the SIP payload. Thus, when the SIP payload goes through a NAT box and the payload is not modified accordingly, the RTP session rarely works out right. Owen --On Wednesday, October 29, 2003 11:03 AM + Simon Lockhart [EMAIL PROTECTED] wrote: No. Anything that relies on knowing which host it is talking to by looking at the source address of packets breaks. Plenty of UDP based apps work over NAT. Simon On Wed Oct 29, 2003 at 10:57:35AM -, Dave Howe wrote: Avleen Vig wrote: If more IP addresses is the only motivation for using IPv6, it's really not enough. For environments where direct access to the internet isn't required, NAT serves perfectly well. IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT, doesn't it? -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK -- If it wasn't signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
However, what is authenticated in the IPSEC datagrams is the addresses of the IKE gateways (the routers). The fact that an entire netblock exists within the tunnel is not especially relevant to the part that suffers from NAT breakage. Owen --On Wednesday, October 29, 2003 3:14 AM -0800 Avleen Vig [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote: No. Anything that relies on knowing which host it is talking to by looking at the source address of packets breaks. Plenty of UDP based apps work over NAT. Indeed, and IPSec tunnels are frequently done between routers on networks, rather than individual hosts on networks (at least in most multi-site enterprises i've seen). -- If it wasn't signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
And sometimes you use NAT because you really do not want the NAT'ed device to be globally addressible but it needs to have a link to the outside to download updates. Instrument controllers et.al. The wisdom of the design decision to use the internet as the only method to provide software updates is left for individual cogitation. (and no I am not talking about Win[*] products here) Scott C. McGrath
Re: [arin-announce] IPv4 Address Space (fwd)
In article [EMAIL PROTECTED], Scott McGrath [EMAIL PROTECTED] wrote: And sometimes you use NAT because you really do not want the NAT'ed device to be globally addressible but it needs to have a link to the outside to download updates. Instrument controllers et.al. I don't understand. What is the difference between a /24 internal NATted network, and a /64 internal IPv6 network that is firewalled off: only paclets to the outside allowed, and packets destined for the inside need to have a traffic flow associated with it. As I see it, NAT is just a stateful firewall of sorts. A broken one, so why not use a non-broken solution ? We can only hope that IPv6 capable CPE devices have that sort of stateful firewalling turned on by default. Or start educating the vendors of these el-cheopo CPE devices so that they will all have that kind of firewalling enabled before IPv6 becomes mainstream. Mike.
RE: [arin-announce] IPv4 Address Space (fwd)
The end result is that in the near future it will be much harder, or impossible for network operators to collect statistics based on traffic type or to filter particular types of traffic without being able to dig into the payload itself and see what type of traffic is passing. Some people see this as a problem, some do not. Isn't that the whole point of running a VPN connection? * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.61
RE: [arin-announce] IPv4 Address Space (fwd)
In article [EMAIL PROTECTED] arvard.edu, Scott McGrath [EMAIL PROTECTED] wrote: And sometimes you use NAT because you really do not want the NAT'ed device to be globally addressible but it needs to have a link to the outside to download updates. Instrument controllers et.al. I don't understand. What is the difference between a /24 internal NATted network, and a /64 internal IPv6 network that is firewalled off: only paclets to the outside allowed, and packets destined for the inside need to have a traffic flow associated with it. As I see it, NAT is just a stateful firewall of sorts. A broken one, so why not use a non-broken solution ? You forget the effort required to overcome the inherent inertia of expenditure required to use the non-broken solution... We can only hope that IPv6 capable CPE devices have that sort of stateful firewalling turned on by default. Or start educating the vendors of these el-cheopo CPE devices so that they will all have that kind of firewalling enabled before IPv6 becomes mainstream. CPE devices are already available.. POP gear is available. Dedicated access shouldn't be a problem. Forget dial, what's the point.. The gear that worries me is inbetween the PE and the CPE for broadband connections. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.60
Re: [arin-announce] IPv4 Address Space (fwd)
Life would be much simpler without NAT howver there are non-computer devices which use the internet to get updates for their firmware that most of us would prefer not to be globally reachable due to the human error factor i.e. Oops forgot a rule to protect X. The radar on your cruise ship uses an IP network to communicate with the chartplotter, GPS, depthsounder do you really want _this_ gear globally reachable via the internet?. Remember if it's globally reachable it is subject to compromise. A good example of this is building control systems which get firmware updates via FTP from their maker. Usually there is no manual system for updating them offline and allowing them to be disconnected from the internet as in my opinion they _should_ be. NAT is not security just look what you can do with sFlow to identify machines behind a NAT. NAT is useful for machines which need to periodically make a connection to perform some function involving the network. This class of devices should not have a globally routable address because in many cases security on them is less than an afterthought (short fixed passwords no support for secure protocols, etc) The other case as pointed out by another poster is overlapping networks which need NAT until a renumbering can be accomplished. Scott C. McGrath On Wed, 29 Oct 2003, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Scott McGrath [EMAIL PROTECTED] wrote: And sometimes you use NAT because you really do not want the NAT'ed device to be globally addressible but it needs to have a link to the outside to download updates. Instrument controllers et.al. I don't understand. What is the difference between a /24 internal NATted network, and a /64 internal IPv6 network that is firewalled off: only paclets to the outside allowed, and packets destined for the inside need to have a traffic flow associated with it. As I see it, NAT is just a stateful firewall of sorts. A broken one, so why not use a non-broken solution ? We can only hope that IPv6 capable CPE devices have that sort of stateful firewalling turned on by default. Or start educating the vendors of these el-cheopo CPE devices so that they will all have that kind of firewalling enabled before IPv6 becomes mainstream. Mike.
Re: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Christian wrote: Isn't that the whole point of running a VPN connection? Yes. What I'm saying is network operators are slowly forcing everyone to run _everything_ over a VPN like service. That's fine, but it makes network operators unable to act on the traffic at the same level they can today. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Scott McGrath wrote: Life would be much simpler without NAT howver there are non-computer devices which use the internet to get updates for their firmware that most of us would prefer not to be globally reachable due to the human error factor i.e. Oops forgot a rule to protect X. snip A good example of this is building control systems which get firmware updates via FTP from their maker. Usually there is no manual system for updating them offline and allowing them to be disconnected from the internet as in my opinion they _should_ be. NAT is certianly not the only way to restrict this sort of access. For your ship example (snipped) an isolated network is best. For your building control systems a firewall preventing inbound access, instead of a NAT device, should be your control of choice. This class of devices should not have a globally routable address because in many cases security on them is less than an afterthought (short fixed passwords no support for secure protocols, etc) routable =! reachable. Restrict inbound access to your networks as needed, with or without NAT, IPv4 or IPv6. For legacy IPv4 networks that haven't been renumbered to IPv6, use a 4to6 gateway. You seem to be arguing that NAT is the only way to prevent inbound access. While it's true that most commercial IPv4 firewalls bundle NAT with packet filtering, the NAT is not required..and less-so with IPv6. ...david --- david raistrick [EMAIL PROTECTED] http://www.expita.com/nomime.html
RE: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Christian wrote: Isn't that the whole point of running a VPN connection? Yes. What I'm saying is network operators are slowly forcing everyone to run _everything_ over a VPN like service. That's fine, but it makes network operators unable to act on the traffic at the same level they can today. How do they act on it today? If you want a diff served VPN or anything done to something in it, you're going to have to sign up for a service that can do that.. Or mark your vpn streams on the outside accordingly... You can do that with IPSEC in TCP by marking the wrapper if you wish.. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.60
Re: [arin-announce] IPv4 Address Space (fwd)
David Raistrick wrote: You seem to be arguing that NAT is the only way to prevent inbound access. While it's true that most commercial IPv4 firewalls bundle NAT with packet filtering, the NAT is not required..and less-so with IPv6. I think the point that was being made was that NAT allows the filtering of the box to be more idiot proof. Firewall rules tend to be complex, which is why mistakes *do* get made and systems still get compromised. NAT interfaces and setups tend to be more simplistic, and the IP addresses of the device won't route publicly through the firewall or any unknown alternate routes. -Jack
Re: [arin-announce] IPv4 Address Space (fwd)
Owen DeLong wrote: It's much the same problem as FTP. The reason FTP doesn't BORK is because most NAT gateways understand about the need to proxy FTP and because PASSIVE mode FTP doesn't have the same call-setup problems. Passive mode has the same problems that PORT FTP does. It just pushes the problems to the server end. If you put a FTP server behind a NATed address, you'll need to proxy PASV (and also inverse to the client behind NAT, PORT needs none at the server end). -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Chris= tian wrote: Isn't that the whole point of running a VPN connection? Yes. What I'm saying is network operators are slowly forcing everyone to run _everything_ over a VPN like service. That's fine, but it makes network operators unable to act on the traffic at the same level they can today. Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ I think the other point that may be escaping some people, is that as more and more connections take on this VPN-like quality, as network operators we lose any visibility into the validity of the traffic itself. Imagine how much more painful SQL Slammer would have been, if all the traffic was encapsulated in port 80 between sites, and only hit port 1434 locally? We'd suddenly be unable to quickly filter out the worm traffic, and would instead see only that our port 80 traffic was now eating our network alive--and we certainly couldn't get away with filtering that out. We'd have no choice but to build our networks large enough to handle the largest sized worm outbreak, as we'd have no option but to carry the traffic blindly from end to end, having no way to even begin to consider how to differentiate valid traffic from invalid traffic. At least today, we can decide that 92 byte ICMP echo-request packets are invalid, and drop them; or that for the most part, packets destined to port 1434 should be discarded as quickly as possible. If everything, include worm outbreaks, gets tunneled on port 80, get ready to loosen the purse strings, because there's no alternative other than add more capacity. If I were more of a conspiracy theorist, I might think that the router vendors and long-haul fiber providers might be rubbing their hands gleefuly in the background, funnelling dollars into the VPN marketplace to fund more and more products that do exactly that...it would certainly be one way to ensure that the demand for larger pipes and faster routers stays high for the next decade or so, until OS vendors learn to secure their software better. ^_^;; Matt happy to still be able to block IPs/ports at his own discretion
Re: [arin-announce] IPv4 Address Space (fwd)
I think the other point that may be escaping some people, is that as more and more connections take on this VPN-like quality, as network operators we lose any visibility into the validity of the traffic itself. As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Imagine how much more painful SQL Slammer would have been, if all the traffic was encapsulated in port 80 between sites, and only hit port 1434 locally? How do you know which traffic is good and which traffic is evil? At least today, we can decide that 92 byte ICMP echo-request packets are invalid, and drop them; or that for the most part, packets destined to port 1434 should be discarded as quickly as possible. How does you IS know that a _particular_ ES uses port 1434 for? Alex
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Alex Yuriev wrote: As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Well, that is nice thery, but I'd like to see how you react to 2Gb DoS attack and if you really intend to put filters at the edge or would not prefer to do it at the entrance to your network. Slammer virus is just like DoS, that is why many are filtering it at the highiest possible level as well as at all points where traffic comes in from the customers. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Alex Yuriev wrote: As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Well, that is nice thery, but I'd like to see how you react to 2Gb DoS attack and if you really intend to put filters at the edge or would not prefer to do it at the entrance to your network. Slammer virus is just like DoS, that is why many are filtering it at the highiest possible level as well as at all points where traffic comes in from the customers. Actually, no, it is not theory. When you are slammed with N gigabits/sec of traffic hitting your network, if you do not have enough capacity to deal with the attack, no amount of filtering will help you, since by the time you apply a filter it is already too late - the incoming lines have no place for non-evil packets. Leave content filtering to the ES, and *force* ES to filter the content. Let IS be busy moving bits. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
Recently, [EMAIL PROTECTED] (Alex Yuriev) wrote: On Wed, 29 Oct 2003, Alex Yuriev wrote: As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Well, that is nice thery, but I'd like to see how you react to 2Gb DoS attack and if you really intend to put filters at the edge or would not prefer to do it at the entrance to your network. Slammer virus is just like DoS, that is why many are filtering it at the highiest possible level as well as at all points where traffic comes in from the customers. Actually, no, it is not theory. When you are slammed with N gigabits/sec of traffic hitting your network, if you do not have enough capacity to deal with the attack, no amount of filtering will help you, since by the time you apply a filter it is already too late - the incoming lines have no place for non-evil packets. And how many people here operate non-oversubscribed networks? I mean completely non-oversubscribed end to end; every end customer link's worth of capacity is reserved through the network from the customer edge access point, to the aggregation routers, through the core routers and backbone links out to the peering points, down to the border routers, and out through the peering ports? I've worked at serveral different companies, and none of them have run truly non oversubscribed networks; the economics just aren't there to support doing that. So having 3 Gb of DoS traffic coming across a half dozen peering OC48s isn't that bad; but having it try to fit onto a pair of OC48s into the backbone that are already running at 40% capacity means you're SOL unless you filter some of that traffic out. And I've been in that situation more times than I'd like to remember, because you can't justify increasing capacity internally from a remote peering point into the backbone simply to be able to handle a possible DoS attack. Even if you _do_ upgrade capacity there, and you carry the extra 3Gb of traffic from your peering links through your core backbone, and off to your access device, you suddenly realize that the gig port on your access device is now hosed. You can then filter the attack traffic out on the device just upstream of the access box, but then you're carrying it through your core only to throw it away after using up backbone capacity; why not discard it sooner rather than later, if you're going to have to discard it anyhow? Leave content filtering to the ES, and *force* ES to filter the content. Let IS be busy moving bits. Alex I think you'll find very, very few networks can follow that model; the IS component almost invariably has some level of statistical aggregation of traffic occurring that forces packet discard to occur during heavy attack or worm activity. And under those circumstances, there is a strong preference to discard bad traffic rather than good traffic if at all possible. One technique we currently use for making those decisions is looking at the type of packets; are they 92 byte ICMP packets, are they TCP packets destined for port 1434, etc. I'd be curious to see what networks you know of where the IS component does *no* statistical aggregation of traffic whatsoever. :) Matt
Re: [arin-announce] IPv4 Address Space (fwd)
Jack Bates wrote: David Raistrick wrote: You seem to be arguing that NAT is the only way to prevent inbound access. While it's true that most commercial IPv4 firewalls bundle NAT with packet filtering, the NAT is not required..and less-so with IPv6. I think the point that was being made was that NAT allows the filtering of the box to be more idiot proof. Firewall rules tend to be complex, which is why mistakes *do* get made and systems still get compromised. NAT interfaces and setups tend to be more simplistic, and the IP addresses of the device won't route publicly through the firewall or any unknown alternate routes. NAT for security is a bogus argument. NAT provides you nothing that a simple stateful firewall provides[0]. The only reason a firewall is less idiot proof, is because NAT has such limited capabilities. People may do more with a firewall simply because they can. If you want complex rules, look at what happens to a NAT set up when you want to set up a few static mappings. That's asking for trouble. For a firewall to hobble the hosts behind it like NAT does takes only a few simple rules. NAT also takes considerably more resources than a stateful firewall. [0] The only bonus in NAT is for the truly paranoid who want to hide their network topology. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Alex Yuriev wrote: application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Well, that is nice thery, but I'd like to see how you react to 2Gb DoS attack and if you really intend to put filters at the edge or would not prefer to do it at the entrance to your network. Slammer virus is just like DoS, that is why many are filtering it at the highiest possible level as well as at all points where traffic comes in from the customers. Actually, no, it is not theory. When you are slammed with N gigabits/sec of traffic hitting your network, if you do not have enough capacity to deal with the attack, no amount of filtering will help you, since by the time you apply a filter it is already too late - the incoming lines have no place for non-evil packets. This concept does not work on every network. You may very well have enough capacity to handle all the traffic from upstream provider (you probably don't want to and will ask them to filter as well) but actual line to the POP where customer is connected maybe smaller or even if you do have enough capacity to the POP, the extra traffic going there will greatly effect IGP routing on the network and may cause problems for customers in completely different cities. Leave content filtering to the ES, and *force* ES to filter the content. Its not content filtering, I'm not filtering only certain html traffic (like access to porn sites), I'm filtering traffic that is causing harm to my network and if I know what traffic is causing problems for me, I'll filter it first chance I get. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
Some would ask, What about increasing address usage? Only the ones who weren't at the ARIN meeting in Chicago where we saw a chart showing that monthly consumption of IP addresses continues to decrease as it has since around the year 2000. I would ask, What evidence do you have that usage is increasing? I would ask where's the evidence, period. Not much evidence in press articles and none in the ARIN article which was trying to tell people where to find evidence, not to make a case on the evidence. You've all heard of the CIDR report from http://www.potaroo.net Has anyone checked the articles there about IPv4 consumption trends? First written in July http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html Then updated for RIPE in September http://www.potaroo.net/presentations/2003-09-04-V4-AddressLifetime.pdf This was also presented at the Chicago ARIN and the slides will likely be on the web in a few days. The bottom line is that there are three different models which may predict when we run out of IPv4 addresses. The models predict dates ranging from 2022 to 2045. None of the models predict an exact year, they all predict a range of 4 to 8 years and the above dates are the earliest and latest of those ranges. Does anybody have statistics for assigned-but-not-announced space? I'd be willing to bet there will be more and more dead space over the years, and in fact quite a bit of increasing usage is just churn. Some networks are actively growing these allocations. Does anybody honestly think companies will commit the capex needed to implement IPv6? Yes, because IPv6 is merely and incremental improvement, not a grand elegant solution to world hunger like ATM. Look at how we managed the incremental step of adding MPLS to our IPv4 networks. It was fairly painless because it uses the same boxes, the same people and the same management systems. And over time, the pain of doing MPLS is reduced because the bugs get worked out. Similarly, IPv6 is an incremental change that uses the same boxes, people and management systems. In fact, if you've put MPLS into your core, you only need to worry about IPv6 at the edge from the PE router to the CE router because you can use 6PE. The capex is being spent anyway by upgrading boxes to meet capacity needs. You didn't notice it but the new core boxes are all capable of IPv6 with a simple software feature upgrade. if the people of this Esteemed Forum can't agree that IPv6 is something that must happen ASAP, how will the PHBs (those who control the money) and the customers (those who control demand) ever be convinced? NANOG rarely takes the lead in new product development and driving market demand. Someone else will sort out that problem. Hell, I can't even convince myself that IPv6 is neccessary. Is anybody out there totally sold on IPv6, enough to evangelize it to anybody willing to listen? I mean, IPv6 is no CIDR... I know that I said IPv6 is an incremental change, but the world that it enables is not incremental. Imagine 30 years from now where the majority of people in the developed world have full two-way voice, video, and data communications capability seamlessly integrated into their clothing, their vehicles, their workplace cubicles and their homes. X10 is obsolete replaced by IPv6 over power networks and IPv6 over Bluetooth v.3. Networks are everywhere and it is common for even small devices to have multiple IPv6 addresses. My belt (containing the cellphone transceiver) will have 20 IPv6 addresses in 20 different subnets corresponding to 20 VPNs. If you know about today's SIP networks, it's like having a phone number in INOC-DBA, FWD, SIPPhone, IAXtel etc. Except that these will be IPv6 addresses because they aren't for voice traffic. One of the 20 VPNs will be for a heart-rate monitoring service that coordinates with my gym and my personal trainer. Another one might be for an insulin level monitor that connects to my physician and pharmacy. The pharmacist will know when the insulin pack in my shirt collar will be depleted and will dispatch a refill to my home automatically. That's the problem that IPv6 is intended to solve. Providers with foresight can begin the process of upgrading today so that when IPv6 really is needed they will have a headstart. I'm not suggesting that anyone should rush IPv6 into production today, but everyone on this list should be running internal IPv6 trial networks to facilitate training of their personnel and to ensure that people have the experience needed to make rational and informed decisions about IPv6. In 1995, the Internet, a.k.a. IPv4 networks, took off with a boom and left the legacy telcos in the dust. If you want to recreate that, then keep your heads in the sand and other people will do IPv6 leaving you in the dust when critical mass finally arrives. It's that simple. --Michael Dillon
RE: [arin-announce] IPv4 Address Space (fwd)
Does anybody honestly think companies will commit the capex needed to implement IPv6? William Leibzon wrote: Not without additional benefits. I agree, and they're all gone now. To my deepest regrets, IPv6 has become nothing more than IPv4 with more bits (it's actually worse than IPv4 as of today). Excuse my rambling and what some may consider heresy even :), but.. One question to ask is whether IPv6's approach is the right one, furthering a particular way of doing things rather than really reinventing itself. Do I really need global awareness of address space? Why isn't address space a tool, services is what you're really after, and why not build an infrastructure centered around context of a service rather than reachability of an address? If we're going thru all this trouble in providing support for it, why not make it a more revolutionary approach? Is it really realistic to have some of the features in IPv6 employed in the way they are designed? The debate around NAT in IPv6 circles clearly show that there's an (more or less) academic desire to expose every address on the planet to every other. Is that truly required by way of the way IPv4/v6 work today? There are very convincing arguments to be made to say that this isn't desirable and that I don't particularly want everybody to get to every address (and once you accept that unrestricted, 100% reachability of every globally assigned address is unrealistic, many of the arguments behind the need for vast address space go away..). I really don't necessarily care what somebody's address is, if or if not it gets translated, as long as reachability exists.. So, as long as I can make the service work, what does it matter? Per hop architectures do seem to work nicely. The addressing allocation debate and that we to this date do not have a fully functional and working 'multihoming address space to multiple providers' approach that matches reality is another problem to be solved. And notions that try to explain the need for multihoming away rather than admitting that strictly hierarchical address space may be a dead end path and that a new solution is needed, are disturbing to me. Both of the last points are real issues, IMHO, not just rambling. And, no, I don't have a solution to instantiate right now and here, but I do have some ideas as to what I would or would not like to see included in a solution. I'm not saying IPv6 is dead, but I think a leap, rather than an incremental improvement may be needed. Unless somebody actually does come up with an IPv6 killer app... My $.02, Christian * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.61
RE: [arin-announce] IPv4 Address Space (fwd)
On Tue, 28 Oct 2003, Kuhtz, Christian wrote: Excuse my rambling and what some may consider heresy even :), but.. One question to ask is whether IPv6's approach is the right one, furthering a particular way of doing things rather than really reinventing itself. Do I really need global awareness of address space? Why isn't address space a tool, services is what you're really after, and why not build an those who do not understand end-to-end are doomed to reimplement it, poorly.
RE: [arin-announce] IPv4 Address Space (fwd)
End-to-end requires that people writing the software at the end learn about buffer overruns (and other data-driven access violations) or program using tools that prevent such things. It is otherwise an excellent idea. Unfortunately, the day that someone decided their poorly-designed machine and operating system would be safer sitting behind a firewall pretty much marked the end of universal end-to-end connectivity, and I don't see it coming back for a long long time. Probably not on this Internet. IPv6 or not. Combine that with ISP pricing models (helped by registry policy) that encourage =1 IP address per household, and the subsequent boom in NAT boxes, and the fate is probably sealed. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Maxwell those who do not understand end-to-end are doomed to reimplement it, poorly.
Re: [arin-announce] IPv4 Address Space (fwd)
On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote: The bottom line is that there are three different models which may predict when we run out of IPv4 addresses. The models predict dates ranging from 2022 to 2045. None of the models predict an exact year, they all predict a range of 4 to 8 years and the above dates are the earliest and latest of those ranges. Ok, so let's assume 2022, for the sake of argument. That is, after all, nearly 20 years from now. Does anybody honestly think companies will commit the capex needed to implement IPv6? Yes, because IPv6 is merely and incremental improvement, not a grand elegant solution to world hunger like ATM. Look at how we managed the incremental step of adding MPLS to our IPv4 networks. It was fairly painless because it uses the same boxes, the same people and the same management systems. And over time, the pain of doing MPLS is reduced because the bugs get worked out. Yes, but did MPLS require different ASICs? Similarly, IPv6 is an incremental change that uses the same boxes, people and management systems. People need training (but not all that much), management systems need rewritten (not majorly), and boxes need hardware replacements to forward at line rate (CAPEX ALERT). In fact, if you've put MPLS into your core, you only need to worry about IPv6 at the edge from the PE router to the CE router because you can use 6PE. The capex is being spent anyway by upgrading boxes to meet capacity needs. You didn't notice it but the new core boxes are all capable of IPv6 with a simple software feature upgrade. Yes, but there will always be this issue of billions of dollars of exisiting, perfectly functional, unable-to-forward-v6-at-linerate routing gear. If you have a router completely filled with attached customers, why would you upgrade that router? You would buy another one for future new customers, but not upgrade the existing one. The new one might forward IPv6 at linerate, but the old one still doesn't, and there is still not sufficient motivation to upgrade that old router. NANOG rarely takes the lead in new product development and driving market demand. Someone else will sort out that problem. Yes, but the growing consensus among network operators is that IPv6 is a waste of time and money, a technology that solved a problem that no longer exists. If we won't sign off on it, these other people won't even have a chance to. I know that I said IPv6 is an incremental change, but the world that it enables is not incremental. Imagine 30 years from now where the majority of people in the developed world have full two-way voice, video, and data communications capability seamlessly integrated into their clothing, their vehicles, their workplace cubicles and their homes. X10 is obsolete replaced by IPv6 over power networks and IPv6 over Bluetooth v.3. Networks are everywhere and it is common for even small devices to have multiple IPv6 addresses. My belt (containing the cellphone transceiver) will have 20 IPv6 addresses in 20 different subnets corresponding to 20 VPNs. If you know about today's SIP networks, it's like having a phone number in INOC-DBA, FWD, SIPPhone, IAXtel etc. Except that these will be IPv6 addresses because they aren't for voice traffic. One of the 20 VPNs will be for a heart-rate monitoring service that coordinates with my gym and my personal trainer. Another one might be for an insulin level monitor that connects to my physician and pharmacy. The pharmacist will know when the insulin pack in my shirt collar will be depleted and will dispatch a refill to my home automatically. Like I said, I don't think people will be all that excited about their heart-monitor being reachable with a globally routed IP. People only want to be connected to a certain degree. Hell, there are people JUST NOW getting cell phones, and even more people who will never get them. Most people aren't interested in being reachable 24/7. Even more people aren't interested in having critical functions rely on technical mumbo-jumbo when they have grown up taking care of themselves just fine. I think you're WAY overestimating our culture's thirst for technology. As a society, we're still coming to grips with DVDs, MP3s, and cell phones. That's the problem that IPv6 is intended to solve. Providers with foresight can begin the process of upgrading today so that when IPv6 really is needed they will have a headstart. I'm not suggesting that anyone should rush IPv6 into production today, but everyone on this list should be running internal IPv6 trial networks to facilitate training of their personnel and to ensure that people have the experience needed to make rational and informed decisions about IPv6. Getting ready for 2022 a little early, aren't we? In 1995, the Internet, a.k.a. IPv4 networks, took off with a boom and left the legacy telcos in the dust. If you want to recreate that, then keep your heads in the sand and other
RE: [arin-announce] IPv4 Address Space (fwd)
On Tue, 28 Oct 2003, Matthew Kaufman wrote: End-to-end requires that people writing the software at the end learn about buffer overruns (and other data-driven access violations) or program using tools that prevent such things. It is otherwise an excellent idea. A lack of end-to-end just obscures the problem, it does not remove it. Host based firewalling or tcpwrapper style approaches address this point just as well, if not much better. At least if systems shipped with them defaulting to DENY. Unfortunately, the day that someone decided their poorly-designed machine and operating system would be safer sitting behind a firewall pretty much marked the end of universal end-to-end connectivity, and I don't see it coming back for a long long time. Probably not on this Internet. IPv6 or not. Unfortunate exceptions to the correct design methodology are not an acceptable reason to ignore the correct solution. Most NAT workaround methods currently used by applications fail horribly when both endpoints are behind a NAT, so we are only beginning to feel the initial impact of our reality of slightly broken end-to-end. Imagine an internet that never had end-to-end as a goal... where 'circuits' had to be manually provisioned across multiple carriers networks... where address translation happens at every intra-agency link. Oh wait, we call that the public switched telephone network... and I'm sure we're all already well aware of the amount of innovation that infrastructure affords us, and it's highly economic pricing model as well! I think it's amusing that I see the largest arguments against end-to-end coming from people who ran the networks that the end-to-end internet made largely obsolete. Combine that with ISP pricing models (helped by registry policy) that encourage =1 IP address per household, and the subsequent boom in NAT boxes, and the fate is probably sealed. ISPs simply respond to demand. We're all market whores on this list. Where there is a competitive advantage to offer multiple IPs per customer the ISPs will provide it: we already see this in highly competitive markets. Providing many IPs per household requires no major change to infrastructure, it's simply a policy decision.
Re: [arin-announce] IPv4 Address Space (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Dills wrote: | On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote: | | |The bottom line is that there are three different models |which may predict when we run out of IPv4 addresses. The |models predict dates ranging from 2022 to 2045. None of |the models predict an exact year, they all predict a range |of 4 to 8 years and the above dates are the earliest and |latest of those ranges. | | | Ok, so let's assume 2022, for the sake of argument. That is, after all, | nearly 20 years from now. | | |Does anybody honestly think companies will commit the capex needed to |implement IPv6? | |Yes, because IPv6 is merely and incremental improvement, not a grand |elegant solution to world hunger like ATM. Look at how we managed the |incremental step of adding MPLS to our IPv4 networks. It was fairly |painless because it uses the same boxes, the same people and the same |management systems. And over time, the pain of doing MPLS is reduced |because the bugs get worked out. | | | Yes, but did MPLS require different ASICs? | | |Similarly, IPv6 is an incremental change that uses the same boxes, |people and management systems. | | | People need training (but not all that much), management systems need | rewritten (not majorly), and boxes need hardware replacements to forward | at line rate (CAPEX ALERT). | | |In fact, if you've put MPLS into your core, you only need to worry about |IPv6 at the edge from the PE router to the CE router because you can use |6PE. The capex is being spent anyway by upgrading boxes to meet capacity |needs. You didn't notice it but the new core boxes are all capable of |IPv6 with a simple software feature upgrade. | | | Yes, but there will always be this issue of billions of dollars of | exisiting, perfectly functional, unable-to-forward-v6-at-linerate routing | gear. If you have a router completely filled with attached customers, why | would you upgrade that router? You would buy another one for future new | customers, but not upgrade the existing one. The new one might forward | IPv6 at linerate, but the old one still doesn't, and there is still not | sufficient motivation to upgrade that old router. | | |NANOG rarely takes the lead in new product development and driving |market demand. Someone else will sort out that problem. | | | Yes, but the growing consensus among network operators is that IPv6 is a | waste of time and money, a technology that solved a problem that no longer | exists. | | If we won't sign off on it, these other people won't even have a chance | to. | | |I know that I said IPv6 is an incremental change, but the world that it |enables is not incremental. Imagine 30 years from now where the majority |of people in the developed world have full two-way voice, video, and |data communications capability seamlessly integrated into their |clothing, their vehicles, their workplace cubicles and their homes. X10 |is obsolete replaced by IPv6 over power networks and IPv6 over Bluetooth |v.3. Networks are everywhere and it is common for even small devices to |have multiple IPv6 addresses. My belt (containing the cellphone |transceiver) will have 20 IPv6 addresses in 20 different subnets |corresponding to 20 VPNs. If you know about today's SIP networks, it's |like having a phone number in INOC-DBA, FWD, SIPPhone, IAXtel etc. |Except that these will be IPv6 addresses because they aren't for voice |traffic. One of the 20 VPNs will be for a heart-rate monitoring service |that coordinates with my gym and my personal trainer. Another one might |be for an insulin level monitor that connects to my physician and |pharmacy. The pharmacist will know when the insulin pack in my shirt |collar will be depleted and will dispatch a refill to my home |automatically. | | | Like I said, I don't think people will be all that excited about their | heart-monitor being reachable with a globally routed IP. People only want | to be connected to a certain degree. | | Hell, there are people JUST NOW getting cell phones, and even more people | who will never get them. Most people aren't interested in being | reachable 24/7. Even more people aren't interested in having critical | functions rely on technical mumbo-jumbo when they have grown up taking | care of themselves just fine. | | I think you're WAY overestimating our culture's thirst for technology. | As a society, we're still coming to grips with DVDs, MP3s, and cell | phones. | While this may be NANOG, that's a pretty U.S.-centric point of view. The appetite for technology and connectivity in Asian countries is mind-boggling. If just 50% of the college students in China had IP enabled cell phones, that would be 160 million users. I don't know if most U.S. providers have requirements on that kind of scale. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (MingW32) iD8DBQE/nrZQE1XcgMgrtyYRAmDIAJ9fRT/7jbAHE9LSL+Ot8NlbAuiv+ACg1/hP dc7ob/VJ8u3dTzRDOBtsNRY= =/7VW -END PGP SIGNATURE-
Re: [arin-announce] IPv4 Address Space (fwd)
Yes, because IPv6 is merely and incremental improvement, not a grand elegant solution to world hunger like ATM. Look at how we managed the incremental step of adding MPLS to our IPv4 networks. It was fairly painless because it uses the same boxes, the same people and the same management systems. And over time, the pain of doing MPLS is reduced because the bugs get worked out. Yes, but did MPLS require different ASICs? In some cases, yes. Cisco Catalyst 6500 with Sup2/MSFC2/PFC2 cannot do MPLS by itself, while 6500 with Sup720 can. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
Matthew Kaufman wrote: End-to-end requires that people writing the software at the end learn about buffer overruns (and other data-driven access violations) or program using tools that prevent such things. It is otherwise an excellent idea. There is supposedly some magic going into this in the next Service Pack of a mentioned major exploding Pinto. Not sure if it´s just flipping the joke of firewall on by default or something more comprehensive/destructive like non-executable stack. Or a completely new invention like bug free code :-) Unfortunately, the day that someone decided their poorly-designed machine and operating system would be safer sitting behind a firewall pretty much marked the end of universal end-to-end connectivity, and I don't see it coming back for a long long time. Probably not on this Internet. IPv6 or not. Last I checked most firewalls don´t make these machines safe, it might make them safer, so only two out of three malwares hit them. Does not really help too much. Combine that with ISP pricing models (helped by registry policy) that encourage =1 IP address per household, and the subsequent boom in NAT boxes, and the fate is probably sealed. Here I´ve observed opposite trend, most ISP´s are getting rid of NATting because it´s failure prone and expensive to implement and keep running. Pete
Re: [arin-announce] IPv4 Address Space (fwd)
Kuhtz, Christian wrote: I'm not saying IPv6 is dead, but I think a leap, rather than an incremental improvement may be needed. Unless somebody actually does come up with an IPv6 killer app... Most Internet traffic is p2p traffic. IPv6 (by virtue of eliminating most perceived needs for NAT devices) increases the efficiency of p2p traffic. So implementing IPv6 will improve the efficiency of the Internet. No need for a new killer app, the old one will suffice. Pete
Re: [arin-announce] IPv4 Address Space (fwd)
I think if program design criterion would change, to coding secure applications then the problem would be reduced dramatically -HenryPetri Helenius [EMAIL PROTECTED] wrote: Matthew Kaufman wrote:End-to-end requires that people writing the software at the end learn aboutbuffer overruns (and other data-driven access violations) or program usingtools that prevent such things. It is otherwise an excellent idea. There is supposedly some magic going into this in the next "Service Pack" of a mentionedmajor exploding Pinto. Not sure if it´s just flipping the joke of firewall on by default or somethingmore comprehensive/destructive like non-executable stack. Or a completely new invention likebug free code :-)Unfortunately, the day that someone decided their poorly-designed machineand operating system would be safer sitting behind a "firewall" pretty muchmarked the end of universal end-to-end connectivity, and I don't see itcoming back for a long long time. Probably not on this Internet. IPv6 ornot. Last I checked most "firewall"s don´t make these machines safe, it might make them safer,so only two out of three malwares hit them. Does not really help too much.Combine that with ISP pricing models (helped by registry policy) thatencourage =1 IP address per household, and the subsequent boom in NATboxes, and the fate is probably sealed. Here I´ve observed opposite trend, most ISP´s are getting rid of NATting because it´s failureprone and expensive to implement and keep running.Pete
Re: [arin-announce] IPv4 Address Space (fwd)
and operating system would be safer sitting behind a firewall pretty much marked the end of universal end-to-end connectivity, and I don't see it An OS-level (software) firewall doesn't preclude end-to-end connectivity, and even a per-machine hardware firewall doesn't given it can pass inbound traffic through. Most servers on the Internet are also behind hardware firewalls, and they don't hinder end-to-end connectivity. Last I checked most firewalls don´t make these machines safe, it might make them safer, so only two out of three malwares hit them. A probably configured firewall will protect a machine against everything but it's user, and therein lies a problem you will likely never solve. Adam
Re: [arin-announce] IPv4 Address Space (fwd)
On Tue, 28 Oct 2003 18:28:55 CST, Adam Selene [EMAIL PROTECTED] said: A probably configured firewall will protect a machine against everything but it's user, and therein lies a problem you will likely never solve. The real problem is that we have an environment where the malware can figure out how to disable the firewall but the user can't. pgp0.pgp Description: PGP signature
RE: [arin-announce] IPv4 Address Space (fwd)
On Tue, 28 Oct 2003 18:28:55 CST, Adam Selene [EMAIL PROTECTED] said: A probably configured firewall will protect a machine against everything but it's user, and therein lies a problem you will likely never solve. The real problem is that we have an environment where the malware can figure out how to disable the firewall but the user can't. Hopefully, one day software will be good enough the user won't have to be smart. And even clever malware will need some good luck to do its job. DJ
Re: [arin-announce] IPv4 Address Space (fwd)
Andy Dills wrote: Technologies like NAT and efforts to reclaim poorly assigned address space have a large negative pressure on the increase of IP utilization. As more and more appliances need IP addresses, people will realize more and more that the last thing they want is those applicances on public IP space. It seems that the Internet will take the switchboard lady detour due to misguided thinking like the one above, mostly due to the fact that a major OS explodes when it touches the Internet. Fortunately hardly any of these applicances have this OS. How about a protocol that eliminated the need for BGP, while simultaneously making every address portable? That, to me, would be The Answer. Not that it seems possible given what we currently know, but 20 This protocol is called HIP, right? (Host Identity Payload) Does anybody honestly think companies will commit the capex needed to implement IPv6? Yes. Investment in information technology hardly ever makes sense. If it would, market share numbers of various ICT products would look wildly different. I know this thread keeps on coming up...but I don't see any positive momentum for IPv6, and if the people of this Esteemed Forum can't agree that IPv6 is something that must happen ASAP, how will the PHBs (those who control the money) and the customers (those who control demand) ever be convinced? Because they heard somebody from Gartner, IDC, etc. so say so. Hell, I can't even convince myself that IPv6 is neccessary. Is anybody out there totally sold on IPv6, enough to evangelize it to anybody willing to listen? I mean, IPv6 is no CIDR... You are smarter than many of them. Like most of the readers here. Pete
Re: [arin-announce] IPv4 Address Space (fwd)
On Mon, Oct 27, 2003 at 04:10:26PM -0500, Andy Dills wrote: Technologies like NAT and efforts to reclaim poorly assigned address space have a large negative pressure on the increase of IP utilization. As more and more appliances need IP addresses, people will realize more and more that the last thing they want is those applicances on public IP space. Does anybody have statistics for assigned-but-not-announced space? I'd be willing to bet there will be more and more dead space over the years, and in fact quite a bit of increasing usage is just churn. http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html This is actually a pretty good write-up about the IPv4 address lifetime by Geoff Huston. It has some graphs that compares BGP to actually assigned space comparisons. Makes very good reading about all this. -- Cliff Albert| RIPE: CA3348-RIPE | https://oisec.net/ [EMAIL PROTECTED] | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A signature.asc Description: Digital signature
Re: [arin-announce] IPv4 Address Space (fwd)
Does anybody have statistics for assigned-but-not-announced space? I'd be willing to bet there will be more and more dead space over the years, and in fact quite a bit of increasing usage is just churn. I have these statistics at http://www.completewhois.com/statistics/ip_statistics.htm At above page look specifically at the blue part of the graph for assigned- but-not-allocated space. I actually looked at opposite (assigned routed - this I named routing utilization ratio) as way to determine efficiency of RIR policies. This ratio is very high for the new ARIN ip blocks (97%), but as you pointed above the churn is high for older blocks and only 42% of allocated space in 192/8 is actively routed. The ratios are in between around 60%-80% for other old blocks and these numbers both has to do with allocation policies that were not developed at the time and with churn due to dead companies. I have done analysis for different time periods, see: http://www.completewhois.com/statistics/rir_ratios.htm If you need data on exact amounts, you will need to do your own substraction use allocation statistics data from http://www.completewhois.com/bogons/data/allocation-statistics.txt and substract current use data from http://www.completewhois.com/bogons/data/data-bgp-announced/ipv4-activeblocks-statistics.txt Does anybody honestly think companies will commit the capex needed to implement IPv6? Not without additional benefits. We need either applications that are working a lot better at ipv6 or we may yet have to see ipv4 space ran out before it becomes clear to everybody that ipv6 is a must. --- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: [arin-announce] IPv4 Address Space (fwd)
Does anybody honestly think companies will commit the capex needed to implement IPv6? William Leibzon wrote: Not without additional benefits. I agree, and they're all gone now. To my deepest regrets, IPv6 has become nothing more than IPv4 with more bits (it's actually worse than IPv4 as of today). We need either applications that are working a lot better at ipv6 or we may yet have to see ipv4 space ran out before it becomes clear to everybody that ipv6 is a must. Besides, IPv4 will never run out; as pointed out to me recently, it will simply become more expensive as it becomes rarer, and large and/or wealthy corporation in developed countries will likely always be able to afford it. Note, I'm not saying this is good, all I'm saying is that's just the way it is. Michel.
RE: [arin-announce] IPv4 Address Space (fwd)
We need either applications that are working a lot better at ipv6 or we may yet have to see ipv4 space ran out before it becomes clear to everybody that ipv6 is a must. Besides, IPv4 will never run out; as pointed out to me recently, it will simply become more expensive as it becomes rarer, and large and/or wealthy corporation in developed countries will likely always be able to afford it. Note, I'm not saying this is good, all I'm saying is that's just the way it is. Even if it becomes more expensive and nearly runs out, providers to those who can't afford the space directly can always gateway IPV4IPV6 until every major provider starts providing new allocations out of IPV6 space since its less expensive to operate that way. It might be two years or ten, or it might be a new ip model entirely, but history has told us that once we outgrow something, we route-around it (note: NSFNET). Deepak Jain AiNET
