Hi Chris, I don't understand your points.
In my mind, all IETF participants are individual, not delegate of organization. Regarding NAT66, I believe we (everyone) are FREE to express our opinions. And regarding standard of NAT66, I believe we SHOULD carefully consider its advantage, and disadvantage, or even danger, harm ... > The point I'm trying to make is why should individuals feel compelled to oppose > the creation of a standard simply because that standard is only applicable to a > particular scope of usage cases. For example, my company doesn't utilize > VoIP.... is it reasonable for us to oppose the existance of VoIP standards or > some-one elses choice to utilize VoIP as a technology simply because we won't > utilize it? If you are not interested in VoIP, let me say, it's better to keep silent to VoIP standards. And again, we are speaking here not because our organizations manufacture or sell NAT66 boxes, or competitive organizations manufacture/sell NAT66 box, it is just because we individuals are interested in this topic. > > The same should hold true for NAT. Those of us on the Enterprise side who > CHOOSE to deploy NAT know full well that it will break certain types of apps. In > general we DON'T want those type of apps crossing our network boundaries in > the first place.....and take steps to try to block them even without NAT. We > further recognize that IF we do want to utilize one of those apps through NAT > WE bear the burden/cost for establishing a work around. Why is it not > acceptable for us to ask for a standard for NAT in IPv6 that would cover our > usage case? Everyone are free to ask for any standard of anything here, imho, that (the behavior of asking, but not the content) is of course acceptable. But, before the acceptance and standardization, it is also acceptable that the items are deeply discussed. Maybe you don't care the end customers and internet users behind you (or maybe you intend to control something, e.g. filtering something), but you can not oppose others to consider these issues. I also believe, for any solution (the worst one included), there is always someone can get benefit from it, but many solutions cannot become standard solution, because their advantage are less than their disadvantage. This means, standardization need to balance the advantage and disadvantage. > > No one is arguing for a standard that NAT MUST be deployed across the entire > internet. People simply want a standard by which organizations which CHOOSE > to deploy it on their OWN network boundaries can expect it to behave > consistently. I believe, if there was NO NAT66 standard, in technology, everyone is FREE to invent/manufacture/sell/develop/etc. their OWN NAT66 box. Regards, Xiangsong > > > > > Christopher Engel > Network Infrastructure Manager > SponsorDirect > [email protected] > www.SponsorDirect.com > p(914) 729-7218 > f (914) 729-7201 > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > On Behalf Of Brian E Carpenter > > Sent: Monday, October 25, 2010 6:30 PM > > To: Gert Doering > > Cc: Roger Marquis; Margaret Wasserman; [email protected] > > Subject: [nat66] e2e [New Version Notification for draft-mrw-nat66-00] > > > > > > Gert, > > > > On 2010-10-26 04:59, Gert Doering wrote: > > > Hi, > > > > > > On Mon, Oct 25, 2010 at 05:41:30PM +0200, Rémi Després wrote: > > >> But, again, many users already use "native" IPv6 (neither 6to4 nor > > >> Teredo) and no bomb has exploded. And AFAIK no bomb is timed to > > >> explode either. > > > > > > Please understand that *your* customers are not the type of > > networks > > > Chris Engel talks about. Residential and enterprise are the most > > > distant points in a spectrum - residential *wants* e2e and > > p2p apps, > > > while enterprise does *not* want that. > > > > > > This discussion has been rehashed a number of times now, > > and it's time > > > that the "anti-NAT" crowd starts to accept that e2e is not > > a desirable > > > property in some networks, and thus, this aspect of NAT doesn't do > > > "harm". > > > > The problem comes when one of the ends tries to participate > > in a multi-party protocol. The state that a NAPT creates to > > permit a two-party protocol to work isn't able to support a > > third party. > > > > So, people whose model of connection to the Internet only > > involves two-party client-server protocols can use the > > arguments Chris Engel has expressed, but if they want > > multi-party protocols they have to start using some kind of > > kludge. (I am including things like ICE in the category "kludge".) > > > > Has anyone analysed how stateless NAT66 will impact > > multi-party applications? Since it doesn't break address > > uniqueness, there may be hope. > > > > Brian > > > > _______________________________________________ > > nat66 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nat66 > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
