Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Mon, Nov 24, 2008 at 15:46, Margaret Wasserman [EMAIL PROTECTED]wrote: On Nov 24, 2008, at 5:56 AM, Eric Klein wrote: We need a team made up of both sides to sit down, spell out what are the functions of NAT (using v4 as a basis) and then to see if: 1. If they are still relevant (like number shortage from v4 is not the same issue under v6 for example) 2. Do they already exist in v6 without adding NAT This was already done, and the results are in RFC 4864. I know, I was one of the co-authors of that RFC. But there seems to be a differnce of opnion as to how well we covered all pervieved needs - otherwise this discussion would not be happening and everyone would say oh yeah we don't need on NAT But as there are people that have a percieced need for topology hiding and port translation lets look at this compleatly and build what is needed the first time (and prevent the need for BEHAVE to rebuild it later) Then we need to check: 1. Is there is a solution by using NAT 2. Is there is a better solution than using NAT #2 was done in the gap analysis section of RFC 4864. I'm not sure what you mean by #1, because if you start with a list of the functions of NAT, the fact that NAT can be used for those functions just follows, doesn't it? #1 asks that if NAT will not fit the real need, why use it to fit the percieve need. Only then can we make a proper and informed decission on what is needed and what is unneeded legacy. I think we are ready to do this, based on the information in RFC 4864. Do you see anything missing from 4864 that needs to be analyzed further? If so, could you send specific points, and perhaps we can consider an update? All of the points that have been made in this chain point to diffrent percieved requreiments, and there are multiple proposed solutions being tossed around. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On 25 nov 2008, at 23:10, Tony Hain wrote: Iljitsch van Beijnum wrote: ... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? Who do you ask??? Your note assumes there is only one 'outside', so any server could answer the question. There is absolutely no restriction on where and how topology warts are deployed, so asking a server in network A what your address will appear to be to network B is fundamentally absurd. Well, the case where my externally visible address is different depending on who I talk to makes it fundamentally impossible to set up peer to peer connections if the other end is living with the same limitation, so we'd have to define this such that only a single translation is permitted at a time. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
From: David Conrad [EMAIL PROTECTED] The architecture is _ALREADY_ broken. 66NAT is merely another symptom of the underlying disease. Hey, that's what happens when you pick as 'the next generation of networking', X.25 with a larger sequence number space (or, for you youngsters who don't remember X.25, ATM with a larger cell size). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Please, any input into this debate shall go to the behave list. People interested in this topic please subscribe to Behave. Regards Magnus Peter Dambier skrev: Keith Moore wrote: absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? That is what bothers me too. sip is mostly peer to peer, so for most of your communication (in megabytes) no server in a rack needed. Email, with fixed IPv6 addresses will become peer to peer again too. html? html is not much traffic. Many people do html hehind their NAT44 boxes today. There is still a lot to be done for zeroconf, so DNS still is ok with a server in a rack. Oh, I forgot. For DNS you are still dependent on IPv4. All the enthusiasts with their linux and freebsd boxes using ISATAP to communicate don't see a need for NAT66. It is the big guys with big windows servers who really need NAT66 to hide their fragile machines from the bad wild internet. I am one of those poor guys who has never been told what good NAT66 can do for him. I am still troubled by NAT44 preventing me from connecting with my ISATAP interface. I am running more than one computer. That is why I am imprisoned behind my NAT44 and I am afraid NAT66 will be yet another prison. I have seen with tunneling (slow as molasses) I get only a single /128. So I guess a bilingual router will sit on both his single IPv4 and another single IPv6 and keep all the traffic for himself letting me do the guesswork how to drill the holes I need to connect to the internet. I see with IPv6 I do have to compete with my fridge and the central heating drilling holes to talk to the butcher, the baker and the oil-tanker. None of them is living in a rack in a colocation. They all have to drill holes into their NAT66 to talk to my home. There is a hole industry living from selling me super excluse and expensive drilling machinery, I would not need if there was not a NAT66 in the first place. I know NAT44 is like my front door and keeps the bad internet out. But it is not NAT44, it is the firewall who keeps them out. Only a vague feeling for symmetry keeps telling me I should have a NAT66. Math is telling me that need not be true. IPv4 brought us from point to point clothes line to 2-dimensional space spanning continents. IPv6 will bring us 3-dimensional space spanning the globe and DNT will bring us even further. I do not know if there is such a thing as NAT66 existing. In 2-D space we do have trigons, squares, pentagons, hexagon... In 3-D space live stops with things built from pentagons. The guys with their big windows servers behind NAT44 are living in a 2-D world, dreaming their 2-D dreams bout selling us 3-D NAT66 boxes without even knowing the math. Kind regards Peter -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Nov 25, 2008, at 15:11, Sam Hartman wrote: Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? No. RFC 3424 is the IAB Considerations document covering that problem. I'm tempted to copy and paste highlights from that ancient scripture here, but I don't think I'd know where to stop. As the kiddies say, Read The Whole Thing. The basic problem with NAT66 is that it introduces the possibility of more than one global IPv6 address realm. Where there is more than one, there is *any* number, not just the current realm and the single realm on the other side of the relevant NAT66 box. Fixing your self- address in whatever address realm any given communications peer happens to reside is the canonical problem that NAT causes for applications developers, and NAT66 is no exception to that. If we're going to go very far down this road toward standardizing on a NAT66 solution, then I would humbly suggest that it doesn't make much sense for there to be a single global DNS horizon where we have multiple global address realms. Do the proponents of NAT66 have any proposals for extending DNS appropriately to support the architecture that NAT66 implies? Do we really want to open the can of worms that multiple global DNS horizons represents? I should hope not. -- james woodyatt [EMAIL PROTECTED] member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
At 6:07 PM -0800 11/25/08, David Conrad wrote: Tony, On Nov 25, 2008, at 4:41 PM, Tony Hain wrote: Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. Stuff they presumably already have to deal with because they'd like their applications to be used in the real (IPv4+NAT) world... Have to deal with does not mean that the current solutions actually work. As I said in my first message in my thread, the estimates we have for ICE-TCP working in the real world are 40% or so, and it is the best thing that we have. That means real applications that already benefit from 1) having a known rendezvous/signalling path and 2) have defined methods for using relays *still fail the majority of the time they use TCP*. We deal with that by not having the apps deploy. One of the few ways to actual get a pull for v6, rather than than exhaustion-based push, is to have the topology sufficiently simpler that some things work there better than they work in v4. Introduce NAT, and you have shot that possibility in the head, not the foot. There is a reason we see so many systems deploying in overlay networks at this point--the IP topology is so broken for v4 that it is better to use a key-based routing system on top of it than to use the topology itself. If we are giving up on this for v6 at this point, we need much more work on dealing with overlays, because our ability to have non client-server systems will depend largely on them. A reasonable standards development effort would not blindly endorse something known to be detrimental, Standards development effort != endorsement. But the IETF sells itself as something that gets cross-area review and gives a benefit in understanding how a technology fits in the ecosystem. If we aren't going to pay attention to it when it comes, we have relatively little value beyond a cheaper industry consortium. The review on this is trying to express real concerns.You have people offering to do real work to come up with solutions that meet the need without this breakage. That's not possible, obviously, if the need is introduce NAT, but if the need is expressible in security properties or a threat model, I personally believe we can do much, much better. Happy Thanksgiving, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
FWIW - I wholeheartedly agree with If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. In fact, I think this (end nodes awareness of their real external address and port) should be one of the, if not the, biggest design goals for NAT66 ... assuming we do define it. This enables the NAT to still do its thing, while still retaining the ability for apparent end to end communications. Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow firewall pinhole creation might just be useful, with a note of concern around security of course ... /TJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore Sent: Tuesday, November 25, 2008 5:43 PM To: David Morris Cc: 'IAB'; '[EMAIL PROTECTED] WG'; 'IETF Discussion'; 'IESG IESG' Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers David Morris wrote: Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. I understand. But in practice just knowing your external address is often insufficient. You need an intermediate server that will forward traffic as well as maintain the bindings in both (nay, all) endpoints' NATs. If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. Furthermore it's not sufficient to just define a NAT with a bidirectional, algorithmic mapping (in order to avoid some of these problems) because what people have come to expect from NAT (and to rely on) is that incoming connections are denied by default. So really, to be viable, any NAT standard needs to include some amount of firewall functionality. And the firewall needs to be able to keep working even if the NAT function is turned off. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
As far as I can tell, most of what is being asked for here has little, if anything, to do with NAT. To paraphrase: If we are going to have firewalls which block incoming connections, communication between entities behind such firewalls should still be possible without any external servers. That is a tall (not impossible, but quite tall) order, which we have attempted to address several times with little effect. And let us be very clear. Network admins have been asking for and using such features for at least 18 years, well before NAT. I would recommend separating the problems. The NAT solution, as I understand it, does not make this problem worses. That is about all one can ask of the NAT side of the equation. Yours, Joel M. Halpern TJ wrote: FWIW - I wholeheartedly agree with If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. In fact, I think this (end nodes awareness of their real external address and port) should be one of the, if not the, biggest design goals for NAT66 ... assuming we do define it. This enables the NAT to still do its thing, while still retaining the ability for apparent end to end communications. Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow firewall pinhole creation might just be useful, with a note of concern around security of course ... /TJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore Sent: Tuesday, November 25, 2008 5:43 PM To: David Morris Cc: 'IAB'; '[EMAIL PROTECTED] WG'; 'IETF Discussion'; 'IESG IESG' Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers David Morris wrote: Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. I understand. But in practice just knowing your external address is often insufficient. You need an intermediate server that will forward traffic as well as maintain the bindings in both (nay, all) endpoints' NATs. If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. Furthermore it's not sufficient to just define a NAT with a bidirectional, algorithmic mapping (in order to avoid some of these problems) because what people have come to expect from NAT (and to rely on) is that incoming connections are denied by default. So really, to be viable, any NAT standard needs to include some amount of firewall functionality. And the firewall needs to be able to keep working even if the NAT function is turned off. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Joel M. Halpern wrote: As far as I can tell, most of what is being asked for here has little, if anything, to do with NAT. To paraphrase: If we are going to have firewalls which block incoming connections, communication between entities behind such firewalls should still be possible without any external servers. That is a tall (not impossible, but quite tall) order, which we have attempted to address several times with little effect. And let us be very clear. Network admins have been asking for and using such features for at least 18 years, well before NAT. I would recommend separating the problems. The NAT solution, as I understand it, does not make this problem worses. That is about all one can ask of the NAT side of the equation. the problem with separating the problem is that we'll solve the easy part first (the NAT part) and put off trying to solve the biggest part of the problem that is really keeping applications from working efficiently or reliably ... and meanwhile we'll have done nothing to improve security either. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Iljitsch van Beijnum wrote: On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Tue, 25 Nov 2008, Keith Moore wrote: Iljitsch van Beijnum wrote: On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. A ip-ip mapping lookup service, probably not all that different than DNS or the service the telcos use to map 8xx numbers to actual phones, or phone numbers to specific terminal devices on specific carriers. I don't know if that is a good approach or not but I find it quite a bit less onerous than routing all traffic via an intermediate server. And it seemed the question wasn't understood. Dave Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Morris wrote: Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. I understand. But in practice just knowing your external address is often insufficient. You need an intermediate server that will forward traffic as well as maintain the bindings in both (nay, all) endpoints' NATs. If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. Furthermore it's not sufficient to just define a NAT with a bidirectional, algorithmic mapping (in order to avoid some of these problems) because what people have come to expect from NAT (and to rely on) is that incoming connections are denied by default. So really, to be viable, any NAT standard needs to include some amount of firewall functionality. And the firewall needs to be able to keep working even if the NAT function is turned off. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Keith == Keith Moore [EMAIL PROTECTED] writes: Keith I understand. But in practice just knowing your external Keith address is often insufficient. You need an intermediate Keith server that will forward traffic as well as maintain the Keith bindings in both (nay, all) endpoints' NATs. Keith If we're going to standardize NATs of any kind, they need Keith to be defined in such a way that no external server is Keith necessary - not to determine one's external IP address, nor Keith to forward traffic between hosts that are all behind NATs, Keith nor to maintain state in the NAT, nor to determine a host's Keith 'external' IP address or port, nor to listen for traffic Keith intended for a host behind a NAT. All of this Keith functionality (and more) needs to be built in to the NAT Keith itself. Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? How about the existing proposal plus an IPV6 anycast address for a stun-like protocol? If not, why not? I'm a bit concerned about adding requirements that would involve solving the NAT discovery problem. We've already had a lot of bad luck with that approach in protocols like midcom, nsis, etc. In contrast, in environments where it works, stun has been quite successful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Iljitsch van Beijnum wrote: ... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? Who do you ask??? Your note assumes there is only one 'outside', so any server could answer the question. There is absolutely no restriction on where and how topology warts are deployed, so asking a server in network A what your address will appear to be to network B is fundamentally absurd. I have heard similar comments from the document authors recognizing this problem, but hand-waving something about asking a service before populating DNS, while completely ignoring the fact that there is no way to predict in advance who will want to know or where they will be attached. Essentially a server is not reachable until it guesses that network B exists, someone wants to contact it from there, and where the service is to ask about the address that the server appears to be. There is no valid reason for 66nat. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony, On Nov 25, 2008, at 2:10 PM, Tony Hain wrote: There is no valid reason for 66nat. Then it will die in the marketplace and any standardization efforts will simply fade away. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. So, if vendors are trying to build it, it would seem to me that an industry group focused on standardizing its functionality would be a good thing, otherwise we get into the same mess we got into with IPv4. If vendors aren't trying to build it, no significant harm is done (other than the waste of time for folks participating in the standardization). Putting our fingers in our ears and singing la la la because we don't think a particular technology should exist is unlikely to be particularly beneficial. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Sam Hartman wrote: Keith == Keith Moore [EMAIL PROTECTED] writes: Keith I understand. But in practice just knowing your external Keith address is often insufficient. You need an intermediate Keith server that will forward traffic as well as maintain the Keith bindings in both (nay, all) endpoints' NATs. Keith If we're going to standardize NATs of any kind, they need Keith to be defined in such a way that no external server is Keith necessary - not to determine one's external IP address, nor Keith to forward traffic between hosts that are all behind NATs, Keith nor to maintain state in the NAT, nor to determine a host's Keith 'external' IP address or port, nor to listen for traffic Keith intended for a host behind a NAT. All of this Keith functionality (and more) needs to be built in to the NAT Keith itself. Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? How about the existing proposal plus an IPV6 anycast address for a stun-like protocol? If not, why not? I don't think so in either case. The reason I don't think so is that I suspect the NAT traversal problem is really a firewall traversal problem in disguise. People say they want NATs when what they mostly want is stateful firewalls and maybe some topology hiding. We might get them to move to stateless NATs with bidirectional algorithmic mapping and a STUN-like protocol, but they'll still want a statefull firewall to be bundled in to block incoming connections. And if there's a statefull firewall that denies incoming connections by default, there will still be a need for an intermediary in the network core that can arrange for traffic to be forwarded between two hosts that are behind firewalls. And there will be little incentive for any network admin to get rid of NAT, because as long as those firewalls are in the way, doing so won't enable many more applications. So if we really want to get rid of NAT, I think we have to resolve a tussle between users and application developers on one hand, and enterprise network operators on the other. The tussle is over two things: (1) how to restrict the kinds of traffic that can be sent over the network, how to communicate those restrictions to apps, and what kind of behavior is reasonable for apps that are presented with such restrictions. (2) to what extent network admins can control what programs are used on hosts that attach to their networks. Hey, I didn't say it was easy. But I don't think anything less will get rid of the need for the kinds of workarounds apps currently have to use to deal with NATs. Even if we got rid of NAT, we wouldn't solve the problem (and NATs wouldn't matter too much) if apps still have to use those workarounds. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Conrad wrote: Tony, On Nov 25, 2008, at 2:10 PM, Tony Hain wrote: There is no valid reason for 66nat. Then it will die in the marketplace and any standardization efforts will simply fade away. No it won't, because people will have deployed it in default configurations without realizing they didn't need it. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. So, if vendors are trying to build it, it would seem to me that an industry group focused on standardizing its functionality would be a good thing, otherwise we get into the same mess we got into with IPv4. If vendors aren't trying to build it, no significant harm is done (other than the waste of time for folks participating in the standardization). Putting our fingers in our ears and singing la la la because we don't think a particular technology should exist is unlikely to be particularly beneficial. This is not about ignoring the technology, it is about blindly legitimizing short-term money making for a few box vendors at the long term expense to the entire Internet application development and end user community. If it were simply a stand-alone technology, it would have to show value before being deployed. It is not, because the IPv4 version of it became mandatory, and due to marketing crap synonymous with firewall. This ensures people will deploy it a) without awareness as a default 'security' config, or b) because they have completely drowned in the nat==security kool-aid. Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. A reasonable standards development effort would not blindly endorse something known to be detrimental, simply because one constituency plans to make a quick buck. We do have an Architecture Board, and a Steering Group, so one would think we have reason to be thoughtful about the long term impacts of what we publish. Instead all we get is complaints that anyone not helping detail how to ship the broken architecture is ignoring reality and off in a fantasy land, when the exact opposite is closer to the truth. Rushing to restock the drug dealers while claiming we have no hand in the outcome is about as far from reality as one can get. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
james woodyatt wrote: On Nov 25, 2008, at 15:11, Sam Hartman wrote: Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? No. RFC 3424 is the IAB Considerations document covering that problem. I'm tempted to copy and paste highlights from that ancient scripture here, but I don't think I'd know where to stop. As the kiddies say, Read The Whole Thing. The basic problem with NAT66 is that it introduces the possibility of more than one global IPv6 address realm. Where there is more than one, there is *any* number, not just the current realm and the single realm on the other side of the relevant NAT66 box. I'm not sure about that. Conflicting use of address space is probably the biggest single source of NAT-related pain that network operators experience. If enterprise network operators can still NAT without reusing the same addresses in different realms, I think they'll mostly do so. And regardless of what else happens with NAT66, I think it's reasonable for IETF to make it really clear that apps aren't expected to deal with conflicting address assignment in IPv6. Fixing your self-address in whatever address realm any given communications peer happens to reside is the canonical problem that NAT causes for applications developers, and NAT66 is no exception to that. No, it's only one of several canonical problems that NAT causes for applications developers. If we narrow the focus to that one problem, we'll miss the boat - we won't produce a solution that makes life any easier for apps developers. If we're going to go very far down this road toward standardizing on a NAT66 solution, then I would humbly suggest that it doesn't make much sense for there to be a single global DNS horizon where we have multiple global address realms. If we were going down that road, I'd agree with you. But I'll make a stronger statement - any solution to NATxx (for any value of xx) that requires split DNS should be considered a non-starter. It doesn't make much sense to improve consistency at the IP naming layer if you're going to degrade consistency at the DNS naming layer. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony Hain wrote: There is no valid reason for 66nat. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. Okay, let's try to be a tad more precise. There is a subtle but important difference between: A) There is no valid reason for 66nat and B) There are obvious ways to solve the problems that people want to solve with 66nat that are both easier to understand and technically superior The two statements should have equivalent truth values, but the second one is more illuminating. It follows that if we want people to avoid using 66nat, we need to (a) identify or provide technically superior solutions that are easy to understand and (b) make them obvious to people. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony, On Nov 25, 2008, at 4:41 PM, Tony Hain wrote: Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. Stuff they presumably already have to deal with because they'd like their applications to be used in the real (IPv4+NAT) world... A reasonable standards development effort would not blindly endorse something known to be detrimental, Standards development effort != endorsement. I considered NetBIOS to be wildly offensive and actively detrimental, but RFC 1001 and 1002 were appropriate codifications of NetBIOS over TCP/UDP/IP. Instead all we get is complaints that anyone not helping detail how to ship the broken architecture is ignoring reality and off in a fantasy land, when the exact opposite is closer to the truth. The architecture is _ALREADY_ broken. 66NAT is merely another symptom of the underlying disease. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Conrad wrote: Tony, On Nov 25, 2008, at 4:41 PM, Tony Hain wrote: Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. Stuff they presumably already have to deal with because they'd like their applications to be used in the real (IPv4+NAT) world... Yeah, but we're trying to get rid of that stuff, or at least considerably reduce the cost and complexity, because (among other things) it presents a huge barrier to adoption of new multiparty apps. A reasonable standards development effort would not blindly endorse something known to be detrimental, Standards development effort != endorsement. According to RFC 2026, IETF standardization is a kind of an endorsement, because it's a statement of both protocol quality and community consensus. The architecture is _ALREADY_ broken. 66NAT is merely another symptom of the underlying disease. Just because a disease exists does not mean we have to encourage its spread. The only reason for IETF to standardize some kind of 66NAT is to significantly improve the situation over what would happen in the absence of standardization. There are several ways that we could probably do that. But one of them is NOT to standardize NATs like they exist in IPv4. We already know that that sucks really badly, and it would never meet the criteria defined in RFC 2026. Nor would it achieve community consensus. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker [EMAIL PROTECTED] wrote: On Nov 21, 2008, at 9:39 PM, Tony Hain wrote: The discussion today in Behave shows there is very strong peer-pressure group-think with no serious analysis of the long term implications about what is being discussed. Yes, there is a very clear anti-NAT religion that drives a lot of thought. It's not clear that any other opinion is tolerated. Fred, I pesonally would be open to a real discussion about the needs and then about the solution. But for now NAT has taken on religious connotations with those who are for it being as single minded as those who are against it. We need a team made up of both sides to sit down, spell out what are the functions of NAT (using v4 as a basis) and then to see if: 1. If they are still relevant (like number shortage from v4 is not the same issue under v6 for example) 2. Do they already exist in v6 without adding NAT Then we need to check: 1. Is there is a solution by using NAT 2. Is there is a better solution than using NAT Only then can we make a proper and informed decission on what is needed and what is unneeded legacy. Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Hi Eric, I would like to be part of that group. My little network is connected to the internet via a NAT router and I could not live without it because daily renumbering wont do. On the other hand that NAT-box is the biggest obstacle between my network and IPv6. I would like to help design a NAT that is not an obstacle but a stepping stone. Kind regards Peter Eric Klein wrote: On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Nov 21, 2008, at 9:39 PM, Tony Hain wrote: The discussion today in Behave shows there is very strong peer-pressure group-think with no serious analysis of the long term implications about what is being discussed. Yes, there is a very clear anti-NAT religion that drives a lot of thought. It's not clear that any other opinion is tolerated. Fred, I pesonally would be open to a real discussion about the needs and then about the solution. But for now NAT has taken on religious connotations with those who are for it being as single minded as those who are against it. We need a team made up of both sides to sit down, spell out what are the functions of NAT (using v4 as a basis) and then to see if: 1. If they are still relevant (like number shortage from v4 is not the same issue under v6 for example) 2. Do they already exist in v6 without adding NAT Then we need to check: 1. Is there is a solution by using NAT 2. Is there is a better solution than using NAT Only then can we make a proper and informed decission on what is needed and what is unneeded legacy. Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
This is not anti-nat religion. There are costs that every application developer has to absorb to deal with topology warts, and the people that are focused on their little part of the problem space refuse to acknowledge those costs. They also refuse to recognize the fact that these costs are multiplied many times over due to the breadth of the application development space. In terms of the overall costs to the system, squeezing a cost out of the core forces a much larger cost spread all around the edges. The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Baker Sent: Friday, November 21, 2008 10:08 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] WG; IAB; IETF Discussion; IESG IESG Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers On Nov 21, 2008, at 9:39 PM, Tony Hain wrote: The discussion today in Behave shows there is very strong peer- pressure group-think with no serious analysis of the long term implications about what is being discussed. Yes, there is a very clear anti-NAT religion that drives a lot of thought. It's not clear that any other opinion is tolerated. ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
