![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
>>>>> "Keith" == Keith Moore <moore at cs.utk.edu> writes:
>> Fourth, lots of folks (me included) happen to find it >> convenient to use NAT between my site/house/office and my >> upstream provider. Keith> do you also find it "convenient" that NAT has effectively Keith> thwarted the deployment of huge numbers of new Keith> applications, significantly raised the cost of deploying Keith> others, and harmed the reliability of all applications?
I find the tradeoffs work in favor of NAT; I expect this to be true both for V4 and V6.
Try tftp booting two devices from behind a NAT w/o a tftp ALG.
Yes this is a obscure case but is is a perfect example of why NAT is evil. Things that just should work fail and there is no end user fix.
With a plain firewall you can add rules to let the reply traffic through.
With a NAT you have to choose which device gets to boot as you can't port forward both sets of replies.
S
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.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.