Re: [Hipsec] RFC5206-bis and next steps

[Christian Vogt <[e-mail]>]

Tom -

I agree that NAT traversal support as well as support for handovers  
across address families would be useful to add to the document.  I  
don't see either of this as new functionality, but rather as a  
robustness improvement.

In regards of your suggestion to move use cases into a separate  
document:  Why not?  It makes sense in particular because the use case  
description is quite comprehensive.

- Christian



On Jan 6, 2010, at 7:11, Henderson, Thomas R wrote:

> Similar to what was started for RFC 4423 and 5201, I posted a new  
> version of RFC 5206 as draft-henderson-hip-rfc5206-bis-00.   
> Presently it is the same as RFC 5206.  I intend to use the trac  
> issue tracker once I can access it.
> http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt
>
> Since RFC5206 was written, we've had a number of developments:
>
> 1) NAT traversal draft (soon to be RFC):
> http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09
>
> 2) mobility management aspects of NAT traversal:
> http://tools.ietf.org/html/draft-melen-hip-nat-mm-00
>
> 3) There has been work from a couple of implementation teams on  
> cross-family handovers (which were largely out of scope of RFC 5206;  
> briefly mentioned in Section 3.2.7)
>
> 4) shim6 has published RFC 5334 that does failure detection and  
> locator pair exploration for shim6 contexts, but also has  
> applicability to HIP.
>
> 5) Mobile router draft
> http://tools.ietf.org/html/draft-melen-hip-mr-02
>
> My first question is how to scope the RFC5206 revision to take into  
> account this additional work.  On one hand, Gonzalo has previously  
> requested that, while we can rewrite/reorganize the RFC to improve  
> clarity, we should avoid adding functionality.  On the other, it  
> seems to me to be hard to ignore this additional progress when  
> revising RFC5206bis, because I think we would like to avoid asking  
> the future implementor to guess how one set of mechanisms (for  
> traditional mobility management) interact with another (when NAT  
> traversal is in use).
>
> My recommendation would be to make RFC5206bis be NAT-aware and cross- 
> family capable, but leave out the mobile router work (keep the scope  
> to be end-to-end mechanisms).  I think we should somehow reconcile  
> the similar but slightly different approaches to determining working  
> locator pairs that can be found in RFC5206, ICE, and RFC5534.
>
> My second question is about use cases and document organization.   
> Use cases are very important to document so that people understand  
> how these mechanisms work, but there are quite a few possibilities  
> (permutations) such as whether rekeying is simultaneously occurring  
> or not, in what order the events occur, whether NAT traversal occurs  
> or not (moving into and from a NATted environment), how mobility  
> events are detected or triggered, etc.  If we keep all of the use  
> cases together with the normative material in the document, the  
> document may get quite large.
>
> Another option to having a single document is to keep RFC5206bis  
> focused on normative material that is necessary to interoperate  
> (e.g. messages, required elements of procedure) and keep in parallel  
> a second informative "use cases" document that can also discuss how  
> platform-specific or implementation-specific policies impact the  
> operation of the protocol.  If we went down this path, we could take  
> Section 3 from RFC5206 as well as the use cases in draft-melen-hip- 
> nat-mm-00 and put them in a new hip-mm-use-cases document.  If this  
> approach were to work out, it would mean that the WG would prepare  
> two documents to replace RFC5206, one normative and one  
> informative.  I would be inclined to at least try this approach.
>
> Any comments or feedback on these choices?
>
> - Tom