Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 1-okt-2007, at 19:56, Stephen Sprunk wrote: The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world. There is no IPv6 world. I've heard reference over and over to how developers shouldn't add NAT support into v6 apps, but the reality is that there are no v6 apps. There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time. I could talk about APIs and how IPv6 addresses are embedded in protocols, but let me suffice to say that although your applications may work over both IPv4 and IPv6, this doesn't mean that the two protocols are completely interchangeable. NATs and their ALGs as well as applications WILL have to be changed to make protocols that embed IP addresses work through NAT-PT (or IPv6 NAT). The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6. There are different approaches possible for this. Opening up holes in the firewall is probably better than ALGs. 1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections 2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6 Neither solves the problem of v6-only hosts talking to v4-only hosts. Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the IPv6-only status from the host if not from the network it connects to.) The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. You're right, that doesn't work. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. Again, you're right. The costs will be ongoing in the form of reduced transparency (both in the technical/architectural sense and in the sense that applications behave unexpectedly) and the continous need to accommodate workarounds in applications. Could you please explain what problems you see with the proxy/tunnel approach and why you think NAT-PT doesn't have these problems? When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I guess I wouldn't.) No, what's going to happen is that users will demand IPv4 connectivity from their service providers if IPv6-only doesn't work well enough. On 1-okt-2007, at 20:15, Stephen Sprunk wrote: The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT. Of course ALGs will exist in IPv6: they'll be needed for stateful firewalls, which aren't going away in even the most optimistic ideas of what an IPv6-only network will look like. That doesn't mean it's a good idea to embrace something that requires them, because every protocol needs an ALG of its own. If both sides use a dual stack proxy, it's even possible to use address-based referrals. E.g., the IPv4 host asks the proxy to set up a session towards 2001:db8:31::1 and voila, the IPv4 host can talk to the IPv6 internet. Not possible with a NAT-PT like solution. Only one side needs to proxy/translate; if both sides have a device to do it, one of them will not be used. Today, it's perfectly reasonable to assume that everything's reachable over IPv4. At some point in the future, everything will be reachable over IPv6. Somewhere in between, there could be a situation where some people are running IPv4-only and others IPv6-only, so access to a dual stack proxy would be beneficial for both types of hosts. Better, if both sides support the same version (either v4 or v6), that would be used without any proxying or translating at all. True. It would be nice if applications or OSes could use direct communication if a destination is reachable that way and only use the proxy when there is an IP version mismatch. Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-) And when we run out of v4 addresses in a few years, what do you propose we do? Use NAT for the IPv4 connectivity, I'm afraid. It makes little sense to tunnel v4 over v6
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
What has happened? Well, application protocols have evolved to accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have undergone incremental improvements, and almost no end-users care about NATs. As long as they can use the Google, BitTorrent and Skype, most moms and dads neither know nor care about any technical impediments NATs erect between them and their enjoyment of the Internet. Except every service that used to work using direct TCP connections has either moved to UDP, or moved towards having unNATted boxes that people can relay through. While NAT traversal for TCP is theoretically possible, it relies on rarely used features of TCP (Simultaneous open) and good timing, both of which are likely to cause issues. I've never heard of a successful real world application successfully doing this. (Feel free to educate me if you know of a realworld application in common use that does do TCP NAT traversal and has it work a significant amount of the time). Even p2p apps like bittorrent rely on the fact that there are /some/ people /somewhere/ in the swarm that have either configured their NAT to allow pinholing or don't have any NAT between them and the Internet. Plastered everywhere over anything P2P filetransfer related is poor performance? Add a pinhole to your NAT box! suggesting quite strongly that NAT is causing large problems for P2P swarms. NAT is hurting applications today, and applications aren't getting deployed (or even written) because of problems NAT causes.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 10:43 AM +0200 10/2/07, Iljitsch van Beijnum wrote: When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. For you? now? Not likely. About the time that a very large number of new Internet sites are being connected via IP6 because there is little choice, that's a different story. Providers would be likely be telling customers to send their complaints to YouTube, and that everyone's in the same situation until Youtube gets a real connection. The proxytunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT, only without the attention to ALG's that NAT-PT will receive, and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. For now, HTTPS proxy or a IPv4 tunnel over IPv6 works fine, but most folks don't really care about IPv6 deployment right now. They're looking for a model which works 3 years from now, when the need to deploy IPv6 is clear and present. At that point, there's high value in having a standard NAT-PT / ALGs approach for providing limited IPv4 backwards compatibility. /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 5:36 AM -0400 10/2/07, John Curran wrote: ... tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. c/are/are no longer/ (before my morning caffeine fix) /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 2-okt-2007, at 11:36, John Curran wrote: The proxytunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT, The main issue with a proxy is that it's TCP-only. The main issue with NAT-PT is that the applications don't know what going on. Rather different drawbacks, I'd say. only without the attention to ALG's that NAT-PT will receive, ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to. and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 1:50 PM +0200 10/2/07, Iljitsch van Beijnum wrote: ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to. At the point in time that NAT-PR is used for backward compatibility (because we're connecting new sites via IPv6) people should be encouraged to rollout their new apps over IPv6, right? What's the problem? and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4. That's a wonderful solution, and you should feel free to use it. It's particularly fun from a support perspective, because you get to be involved all the way down the host level. A lot of ISP's don't want to be involved in supporting *anything* all the way down to the local host level, and want a simple method for connecting new customers via IPv6 while offering some form of legacy connectivity to rest of of the (IPv4) Internet. You're asserting that they shouldn't be allowed to use NAT-PT for this purpose, despite the fact that it meets their needs? /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 2-okt-2007, at 14:08, John Curran wrote: That's a wonderful solution, and you should feel free to use it. It's particularly fun from a support perspective, because you get to be involved all the way down the host level. Tunneling IPv4 over IPv6 and translating IPv4 into IPv6 pretty much do the same thing except that translating means information gets lost. I don't see how there is a host level difference between the two. A lot of ISP's don't want to be involved in supporting *anything* all the way down to the local host level, and want a simple method for connecting new customers via IPv6 while offering some form of legacy connectivity to rest of of the (IPv4) Internet. Well, then obviously they're not going to tunnel real addresses, so address use is not an issue. This means they can easily give out an address to all hosts connected to their network that wants one. This only costs the amount of state required per address, which should be negligible compared to the amount of state (per session) that's required when users start actually using such a service. You're asserting that they shouldn't be allowed to use NAT-PT for this purpose, despite the fact that it meets their needs? The IETF is asserting that NAT-PT is not fit for deployment. What I'm saying is that there are better ways to accomplish the same goals. Not sure what I would do if I had the power to make people stop using protocols that I feel they shouldn't use.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Tue, Oct 02, 2007, Iljitsch van Beijnum wrote: Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4. Please explain how you plan on getting rid of those protocol-aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-. Please don't say I'm the only one who thinks this will be a problem. End-to-end-ness is and has been busted in the corporate world AFAICT for a number of years. IPv6 people seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't. Plenty of places run a locked down firewall with a tight security policy that requires PERMITs in the firewall policy before access out is needed. These are going to need similar ALGs to NAT, even if they're not fiddling with end-points addresses. Could someone explain how I'm wrong so I can worry about other things? Adrian
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 2-okt-2007, at 15:05, Adrian Chadd wrote: Please explain how you plan on getting rid of those protocol-aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-. You just open up a hole in the firewall where appropriate. You can have an ALG, the application or the OS do this. As you probably know by now, I don't favor the ALG approach. End-to-end-ness is and has been busted in the corporate world AFAICT for a number of years. IPv6 people seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't. If you don't want end-to-end, be a man (or woman) and use a proxy. Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. At least not without a long, bloody fight.
Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Oct 1, 2007, at 9:15 AM, John Curran wrote: What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them? [EMAIL PROTECTED] (David Conrad) writes: Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses). i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with full routing in the face of this kind of unaggregated/nonhierarchical table, followed by a surge of bankruptcies and mergers and buyouts as those without access to sufficient new-router capital gave way to those with such access, followed by another surge of bankruptcies and mergers as those who thought they had access to such capital couldn't make their payments. call me a glass-half-full kind of guy, but the picture in my head in response to john's question is of a whole lot of network churn as the community jointly answers the question who can still play in this world? rather than how useful will those new routes really be? internet economics don't admit the possibility of not-full-routes, and so david's view that nonhierarchical routes won't be as useful as hierarchical makes me wonder, what isp anywhere will stay in business while not routing everything if other isp's can route everything? we're all in this stew pot together. -- Paul Vixie
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 1-okt-2007, at 19:56, Stephen Sprunk wrote: There is no IPv6 world. I've heard reference over and over to how developers shouldn't add NAT support into v6 apps, but the reality is that there are no v6 apps. There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time. I could talk about APIs and how IPv6 addresses are embedded in protocols, but let me suffice to say that although your applications may work over both IPv4 and IPv6, this doesn't mean that the two protocols are completely interchangeable. NATs and their ALGs as well as applications WILL have to be changed to make protocols that embed IP addresses work through NAT-PT (or IPv6 NAT). First, there really aren't that many apps today that embed IP addresses or don't follow the traditional client-server model. We don't have more of them because of v4 NAT. Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens. The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6. There are different approaches possible for this. Opening up holes in the firewall is probably better than ALGs. That's the purpose of an ALG. Requiring users to modify their home router config or put in a change request with their IT department for a firewall exception is a non-starter if you want your app to be accepted. Whether the pinhole is needed because of a NAT or a stateful firewall is irrelevant; what matters is having an ALG create the pinhole _automatically_. 1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections 2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6 Neither solves the problem of v6-only hosts talking to v4-only hosts. Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the IPv6-only status from the host if not from the network it connects to.) The former only handles outbound TCP traffic, which works through pure NAT boxes as it is. The latter solution ignores the problem space by telling people to not be v4-only anymore. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. Again, you're right. The costs will be ongoing in the form of reduced transparency (both in the technical/architectural sense and in the sense that applications behave unexpectedly) and the continous need to accommodate workarounds in applications. Agreed. People have shown they're willing to accept those costs in a v4-only network. Extending that to the transition phase adds zero _new_ costs. Providing a way out for people if they deploy v6 is a new _benefit_. Could you please explain what problems you see with the proxy/tunnel approach and why you think NAT-PT doesn't have these problems? NAT-PT works for more apps/protocols. It definitely has its own problems, though. That's why I view it as a transition technology, not a desirable end state. If it's successful, it will drive itself out of existence. When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I guess I wouldn't.) Either YouTube won't care, in which case NAT-PT obviously isn't as evil as people claim, or they will care and they'll deploy v6. I don't claim to know which scenario is correct, but I assert that it's one of the two. No, what's going to happen is that users will demand IPv4 connectivity from their service providers if IPv6-only doesn't work well enough. This is one place where the duopoly will work in our favor -- most people (at least in the US) only have two choices, and if neither of them has new IPv4 addresses available due to exhaustion, people simply can't buy non-NATed v4 access. The choices will be native v6, NAT-PT to v4, or multilayered v4 NAT. If that doesn't work well enough, the people at the other end will be motivated to deploy native v6 on their end to make their service work better than their competitors' -- and all the evil NAT(-PT) stuff is bypassed. On 1-okt-2007, at 20:15, Stephen Sprunk wrote: The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 2-okt-2007, at 15:05, Adrian Chadd wrote: Please explain how you plan on getting rid of those protocol- aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-. You just open up a hole in the firewall where appropriate. You can have an ALG, the application or the OS do this. As you probably know by now, I don't favor the ALG approach. You obviously have no experience working in security. You can't trust the OS (Microsoft? hah!), you can't trust the application (malware), and you sure as heck can't trust the user (industrial espionage and/or social engineering). The only way that address-embedding protocols can work through a firewall, whether it's doing NAT or not, is to use an ALG. The defense and healthcare industries will force vendors to write those ALGs (actually, make minor changes to existing ones) if they care about the protocols in question because they have no choice -- security is the law. And, once those ALGs are available, everyone else will use them. Even for home users, most have zero clue how to open a hole in their home firewall. Consumer OSes are far, far too insecure to let them sit exposed without a firewall by default (you can't even patch a Windows system before it's hacked), and we can't trust end users not to run malware that will open holes for them. End-to-end-ness is and has be-en busted in the corporate world AFAICT for a number of years. IPv6 people seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't. If you don't want end-to-end, be a man (or woman) and use a proxy. Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. At least not without a long, bloody fight. If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Tue, Oct 02, 2007 at 10:35:11PM +1300, Perry Lorier wrote: What has happened? Well, application protocols have evolved to accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have undergone incremental improvements, and almost no end-users care about NATs. As long as they can use the Google, BitTorrent and Skype, most moms and dads neither know nor care about any technical impediments NATs erect between them and their enjoyment of the Internet. [ ... ] While NAT traversal for TCP is theoretically possible, it relies on rarely used features of TCP (Simultaneous open) and good timing, both of which are likely to cause issues. You're talking about inbound (from the Internet to the client) traversal, right? Because outbound is trivial :-) I've never heard of a successful real world application successfully doing this. (Feel free to educate me if you know of a realworld application in common use that does do TCP NAT traversal and has it work a significant amount of the time). By focussing on the mechanics of inbound NAT traversal, you're ignoring the fact that applications work regardless. Web, VoIP, P2P utilities, games, IM, Google Earth, you name it, it works. On the ADSL network my employer operates, the number of customers who use NAT (because it's enabled by default on their CPE and they don't know or care enough to turn it off) is somewhere north of 95%. The Internet works. Nobody cares about NAT. Yes, it means that some classes of protocol (which rely on full P2P visibility) don't happen; But they aren't going to happen _anyway_, because NAT or no NAT firewalls remain a reality, and inbound firewall traversal is every bit as problematic as inbound NAT traversal. Like it or not, we don't really have a peer-to-peer Internet anymore. Not like we used to in the good ol' days when everyone had a globally routed IP address and nobody used firewalls. NAT is hurting applications today, and applications aren't getting deployed (or even written) because of problems NAT causes. Meanwhile, IPv6 advocates who don't like NAT are hurting IPv6 deployment today by waving their arms in the air and bitching about NAT. That makes life difficult, because their advocacy is removing tools (such as NAT-PT) which we could use to facilitate and hasten an IPv6 rollout. Throughout IPv6's history, and IPng's history before that, lots of disparate problem domains have been bundled together as things that the new protocol _must_ solve. IPv6 solves the 32-bit-address-space-is-too-small problem. That's all it does. So we've been able to run IPv6 for years, except IPv6 is also supposed to solve the bgp-table-is-too-big problem by (until recently) banning PI address space by non-ISPs and focussing attention on vaporware like SHIM6, so non-ISPs have yawned instead of deploying it; and IPv6 is also supposed to solve the security problem, so years were wasted defining mandatory IPSEC which isn't really mandatory; and IPv6 is also supposed to solve the mobility problem, so more years were wasted working out option headers and all measure of other crap needed to support mobile-IPv6; Now IPv6 is supposed to solve the we-want-a-p2p-internet-all-over-again problem by making NAT go away, and anti-NAT purists have spent their energy having NAT proposals for v6 written out of the standards, and oppose various deployment scenarios by saying, You can't possibly do that beacuse you'll (re)break end-to-end, and that isn't allowed in an IPv6 universe! While all this dicking around has been happening, the vendors have been cooling their heels waiting for sufficient amounts of consensus to make it worth their while to release the mass-market CPE with v6 support that we'll need to drive mass-market adoption of the new protocol. Protocol purists hold the whole process to ransom with their aesthetic sensibilities, and every year of delay is another year that'll pass before grandma can go down to Frys and buy a DLink ADSL modem with IPv6 support. And until grandma has a native IPv6 IP address, all the table-thumping in the world about end-to-end reachability ain't worth beans. In a _rational_ world, we would have said, We have a pressing problem, that of v4 exhaustion, so lets build a protocol that solves that, and maybe after we've passed that speed-bump we can fit mobility, security, end-to-end visibility, routing table controls, etc into the new framework. So, a reality check: IPv6 will happen. Eventually. And it'll have deficiencies which some believe are severe, just like the IPv4 Internet. Such as NAT. Deal with it. Throughout its history, the Internet has advanced by applying less-than-optimal solutions to the most pressing problems of the time, then going back and fixing it later when the heat has died down if the suboptimal solutions create their own new problems. If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Tue, Oct 02, 2007 at 01:50:57PM +0200, Iljitsch van Beijnum wrote: ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to. No, they turn the Intenret into a network where you only get to deploy new IPv4 applications when the powers that be permit you to. So everyone will deploy IPv6 applications, which require no ALGs, instead. Isn't that a solution that everyone can be happy with? - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Tue, Oct 02, 2007 at 01:57:15PM +, Paul Vixie wrote: On Oct 1, 2007, at 9:15 AM, John Curran wrote: What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them? [EMAIL PROTECTED] (David Conrad) writes: Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses). i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with full routing in the face of this kind of unaggregated/nonhierarchical table, followed by a surge of bankruptcies and mergers and buyouts as those without access to sufficient new-router capital gave way to those with such access, followed by another surge of bankruptcies and mergers as those who thought they had access to such capital couldn't make their payments. call me a glass-half-full kind of guy, but the picture in my head in response to john's question is of a whole lot of network churn as the community jointly answers the question who can still play in this world? rather than how useful will those new routes really be? internet economics don't admit the possibility of not-full-routes, and so david's view that nonhierarchical routes won't be as useful as hierarchical makes me wonder, what isp anywhere will stay in business while not routing everything if other isp's can route everything? we're all in this stew pot together. -- Paul Vixie stewing melds flavors, i hope we have a good chef. that said, i'm kind of leaning toward what i think of as DRC's view... but to clarify, can you tell me the economic incentive to carry route prefixes that you will only ever use to accept SPAM? --bill
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 10/2/07, Stephen Sprunk [EMAIL PROTECTED] wrote: If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well. Vendor C claims to support v6 (without NAT) in their enterprise class stateful firewall appliance as of OS version 7.2 (or thereabouts, perhaps 7.0). I've not tried it out yet to see how well it works. But, as far as the home/home office goes -- will my cable/dsl provider be able (willing?) to route a small v6 prefix to my home so that I can use a bitty-box stateful v6 firewall without NAT? What will be the cost to me, the home subscriber, to get said routable prefix? I am sure it increases the operator's expense to route a prefix to most (if not every) broadband subscriber in an area. In the beginning, cable operators were reluctant to support home customers using NAT routers to share their access. Now, renting/selling NAT routers to customers has become a revenue stream for some. How does lack of v6 NAT affect all of this?
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Thus spake Duane Waddle On 10/2/07, Stephen Sprunk [EMAIL PROTECTED] wrote: If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well. Vendor C claims to support v6 (without NAT) in their enterprise class stateful firewall appliance as of OS version 7.2 (or thereabouts, perhaps 7.0). I've not tried it out yet to see how well it works. Good for them. Perhaps one day their Divison L will wake up and do the same for consumer products. But, as far as the home/home office goes -- will my cable/dsl provider be able (willing?) to route a small v6 prefix to my home so that I can use a bitty-box stateful v6 firewall without NAT? What will be the cost to me, the home subscriber, to get said routable prefix? I am sure it increases the operator's expense to route a prefix to most (if not every) broadband subscriber in an area. Pricing is, of course, up to the vendors and operators in question. One possibility is that your CPE box would do a DHCP PD request for a /64 upstream, the /64 would come out of a pool for your POP. As the response came back downstream from whatever box managed the pool, routers would install the /64 in their tables to make it reachable. It wouldn't need to propogate any higher than the POP since the the POP's routers would be advertising a constant aggregate for the pool into the core. Another possibility is that the operator would assign a /48 (or /56) to your cable/DSL modem, which would handle the above functions at the home level instead of the POP level. It would provide a /64 natively on its own interface, and delegate /64s to downstream devices on request. If customer-owned CPE boxes did the same thing, you could chain hundreds of them together and have a network that Just Worked(tm). In the beginning, cable operators were reluctant to support home customers using NAT routers to share their access. Of course -- they were used to charging per television. However, they learned over time that they really wanted to charge for usage and the per-computer model didn't work like the per-television model did. Now they don't care about how many computers you have, just how many bits you move. That's a good thing. Now, renting/selling NAT routers to customers has become a revenue stream for some. I bet they break even at best on the rentals, given how often the darn things die. One shipment and/or truck roll eliminates a year's profit margin on the equipment, even if the replacement box itself is free. How does lack of v6 NAT affect all of this? It prevents them from being characteristically stupid. However, I wouldn't be surprised if one or more of them demanded it from their vendors, though, or if their vendors caved to win a deal. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Creating demand for IPv6
Thus spake William Herrin [EMAIL PROTECTED] As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer: 1. More addresses. 2. Provider independent addresses At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up. This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well. If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. If you're claiming that you have a PIv6 block and ISPs won't route it, please publicly shame the offending parties here so the rest of us will know not to give them our money. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 2-okt-2007, at 11:36, John Curran wrote: The proxytunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT, The main issue with a proxy is that it's TCP-only. The main issue with NAT-PT is that the applications don't know what going on. Rather different drawbacks, I'd say. There are several different mechanisms devices can use to discover they're behind a NAT(-PT) if they care. Most do not, and those that do often can't do anything about it even if they know. only without the attention to ALG's that NAT-PT will receive, ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to. That's somewhat true if you rely on a NAT-PT upstream. However, you can run your own NAT-PT box, decide what ALGs to run, and bypass the upstream NAT-PT since you will _appear_ to be a natively dual-stacked site. Of course, you're limited by the vendor writing the ALGs in the first place, but that's just an argument for OSS. Or perhaps it's an argument for deploying real v6 support and getting rid of NAT-PT entirely. The alternative to NAT-PT is multilayered v4 NAT, which has the same problem you describe except there's no way out. and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. We'll still need all those ALGs for v6 stateful firewalls. Might as well put them to use in NAT-PT during the transition between the ALG'd starting phase (all v4) and the ALG'd ending phase (all v6). Also, not unimportant: it allows IPv4-only applications to work trivially. Any applications that work trivially through v4 NAT will also work trivially through NAT-PT and v6 stateful firewalls. The interesting apps are the ones that don't work through NAT or firewalls without ALGs. If you're making some silly argument about non-NAT v4 access, well, you're over a decade out of touch with reality. The number of v4 hosts that are _not_ behind a NAT is negligible today. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Creating demand for IPv6
Stephen Sprunk wrote: Thus spake William Herrin [EMAIL PROTECTED] As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer: 1. More addresses. 2. Provider independent addresses At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up. This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well. If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. Really? As far as I understood it, I still had to pay $500 for end-user allocations. ~Seth
Re: Creating demand for IPv6
On 10/2/07, Stephen Sprunk [EMAIL PROTECTED] wrote: If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. Stephen, At this point its not an ARIN problem. The requirement from the operators (like us) is that ARIN keep the total number of PI prefixes to a minimum. So long as that requirement stands, ARIN is doing the best it can. Having recently dealt with the 244k IPv4 TCAM limit on my 6500 sup 2's, I'll stipulate that the requirement has merit. But lets not pass buck; its our requirement, not ARIN's. Also, to be clear: if you meet the requirements for IPv4 addresses today then you can get IPv6 addresses today. This is not parity with IPv4: a large number of IPv4 addresses are presently assigned to organizations who met the requirements of their day but do not meet today's requirements. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: WG Action: Conclusion of IP Version 6 (ipv6)
i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with full routing in the face of this kind of unaggregated/nonhierarchical table been there done that followed by a surge of bankruptcies and mergers and buyouts and that is not what happened last time, so why should it happen this time? randy
Re: Creating demand for IPv6
Thus spake Seth Mattinen [EMAIL PROTECTED] Stephen Sprunk wrote: If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. Really? As far as I understood it, I still had to pay $500 for end-user allocations. If you're an end user, you pay $100/yr for _all_ your resources. If you're an LIR, you pay either your v4 or v6 maintenance fees, whichever is greater. I don't know the status of the v6 initial assignment fee; I think that the v6 initial allocation fee was waived at one point. If they're not waived now, that'd be a one-time cost of $1250. The only $500/yr fee is to be a General Member, which is how non-LIRs get to vote in ARIN elections. You don't need to be a member to get a v6 assignment. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Creating demand for IPv6
On Tue, 2 Oct 2007, Stephen Sprunk wrote: I don't know the status of the v6 initial assignment fee; I think that the v6 initial allocation fee was waived at one point. If they're not waived now, that'd be a one-time cost of $1250. I'm pretty sure it's still being waived (at least for ISP/LIRs). I just applied for and received Atlantic.net's v6 /32 without paying any fees in advance. IIRC, with IPv4 initial allocations, you have to pay in advance. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: WG Action: Conclusion of IP Version 6 (ipv6)
and that is not what happened last time, so why should it happen this time? In fact, it's reasonable to assume that we will again filter prefixes. i agree but fear that it will be harder to find the filter algorithms this time. Hopefully, the ISP that is forced into this position will have the insight to accept cash in exchange for filter exceptions. This will be the start of the market place for routing table slots. last time, it was not offers of payment which caused the removal of phyltres, but the whining at the filterers' sm folk. we're very important and your customers will not be able to reach us. and we'll tell our mommy and all our friends that you're mean and nasty. randy
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
End-to-end-ness is and has been busted in the corporate world AFAICT for a number of years. IPv6 people seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't. If you don't want end-to-end, be a man (or woman) and use a proxy. Been doing that for a long time for v4, only a few protocols have been a problem where they've deliberately ignored this requirement to force the only end-to-end shall exist dogma. They die off or get worked around Real world is both exist and have their uses Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. And people wonder why v6 is going nowhere. Whilst I'm happy with proxy rather than fudging bits others want to fudge. At least not without a long, bloody fight. I don't think they'll fight they'll say stuff v6 as it doesn't work. If v6 is to take over people will have to be a bit more flexible brandon
WG Action: Conclusion of IP Version 6 (ipv6)
From: David Conrad: snip : Older routers will indeed fall over, as they are going to : fall over when we go over 240K routes, so folks will upgrade. I see we're pretty close to that: www.cidr-report.org/as2.0 Date Prefixes 03-10-07 239049 scott
Re: Creating demand for IPv6
[EMAIL PROTECTED] (David Conrad) writes: ... You cannot simply wave a magic wand and say there shall be no NAT. ... actually, you can. see RFC 4966. don't be fooled by the title, it's not just damning NAT-PT, since it justifies doing so by stating that NAT is damned. (of course, waving a magic wand and saying something doesn't make it so.) -- Paul Vixie
