I just published version 8 of RFC5206-bis (mobility), and version 5 of
the multihoming draft. These updates make the changes that were
discussed on the list in December; in summary, the updates were mainly
about moving additional material related to multihoming from the
RFC5206-bis draft to the multihoming draft.
The next update I plan to make is to add a description of how UPDATEs
may be forwarded through rendezvous servers, to handle the double jump
mobility scenario. There isn't any discussion about what to do when
UPDATEs are not acknowledged, so I propose to suggest that, upon failure
of obtaining an ACK to an UPDATE from a peer, the host should try any
other addresses that it knows about, and if those also fail, try to send
the UPDATE to the peer's rendezvous server (if known).
There were 13 open issues in the tracker against RFC5206-bis, but upon
review, many of them are multihoming questions, so I reassigned several
of them to the multihoming draft. Here are the issues against
RFC5206-bis that I see remaining.
Issue 8: decouple locator announcement from SA creation
http://trac.tools.ietf.org/wg/hip/trac/ticket/8
Issue 9: some implementations lack some of the compulsory UPDATE
features, so maybe they should not be mandatory
http://trac.tools.ietf.org/wg/hip/trac/ticket/9
Issue 12: sending UPDATE via rendezvous server (discussed above)
http://trac.tools.ietf.org/wg/hip/trac/ticket/12
Issue 15: suggestion for naming UPDATE packets
http://trac.tools.ietf.org/wg/hip/trac/ticket/15
Issue 21: UPDATE signature and HI inclusion
http://trac.tools.ietf.org/wg/hip/trac/ticket/21
Issue 23: Allow Locator fields to have flow bindings
http://trac.tools.ietf.org/wg/hip/trac/ticket/23
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
