I'm having a hard time imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it means that there is something on path even worse than a NAT, right?
Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encaps? David On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov <smyslov.i...@gmail.com> wrote: > Hi, > > coming back to the yesterday discussion. There seems to be another issue > if implementation first sends request to update address over UDP and > then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - > it contains IP addresses and ports for initiator and responder. If you > leave it intact while switching to TCP, then it won't match real addresses > and the responder will treat it as NAT presence. In this case RFC 4555 > suggests to retry sending request several times with a new INFORMATIONAL > request. Probably we could clarify in TCP guidelines draft that the content > of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
