Conclusion on issue 34

Based on discussion, it appears that most people prefer
the following:

   1) NAT-detection payload -based NAT reboot/change detection
       as a complement to existing source address -based
       mechanisms. This mechanism would be used if MOBIKE
       is on, because otherwise MOBIKE probing would become
       harder.

       Detection would be done by including NAT detection
       payloads in dead peer detection messages.

       Existing source address -based detection is still allowed in
       limited manner:  "MUST NOT do automatic update with
       IKEv2 packets when MOBIKE is used (breaks the probing),
       but you MAY do it for ESP packets."

   2) Use IKE messages for the path testing that is needed
       in MOBIKE.

I have specifically left out the conclusion about whether
to do return routability after a NAT change is detected.
I'm hoping its covered by the policy that we already have
for return routability usage. If people disagree about this
we'll open a separate issue on it.

Also, it was brought up during the discussion that our
charter talks about NAT traversal, requires us to not
change IKEv2 NAT traversal but also requires us to
document how they work together. There has been a
discussion of how well the different alternative proposals
follow the charter. We discussed this with Paul and
concluded that its important we choose the solution
that the group feels is the technically correct one.
The charter requires us to document interactions,
which we are doing. We also do not change anything
in the regular NAT traversal behaviour, except that
when both NAT traversal and MOBIKE are being
used we need to handle source address changes
in MOBIKE-compatible manner. We realize that
any specification of the interaction that goes beyond
("they can be used completely independently" and
"they can not be used together at all") is walking
a fine line between complying and violating the
charter. But we feel that in this case we are still
reasonably within charter.

--Jari