Stephane Beaulieu wrote:
>
> I would prefer to avoid sending periodic probes (option 3).
Note that these periodic probes are already present in normal
IKEv2; option 3 just piggy-backs additional information (NAT
detection payloads) to the same messages.
> Even though the HW may not be capable of detecting and
> performing IP/port changes *today*, they will be able to do it
> in the future (especially if we make it a requirement for
> them).
>
> It's not like if Mobike is going to be mass deployed tomorrow.
> This is going to take a long time to bake and test. Start
> working with your HW vendors now, and let's do it right the
> first time. Those who ship before the HW is ready can
> document this corner case, or solve it via some less efficient
> SW workaround (for now). I'd rather take the performance hit
> for BETA than forever...
>
> I vote option 1.
Since the same messages are sent in normal IKEv2 as well,
option 3 has a performance hit (on gateway load) only if
choosing it causes the users to change the timer values
for DPD ("X" in my IETF63 slides; essentially how long to
accept a situation where we have only outgoing traffic before
getting suspicious and starting DPD).
This is what I was initially worried about as well (choosing
option 3 would lead to users choosing significantly smaller
values for X), but I'm not so sure anymore this would happen...
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.