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 28-sep-2007, at 6:25, Jari Arkko wrote: And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead. For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this. 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. Yes, ideally the NAT code wouldn't get used if the socket were v6. 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. Rather than solving this issue by trying harder, I would like to take the IETF to adopt the following approach: 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. The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. 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. The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils? 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] For the purpose of this particular discussion, NAT in IPv4 is basically a given: coming up with an IPv4-IPv6 transition mechanism that only works with if no IPv4 NAT is present both defeats the purpose (if we had that kind of address space we wouldn't have a problem in the first place) and it's completely unrealistic. 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. I don't see the problem with proxying, except that it only works for TCP. Yes, you need a box in the middle, but that's true of any solution where you have an IPv6-only host talk to an IPv4-only host. 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. Better, if both sides support the same version (either v4 or v6), that would be used without any proxying or translating at all. 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? It makes little sense to tunnel v4 over v6 until v6 packets become the majority on the backbones -- and the only way that'll happen is if everyone dual-stacks or is v6-only. If everyone has v6 connectivity, then why do we need to route v4 anymore, even over tunnels? 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)
At 12:56 PM -0500 10/1/07, Stephen Sprunk wrote: ... The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. 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. The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils? Stephen - Very well said... Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol? Oh wait, wrong mailing list... ;-) /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Mon, 01 Oct 2007 14:39:16 EDT, John Curran said: Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol? Historic usually refers to stuff we've managed to mostly stamp out production use. So it boils down to Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?. (Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon). pgpuAYZyDe2Tt.pgp Description: PGP signature
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 3:11 PM -0400 10/1/07, [EMAIL PROTECTED] wrote: So it boils down to Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?. (Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon). If indeed one believes that's there more functionality for having end-to-end IPv6, then presumably their competitors will roll out services which make use of these capabilities, and Amazon will feel some pressure to follow. Operating through NAT-PT is not very exciting and it's not going to take much (e.g. quality video support) to cause major content providers to want to have native end-to-end communication. Amazingly, it creates an actual motivation for existing IPv4 content sites to considering adding IPv6 support, which is something we've lacked to date. /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol? to remind you of my original message pushing nat-pt. the nat functionality itself needs standardization, as well as algs for dns, smtp, http, sip, and rtp. these will be sufficiently widely deployed, that we need the interchangability and testability that standardization gives us. what i did not say at that time, but think would be quite useful, is that it would be nice to have a standardized api for new algs. randy
OT: Need connectivity between St. Louis and NYC.
Hi all, Sorry for the off-topic post, but I'm in a jam. I need two 10mbps connections based in St. Louis for the following sites: 1. 900 Walnut - 10mbps backhauled to 32 Avenue of the America's, NYC. 2. Chesterfield, MO to 900 Walnut St. Louis. Please ping me off list for more details and clarification. -- Stephen.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Thus spake [EMAIL PROTECTED] Historic usually refers to stuff we've managed to mostly stamp out production use. So it boils down to Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?. This particular camel will be here until we manage to get v4 turned off, regardless of what status the IETF dogmatists assign it. Once that happens, though, there will be no need for NAT-PT anymore :-) (Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon). That depends. If Amazon sees absolutely no ill effects from v6 users reaching it via v4, then they obviously have little technical incentive to migrate. OTOH, if that is true, then all the whining about how evil NAT-PT is is obviously bunk. We can't have it both ways, folks: either NAT-PT breaks things and people would move to native v6 to get away from it, or NAT-PT doesn't break things and there's no reason not to use it. 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 Mon, Oct 01, 2007 at 09:18:43PM -0500, Stephen Sprunk wrote: That depends. If Amazon sees absolutely no ill effects from v6 users reaching it via v4, then they obviously have little technical incentive to migrate. OTOH, if that is true, then all the whining about how evil NAT-PT is is obviously bunk. We can't have it both ways, folks: either NAT-PT breaks things and people would move to native v6 to get away from it, or NAT-PT doesn't break things and there's no reason not to use it. The IPv4 Internet has been awash with dodgy NATs that negatively affect functionality ever since NAT arrived on the scene. 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. There's no rational reason to believe that NAT-PT would be any different. If NAT-PT breaks stuff, it'll get improved. It'll keep getting better until we don't need it anymore (or forever, whichever comes first) - 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
