|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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 until v6 packets become the majority on the backbones No, the way I see it you would have an IPv6-only local network and then have a translation box at the edge of a corporate network or in an ISP network. So you'd be in the IPv4 world before you hit any major backbones. -- and the only way that'll happen is if everyone dual-stacks or is v6-only. There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices. For the same reason, running IPv6-only is pretty close to being feasible. (It already is if you don't mind conf t and can skip the fancy management stuff.) On hosts you have the trouble that all applications must run over IPv6 before you can yank the IPv4 address and while everything still has IPv4 anyway, there is little value in adding IPv6.
|