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 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, w
On Dec 13, 2012, at 9:20 AM, Yoav Nir 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 that requests c
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 doe
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 forw
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
F
