[Hipsec] review of tracker issues for RFC 5206-bis

["Henderson, Thomas R" <[e-mail]>]

I would like to make an update of the RFC5206-bis draft by Monday's cutoff.  I will not make any technical changes between now and then so that there is time for people to discuss any changes, but I would like to review the open issues in this mail with a proposal for how to handle each of them.  I hope that, by the end of the Prague meeting, we could close most or all of the mobility-related issues.

For reference, the tracker issues are logged here:

http://trac.tools.ietf.org/wg/hip/trac/report/1

If you would like to start a thread on any of these proposals, can you please start one with a new subject line? 

I will discuss the issues related to mobility in particular; multihoming can be left for another time.

Ticket2:  inclusion of LOCATOR in R2 vs. R1

This is a proposal by Miika to shift the load balancing feature of the R1 LOCATOR to DNS-based schemes.  I am neutral to slightly against this proposal on the grounds that we try to avoid DNS reliance in HIP in general, and I am not convinced it is a burden on implementations.  I suggest no change, but feel free to convince me otherwise.

Ticket 4:  make before break use case missing
Ticket 5:  cross-family handovers missing from RFC5206-bis
Ticket 6:  specify peer-locator exposure policies and sending from unannounced locators
Ticket 8:  decouple locator announcement from SA creation

I support adding text for these four cases and will try to come up with a specific proposal for review on the list before adding to the published draft.  So, this would be added for the subsequent draft version (the next one past Monday's IETF-80 version).

Ticket 10:  LOCATOR/locator terminology in RFC 5206

I would like to suggest changing the name of this parameter to "LOCATOR-SET" but I will wait for comments on this suggestion before implementing it.  This would also need to change in the RFC5770-bis.

Tickete 11:  review ESP_INFO/SPI issues in RFC5206

this is a request to clarify whether the mappings of SPI to interface or locator are one-one or one-many.  draft-melen-hip-nat-mm-00 recommended to avoid assigning locators on different interfaces to a single SPI (this may be more an issue for the multihoming draft).

Ticket 12:  should UPDATE be sent via rendezvous server?

This requires coordination with RFC5204-bis but I support adding text to document this.

Ticket 13:  SEQ/ACK handling with respect to UPDATE

I do not really understand the concern so would like to request specific text change proposal.

Ticket 14:  can actual IP addresses of UPDATEs be used as locators, even if not in LOCATOR set?

In principle, it seems like this should be permitted; I do not see a reason why an implementation should be precluded from trying a locator found on the inbound IP packet, perhaps as a last resort.  I would suggest to add a statement along these lines.

Ticket 15:  suggestion for naming UPDATE packets

I believe that the basic request here is to reduce the number of possible different UPDATE scenarios, document them better, and modularize the separate concepts.  I will have a look at this in the subsequent revision.

----

So, in summary, I propose to do the following
- publish draft-ietf-hip-rfc5206-bis-02.txt by Monday, with updated references
- work on a suggested -03 draft for possible publishing during IETF 80 week or shortly thereafter, covering the above topics.

Tom