![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
ftp://ftpeng.cisco.com/fred/gse/behave-nat66-gse.pdf
At this point, given the amount of discussion that has happened that
presumes that "we", for some definition of that term, are wise, smart,
and good, and everyone else (in your email, those thieving greedy
vendors), without taking into account the written statements or the
discussion that happened in the working group meeting (which is the
email address you conveniently dropped from the thread), I am at a
loss for words.
Take time to find out what I took time to tell people about my motivations. Then, and only then, sit in judgement.
As a matter of fact, the IETF is looking very hard at solutions to the problem I raise and has for the past several years been very explicitly reaching out to operators and others. A GSE/8+8 approach, which is the root of several proposed solutions in that area, can't work without the components fundamental to it, one of which is a NAT.
On Nov 26, 2008, at 1:27 AM, <michael.dillon at bt.com> <michael.dillon at bt.com > wrote:
Yeah, but we're trying to get rid of that stuff, or at least considerably reduce the cost and complexity, because (among otherthings) it presents a huge barrier to adoption of new multiparty apps.Promoters of NAT, particularly vendors, seem to have a two-valued view of the network in which inside is good and outside is evil. But network operators, who sit on the outside of the NAT, do not share that view. In fact, we see a future in which cloud computing centers within the network infrastructure will lead to a wide variety of new multiparty applications. In many cases the network operator also takes management responsibility for gateway devices, so the idea of evil on the outside is even further fetched. That said, if there is to be some form of NAT66 because there are real requirements elsewhere, it would be preferable if the defined default state of this NAT66 was to *NOT* translate addresses. This is not crazy if you see it in the context of a NAT device which includes stateful firewalling. I suggest that if part of the problem is an excess of pressure from vendors, then the IETF could resolve this by actively seeking greater input from other stakeholders such as network operators. --Michael Dillon _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.