Hi Valery
Thinking it over, I kind of regret adding the port field to the TCP_SUPPORTED
notification. We don't have any mechanism for alternate UDP ports. Yes, UDP has
cheap liveness checks to keep the mapping in the NAT so that requests can be
initiated to the original initiator, while TCP
On Dec 13, 2012, at 9:20 AM, Yoav Nir y...@checkpoint.com wrote:
Hi Valery
Thinking it over, I kind of regret adding the port field to the TCP_SUPPORTED
notification. We don't have any mechanism for alternate UDP ports. Yes, UDP
has cheap liveness checks to keep the mapping in the NAT so
Hi Yoav,
Hi Valery
Thinking it over, I kind of regret adding the port field to the
TCP_SUPPORTED notification.
We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap
liveness checks
to keep the mapping in the NAT so that requests can be initiated to the
original initiator,
On Fri, 14 Dec 2012, Valery Smyslov wrote:
Thinking it over, I kind of regret adding the port field to the
TCP_SUPPORTED notification.
We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap
liveness checks
to keep the mapping in the NAT so that requests can be initiated to the
Hi,
I'm a bit uncomfortable with the requirement that IKE peer MUST
advertise NAT device port if it is reachable and MUST NOT
if it isn't. I think, that IKE Initiator in most cases cannot
reliably determine whether it is reachable or not. For example,
even if you manually configured port
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.
Title : A TCP transport for the Internet Key Exchange
Author(s) : Yoav Nir
