| # | Type | Description | Status | Resolution / Current working assumption |
| 73 | Editorial | Port numbers in examples | Closed | Fixed in protocol-06. |
| 72 | Editorial | More editorial comments from Tero | Closed | Clarified in protocol-06. |
| 71 | Technical? | Failing RR | Closed | Added text in protocol -06. |
| 70 | Technical? | Non-SAD updates | Closed | Added appendix to protocol-06. |
| 69 | Editorial | RR requirements | Closed | Clarified in protocol-05. |
| 68 | Editorial | Conformance requirements | Closed | Clarified in protocol-05. |
| 67 | Editorial | Certain vs. possible changed address | Closed | Clarified in protocol-05. |
| 66 | Editorial | Imprecise NAT explanation | Closed | Clarified in protocol-05. |
| 65 | Editorial | Editorial comments from Jari | Closed | Editorial fixes and clarifications in protocol-05. |
| 64 | Editorial | Editorial comments and questions from Stephane | Closed | Clarified in protocol-06. |
| 63 | Technical | Extensiblity and payload? | Closed | No changes to protocol document, but noted for future work. |
| 62 | Editorial | Editorial comments from Francis | Closed | Editorial fixes and clarifications in protocol-05. |
| 61 | Technical | Version number, again | Closed | MOBIKE_SUPPORTED can be extended in protocol-05. |
| 60 | Technical | Addresses in IKE_SA_INIT/AUTH | Closed | Addresses from IKE_AUTH in protocol-06. |
| 59 | Editorial | Editorial comments from Tero | Closed | Editorial fixes and clarifications in protocol-05 and 06. |
| 58 | Editorial? | Deleting addresses | Closed | Clarified in protocol-06. |
| 57 | Technical | Question about "initiator decides" | Closed | No changes to protocol document. |
| 56 | Editorial | Ingress filtering compatibility | Closed | Clarified in protocol-05 and 06. |
| 55 | Editorial | MOBIKE scope and limitations | Closed | New text in protocol-05. |
| 54 | Editorial | Editorial comments from Marcelo | Closed | Clarifications in protocol-06. |
| 53 | Editorial | Editorial comments from Pete | Closed | Editorial fixes and clarifications in protocol-05. |
| 52 | Editorial | Security of address updates | Closed | No changes needed to protocol document. |
| 51 | Technical | SPI collisions | Closed | Added appendix in protocol-06. |
| 50 | Editorial | More editorial comments from Maureen | Closed | Editorial fixes and clarifications in protocol-05. |
| 49 | Editorial | Editorial comments from Maureen | Closed | Clarified in protocol-05. |
| 48 | Editorial | Editorial comments from James | Closed | Editorial fixes and clarifications in protocol-05. |
| 47 | Editorial | More comments from Mohan | Closed | Clarified in protocol-05. |
| 46 | Editorial? | Questions about additional addresses | Closed | Clarified in protocol-06. |
| 45 | Editorial | Clarifications to security considerations | Closed | Clarified in protocol-06. |
| 44 | Technical | NAT mapping changes and rekeying | Closed | Clarified in protocol-05. |
| 43 | Editorial | Editorial comments from Pekka | Closed | Editorial fixes and clarifications in protocol-03. |
| 42 | Technical | Review from Pekka | Closed | Several changes in protocol-03 |
| 41 | Technical | Mandate NAT prevention if not doing NAT-T? | Closed | NAT prevention mandatory if not doing NAT-T in protocol-03. |
| 40 | Editorial? | Review from Francis | Closed | Several changes in protocol-02 and -03. |
| 39 | Question | Question about how addresses change | Closed | Question answered on mailing list. |
| 38 | Editorial | Editorial comments from Shinta | Closed | Clarified in protocol-02. |
| 37 | Technical | Move MOBIKE_SUPPORTED to IKE_AUTH | Closed | Moved in protocol-02. |
| 36 | Technical | Handling UNACCEPTABLE_PATH | Closed | Clarified in protocol-02. |
| 35 | Technical | Adding version number to MOBIKE_SUPPORTED | Closed | Agreed not to add version number. |
| 34 | Technical | Separate path test, handling changes in NAT mappings | Closed | DPD to detect NAT mapping changes, no separate path test exchange |
| 33 | Technical | Changing ports 500/4500 and RR | Closed | Reason for changing ports clarified in protocol-02. |
| 32 | Technical | Omitting COOKIE2 from non-RR messages | Closed | COOKIE2 included only when doing RR in protocol-02. |
| 31 | Technical | Responder address changes | Closed | Details covered in other issues already. |
| 30 | Technical | Protocol ID in notifications | Closed | Protocol ID 0 used in protocol-01. |
| 29 | Editorial | Editorial comments from Tero | Closed | Editorial fixes and clarifications in protocol-01. |
| 28 | Editorial | Comments about security considerations text | Closed | Security considerations text updated in protocol-02. |
| 27 | Technical | Security and path testing | Closed | Security considerations text updated in protocol-02. |
| 26 | Technical | Window size and latest_update_counter | Closed | Clarified in protocol-01. |
| 25 | Editorial | Editorial comments from Mohan | Closed | Editorial fixes and clarifications in protocol-01. |
| 24 | Technical | NAT prevention details | Closed | Payload names changed in protocol-02. |
| 23 | Technical | Payload type for addresses | Closed | Separate payloads for IPv4/IPv6 in protocol-01. |
| 22 | Technical | Is disabling NAT traversal a possibility? | Closed | Payload names changed in protocol-02. |
| 21 | Editorial | Editorial comments from Lakshminath | Closed | Editorial fixes and clarifications in protocol-01. |
| 20 | Question | Selecting addresses for IPsec SAs | Decided | Initiator decides which address pair is used for IPsec SAs and informs the responder. |
| 19 | Question | Should IPsec traffic in both directions use the same pair of addresses (in stable situations)? | Closed | Since initiator decides, this becomes a local matter. |
| 18 | Question | Threat discussion | Decided | Attacks by the authenticated peer will also be considered. |
| 17 | Question | If both parties have several addresses, do we assume that all pairs have connectivity between them? | Decided | No, we should not assume full connectivity. |
| 16 | Question | Can the protocol recover from situations where the only sign of problems is lack of packets from the other end? | Decided | MOBIKE can be affected by multiple sources of information, including failing dead peer detection. |
| 15 | Question | How to do RR (empty informational exchange is not enough)? | Decided | Add "cookie" payload to informational exchange. |
| 14 | Question | Path testing and congestion | Decided | Path testing must follow congestion control best practices (see full issue for details). |
| 13 | Question | Does switching from IPv4 to IPv6 or vice versa work? Presumably only for tunnel mode? | Decided | Changing from IPv4 to IPv6 or vice versa should work for tunnel mode at least. |
| 12 | Question | Interaction with other protocols doing return routability? | Decided | Possible to do in the future, but beyond the current scope of MOBIKE WG. |
| 11 | Question | Window size vs. retransmissions and DPD | Closed | Details covered in other issues already. |
| 10 | Question | Changing addresses vs. changing paths. | Decided | Not assuming full connectivity (issue 17) implies that changing paths is sometimes necessary. |
| 9 | Question | Does MOBIKE require RFC2401bis? | Decided | Yes: IKEv2 requires RFC2401bis and MOBIKE requires IKEv2. |
| 8 | Question | Scope of SA changes: do we need per-IPsec SA granularity, or is it acceptable to use separate IKE SAs when needing this? | Decided | The addresses in all child SAs are updated at the same time. |
| 7 | Question | Do we support tunnel mode only, or tunnel mode first and transport later, or both by same document? | Decided | First document will consider only tunnel mode. |
| 6 | Question | When to do return routability checks? | Decided | By default, before moving traffic (see full issue for more details). |
| 5 | Question | Is "zero address set" (temporarily disabling SAs) functionality necessary? | Decided | No, there is no need to support this functionality. |
| 4 | Question | How to signal the other end that we support MOBIKE? Is it even necessary? | Decided | Use Notify payloads. |
| 3 | Question | Interaction with NAT traversal: does moving to behind NAT, from behind NAT, or from one NAT to another work? | Closed | Details covered in other issues already. |
| 2 | Question | Is simultaneous movement of both parties supported? | Decided | No; both parties can be mobile, but simultaneous movement is not supported. |
| 1 | Question | Is address change always requested explicitly, or can some "indirect indication" cause switching to another IP? Do "indirect indications" require address lists? | Closed | Details covered in other issues already. |
Issue type is either question (open design decision or a question deserving an answer from WG), technical (requesting technical change to document) or editorial (requesting editorial change to document). Questions may eventually change to technical/editorial issues, or lead to opening a new issue.
Status for questions is either no discussion, pending, or decided. Status for editorial/technical issues is either no discussion, pending, text required, text proposed, accepted, or rejected.
Submit new issues and comments to WG mailing list. The issues list is maintained by (pasi.eronen at nokia.com).