Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
On Fri, Nov 28, 2008 at 21:50, Hallam-Baker, Phillip [EMAIL PROTECTED]wrote: Yes, we all know that it is much easier to get O/S vendors to fix their billion plus lines of code and the apps vendors to fix their million plus lines of code than it is to deploy a $50 NAT box. What you are proposing here is that we bell the cat instead. Not necessarily, but it would be nice if we could both have systems that are not coded badly and networks that are not broken by design. And I really doubt that the lines of code, in say Vista, that relate to IP stack and addressed makes up even 0.01% of their code. ___ 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 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 applicationdevelopers
On Wed, Nov 26, 2008 at 19:14, Hallam-Baker, Phillip [EMAIL PROTECTED]wrote: Eric, The problem here is that you assume that the IETF has decision power that can magic away NAT66. Clearly it did not for NAT44 and will not for NAT66. There is a diffrence between doing aways with NAT, allowing natural growth of NAT, and endorsing NAT. Of the 3 I only object to the 2nd one. So we either kill NAT so dead that it can not be brough back in any form or we find a way to meet the needs in a way that will not break the internet nor prevent new p2p applications. The only way that the effort being expended to kill NAT66 makes any sense is if the idea is to allow this type of argument to be rulled out of scope as similar arguments were ruled out of scope when they were brought up in existing protocols that simply do not work properly because the design was intentionally made to be unfriendly to NAT. Agreed, but to do that we need a consensus - and that seems very hard to reach on this topic If we recognize that there is no consensus that applications that are not NAT66-agile will work in future then we should agree that the reasonable default requirement for an apps WG should be that it should build a protocol that is NAT66 tolerant. But I suspect that there will be severe pushback against that. Peter Dambier is right in this case, I would NAT66 my network for the simple reason that very few endpoint devices actually tollerate a change in the IP address without at a minimum a service interruption. Since I cannot guarantee that my IPv6 address from my ISP will never change I am going to NAT66 my internal network for the sake of having static numbering inside the network. The more infrequent you posit the need for renumbering is, the greater my reluctance to allowing it will become. If you have a network event that happens only once a year it is going to mean a very serious disruption when it happens. DHCP only solves some of the problems, I am still effectively forced to perform a reboot, I will lose connections and this will cost me real time and money to fix. This goes back to the renumbering issue, and I agree it is a real and signifigant issue. But I am still not convienced that NAT is the only solution. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
On Wed, Nov 26, 2008 at 19:17, Ned Freed [EMAIL PROTECTED] wrote: I would NAT66 my network for the simple reason that very few endpoint devices actually tollerate a change in the IP address without at a minimum a service interruption. Since I cannot guarantee that my IPv6 address from my ISP will never change I am going to NAT66 my internal network for the sake of having static numbering inside the network. Bingo. That's exactly the reason long-term I'll probably do it too. And even this assumes that renumbering support of any kind manifests in a useful way. The absolutely dismal state of support for IPv6 in SOHO-grade routers is IMO one of the orimary current impediments for IPv6 deployment. And when IPv6 support does start to show up in these boxes, I really have to wonder if they'll get automatic renumbering right, assuming it's supported at all. The more infrequent you posit the need for renumbering is, the greater my reluctance to allowing it will become. If you have a network event that happens only once a year it is going to mean a very serious disruption when it happens. DHCP only solves some of the problems, I am still effectively forced to perform a reboot, I will lose connections and this will cost me real time and money to fix. I went for something like 10 years without having to renumber, and as a result IP addresses got put in all sorts of nooks and crannies on my network. Then suddenly and without warning my ISP announced an emeergency numbering change due to an upstream provider switch. The announcement went out at 11:00PM Sunday night; the renumbering occurred the next morning. It is a bit of an understatement to say I was not a happy camper. And then it happened again a week or so later - easier because I had notes on all the stuff that needed changing plus I'd switched to DHCP as much as possible, but still no picnic. And then I had to renumber again when I switched ISPs ;-) But that should be the last time because I took the opportunity to switch to 1:1 NAT and private address space. In any case, I think getting renumbering right and getting it deployed is an essential step in minimizing the use of NAT66. There are many drafts out there on renumbering, maybe we need to review them to see how they fit in this issue or if NAT would do away with the need for them. This is the analysis I am asking for. 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
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] Can we have on NAT66 discussion?
Hi Phillip, On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip [EMAIL PROTECTED]wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. If you want to effect a transition from IPv4 to IPv6, the only way to do that effectively is to design a protocol stack in which the applications simply do not care whether their packets are routed over IPv4, IPv6 or carrier pidgeon. Agreed NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts. NAT is not and never was a security feature, it was a way to use fewer numbers because they were hard to get. Please stop the falacy that NAT in any way is related to security, otherwise we would not need firewalls. I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed. On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it. This is not quite true, the ones who have been argueing against it have constantly asked why we need it. But we still do not know why we need NAT, no one has done the gap analysis. And yes, I have been guilty of many of the same mistakes. But unlike some folk I am not about to compound that mistake by telling the folk who want NAT66 that they should visit a re-education camp and unlearn their heretical thoughts. The only reason NAT is bad in practice is because some people were so opposed to the concept that they decided it would be a good thing to allow designs that were purposefully designed to be NAT-unfriendly. If we don't want to have these discussions on the IETF list we should have a separate architecture list. NAT66 is a reasonable protocol proposal to make. If BEHAVE does not like the idea let the advocates start a new group. This is why I am proposing a wider audience make a decission rather than having several groups making solutions without understanding the need. -- *From:* [EMAIL PROTECTED] on behalf of Mark Townsley *Sent:* Thu 11/13/2008 9:10 AM *To:* Eric Klein *Cc:* Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org *Subject:* Re: [BEHAVE] Can we have on NAT66 discussion? Eric Klein wrote: Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. I agree, and it is not behave's place to make that decision at this time. I had originally proposed that this be discussed in int-area (if nothing else because behave's plate is rather full), but some folks pointed out that some modes may have affects on applications and that behave was best able to determine that, particularly within context of the other NATxy work. I'm looking forward to that assessment. So for now this should remain discussion to understand the problem space and potential solution space better, not a final referendum on whether or not the IETF is going to charter work in or otherwise endorse NAT66 in any manner. Thanks, - Mark Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need
Re: [BEHAVE] Can we have on NAT66 discussion?
Hi Darrel, Comments below On Thu, Nov 13, 2008 at 9:30 PM, Darrel Lewis (darlewis) [EMAIL PROTECTED] wrote: Comments below inline with DL NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts. NAT is not and never was a security feature, it was a way to use fewer numbers because they were hard to get. Please stop the falacy that NAT in any way is related to security, otherwise we would not need firewalls. DL Port/Overload NAT for IPv4 (NAT:P) has security benefits in that it requires explicit configuration to allow for inbound unsolicited transport connections (via port forwarding) to 'inside' hosts. This mimics many of the default policies on most firewalls, hence the confusion. Note that can also cause security issues elsewhere in the network. The loss of information of the identity of the source host can cause address filtering in the network to effect other devices than just the one intended. If you are keeping the source IP address the full length of the session, then there is no problem of loosing hte identiy of the source host, thus there should be no problem with address filtering - this is the point of not breaking the end-to-end connectivity that is built into v6. This has nothing to do with ports, so that requirement is not relevant as far as I can see. DL I'm wondering if this is written down somewhere, because both of the above points seem to be argued over and over again, without people being genererally educated about them. I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed. On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it. This is not quite true, the ones who have been argueing against it have constantly asked why we need it. But we still do not know why we need NAT, no one has done the gap analysis. DL I would argue that stateless filtering (e.g. access control lists) are even more common than firewalls and are the single most widely used network security control. But the main point is that firewalls ( statefull (flow based) filtering that usually have default policies), are orthogonal to address translation. They just happen to occur at the same point in the topology in many networks. DL But I think Eric you have a good point about documenting the relationship between a privately addressed IPv4 site and a publicly addresses IPv6 site. We should publicly document the differences, it would likely make or break the case for NAT66. Darrel, this is exactly my point. I do not want to predujice the final solution, but until we know what we want to fix just throwing NAT at it is not good enough. If there is a real need that requires some or all of the old NAT44 then I will suppor it - but I want to know why we need it over anyother solution first. Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely discussion of the topic. - Mark Margaret Wasserman wrote: Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, [EMAIL PROTECTED] wrote: Cross posted to several lists Can we keep the NAT66 discussion to less than WGs at a time? I am trying to keep up with multiple threads on this and trying to explain that we do not have a valid requirement for NAT66 defined on any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). Le's get this to one group (maybe we need a new mailing list just for NAT66 discussions, but this is getting out of hand. Until now the simple response is that the IETF does not support NAT in the v6 architecture. If this needs changing lets do it right with proper gap analysis and needs assessment, and then seeing if there is a solution (several have been proposed that are not NAT) or if we need to create one, and if those fail then see about changing the architecture of IPv6. Eric ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ 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
