![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> >> However, I do agree that anybody designing a protocol in > the last 3-4 > >> years *should* have designed it to be firewall and NAT friendly. > >> (Yes, I know that can be difficult in practice. I guess > that's today's > >> "Welcome to Reality"). > > > >> > In any event, I've always personally been of the opinion that > >> > if applications don't work in the face of NAT, then the > >> > applications themselves are functionally deficient and should be > >> > fixed. :-) > >> > >> ...and [NAT] must be taken into consideration when > designing protocols. > >> > >> .... New protocols should, in my opinion, > provide descriptions > >> of how they work or don't work with NAT. If there is a > reason why they > >> aren't going to work (carriage of port or address information), a > >> description of how to build an Application Layer Gateway > (ALG) should be > >> provided. Could someone please take a look at draft-welzl-ptp-01.txt, and tell me how this protocol could be turned NAT friendly. I doubt that it's possible. I expect some people to yell "bad design" then; but how would you provide this functionality? Certain things simply can't be done if we strictly stick with an end2end point of view - and I would of course be glad if someone tells me I'm wrong and comes up with a solution :) Regards, Michael Welzl
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.