I'd like to try to wrap up the open issues on RFC5201-bis. There are four issues remaining in the tracker:
1) ticket 25: Orchid Generation Algorithm (http://trac.tools.ietf.org/wg/hip/trac/ticket/25) This issue was open to flag the need to revise RFC4843-bis. I believe that this has been done and the documents are now consistent (although the 5201-bis draft should point to the -03 version of the 4843-bis draft). I propose to close this with no further changes other than a reference refresh, if there are no objections. 2) ticket 39: Improve text relating to R1 counter rollover (http://trac.tools.ietf.org/wg/hip/trac/ticket/39) I'd like to propose the following text change: OLD TEXT (sec 4.1.4): The R1 counter SHOULD NOT roll over. NEW TEXT: The R1 generation counter may roll over or may become reset. It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer, or to a reset of the peer's counter. It is recommended that, when choosing between multiple R1s, the Initiatior prefer to use the R1 that is most consistent with the R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s. 3) ticket 40: decreasing the per-packet overhead (http://trac.tools.ietf.org/wg/hip/trac/ticket/40) Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding, to make them more bit-efficient. The proposals seem reasonable to me but there hasn't been much list discussion. Should we proceed with these changes? (suggested in this email: http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html) 4) ticket 41: LSI prefix range (http://trac.tools.ietf.org/wg/hip/trac/ticket/41) As I mentioned last month, it seems that the use of special IPv4 addresses (loopback prefix or class E prefix) may cause problems on some operating systems. However, I just scanned the draft and couldn't find any place where we are mentioning LSIs. It may be out of scope for 5201-bis. I propose to close this with no changes, perhaps just updating the tracker issue with the results of the implementation survey. If there is a future need to specify LSI ranges, it may be that RFC 1918 blocks or other address blocks known to be unused in a HIP environment could be recommended as LSIs. We also have the open issue of IANA allocation of an Orchid prefix, but that is a 4843-bis issue. - Tom _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
