Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 4-okt-2007, at 14:36, Iljitsch van Beijnum wrote: I would be interested to know how many people favor each of the following approaches. Feel free to send me private email and I'll summerize. I only got three replies, which don't really support drawing many conclusions. 1. Keep NAT and ALGs out of IPv6 and use additional protocols between hosts and firewalls to open pinholes in firewalls (where appropriate/allowed, such as in consumer installations) to avoid ALGs + + 2. Keep NAT out of IPv6 but use ALGs to bypass firewalls _ 3. Come up with a standard way of doing 1-to-1 NAT (no PAT) in IPv6 4. Come up with a standard way of doing NAT/PAT in IPv6 + 5. Everyone do whatever suits their needs like what happened in IPv4 - Interestingly, nobody seems to like option 3. And: if people start using NAT in IPv6 I will: a. Implement ALGs and application workarounds to accommodate it don't want to but we'll have to if it comes to this x 2 unqualified x 1 b. Not do anything, it's their problem if stuff breaks would prefer this if it were up to me x 1 c. Break stuff that goes through IPv6 NAT on purpose to prove a point -
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 4-okt-2007, at 17:50, Stephen Sprunk wrote: Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on. uPNP is moderately successful in the consumer space; it still doesn't work very well today, and it won't work at all in a few years when ISPs are forced to put consumers behind their own NAT boxes because they can't get any more v4 addresses. Please don't take my statement to be an endorsement of uPnP: it's a huge hack and has proven to be a security hole big enough to drive a truck full of NAT boxes through. My point is that in the consumer market, there has been a move to explicit hole punching rather than full reliance on ALGs. None of those protocols are being seriously considered by business folks. Business folks once ruled the internet but those days are over. The consumer is king. If the NAT/FW box can recognize a SIP call, or an active FTP transfer, or whatever and open the pinhole on its own, why is that a bad thing? The bad thing is when it doesn't work. For instance, when I let my Apple Extreme base station do NAT, RTSP (QuickTime streaming, although I think this defaults to HTTP these days, which sucks in its own way) works. But when I let my Cisco 826 do it, there is no RTSP ALG and it doesn't work. Since it's practically impossible for an end-user to add ALGs, this means that relying on them is russian roulette. You can get lucky at first, but nobody survives the sixth round. Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden. Today, at least, it's less of a burden to build a NATed v4 network than it is to try to get v6 working end-to-end (with or without NAT). On the contrary. It's extremely simple: get IPv6-enabled ISPs on both ends, configure IPv6 on all routers on both sides, sprinkle with records and you're in business. Then ALL applications that work over IPv6 will work. No exceptions. With NAT you're forever chasing after the exceptions. Now of course getting those IPv6 ISPs may be hard/expensive/ impossible and running v6 on the routers may require replacing them, but those are simple practical issues that are irrelevant in the long term. One of the benefits of NAT-PT is all those legacy v4-only apps can stay exactly how they are (at least until the next regular upgrade, if any) and talk to v6 servers, or to other v4 servers across a v6- only network. No they can't. When I fire up pretty much any IM client when I'm running IPv6-only, it doesn't work, despite the presence of the necessary translation gear. Those apps simply cannot communicate over IPv6 sockets. You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks. Yes, it is. Or at least it should be. There is no trusted side of a firewall these days. Exactly: not the inside, not the outside, and also not the middle. As I said, in consumer installations, apps get to open up holes in NAT boxes so there is no protection from rogue applications running on internal hosts. Also, consumer networks are not the only relevant networks. There are arguably just as many hosts on enterprise networks, and the attitudes and practices of their admins (regardless of technical correctness) need to be considered. In such networks, it would be reasonable to expect that what happens on the hosts and what happens on the middleboxes is sufficiently coordinated that it presents something unified to the outside. This is different from the consumer space where random apps need to communicate across random home gateways.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Thu, 04 Oct 2007 22:35:33 +0200, Iljitsch van Beijnum said: Business folks once ruled the internet but those days are over. The consumer is king. Given yesterday's RIAA victory in their lawsuit in Minnesota, I expect the RIAA will start lobbying for more ways to easily identify the individual users/computers - the easiest way to do *that*, of course, is to give each computer a truly unique address rather than allow some unknown number of authorized and freeloading computers to all hide behind one NAT on a wireless cable/DSL modem. I predict this will finally be the Killer App that IPv6 has been waiting for. :) pgpxbO7dhhhJe.pgp Description: PGP signature
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Fri, 05 Oct 2007 17:42:05 +0200, Mohacsi Janos said: Except if you are using privacy enhanced ipv6 addresses a la RFC 3041 Which is more likely: 1) The RIAA successfully lobbies for a network that basically prohibits rfc3041. 2) The consumers successfully lobby for a network that permits/requires rfc3041. (My point was that at least in the US, the consumer is king mantra has been a crock for several years - witness the incredible range and speeds of our broadband choices, the whole net neutrality thing. If forced into a choice between what the RIAA wants and what consumers want, I think we know what most last-mile providers are going to do.) pgpXPLwlSFRqV.pgp Description: PGP signature
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Fri, 05 Oct 2007 18:56:48 +0200, Mohacsi Janos said: controller can force enable/disable. I don't see how RIAA can lobby for switching off privacy enhancement - disabling certain component of the operating system?. Consider the fact that they lobbied *and got* 17 USC 512 takedowns, and the DMCA anti-circumvention clause. Still don't see how they could lobby for it? pgprVMfdUM4r3.pgp Description: PGP signature
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Iljitsch van Beijnum wrote: That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail. Somehow we made it work for v4. How did that happen?
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 4-okt-2007, at 13:36, Eliot Lear wrote: That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail. Somehow we made it work for v4. How did that happen? (Hm, RTSP fails miserably when I use NAT on my Cisco 826...) Well, if 95% of the people in a position to do this think it's worth repeating this effort for IPv6, my objections aren't going to stop them. But if the majority or even a significant minority don't want to play, then IPv6 NAT is going to work a lot worse than IPv4 NAT. And although it's clear that some people want IPv6 NAT, IPv6 NAT is not nearly as useful as IPv4 NAT, because IPv6 has more than enough addresses for any conceivable use without it. I would be interested to know how many people favor each of the following approaches. Feel free to send me private email and I'll summerize. 1. Keep NAT and ALGs out of IPv6 and use additional protocols between hosts and firewalls to open pinholes in firewalls (where appropriate/allowed, such as in consumer installations) to avoid ALGs 2. Keep NAT out of IPv6 but use ALGs to bypass firewalls 3. Come up with a standard way of doing 1-to-1 NAT (no PAT) in IPv6 4. Come up with a standard way of doing NAT/PAT in IPv6 5. Everyone do whatever suits their needs like what happened in IPv4 And: if people start using NAT in IPv6 I will: a. Implement ALGs and application workarounds to accommodate it b. Not do anything, it's their problem if stuff breaks c. Break stuff that goes through IPv6 NAT on purpose to prove a point
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:56, Stephen Sprunk wrote: Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens. That's one solution. I like the hole punching better because it's more general purpose and better adheres to the principle of least astonishment. ALGs are just automated hole-punching. 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. Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on. uPNP is moderately successful in the consumer space; it still doesn't work very well today, and it won't work at all in a few years when ISPs are forced to put consumers behind their own NAT boxes because they can't get any more v4 addresses. None of those protocols are being seriously considered by business folks. ALGs are here to stay. If the NAT/FW box can recognize a SIP call, or an active FTP transfer, or whatever and open the pinhole on its own, why is that a bad thing? Since it's the NAT/FW box that's breaking things, it's the NAT/FW box's responsibility to minimize that breakage -- not rely on hosts to tell it when a pinhole needs to be opened. 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. BitTorrent is TCP, but it sure doesn't like NAT because it gets in the way of incoming sessions. Of course. It doesn't help that many ISPs are filtering inbound SYN packets specifically to block (or at least severely degrade the performance of) P2P apps. The latter solution ignores the problem space by telling people to not be v4-only anymore. Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden. Today, at least, it's less of a burden to build a NATed v4 network than it is to try to get v6 working end-to-end (with or without NAT). 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. *giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years? The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors. You forget that the majority of applications need to be changed to work over IPv6. The majority of bits moved are via apps that support v6. One of the benefits of NAT-PT is all those legacy v4-only apps can stay exactly how they are (at least until the next regular upgrade, if any) and talk to v6 servers, or to other v4 servers across a v6-only network. On 2-okt-2007, at 16:10, Stephen Sprunk wrote: You just open up a hole in the firewall where appropriate. You obviously have no experience working in security. Who wants those headaches? 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. You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks. Yes, it is. Or at least it should be. There is no trusted side of a firewall these days. Even a decade ago it was recognized that the majority of attacks were from the inside. With the advent of worms and viruses (spread by insecure host software), outside attackers are almost irrelevant compared to inside attackers. Also, consumer networks are not the only relevant networks. There are arguably just as many hosts on enterprise networks, and the attitudes and practices of their admins (regardless of technical correctness) need to be considered. Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else? You can't completely, and obviously ALGs would fail completely if IPsec ever took off (in fact, that may be one reason it hasn't), but in practice it's the best option we have today. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at
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 16:53, Mark Newton wrote: 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. O really? When was the last time you successfully transferred a file using IM? It only works half the time for me and I don't even use NAT on my main system myself. Some audio/video chat applications work well, others decidedly less so. The only reason most stuff works most of the time is because applications tell NAT devices to open up incoming ports using uPnP or NAT-PMP. 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. If you want NAT, please come up with a standards document that describes how it works and how applications can work around it. Just implementing it and letting the broken applications fall where they may is so 1990s. If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem. NAT is not a problem and running out of IPv4 address space is a problem can't both be true at the same time. With enough NAT lubrication you can basically extend the IPv4 address space by 16 bits so you don't need IPv6. If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory. Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
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 16:55, Mark Newton 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? Well, I can think of a couple of things that make me unhappy: - IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about. - If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT.
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:56, Stephen Sprunk wrote: Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens. That's one solution. I like the hole punching better because it's more general purpose and better adheres to the principle of least astonishment. 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. Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on. 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. BitTorrent is TCP, but it sure doesn't like NAT because it gets in the way of incoming sessions. The latter solution ignores the problem space by telling people to not be v4-only anymore. Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden. 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. Disagree. Tunneling gives you actual IPv4 so obviously that will always be better than translation. One of the problems with a proxy is that you have to configure hosts to use it, and all traffic flows through it whether it's needed or not. Obviously we could make the clients smarter, but then you're back to the decade problem. It's too late for that. Automatic proxy configuration already exists. I agree that having IPv6 traffic go through a proxy is unnecessary but that can be fixed. And there's no such thing as too late (if there were, the IETF would have been out of business long ago): problems stick around until you fix them. 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. *giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years? The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors. You forget that the majority of applications need to be changed to work over IPv6. If I turn off IPv4 on my Mac and use some magic to go from v6 to v4, I can get to the web and do stuff like ssh and ftp, but most other applications don't work because they don't support IPv6 yet. On 2-okt-2007, at 16:10, Stephen Sprunk wrote: You just open up a hole in the firewall where appropriate. You obviously have no experience working in security. Who wants those headaches? 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. You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks. Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else? 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. Seems to work well, that law. But these people don't complain when their video streaming/chatting doesn't work out of the box. These are highly specialized setups that are really beyond what general purpose hard- and software can be expected to cope with. Even for home users, most have zero clue how to open a hole in their home firewall. Repeat after me: uPnP, NAT-PMP.
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: On 2-okt-2007, at 16:53, Mark Newton wrote: 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. O really? When was the last time you successfully transferred a file using IM? It only works half the time for me and I don't even use NAT on my main system myself. Some audio/video chat applications work well, others decidedly less so. The only reason most stuff works most of the time is because applications tell NAT devices to open up incoming ports using uPnP or NAT-PMP. Ah, god damn Microsoft MSN client. Just send it via gmail already. People deal with slightly broken crap all day, every day. If they had a low tolerance for it then we'd be running OSF/1+Motif on multi-core Alphas cause Windows on whiteboxes wouldn't have cut the mustard. Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem. Ah, but: * y'all didn't know what were reasonable requirements when SMTP was built; and * You're not trying to do a forklift upgrade of SMTP protocol (which, arguably, would include reasonable anti-spam methods!) Whereas: * Y'all know the issues involved in migrating from ipv4 to ipv6, as you've got operational experience with both now, and * You're trying to do a forklift upgrade of the IP protocol. Adrian
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 09:50:09PM +0200, Iljitsch van Beijnum wrote: On 2-okt-2007, at 16:55, Mark Newton wrote: So everyone will deploy IPv6 applications, which require no ALGs, instead. Isn't that a solution that everyone can be happy with? Well, I can think of a couple of things that make me unhappy: Doubtless. - IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about. With respect, that's why a bunch of us have been suggesting using techniques such as NAT-PT to make sure taht IPv6 works _and_ IPv4 works. If the mechanisms used lack sufficient quantities of perfection, they'll be modified until they're good enough. - If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT. And thus the sky falls. Perhaps it's a perspective issue, but I really don't see a problem with that. If the network works, who cares? Perhaps you'd be happier if, in recognition of the fact that NAT appears to be a dirty word, we called it something else. The IPv6 people have already jumped on this bandwagon, so it shouldn't be a huge gulf to bridge: SHIM6 is basically wide-scale highly automated NAT, in which layer-3 addresses are transparently rewritten for policy purposes (a SHIM6 middlebox, if it ever existed, would be indistinguishable from a NAT box), so we have a start here: If we rename NAT, it becomes acceptable to IPv6 proponents. So my proposal is this: Instead of saying, NAT, from now on we should say, Layer-4 switch. I don't know about you, but I feel comfortable deploying a network which has layer-4 switches in it. I already have layer-2 and layer-3 switches, so I might as well collect the whole set. That solution to this quagmire also solves the other great problem that you seem to have in gaining acceptance: There are legitimate uses for NAT right now, and there will be in the future, so arguing for the elimination of a useful tool before we can move the Internet forward strikes me as a fundamentally regressive argument. Perhaps in years to come we'll look at the people who argue for the elimination of layer-4 switches in the same way that we look at 1980's campus network administrators who thought the whole organization should be one big broadcast domain, with no place for layer-3 switches. Ah, look at that, he doesn't like NAT. How... quaint. :-) - 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: 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:07:19PM +0200, Iljitsch van Beijnum wrote: 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. If you want NAT, please come up with a standards document that describes how it works and how applications can work around it. Just implementing it and letting the broken applications fall where they may is so 1990s. Ah, how obstructive of you. We can't possibly do this until a multi-volume standards document has been written which encompasses and solves every conceivable problem with absolute perfection. Have it on my desk by 5pm. No, that's not how we do things on the Internet. It _is_ how they do things on those old-school telco networks you keep telling us to avoid emulating, but it's not our way. Never has been, likely never will be (and, indeed, I'd put it to you that the reason we're all talking about IPv6 in 2007 instead of _using_ it is because the IETF tried the old-school way instead of the Internet way to solve the running-out-of-addresses problem) If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem. NAT is not a problem and running out of IPv4 address space is a problem can't both be true at the same time. With enough NAT lubrication you can basically extend the IPv4 address space by 16 bits so you don't need IPv6. Don't you think that's a bit of an oversimplification? With respect, Iljitsch, if you want a long and bloody argument about IPv6 NAT, and you engineer one by constructing straw men to argue against, my guess is that the blood on the walls at the end of the process will be yours. If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory. Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem. My email works. How about yours? - 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: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
- IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about. but the reality is ipv4 works and ipv6 doesn't. and unless the ivory tower purists get off their doomed thrones, ipv6 will die stillborn. in fact, that is what is happening now. there are more ipv4 nats within a 1km radius of here than there are v6-enabled networks on the planet. and i am at the nexus of ipv6 deployment in the world, networking central in tokyo. - If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT. the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it. randy
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:33:43PM +0200, Iljitsch van Beijnum wrote: On 2-okt-2007, at 16:10, Stephen Sprunk wrote: 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. You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks. Err, it is. Really, it is. Residential-grade customers employ trusted parties like DLink, Alloy, Alcatel, Linksys, and various others to be in charge of the firewall that separates the untrustworthy internet from their inside network. Corporate-grade customers employ trusted parties as staff. SMEs are somewhere in between, often substituting their ISP as a proxy for staff. Ether way you cut it, the model you've just dismissed is _exactly_ the way the real world works. Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else? You can't. So if the control protocol can possibly do anything bad, the firewall administrator says, Well, can't let this take control of my network, I'll just block it. ... which breaks end-to-end reachability every bit as effectively as a NAT box does, regardless of whether or not the firewall employs NAT. Which is why various correspondents in this thread have repeatedly pointed out that any assertion that an IPv6 Internet is going to be any more end-to-end than an IPv4 Internet is delusional. 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. Seems to work well, that law. But these people don't complain when their video streaming/chatting doesn't work out of the box. splutter Oh yes they do. You better believe it. - 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: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
- If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT. Perhaps it's a perspective issue, but I really don't see a problem with that. If the network works, who cares? well, the thing is that nats in the middle really do cause problems. and we do care about those problems. it's just that inability to have a usable transition toward the wonderfully incompatible ipv6 protocol is a far worse problem. so, as this is engineering, not religion, we will make the trade-off and put up with the mostly hackable problems of nat-pt rather than the much more serious problems living with ipv4 only and a jillion nats for ever and ever. some of the older of us may be more used to such lesser of two evil compromises. heck, i voted for hubert the whore. randy
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 3-okt-2007, at 9:42, Randy Bush wrote: but the reality is ipv4 works and ipv6 doesn't. It has very little deployment at this point in time, that's something different. and unless the ivory tower purists get off their doomed thrones, ipv6 will die stillborn. And unless the purists, whatever their living arrangements, get to keep out at least some of the bad stuff that's in IPv4, the entire effort to move to IPv6 will be a waste of time because we'll all be in the exact same mess only with harder to remember addresses. there are more ipv4 nats within a 1km radius of here than there are v6-enabled networks on the planet. and i am at the nexus of ipv6 deployment in the world, networking central in tokyo. So? Still 1157 million IPv4 addresses to burn, can't realistically expect people to upgrade to IPv6 unless they have to. the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it. I'd rather have IPv4 with massive NAT and IPv6 without NAT than both IPv4 and IPv6 with moderate levels of NAT. The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another.
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Wed, Oct 03, 2007 at 12:02:31PM +0200, Iljitsch van Beijnum wrote: The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another. That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. This whole debate is a complete waste of time, because everyone, yourself included, knows that regardless of what consensus we end up with, at the end of the day if NAT makes sense NAT will be deployed. End of story, game over. This whole meme that says we need the entire industry to move in the same direction at the same time is yet another delaying fallacy, and yet another example of you proposing that we all behave like old-skool telcos inside the exact same 24 hour period when you decry any suggestion that we act like old-skool telcos. Whatever. - 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: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. This whole debate is a complete waste of time, Yup. It would be more productive for everyone in the debate to build an IPv6 router based on Linux, add NAT-PT and trial it for their own Internet access for a few weeks. Instructions are here: http://tomicki.net/ipv6.router.php The proof of the pudding is in the tasting. --Michael Dillon
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
On 3-okt-2007, at 15:52, Mark Newton wrote: The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another. That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail. This whole debate is a complete waste of time, because everyone, yourself included, knows that regardless of what consensus we end up with, at the end of the day if NAT makes sense NAT will be deployed. End of story, game over. Few things in today's internet are universal. I don't think the answer to the question whether NAT makes sense is one of them. This whole meme that says we need the entire industry to move in the same direction at the same time is yet another delaying fallacy, and yet another example of you proposing that we all behave like old-skool telcos inside the exact same 24 hour period when you decry any suggestion that we act like old-skool telcos. It takes two to tango. If you deploy something that doesn't work with what everyone else has deployed, in most cases, it's you who has the problem. In that sense, the industry must move fairly coherently. Unfortunately, this is true regardless of any underlying merit. Current path MTU discovery practices are insane but use a smaller- than-1500-byte MTU at your peril.
RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
It's seems we're always confusing NAT with PAT (or NAT overload, or whatever else you want to call it). One to one NAT rarely breaks stuff. NAT-PT would need to follow that model, otherwise, yes, things will break. It seems like an IPv6-only ISP would need to operate the NAT-PT boxes, and dedicate a block of v4 addresses the size of the expected concurrent online users to the NAT-PT box. Keep in mind that a v6 ISP with 1 million customers won't need a million v4 addresses, for obvious reasons. It's going to be considerably less than if each customer got a v4 address. NAT-PT does seem like a viable short term solution. I'm not sure though how to get current v4-only content providers to dual-stack their stuff. Increased domain fees maybe for v4-only domains... Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
break. It seems like an IPv6-only ISP would need to operate the NAT-PT boxes, and dedicate a block of v4 addresses the size of the expected concurrent online users to the NAT-PT box. Keep in mind that a v6 ISP with 1 million customers won't need a million v4 addresses, for obvious reasons. It's going to be considerably less than if each customer got a v4 address. NAT-PT does seem like a viable short term solution. I'm An IPv6-only ISP with enough IPv4 addresses for its concurrent online users seems strange. Why wouldn't that ISP give those v4 addresses to the online users instead of the NAT-PT box? And why do you call it IPv6-only? Andras
RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
-Original Message- From: JAKO Andras [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 8:59 PM To: Church, Charles Cc: nanog@merit.edu Subject: RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6) An IPv6-only ISP with enough IPv4 addresses for its concurrent online users seems strange. Why wouldn't that ISP give those v4 addresses to the online users instead of the NAT-PT box? And why do you call it IPv6-only? Andras Because not all users are online at the same time. Think back to the days where you had x number of dialup lines for y number of subscribers. It might be a 2:1 ratio. Maybe more, depending on how many time zones an ISP serves. It's not a huge plus, but once IPv4 content providers can see where x% of their web hits are coming from these NAT-PT blocks, they might be more motivated to go dual-stack. Chuck
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: 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: 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: 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: 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
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
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
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
If we agree that dual-stack can be only needed in a small part of the network (and in my opinion in all the LANs, until all the applications are IPv6-enabled), then you could use private addresses and softwires (LT2P) for automatic tunneling of protocols that you can't proxy to avoid any new translation protocol, break less things and make it all much simple. I will just add proxies (v4-v6) for protocols such as http, in order to avoid unnecessarily tunneling traffic that can just be proxied. We have this in real customers, so I know it works. Regards, Jordi De: John Curran [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sat, 29 Sep 2007 23:10:24 -0400 Para: Iljitsch van Beijnum [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Asunto: Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6) At 11:13 PM +0200 10/21/07, Iljitsch van Beijnum wrote: ... If an IPv6-only box is going to talk to the IPv4 world, at some point, the traffic needs to hit a dual stack system that can do the IPv6/IPv4 translation. I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT. There are companies which would like to be connecting new customers with IPv6 as we approach IPv4 depletion and then handle translation for IPv4 site connectivity in their network i.e. customers connecting to The Internet via only IPv6 with the expectation of reaching all Internet destinations (IPv4 and IPv6) without any hassles. While making the backbone networks dual-stack is going to be serious work, it's at least an understandable goal that operators can makes plans to hit. That's not the case with the requirement to provide transparent connectivity to IPv4 destinations via IPv6 transport. NAT-PT wasn't exactly an elegant solution, but it's now precisely what some providers are looking for (so connecting customers via just IPv6 is at least viable). Without it, every provider is going to come up with ad-hoc customer connection models with various IPv4 tunnelling and translation games once IPv4 address blocks become generally unavailable. The irony is that the I* rationale for moving NAT-PT to historic was to restore the end-to-end transparency of the Internet and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain end to end transparency via IPv6. /John ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
